tc3x mux guide03 01 - pudn.comread.pudn.com/downloads103/doc/project/423620/tc3x_mux_guide_v0… · reserved in the event of grant of a patent or the registration of a utility model

TC3xSiemens Cellular Engines

Multiplex Mode

Installing,Configuring,

Implementing

Version: V03.10DocID: TC3x_UG_01_V03.10

TC3x Multiplexer User's Guide

TC3x_UG_01_V03.10 - Released Page 2/50 10.01.2002

Document Name: TC3x Multiplexer User's GuideVersion: V03.10Date: 10.01.2002

DocId: TC3x_UG_01_V03.10Status: Released

General notesWith respect to any damages arising in connection with the described product or this document,Siemens shall be liable according to the General Conditions on which the delivery of the describedproduct and this document are based.This product is not intended for use in life support appliances, devices or systems where a malfunctionof the product can reasonably be expected to result in personal injury. Siemens AG customers using orselling this product for use in such applications do so at their own risk and agree to fully indemnifySiemens for any damages resulting from illegal use or resale.Applications incorporating the described product must be designed to be in accordance with thetechnical specifications provided in these guidelines. Failure to comply with any of the requiredprocedures can result in malfunctions or serious discrepancies in results.Furthermore, all safety instructions regarding the use of mobile technical systems, including GSMproducts, which also apply to cellular phones must be followed.Handheld applications such as mobile phones or PDAs incorporating the described product must be inaccordance with the guidelines for human exposure to radio frequency energy. The Specific AbsorptionRate (SAR) of the application must be evaluated and approved to be compliant with national andinternational safety standards or directives.

Subject to change without notice at any time.

Copyright noticeCopying of this document and giving it to others and the use or communication of the contents thereof,are forbidden without express authority. Offenders are liable to the payment of damages. All rightsreserved in the event of grant of a patent or the registration of a utility model or design.

Copyright © Siemens AG 2002

Trademark noticeMS Windows� is a registered trademark of Microsoft Corporation.



Contents

1 Introduction.................................................................................................................................. 61.1 Supported product versions and related documents........................................................... 61.2 References .......................................................................................................................... 61.3 Abbreviations....................................................................................................................... 7

2 Technical Requirements for system with PC Mux ................................................................... 82.1 System Software ................................................................................................................. 82.2 PC Multiplexer Simulation Software .................................................................................... 82.3 Hardware ............................................................................................................................. 8

2.3.1 Using virtual COM Ports....................................................................................... 82.3.2 Using physical COM Ports ................................................................................... 9

3 System Overview for the PC Mux ............................................................................................ 103.1 Multiplexer Architecture when using the PC Mux .............................................................. 103.2 Virtual Channels and AT commands................................................................................. 10

4 Installation of the components for the PC Mux...................................................................... 124.1 Hardware Installation......................................................................................................... 12

4.1.1 Using virtual COM Ports..................................................................................... 12Using physical COM Ports................................................................................................. 12

4.2 PC Mux Software Installation ............................................................................................ 134.2.1 Multiplexer Simulation (PC Mux)........................................................................ 13

5 Using the PC Mux as external multiplexer .............................................................................. 165.1 Starting the PC Mux .......................................................................................................... 165.2 Stopping the PC Mux.........................................................................................................185.3 Additional buttons of the PC Mux ...................................................................................... 195.4 Examples........................................................................................................................... 19

6 Internal work flow of the PC Mux............................................................................................. 226.1 Multiplexer Related Modules ............................................................................................. 23

6.1.1 Muxappl.exe with Pcmux.dll............................................................................... 236.1.2 Port.exe.............................................................................................................. 246.1.3 Controller.exe..................................................................................................... 246.1.4 Chopper.exe....................................................................................................... 256.1.5 Muxtester.exe..................................................................................................... 25

6.2 Additional Modules and Files............................................................................................. 256.2.1 Simulation.exe and Simulation.ini ...................................................................... 256.2.2 Log.exe .............................................................................................................. 256.2.3 Send.exe ............................................................................................................ 256.2.4 Process.exe ....................................................................................................... 256.2.5 Trace.exe ........................................................................................................... 26

6.3 The Internal Pipe System .................................................................................................. 26



7 Integrating the multiplexer into the customer application .................................................... 277.1 Tips and Tricks .................................................................................................................. 27

7.1.1 Terminal Flow Control ........................................................................................ 277.1.2 Timeout after starting the multiplexer................................................................. 27

7.2 Restrictions........................................................................................................................ 277.3 Multiplexer control and signaling lines............................................................................... 28

7.3.1 Flow Control ....................................................................................................... 297.3.2 Escape Sequence.............................................................................................. 30

7.4 Power Saving .................................................................................................................... 307.5 Flash Management............................................................................................................30

8 Structure of the multiplexer protocol ...................................................................................... 318.1 Introduction of the multiplexer protocol ............................................................................. 31Data link layer .............................................................................................................................. 31

8.2.1 Flag sequence.................................................................................................... 328.2.2 Address field ...................................................................................................... 328.2.3 Control field ........................................................................................................ 338.2.4 Length indicator.................................................................................................. 338.2.5 Information field ................................................................................................. 338.2.6 Frame checking sequence field (FCS) .............................................................. 33

8.3 State Diagrams.................................................................................................................. 348.3.1 Startup................................................................................................................ 378.3.2 DLC Establishment ............................................................................................ 388.3.3 Information transfer............................................................................................ 388.3.4 DLC release ....................................................................................................... 388.3.5 Closedown ......................................................................................................... 398.3.6 Multiplexer control channel ................................................................................ 398.3.6.1 Multiplexer close down (CLD) ............................................................................ 398.3.6.2 Test command (Test)......................................................................................... 408.3.6.3 Modem status command (MSC) ........................................................................ 408.3.6.4 Non-supported command response (NSC) ....................................................... 41

8.4 Samples of establishing logical channels.......................................................................... 418.4.1 Establishing logical channels without parameter negotiation............................. 418.4.2 Closing the multiplexer protocol and returning to AT mode............................... 42

9 Version Control.......................................................................................................................... 439.1 Introduction........................................................................................................................ 439.2 Multiplexer versions........................................................................................................... 439.3 Implementation.................................................................................................................. 449.4 Case Descriptions ............................................................................................................. 45

9.4.1 Description case (01) ......................................................................................... 459.4.2 Description Case (02) ........................................................................................ 469.4.3 Description Case (03) ........................................................................................ 479.4.4 Description Case (04) ........................................................................................ 489.4.5 Abnormal Cases ................................................................................................ 48

9.5 Definitions.......................................................................................................................... 499.5.1 Coding of �TestCommand� message................................................................. 499.5.2 Example of �TestCommand� message .............................................................. 50



Figures

Figure 1: Multiplexer architecture........................................................................................................... 10Figure 2: Example configuration of the COM Ports when using virtual COM Ports............................... 12Figure 3: Connection of the COM ports when using an 8 Port serial Card ............................................ 12Figure 4: Simcominstall Tool.................................................................................................................. 13Figure 5: Starting the multiplexer simulation.......................................................................................... 16Figure 6: Start panel of the PC Mux....................................................................................................... 16Figure 7: Starting the multiplexer in the PC Mux ................................................................................... 17Figure 8: Start of the multiplexer in a terminal program......................................................................... 17Figure 9: Multiplexer Simulation status field description ........................................................................ 18Figure 10: Starting a multiplexer session............................................................................................... 19Figure 11: Multiplexer activation on Hyperterminal ................................................................................ 20Figure 12: Three active logical channels ............................................................................................... 21Figure 13: Integration of the multiplexer ................................................................................................ 22Figure 14: Flow control � RTS/CTS signaling........................................................................................ 29Figure 15: Data link layer ....................................................................................................................... 31Figure 16: Relationship between the customer µC and TC3X µC......................................................... 35Figure 17: MPl: Startup, DLC Establishment, Information Transfer....................................................... 36Figure 18: MP: DLC Release, Close Down............................................................................................ 37Figure 19: DLC Establishment ............................................................................................................... 38Figure 20: Information transfer............................................................................................................... 38Figure 21: DLC release.......................................................................................................................... 38Figure 22: Multiplexer control channel ................................................................................................... 39Figure 23: Modem status command (MSC)........................................................................................... 40Figure 24: Multiplexer control channel and logical channel, no parameter negotiation ......................... 42Figure 25: Possible combinations for version check.............................................................................. 43

Tables

