Supporting Dynamic IP Addresses for Wireless Push Services in Cellular Networks

Transcription

1 Supporting Dynamic IP Addresses for Wireless Push Services in Cellular Networks Timucin Ozugur ALCATEL Research & Innovation Center, 1000 Coit Rd., M/S CT02, Plano, TX, USA tim.ozugur@alcatel.com, Work: , Fax: Abstract This paper details the wireless location-aware and content aware push application delivery over the packet-switched wireless core network. The directory server, which is deployed besides the WAP server in order to support the push applications by storing the user profile, IMSI and user IP address, requires static IP addressing to support such 3G applications. For each incoming IP packet, the is capable of establishing a GTP tunnel to the serving SGSN using the network-requested PDP context activation procedure for the static IP users due to their static IP entries at the HLR. However, the incoming IP packets destined for dynamic IP users are discarded at the level. This paper introduces a methodology to provide push services to dynamic IP addressed-mobile users in 2.5G/3G networks, and minimize the unsuccessful-network-requested PDP Context Activation for static IP users. The proposed method is based on the Protection and Mobile User Activity procedures, SMS service, and a new signaling mechanism to forward the HLR-based flags to the WAP/Directory server. 1. Introduction The number of mobile devices, such as pagers, notebooks, smart cellular telephones and personal organizers, has increased tremendously, due to the great improvement in the technology with respect to size, speed and weight. An infrastructure of protocols is required to link these different mobile devices to Internet such that they would be able to exchange data as well as voice, [1, 2]. The Internet is already driving wireline network growth today; however, there are significant network architecture issues when it comes to delivering data over wireless networks. The most widely deployed standard for second-generation mobile radio networks is the Global System for Mobile Communications (GSM). Cellular Networks based on this standard are extended in the near future with the General Packet Radio Service (GPRS), which is referred to as 2.5 G technology, [5]. The core packet domain of the Universal Mobile Telecommunication System (UMTS), which is referred to as 3G technology, will evolve from the GPRS, [6]. In this paper, we focus on the data delivery over the packet core domain of GPRS and UMTS networks. The evolution of the wireless infrastructure from GSM to GPRS and UMTS networks realizes the wireless data delivery over the packet-switched core network, [1, 3-5]. In the packet-switched data delivery, the mobile user is assigned either static or dynamic IP address to use any 3G applications, such as location-aware and content-aware smart-push applications, where a push server periodically sends some user specific information, such as stock market watch, or weather forecast. In general cases, the mobile user registers its user information, such as IP addresses, mobile devices and application type, in order to receive the push data. The information registration may be provided by Wireless Application Protocol (WAP)/Directory server. When WAP/Directory server attempts to connect the mobile node over wireless packet core domain to deliver push data, the packet core network requires static IP addressing for the mobile user for the delivery. Due to the limited addressing in IPv4, many mobile users generally are assigned dynamic IP addresses using Dynamic Host Configuration Protocol (DHCP). In this case, dynamic IP users are not able to register for the push data services. The reason is due to not having any IP address entry at the Home Location Register (HLR) for the dynamic IP users, [5]. These users may still receive the data over the circuited-switched domain, [2, 10]. However, the circuit-switched data is limited by the low data rates, which is 9.6 kbps. The main goal of this paper is to propose a methodology to provide push services over the packet-switched wireless core network for dynamic IP addressed-mobile users in GPRS/UMTS networks. The proposed methodology is based the Protection and Mobile User Activity procedures, Short Messaging Service (SMS) service, and a new signaling mechanism to forward the HLR-based flags to the WAP/Directory server. The outline of the paper is as follows: Section 2 summarizes the standard procedures that the wireless network should employ to support the mobile data delivery. Section 3 describes 3G wireless push applications. WAP/Directory server is detailed to support the wireless push applications. Wireless push delivery failures are also investigated for the WAP/Directory server. In Section 4, a methodology is proposed to support dynamic IP addressed-mobile users to access the push services. The proposed methodology is referred to as WAP/SMSrequested PDP Context Activation Procedure. In Section 5, simulation results are given. Section 6 concludes the paper. 2. Wireless Data Delivery This section summarizes the wireless data delivery procedures that the mobile station (MS) performs to transmit data through the Packet-Switched Domain. In order to deliver packet data in GPRS/EDGE and UMTS networks, the mobile station (MS) performs two necessary procedures: GPRS Attach and Packet Data Protocol (PDP) context activation procedures.

