Wavecom GX64 GSM 27.010 Multiplexer Feature Installation and operating instructions

GX64
A
PPLICATION NOTE
GSM 27.010 Multiplexer
Feature
Reference:
W
I_DEV_Gx64_APN_006
Revision: 001
Date: 2007/01/30

Trademarks
®, WAVECOM
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
®, WISMO®, Open AT®, Wireless CPU®, Wireless Microprocessor®and certain
other trademarks and logos appearing on this document, are filed or registered trademarks
of Wavecom S.A. in France or in other countries. All other company and/or product names
mentioned may be filed or registered trademarks of their respective owners.
Copyright
This manual is copyrighted by WAVECOM with all rights reserved. No part of this manual may
be reproduced in any form without the prior written permission of WAVECOM.
No patent liability is assumed with respect to the use of the information contained herein.
No Warranty
WAVECOM publishes this manual without making any warranty as to the content contained
herein. Further Wavecom Inc reserves the right to make modifications, additions and
deletions to this manual due to typographical errors, inaccurate information, or
improvements to programs and/or equipment at any time and without notice. Such changes
will, nevertheless be incorporated into new editions of this manual.
27.010 MUX Feature
Page: 2/24

Table of Contents
1Overview................................................................................................. 5
2Glossary.................................................................................................. 5
3Introduction ............................................................................................ 6
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
3.1 ......................................................................................................... 7BENEFITS OF MUX
3.2 .................................................................................................... 7INTENDED AUDIENCE
4Use Case Examples ................................................................................. 8
5GR/GS64 27.010 MUX Implementation.................................................. 10
5.1 ............................................................................................................. 10BASIC OPTION
5.2 ..................................................................................... 10CONVERGENCE LAYER TYPE 1
5.3 ............................................................................................... 10NUMBER OF CHANNELS
5.4 .......................................................................................... 11PARAMETER NEGOTIATION
5.5 ........................................................................................ 11MODEM STATUS COMMAND
5.6 ................................................................................................................. 12BAUD RATE
5.7 .......................................................................................................... 12FLOW CONTROL
5.8 ...................................................................................................... 12LOW POWER MODE
5.9 .................................................................................................................... 12T3 TIMER
6Application Design Considerations........................................................ 13
6.1 .................................................................................... 13LOCAL AND GLOBAL SETTINGS
6.2 .......................................................... 14AT COMMANDS NOT APPLICABLE IN MUX MODE
6.3 ........................................................................................ 14AIR INTERFACE LIMITATION
6.4 ................................................................................... 14APPLICATION DATA RECOVERY
27.010 MUX Feature
Page: 3/24

Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
6.5 ............................................................... 15FLOW CONTROL AND BUFFER MANAGEMENT
6.6 ................................................................. 16OVERHEAD AND TIMING CONSIDERATIONS
6.7 .......................................................................................... 17OPTIMAL CHANNEL USAGE
7Host Side MUX Driver Designs............................................................... 17
8References ............................................................................................ 18
Appendix A – Basic MUX Procedures............................................................ 19
27.010 MUX Feature
Page: 4/24

1Overview
This document provides an overview of GSM Multiplexer feature defined by 3GPP
27.010 specification, details of 27.010 multiplexer features supported by Wavecom
GR/GS64 Wireless CPU, and application design considerations. This document is
intended as a reference for integrators, as an aid to understanding and implementing
27.010 multiplexer feature. These notes are written to be informative and helpful,
but they are by no means definitive or exhaustive in their content or suggestions.
2Glossary
27.010 GSM 3GPP 27.010 Multiplexing protocol
CS Circuit Switched
DCE Data Circuit terminating Equipment
DLC Data Link Connection – virtual serial channel
DTE Data Terminal Equipment
FCS Frame Check Sequence
HDLC High-level Data Link Control (ISO/IEC 13239:1997)
Host Application A TE side customer application
MSC Modem Status Command
MS Mobile Station (i.e. GR/GS64 Wireless CPU)
MO Mobile Originated
MT Mobile Terminated
MUX Multiplexer
SABM Set Asynchronous Balanced Mode
Serial Mode The Non-MUX mode GR/GS64 starts up into
TE Terminal Equipment
UIH Unnumbered Information with header Check
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 5/24