Table 1: Comparison of multiplexer channels........................................................................................ 11Table 2: Available services if multiplexer is activated ............................................................................ 11Table 3: Commands with possible channel dependencies ................................................................... 28Table 4: Commands/Features without channel dependencies............................................................. 28Table 5: Address field ............................................................................................................................ 32Table 6: Assignment of the DLCI ........................................................................................................... 32Table 7: Use of the command/response bit ........................................................................................... 32Table 8: Coding of the control field ........................................................................................................ 33Table 9: Version cases .......................................................................................................................... 45Table 10: IEI coding ............................................................................................................................... 49Table 11: Coding of �TestCommand� (Example)................................................................................... 50



1 IntroductionThe TC3x supports the basic option of the multiplex mode according to the ETSI TS 101 369, GSM07.10 Multiplexer protocol and enables one physical serial interface to be partitioned into three virtualchannels. This allows you to take advantage of three simultaneous sessions running on one serialinterface. For example, you can send or receive data on the first channel, while the other two channelsare free to control the GSM engine with AT commands. In this document the multiplexer integration inthe module is also referred to as internal multiplexer.Outside the module on the application side of the serial interface another multiplexer must be integra-ted, in order to demultiplex the signal and distribute it on the 3 virtual channels. This externalmultiplexer must be provided by the user.For demonstration and test purposes a Windows program, the Multiplexer Simulation (PC Mux) isavailable, which simulates the external multiplexer on a PC running with Windows NT. The multiplexerprotocol (MP) sources can be provided.The purpose of this document is to describe how to install, configure and use the multiplexer in themodule as well as the Simulation of the multiplexer protocol (PC Mux) for Siemens TC3x GSM enginesand to explain how to integrate the external multiplexer in your application.

1.1 Supported product versions and related documentsPlease note that this User Guide is intended for TC35 Version V03.10

Related documents/1/ TC3x Hardware Interface Description V03.10/2/ TC3x AT-Command-Set V03.10/3/ Release Notes: TC3x, Version V03.10/4/ Application Note: Updating TC3x Firmware V03.10/5/ T35 Terminal Hardware Interface Description V03.10/6/ TC35 MC35 Terminal User's Guide V03.10

Prior to using TC35 / TC35T or upgrading to a new firmware release, be sure to carefully read andunderstand the latest product information provided in the Release Notes.

To visit the Siemens Website you can use the following link:http://www.siemens.com/wm

1.2 References[1] Digital Cellular Telecommunications Systems (Phase 2+); Terminal Equipment to Mobile Station

(TE-MS) "Multiplexer Protocol"; ETSI TS 101 369 V7.1.0 (1999-11), GSM 07.10 Version 7.1.0,Release 1998

[2] AT Command Set � Siemens Cellular Engines; Version 03.10



1.3 AbbreviationsCSD Circuit Switched Data

CTS Clear to Send

DCD Data Carrier Detect

DLCI Data Link Connection Identifier

DSB Developer Support Box

DSR Data Set Ready

DTR Data Terminal Ready

FC Flow Control

FFC Flat Flex Cable

GPRS General Packet Radio Service

GSM Global System of Mobile Communication

IEI Information Element Identifier

IP Internet Protocol

MO Mobile originated

MP Multiplexer Protocol

MS Mobile Station

MSDN Microsoft Developer Network

MT Mobile terminated

MUX Multiplexer

OS Operating System

PC Personal Computer

PC Mux Multiplexer Simulation

RTS Request to Send

TE Terminal Equipment

UART Universal Asynchronous Receiver Transmitter



2 Technical Requirements for system with PC Mux

2.1 System Software• Windows NT4.0

This requirement only refers to PC Mux software which we provide for testing purposes. It has beendeveloped for Windows NT 4.0. Of course the multiplexer protocol can be implemented in any OS.

2.2 PC Multiplexer Simulation SoftwareIn order to use the PC Mux, you get a *.zip file, which includes files to install the PC Multiplexer Simula-tion Program on your PC.The PC Mux is a Windows NT program, which enables the usage of the external multiplexer on a PC.This program is a suitable means to demonstrate and make use of the functionality of the multiplexerduring the development phase. Only the binary versions of the PC Mux files will be provided.

Provided files:When you extract the *.zip file the following files will be extracted onto your PC:

• chopper.exe• controller.exe• log.exe• muxappl.exe• muxport.exe• muxtester.exe• pcmux.dll• process.exe• send.exe• sharecnt.dll• simcom.sys• simcominstall.xls• simulation.exe• simulation.ini• trace.exe

The file pcmux.dll includes all *.c and *.h files, which form the multiplexer protocol. They must be inte-grated in the module software as well as on the PC side. Refer to chapter 6.1 for detailed informationabout the purpose of each file.

2.3 Hardware• Minimum Pentium III, 133 Mhz• e.g. DSB35 or TC35T (during development or testing phase)• TC35 module with baud rate set to 57600 bps

2.3.1 Using virtual COM Ports

• 1 RS232 interface• 1 RS232 cable



2.3.2 Using physical COM Ports

• 7 RS232 interfaces (e.g. 1 Serial 8 Port expansion card)• 3 null modem RS232 cables• 1 RS232 cable



3 System Overview for the PC MuxThe multiplex mode allows to communicate with the module over one serial interface simultaneouslywith 3 different customer applications (e.g. terminal programs). This is achieved by providing three vir-tual channels using a multiplexer (Mux).This is especially advantageous when a data call is ongoing. Without multiplexer no further access tothe module is possible without interrupting the data transfer. Using the multiplexer features like e.g.controlling the module or using the SMS service can be done via the additional channels without dis-turbing the data flow.Furthermore, several accesses to the module can be created with the multiplexer, which is advanta-geous when several independent electronic devices or interfaces are used.

3.1 Multiplexer Architecture when using the PC MuxTo make the three virtual interfaces (channels) available, both the TC3X module and the customerapplication must contain Mux components which communicate over the Multiplexer Protocol. In theTC3x module, the Mux/MP software is already incorporated. The customer application should eitherintegrate the TC3x Mux/MP software or include a Mux/MP developed by the customer.

3.2 Virtual Channels and AT commandsGenerally take into account, that a module including the multiplexer does not include three differentdevices, the module has only one single air interface, that means one RF part. The multiplexer simplyallows three simultaneous accesses to the module. So a call is never connected to a channel, but tothe device.The functionality scope is alike for all logical channels except for the data calls. Channel 1 supports thefull range of functions, which is available without MP. Channel 2 and 3 are connected to a different ATinterpreter and support a subset of the functional range of channel 1.

Figure 1: Multiplexer architecture

Terminal programsor internal programsintegrated in cus-tomer applicationplatform

User application TC35

Channel 1

Channel 2

Channel 3

Terminal 1

Terminal 2

Terminal 3

MP

Data/FaxSupported

Data/FaxNotSupported

SerialI/O

MUXconformingto GSM 07.10

1

2

3

SerialI/O

MUXconformingto GSM 07.10



Table 1 shows which features are available on each channel.

Voice callsincoming/outgoing

Data callsincoming/outgoing

SMSincoming/outgoing

Phonebookmanagement

ATcommands

Channel 1 � � � � �

Channel 2, 3 � --- � � � 1)

� indicates that the functionality is available on the channel--- indicates that the functionality is not available on the channel1) except for AT commands related to data

Examples:• While a data call is in progress on channel 1, you can send an SMS on channel 2 and edit the

phonebook on channel 3. The last access is the deciding one. When writing the same phonebookentry simultaneously on two different channels, the one writing last, is the one which will be perma-nent. The others will be lost.

• AT&V shows less settings when executed on channels 2 and/or 3 than on channel 1.• AT+CMGF can be configured separately for each channel.

Note:Data and voice calls are not possible simultaneously, because of the single air interface. For furtherrestrictions of the multiplexer mode please refer to [2] supplied with TC3x.The following table points out the main differences using the module with and without multiplexer:

Multiplexer activated

Logical channel 1 2 3Mode ATC and Data ATC ATC

The applications which access the module, must avoid mutual disturbances. They should know abouteach other´s functionality.

For further details regarding restrictions and interferences between the channels see also chapter 7.2.

Table 1: Comparison of multiplexer channels

Table 2: Available services if multiplexer is activated



4 Installation of the components for the PC Mux

4.1 Hardware InstallationThe following chapters describe the two different possibilities how to realize the physical connectionfrom the application (PC) to the module.

4.1.1 Using virtual COM Ports

Creating virtual COM ports avoids the installation of 7 COM ports (8 Port serial card) in your PC. Theapplications (e.g. terminal programs) must be connected to the 3 virtual COM Ports. The multiplexerinternally connects these 3 Ports to 3 other virtual Ports and maps them onto the one serial Port whichis physically connected to the DSB35 or TC35T. See chapter 4.2.1 to install the virtual ports.