2 A GPRS Attach is made to the SGSN when the MS turns the phone on in GPRS mode. In this procedure, the MS provides its International Mobile Subscriber Identity (IMSI), and the attach type. The GPRS Attach procedure is basically establishment of Logical Link Control (LLC) layer between the MS and the Serving GPRS Service Node (SGSN). The SGSN performs mobility management, session management, and authentication procedures for data users. This LLC connection between MS and SGSN is an IMSI-based connection. It stays alive even when the MS is not on a traffic channel. Note that Gateway GPSR Service Node () is not aware of whether the MS is GPRS-attached. After attaching to the SGSN, the MS connects to the using the Packet Data Protocol (PDP) Context Activation procedure in order to transmit or receive data. The provides the point of interconnection with external packet data networks for mobile network supporting GPRS. The stores routing information for attached GPRS users. By using the PDP context activation, a GPRS Tunneling Protocol (GTP) tunnel is established between SGSN and in GPRS networks or between Radio Network Controller (RNC - providing control of the multiple radio resources) and through SGSN in UMTS networks, respectively. The GTP tunnels user data and signaling messages between SGSNs and s in the GPRS backbone network. The PDP context activation may be achieved in two different ways: (1) Mobile-Initiated, (2) Network-Requested PDP Context Activation. If an MS initiates the PDP context activation at any time after attaching to the SGSN in order to transmit packet data, it is referred to as Mobile-Initiated PDP Context Activation. After data transmission session, the assigned-gtp tunnel is aborted, and the MS returns to the GPRS-Attached mode. The MS is not continuously assigned a GTP tunnel during its GPRS-Attached mode due to the fact that the PS Domain supports only limited number of simultaneous GTP tunnels. The network-requested PDP context activation procedure is used to establish the GTP tunnel only for the MS using static PDP addressing. In this procedure, the initiates the PDP context activation when the receives packet data destined to a static PDP-addressed MS. In the case of dynamic PDP addressing, is not able to perform the network-requested procedure due to the fact that HLR does not have any entry for the dynamic PDP users. In order to prevent unnecessary data delivery inquires to the HLR from during the network-requested PDP context activation, following techniques are implemented: Implementation of the Mobile-Station-Not-Reach-able for GPRS (MNRG) flag in, SGSN, and HLR and Mobile station-not-reachable Flag (MNRF). If the MS is GPRS-detached, the SGSN,, and HLR perform Protection and Mobile User Activity procedures. The MNRG flag is stored in the HLR, and Short Message Service-Center (SMS-C), SMS-Gateway MSC (SMS- GMSC). The MNRG is raised according to the Protection procedure. The Protection procedure raises the MRNG flag in certain components if the PDP context activation has failed, [5]. In order to clear the MNRG flag, the Mobile User Activity procedure is performed, [5]. According to the procedure, the MNRG is cleared at the SGSN, and HLR if the SGSN receives an indication that the MS is reachable. The MNRF flag is stored the MSC/VLR, HLR and SMS-C. The MNRF flag indicates that the MS is not reachable by any means. VLR sets the MNRF if the transmission or SMS service attempts fail. In the next section, we detail the 3G push applications. We also describe the shortcomings of the current technologies. We then propose a new PDP activation procedure using the MNRG and MNRF flags at the WAP/Directory server. 3. Wireless Push Applications In order to support 3G push applications, such as locationaware services and content-aware services, Wireless Application Protocol (WAP)/Directory server bridges the IP-based wireless core network to Internet. The WAP/Directory server stores the MS profile to personalize the Internet applications. The server consists of few servers and managers. The servers resides in the WAP/Directory server are a WAP push proxy gateway, which converts XML contents to HTTP or vice versa, a WAP Application Server, which acts as the proxy web server, a Location Server and Manager, which interacts with HLR to get location information subscribers, and finally a Directory, which is the repository of subscriber s profile and other information. The WAP/Directory requires the static PDP addresses for the users to connect the. In the case of static IP addressing, initiates a network-requested PDP context activation if the PDP Context Activation is not available. In the successful case, the GTP tunnel is established between the SGSN and, and the data is delivered to the MS. After the successful data transmission, the tunnel is deleted by the PDP context deactivation procedure. WAP Push Proxy Server does not know whether the MS is not reachable through SGSN or not. It tries to deliver the context through the by network-initiated PDP context activation until it fails. Successful push data delivery through the WAP/Directory and GPRS networks is illustrated in Figure 1. Standards do not support network-initiated PDP context activation for dynamic IP addresses. The reason is that dynamic IP address is not store in the HLR, and push data is rejected at the. As a result, the WAP/Directory cannot deliver push services to the dynamic IP addressed users. In current systems, service providers need to assign static IP addresses to the MS, which register for push services. However, static IP addresses are limited for IPv Wireless Push Failures The delivery of push data through the WAP/Directory server may fail in several. As mentioned above, the networkrequested PDP context activation is not supported for dynamic IP addresses. One solution for dynamic IP addressed user is to keep a GTP tunnel for a long period. However, this is not feasible since the number of GTPs is very limited in the core network. Therefore, an MS establishes the tunnel, and transmits its data. At the end of the transmission, the GTP 2