3Introduction
The 27.010 multiplexer protocol operates between an MS (e.g. GR/GS64) and a TE
(i.e. a host application) and allows a number of simultaneous virtual channels over a
serial asynchronous interface (e.g., a RS232 link). GPRS data, SMS data, AT
commands, unsolicited responses, etc. can be sent on different channels. When
virtual channels are established, they begin in AT command mode and each channel
acts like a virtual serial link from a host application point of view. For technical details
of 27.010 features please refer to [1]. GSM specs can be found at URL:
http://www.3gpp.org.
Physical Layer -
serial link
Multiplexer Layer
Convergence
Layers
MS Processes
Physical Layer -
serial link
Multiplexer Layer
Convergence
Layers
TE Processes
TE MS
Figure 1: 27.010 protocol stack
Figure 1 shows the arrangement of the 27.010 protocol stack. The multiplexer layer
provides multiplexing of data; if the structure of the data has to be conveyed, a
convergence layer may be necessary.
The 3GPP 27.010 specification is intended to define a protocol that can be used to
emulate a serial port. Each virtual channel does best-effort emulation of a serial link.
Each channel may have individual flow control procedures for buffer management
purposes and Modem Status Command(MSC)s are used to emulate serial link control
signals (such as RTS, CTS, DTR, DSR, DCD).
AT+CMUX command enables the 27.010 MUX control channel and it is the first step
in starting the MUX. The basic MUX set up procedures are described in Appendix 1.
A MUX driver is needed on the host application side to enable the host application to
communicate with GR/GS64 using MUX protocol.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 6/24

3.1 Benefits of MUX
The existence of simultaneous virtual channels in MUX mode creates advantages over
serial mode where only one link is available. Some benefits are as follows:
1. A host application can parse AT command results and unsolicited responses
on different channels.
2. A GPRS or a CSD data session can run in one channel uninterrupted while
unsolicited responses and AT command controls can be handled in other
channels.
3. In host applications that have 3 wire interfaces, MSCs provide virtual signals
such as DTR, DCD, RI, etc.
These benefits are demonstrated in the use case examples in section 4.
3.2 Intended Audience
This application note is intended for integrators who have experience writing serial
communication programs and intend to develop and integrate a host side MUX driver
according to the GSM 27.010 specification and GR/GS64 AT command manual. Before
reading this document, readers should have a basic understanding of the 27.010
standard itself and a basic working knowledge of GR/GS64 AT commands.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 7/24

4Use Case Examples
In this section, we will examine several use case scenarios where MUX channels are
advantageous. Comparisons between serial mode and MUX mode are also provided. In
following scenarios, a GPRS data connection could be an on-board TCP/IP socket
connection or a dial up GPRS connection.
Scenario 1: Mobile terminated SMS while in online data mode
Serial mode:
After a host application establishes a GPRS data connection, the serial link enters
online data mode. Subsequent SMS unsolicited responses are buffered or discarded
depending on the +CNMI setting. When the host application is expecting an MT SMS,
it can only do it in two ways:
•Periodically switch to online command mode and check the SMS messages.
•Monitor the RI pin to detect incoming SMS if AT*E2SMSRI is enabled.
The first method may not work if the host application has to process SMS messages in
a timely fashion. The second method may not work due to the possible hardware
constraints of the host application.
MUX mode:
The host application uses two virtual channels, one for GPRS data connection (using
AT+CGDCONT, AT+CGACT, AT*E2IPO, etc.) and one for AT commands. Enable the
SMS unsolicited responses (using AT+CNMI) in the AT command channel and host
application can receive SMS notification right away.
Scenario 2: Unsolicited responses while in online data mode
Serial mode:
A host application can not receive unsolicited responses in on-line data mode. If the
host application relies on certain status to determine the execution of the program, it
has to switch between online data mode and online command mode at certain
intervals and then query for the status. This might not work reliably in some cases.
For example, if the host application relies on the +CGREG unsolicited response to
make sure data is always not sent while roaming.
MUX mode:
The host application uses two virtual channels, one for data connection and one for
unsolicited responses. Upon the receipt of +CGREG roaming unsolicited response,
application can stop the data flow immediately.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 8/24

Scenario 3: AT commands and unsolicited responses in different channels
Serial mode:
A host application has to parse both AT commands and unsolicited messages, which
can be complex.
MUX mode:
The host application uses two virtual channels, first one for AT commands and second
one for Unsolicited Responses. On the first channel, the host application only parses
AT commands responses and on the second channel, it only parses unsolicited
responses.
Scenario 4: AT command control while in online data mode
Serial mode:
Again a host application has to switch between online data mode and online
command mode in order to use AT commands, such as AT+CSQ. The host
application has to explicitly suspend GPRS session in order to switch between modes.
MUX mode:
The host application uses two virtual channels, one for data connection and one for
AT commands. The host application can send data without being interrupted on the
data channel while it sends AT+CSQ and other commands are on another channel.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 9/24