Figure 2: Example configuration of the COM Ports when using virtual COM Ports

Note:When using virtual COM Ports RTS/CTS are not passed to the application. So data transfer is notpossible.

4.1.2 Using physical COM Ports

Figure 3: Connection of the COM ports when using an 8 Port serial Card

virtual COM ports

COM14

COM15

COM16

COM24

COM25

COM26

COM1

multiplexsimulation

controller

multiplex

HyperTerminal

HyperTerminal

HyperTerminal DSB35 orTC35T

COM 1COM 2COM 3COM 4COM 5COM 6COM 7COM 8

PC

TerminalProgram

TerminalProgram

TerminalProgram

FFC

Null Modem Cables

Serial Cable

DSB35

DSub9 ApplicationInterface

MP



Install the 7 COM ports (8 Port serial card) in your PC. Some systems may show problems and not allcards may be compatible with your system. The 8 Port serial card in your PC allows the usage ofphysical ports for the applications. The applications (e.g. terminal programs) must be connected to 3 ofthe 7 physical COM Ports. Connect these 3 Ports with 3 other Ports of the serial card with null modemcables (see Figure 3). The multiplexer internally maps these 3 Ports to the one serial Port which isphysically connected to the DSB35 or TC35T.

4.2 PC Mux Software Installation

4.2.1 Multiplexer Simulation (PC Mux)

Note:Attention: The multiplexer simulation only runs on Microsoft Windows NT 4.0 operating systems!

1. Create a directory on your hard disk were to save the files or use an existing directory and copy theinstallation files to your hard disk (further steps are done in the hard disk directory).

2. Remove the write protection from all files.

Steps 3 to 5 are only relevant when using virtual COM Ports. Otherwise proceed with step 6.

3. Change to directory ../simcom4. Open the Excel file simcominstall.xls and follow the steps to install the virtual COM ports. Figure 4

shows an example of how to install the virtual COM Ports. Choose the Port numbers according toyour system configuration. With the Remove button the COM Ports can be deinstalled again.

5. Reboot the system

6. Open the file simulation.ini in a text editor and adapt the numbers and baudrate in the sectionsCHANNEL0, CHANNEL1, CHANNEL2 and CHANNEL3 to your system configuration as describedbelow. PC Mux requires 1 physical and 3 virtual or physical (when using 7 COM ports) COM ports.

Figure 4: Simcominstall Tool



• Section CHANNEL0This section contains the configuration of the physical COM port your DSB35 or TC35T isconnected to. You may modify the selected Port and the Baud rate. When using all 3 virtualchannels, we recommend you use a baud rate of 57600 bps (AT+IPR=57600<CR><LF>).

Note:Autobauding must be turned off!

Example for the physical channel:

[CHANNEL0]; type specifies the executable to startType=PORT; own server nameName=hardware; default destination [CONTROL]Destination=ctrl; serial interfacePort=COM1Baud=57600DataBits=8; parity: 0=no, 1=odd, 2=even, 3=mark, 4=spaceParity=0; stop bits: 0=1, 1=1.5, 2=2StopBits=0

• Sections CHANNEL1 to CHANNEL3These sections contain the configuration of the 3 virtual (or physical) COM ports. As above youmay modify the Port and Baud settings. A baud rate of 19200 bps is sufficient, but 57600 arerecommended. The baud rate setting has no impact on the virtual COM Ports, but is onlyrelevant when using physical ports.

Example for the first logical channel:

[CHANNEL1]; type specifies the executable to startType=PORT; own server nameName=channel1; default destination [CONTROL]Destination=ctrl; serial interfacePort=COM24Baud=57600DataBits=8; parity: 0=no, 1=odd, 2=even, 3=mark, 4=spaceParity=0; stop bits: 0=1, 1=1.5, 2=2StopBits=0



Example for the second logical channel:


Example for the third logical channel:


Note:The examples given assume that virtual COM Ports have been installed. Instead of COM24 youmay connect any other virtual channel or physical channel (when using 7 COM ports). Thesections for CHANNEL2 and CHANNEL3 need to be filled out accordingly.

Now all hardware and software components have been installed and you can work with the PC Mux.



5 Using the PC Mux as external multiplexerThe PC Mux simulates the multiplexer on a PC and can be used as an external multiplexer. However,this requires some configuration as described in the following chapters.

Note:The usage of the multiplexer is not possible, when auto bauding (AT+IPR) has been activated.

5.1 Starting the PC MuxStart the PC Mux by double clicking the file simulation.exe.

The MultiplexerSimulation window as inFigure 6 pops up on yourscreen.Click Enable Display (1)in order to trace the MPoutput on your display.

Note:Only use the displaywhen not in data mode,because it takes away toomany resources.

When clicking on Start(2), the virtual ports areinitialized (terminals canbe connected), but themodule is not yet inmultiplexer mode.

Figure 5: Starting the multiplexer simulation

Figure 6: Start panel of the PC Mux



There are two ways to startthe multiplexer:A. Follow the steps

highlighted in Figure 7:• (1) Choose Enable

Multiplexer from theCombo Box menu ofthe PC Mux window

• (2) Click on the buttonSend

• (3) If you have en-abled the display, thelast status messageshould indicate thatthe multiplexer hasbeen enabledsuccessfully

Note:In the unsuccessful case,the PC Mux does not startand after a timeout after 5sthe normal AT interface isstarted.

B. When switching on the module after a firmware update, we recommend to wait 5 seconds beforeentering AT commands. Enter AT+CMUX=0<CR><LF> in a terminal program connected to thefirst logical channel. See also Figure 8.

Approximately one second later the module is in multiplex mode.

Note:No ATC-response traffic must be ongoing on any of the three logical channels when switching off themultiplexer.

To check whether the PC Mux is operational, enter a short AT command on each of the three terminalprograms and verify whether the module sends a correct response.

The Status window shows the debug output of the MP sources. A log-file trace.txt which is created inthe same directory as the simulation.exe, contains the whole output. See Figure 9 for explanation ofthe Multiplexer Simulation buttons.

Figure 7: Starting the multiplexer in the PC Mux

Figure 8: Start of the multiplexer in a terminal program



When PC Mux is in service, it disposes of the 4 COM Ports which have been defined in simulation.iniand no other application can use them.

5.2 Stopping the PC MuxTo stop the multiplex mode, choose Disable Multiplexer from the Combo Box of the MultiplexerSimulation. Click on Send. See Figure 9.This switches the module back to Normal Mode. The RS232 interface of the module is now connectedto the first logical channel.

Note:No ATC-response traffic must be ongoing on any of the three logical channels when switching off themultiplexer.

Clicking on Stop frees the COM Ports and PC Mux can be terminated. You can use the COM Portwhich is connected to the module e.g. for starting a terminal program.It is crucial that PC Mux be terminated as described above. If you terminate the PC Mux or switch offthe PC while the multiplexer mode is still active, the module stays in the multiplexer mode. PC Mux isnot able to synchronize with a running Mux protocol, so that the module must be restarted.

Figure 9: Multiplexer Simulation status field description



5.3 Additional buttons of the PC MuxIn addition to the functions already described the PC Mux has a display and a trace possibility.

With Enable Display/Disable Display the running Mux protocol can be displayed in the status win-dow. When activating the display before starting the Mux, error messages e.g. for wrong configurationof the simulation.ini are displayed. Choose Enable/Disable Trace to output results into the filetrace.txt.

Note:The file may become quite big.

5.4 ExamplesFigure 10 shows how to start a multiplexer session. First start the multiplexer simulation by doubleclicking on the simulation.exe (1). Then start the terminal programs one after another (2-4). Make surethat the terminal programs are connected to the correct logical COM Ports. Now enter AT+IPR to setthe baud rate.

Afterwards start the multiplexer with AT+CMUX=0 as shown in Figure 11.

Figure 10: Starting a multiplexer session



Figure 11: Multiplexer activation on Hyperterminal

With AT+CMUX=0 the multiplexer has been activated. Now all terminals can be used. Figure 12 showsthat all terminals are ready to process AT commands.



Figure 12: Three active logical channels

The Source Code for the Status messages of the PC Mux is available so that the message flow can beinterpreted.



6 Internal work flow of the PC Mux

port.exe

channel1

port.exe

channel3

port.exe

channel2

port.exe

hardware

muxtester.exe

mux2hw

muxtester.exe

hw2mux

controller.exe

ctrl

chopper.exe

mux

