Push Mechanism

Because the power consumed by a wireless LAN interface occupies a great ratio on battery-operated devices, a lot of research has tried to reduce the energy

consumption by these devices. To conserve the energy used by a WLAN device, the power saving mode (PSM) defined in the IEEE 802.11 is widely employed[19], which switches a wireless interface into sleep mode when it is idle. However, instead of simply leaving the WLAN interface in the sleep mode, turning it off completely will reduce more power consumption. To do this, [20][21][22] propose the idea of using a secondary out-of-band low power interface to wake up the closed WLAN device only when needed, called push mechanism. In [21], a low power radio access interface is designed and added into the WLAN device. When there is no traffic, MHs can turn off the WLAN interface and listen to the messages from the low power radio. Once there are packets destined for disconnected MH, WLAN access points (APs) can inform the MH to activate its WLAN interface and receive these packets by sending

Fig. 6 Bi-directional tunneling of mobile router

messages to the low power radio. In [22], Feng et al. propose a push mechanism to activate the WLAN interface by sending a short message via cellular networks. In this approach, a cellular interface is equipped with a MH, which consumes much less power than the WLAN module, and is always on. When a SIP call request for the MH is received by the SIP server, a SPC(SIP-based push center) module in the SIP server will check if the MH is connected to wireless networks. If yes, the request is directly forwarded to the MH. Otherwise, the call is suspended, and the SPC will send a short

message to the MH to activate its WLAN interface. After the wireless connection is activated, the MH sends a message to inform the SPC. On receiving the message from the MH, the SIP server then delivers the suspend call request to the MH, and the standard SIP call setup procedure will be continued.

2.5 GSM Short Message Service(SMS) with IP Network

Global System for Mobile Communications (GSM) provides Short Message Service (SMS) which is a connectionless transfer of messages with low-capacity.

Figure 7 shows the GSM SMS network architecture. In this architecture, when a Mobile Station (MS) sends a short message, this message is delivered to the GSM radio system. The radio system then forwards the message to the Mobile Switching Center (MSC) called SMS Inter-Working MSC (IWMSC). It passes this message to a Short Message Service Center (SM-SC). The SM-SC then forwards the message to the destination GSM network through a specific GSM MSC called the SMS Gateway MSC (SMS GMSC). Then the SMS GMSC locates the serving MSC of the message receiver and forwards the message to that MSC. This MSC will broadcast the message to the BTSs. On receiving the message, the BTSs will page the destination

MS(receiver), and send the message to it. So far, the short message transmission completes.

Fig. 7 GSM SMS network architecture

GSM SMS and IP networks can be integrated through Short Message Service Center (SM-SC). Figure 8 shows the architecture of SMS-IP integration with SM-SC.

In this architecture, a special gateway must exist to associate the SM-SC to the IP network, where a specific protocol is essential for the communication between the SM-SC and the gateway.

Since both SM-SC and SMS-IP gateway are controlled by GSM operators, it is difficult for a third party to deploy new services via SMS. To address this issue, in [23], an endpoint SMS-IP integration solution, called iSMS, is proposed to provide an environment for quickly prototyping and hosting wireless data services. The iSMS system architecture is illustrated in figure 9. As shown in the figure, the iSMS gateway connects to an MS modem instead of SM-SC and consists of two parts. One is iSMS servers, which is responsible to provide services, the other is short message

Fig. 8 SMS-IP integration with SM-SC

driver, which interconnects the GSM network and the iSMS servers in the IP network.

The short message driver and the iSMS servers can be implemented in a single host or separated. In the later case, the short message driver and the iSMS servers

communicate with each other through TCP/IP protocol. When the short message driver receives an incoming short message from the MS modem, it will pass them to the specific iSMS server according to the service type requesting by the received short message. On receiving the outgoing message from an iSMS server, the driver will transform it into the short message format and then send it out to the GSM network via the MS modem. By using the above model, a user can make a request from the GSM network by sending a short message to the MS modem which is connected to the iSMS gateway. Upon the receipt of the short message, the iSMS gateway executes

