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. 3.1). 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.

The push mechanism has also been used in other applications. In GPRS networks, an MS must activate a PDP context before the corresponding service can be used. However, maintaining a PDP context without actually using it will consume network resources.

So, short messages are used in [36] to activate a PDP context on-the-fly. For a dual-mode handset (with a cellular and a WLAN interfaces, for instance), to reduce energy consumption, it is desirable to disable the handset’s WLAN module when it is not used.

However, this will prevent the handset from receiving incoming VoIP calls from the WLAN interface. To solve this problem, reference [35] uses a paging mechanism via the cellular interface to inform the handset to activate its WLAN module. Then the VoIP call can be connected via the relatively inexpensive WLAN. However, both [36, 35] involve some modifications on SIP components and end devices to support such functions, which is undesirable. In addition, because of the overhead to go through the push procedure, both approaches may suffer from the timeout problem if the callee’s response time exceeds a predefined threshold. In our architecture, the standard protocols in SIP servers and SIP

MSs

IP addr: SIP-MNG.NEMO.com mobile network subsystem

(H1) SLEEP

(H2) OK SIP servers of inside MSs

(H3) UNREGISTER

(H4) 200 OK

Push server

(H5) REGISTER

(H6) 200 OK

Figure 3.5: Sleep procedure.

clients are unchanged. Also, with an external server and SIP call control feature, our approach can effectively relieve the timeout problem.

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. 3.5 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 MSs 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 MS and includes three fields: SIP URI, SIP-MNG id, and registration 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 MSs served by

UA2

IP addr: SIP-MNG.NEMO.com mobile network

subsystem

SIP servers of inside MSs and UA1

(F8) REGISTER

(F9) 200 OK

Push server

UA1

(F1) INVITE (F2) INVITE (F3) WAKEUP

(F4) 200 OK (F5) 200 OK

(F6) ACK (F7) ACK

(F10) OK

Figure 3.6: Wake-up process.

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 MSs 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.

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.

• Wake-Up Process

Fig. 3.6 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 address of the push server to inform the SIP-MNG to reconnect to the

UA2

SIP-MNG mobile network subsystem

SIP servers of inside MSs and UA1

(F23) UNREGISTER

(F24) 200 OK Push server

UA1

(F12) 202 Accepted (F11) REFER Refer-To: UA2

(F17) INVITE Referred-By: Push server

(F17) INVITE Referred-By: Push server

(F18) 180 Ringing

(F13) NOTIFY (F14) 200 OK

(F16) 200 OK (F15) BYE

(F18) 180 Ringing (F19) 200 OK

(F19) 200 OK (F20) ACK

(F20) ACK (F21) NOTIFY

(F22) 200 OK

Figure 3.7: Session transfer process.

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 MSs 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).

• Session Transfer Process

Next, the session needs to be transferred from the push server to UA2. Fig. 3.7 depicts the message flow. The process is based on the REFER method [58] proposed by IETF to support session mobility. We comment that IETF also proposes an alternative third-party call control (3pcc) [54]. 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 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 sig-nalings 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 MS may simply leave the network without giving any notification. We have discussed some timeout mechanisms to determine a MS’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 MS 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.

3.2 A Cross-Layer Resource Management Mechanism for Mo-bile Broadband Networks

User mobility and physical rate adaptation are two important factors concerning real-time application-over-wireless network services. With user mobility, handoff between BSs/APs is inevitable. Failure to reserve sufficient bandwidths for handoff sessions may force them being dropped. Dropping on-going sessions has a very negative impact from users’ per-spective. While resource reservation for handoff calls is necessary, maintaining fairness among handoff calls and existing calls within a wireless network is also important. On the other hand, today’s wireless transmission support multiple transmission rates to adapt to physical channel conditions. However, to keep the same level of QoS, using a lower trans-mission rate means that more wireless resource has to be allocated to that mobile station.

Failure to reserve the required resources for roaming stations would degrade their QoS.

It is a challenge to guarantee the QoS of real-time applications over a multi-rate wireless networks concerning user mobility and rate adaptation. Fortunately, today’s wireless net-work protocols all support QoS mechanisms in the MAC layer. In this part, we show how to design a cross-layer resource management mechanism by integrating the application layer and the QoS mechanisms of wireless networks to support handoff and multi-grade QoS for real-time applications over multi-rate wireless networks. In the following, we focus on VoIP (voice over IP) and QoS mechanisms in IEEE 802.11e to design such a cross-layer mechanism. For other types of real-time applications and wireless network protocols, we believe similar technology can be applied.

We consider an IEEE 802.11e wireless network operating in the infrastructure mode to support VoIP applications. Although IEEE 802.11e supports QoS, the resource reserva-tion and handoff handling issues for particular applicareserva-tions are left open to designers. In this work, we consider using SIP signaling to support VoIP over IEEE 802.11e networks.

We propose a cross-layer resource management mechanism to solve the problems caused by handoff and rate adaptation, which includes a call admission control (CAC) algorithm and a resource adjustment (RA) algorithm. The CAC algorithm is performed whenever a new call or a handoff call arrives at a QAP (Quality of Service Access Point).

The CAC algorithm accepts or rejects an arriving call according to the amount of available resources versus the QoS requirements of the call. The purpose of the RA algorithmis to dynamically change bandwidth allocation among on-going calls in a QAP for better re-source utilization and fairness. This is feasible because multimedia services can typically operate under different bandwidths.

In order to dynamically adjust resource allocation, we assume that VoIP calls can be supported by multiple levels of QoS. Each QoS level corresponds to a voice codec and a

PI, where PI is the period that voice data is encapsulated into packets for transmission.

For most current systems, the default PI is 20 ms. Larger PIs would introduce less header overhead, but may suffer from higher delays and are more sensitive to packet loss. Given a PI and a data generation rate of λ, the amount of data to be transmitted per PI is (λ × P I + h), where h is the header overhead. Therefore, the bandwidth required per time unit is (λ × P I + h)/P I = λ + h/P I. Clearly, a larger PI will incur less traffic.

Suppose that for each codec there are k QoS levels and each QoS level corresponds to a PI. Note when a call changes from a PI to another P I⁰, the difference of resource usage is (λ − h/P I⁰) − (λ − h/P I) = h(1/P I⁰ − 1/P I). This value is only dependent of PI and P I⁰, but is independent of λ (and thus independent of which codec is used).

Therefore, the system state of a QAP can be denoted as s = (s₁, s₂, s₃, ..., s_k), where s_i is the number of calls served at the ith level (these calls may use different codecs). The following terminologies will be used in our CAC and RA algorithms.

• B_total: the total bandwidth of a QAP.

• B_th: the threshold of occupied bandwidth (below which new calls can be accepted).

• B_{f ree}: the current free bandwidth of the QAP.

• B_deg: the maximum available free bandwidth of the QAP after degrading all existing calls to the lowest QoS level.

• P I_def: the default PI for all new calls.

• W_alloc: the bandwidth allocated to the request call.