GX64 APPLICATION NOTE GSM Multiplexer Feature. Reference: WI_DEV_Gx64_APN_006 Revision: 001 Date: 2007/01/30

Transcription

1 GX64 APPLICATION NOTE GSM Multiplexer Feature Reference: WI_DEV_Gx64_APN_006 Revision: 001 Date: 2007/01/30

2 Trademarks, WAVECOM, 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. Page: 2/24

3 Table of Contents 1 Overview Glossary Introduction BENEFITS OF MUX INTENDED AUDIENCE Use Case Examples GR/GS MUX Implementation BASIC OPTION CONVERGENCE LAYER TYPE NUMBER OF CHANNELS PARAMETER NEGOTIATION MODEM STATUS COMMAND BAUD RATE FLOW CONTROL LOW POWER MODE T3 TIMER Application Design Considerations LOCAL AND GLOBAL SETTINGS AT COMMANDS NOT APPLICABLE IN MUX MODE AIR INTERFACE LIMITATION APPLICATION DATA RECOVERY Page: 3/24

4 6.5 FLOW CONTROL AND BUFFER MANAGEMENT OVERHEAD AND TIMING CONSIDERATIONS OPTIMAL CHANNEL USAGE Host Side MUX Driver Designs References Appendix A Basic MUX Procedures Page: 4/24

5 1 Overview This document provides an overview of GSM Multiplexer feature defined by 3GPP specification, details of 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 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. 2 Glossary GSM 3GPP Multiplexing protocol CS DCE DLC DTE FCS Circuit Switched Data Circuit terminating Equipment Data Link Connection virtual serial channel Data Terminal Equipment Frame Check Sequence HDLC High-level Data Link Control (ISO/IEC 13239:1997) Host Application MSC MS MO MT MUX SABM Serial Mode TE UIH A TE side customer application Modem Status Command Mobile Station (i.e. GR/GS64 Wireless CPU) Mobile Originated Mobile Terminated Multiplexer Set Asynchronous Balanced Mode The Non-MUX mode GR/GS64 starts up into Terminal Equipment Unnumbered Information with header Check Page: 5/24

6 3 Introduction The 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 features please refer to [1]. GSM specs can be found at URL: TE MS TE Processes Convergence Layers Multiplexer Layer Physical Layer - serial link MS Processes Convergence Layers Multiplexer Layer Physical Layer - serial link Figure 1: protocol stack Figure 1 shows the arrangement of the 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 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 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. Page: 6/24

7 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 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 specification and GR/GS64 AT command manual. Before reading this document, readers should have a basic understanding of the standard itself and a basic working knowledge of GR/GS64 AT commands. Page: 7/24

8 4 Use 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. Page: 8/24

9 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. Page: 9/24

10 5 GR/GS MUX Implementation GR/GS implementation conforms to the Release 99 GSM specification 3GPP version GPP defines three operating options: basic, advanced without error recovery and advanced with error recovery. The GR/GS64 supports basic option. 3GPP defines four convergence layer types and GR/GS64 only supports convergence layer type 1. All other MUX services that are defined in the spec but not mentioned in this section are not supported by GR/GS 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. Page: 10/24

11 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 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 Bit, Name Output Signal Input Signal 3, RTC DSR DTR 4, RTR CTS RTS 7, IC RI -ignored 8, DV DCD -ignored Break Signal is not supported in the MSC. Page: 11/24

12 5.6 Baud Rate GR/GS64 supports baud rates ranging from 9600 to 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 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 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 spec) to provide fast response. Please see section 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. Standbyhandshaking 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. Page: 12/24

13 6 Application 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 Abortable Execution Required Setting by &F, with with 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. Page: 13/24

14 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 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 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 tends to have long recovery time if frames become out-of-sync. Page: 14/24

15 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 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, deasserting 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 Page: 15/24

16 channels in the UART IO buffer. As a result, individual data flow can not be stopped right away. This constraint is inherent to 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 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. Address Control Length Information FCS Indicator 1 octet 1 octet 1 octet 1 octet Integral number of 1 octet 1 octet octets The overhead of 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. Page: 16/24