3 tunnel is discarded. However, the MS may stay in the GPRSattached mode. Assume that the MS who is a dynamic IP user is in the GPRS-attached mode, but there is not tunnel established between the SGSN and. Figure 2 illustrates the scenario, where the WAP/Directory server has push data for the MS. In this case, since the WAP/Directory is not aware of the situation, it sends the push data to the. The checks the source IP address of the MS from the HLR. Since the HLR does not have any entry for the user, the discards the push data. In this case, although the MS is capable of receiving the data due to its GPRS-attached mode, the delivery of the push data is unsuccessful. In the dynamic IP addressing, push data may be delivered as a circuit-switched data over the CS domain using the Push Over-The-Air protocol. However, the circuit-switched data is limited by the low data rates. If the MS is GPRS-detached or IMSI is unknown to the SGSN, fails to activate the PDP Context using network-requested procedure. The may refuse any PDP PDU for that PDP address for a specific period. If the WAP/Directory server is not aware of the GPRS-detached procedure or raised MNRG flag, it will send the push data to the for each transmission attempt before trying the alternatives if there is any specified. Therefore, it will reduce the capacity. Figure 4 illustrates the static IP user who is in the GPRSdetached mode and/or IMSI is unknown to the SGSN. In this case, contacts the HLR for the SGSN information. If the MNRG flag is raised, or the MS is out-of-sgsn coverage area and it haven t performed any routing area update, the cannot activate the GTP tunnel by the networkrequested PDP context activation procedure. The discards the incoming push data packets for this specific MS until it clears the MNRG flag in the HLR and by performing a GPRS-attached and routing update procedures. In the next section, we propose a new PDP context activation procedure to support push application for the dynamic IP users, which is referred to as WAP/SMS-Requested PDP Context Activation, which collaborates with a forwarding mechanism, which passes mobile-reachable flags to the WAP/Directory server. WAP/Directory initiates the procedure according to the status of the flags. PDP Context Activation request is encapsulated into the SMS message, and is forwarded to the MS. 4. WAP/SMS Requested PDP Context Activation In this section, we propose a WAP/SMS-requested PDP context activation procedure, where the WAP PPG requests for the PDP context activation through the SMS-Center (SMS-C) if the MS is GPRS-reachable. If the PDP context activation is not possible due to raised MNRG flag, the WAP PPG requests it through the circuit-switched domain, namely through SMS-C, SMS-Gateway MSC (SMS-GMSC), and MSC. Briefly, the WAP/SMS-requested PDP context activation uses GSM core network to establish the GTP tunnel, and the GPRS core network to send the push data. Figure 2 shows the difference of the proposed method from the WAP push mechanism. In order to guarantee delivery, the WAP/Directory server needs to know whether the MS is GPRS-attached, or IMSIattached, or both. As described in Section 3.3, the MNRG and MNRF are used to reduce the excess transmission attempts to the unreachable users. The MNRG and MNRF flags are stored in MSC/VLR, SGSN,, HLR, SMS-GMSC and SMS-C components. We propose that these components pass the MNRF and MNRG flags to the WAP/Directory server. In the following sections, we detail the signaling interfaces for the forwarding mechanism to pass the flags to the WAP/Directory server, and bearer interfaces to activate the PDP context using the WAP/SMS-requested PDP context activation procedure. 4.1 WAP/SMS Signaling Interfaces This section introduces the proposed signaling interfaces, which will be used by the MSC, or SMS-C nodes to update the flags at the WAP/ Directory server. The MNRG and MNRF flags are set according to the Protection and Mobile User Activity procedures as described in Section When the MNRG or MNRF flag is set, it should be forwarded to the WAP/Directory server. The signaling interfaces for the forwarding mechanism are given in Figure 5. The forwarding mechanism uses one of the three signaling interfaces: SGSN Initiated Interface If SGSN sets the MNRG to indicate the need of reporting to the HLR when the next contact with that MS is performed, SGSN forwards the MNRG to HLR and. should pass the MNRG to the WAP PPG through the signaling interface (5) in Figure 5. HLR Initiated Interface The MNRF is mandatory for MSC/VLR, and if it is set, the MSC forwards it to the HLR. The HLR should pass it to the WAP/Directory server through the signaling interface (4) in Figure 5. SMS-C Initiated Interface The MNRG and MNRF may also be set in the SMS-C if the MNRG or MNRF flags are raised during the SMS transfer. SMS-C forwards the flag information to the WAP/Directory server through the signaling interface (6) in Figure 5. When SGSN receives an indication that an MS is reachable again and the MNRG for this MS has been set, SGSN clears the MNRG for this MS at HLR and. should clear the MNRG at the WAP/Directory server GPRS Deactivation In order to employ the WAP/SMS-requested PDP Context Activation procedure, the GPRS deactivation procedure should also be modified. According to the UMTS standards, the PDP context deactivation can be achieved in three ways: Mobile-initiated PDP context deactivation, SGSN-initiated PDP context deactivation, -initiated PDP context deactivation. 3