5GR/GS64 27.010 MUX Implementation
GR/GS64 27.010 implementation conforms to the Release 99 GSM specification 3GPP
27.010 version 3.4.0. 3GPP 27.010 defines three operating options: basic, advanced
without error recovery and advanced with error recovery. The GR/GS64 supports basic
option. 3GPP 27.010 defines four convergence layer types and GR/GS64 only
supports convergence layer type 1. All other MUX services that are defined in the
27.010 spec but not mentioned in this section are not supported by GR/GS64.
5.1 Basic Option
The GR/GS64 supports basic option and thus it only supports non-error-recovery
mode and uses UIH frame to carry user data. In addition, basic option also means the
following:
- Length indicator used instead of the HDLC transparency mechanism.
- Different flag octet (0xF9) from that used by HDLC.
- Can not be used on links that use XON/XOFF flow control.
- May have longer recovery procedure from loss of synchronization.
Basic option is intended for serial links with good quality.
5.2 Convergence Layer Type 1
GR/GS64 only supports convergence layer type 1. Convergence layer type 1 is used to
transfer over channels where there is no need to convey the control signals (such as
embedded V.24 signals) along with the information. The V.24 information instead will
be carried by the MSCs on the MUX control channel. Only UIH frames are used for data
frames.
5.3 Number of Channels
A Data Link Connection (DLC) is used to identify a virtual channel. A MUX control
channel (DLC 0) is used to exchange management information, such as parameter
negotiation, testing, flow control, close down, etc. In the context of this document,
channel and DLC will be used interchangeably.
GR/GS64 supports up to 8 channels in addition to a MUX control channel. MUX
control channel has high priority and all other channels have same priorities.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 10/24

5.4 Parameter Negotiation
Individual channel parameters such as priority, acknowledgement timer, maximum
frame size, and maximum number of retransmissions are optional for negotiation
according to 27.010 standard. GR/GS64 only supports maximum frame size
negotiation. The upper limit of the negotiable maximum frame size is 127 bytes.
AT+CMUX command uses the parameter N1 to set the default value of the Maximum
Frame Size. The actual maximum frame size can be then negotiated when DLCs are
established via Parameter Negotiation Command.
5.5 Modem Status Command
Physical RS232 control signals DTR, DCD and RI are disabled when MUX is activated.
Instead virtual signals (MSCs) are used to simulate those signals for individual DLCs.
In MUX mode AT commands such as AT+IFC, AT&D, AT&S, and AT&C control the
behaviours of individual DLCs’ virtual signals rather than the physical UART control
signals. DLCIs (Data Link Connection Identifiers) and virtual modem signals RTS, CTS,
DTR, DSR, DCD and RI modem signals are specified in the MSC frames and MSCs are
sent on the MUX control channel. Virtual modem signals are mapped to the following
bits in a MSC command frame.
Control Signal
Output Signal Input Signal
Bit, Name
3, RTC DSR DTR
4, RTR CTS RTS
7, IC RI -ignored
8, DV DCD -ignored
Break Signal is not supported in the MSC.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 11/24

5.6 Baud Rate
GR/GS64 supports baud rates ranging from 9600 to 230400. They correspond to the
third parameter of the AT+CMUX command.
If autobaud is active (i.e. AT+IPR=0) when the MUX is started, it is automatically
turned off and the MUX continues to operate at the baud rate in which the +CMUX
command is entered. For example, if auto baud is active, a host application can switch
baud to 115200 and send AT+CMUX=0,0,5<CR> and SABM on channel 0 at that
baud rate. Once the MUX is closed the module will be placed back into autobaud.
On the other hand, if autobaud is OFF (e.g. AT+IPR=115200), the host application has
to send AT+CMUX=0,0,5<CR> and send SABM at the baud rate of 115200. Sending
them at any other baud rate will fail.
5.7 Flow Control
Two kinds of flow controls are supported by GR/GS64 MUX.
•Individual channel flow control enabled by MSC
•Aggregate flow control enabled by the Hardware signals RTS and CTS.
Individual channel flow control is achieved via MSC on the MUX control channel.
Aggregate flow control is achieved by hardware and the hardware handshake signals
are used instead of FCon and FCoff (defined in 27.010 spec) to provide fast response.
Please see section 6.5 - Flow control and Buffer Management for more information.
5.8 Low Power Mode
Autonomous standby mode stays effective in MUX mode if it was enabled (by
AT*E2RS232 command) in serial mode before activation of the MUX mode. Standby-
handshaking on the other hand does not work with MUX because it involves direct
control of RS232 signal lines.
5.9 T3 Timer
After GR/GS64 has received AT+CMUX command, if it does not receive SABM on
channel 0 before the timer T3 expires, it will revert to normal AT mode. Since the MUX
activation usually takes more than 4 seconds for GR/GS64, T3 parameter of the
AT+CMUX command should be greater than 10 seconds.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 12/24

