MH Leaving the Mobile Network

When a MH leaves the mobile network, it may detect other network and update its contact information by sending a SIP REGISTER message. If there is an on-going session, it can be resumed by SIP re-INVITE. However, since the MH does not deregister with the SIP-MNG, the SIP-MNG will keep its information in the SIP client table. If the MH has an on-going session before it leaves, the SIP-MNG will still reserve resource for the session. Fortunately, if a SIP request arrives, because the MH does not exist in the network, a new session will not be set up. However, the allocated resource will never be released. To solve this problem, we suggest to set a

timer for each session and integrate the SIP-MNG with the underlying routing protocol in the MANET. If the SIP-MNG finds that the MH does not exist after the timer times out, the corresponding resource will be recycled. Noted that the SIP-MNG can determine whether a specific MH exists or not by searching the corresponding entry in the routing table. Alternatively, the SIP OPTIONS message can be used to query the capability of a SIP client or server. The message should be responded with a SIP 200 OK response with the supported capabilities. This can be used to determine a MH's existence.

Chapter 5

The Proposed Push Mechanism

Our system allows the external interfaces of SIP-MNGs to be disconnected when there is no Internet connection. When any interface is connected, the mobile network becomes a part of the Internet, so all sessions can be handled as usual. When all interfaces are disconnected, if an outgoing SIP request is sent by a user in the mobile network, the SIP-MNG can buffer the invitation, dial up to the Internet, register this user with the SIP registrar, and then send the invitation to the callee. However, when the mobile network is out of reach from the Internet, an incoming SIP request can not be completed. To solve this problem, we propose a push mechanism.

In our push mechanism, the SIP-MNG will carry out a sleep procedure when it decides to disconnect from the Internet. Recall that there is a push server in the SIP subsystem (refer to Fig. 10). The SIP-MNG will solicit the push server as its agent during the disconnection period. When an incoming SIP request arrives, the push server will be notified first and will trigger a wake-up procedure, which includes a wake-up process and a session transfer process. In the wake-up process, the push

server will activate the SIP-MNG via SMS (Short Message Service) and establish a connection with the caller to hold the session. After the SIP-MNG reconnects to the

Internet, the transfer process will help build the link between the caller and the

internal callee. In this way, the SIP-MNG can stay off-line but remain reachable from the Internet.

5.1 Sleep Procedure

To avoid modifying the existing SIP standard, the push server works as an agent for users inside the mobile network when the SIP-MNG is disconnected from the Internet. The sleep procedure is to inform the SIP server to redirect all SIP messages destined to mobile network users to the push server.

Fig. 14 shows the message flow of the sleep procedure. When there is no Internet connection, the SIP-MNG may initiate the sleep procedure by sending a sleep request to the push server (H1). The sleep request includes the SIP URIs of MHs inside the mobile network and the MSISDN (Mobile Station International ISDN Number) of one of the cellular interfaces of the SIP-MNG. The MSISDN will later be used by the push server to notify the SIP-MNG of new incoming SIP requests via short messages.

The push server maintains a gateway table and a SIP client table. Each entry in the gateway table is to track the status of one SIP-MNG and includes four fields:

gateway id, status, MSISDN, and IP address. Each entry in the SIP client table is to track one MH and includes three fields: SIP URI, SIP-MNG id, and registration

Fig. 14 Sleep procedure

expiration time. On receiving the sleep request from the SIP-MNG, the push server updates these two tables and marks the status of the SIP-MNG as off-line. The push server then replies an OK to the SIP-MNG (H2). Upon receipt of the OK message, the SIP-MNG will generate REGISTER messages for all internal SIP clients to their corresponding SIP servers (H3) with an EXPIRE value of 0 (which means unregister).

In return, the SIP server will reply SIP 200 OK messages (H4). On the other hand, as soon as the push server replies an OK message to the SIP-MNG (H2), it also sends REGISTER messages for all MHs served by the sleeping SIP-MNG to their SIP servers with a non-zero EXPIRE value (H5). These REGISTER requests should contain the push server's IP address in the CONTACT field, so that all future SIP INVITE requests to these MHs will be forwarded to the push server. Upon receipt of a