4 The PDP context deactivation procedures, which abort the GTP tunnel between the SGSN and, are given in Figure 6. Using the deactivation procedure, SGSN releases the resources that have been held for this specific tunnel. In all three deactivation cases, should forward this deactivation information to the WAP/Directory server as shown in Figure 6. By this way, the WAP/Directory server is aware of that the GTP tunnel is not existed for this specific user; however, the mobile user may still be GPRS-reachable. The GPRS-reachable status of this user changes if the MNRG is also raised. 4.2 WAP/SMS Push Data Interfaces This section summarizes the WAP/SMS push bearer data interfaces to transmit the push data to the mobile using the WAP/SMS-requested PDP Context Activation. The smartpush bearer interfaces are grouped into two categories: (1) Dynamic PDP Addressing, (2) Static PDP Addressing Dynamic PDP Addressing In the case of dynamic PDP addressing, the push data delivery is possible if and only if PDP Context is already activated. The bearer interfaces for push applications are given in the following: Presence of PDP Context Activation: Push data is delivered through regular path, namely bearer data interface (3) in Figure 5. Non-presence of PDP Context Activation: The WAP/ Directory server should know the PDP Context status in order not to contact since cannot activate the PDP context for the dynamic IP addressing. Therefore, we propose that the should inform the WAP/Directory server during PDP context deactivation procedure as shown in Figure 6. Data delivery in this case has two sub-cases based on the status of MNRG and MNRF flags in the WAP/Directory server: (i) MNRG flag is not set, (ii) MNRG Flag is set, but MNRF Flag is not set. (1) MNRG Flag is not set This case represents that the mobile is in GPRS-attached mode, but the GTP tunnel is not existed due to PDP context deactivation. The WAP/ Directory server transmits a short message through SMS-C following the bearer data interface (2) in Figure 5, passing through SMS-IWMSC and SGSN asking MS to initiate PDP Context Activation in order to deliver the push data. Hence, the MS initiates the PDP context activation to receive its dynamic IP address from the. After the IP address is assigned to the MS, the WAP/ Directory server transmits the push data to the MS through the established GTP tunnel between and SGSN. This procedure is referred as WAP/SMS-requested PDP context activation. (2) MNRG Flag is set, but MNRF Flag is not set If the SMS procedure fails through the SGSN, MNRG flag is raised for the SGSN, HLR and SMS-C, SMS- GMSC attempts to transmit the short message through MSC following the bearer data interface (1) in Figure 5. Note that SMS delivery through the MSC is more resource consuming than the delivery through the SGSN. The SMS-C should inform the WAP/Directory server about the status of the MNRG flag through the GPRS/WAP signaling interface (6) in Figure 5. If the bearer data interface (1) also fails, the MNRF is set in MSC, HLR and SMS-C, and the SMS-GMSC returns an error message to SMS-C. The SMS-C should inform the WAP/Directory server that the MNRF is set, and the WAP rejects push applications for that specific user until one of the flags is cleared Data Delivery Procedure As describe above, the WAP/SMS-requested PDP context activation procedure is employed when the mobile user is GPRS-reachable, but the PDP context is deactivated. Push data delivery procedure for the WAP/SMS-requested PDP Context Activation is given in Figure 7. The figure details the bearer data delivery for the situation, where dynamic IP user doesn t have an active GTP tunnel, but the MNRG flag is not set either. The detail description of the push data delivery procedure is itemized as follows: Step 1(a) The Push Server (or Initiator, which may be an e- mail provider, stock market service provider) provides the push data. The Push message contains a control entity and a content entity, and may contain a capability entity. The control entity is an XML document that contains control information for the PPG to use in processing the message for delivery. The push server instructs the WAP PPG to push the content to the mobile client using the Push Access Protocol. Step 1(b) The response to the push content delivery is an XML document that indicates initial acceptance or failure. At minimum the WAP PPG must validate against the Document Type Definition (XML), the control entity, in the message and report the result in the response. Step 2(a) If the size of the push content is larger than a specific threshold, the WAP PPG requires to establish the GTP tunnel according to the WAP/SMS-requested PDP Context Activation Procedure. The WAP PPG sends the WAP/SMSrequested PDP Context Activation Request to the mobile client through SMS. (If the size of the push content is small, then the WAP PPG may initiate the regular SMS messaging to transmit the push content). Step 2(b) In the current protocol, the response of the SC indicates initial acceptance or failure due the raised MNRG and MNRF flags. Since the MNRG and MNRF are already stored in the WAP according to the proposed forwarding mechanism, this response is always positive. Step 3(a) This operation is used to transfer a short message from an SC to an SMS-GMSC. The operation consists of the transfer of a message containing the transfer protocol data unit (TPDU) from the SC to the SMS-GMSC. This message contains a request for PDP Context Activation for the MS. Step 3(b) The operation consists of the return of either a "Failure report" or a "Delivery report". "Failure report" is returned to the SC when the SMS-GMSC has received indication from another entity (MSC, SGSN or HLR) the procedure was unsuccessful. The error indications, which the SMS-GMSC may receive from the MSC, SGSN, HLR, VLR or MS, enable the SMS-GMSC to return an error indication. 4

