This document describes the specifics of the GSM IAP. For a general description of an IAP, refer iap.html.

The GSM IAP provides an interface for the cell-phones in the testbed to be part of Iceberg (i.e., to be Iceberg end-devices, access Iceberg services, etc).

The constituent pieces

The GSM IAP is by far the most complicated one. It has several constituent pieces: the UPSim, the IP-PAD, and a Java-based software to interface the two to the Iceberg Internet-core. The relationship between these components is shown in the figure below.


The Java-based software is the UPSim-IP gateway in the picture. This software is very similar to the other IAPs. We will be describing this software in this document. For simplicity, we will use the term GSM-IAP to denote this software although the IAP also includes the other pieces in the figure.

The UPSim provides the control path between the cell-phone and the GSM-IAP. The IP-PAD (IP Packet Assembler Disassembler) provides the data-path. The data-path is in terms of an RTP stream per established session. The control-connection between the GSM-IAP and the UPSim is in terms of two TCP connections. This interface is documented elsewhere and is not relevant here.

Structure of the GSM-IAP

There are two main programs. One is the program that has the control connections with the UPSim -- The other is the one that forwards the RTP stream from the IP-PAD to the other end of the session -- The interface between these two could have been an RMI interface. In fact, these need not have been different program -- the second could have been a thread within the first. But the interface between the two is a clumsy TCP based sockets interface (I was more familiar with sockets than Java RMI when I wrote this). has five threads. There is one each for waiting on each of the TCP connections to the UPSim (one of the TCP connections is for calls from the cell-phone side, and one is for calls from the Internet-core side). One thread is for managing the TCP connection with

The other two threads are for reporting cell-phone attach and detach to an arbitrary interested party. This interface was originally intended for the preference registry to detect if a user's cell-phone is turned off and redirect calls accordingly. This interface is TCP based. There are a lot of open issues with such reporting and these have not been addressed very well. This part of the IAP needs re-thinking and re-implementation and can be ignored.

Interface between GSM-IAP and Ctl_Data Forwarder

The ctl_data forwarder connects to the GSM-IAP which listens on TCP port 2222. All further communication happens through this TCP connection. A uniform packet format is defined on this connection. The packet in C-style is:

struct ctl_data_pkt {
  byte type;
  byte ts;
  int send_port;
  int listen_port;
  int ipaddr;

The type field defines the purpose of the packet. The ts field specifies the time-slot of the call in question. The send_port and ipaddr define the destination of the packets on the other side. The listen_port field defines the port on which to listen locally for this particular stream.

The following packet types are defined:

Note: When the GSM-IAP sets up a call to itself (one cell-phone to another), only one forwarder is required. This is spawned by the caller (that is, the IAP when it is calling, rather than when it is responding to the call).

The files

Running the IAP

Since running the IAP without the other pieces (UPSim and IP-PAD) does'nt make sense, this is documented elsewhere and is not relevant here.

Bhaskaran Raman,
Last modified: Mon May 29 12:29:20 PDT 2000