REGISTER message, a SIP server will update its record and reply a SIP 200 OK message to the push server (H6). After step H4, the SIP-MNG can disconnect all its wireless interfaces, and after step H6 the push server will become the agent of the mobile network subsystem and send periodic REGISTER messages for it.

5.2 Wake-Up Procedure

Consider a SIP request from a SIP client UA1 in the Internet to a client UA2 in the mobile network. To complete this session, there are two parts in the wake-up procedure: wake-up process and session transfer process.

5.2.1 Wake-Up Process

Fig. 15 illustrates the message flow of the wake-up process. To set up a session to UA2, UA1 first sends a SIP INVITE message to UA2's SIP server containing the session information, connection address, and port number of UA1 in the SDP (F1).

The SIP server will identify that the contact of UA2 is the push server and forward the INVITE to the push server (F2). The push server then checks its SIP client table and gateway table and retrieves UA2's SIP-MNG information. Because the status of the SIP-MNG is off-line, the push server will send a short message to the MSISDN registered by the SIP-MNG (F3). This short message carries the event type and IP

Fig. 15 Wake-Up process

address of the push server to inform the SIP-MNG to reconnect to the Internet. In the meantime, the push server will temporarily set up the session with UA1 to keep the session alive (F4-F7). This can prevent the SIP signaling from timeout. If this is a voice call request, to be more friendly, an option is to have the push server prepare a pre-recorded voice to tell UA1 to wait for the call to be transferred. On the other hand, when the SIP-MNG receives the short message, it will reconnect to the Internet and re-register for all MHs inside the mobile network (F8, F9) using the IP address of any active external interface of the SIP-MNG in the CONTACT field. Also, the SIP-MNG will reply an OK message to the push server via its Internet connection to update its status with the push server (F10).

5.2.2 Session Transfer Process

Next, the session needs to be transferred from the push server to UA2. Fig. 16 depicts the message flow. The process is based on the REFER method [29] proposed by IETF to support session mobility. We comment that IETF also proposes an alternative third-party call control (3pcc) [30]. Requiring no special servers, both REFER and 3pcc are standard SIP solutions to support session mobility and fit our needs well. We adopt the REFER method because it requires less efforts for the push server.

After accomplishing the wake-up process, the push server will send UA1 a

REFER request containing the contact information of UA2 in the Refer-To field (F11).

This message triggers UA1 to invite UA2 using the contact in the Refer-To field.

UA1 then replies a SIP 202 Accepted response to the push server to indicate its approval (F12). To inform the push server that it is establishing a session with UA2, UA1 will also send a SIP NOTIFY message to the push server with an indication of

“SIP/2.0 100 Trying” in the message body (F13). On receiving the NOTIFY message, the push server will respond a SIP 200 OK response (F14). The push server then

Fig. 16 Session transfer process

sends a SIP BYE request to UA1 to terminate their session (F15). UA1 will reply a SIP 200 OK (F16). However, the dialog between the push server and UA1 will be maintained until the subscription created by the REFER is terminated.

To set up a session with UA2, UA1 sends a SIP INVITE request to UA2 containing the SDP that describes the session information of UA1. Then the rest of the SIP signalings follows the normal session setup flow (F17-F20). After the session between UA1 and UA2 is connected, UA1 will report to the push server the success of the session setup and terminate the Refer-To subscription by sending the push

server a SIP NOTIFY message (F21) containing a Subscription-State header field with content of “terminated; reason=noresource". Then, the push server will respond a SIP 200 OK message (F19). The dialog between the push server and UA1 will then be terminated. To stop acting as an agent of the mobile network subsystem, the push server may send REGISTER messages for all SIP clients inside the SIP-MNG to their SIP servers with an EXPIRE value of 0 (F23). In response, the SIP servers will sent 200 OKs (F24).

Note that a MH may simply leave the network without giving any notification.

We have discussed some timeout mechanisms to determine a MH's existence. If the SIP-MNG knows that the callee has left the network, it will not activate any external interface. Otherwise, an interface will be activated, but no MH will accept the INVITE message. So our system still works correctly.