model is transparent to telecommunication operators, in this thesis, we adopt it in our proposed push mechanism.

Fig. 9 iSMS system architecture

Chapter 3

System Architecture and Motivation

Fig. 10 shows our SIP-based mobile network architecture, which contains a mobile network subsystem and a SIP subsystem. The former is a SIP-based mobile

network connecting to the Internet. The latter includes some servers to support SIP-based networking services.

Central to the mobile network subsystem is a SIP-based mobile network gateway (SIP-MNG). It is equipped with one or multiple wireless interfaces (such as GSM, GPRS, PHS, 3G, WLAN, and WiMAX interfaces) that can dial up to the Internet and some IEEE 802.11 interfaces to connect to the internal MANET. In real applications, cellular interfaces may be applied in freeways, country areas, and trains, while WLAN and WiMAX interfaces may be applied in hot-spot and metropolitan areas. The

MANET consists of a set of mobile hosts (MHs), each equipped with an 802.11 interface configured at the ad hoc mode. Because real-time services are stringent in responsiveness, routing in the MANET is supported by a proactive protocol, such as DSDV [24] and CGSR [25], which will attempt to maintain consistent, up-to-date routing information at each host.

The SIP subsystem has four components: SIP registrar, SIP proxy, PSTN (Public

Fig. 10 System architecture

database containing users' subscription and status information. Users need to send their SIP registrar SIP REGISTER request messages to update their current locations periodically or when IP changes. The SIP proxy is responsible for routing SIP messages. The SIP registrar and SIP proxy are logical entities and are commonly implemented in a single host, called a SIP server. The PSTN gateway interconnects the Internet and the PSTN. So, with the PSTN gateway, SIP servers can set up/receive calls to/from the PSTN, respectively. The push server is to support our push

mechanism and can “wake up” the SIP-MNG when its wireless interfaces are

disconnected from the Internet. This can prevent incoming requests to the mobile network subsystem from loss.

Before presenting the detail system operations of our system, we first introduce our design motivations.

z Saving charges of Internet access: Table 1 shows the charge plans for different

types of wireless interfaces. The charge plans can be divided into three types: 1).

Charge by time; 2). Flat rate; and 3). Charge by packet. Clearly, for charge plans 1) and 2), accessing the Internet for a group of users in a vehicle through a few wireless interfaces can save a great deal of charges for individuals. For plan 3), operators can save wireless resources.

Charge Plans Type of Interfaces

By time Flat rate By packet

GPRS √

3G √ √

PHS √ √

IEEE 802.11 √ √

WiMAX √ √

Table 1 Charge plans for different types of wireless interfaces

z QoS guarantee: For realtime and multimedia sessions, QoS has to be guaranteed.

designed with CAC and RM mechanisms to guarantee the QoS of a real time or

multimedia applications.

z Push mechanism to save charges, power consumption, and wireless

resources: Considering that the current battery technology for cell phones can

operate 2~5 hours when in active mode, but 5~14 days when in standby mode, it is desirable to disconnect the cellular interfaces of SIP-MNG to save power consumption when no Internet activity exists. Also, this can save charges for plans 1) and 3), too. Moreover, SIP-MNG does not need to collect network advertisements to maintain global reachability. Via SIP session control and SMS, we design a push mechanism to allow the wireless interfaces to stay off-line

when there is no Internet connection and to be “woken up” when necessary.

z An added service for public transportation operators: The public

transportation operators can use our system as an added service to attract customers. In addition, adding management functions (such as accounting)

becomes easy via SIP-MNG.

z Backward compatibility: Our goal is to serve the existing SIP clients without

modification. So, we design our system by adding some new servers that can work transparent to existing SIP clients.

z Reducing handoffs: When a vehicle moves from one BS to another, BSs have to

handle a large number of handoff events if host mobility is used. With our architecture, BSs only have to handle the mobility of the SIP-MNG, thus

significantly reducing BSs’ load.