6Application Design Considerations
When designing a host application that uses MUX, following have to be taken into
considerations up front.
6.1 Local and Global Settings
Integrators must take local and global settings into consideration when designing
host application that utilizes MUX. AT commands with settings are identified as either
global or local under “Parameter Setting” of the AT commands characteristic table in
the AT commands manual [2]. For example the table for +CNMI is as follows.
Command Long SIM Parameter Affected Works Works CFUN
by &F, with with
Abortable Execution Required Setting Modes
&W USB MUX
No No Yes Local Yes Yes Yes 1,4,5
Under “Parameter Setting”:
Local - means that a change to the setting will only take affect in the channel where
the change was made. For example, if the user has 2 MUX channels active, and
make a change to a Local parameter on one MUX channel, the other MUX
channel would not see the change. One example is the AT+CNMI setting.
Global - means that if a change to a setting is made on any channel, all channels will
see the affect of the change. For example, if a change is made on one MUX
channel, any other active MUX channel would also experience the change. One
example is the AT+CGDCONT setting.
ATZ, AT&V and AT&W allow the user to restore, view and store the current profile
parameters in non-volatile memory. AT&Y specifies which profile gets loaded on
start-up of GR/GS64 wireless CPU. In the MUX mode, the last channel that executes
the AT&W command has its local setting stored which is persistent through power
cycle.
Most of the unsolicited responses (such as +CREG, +CGREG, +CGEV, +CMTI, +CIEV,
*ECIND) are “local” to a channel. They are only outputted in channels that have the
unsolicited responses turned on. For example for two active MUX channels, if only
channel one has AT+CREG=1 or AT+CREG=2 set, +CREG unsolicited response only
get outputted in channel one. On the other hand, unsolicited response “RING” or
“+CRING” (depending on the AT+CRC setting) comes out of all MUX channels.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 13/24

Some local settings may cause “global” activities and should only be set in one
channel. For instance ATS0 and AT+CGAUTO should not be used in more than one
channel.
6.2 AT Commands Not Applicable in MUX Mode
Some AT commands are not applicable in MUX mode. One such an example is
AT+CMUX command – AT+CMUX set command returns ERROR in MUX mode. Another
example is AT+IPR command – this command may be issued in MUX mode but it will
have no effect on the channel’s operation. One can find whether or not a command
works with MUX in the AT commands’ characteristic table under “Works with MUX”.
6.3 Air Interface Limitation
Although 27.010 MUX provides capability to multiplex on the serial link, the air link is
not multiplexed; all the limitations of air link still apply in MUX mode. GR/GS64
wireless CPU is a mobile class B device; as a result, simultaneous GPRS data and
circuit-switched transactions (such as voice calls) are not possible.
For GR/GS64, GPRS will temporarily suspend to support circuit-switched activities
such as CS SMS, Location Updates and voice calls. After the circuit-switched
transactions finish, GPRS is resumed. In serial mode, in order to perform any MO CS
transactions a host application has to explicitly suspend or escape out of a GPRS data
session. But in the MUX mode, both MO and MT CS activities can happen while the
GPRS session is ongoing, which in turn makes the air link limitation an important
design consideration in the MUX mode.
6.4 Application Data Recovery
As discussed in section 6.3, GPRS can be suspended due to the nature of mobile class
B. A host application needs to have an application level mechanism to handle the
possibility of temporary data loss - either through a reliable transport protocol such
as TCP or other application layer re-transmission mechanisms.
Measures can also be taken to reduce the occurrence of GPRS suspension during
heavy GPRS data traffic. This can be managed by scheduling MO Circuit Switched
activities properly. Since MO CS SMS messages are more widely supported by carriers
than Packet Switched (GPRS) SMS messages, the default AT+CGSMS setting of 3 (i.e.
Circuit Switched preferred SMS) is used for simultaneous GPRS and MO SMS. In this
case scheduling would be beneficial.
On the other hand, a basic mode 27.010 does not guarantee reliable transmission of
user data through virtual channels. In basic mode only UIH frames are used to carry
user data and by definition, only headers are checked against FCS. Moreover, basic
mode 27.010 tends to have long recovery time if frames become out-of-sync.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 14/24