To summarize, in our push mechanism, no change is made on the behavior of the SIP registrar and SIP proxy. SIP clients still use the standard SIP signaling. A push server can serve multiple SIP-MNGs at the same time. The REFER method is also a standard. So the system is fully compatible with existing SIP standards. Short messages and new signaling are supported by our proprietary SIP-MNG and push server. Each SIP client inside the mobile network subsystem can still use its original SIP server, SIP URI, and configuration.

Chapter 6

Prototyping Results

This chapter describes our prototyping results. We will first present the overall prototype, development platforms and tools. Then, we will describe the

implementation details of the two core entities in our system: SIP-based mobile network gateway (SIP-MNG) and push server respectively.

6.1 Prototype, Development Platforms and Tools

Figure 17 shows our prototype of the proposed system, which contains a SIP subsystem and a mobile network subsystem. The SIP subsystem includes three

components: SIP UA, SIP server, and push server. The SIP server is the combination of the two logical entities of SIP registrar and SIP proxy. In the prototype, we adopt the iptel SER[31] to be our SIP server. For the SIP UA, we select two SIP phone products to be our SIP client terminals. One is the D-Link wireline SIP phones; the other is the wireless SIP phones by BCM communication company. In addition to the basic features defined in rfc3261, the D-Link SIP phone supports the SIP REFER method. All SIP clients inside the MANET or in the Internet use the same SIP server as their home SIP server. The push server is implemented on an ASUS centrino notebook running the Windows XP. To carry out the push mechanism, the iSMS

Fig. 17 The implementation of our system architecture

software and the programming tool of Microsoft Visual C++ 6.0 are used. The push server is equipped with a Nokia card phone 2.0 to connect to the GSM cellular network.

The mobile network subsystem consists of a SIP-based mobile network gateway (SIP-MNG), short message service(SMS) relay, and a mobile ad-hoc network

(MANET). The SIP-MNG is implemented on an IBM T42 notebook running the Linux Fedora Core Release IV. The iptables, library libipq, GNU gcc, and g++ are

used as the programming tools to carry out it. The SIP-MNG is equipped with a cellular interface(PHS J88/Huawei E612 WCDMA PCMCIA), which connects to the Internet, and an ASUS WL-167G USB2.0 WLAN adaptor, which is configured at the ad hoc mode and connects to the inside MANET. When a PHS J88 cell phone is used as an external interface, the SIP-MNG drives it via a P-card MC-6550 PCMCIA card.

The installation of PHS and PPP is illustrated in Appendix A. Since the iSMS platform presently only supports Windows OS, to support SMS for SIP-MNG, an SMS relay is set up and connected to SIP-MNG directly via a RJ-45 cable. The SMS relay is equipped with a Nokia card phone 2.0 and installed with the iSMS platform.

So, the SIP-MNG can send and receive short messages through it. In addition to the SIP-MNG, there is a BCM WiFi phone and a D-Link SIP phone inside the MANET.

The BCM SIP WiFi phone is configured at the ad hoc mode. Because the D-Link SIP phone has no 802.11 interface, we connect it to an ASUS centrino notebook via its ethernet interface first, then connect the ASUS notebook to SIP-MNG via its 802.11 interface, and set the two interfaces in the bridge mode. As a result, the D-Link SIP phone can connect to the SIP-MNG through the ASUS notebook’s WLAN interface which is configured at the ad hoc mode.

As for the SIP-MNG and Push Server, we will describe their implementation details in the following.

6.2 SIP-Based Mobile Network Gateway(SIP-MNG)

The SIP-MNG is a gateway between the inside MANET and the outside internet.

To implement the NAPT between the outside Internet and the inside MANET, the netfilter software and command iptables are used. Netfilter [32] is a set of hooks inside the linux kernel that enables packet filtering, network address(and port)

translation and other packet mangling. Iptables is a userspace command line program which is used to define packet filtering rules for netfilter. We also use them to

implement our RM&CAC and SIP signaling NAT traversal, because it can help to extract the SIP packets from the kernel. Below, we will describe how it works.