muxappl.exe

muxdll

COMm

COMn

COMp

COMq

port.exe

channel1

port.exe

channel3

port.exe

channel2

port.exe

hardware

muxtester.exe

mux2hw

muxtester.exe

hw2mux

controller.exe

ctrl

chopper.exe

mux

muxappl.exe

muxdll

COMm

COMn

COMp

COMq

GSMdevice

GSMdevice

verifymultiplexerframes

pcmux.dll

pcmux.dll

choplargedatablocksinto alot ofsmallones

The block diagram above illustrates the interrelationship between the different modules of the PCadaptation of the multiplexer and presents the two operating states of the PC multiplexer.The upper schematic shows the multiplexer with disabled multiplexer protocol as normal COM inter-face. The dark shaded modules and connections are active, white modules and grayed connectionsare disabled. The red link between the module's port interface (port.exe on the right side) and thecontroller shows the only connection which changes when the multiplexer is enabled.

The lower schematic shows the multiplexer adaptation in enabled state. All modules and connections

Figure 13: Integration of the multiplexer



are active. The data flow from the module's port now runs through the multiplexer (muxappl.exe andpcmux.dll), i.e. it does not go directly through the controller to the first PC port as in the disabled mode(again the red connection).

The names of the applications associated with each module are presented in the middle of each block.The names of the server pipes are shown in the small block on top of each module. Please refer tochapter 6.3 for a further description of what exactly is a server pipe. The required hardware, i.e. theCOM ports and GSM device are shown as a smaller block on both sides of the diagram.The following subchapter 6.1 describes the role of the different modules related to the PC multiplexerfunctionality. Chapter 6.2 describes the modules and required files which are part of the PC implemen-tation but not directly involved in the base functionality.

6.1 Multiplexer Related ModulesThe external multiplexer can be realized in two ways. You can either use the provided binaries of thePC Mux or implement the multiplexer protocol in your own application to use the functionality of themultiplexer mode. The following files can be provided:

ddmpadp.cddmpdlch.hddmpfra.cddmpfrah.hddmpfunc.cddmpio.cddmpmem.cddmpstat.cddmptype.cddmpadph.hddmpglob.hddmpmsgh.hxamuxh.h

6.1.1 Muxappl.exe with Pcmux.dll

This block is the heart of the multiplexer implementation which does all the multiplexing and demulti-plexing. The reason for implementing it in a separate DLL and an application is that the best approachis to use the same source code of the multiplexer in the module software and on the PC side. For thisreason, this code is separated in a Windows DLL. In fact, there are some platform specific compilerswitches but the sources are the same.Because the multiplexer sources use the interface of the module's operating system an encapsulatingapplication is necessary on the PC side which maps this interface to a Win32 compatible interface.This mapping of the called functions and the used messages is the only reason for using themuxappl.exe application. The following list describes the functions the multiplexer calls from theoperating system and which therefore must be implemented in muxappl.exe:

void MP_PostUserMessage(MP_PRIMITIVE *psPrimitive)This function is used by the multiplexer to post a message to any receiver via the operating system. Inthis function you find all messages the multiplexer uses and how they are mapped into the messageformat used inside the PC framework.

UINT8 MP_ucGetMessage(struct MP_PRIMITIVE_tag *pstMpPrimitive, UINT8 ucMsgSize)This function is called by the multiplexer when it has finished processing a message to get the nextmessage out of the message queue. The internal message queue contains the messages already inthe multiplexer format. The mapping from the PC adaptation format is done in the main message loopMessageLoop().



void MP_Dummy_WriteCOM(unsigned int cnt, const char far *msg)This function is called by the multiplexer when it has finished framing one data package received fromone of the logical channels ports and wants to send it out through the multiplexer port.

void MP_Test_Scanner(UINT8 ucDLCI, UINT8 *pBuffer, UINT16 length)This function is called by the multiplexer when it has finished unframing one data package receivedfrom the multiplex port and wants to forward it to the corresponding logical channel.

void MP_ReceiveFrame(unsigned char *bBuffer, UINT16 wLength)This function is called from the subsystem (usually UART receive part) when multiplexed data receivedand has to be demultiplexed and transported to the decoded DLCI (the corresponding logical channel).This is the entry into the multiplex protocol from the multiplexed UART.

void MP_TransmitData (unsigned char tsap, UINT16 length, const char far *pBuffer, enSerialwhichUart, MP_eDLCI ucDLCI)This function is called, when unframed data on a logical channel will transported using the multiplexer.Data are encoded for the selected DLCI (the corresponding logical channel) and sent through themultiplexer to the module. This is the normally used function to transmit data to the module when themultiplexer is used.

static void print (const char * s)

static void dump (PBYTE pBuffer, WORD wLength)These two functions are used inside the multiplexer to do some debug output. Both functions aremapped to the trace mechanism of the PC adaptation.

6.1.2 Port.exe

The port.exe application encloses the hardware COM ports from the used pipe system for internal datatransfer. They map data received on the connected COM port and transfer them via the connectedpipe into the multiplexer system. In opposite direction they send data received on the pipe out to theCOM port.

6.1.3 Controller.exe

As the name suggests, the controller.exe controls the complete PC multiplexer system. This isprimarily enabling and disabling the multiplexer, i.e. enabling and disabling the associated modules andpipes. To perform this task the controller scans the complete data passed via the control channel forAT commands that enable the multiplexer or switch the baud rate, and for the associated responses.The control channel is always only channel 1.

UARTmux’ed

Multiplexer

� Mux�ed

Demux�ed�MP_ReceiveFrame

MP_Dummy_WriteCOM

MP_Test_Scanner

MP_TransmitData Logical channelsdemux’edDLCI1 = Data,

AT-Cmd

DLCI2 = AT-CmdDLCI3 = AT-Cmd



6.1.4 Chopper.exe

Due to the limited memory of the module's hardware the multiplexer implementation can handle onlysmaller data packages (the frames for the different ports). For this reason the chopper.exe chops largeincoming frames into blocks of maximum 100 bytes. This maximal frame size can be configured in thesimulation.ini file (refer to chapter 6.2.1)

6.1.5 Muxtester.exe

The muxtester.exe is an application only for debug and test reasons. It simply analyzes receivedframes, traces them for frame errors and writes error information to an error file. Currently it isconnected to the muxappl.exe to examine the frames sent to the module and to the modules port.exeto analyze the frames sent out of the module into the PC multiplexer system.

6.2 Additional Modules and Files

6.2.1 Simulation.exe and Simulation.ini

Simulation.exe provides the user interface for the PC multiplexer adaptation. The PC multiplexer withall modules belonging to the system can be started clicking the Start button. All settings, such as portconfiguration and pipe names etc. are stored in the simulation.ini file. Of course the complete multi-plexer configuration can also be stopped. All modules are closed, ports are freed etc. In addition to thestart-up, initialization or stopping procedures of the whole multiplexer system, the application simula-tion.exe provides the functionality to switch the multiplexer on or off. A Trace window can be openedand closed by pressing the appropriate buttons.

6.2.2 Log.exe

This is a console application which allows to decode and display the internal messages. The messagesdecoded and displayed have to be explicitly sent to an instance of log.exe for display. Log.exe is adevelopment and debug tool which isn�t used in the running multiplexer system. It simply provides thefunctionality to connect log.exe e.g. instead of or in addition to an instance of port.exe to thecontroller.exe to have all incoming messages displayed.

6.2.3 Send.exe

This is a command line tool which serves to send any internal messages to any possible pipe. It is notused directly inside the running PC multiplexer system. Nevertheless it is very useful for development.It is used to send the message �disable multiplexer�.

6.2.4 Process.exe

This is also a command line tool created for development reasons and has nothing to do with themultiplexer functionality. It is nothing but a simple task manager used to list all running processes andprovides the functionality to kill all running processes with the same name by one command (e.g. kill allrunning instances of port.exe with one call). After pressing the Stop button within the applicationsimulation.exe all multiplexer related applications will be stopped by sending a �termination� message.Sometimes the processes do not stop; then it is necessary to kill them via process.exe.



6.2.5 Trace.exe

Because the PC multiplexer implementation is based on several connected but separated applicationsthe trace information for the debug traces must be collected out of several trace files created by thevarious modules. Trace.exe does this collecting by opening several trace files, searching cyclically fornew information, sorting the found trace information and writing it altogether to a file which thencontains the trace output of the whole system as a formatted text.