Although in most practical situations serial links have very good quality and thus have
very rare instances of transmission errors, host applications still have to make sure
there are application level error detection and recovery mechanisms in place.
6.5 Flow Control and Buffer Management
Figure 2 shows a typical set up for a host application that uses MUX feature. Buffers
that are involved in the MUX data flow are also included in the figure. Four channels
are used in this example.
Figure 2: MUX data flow
Gx64 APPLICATION NOTE
Individual channel flow control via MSC in the MUX mode is not as responsive as
hardware flow control used in the serial mode. As shown in Figure 2, individual
channel flow control (in Figure 2 flow control for DLC4 is shown) is applied at a higher
level (MUX layer) than the layer that hardware flow control operates. As a result, de-
asserting virtual RTS on the host application side will stop flow on the GR/GS64 side
slower than it will by hardware RTS signal. By the time the virtual RTS signal reaches
the upper layer of target side, some data could have already transmitted over the
serial link (e.g. from GR/GS64 UART IO buffer to Host UART IO buffer in Figure 2) and
some data could have travelled from DLC buffers to the UART IO buffer (e.g. from
DLC4 buffer to UART IO buffer on the GR/GS64 side in Figure 2). Data flow can not be
stopped at the UART IO buffer layer either because there could be data from other
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 15/24

channels in the UART IO buffer. As a result, individual data flow can not be stopped
right away. This constraint is inherent to 27.010 standard and a host application
should size its receiving buffers accordingly and carefully manage the data flow. This
can typically be accomplished by using a large buffer space to hold additional data or
to start flow control request early. Since the UART IO buffer on the GR/GS64 side has
a size of 8K, in the worst case a host application should allocate additional 8K bytes
worth of buffer space for the channel that carries the largest amount of data.
If possible, hardware flow control signals (RTS and CTS) should be enabled even in the
MUX mode. GR/GS64 relies on hardware flow control to provide fast aggregate flow
control on the serial link on top of Individual channel flow controls. If using large
buffers for individual channel flow control is not feasible, hardware flow control is
required to make sure there is no data loss.
6.6 Overhead and Timing Considerations
When multiple MUX channels are used, multiple data streams share a single
underlying serial link and thus an individual channel only gets a portion of the serial
link bandwidth.
27.010 MUX frames have 6 bytes overhead as shown in the table below. As a result, a
host application needs to determine what it should use as the maximum frame size.
Although overhead of MUX frames does not translate to air interface overhead, it
could change timing of the user data flow and buffer space requirements on the host
application side. If the frame size gets smaller, overhead becomes proportionally
higher. On the other hand, the larger the frame size, the more likely a frame error
happens – a bit error is more likely to cause a frame error for a large frame than for a
small frame.
Flag Address Control Length Information FCS Flag
Indicator
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
1 octet 1 octet 1 octet 1 octet Integral number of 1 octet 1 octet
octets
The overhead of 27.010 MUX frames and sharing of the underlying serial link could
cause a timing difference on how a host application receives and responds to user
data. The number of channels has a direct impact on the how much timing difference
a host application sees. This is because data from different channels will be put into a
shared UART IO buffer before they are sent through the serial link and a heavily
utilized channel may affect the throughput of other channels.
27.010 MUX Feature
Page: 16/24

6.7 Optimal Channel Usage
A host application can choose to use more than two channels. For example, one for
AT commands such as SMS commands and +CSQ command, one for unsolicited
responses, and one or more for on board TCP/IP socket connections, where each
socket connection runs in a separate channel.
It is generally good idea that a host application uses as few numbers of channels as
possible, thereby minimizing the use of resources (memory, processing power, etc.)
on both the host application side and GR/GS64 side. Although user data channels
have same priorities, as explained in section 6.6, a heavily utilized channel could
delay the servicing of other channels. The number of channels should be carefully
considered up front for the host application design.
7Host Side MUX Driver Designs
In a typical host application that uses MUX, 27.010 is part of a port driver which
includes a port emulation entity that supports serial communication APIs. The
communication APIs vary from operating system to operating system and from device
to device. 27.010 standard defines a set of services such as Request, Indication,
Response, and Confirmation that can be used by all port drivers. The services are
shown in the Figure 3.
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 17/24