The iptables provides a kernel module, called queue handler, to perform the mechanics of passing packets out of the network stack and queueing them for the userspace programs. This provides a way for the userspace programs to monitor and process network packets. So, a userspace program can further choose to modify these captured packets before reinjecting them back to the network stack or drop them. The standard queue handler for IPv4 is the ip_queue module, which is distributed with the linux kernel. Once ip_queue is loaded, IP packets can be filtered and queued for userspace in the QUEUE target. QUEUE is a special target, which queues IP packets for userspace. The following is how we define the ruleset by iptables to realize NAPT

and queue SIP signaling packets for our userspace to carry out SIP signaling NAT traversal and RM&CAC.

1. # modprobe iptable_nat

2. # modprobe ip_queue

3. # /sbin/iptables –t nat –A POSTROUTING –s $INNET –o $EXTIF –j

MASQUERADE

4. # /sbin/iptables -t mangle –A FORWARD –p udp –dport 5060 –j QUEUE

5. # /sbin/iptables -t mangle –A INPUT –p udp –dport 5060 –j QUEUE

Line1 and Line2 are used to load the related iptables modules. Line3 is used to translate the ip address and port number between the inside MANET and the outside Internet, which carries out the NAPT. Line4 and Line5 are used to pass the SIP packets(default port for SIP is 5060) to the ip_queue module, which will then be processed by our SIP ALG and RM&CAC modules. To write an application layer program to handle the extracted packets in ip_queue, the Libipq library is required. It is a development library which provides APIs for userspace program to get and process queued packets in ip_queue. We use the libipq APIs to carry out our SIP signaling NAT traversal, RM&CAC, and SIP mobility. The included libraries and the APIs we used in our program are introduced in Appendix B. Figure 18 illustrates the software architecture in our SIP-MNG. In this figure, there are four main components:

Fig. 18 The software architecture of SIP-MNG

1) SIP UA handles all SIP signaling and SIP signaling NAT traversal; 2) RM&CAC manages the SIP-MNG’s external bandwidth and decides whether a new call shall be admitted or not; 3) SIP mobility is responsible for the mobility management of SIP sessions; 4) external link monitor is used to monitor the external link status. Below, we will describe each of them.

The SIP UA module is responsible for all incoming SIP signaling. Our SIP-MNG has two interfaces: One is the inside WLAN interface; the other is the external PHS interface. So, the SIP UA module will handle all SIP messages coming from the two interfaces. Fig. 19 illustrates how the SIP UA module handles SIP messages coming from the inside MANET. On receiving a SIP message, it first

2. Packets come from the inside

MANET

11. 404 Not found/

480 Temporarily not available

1XX

6. Forward to SIP server 20. Establish RTP

connection

Packets come from the outside Internet

15. Other Request 10. sipOpenSession

Calling Yes 9. RM&CAC

No 404 Not found

Fig. 19 The processing flow chart of the packets coming from the inside MANET

checks whether it is a SIP request or not(3). If it is a SIP request, the SIP UA module further checks if it is a SIP REGISTER message(4). If it is a SIP REGISTER, the SIP UA module will add the from SIP client into its SIP client table and translate it(5). If it is not a SIP REGISTER message, the SIP UA module will then check its client table(7). If the from SIP client is not in the table, the SIP UA module will drop the SIP message and respond the SIP client a 404 Not Found/480 Temporarily Not

Fig. 20 The processing flow chart of the packets coming from the outside internet

Available SIP message(11). If the from-SIP client exists and the SIP message is a SIP INVITE request(8), the SIP UA module will run RM&CAC module(9). If pass, then RM&CAC will create a new SIP session(10), and replace some SIP headers for NAT traversal and forward the INVITE message to the outside SIP server. On the other hand, if the incoming packet is a SIP response, the SIP UA module will check its SIP client table first(17). If the to-SIP client is in the table, it will find out which session the message responses(18). Then, if it is a 200 OK response(18), the SIP UA module

will use the following iptables command to establish the RTP connection(20) for the

will use the following iptables command to establish the RTP connection(20) for the