6.3 The Internal Pipe SystemIn order to pass data between the different applications of the PC multiplexer application, the Windowspipe mechanism is used. This mechanism only exists in Windows NT and Windows 2000. For thisreason the multiplexer doesn�t work in Windows 9x.The Windows pipe mechanism allows to easily pass data between different applications independentlyon which systems they are running (on the same system or on different systems via LAN or even viaWAN). Please refer to the MSDN for a very detailed description of this technology.The pipe mechanism is encapsulated in different C++ classes in the PC multiplexer implementation.These classes are CMsgServWrap and CMsgClient. The idea behind the used expressions�MsgServer� and �MsgClient� is that the server creates and controls a pipe to which clients can connectand send data to the server. This means that an instance of CMsgServWrap can only receive datafrom clients connected to its pipe. Instances of CMsgClient have to connect to the existing server � ormore exactly to their pipes � and can only send data out to this server. Accordingly, each applicationwhich has to transmit data in both directions needs to have at least one instance of CMsgServWrapand CMsgClient. The class CMessage implements an internal message system which is used for alldata transmissions. This message system is completely based on the pipe mechanism and has noconnection to the Windows message system. The different pipes are identified by their names shownin Figure 13 on top of each module.



7 Integrating the multiplexer into the customer applicationIf you want to make your own design of the multiplexer, you may use the delivered sources. You get a*.zip file, which includes files you can use to include the multiplexer in your application. Naturally youmay instead make your own implementation of the multiplexer.

Provided files:When you extract the *.zip file *.c and *.h files will be installed on your PC. You need to link andcompile these files together with your application software. Refer to chapter 6.1 for detailed informationabout the purpose of each file.

7.1 Tips and Tricks

7.1.1 Terminal Flow Control

The Multiplexer Simulation provides RTS/CTS hardware flow control. If a terminal application usestoggle flow control (this includes Start/Stop of the Application), the Multiplexer Simulation informs themodule about this. This way an unintended blocking may occur:

Example:An application may set RTS when being started and resets RTS when being closed (e.g. Hyper-Terminal uses RTS this way, regardless of the flow control settings). The Multiplexer Simulation de-tects the toggling of RTS and informs the module. If another applications is started on this serial port,which does not set RTS (e.g. ZOC uses RTS this way, if RTS/CTS-handshake is not activated by de-fault), it cannot send/receive data from then Multiplexer Simulation until it toggles the RTS-line to High.

The following procedure is recommended to change from flow control to none flow control follow thesteps listed below:1. Flow control is switched on2. Disable Multiplexer (Choose Disable Multiplexer and push button Send)3. Switch off flow control within the terminal4. Start Multiplexer again (e.g. AT+CMUX=0)

This procedure is absolutely necessary, otherwise a restart of the whole environment (GSM engine andMultiplexer simulation) is required.

7.1.2 Timeout after starting the multiplexer

Bear in mind that a 5 second timeout should be kept after starting the multiplexer. No AT commandsshould be entered. If the multiplexer does not start correctly, the normal AT interface will be freed againafter the timeout.

7.2 Restrictions• After starting the MUX-Protocol 3 logical channels are available. Beware of the following restric-

tions:• The TC3x supports the basic option and UIH Framing according to GSM 07.10.• MO and MT Data calls can only be set up on channel 1• It is not possible to set up a data and a voice call on channel 1 at the same time.• Unsolicited Result Codes will generally be transmitted to all logical channels (like �RING�).• In charge-only and in alarm mode the multiplexer is not available• See [2] for multiplexer characteristics with the commands AT&V, AT+CNMI, +CALA and +CMEE



• A call can be answered or ended on every channel. See AT commands like ATD, ATA, ATH.• The PC Mux environment can only be started once on a PC.• XON/XOFF are not allowed in the multiplex mode (AT\Q2).• When switching on the module after a firmware update we recommend to wait 5 seconds before

entering the first AT command.• Fax calls are not supported when using the multiplexer.The following table lists commands and features for which dependencies between the differentinstances on the 3 channels may exist.

Example:A data call is ongoing on channel 1. When answering an incoming voice call on channel 2 or 3 andterminating it, the data call will be ended as well.

So the table is intended to remind the customer to be aware of possible dependencies when using thelisted commands/features on different channels. One way of avoiding the problems may be to dedicatecertain commands/features to certain channels or to assure, that the application avoids conflicts.

Access types valid for all channels

Call ControlPhonebook accessSIM Card accessRF settingsTime settingsATZ, AT&F, AT&V, AT&W, AT+CEER, AT+CLCKNetwork settingsPower saveDevice locksSMS read, write and deleteBaud rate settings

Access types for Channel 2 and 3 not disturbing other instances

URCsRING voice callsRead device informationSignal quality and monitoring

Table 4 gives an overview about events which may be ongoing on different channels independently.

7.3 Multiplexer control and signaling linesFor performance reasons the channels which are provided by MP have been realized as pure datachannels, not as virtual V.24-Channels with signaling and control lines. For this reason efforts areneeded on the application side to emulate the missing information.Possibilities how to develop a virtual driver are shown in the following chapters. Differences andrestrictions in comparison to the unframed module are pointed out.

Table 3: Commands with possible channel dependencies

Table 4: Commands/Features without channel dependencies



7.3.1 Flow Control

RTS/CTS on the physical channel:It is recommended to use AT\Q3 when the multiplexer is switched on.The customer application de- and encodes the data. It needs to respect the flow control given by theMP. The flow control is transmitted in the data flow and contains information on whether a channel isallowed to send or not.The customer application must set RTS (in the direction of the module) on 1. It shall neither be usednor switched off to prevent from loss of data (control data cannot send in that case).

RTS/CTS on the logical channels:The customer application needs to regulate the data flow according to the logical flow control. Theimplementation of the PC Mux is a good example. It maps the 3 decoded channels to 3 serial inter-faces and the logical flow control information directly on the RTS/CTS-control lines.In this case CTS superposes the STOP information (data sending disabled) sent by the module tocontrol the data transmission from the customer application to the module. If RTS is reset, a STOP istransmitted to the module to control the data transmission from the module to the customer application.Figure 14 illustrates the data flow.

MSModule (TC35)

TEKundenapplikation(PC-Mux, Mux-Treiber)

MultiplexerProtocol

GSM 07.10

MultiplexerProtocol

GSM 07.10

serIO

serIO

COMX

COMY

COMZ

gipsy

RemoteControl

RTS/DTR

RTS/DTR

Kanäle 2,3:RTS

(/DTR)

Kanal 1:RTS/DTR

Controller(mappt RTS/DTR derungeframten Kanäle

auf log. FC)

RTS/DTR

logical flow control

HW Flow control

Flow control between the applications

DTR/DSR:When the MP is active only coded Channel 1 transmits DTR non-transparently. When DTR is used asa signal (for example to hang up a call with AT&D2), please keep in mind that the multiplexer cannottransport this signal in real time. Please use a certain gap time between signaling with DTR/RTS.

Ring/DCD:Contrarily to all other lines DCD and Ring are still transmitted on the UART directly by the module.However, the customer application must carefully decide how to handle the RING line and it shouldmake sure, that no conflicts occur between the different channels. E.g. in some situations it may beadvisable to only display RING on channel 1.

Figure 14: Flow control � RTS/CTS signaling



Note 1:It must be taken into account, that a call can only be accepted once. So some kind of mutual lockingmechanism must be realized.

Note 2:See also chapter 7.1.1 for terminal flow control problem.

7.3.2 Escape Sequence

When the MP is active only coded data is transmitted over the UART. The coding includes a headerand a checksum, so that an Escape sequence coding (+++) of the already coded data flow does notmake sense.

The following ways of transmitting an ESC signal have been implemented:

• DTR is transported within the logical channel. To hang up a call, the normal way of using DTR isavailable. Please keep in mind that the multiplexer cannot transport this signal in real time. Pleaseuse a certain gap time between signaling with DTR.

• It is possible to detect the �+++� on the customer multiplex application (for example see PC-MUX)and transport this information via the MSC signal to the module (see chapter 8.3.6.3).

As an alternative, ATH may be sent on one of the other channels.

7.4 Power SavingTwo variants exist in the power save mode with AT+CFUN:

• AT+CFUN = 0: The multiplexer is still enabled• AT+CFUN = 0,1: The module is reset, the multiplexer is disabled.

For the first variant:• The multiplexer is not disabled. The module goes to power save mode and can be woken up by an

incoming call or with RTS (see also [2], AT+CFUN). When waking up, the multiplexer is automati-cally available.

For the second variant:• The module also disables the counterpart of the multiplexer via the protocol. The multiplexer must