5 Step 4 This operation is referred to as sendroutinginfofor- ShortMsg. The operation is an interrogation of the HLR by the SMS-GMSC to retrieve information necessary to forward the short message. The result may contain the MSC, SGSN or both addresses, and also indicates which address belongs the MSC and the SGSN. Step 5(a) This operation is referred to as forwardshortmessage. The operation provides a means for the SMS-GMSC to transfer a short message to the MSC or to the SGSN at which the MS is currently located. If the mobile is in GPRS-attached mode, the TPDU commands the MS to establish the GTP tunnel using the WAP/SMS-requested PDP Context Activation procedure. The operation works in tandem with the forwarding of the short message from the MSC or from the SGSN to the MS. Step 5(b) The outcome of the operation comprises either success, i.e. that the message has been delivered to the MS; or a failure that may be caused by several reasons, e.g. failure in the transfer SMS-GMSC -> MSC or SMS-GMSC -> SGSN, MS being detached, or no paging response. It should be noted that the MNRG setting is implicitly carried out in SGSN when the message transfer is denied due to GPRS DETACH. Step 6 This operation is referred to as sendinfofor-mtsms. The operation provides a means for the MSC to retrieve subscriber information from VLR for mobile terminated short message transfer. The operation may be associated with an authentication procedure. Unsuccessful retrieval (e.g. absent subscriber) is indicated by a cause indication to the SMS-GMSC. It should be noted that the MNRF setting is implicitly carried out when the message transfer is denied due to IMSI DETACH. This operation is not used by the SGSN. Step 7 This operation is referred to as Message transfer MSC to MS. The operation is used to transfer a short message from the MSC to the MS. If the transfer is not successful, e.g. due to the MS losing radio coverage after having successfully authenticated, a failure report is returned to the SMS-GMSC. If the MS notifies the network that the MS has been unable to accept a short message because its memory capacity has been exceeded, then the ME will set the Memory Capacity Exceeded Notification flag if present. Step 8 This operation is referred to as SM-DeliveryReport- Status. The operation provides a means for the SMS-GMSC to request the HLR to add an SC address to the Message Waiting Data, and is activated when the SMS-GMSC receives an absent subscriber indication from the MSC, SGSN or both, and/or when the SMS-GMSC receives a failure report for a short message transfer with cause MS Memory Capacity Exceeded via the MSC or SGSN. This operation is also activated at successful delivery short message when the MNRF, MNRG or both are set in HLR. Step 9 This operation is used to transfer the Delivery Status of the SMS message to the WAP PPG before establishing the GTP tunnel. Step 10 The MS sends an Activate PDP Context Request message to the SGSN after receiving the PDP Context Activation request by a SMS message through SGSN. This procedure is referred to as WAP/SMS-requested PDP Context Activation. The MS leaves PDP Address empty to request a dynamic PDP address. Step 11 Security functions may be executed. Step 12(a) The SGSN validates the Activate PDP Context Request using PDP Type, PDP Address, and Access Point Name provided by the MS and the PDP context subscription records. If no address can be derived or if the SGSN has determined that the Activate PDP Context Request is not valid, then the SGSN rejects the PDP context activation request. The SGSN sends a Create PDP Context Request message to the affected. The creates a new entry in its PDP context table. The new entry allows the to route PDP PDUs between the SGSN and the external PDP network. Step 12(b) The then returns a Create PDP Context Response message to the SGSN including PDP Address. The Create PDP Context messages are sent over the GPRS backbone network. Step 13 The SGSN inserts the Network layer Service Access Point Identifier (NSAPI) along with the address and PDP address in its PDP context. The SGSN is now able to route PDP PDUs between the and the MS. Step 14 After establishing the GTP tunnel between the SGSN and, the MS sends the Wireless Session Protocol (WSP) GET message to the related WAP Push Proxy Server. Step 15 The WAP Gateway transmits the XML-binary push data through the GTP tunnel between and SGSN, which is established by the WAP/SMS-requested PDP Context Activation Procedure. Step 16 The MS sends a delivery status of the push data to the WAP PPG. Step 17(a) The WAP PPG forwards the delivery status of the push data to the Push Server. Step 17(b) The Push Server sends a response back to the WAP PPG according to the WAP. In the next section, we detail the GPRS/WAP bearer data interface for the static IP users in order to deliver the push data Static PDP Addressing In the case of static PDP addressing, if the MNRG is not set, the WAP/Directory server directs the push data to the. The establishes the GTP tunnel according to the standard network-requested PDP Context Activation procedure unless there is an active GTP tunnel for the MS. If the network-requested activation is unsuccessful, the MNRG is set, and the WAP/Directory server should follow the same steps of the above scenario dynamic PDP addressing, MNRG is set, MNRF is not set, given above. In the case of MNRG is set, the HLR and resources are preserved by not initiating the network-requested PDP-Context Activation. 5. Performance Evaluation In this section, we simulate the UMTS network with and without WAP/SMS-requested PDP Context Activation procedure. The simulation parameters for a simplified UMTS network are as follows: The number of mobile users is The percentage of static IP mobile users is assumed as 0.2, 0.5 and 0.8. The UMTS core network consists of one SGSN and one. The number of GTP tunnels supported between SGSN and is 100. can process an average of 500 HLR inquiries per second for network-requested PDP context activation requests, which is sufficient to support 100 GTP tunnels. The distribution of mobile-initiated 5