DTE Application
DCE
Port Emulation Entity
Write
Read
27.010
27.010
Control
Request
Confirm
Control Parameters
Parameter Setting
Response
Indication
Port interface
e.g. Wavecom
CMUx dirver
Control Parameters
Parameter Setting
27.010
service
interface
Figure 3: 27.010 interfaces
Wavecom provides a Microsoft Windows XP CMUX driver if integrators request it from
Wavecom sales representatives and FAEs. This CMUX driver creates virtual com ports
for MUX channels. Many Windows application programs such as dial-up networking,
hyper terminal and ProComm can run directly on these virtual com ports. Wavecom
CMUX driver version 2.4.0.0 and above should be used with GR/GS64 products.
Serial port monitoring tools are helpful when it comes to debugging or evaluating the
host side MUX driver. Here are two examples of commonly used tools:
Free Serial Port Monitor (http://www.serial-port-monitor.com/index.html)
Portmon (http://www.microsoft.com/technet/sysinternals/utilities/portmon.mspx)
8References
1. 3GPP TS 27.010 V3.4.0 (2002-03) Terminal Equipment to User Equipment (TE-UE)
multiplexer protocol (Release 1999)
2. AT Command Manual for GR64 & GS64
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 18/24

Appendix A – Basic MUX Procedures
To facilitate the understanding of the 27.010 specification and the basic MUX
procedures, an example sequence of MUX frames is provided below. Note in the
following examples: Îstands for the flow from TE to MS and Ístands for flows from
MS to TE. If not otherwise specified all the octets below are Hexadecimal. For
example, F9 really means 0xF9. The sequence is taken from communication between
Wavecom MUX driver and GR/GS64. For more information on how to decode the
frames, please refer to [1].
1) Enable MUX control channel by issuing AT+CMUX=0,0,5,31,10,3,15,10<CR>.
2) Send SABM on DLC 0 to start up the MUX. If SABM is not received on DLC0 within
the timer T3 (The eighth parameter of +CMUX command). GR/GS64 returns to AT
command mode.
ÎF9 03 3F 01 1C F9
F9 03 3F 01 1C F9
Closing
Flag
Opening
Flag DLC 0 SABM Length = 0 FCS
ÍF9 03 73 01 D7 F9
F9 03 73 01 D7 F9
Closing
Flag
Opening
Flag DLC 0 UA Length = 0 FCS
3) Establish DLC 1
ÎF9 03 FF 15 83 11 01 00 01 0A 1F 00 03 01 FB F9
F9 03 FF 15 83 11 01 00
Parameter
Negotiation
Command
Length
8
DLC
1
Covergence
Layer type 1
Length
10
Opening
Flag
DLC
0 UIH
01 0A 1F 00 03 01 FB F9
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 19/24

N1: 31 N1: 0
N2: 3 K: 1 FCS Closing Flag
Priority: 1 T1: 10
Lower 8 bit Higher 8 bits
ÍF9 03 FF 15 81 11 01 00 01 0A 1F 00 00 00 FB F9
F9 03 FF 15 81 11 01 00
Parameter
Negotiation
Response
Length
8
DLC
1
Covergence
Layer type 1
Length
10
Opening
Flag
DLC
0 UIH
01 0A 1F 00 00 00 FB F9
N1: 31 N1: 0
N2: 0* K: 0* FCS Closing Flag
Priority: 1 T1: 10
Lower 8 bit Higher 8 bits
* GR/GS64 only supports parameter negotiation of N1: Maximum Frame Size. As a result both
N2 and K parameters are set to 0.
* Windows size K is not applicable in basic option
ÎF9 07 3F 01 DE F9
F9 07 3F 01 DE F9
Closing
Flag
Opening
Flag DLC 1 SABM Length = 0 FCS
ÍF9 07 73 01 15 F9
F9 07 73 01 15 F9
Closing
Flag
Opening
Flag DLC 1 UA Length = 0 FCS
Establish DLC2
ÎF9 03 FF 15 83 11 02 00 01 0A 1F 00 03 01 FB F9
F9 03 FF 15 83 11 02 00
Gx64 APPLICATION NOTE This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable
27.010 MUX Feature
Page: 20/24