be restarted and settings for channel 2 and 3, which have not been stored are lost. The modulegoes to power save mode and can be woken up by an incoming call or with RTS (see also [2],AT+CFUN).

Settings on channel 2 and 3 which have not been saved are lost.

7.5 Flash Management Multiple access on the flash is no problem. The latest access is always the valid one. E.g. when writinga parameter set into the flash via channel 1, afterwards via channel 2, the second is the valid one.



Address1 Octet

Control1 Octet

Flag1 Octet

0xF9

DLCI

DLCI: Data Link Connection IdentifierC/R: Command / ResponseEA: extension bit; EA = 1

Frame type:SABM Set Asynchronous Balanced ModeUA Unnumbered AcknowledgementDM Disconnected ModeDISC DisconnectUIH Unnumbered Information with Header checkUI Unnumbered InformationP/F-Bit Poll- /Final - Bit

Length1 or 2 Octets

Informationn Octets

FCS1 Octet

Flag1 Octet

0xF9

Checksum for address,control and lengthfields, also for theinformation field in thecase of UI frames FCS.

LengthEA

Length: Length InformationEA: extension bit;

EA = 1 -> 1 octet length informationEA = 0 -> >2 octets length information

EA C/R

8 Structure of the multiplexer protocol

8.1 Introduction of the multiplexer protocolThe multiplexer protocol conforms with the multiplexer protocol GSM 07.10. The non-error recoverymode was implemented with the basic option.

The frames have a start and a stop byte. A checksum is calculated to protect the transferred data.Frame repetition is not enabled.

Data calls are transferred in the logical channel DLCI = 1 (DLCI: Data Link Connection Identifier). Theremaining DLCIs are in AT command mode.The multiplexer protocol must be started and the logical channels opened in compliance with specifiedprocedures.

The chapter also gives you suggestions for the following aspects:

Opening logical channels without parameter negotiationOpening logical channels with parameter negotiationClosing of logical channels

8.2 Data link layerThe followingsubchapters show thedetailed structure of a datalink frame.

Figure 15: Data link layer



8.2.1 Flag sequence

Each frame begins and ends with a flag sequence. The flag sequence contains a bit sequence:11111001 (hexadecimal: 0xF9).Only one flag sequence occurs between any two frames. If two successive flag sequences do occur,the frame is regarded as being empty and is discarded.

The flag sequence is used for the synchronization of frames.

8.2.2 Address field

DLCI

DLCI: Data Link Connection IdentifierC/R: Command / ResponseEA: extension bit; EA = 1

EA C/R

The values for the Data Link Connection Identifier (DLCI) are dynamically defined apart from DLCI = 0.

DLCI number (decimal) Priority

Multiplexer control channel(see Section 8.3.6)

0 0

highest priority

AT commands, data (gipsy) 1 7

AT commands 2,3 7

The command/response bit identifies the frame as a command or response. A command contains theaddress of the data link connection to which the command is sent. A response contains the address ofthe data link connection sending the frame.

Command/Response Direction C/R

Customer µC → TC3X 1Command

(SABM, DISC) TC3X → Customer µC 0

Customer µC → TC3X 0Response

(UA, DM) TC3X → Customer µC 1

Every command expects a response. No provision is made to repeat the command if no response isreceived

Table 5: Address field

Table 6: Assignment of the DLCI

Table 7: Use of the command/response bit



8.2.3 Control field

The control field defines the frame type.

Frame Type 1 2 3 4 5 6 7 8SABM(Set AsynchronousBalanced Mode)

1 1 1 1 P/F 1 0 0

UA(UnnumberedAcknowledgement)

1 1 0 0 P/F 1 1 0

DM(Disconnected Mode)

1 1 1 1 P/F 0 0 0

DISC(Disconnect)

1 1 0 0 P/F 0 1 0

UIH(UnnumberedInformation with Headercheck)

1 1 1 1 P/F 1 1 1

P/F: Poll/Final bitCommands: P = 1, Responses: F = 1For each DLCI, only one frame with P = 1 may ever be expected.

8.2.4 Length indicator

The Length Indicator specifies the length of the following information field.The length of the Length Indicator can be extended with the E/A bit. The default length is 31 bytes.

1st octet:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8E/A L1 L2 L3 L4 L5 L6 L7

2nd octet:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8L8 L9 L10 L11 L12 L13 L14 L15

E/A = 1: only one octet for the Length IndicatorE/A = 0: two octets for the Length Indicator

8.2.5 Information field

The Information Field contains the data and has an octet structure. The field only exists for UIH frames(Unnumbered Information with Header check).To transfer information fields, the P/F bit is set to 0; a response is not necessarily expected.

8.2.6 Frame checking sequence field (FCS)

The Frame Checking Sequence (FCS) is computed with the address, control and length fields.For further information and the specification of the frame checking sequence refer to /2/:

Table 8: Coding of the control field



8.3 State DiagramsThe multiplexer protocol is based on two state machines (see Figure 16). One state machine initiatesthe setup of the logical channels, while the other responds to the requests.The TC3x can only respond to requests. A higher level for controlling the state machines is notimplemented.The procedure for setting up the two state machines � the one for the customer µC and the one for theTC3x � is shown in Figure 17 and Figure 18.The AT command "AT+CMUX=0" starts the switchover from AT command mode to the multiplexerprotocol and parameterizes the muliplexer control channel DLCI = 0. Both state machines are then inthe DISCONNECTED state and immediately have the option of setting up the multiplexer controlchannel DLCI = 0 and other logical channels.The logical channels are then set up (DLC establishment). If the DLC establishment is successful thestate machine for that particular channel changes to CONNECTED. If the request is unsuccessful thelogical channel cannot be established and the state machine remains in DISCONNECTED for thatparticular channel.Information can be transferred over all channels in CONNECTED. Control commands can betransferred in the multiplexer control channel DLCI = 0; the other channels transfer data.The parameters for all logical channels DLCI = 1...4 in DISCONNECTED can be set for the requestedlogical channels by parameter negotiation.Disconnecting individual channels (DLC release) causes the state machine for those channels to revertto DISCONNECTED. Release of the multiplexer control channel DLCI = 0 corresponds to a CLOSEDOWN. The CLOSE DOWN command switches back

TC3x

Mul

tiple

xer U

ser's

Gui

de

TC3x

_UG

_01_

V03.

10 -

Rel

ease

dPa

ge 3

5/50

10.0

1.20

02

Figu

re 1

6: R

elat

ions

hip

betw

een

the

cust

omer

µC

and

TC

3X µ

C

DIS

-C

ON

NE

CTE

D

DIS

-C

ON

NE

CTE

D-

NE

GO

TIA

TIO

N

CO

NN

EC

TED

CLO

SE

D-

DO

WN

Sta

rt U

p

DLC

Est

ablis

hmen

t

Clo

se D

own

Clo

se D

own

Clo

se D

own

DLC

para

met

erne

gotia

tion

DLC

Rel

ease In

form

atio

nTr

ansf

er

DIS

-C

ON

NE

CTE

D

DIS

-C

ON

NE

CTE

D-

NE

GO

TIA

TIO

N

CO

NN

EC

TED

CLO

SE

D-

DO

WN

Sta

rt U

p

DLC

Est

ablis

hmen

t

Clo

se D

own

Clo

se D

own

Clo

se D

own

DLC

para

met

erne

gotia

tion

DLC

Rel

ease In

form

atio

nTr

ansf

er

Cus

tom

er µ

CM

aste

r st

ate

mac

hine

TC3x

µC

Sla

ve s

tate

mac

hine



CustomerµC TC3x µC

Closed Down Closed Down

RequestStartUp

ResponseStartUpConfirmStartUp

IndicationStartUp

DisconnectedDisconnected

Serialinterface

Star

t Up

"AT+

CM

UX"

Connected

RequestSABMIndicationSABM

ResponseDMConfirmDM

DLC

Est

ablis

hmen

t,D

LC c

reat

ed


RequestSABMIndicationSABM

ResponseUAConfirmUA

DLC

Est

ablis

hmen

t,D

LC n

ot c

reat

ed

ConnectedConnected

ConnectedConnected

RequestUIHIndicationUIH

IndicationUIHRequestUIH

Connected

Info

rmat

ion

Tran

sfer

Figure 17: MPl: Startup, DLC Establishment, Information Transfer



Customer µC TC3x µC


Serial interface

DLC

Rel

ease

Connected Connected

RequestDISCIndicationDISC

ResponseUAConfirmUA

RequestCloseDownIndicationCloseDown

ResponseCloseDownConfirmCloseDown C

lose

Dow

nClosed Down