6 PDP context activation requests is exponential, and each mobile user has an average of mobile-initiated PDP context activation request per second. The distribution of push message arrival is exponential, and the average push message per mobile user is 0.02 per second. We consider the GTP tunnel duration between 70 and 150 sec. for mobile-initiated PDP contexts. We assume that circuit-switched data rate for push messages is 9.6 kbps. Packet-switched data rate is assumed to be 300 kbps, which is viable in UMTS when mobile user is on the move. We assume that WAP Directory Server always sends the push message to the for static IP users in any condition. And, then performs the network-requested PDP Context Activation procedure to build GTP tunnel if there is no GTP tunnel at the moment for this static IP user. When push message arrives to WAP Directory Server for dynamic IP user in UMTS without WAP/SMS-requested PDP Context Activation capability, the push message is transmitted to the user over the circuit-switched domain with 9.6 kbps. When push message arrives to WAP Directory Server for dynamic IP user in UMTS with WAP/SMS-requested PDP Context Activation capability, the WAP Server first establishes the GTP tunnel using WAP/SMS-requested PDP Context Activation if possible. Then, push message is transmitted to the user over the packet-switched domain with 300 kbps. Note that we assume the network doesn t use WAP/SMS-requested PDP Context Activation capability for the static IP users in any case. We also assume that the transmission of the WAP/SMS-requested PDP Context Activation request message is negligible due to short message length. In Figure 6, we plot the push transmission delay versus the GTP tunnel duration for UMTS network with and without WAP/SMS-requested activation. As expected, push transmission delay gets shorter in UMTS network as the percentage of static IP users gets higher. Average push transmission delay stays between 0.2 and 1 sec. In UMTS network with WAP/SMS-requested activation, it is observed that push transmission delay is unexpectedly smaller at shorter GTP tunnel duration for small number of static IP users than the large number of static IP users. This behavior indicates that all the GTP tunnels are occupied after a certain GTP tunnel duration, which forces the dynamic IP users to use the circuitswitched data transmission. Note that push transmission delay for the UMTS with the WAP/SMS activation is smaller than the UMTS without the WAP/SMS activation. In Figure 7, we plot the push packet blocking probability. We assume the WAP/SMS-requested PDP Context Activation capability is not used for the static IP users, where if the GTP tunnels are all occupied, push packet is discarded for the static IP user instead of delivery over circuit-switched domain. Therefore, push packet blocking probability is same for both of the cases, the UMTS with and without WAP/SMS activation. 6. Conclusions This paper details the wireless location-aware and content aware push application delivery over the packet-switched wireless core network, namely GPRS and UMTS networks. GPRS and UMTS wireless systems will deploy WAP Server, which bridges wireless networks and the Internet. A sort of directory is also deployed besides the WAP server in order to support the push applications by storing the user profile, IMSI and user IP address. WAP/Directory server requires static IP addressing to support such 3G applications. For each incoming IP packet, the is capable of establishing a GTP tunnel to the serving SGSN using the network-requested PDP context activation procedure for the static IP users due to their static IP entries at the HLR. However, the HLR does not have any IP entry for the users with the dynamic IP addresses. The incoming IP packets destined for dynamic IP users are discarded at the level. We propose a WAP/SMS-based methodology, which establishes the GTP tunnel before delivering the push data from WAP to the. The new method is referred to as WAP/SMS-requested PDP Context Activation Procedure, which establishes the GTP tunnel for the dynamic IP users. The proposed methodology provides push services to dynamic IP addressed-mobile users in GPRS/UMTS networks, and minimizes the unsuccessfulnetwork-requested PDP Context Activation for static IP users. The proposed method is basically based on the Protection and Mobile User Activity procedures, SMS service, and a new signaling mechanism to forward the HLR-based flags to the WAP server. References [1] R. Kalden, I. Meirick, M. Meyer, Wireless Internet access based on GPRS, IEEE Personal Communications Magazine, V. 7, Page(s): 8 18, April [2] Chung-Hwa Rao, H.; Di-Fa Chang; Yi-Bing Lin, ``isms: an integration platform for short message service and IP networks, IEEE Network, V. 15, Page(s): 48 55, March-April [3] R. Ramjee et al., IP-Based Access Network Infrastructure for Next-Generation Wireless Data Networks, IEEE Personal Communications Magazine, August [4] GSM 02.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 1, [5] GSM 03.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 2, [6] 3GPP Specifications are available at [7] GSM 09.61, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Interworking between the Public Land Mobile Network (PLMN) supporting GPRS and Packet Data Networks (PDN), [8] GSM 03.40, Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS), [9] WAP Push Access Protocol Specification, WAP Forum, [10] "WAP Push Architectural Overview, WAP Forum, [11] Wireless Application Protocol Architecture Specification, WAP Forum,

