To evaluate our fast handoff mechanism, we have implemented it by using open source code projects on the Linux platform. We implemented our stealthy channel scanning algorithm for the HostAP driver which is a Linux driver for wireless LAN cards based on Intersil’s Prism2/2.5/3 802.11b chipset. We extended the SIP proxy, SIP Express Router, to support the operation of the mobility server and modified the SIP user agent, KPhone, to query the mobility server for system channel map and IP address pre-assignment. The message flows of our fast handoff mechanism are described below.
4.1 Download System Channel Map
In order to generate the system channel map for an MS, the mobility server must know the current associated access point of the MS. Note that RFC 3455 defines Private Header Extensions to the Session Initiation Protocol for the 3rd-Generation Partnership Project. One extension introduces the P-Access-Network-Info header that a SIP user agent can use to relay information about the access technology to proxies that are providing services.
Fingure 10 depicts the message flow where a SIP UA, UA1, downloads the system channel map.
1. UA1 associates with an access point, AP1.
2. UA1 registers to the mobility server with AP1 specified in the P-Access-Network-Info field of SIP REGISTER message.
3-4. If UA1 has not ever registered, the mobility server acts as a normal SIP proxy and forwards the registration toUA1’s home proxy/registrar.
5-6. The mobility server queries the database (Channel Map) about the neighbor APs of AP1.
7. The mobility server returns a 200 OK with the neighbor APs’ information in the system channel map to UA1.
Figure 10: Download System Channel Map Flow
4.2 Call Setup Flow
When a mobile station initiates a call, it must ensure that the SIP-INVITE request traverses the mobility server (outbound proxy) so that the fast handoff mechanism can be activated. After that, it is the mobility server’s duty to interact with the RTP relay agent for the operations of fast handoff. The mobility server also functions as a SIP ALG and modifies SDP messages to ensure that a RTP stream will traverse through the RTP relay agent.
Fingure 11 depicts the message flow where UA1 makes a call to UA2.
1. UA1 sends a SIP INVITE request to the mobility server.
2-4. The mobility server requests the RTP relay agent to open a port for the RTP stream and maintain the dialog state for UA1.
5. The mobility server (SIP ALG) modifies SDP of SIP-INVITE request to ensure that the RTP stream will traverse through the RTP relay agent, and routes the modified SIP-INVITE request to UA2.
6. UA2 accepts the call and returns a SIP-200 OK response.
7-9. The mobility server queries the RTP relay agent about the opened port for this dialog, and requests the RTP relay agent to maintain the dialog state for UA2.
10. The mobility server (SIP ALG) also modifies SDP of SIP-200 OK response to ensure that the RTP stream will traverse through the RTP relay agent, and routes the modified SIP-200 OK response to UA1.
11-12. UA1 returns a SIP-ACK through the mobility server to UA2, and the conversation between UA1 and UA2 begins.
Figure 11: Call Setup Flow
4.3 The Intra-subnet Handoff
Fingure 12 depicts the message flow where UA1 hands off to AP2, which located in the same subnetwork as the current associated AP, during an on-going conversation with UA2.
1. When UA1 is moving away from its attached AP, the radio signal strength from the AP is decreasing. And at some point, according to stealthy channel scanning algorithm, UA1 starts to perform selective active channel on a designated channel chosen from the system channel map (called the stage one of two stage handoff procedure).
2. If UA1 is further moving away, the notification from the driver triggers a handoff action (called the stage two of two stage handoff procedure). Then, UA1 decides a target AP according to stealthy scanning results.
3. Supposes that UA1 decides a target AP called AP2, and AP2 locates in the same subnetwork of UA1; then UA1 directly associates with it.
4. After successful handoff, UA1 should send a new SIP-REGISTER request to refresh the system channel map.
Figure 12: Handoff Scenario One, Intra-subnet Handoff
4.4 The Inter-subnet Handoff
Fingure 13 depicts the message flow where UA1 hands off to AP3, which located in the subnetwork different than the current associated AP, during an on-going conversation with UA2.
1-2. These two steps are the same as indicated in Section 4.3.
3. UA1 sends a SIP-MESSAGE request to apply the mobility server for allocating the network-layer resources, including the IP address and default gateway.
4-5. The mobility server reserves the network-layer resources from the database, Channel Map.
6-7. The mobility server requests the RTP relay agent to fork the RTP stream for UA1 to the new IP address of UA1.
8. The mobility server returns UA1 with the reserved network-layer resources.
9-10. UA1 configures dual network-layer settings at the same time, and associates with AP3.
11. UA1 refreshes the system channel map, and releases its old network-layer setting.
12-13. The mobility server requests the RTP relay agent to stop forking the RTP stream for UA1.
Figure 13: Handoff Scenario Two, Inter-subnet Handoff