Disconnected/DisconnectedNegotiation/Connected

Closed Down

Disconnected/DisconnectedNegotiation/Connected

8.3.1 Startup

The multiplexer protocol is activated with the AT command "AT+CMUX=0". This enables themultiplexer control channel.The multiplexer control channel must be set up next � see DLC establishment section 8.3.2.

Figure 18: MP: DLC Release, Close Down



8.3.2 DLC Establishment

The multiplexer control channel must be set up as the first channel followed by all other DLCIs. To doso, a SABM frame (see Section 8.2.3) must be sent to the TC3x. The TC3x responds with either a UAframe � i.e., the DLCI was set up, or with a DM frame if the DLCI was not set up.No provision is made for repeating the request if a response is not received.The state machine requesting the multiplexer control channel DLCI = 0 is the "initiating station", whilethe other is called the "responding station".

CustomerµC TC3x

SABM: P = 1Address Field = DLCI of channel to be established

UA: F = 1, DLCI is being establishedDM: F = 1, not ready, DLCI is not establishedAddress Field = DLCI of requested channel

8.3.3 Information transfer

A response is not essential for every command � for example, unsolicited code does not require aresponse.

CustomerµC

(Initiator)

MC35(Responder)

UIH: P = 0, C/R = 1

UIH: P = 0, C/R = 0

8.3.4 DLC release

CustomerµC TC3x

DISC: P = 1

UA: F = 1DM: F = 1 responding station is

already disconnected

No provision is made to repeat the request if no response is received.

Figure 19: DLC Establishment

Figure 20: Information transfer

Figure 21: DLC release



8.3.5 Closedown

After the close down procedure both stations return to operation in the AT command mode.

The following options exists for the close down procedure:

- Disconnect all DLCIs (DLCI Command); the last disconnection is for DLCI = 0- Multiplexer close down command (CLD). The multiplexer controls the closedown: all DLCIs are

first closed, finally DLCI = 0

8.3.6 Multiplexer control channel

DLCI = 0

The commands are sent as information in the Multiplexer control channel frame.

Type field:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8EA C/R T1 T2 T3 T4 T5 T6

EA bit: Extension bit.In the last octet of the sequence the EA bit = 1, otherwise = 0.If there is only on octet, EA bit = 1 is set.

C/R bit: Indicates whether the sequence is a command or a response.

T-bits: Coding of the command type.

Length field:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8EA L1 L2 L3 L4 L5 L6 L7

EA bit: Extension bit.In the last octet of the sequence the EA bit = 1, otherwise = 0.If there is only one octet, EA bit = 1 is set.

L-bits: Number of value octets; the following L1 is the LSB, L7 the MSB.

Multiple commands can be sent in a frame. Commands are not permitted to be distributed over morethan one frame.

8.3.6.1 Multiplexer close down (CLD)Type field:

Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 81 C/R 0 0 0 0 1 1

Length byte = 0, no value octet

Figure 22: Multiplexer control channel

Type1 Octet

Lengthn Octets

Value 11 Octet

Value 21 Octet ..... Value n

1 Octet

Information Field



8.3.6.2 Test command (Test)The test command is intended to test the connection between MS and TE.

Type field:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 81 C/R 0 0 0 1 0 0

The length byte indicates the number of test bytes sent in the value bytes. The responding stationshould respond with precisely the same bit sequence. The test command is used for the version con-trol. See also chapter 9 for detailed information.

8.3.6.3 Modem status command (MSC)The Modem Status Command is used for software flow control.

Command1 octet

Length1 octet

DLCI1 octet

V.24 signals1 octet

Command:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 81 C/R 0 0 0 1 1 1

C/R bit: Indicates whether the sequence is a command or a response.

Length: Length = 2 , EA-Bit = 1

DLCI:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 81 1 DLCI

V.24 signals:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 81 FC RTC not

supported

reserved 0

reserved 0

notsupported

notsupported

FC bit: Flow controlFC = 1: no frames are accepted

RTC: mapped to DTRRTR: mapped to RTS

Note:RTC/RTR are valid in the direction host � module only!RTC/RTR are NOT valid in the direction module � host!

Break signal (optional):

Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 81 Not supported

The break signal octet normally carries information about a break condition detected from the host inthe data stream for the DLC.

Figure 23: Modem status command (MSC)



Note:This command supports no parameters. Instead we use this optional parameter to transport an escapesequence detection from the host to the module. If the hosts detects an escape sequence (usually+++), it sends this optional octet with bit 1 set to 1. The module calls its original escape sequence.

8.3.6.4 Non-supported command response (NSC)This response is sent whenever a command type is not supported by the receiving entity.

Type field:Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 81 C/R 0 0 1 0 0 0

C/R bit: Indicates whether the sequence is a command or a response.Value octet:

Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8EA C/R Command type of the non-supported command

C/R bit: Returns the same value as in the received, non-supported command

Frames not recognized by the receiving entity are responded by a NSC-frame.

8.4 Samples of establishing logical channels

8.4.1 Establishing logical channels without parameter negotiation

Send "AT+CMUX=0"; wait for the responseSend Request SABM for DLCI = 0; wait for the responseSend Request SABM for all requested DLCIs; wait for the response

� ready for Information Transfer



CustomerµC TC3x µC

Closed Down Closed Down

RequestStartUp

ResponseStartUpConfirmStartUp

IndicationStartUp


Serialinterface

Star

t Up

"AT+

CM

UX"

ConnectedDLCI = 0

DLC

Est

ablis

hmen

t,C

reat

e D

LCI =

0

DisconnectedDLCI = 0

DisconnectedDLCI = 0

RequestSABMDLCI = 0 IndicationSABM

DLCI = 0

ResponseUADLCI = 0ConfirmUA

DLCI = 0

ConnectedDLCI = 0

ConnectedDLCI = 1

DLC

Est

ablis

hmen

t,C

reat

e D

LCI =

1Disconnected

DLCI = 1Disconnected

DLCI = 1

RequestSABMDLCI = 1 IndicationSABM

DLCI = 1

ResponseUADLCI = 1ConfirmUA

DLCI = 1

ConnectedDLCI = 1

8.4.2 Closing the multiplexer protocol and returning to AT mode

Send Request CLOSE DOWN as a command of the Multiplexer Control Channel

� The interface is returned to the AT command mode

Figure 24: Multiplexer control channel and logical channel, no parameter negotiation



9 Version Control

9.1 IntroductionThe version control for the multiplexer protocol ensures, that TE and the MS side support the samestate of functionality. It ensures upward and downward compatibility of the TC35 and MC35 after theenhancements.A new version is introduced when the scope of the multiplexer functionality changes. Theimplementation is a subset of the GSM 07.10 standards. New versions are introduced when newfeatures are implemented. In these cases the version number is increased.

When using the multiplexer protocol sources delivered by Siemens AG, the version check is includedimplicitly. When you implement the multiplexer protocol yourself, you need to implement the versioncheck as well, if you want to use features which are included in later versions. When the multiplexer isstarted, the MS and the application negotiate which MP version to use.

For each version of the multiplex protocol release notes are published, which:• demonstrate the exact protocol for the version check• mention the different release versions• document the changes in the protocol/feature set, which have led to the new release version

9.2 Multiplexer versionsThe following multiplexer protocol versions exist:

1. No version checkState: multiplexer up to TC35 Release 3.00

2. First version including the version checkState: multiplexer included in TC35 Release 3.10 and higher

3. Additional Features: transparent signals DTR and RTS, escape sequence +++

Figure 25: Possible combinations for version check

TE MS

without version check

with version checkold version

with version checknew version

without version check

with version checkold version

with version checknew version

1

2

3

4

6

5

7

Multiplexer ProtocolVersion:

1

2

3

risingversion num

ber



The TE and MS multiplexer version numbers can be traced on the serial interface.They appear as follows:

• TE version (e.g. version 1): TEMUXVERSION0001• MS version (e.g. version 2): MSMUXVERSION0002

During the version check process the valid multiplexer version is negotiated. TE and MS agree on thelower version of the two.

Examples:1, 2:These cases (bright green arrows) describe the straight case. TE and MS have the same multiplexerversion.

3:TE does no version check, MS does version check. On MS side the protocol is automatically switchedback to the older state.

This constellation is never a problem, because the TE side has been realized with the known features.Thus it expects no features, which will only be added in the next protocol version.

Example: TE Version 1, MS Version 2 � multiplexer version 1 is valid

4:The TE side has the version check included, the MS side does not. The TE has to use the protocolaccording to the old version. This can be done in the following ways:PC