7 MSC/VLR BTS BSC PCU HLR SS7 PSTN T1 Voice Browser VXML HTTP VXML Server SGSN GTP GPRS Backbone Network Directory WAP/ Directory Server IP DNS LDAP Core Router Firewall Internet Figure 1. Successful push data delivery through the WAP/Directory server in GPRS/EDGE networks. BTS BSC MSC/VLR PSTN PCU GPRS-attached Discards the data Dynamic IP not supported by networkinitiated PDP context activation SGSN no tunnel GPRS Backbone Network Directory Push data flow IP WAP/Directory Server DNS LDAP Radius Server Core Router Firewall Internet Figure 2. Failure Scenario 1: Dynamic IP user is in GPRS-attached mode; discards the incoming push data due to no tunnel between the SGSN and. 7

8 SMS-GMSC SMS-IWMSC SMS-C (6) Gd MSC/VLR HLR (1) (2) (4) Gr Gs Gc MT BSS Gb SGSN (5) WAP Internet Um (3) Gn Gi Gp Gn Terminal SGSN GPRS/WAP Bearer Data Interface: (1) MNRG is set (dynamic or static PDP addressing) and MNRF is not set. (2) Dynamic PDP addressing and MNRG is not set. Request for MT to activate PDP Context, it is referred as WAP/SMS-requested PDP Context Activation. (3) Static PDP addressing and MNRG is not set. If no PDP Context Activation, network-requested PDP Context Activation. GPRS/WAP Signaling Interface: (4), (5) Setting MNRF and MNRG, respectively. (6) Alternative Path Figure 3. Push Data Delivery for the WAP/SMS-Requested PDP Context Activation procedure: Signaling and Bearer Data Interfaces. 8