17 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. 7 Host Side MUX Driver Designs In a typical host application that uses MUX, 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 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. Page: 17/24

18 DTE Application Write Control Read Port Emulation Entity Port interface e.g. Wavecom CMUx dirver DCE Request Control Parameters Response Control Parameters Confirm Parameter Setting Indication Parameter Setting service interface Figure 3: 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 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 ( Portmon ( 8 References 1. 3GPP TS V3.4.0 ( ) Terminal Equipment to User Equipment (TE-UE) multiplexer protocol (Release 1999) 2. AT Command Manual for GR64 & GS64 Page: 18/24

19 Appendix A Basic MUX Procedures To facilitate the understanding of the 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 DLC 0 SABM Length = 0 FCS Closing F D7 F9 F D7 F9 DLC 0 UA Length = 0 FCS Closing 3) Establish DLC 1 F9 03 FF A 1F FB F9 F9 03 FF DLC 0 UIH Length 10 Parameter Negotiation Command Length 8 DLC 1 Covergence Layer type A 1F FB F9 Page: 19/24

20 Priority: 1 T1: 10 N1: 31 N1: 0 Lower 8 bit Higher 8 bits N2: 3 K: 1 FCS Closing F9 03 FF A 1F FB F9 F9 03 FF DLC 0 UIH Length 10 Parameter Negotiation Response Length 8 DLC 1 Covergence Layer type A 1F FB F9 Priority: 1 T1: 10 N1: 31 N1: 0 Lower 8 bit Higher 8 bits N2: 0* K: 0* FCS Closing * 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 DLC 1 SABM Length = 0 FCS Closing F F9 F F9 DLC 1 UA Length = 0 FCS Closing Establish DLC2 F9 03 FF A 1F FB F9 F9 03 FF Page: 20/24

21 DLC 0 UIH Length 10 Parameter Negotiation Command Length 8 DLC 2 Covergence Layer type A 1F FB F9 Priority: 1 T1: 10 N1: 31 N1 Lower 8 bit Higher 8 bits N2: 3 K: 1 FCS Closing F9 03 FF A 1F FB F9 F9 03 FF DLC 0 UIH Length 10 Parameter Negotiation Response Length 8 DLC 2 Covergence Layer type A 1F FB F9 Priority: 1 T1: 10 N1: 31 N1: 0 Lower 8 bit Higher 8 bits N2: 0* K: 0* FCS Closing F9 0B 3F F9 F9 0B 3F F9 DLC 2 SABM Length = 0 FCS Closing F9 0B F9 F9 0B F9 Page: 21/24

22 DLC 2 UA Length = 0 FCS Closing 4) DLC1 Modem Status Command F9 03 FF 09 E EE F9 F9 03 FF 09 E3 05 DLC 0 UIH Type Length = 4 MSC Type Command Length= EE F9 DLC 1 V.24 signal FCS Closing F9 03 FF 09 E EE F9 F9 03 FF 09 E1 05 DLC 0 UIH Type Length = 4 MSC Type Command Length= EE F9 DLC 1 V.24 signal FCS Closing Page: 22/24

23 5) Close down MUX F FD F9 F FD F9 DLC 0 DISC Length = 0 FCS Closing F F9 F9 0B F9 F D7 F9 F F9 DLC 1 UA Length = 0 FCS Closing F9 0B F9 DLC 2 UA Length = 0 FCS Closing F D7 F9 DLC 0 UA Length = 0 FCS Closing Page: 23/24

24 P Floor Page: 24/24 WAVECOM S.A. - 3 esplanade du Foncet Issy-les-Moulineaux Cedex - France - Tel: +33(0) Fax: +33(0) Ce document Wavecom, est Inc. la - propriété 430 Davis Dr. exclusive Suite 300 de - Research WAVECOM. Triangle Il ne Park, peut NC être communiqué - USA - Tel: +1 ou 919 divulgué à - Fax: des tiers sans son autorisation préalable nd WAVECOM Asia Pacific Ltd. - Unit , 2P - Bio-Informatics Centre - No. 2 Science Park West Avenue - Hong Kong Science Park, Shatin - New Territories, Hong Kong - Tel: Fax: