Connecting an Apple iBook, running Linux, via GSM to an isdn4linux machine ========================================================================== My intend was to connect two computers, both running a Linux OS, via a Motorola Timeport 260 mobile GSM phone and isdn. The mobile computer was an Apple iBook, the stationary an ordinary PC connected to the ISDN by means of isdn4linux. Unfortunately, completing this task required solving several non-trivial and non-standard problems. I hope that sharing my experience might be helpful for solving problem involving similar sub-tasks. Controlling the Timeport Mobile Phone from Linux ------------------------------------------------ I bought the Motorola Timeport 260 mobile phone bundled with a GSM subscription from the German provider e-plus. This cellular phone supports data transmission via circuit switched data service (CSD) as well as via GPRS. I didn't try GPRS yet, this article only applies to CSD. It seems that in some other areas, the same phone is distributed as model `P 7389i'. (I don't know whether this is exactly the same model, maybe there are minor firmware differences, but the case as well at the supported features seem to be the same). The phone has an IRDA interface as well a serial line interface. An adapter cable with a 9-pin IRS-232 connector was included in the package. The presence of an RS-232 interface alone does not make this working under arbitrary operating systems yet. For working with standard communication packages (under MacOS as well as under Unix-like systems) the phone should support the standard ``AT'' modem commands for controlling connections via the serial line. The package also contained a CD-ROM with some software, but this software was for MS-Windows only. Neither MacOS nor any free software OS was supported. Therefor, I asked the dealers whether it was possible to use that phone for data transmission via the serial cable to a Linux+ and MacOS machine. Surprise: none of the dealers asked ``what is Linux?''. Not so surprising: all of them studied the manual (which does not document the external interfaces at all) and finally replied ``Sorry, I don't know''. Well, the e-plus dealer asked me to came back two hours later, in the mean time, he would figure out from Motorola whether the Timeport 260 could be used under Linux. When I came back, he told me that Motorola had confirmed that using the phone with Linux was possible. Because of this (and also because e-plus seemed to offer the best service package for my estimated usage pattern), I bought the phone and subscribed to their GSM service. The first thing I tried was to connect the phone by means of the bundled serial adapter cable to the /dev/ttyS1 port of my Linux PC and started the seyon terminal emulator by seyon -modem /dev/ttyS1 & I typed `AT[RETURN]' in the terminal emulator window and expected to see an `OK' response. Unfortunately, this response did not appear on the screen. I tried all available speeds and other tty setting of the serial port supported by seyon (the version installed seems to only support setting POSIX baud rates). No effect! Just some garbage-like output with certain baud rates. I did some data mining, and the result was disappointing. There were several hints in the web (including Motorola's own web sites www.motorola.[com,de]) that the phone supports a soft modem only -- that means: it does not support standard modem commands via the RS-232 port internally but needs special (Windows-only) software for call control. But on the other hands, this seemed strange because there was evidence that AT-commands were supported over the IRDA interface: Why should Motorola implement the AT-command set inside the phone's firmware, but not provide this command interface at the RS232 port? Well, before complaining I made a last effort by setting other baud rates that where not supported by my installed seyon version. This can be done by starting seyon and than executing stty from another terminal window with standard input redirected to the serial port in question. And suddenly, after typing stty 57600 < /dev/ttyS1 the `OK' modem prompt appeared after typing `AT' into the seyon terminal window. In brief, the phone honours the AT-command interface but its serial interface does not support auto-sensing the baud rate. Hardware flow control works, but the DTR and DSR RS232 control lines are apparently not functional. (At least, I've never seen seyon indicating DSR `on', nor did setting DTR `off' hang up the current call). This DTR/DSR matter is somewhat annoying because most com software relies on these control line signals for hangup purpose. Most basic AT-commands as well as certain special GSM-related `AT+C'-prefix commands work. (The GSM related commands have been standardised by ETSI in ETSI TS 127 007, see http://www.etsi.org). In particular, SMS-related commands are supported, but the standardised AT+C-commands for manipulating the phone book entries are not. If you want to know more about the GSM-related commands, entering the string ``at+cbst'' into an Internet search engine is a good start. Setting up connections via a GSM call works pretty much like with a standard modem. The only special thing is that some GSM-ISDN-interworking equipment (operated by your GSM provider) must be instructed how the data is to be converted when passing the GSM-ISDN-border. For analogue peers, data is passed through a modem. For isdn peers, data can be converted to V.110 format. The advantage is that connection set up with V.110 is faster: as there is no modem involved, data can be transmitted as soon as the connection is up. A modem, in contrast, needs a considerable amount of time for training before user data transmission can actually start. isdn4linux and the cellular phone both support V.110 at 9600 baud. V.110 at 9600 baud can be selected by sending the command AT+CBST=71,0,1 to the cellular phone before the connection is to be set up. At the isdn4linux side, the /dev/ttyI? virtual modem ports are configured for V.110 at 9600 baud by the command AT&R9600 After that, it is possible to setup data calls from GSM to isdn. For testing, I started 2 seyon processes, one on /dev/ttyS1, the other on /dev/ttyI1. After typing ATD into the ttyS1 seyon window, a RING indicator appears in the ttyI1 seyon window. Typing ATA into the ttyI1 seyon window accepts the call. After that, characters typed into the ttyI1 window are printed on the /dev/ttyS1 window and vice versa. And a positive surprise: It also works vice versa, V.110 data calls originating from isdn4linux to the GSM phone number are signalled at the mobile phone as data calls and can be accepted by the ATA modem command. Why is that surprising? Because I did not pay for it ;). Well, data service for outgoing calls is included in e-plus' service agreement. For incoming data calls originating from POTS (analogue phones), a special data phone number is necessary such that the GSM network can distinguish incoming data calls from voice calls. A special subscription (involving extra payment) to this service is necessary. For calls from isdn however, this is technically not necessary because the data calls can be distinguished from voice calls by means of a service indicator / Q.931 bearer capability information element when the isdn peer sets up the call. The GSM network automatically detects V.110 data calls and implicitly passes them through a V.110 converter and signals them as data calls to the subscriber. Fortunately, e-plus did not artificially block such data calls for non-data-service subscribers. (I don't know whether other GSM provider apply the same policy) Another interesting observation: The AT+CBST modem command also allows to select other bearer service. In particular, V.110 allows also for faster data rates. It is possible to query the phone about the supported bearer service types by the modem command AT+CBST=?; which results in: +CBST: (000-002,004-007,065,066,068,070,071),(000),(000-003) The numbers from 65,66,68,70, and 71 correspond to V.110 data rates 300, 1200, 2400, 4800, and 9600 bps. When trying to set another bearer service, the phone answers with ERROR However, there were three exceptions: 12, 14, (V.34 modem at 9600 and 14400 bps) and 75 (V.110 at 14400 bps) are also accepted, although they are not listed in the AT+CBST=? response! And even better, I've veryfied that V.110 at 14.400 bps actually works! Unfortunatly, current isdn4linux cannot take advantage of this, but more about this problem and its solution later. Connecting the iBook to the Cellular Phone ------------------------------------------ Selecting a USB Converter If you ask why this is worth an own chapter: the Apple iBook is neither equipped with a serial nor an IRDA port. Beside the built-in modem and ethernet interface, connecting external devices is only supported by USB. As the Motorola phone supports a serial and an IRDA interface, there are two options: (a) USB-to-serial adapter (b) USB-to-IRDA adapter The USB support is integrated in Linux 2.4.x kernels. But a look into the kernel source source files linux/drivers/usb{/serial}/Config.in reveals that almost all drivers for USB-serial-converters as well as the only USB-to-irda driver are marked EXPERIMENTAL. As both type of adapters are not needed by the standard PC buyer, they are not sold in every PC shop. Finding a dealer which has such articles on stock can take some time. I prefer the serial cable connection, and the serial adapters sell for around half the price of an IRDA adapter. I've also heard rumours (not sure, but IRDA gurus should now better) that hardware flow control is not supported over irda. Thus, I chose option (a). The next problem is to choose the right product. Of course, the constraint is that the USB-serial adapter works under Linux. For certain classes of devices, there are dedicated USB specifications. Devices conforming to such specifications can usually be connected to any USB-supporting operating system, using a generic class driver provided by the OS. (E.g. there is the so called 'ACM' class for USB modems [which does however not imply that every USB modem conforms to that class specification]). Unfortunately, there is no USB class for serial adapters. Consequently, every type of converter needs a dedicated driver. There are however some standard chip sets used inside USB-to-serial converters. If a driver for that chip set is available, chances are that the driver works with all converter models which are based on that chip set. But that package of the converter does not tell you which chip set is used inside. From looking at the kernel source file, it seemed that the FTDI chipset was fairly well supported. The company's web site (see http://www.ftdichip.com) contains various generic drivers related to their chipsets which can be downloaded for free. Manufacturers who make products based on their chipsets can also use these drivers. They support several operating systems (MS-Win and MacOS family). Linux drivers are not supported by themselves, but they have actively provided assistance to the driver author. See http://reality.sgi.com/bryder_wellington/ftdi_sio for details. So the next step was to find a product which was based on the above chipset. Some computer shops here in Hamburg were selling a converter consisting of a short black cable with an USB plug at one end and a 25-pin RS232 port at the other end. There was no brand name on the product (NoName) -- instead every vendor sold that adapter using its own brand. Although the package looked different, the adapters seemed to be identical. However, the packages stated that it works with Windows98 only. So I suspected that it was not based on the FTDI chipset (otherwise, as drivers for several other MS-Win derivates and MacOS are provided by the chipset manufacturer, the adapter manufacturer would have supported these other OS, too). A local Apple retailer had a two-port converter on stock. It probably was a Keyspan USA-28 product, which seems to be well supported under Linux. But this Converter was not equipped with a standard RS232 connecter but with Apple's MiniDIN RS422 connectors. I would have needed an additional Adapter for connecting this to the DB9 serial port of the Timeport phone. Further, I only needed one serial port. Some data mining suggested that the adapter ATEN UC-232 was based on the FTDI chipset. This adapter also provides one DB25 RS232 serial port. I figured out the the German retailer `Conrad Elektronik' (see http://www.conrad.de) sold that product. Thus, I went to the local Conrad shop. I found the adaptor in the shop's shelves, but it was not the ATEN UC-232, but another model named ATEN UC-232A (see http://www.aten-usa.com for details). The feature list printed on the box also stated that several MS-Win 95/98/2000 as well as MacOS was supported. The apparent difference compared to the UC-232 is that the former is equipped with a DB9 serial plug. ``Even better'', I thought, because the phone also provided a DB9 port and I could save an additional DB9-to-DB25 adapter. It is also smaller and lighter than the UC-232. In brief, it seemed to be exactly the kind of adapter I was looking for. Testing with MacOS Arrived at home, I first tested with the MacOS driver (iBook, MacOS 8.6). Installation of the MacOS driver was somewhat strange, the installation instructions related to MacOS were very raw, not something MacOS users would expect. It was required to copy certain files from the driver CD-ROM into certain MacOS's directories, and the files to be copied depended on the product's serial number. The serial number printed on the adaptor was not structured as described in the installation instructions. However, after guessing which digit of the serial number determines the driver version to be installed, I succeeded. The serial port was visible from MacOS. I tried some basic testing under MacOS by sending AT-command to the Motorola phone. The first problem was that the phone only works with a serial line speed set to 57600 baud. However, MacOS configuration menus apparently do not provide for setting the serial port's baud rate explicitly. They allow to select from a list of modem types, which apparently sets the line speed as well as configures the modem initialisation (AT-command) sequences. I guess there are special programs to create new modem entries. But as I wanted to use MacOS for testing only, I did not look at this further. I just applied a trick to set the line speed: there was an entry in the MacOS modem type menu for a 57600 baud null-modem-cable connection. I selected this. The trick above will not initialise the Timeport phone completely, but at least it allows to send AT-commands to the modem from a terminal emulator window. I did not detect a dedicated terminal emulation program in my MacOS system installation. But the ppp configuration menu has an option which allows to connect through a command line host. (As my MacOS 8.6 is a German version, I don't know what the proper English names for the menu entries are). This essentially provides a terminal emulator window, which is intended to be used for manually logging in at the ppp host. Usually, after successful login and setting up ppp on the peer, you would switch from terminal emulation to ppp protocol processing. But if you don't, you can continue to use it as an ordinary terminal emulator. Anyway, applying this trick allowed to send the AT-commands to the mobile phone and to manually set up a connection to my isdn4linux peer (entering manually the same AT-commands as already tested from Linux /dev/ttyS1 interface). I also used the same set up and connected the iBook successfully to the PC's /dev/ttyS1 port (by means of a null modem cable between the USB-serial adapter and the COM port). Choosing the Proper Linux driver After having verified under MacOS that the USB-to-serial converter worked, I tried to use it from Linux. I re-compiled the kernel, enabling USB serial support and compiling the ftds_io driver as a module. Then I loaded the ftdi_sio driver modprobe ftdi_sio However, the driver did not detect my serial converter. I suspected that the USB vendor id and product id of the new (UC-232A) converter were not yet known by the driver. Thus, I modified the driver source file and added the USB product and vendor ID of my adapter to the driver's list of supported id's. Now the adapter was recognised by the driver, but it did not work. It was possible to send and receive some corrupted characters, but that was unusable. Apparently, either - my data mining results, which suggested that the UC-232 was based on the ftdi chipset, were wrong or - data mining results were correct, but the UC-232A uses a different chipset than the UC-232. I still don't know which of the above is the true reason (and anyway, it does not really matter, the resulting problems and remedies are the same). I tried the other drivers mentioned in the kernel's Documentation/usb/usb-serial.txt file (after adding the adapter's USB vendor and product id to the drivers's lists), but none of them worked. This was not exactly very promising. I continued my data mining efforts, feeding ``UC-232A'' strings into www search engines. This revealed that the USB protocol stack present in the NetBSD (-current) operating system supports the ATEN UC-232A adapter and that the adapter is based on a Prolific 2303 chip (http://www.prolific.com.tw). Further searches even revealed that very recent Linux kernels (2.4.7 definitly) have a driver ``pl2303'' for this chip. I compiled the pl2303 driver from a 2.4.7 kernel and tried to load it. The driver recognized my serial converter without modifications. Characters were no longer corrupted, but unfortunatly only a few characters were transmitted before the driver stopped working or the kernel crashed. Getting the pl2303 Linux Driver Working --------------------------------------- As I had some background with Linux kernel programming (related to network protocol stacks and isdn, but neither to USB nor to serial drivers) I started to look into the driver's source code. I also looked at the NetBSD driver source code for reference. The NetBSD driver revealed that some older versions of the Prolific chipset use a non-standard USB-interface constellation which causes naive USB drivers to fail. The newer revisions of the chipset have fixed this. The NetBSD driver therefor conditionally activates a work-around if it detects that the chip needs it. The Linux driver also implements a similar work-around. But it turns out that the work-around is always active. My ATEN UC-232A seems to be based on the new chip revisions. These new chips do not need the work-around. In contrast, the driver fails with the new chips if the work-around is applied. Thus, the first step was to modify the driver, and to only turn on the work-around when really needed, only. The other observation: It seemed that the Linux generic USB serial driver worked sort of, just the baud rate was in an undefined state. As the original pl2303 driver was very unstable (kernel crashes) I started to only use the initialisation code from the original pl2303 driver and used the generic driver's code for anything else. This resulted in a stable, but functionally very limited, driver. Based on this, I could debug a re-enable the features implemented in the original pl2303 drivers. I was also able to add features not present in the original driver version. An advantage of the chipset is that it honours certain USB Communication Class ACM (Abstract Control Model) commands. These commands are intended to provide a unified driver interface to USB modems. Unfortunately, there is no similar specifications for USB serial converters. But as legacy modems are connected by means of a serial port, the ACM specification contains commands to emulate serial port control. Where applicable, the same commands are honoured by the pl2303 chipset for configuring, controlling, and querying its serial port. That is an advantage, because: - The Linux USB stack already contains a driver for ACM devices (drivers/usb/acm.c). Thus, it was possible to re-use some code of the ACM driver for implementing features not yet present in the original pl2303 driver. - The ACM commands are well documented. See http://www.usb.org for downloading the recent version of the `USB Class Definitions for Communication Devices'. This made implementing new features more easy. (even those features which were neither present in the original pl2303, nor in the ACM driver). The source code of the NetBSD driver was also a good source of getting an idea on how certain things could be done. The driver is now in a state were it works sufficiently for me. Of course, it needs further debugging and testing. Certain features are still missing or difficult to implement (due to hardware limitations). And POSIX-compliance has not been verified, neither. In the mean time, kernel 2.4.10 has been released which contains a revised version of the pl2303 driver. It seems to use methods similar to the generic serial driver such that it works more stable. It does however not implement the additional features mentioned above, thus I now ported these new features to 2.4.10. OOPS -- there is already a 2.4.12 out which even requires a new patch. Login shell via GSM/ISDN connection ----------------------------------- This is not really worth an own section, but does not fit elsewhere. Just add the following line to /etc/initab I1:23:respawn:/usr/sbin/mgetty -D -m '"" at&f&eYOUR_MSN&r9600 OK ath0 OK' /dev/ttyI1 Replace YOUR_MSN above by your isdn phone number. After that, do /sbin/telinit q /sbin/telinit u -- or just reboot instead if you prefer the MS-Windows method ;) Check the mgetty documentation and example config files of your Linux distribution for further documentation. In particular, the following features could be interesting: - the magic /AutoPPP/ entry in mgetty's login.config file. This allows to automatically distinguish incoming shell from ppp login requests. Useful if you you additionally want to run ppp over the GSM link. - The cnd-program entry in mgetty's mgetty.config file. This allows to check for the calling party number before accepting an incoming isdn call. Apply this if you want that only your own mobile phone shall be allowed to dial into your stationary computer. Improving isdn4linux V.110 -------------------------- The total capacity of a circuit switched GSM full rate channel is 22800 bits/sec. However, only a fraction thereof is available to the user. A speech channel provides a 13000 bps bit stream to the speech codec, a data channel 12000 bps. The remaining bits are used by a forward error correction code (the code is different for data and speech channels). But not all of the 12000 bbs are really available to data applications. Some fraction of the 12000 bbs is needed for data encoding. For asynchronous data service, only 9600 bps are available to the end user. isdn4linux supports V.110 at 9600 bps, which seems to be just fine. But that's not true! An isdn channel applying the V.110 protocol at 9600 bps essentially emulates a serial line. Connecting two isdn peers by V.110/9600 should behave (almost) exactly as if the two peers were connected by a null modem cable. In the case of asynchronous serial lines, this implies: - Transmission of each character does not only transmit the 8 data bis, it also requires to send at least one start and one stop bit. This implies that the throughput available for applications is at most 8/10 of the line rate. - Beside the data lines, A serial line has some additional status lines. like DSR, DTR, RTS, CTS. These are not intended for transmitting user data but to signal status changes of the serial interface to the peer. The RTS and CTS signal are in particular frequently used for hardware flow control. Even if these status line are not used to transmit user data, they transmit data, although typically at a much lower rate than the data. lines This implies that a V.110 protocol at 9600 bps: - Must insert extra bits into the user data stream corresponding to the start and stop bits of the serial line. The way characters are framed by V.110 requires 2 bits per characters, thus this is already done implicitly when emulation a serial line with one start and one stop bit. If more stop bits are used, V.110 must insert additional fill bits into the data stream. - Beside the user data, which is transmitted at the nominal user rate, the protocol must provide auxiliary channels for transmitting the status of the control lines. The transfer rate is however lower than the user data rate (the total bandwidth of the V.110 auxiliary channel is 1/6 of the user data rate, the auxiliary channel is further multiplexed into subchannels which carry the state of a certain control line each). V.110 data is carried in frames of 10 bytes. The first byte is always zero, the most significant bit of the other channels is always 1. This allows the sender and the receiver to synchronise the frames. Byte 5 is also used for special purpose (contains so called E-bits, used when emulating synchronous serial lines). That means there are 8 Data bytes per 10 byte frame. As the most significant bit is used for framing, only 7 bits are available for data. The least significant bit (called S and X bits) of each data byte is used for V.24 control line state, the remaining 6 bits for user data. This results in the follwing bit pattern: 00000000 1DDDDDDS 1DDDDDDX 1DDDDDDS 1DDDDDDS 1EEEEEEE 1DDDDDDS 1DDDDDDX 1DDDDDDS 1DDDDDDS Thus, there is space for 48 bits of user data within each 80 bit (=10 byte) frame. Multiplied with the isdn transfer rate of 64000 bps, this allows for a maximum user rate of 48*64000/80 = 38400 bps. Beside the user data bits, V.110 inserts start and stop/fill bits into the stream when emulating asynchronous lines. The start bit is always 0, followed by a fixed number (usually 8) of arbitrary data bits followed by an arbitrary number (at least 1, which correspond to the the stop bit) of fill bits which are always 1. If the serial line data rate to be emulated by V.110 is lower than the 38400 bps, the transmitter must insert additional fill bits after each transmitted character in order to downgrade the throughput of the line appropriately. However, If the rate is less than half the maximum rate, V.110 applies a second method of slowing down the link. The data contained in each byte is distributed among two consecutive bytes. This even allows to multiplex two V.110 frames (operating at half of maximum data speed) into one ISDN B channel. V110 also provides for multiplexing 4 frames into one B channel. isdn4linux supports the 1 (38400 bps), 2 (19200 bps) and 4 (9600 bps) times multiplexed channels. But it does not really support multiplexing, only the data one the first subchannel can be read and written. This is sufficient for downgrading throughput (and most other V.110 implementations don't exploit the multiplexing feature, neither). However, current isdn4linux does not support configuring the number of fill bits to be inserted into the data stream. Thus, it only supports sending with the basic V.110 rates of 38400, 19200 and 9600 bps. This does inter-work sub-optimally with GSM data transmission: GSM async data service allows for up to 9600 bps user data. A V.110 channel at 9600 bps allows at most for 9600*8/10= 7680 bps. And beside this, I detected that isdn4linux always inserts 2 fill bits (instead of 1 required as stop bit) after each transmitted character. This further slows down the data rate, which degrades to 6981.81... bps. For fully exploiting the capacity of a GSM data channel, we need to send at least with a V.110 rate of 12000 bps. As this is not supported by linux, we can only switch to the next available higher rate of 19200 bps. Using this data rate, I could actually verify that the AT+CBST=75 really worked with the Motorola Timeport 260. I switched the Timeport to V.110 to 14400 bps (at+cbst=75) and enabled rts/cts hardware flow control by means of the commands AT+CBST=75,0,1 AT&K3 After logging in from the gsm `modem' to the isdn4linux machine I temporarily switched of echoing on the incoming isdn (say ttyI0) interface (which was the login shells standard input) and cat'ed the input into a file: stty -echo; cat > /tmp/outfile; stty echo Then I typed from another xterm time cat /tmp/infile > /dev/ttyUSB0 When this is finished, it reports the time (say t seconds) used for the data transmission. If the size of /tmp/infile is s bytes, then the bit transfer rate (8 user data bits per byte) is 8*s/t which was very close to the theoretically possible 9600 bps user data. If you want to repeat similar tests: keep in mind that - some data might still be in the modem buffers when the cat command is finished. This gives a slight underestimation (1-2 sec) of the transfer time and a corresponding overestimation of the bit rate. Make the files sufficiently large such that this error is negligible. - Verify that the data you've piped into the cellular phone really arrived at the destination. At least you should compare the file size of /tmp/infile and /tmp/outfile. Better, do a diff /tmp/infile /tmp/outfile in order to check for transmission errors. I used a test file of 96000 bytes, which was transferred in approximatly 80 seconds. This test seemed to verify that the undocumented AT+CBST=75 really allowed for sending data from the GSM peer to the ISDN peer with the full GSM data rate. However, one strange observation was (verified from D channel traces) that the call was signalled as a 9600 baud V.110 call (encoded in the Low Layer Compatibility information element) at my ISDN line. This required a trick such that isdn4linux could accepted the call. I hat to tell i4l to switch to V.110 at 19200 bps (this uses the same frame structure as V.110 rates 12000 and 14400), but nevertheless accept the call with 9600 bps paramters. This is done by the i4l AT commands AT&R19200 ATS19=197 I don't know what causes this strange behavior. I first thought that it was a bug in the GSM's V.110 implementation because my benchmarks had really proven that I could send data faster than an V.110 at 9600 bps. But then a few more tests revealed that I could send with the high throughput (corrsponding to V.110 12000 bps), even if I told the phone to require only V.110 9600 bps (AT+CBST=71) when connection to the isdn4linux port configured at 19200 bps. However, when connecting to an isdn4linux port configured for only 9600 bps, then I really could only receive with the theoreticially expected bandwidth (transmitting the 96000 byte test file takes around 100 seconds). Thus, it might as well be a bug in the motorola phone and the scenario might be like this: - Motorola phone tells the GSM (despite configured for 14400 bps) to set up the call at V.110 9600 bps. - The GSM tries to connect at this speed to my i4l machine - As my i4l is configured at 19200 bps, the GSM's V.110 encoder detects that my machine is operating at the `wrong' speed - The GSM's V.110 encoder is clever and switches to that higher speed. A subjective impression which supports this suspection is that the time between the modem CONNECT message and the appearance of the login prompt is longer when connecting to the 19200 bps port then when connecting to the 9600 bps port. This additional time could have been consumed by detecting the baud mismatch and by re-synchronising at the higher baud rate. Anyway, the tests really proved that it was possible to send data from the mobile phone to isdn4linux at the full bandwidth as provided by the GSM channel! But similar tests sending from isdn towards the mobile phone failed. The problem: if i4l is configured with V.110 at 19200 bps, data is fed too fast to the GSM channel -- faster that the GSM channel capacity. The V.110 converter at the GSM-ISDN border has an input buffer, but after a short time the buffer will overflow and subsequently submitted data will be partially lost. Even if an error correcting and bandwidth adapting protocol like TCP is used in the upper layers, this will at least slow down performance, probably to a much lower throughput rate then provided by the above suboptimal V.110 9600 bps configuration. I even observed that continuous buffer overruns caused the GSM's V.110 input to loose V.110 frame synchronisation. When this happened frequently, this was considered an error which caused the call to be cleared. So the first approach was to make the number of fill bits which the i4l V.110 encoder inserts into the data stream configurable. That was relatively easy after I had finally understood how the encoder worked. A 12000 bps character transmission with one start and one stop bit corresponds to 19200 bps base rate with 7 bits inserted after and one start bit inserted before each V.110 character. With this extension, other rates are easily configured as well. E.g. the common rate of 14400 bps requires (1+4) additional bits for each byte transmitted. However, slowing down the throughput to V.110/12000 bps is not necessarily sufficient. Transmission on the radio link is usually protected by an error correction protocol (in addition to the forward error correction encoding of the full rate channel). This will retransmit frames that could not be corrected by the forward error correction. However, this retransmissions consumes additional bandwidth which is not available to the V.110 sender. If some noise on the radio link temporarily causes several retransmissions, the GSM's V.110 input buffer may overrun during this time, even if only fed with 12000 bps. The i4l downgraded 9600 bps rate may still do do a good job, because there is plenty of sparse bandwidth available for the RLP retransmission. But it is not 100% bullet proof. If the radio link's throughput temporarily decreases too much, even the 8/11 underrate of current i4l V.110/9600 may overrun the GSM's input buffer. To really remedy this, a flow control mechanism is necessary which tells the i4l V.110 transmitter to cease sending more character when the GSM's V.110 input buffer is almost full. On serial lines, the preferred way to do this is hardware RTS/CTS handshake flow control. If the transmitter detects that its CTS line signal is off, it must cease to transmit more characters until the CTS is on again. As V.110 emulates a real serial line including the RTS/CTS signal, this is possible. For emulating the RTS/CTS control circuit state, a certain bit (the so-called X bit) of the V.110 frame is used. If the GSM's V.110 input buffer gets too full, it sets the X bit in all of its outgoing V.110 frames. When the peer receives a frame with the X bit set it should interprete this as a `CTS off' condition and subsequently pause transmission of user data towards the GSM. That's the theory. However, the current i4l V.110 implementation does not scan incoming V.110 frames for the presence of X bits and subsequently cannot use this to flow control the upper i4l layers. So I also added this feature to i4l. The i4l V.110 layer will now refuse to accept more frames for transmission while X bit output flow control is on. I was not sure in advance whether this would suffice. A possible problem is that the reaction on X bit flow control is subject to a certain delay. First, when the GSM V.110 sends us a frame with the X bit on, it takes a certain amount of time until this frame arrives at the i4l computer. Then, even if i4l's V.110 immediately stopped accepting more V.110 frames for transmission, there might already be some frames in the isdn4linux output queues which would still be transmitted. Nevertheless, it worked remarkably well. The GSM's input buffer turned out to be large enough, even when sending as V.110/19200 bps. And again, the benchmark proved that data could be also be tranmitted from isdn4linux to a mobile phone exploiting the full batdwidth provided by the GSM channel! Of course it is possible to combine both methods. As already explained, implementing flow control is really necessary for bullet proof operation. It is still an open question what output rate should be used on a flow controlled connection. The output rate should be at least large enough to fully exploit the available maximum GSM throughput. That is, at least V.110 at 12000 bps should be used. Using higher rates will cause the GSM's V.110 input buffer queues to grow and trigger flow control more frequently. A larger amount of data in the buffers will increase latency. On the other hand, the radio link uses a block encoding scheme for the data. Before the first bit of a block can be encoded and transmitted, the whole block must be present at the encoder. If it is possible to feed a single block to the encoder with a higher bit rate than the radio link speed, the encoder could start to encode a new frame earlier. This might decrease latency if a frame is spontaneously transmitted after a period of silence (where all the buffers have been emptied). HOWTO ===== Well, a short summary on how to configure mobile phone and isnd4linux. For normal speed (V.110 9600 bps): GSM phone: use modem command to configure for V.110 9600 bps AT+CBST=71,0,1 isdn4linux machine: add the following line to /etc/inittab #isdn V.110 at 9600 bps I1:23:respawn:/usr/sbin/mgetty -D -m '"" at&f&e$YOUR_MSN&r9600 OK ath0 OK' /dev/ttyI1 Of course, replace the string `$YOUR_MSN' by one of your isdn phone numbers. This should always work. Cookbook instructions for setting up higher speed (V.110 >= 12000 bps): GSM phone: try the first initialisation from the following list that is accepted (accepted means that GSM phone replies with `OK'): 19200 bps: AT+CBST=79,0,1 14400 bps: AT+CBST=75,0,1 12000 bps: AT+CBST=74,0,1 9600 bps: AT+CBST=71,0,1 Then dial (ATD... from terminal program attached to gsm phone) from the gsm phone to your isdn line. If the correct V.110 baud rate is included in the calls setup messsage, you should observe syslog messages similar to 19200 bps: isdn_net: call from $YOUR_GSM_NO,7,199 -> $YOUR_MSN_NO 14400 bps: isdn_net: call from $YOUR_GSM_NO,7,198 -> $YOUR_MSN_NO 12000 bps: isdn_net: call from $YOUR_GSM_NO,7,192 -> $YOUR_MSN_NO 9600 bps: isdn_net: call from $YOUR_GSM_NO,7,197 -> $YOUR_MSN_NO ^^^ $SI2 Remember the SI2 value reported in your syslog messages. Then add the following line to your /etc/inittab (replace $SI2 by the number observed in the syslog message): #isdn V.110 at 19200 bps, listening for service indicator $SI2 I2:23:respawn:/usr/sbin/mgetty -D -m '"" at&f&e$YOUR_MSN&r19200 OK ats19=$SI2 OK ath0 OK ' /dev/ttyI2 , enter /sbin/telinit q /sbin/telinit u and try to login via a terminal emulator program (e.g. minicom, seyon,..) from your GSM phone. If you get a CONNECT and a login prompt, your connection is probably able to exploit the full GSM channel bandwidth. You should then be motivated to install an isdn4linux patch. After having applied the V.110 patch to isdn4linux, isdn4linux will honor setting the new baud rates 12000 and 14400 by the AT&R modem commands: AT&R12000 or AT&R14400 Further, output to /dev/ttyI* devices will now be (`hardware', rts/cts) flow controlled by means the V.110 X bits when the V.110 protocol is selected. You can now configure even higher baud rates without causing GSM input buffer overruns. Some special remarks about some particulare SI2 values: If $SI2 is 197, then you cannot use the same `I2' /etc/inititatb entry simultaneously with the `I1' line above. The suggested work-around is to use different MSNs for the entries. $SI2=192 ist not necessarily an indication for incoming V.110 call at 12000 bps. The current HiSax driver will assign this value for any V.110 rate it does not explicitly know about (and it does not know about 12000). 198 really corresponds to 14400 bps, but this value is also used by isdn4linux for V.110 38400 bps. The i4l documention mentions that this is non-standard use for V.110 38400. The latter two remarks are for completeness, only. If you set up your GSM phone and isdn4linux as described above, it is very unlikely that the resulting SI2 ambiguities will effect you. Have fun! Henner