9 MS SGSN WAP 1. Deactivate PDP Context Request MS-initiated PDP Context Deactivation 2. Security Functions 3. Delete PDP Context Request 3. Delete PDP Context Response PDP Context Deleted 4. Deactivate PDP Context Accept SGSN-initiated PDP Context Deactivation 1. Delete PDP Context Request 1. Delete PDP Context Response PDP Context Deleted 2. Deactivate PDP Context Request 2. Deactivate PDP Context Accept -initiated PDP Context Deactivation 2. Deactivate PDP Context Request 1. Delete PDP Context Request 2. Deactivate PDP Context Accept 3. Delete PDP Context Response PDP Context Deleted Figure 4. Different component-initiated PDP Context Deactivation and passing the information to the WAP/Directory server. 9

10 Push Server 1a) Push Content Delivery 1b) Response WAP Proxy Gateway 2a) WAP/ SMS PDP Context Activation Request 2b) Response (POSITIVE due to forwarding mechanism) SC 3a) WAP/ SMS PDP Context Activation Request SMS Message Transfer SMS- GMSC HLR SGSN VLR MS 4) Send Routing Info for Short Message 8) SM- Delivery Report Status 5a) Forward Short Msg 5b) Delivery Report 6) Send Info For MT-SMS 7) Message Transfer (encapsulated (PDP context activation request from WAP PPG) 9) Delivery Status 3b) Delivery Report 12a) Create PDP Context Request 10) Activate Context 11) Security PDP Request Functions 14) Wireless Session Protocol (WSP) GET Message 12b) Create PDP Context Response 13)Activate Activation PDP Accept 17a) Delivery Status 17b) Response 15) XML- Binary Push Message 16) Delivery Status Figure 5. Push data delivery procedures for the WAP/SMS-requested PDP Context Activation procedure. 10

11 10 1 UMTS 10 0 UMTS with WAP/SMS static-ip = 0.2 static-ip = 0.5 static-ip = 0.8 Push Transmission Delay (sec.) 10 0 Push Transmission Delay (sec.) static-ip = 0.2 static-ip = 0.5 static-ip = GTP Tunnel Duration (sec.) GTP Tunnel Duration (sec.) Figure 6. Push transmission delay for UMTS with and without WAP/SMS-requested PDP context activation UMTS with/without WAP/SMS 10-1 Push Packet Blocking Probability Static-IP = 0.2 Static-IP = 0.5 Static-IP = GTP Tunnel Duration (sec.) Figure 7. Push packet-blocking probability for UMTS with and without WAP/SMS-requested PDP context activation. 11