z Saving the power consumption of MHs: Since a MH connects to the Internet

via the central SIP-MNG, it’s power consumption is significantly reduced.

z Decreasing the complexity of MHs: Since handoff events are handled by the

SIP-MNG, MHs do not have to do movement detection and location update. The design of MHs is simplified. This is also known as movement transparency.

Chapter 4

Basic Operations of the SIP-Based Mobile Network

In this section, we discuss the basic network operations in our system. Since the MANET is considered a private network, to provide Internet access, the SIP-MNG serves as a NAT (Network Address Translation) server for MHs and is responsible for the translation of SIP messages. To achieve the NAT traversal for SIP, techniques such as ALG (Application Layer Gateway) [26], STUN (Simple Traversal of UDP Through NATs) [27], and ICE (Interactive Connectivity Establishment) [28] have been proposed. Here we adopt the ALG scheme in our SIP-MNG. Below, we will discuss the entrance and session establishment procedures and CAC, RM, and handoff mechanisms.

4.1 MH Joining the Mobile Network

When a mobile device moves into a vehicle with the proposed SIP-based mobile networking services, its IEEE 802.11 interface will detect the existence of the network.

After attaching to the mobile network, the MH will get a new IP address from the SIP-MNG. With this address, the MH can actively send a SIP REGISTER message to its SIP server to update its contact information. The REGISTER message will trigger

the SIP-MNG to serve as a representative of the MH. Fig. 11 shows the detail procedure of the SIP registration. In this scenario, we assume the MH UA-A gets an IP address 192.168.0.1 from the SIP-MNG, and its SIP URL is

sip:[email protected]. Addresses of the SIP-MNG and UA-A's SIP server are SIP-MNG.NEMO.com and SIPsvr-A.mobile.com, respectively. In the registration procedure, UA-A first sends a SIP REGISTER message to its SIP server with Via and Contact fields equal to 192.168.0.1 and sip:[email protected], respectively. Since the SIP-MNG monitors and translates all SIP messages to/from the Internet, it will capture the REGISTER message. On intercepting the message, the SIP-MNG will record UA-A's affiliation by adding UA-A's information into a SIP client table and relay the message by translating the Via and Contact fields into

SIP-MNG.NEMO.com and sip:[email protected], respectively. On receiving the SIP REGISTER message, the UA-A's SIP server will update UA-A's information and then reply a SIP 200 OK message. Since the Via field in the REGISTER request is translated into the SIP-MNG's address, the 200 OK message will be forwarded to the SIP-MNG. Also, with the SIP-MNG's address as the contact address, UA-A's SIP server can later forward SIP request messages destined for UA-A to the SIP-MNG, which will then relay them to UA-A. Upon the receipt of the 200 OK message from UA-A's SIP server, the SIP-MNG will translate the Via and

Contact fields back to UA-A's address and relay the SIP response to UA-A. Then, the SIP registration procedure is completed.

4.2 Session Setup Procedure and CAC and RM Mechanisms

In this subsection, we present how a session is established between a MH in the MANET and an external CN (Corresponding Node). We also discuss how our SIP-MNG supports CAC and RM. Recall that a SIP-MNG has one or more external interfaces. An interface is active if it has been dialed up to the Internet; otherwise, it is idle. RM is responsible for evaluating the required bandwidth of a requested session

and assigning a serving external interface for the session. The required bandwidth can be estimated by the SDP (Session Description Protocol) [14] provided in the SIP signal. If any active wireless interface has sufficient spare resource, RM will assign it to the session. Otherwise, RM will activate a new wireless interface to serve the session. If all wireless interfaces are full, CAC will drop the SIP signal and reject the request.

Here we use a voice call request as an example to describe the detail message flow of session setup, CAC, and RM. Fig. 12 depicts the message flow, with some SIP headers omitted for simplicity. We assume that UA-A's IP address and SIP URL are 192.168.0.1 and sip:[email protected], respectively. CN's IP address and

Fig. 11 The SIP registration procedure in the SIP-based mobile network