(MUX driver or PC Mux): DLLs for all versions are available and have to be chosen according tothe negotiated version.

• Customer application with Siemens AG sources: Switch back to the older protocol version on TE side. This is done automatically when using theSiemens AG sources. This case should not happen, since the customer application is put intoservice with the features which are being offered by Siemens AG at that point of time. Newprotocol features can only be contacted by the application when they have been implemented onthe MS side.

• Customer application with proprietary multiplexer implementation: See Customer application with Siemens AG sources.

Example: TE Version 2, MS Version 1 � multiplexer version 1 is valid

9.3 ImplementationThe TE initiates the version check by sending the test command message on DLCI 0(with TEMUX_Version).

As specified in the GSM recommendation 07.10 (chapter 5.4.6.3.4) the opposite entity shall respondwith exactly the same value bytes.

The Test Command response (with TEMUX_Version) shall be sent from the MS with the samecontents for the verification pattern.In the next step the MS shall send a Test Command message (with MSMUX_Version) and the TE shallrespond with the same contents. After sending the response a comparison will be performed.The version check of the multiplexer is used to ensure the compatibility between TE- and MS-side. Viathis implementation it is possible to manage the different multiplexer versions.After exchanging of version information a version compare is made on both sides. On both sides the



same version shall be used. If there is a mismatch between the entities the earlier internal version isused.From multiplexer version 2 onwards, the version check is automatically executed during the start upprocedure (at+cmux=0). Version 2 is the first version with multiplexer version check.The version check procedure is triggered by the TE side by sending the Test Request Message withthe multiplexer version number. The MS side has to confirm the Test Message by looping it back to theTE side. After that the MS Version shall be sent to the TE with a Test Request Message, which shallbe looped back as well.If the multiplexer is activated no version check shall take place again (it is not permitted to execute theversion check during runtime). However, if the version check needs to be executed again, the multi-plexer has to be deactivated and activated again.

Case TE MS

(01) OLDMUXSW_no_VC OLDMUXSW_no_VC

or OLDMUXSW_VC

or NEWMUXSW_VC

(02) OLDMUXSW_VC

or NEWMUXSW_VC

OLDMUXSW_no_VC

(03) OLDMUXSW_VC

or NEWMUXSW_VC

OLDMUXSW_VC

or NEWMUXSW_VC

(04) OLDMUXSW_VC

or NEWMUXSW_VC

NEWMUXSW_VC

or OLDMUXSW_VC

OLDMUXSW_no_VC => old software version with no version checkOLDMUXSW_VC => is not the newest software version with version checkNEWMUXSW_VC => is the actual software version of the GSM Multiplexer with

version checkMS => mobile station or target moduleTE => terminal, e.g. a personal computer is used to send any data

9.4 Case Descriptions

9.4.1 Description case (01)

As described in the definition part the TE is the master for checking the software version.No version check takes place because it is not implemented on TE side (regardless whether there is asoftware version with or without version check on the MS side).In this case it is not possible to control the activation of the multiplexer dependent on the softwareversion.

Table 9: Version cases



TE MS

enable DLC (DLCI=0)- AT+CMUX=0

enable DLC (DLCI=1)

enable DLC (DLCI=2)

enable DLC (DLCI=3)

No version check takes place !

<Message flow case (01)>

9.4.2 Description Case (02)

For Case (02) only on TE side software with version check is installed. The Test Command Message issent back from the MS side but no Test Message with the MS multiplexer version is triggered. Thelowest multiplexer software version shall be used on TE side.The MS can not inform the TE which software is installed.



<Message Flow Case (02)>


In this case the software version number on both sides is equal. It is possible to use the multiplexerfunctionality without software version mismatches. The version check is passed and the internal isequal to the used version.<Message Flow Case (03)>

TE MS

enable DLC (DLCI=0..3)- AT+CMUX=0

UIH TestCommand(P=0, C/R=1, TEMUX_Version)

UIH TestCommand_Resp(P=0, C/R=0, TEMUX_Version)

<no Test Command with MS multiplexer version is triggered >

- The lowest multiplexer version is used on TE side

TE MS


UIH TestCommand(P=0, C/R=1, TEMUX_VersionX)

UIH TestCommand_Resp(P=0, C/R=0, TEMUX_VersionX)

- Comparison: MSMUX_VersionX == TEMUX_VersionX

UIH TestCommand(P=0, C/R=1, MSMUX_VersionX)

UIH TestCommand_Resp(P=0, C/R=0, MSMUX_VersionX)

- Version check




There is a version conflict � the lowest internal version is used.

<Message Flow Case (04)>

9.4.5 Abnormal Cases

The SW implementation from the MS point of view is known, but on the TE side the following abnormalcases are possible:

• ´Request Test Message´ is not sent from TE side:

No Version check takes place. No retransmission for ´Request Test Message´ is triggered. Themultiplexer is started with the lower version.

• ´Response Test Message´ is not sent from TE side:

No timer has been implemented for the non responding cases. If the response message is notreceived as expected, the multiplexer stays in the state DLC_CONNECTEDWAIT4RESPONSEuntil another multiplexing related action takes place.

However it is possible to send test commands with �any contents� (with exception of test messageswith the specific IEI for the Version Check, as defined in chapter 9.5).If a test command with �any contents� is sent, it has to be sent back to the originator with the samecontents.

TE MS


UIH TestCommand(P=0, C/R=1, TEMUX_VersionX)

UIH TestCommand_Resp(P=0, C/R=0, TEMUX_VersionX)

- Comparison MSMUX_VersionY =! TEMUX_VersionX -> the lower multiplexer version is used (minimum of internal version TE and MS)

UIH TestCommand(P=0, C/R=1, MSMUX_VersionY)

UIH TestCommand_Resp(P=0, C/R=0, MSMUX_VersionY)

- Version check



9.5 DefinitionsIf there is a software version mismatch between the TE and MS the lowest common version will beused. The TE is initiating the version check by sending the test command message during the start upof the multiplexer. The multiplexer version numbers have to be compared on both sides. In the futuresoftware including the multiplexer version check shall be used.

Example:The MSMUX_VERSION2 ´Request Test Message´ is shown as hexadecimal dump send from the MS.The version number is indicated in the last 3 bytes (32 00 00).

F9 03 EF 25 23 21 08 4D 53 4D 55 58 56 45 52 53 49 4F 4E 32 00 00

9.5.1 Coding of �TestCommand� message

The coding of the multiplexer stack version is used specifically for SIEMENS equipment and is notdefined in ETSI standards. The IEI values defined for the verification pattern of the �TestCommand�message are indicated in Table 10.(see GSM recommendation 07.10 / chapter 5.4.6.3.4)

IEI coding Information element name8 7 6 5 4 3 2 1

0 0 0 0 0 1 0 0 TEMUX_VERSION0 0 0 0 1 0 0 0 MSMUX_VERSION

Other values reserved for future use

For easier analysis of multiplexer traces the message shall be sent in the following format:

(1.) Version IEI(2.) TEMUXVERSION/MSMUXVERSION (send as ASCII)(3.) Version Number (1...999 send as ASCII)

The message part after the Version IEI is coded with ASCII characters. So it is possible toread the version information from the trace file.The version number must have a value between 1-999.If not all digits of the version number are used - only the used digits are coded as ASCII sign(s). Digitwhich are not used are sent as zero string in the test message.

Table 10: IEI coding



9.5.2 Example of �TestCommand� message

An example for coding a �TestCommand� message is illustrated in Table 11.

IEI coding Information element name8 7 6 5 4 3 2 1 0x1 0 0 1 1 1 1 1 F9 START Flag0 0 0 0 0 0 1 1 03 Address Field DLCI=0,C/R=0,EA=01 1 1 0 1 1 1 1 EF Control Field UIH Frame, P/F=00 0 0 0 1 0 1 1 25 Length LENGTH=18, EA=10 0 1 0 0 0 1 1 23 Type Field TestCommand, C/R=1, EA=10 0 0 0 0 1 1 1 21 Length Lenth=16, EA=10 0 0 0 0 1 0 0 04 TEMUX_VERSION

54 T45 E4D M55 U58 X56 V45 E52 R53 S49 I4F O4E N39 Version number = 99939

0 0 0 0 0 0 0 1 39X X X X X X X X XX FCS (is calculated)1 0 0 1 1 1 1 1 F9 END Flag

Table 11: Coding of �TestCommand� (Example)

Documents

tc3x mux guide03 01 - pudn.comread.pudn.com/downloads103/doc/project/423620/tc3x_mux_guide_v0… · reserved in the event of grant of a patent or the registration of a utility model