SIP URL are 140.113.216.112 and sip:[email protected], respectively. For simplicity, UA-A and CN use the same SIP server, whose address is

SIPsvr.mobile.com. The SIP-MNG's address is SIP-MNG.NEMO.com. The corresponding call setup steps when UA-A calls CN are as follows.

1. UA-A sends a SIP INVITE message to the SIP server to invite the CN. c

(Connection Information) and m (Media description) fields in the sdp include the connection address and port information, respectively(by which UA-A can receive

Fig. 12 The message flow to set up a session

session; so RM can tell that this is an realtime/multimedia session.

2. When intercepting the SIP INVITE message, the SIP-MNG will initiate the CAC and RM procedures. CAC will accept the requested session if RM returns ok, and reject the session otherwise. RM includes three steps: 1) evaluate the required bandwidth; 2) allocate a wireless interface for the session if there is enough

bandwidth; and 3) return the status ok/failure to CAC. Since the codec information can be derived from the m field (18 = G.729, 3 = GSM, and 0 = G.711 mu-law) and the default packetization interval (PI) is 20 ms, the required bandwidth can be predicted. If there is no resource, the SIP-MNG will drop the SIP INVITE message and respond a SIP 480 “Temporarily not available” message to UA-A. Otherwise, the session will be recorded into a session table and relay this message to the SIP server after translation. Since the sdp provides multiple candidate codecs for the session, RM will preserve the maximum required bandwidth for the session. For non audio/video sessions (which will be described in field m), the SIP-MNG will reserve one or few wireless interfaces dedicated to these types of sessions. For such best-effort sessions, RM will skip the resource evaluation step and directly allocate an interface for it.

3. Then fields Via, Contact, c, and m fields of the SIP INVITE message are translated. In this example, the (connection address):(port) is translated from 192.168.0.1:9000 to 140.113.24.210:45678.

4. On receiving the SIP INVITE message, the SIP server forwards it to the CN, which will register the caller’s address as 140.113.216.112.

5. The CN then replies with a SIP 200 OK message, where it chooses G.729 as the final codec to communicate with UA-A. According to the Via header in the

received SIP INVITE message, this 200 OK message will be sent back to the SIP server at SIPsvr.mobile.com.

6. Upon the receipt of the 200 OK message, the SIP server forward it to address SIP-MNG.NEMO.com.

7. When the SIP-MNG receives the 200 OK message, RM will update the session table according to the final media information. Then, the SIP-MNG translates the 200 OK message and relays it to UA-A.

8. UA-A feedbacks SIP ACK message to the CN directly according to the Contact information in the received 200 OK message.

9. The SIP-MNG relays the SIP ACK message to the CN after translating the Via header. Then the call is established.

4.3 Handoff Procedure

As the vehicle moves, an external interface may change its network domain and the SIP-MNG may change its active interface. In both cases, a handoff happens. The SIP-MNG must recover sessions on these handoff interfaces by sending re-INVITE messages and maintain the global reachability of all MHs in the MANET by sending

Fig. 13 The message flow of the wireless interface network handoff

re-REGISTER messages. Since recovering on-going sessions is more urgent, it will be done first. Below, we outline the detail steps (refer to Fig. 13).

1. According to the SIP_client_table and the session table, the SIP-MNG retrieves the endpoint MHs and CNs of the on-going sessions on each handoff interface.

2. The SIP-MNG then sends each CN a SIP INVITE message to re-invite it.

3. A CN, on receiving the SIP INVITE message, will register the new contact

4. On receiving the 200 OK messages, the SIP-MNG will update the session table and reply the corresponding CN a SIP ACK message. Then, the session between the CN and the MH can be continued.

5. After recovering all handoff sessions, the SIP-MNG will send a SIP REGISTER message for each MH that has changed to a new external interface to update its contact address.

6. When a SIP server receives the above SIP REGISTER message, it will update the corresponding MH's data and reply a SIP 200 OK message. After this, all MHs are guaranteed to be reachable from outside.

4.4 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

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