HK1160714B - System and method for determining that a maximum number of ip sessions have been established - Google Patents

Abstract

Systems and methods for determining that a maximum number of IP sessions have been established are provided. There are instances when the mobile device transmits a request to the wireless network. According to an aspect, in the event that the maximum number of IP sessions is already established for the mobile device, the wireless network transmits a response indicating that the request cannot be fulfilled. The mobile device determines based on the response that the maximum number of IP sessions is already established, which allows the mobile device to determine the maximum number of IP sessions that can be supported so that IP sessions can be managed accordingly.

Description

Method and system for determining that a maximum number of IP sessions have been established

The present application is a divisional application filed on 24/8/2007 under the application number "200710186182.6," entitled "method and system for determining that a maximum number of IP sessions have been established.

Technical Field

The present application relates generally to wireless communications, and more particularly to IP sessions.

Background

Communication between the mobile device and the correspondent node is performed in a UMTS (universal mobile telecommunications system) network via a GPRS (general packet radio service) serving node. The GPRS service nodes include SGSN (serving GPRS support node) and GGSN (gateway GPRS support node). Such communication exchanges between the mobile device and the corresponding node include communication exchanges between the mobile device and the SGSN. Communication exchanges, such as user plane communications (i.e., IP data traffic), between the mobile device and the SGSN node use one or more PDP contexts. There may be multiple PDP contexts based on the number of different applications that the mobile device communicates through the PDP contexts. However, the PDP context for a mobile device may be limited by the number of PDP contexts supported by the routing area in which the mobile device resides.

Different routing areas may support different numbers of PDP contexts. However, the mobile device is not aware of the number of PDP contexts supported by a particular routing area for that mobile device. This can lead to undesirable situations. For example, the mobile device may request a new PDP context to be established when it is not known that the maximum number of IP sessions have been established. Therefore, the mobile device will fail to establish a new PDP context. Also, in some cases, the mobile device is unaware of the reason for the failure of the new PDP context establishment. If the mobile device does not know the maximum number of IP sessions supported for the mobile device, the mobile device is unable to properly manage the PDP context. If the user requests more services using PDP contexts than the network can support, there may be some multiplexing where some services are delayed, etc.

One possible approach provided for the mobile terminal is to always assume that only one PDP context is supported. However, this approach does not have advantages when supporting additional PDP contexts. This has the consequence that the user on a network supporting more than one PDP context is not satisfied.

Disclosure of Invention

According to one broad aspect of the invention, there is provided a method on a mobile device, comprising: sending at least one request of a predetermined type; receiving an indication that a given request of the at least one request cannot be satisfied because a maximum number of Internet protocol "IP" sessions have been established for the mobile device; determining a maximum number of IP sessions supported for the mobile device in a given network area based on the indication; and managing IP sessions based on the maximum number of IP sessions supported for the mobile device.

According to another broad aspect of the present invention, there is provided a mobile device comprising: a wireless access radio adapted to communicate with a wireless network; and an IP session management function adapted to: the method includes transmitting at least one predetermined type of request, receiving an indication that a request of the at least one request cannot be satisfied because a maximum number of IP sessions have been established for the mobile device, determining a maximum number of IP sessions supported for the mobile device in a given network area based on the indication, and managing IP sessions based on the maximum number of IP sessions supported for the mobile device.

According to another broad aspect of the invention, there is provided a method in a wireless network, comprising: upon receiving a request of a predetermined type from a mobile device located in a given network area: determining whether a maximum number of IP sessions have been established for the mobile device for a given network area; and if the maximum number of IP sessions has been established, sending a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has been established.

According to another broad aspect of the present invention, there is provided a wireless network comprising an IP session function adapted to: upon receiving a request of a predetermined type from a mobile device located in a given network area: determining whether a maximum number of IP sessions have been established for the mobile device for a given network area; and if the maximum number of IP sessions has been established, sending a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has been established.

According to another broad aspect of the present invention, there is provided a wireless network comprising an IP session function adapted to: upon receiving a request of a predetermined type from a mobile device located in a given network area: determining whether a maximum number of IP sessions have been established for the mobile device for a given network area; and if the maximum number of IP sessions has been established, sending a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has been established.

According to another broad aspect, there is provided a method comprising: using the information identifying the number of IP sessions supported by a given network area, the mobile device actively manages allocation of IP sessions with respect to the number of supported IP sessions when the IP sessions are less than the device functionality requiring IP sessions.

According to another broad aspect, there is provided a mobile device comprising: a wireless access radio adapted to communicate with a wireless network; and an IP session management function adapted to: using the information identifying the number of IP sessions supported by a given network area, the mobile device actively manages allocation of IP sessions with respect to the number of IP sessions supported when the IP sessions are less than the device functionality requiring IP sessions.

Drawings

Embodiments will be described below with reference to the following drawings, in which:

FIG. 1A is a block diagram of an example wireless network and mobile device;

FIG. 1B is a block diagram of the mobile device shown in FIG. 1A;

FIG. 1C is a block diagram of another mobile device;

FIG. 2 is a flow diagram of an example method of determining that a maximum number of IP sessions have been established;

FIGS. 3A and 3B are tables of a typical GMM cause information element;

fig. 4A and 4B are tables of a typical SM cause information element;

FIGS. 5-7 are flowcharts of an example method of managing IP sessions based on a maximum number of IP sessions that can be supported for a mobile device;

FIG. 8 is a flow chart of a method of determining the number of PDP contexts supported;

FIG. 9 is a flow chart diagram of a method of saving historical information;

FIG. 10 is a table of an example format in which history information may be maintained;

FIG. 11 is a flow diagram of an example method of managing an IP session; and

fig. 12 is a flow diagram of an example method of sending a response indicating that a request cannot be satisfied because a maximum number of IP sessions have been established.

Detailed Description

Wireless communication system

Referring now to fig. 1A, fig. 1 illustrates a block diagram of an example wireless network 100 and a mobile device 10. The wireless network 100 has a first routing area 30 and a second routing area 40. Other routing areas are possible but are not shown for simplicity. Each routing area has at least one RNC (radio network controller). In the illustrated embodiment, the first routing area 30 has a first RNC31 and a second RNC32, and the second routing area has a single RNC 41. Each RNC31, 32, 41 is associated with a corresponding RNC Id, respectively. The first RNC31 and the second RNC32 of the first routing area 30 have RNC Id 31a and RNC Id 32a, respectively, while the single RNC41 of the second routing area 40 has RNC Id 41 a. Each cell (not shown) within the RNC is associated with an RAI (routing area identity) in a hierarchical manner (by the node B). The RAI may include one or more cells and span the RNC. In some embodiments, each RAI is a combination of a country code, a network code, and a routing area code. The RAI may be different for other wireless networks.

In the exemplary embodiment, each RNC31, 32, 41 is coupled to an SGSN (serving general packet radio service support node) 50, an SGSN50 is coupled to a GGSN (gateway GPRS support node) 60, and a GGSN60 is coupled to a PDN (packet data network) 70. PDN70 may be, for example, the internet. The SGSN50 has an IP session function 51 coupled to the processor 52 and may have other components as well, but is not shown for simplicity.

Wireless network 100 is shown with a single mobile device, namely mobile device 10. Other mobile devices are possible but are not shown for simplicity. Referring to FIG. 1B, a block diagram of the mobile device 10 shown in FIG. 1A is shown. The mobile device 10 has a processor 12 coupled to a radio access radio 11, an IP session management function 13, an application 14 and a user interface 15. The mobile device 10 may have other components, but are not shown for simplicity. Referring now back to fig. 1A, the mobile device 10 is currently located within the first routing area 31. However, the mobile device 10 may move to another routing area, such as the second routing area 40, as indicated by the movement arrow 19.

In operation, the mobile device 10 is adapted to communicate with the wireless network 100 using its wireless access radio 11. Such communication may be, for example, voice communication, electronic messaging, or any other suitable form of communication supported by the application 14. At least part of the communication with the wireless network 100 is through one or more IP sessions between the mobile device 100 and the SGSN 50. A PDP (packet data protocol) session is an example of an IP session. There may be multiple IP sessions between mobile device 10 and SGSN50 based on the number of IP sessions that application 14 has established. The number of IP sessions, however, is typically limited by the routing area in which the mobile device 10 is located (currently by the first routing area 30).

There are situations where the mobile device 10 sends a predetermined type of request, such as an active IP session request or an IP session service request. Wireless network 100 receives the request and determines whether the maximum number of IP sessions has been established for mobile device 10. According to one embodiment of the invention, the IP session function 51 performs a method within the wireless network 100 such that, in the event that the maximum number of IP sessions has been established for the mobile device 10, the wireless network 100 sends a response indicating that the request cannot be satisfied because the maximum number of IP sessions has been established. The mobile device 10 receives the response. According to another embodiment of the invention, the IP session management function 13 performs a method within the mobile device 10 to determine, based on the response, that the maximum number of IP sessions has been established. This allows the mobile device 10 to determine the maximum number of IP sessions that can be supported so that the mobile device 10 manages IP sessions accordingly. Further details are provided below with reference to fig. 2-11.

In the illustrated embodiment, it is assumed that the same number of IP sessions are supported for mobile device 10 within each routing area regardless of how many RNCs are present. Typically, the routing area has a single RNC, as is the case for the second routing area 40. The number of IP sessions supported for a given mobile device is currently limited by the RNC. Thus, although the actual limiting factor is the RNC, the routing area may typically be considered the limiting factor. However, one routing area may have more than one RNC, as is the case for the first routing area 30. Thus, the routing area can support a different number of PDP contexts for the mobile device based on where the mobile device is located in the routing area. This is the case where the routing area cannot be considered a limiting factor. Although the examples presented herein refer to "routing area" as a limit to the number of IP sessions for a mobile terminal, it can be appreciated that the more generalized "area" in a network limits the number of IP sessions for a mobile terminal. The "area" may be a routing area, a portion of a routing area defined by, for example, an RNC Id, a network, a cell Id, or other area in which the number of IP sessions supported for a mobile device is limited.

In some embodiments, there is a subtle distinction between connected/active states (CELL _ DCH, CELL _ FACH) and IDLE states (CELL _ PCH, URA _ PCH, IDLE) of the mobile device. The routing area is known to the mobile device while in the idle state; however, the RNC id is typically unknown. While in the idle state, the mobile device enters the connected/active state in order to find out its serving RNC id. This would waste battery life, etc. Thus, in some embodiments, the number of IP sessions supported is considered for a routing region, regardless of whether the routing region is the lowest level of granularity.

There are several possibilities for the IP session management function 13 of the mobile device 10. In the illustrated embodiment, the IP session management function 13 is implemented as software and executes on the processor 12. More generally, however, the IP session management function 13 may be implemented as software, hardware, firmware, or any suitable combination thereof. In the illustrated embodiment, the IP session management function 13 is shown as a single component. More generally, however, the IP session function 13 may be implemented as one or more components. An example in which the IP session management function 13 includes more than one component will be described in detail below.

In some embodiments, the IP session management function 13 includes a NAS (non-access stratum) and an AS (access stratum). The NAS includes a session management layer and manages IP sessions. For example, the NAS may initiate sending an activate PDP context request message to the SGSN 50. The AS manages the air interface of the wireless access radio 11 and includes a corresponding RAB (radio access bearer) for each active IP session. The RAB is an identification of the RF (radio frequency) transmission. There may be a dormant IP session without a corresponding RAB. For example, the AS may initiate sending a service request message to the RNC.

There are many possibilities for the IP session function 51 of the wireless network 100. In the illustrated embodiment, the IP session function 51 is implemented as software and executes on the processor 52. More generally, however, IP session management 51 may be implemented as software, hardware, firmware, or any suitable combination thereof. In the illustrated embodiment, the IP session function 51 is shown as a single component of the SGSN 50. More generally, however, the IP session function 51 may be implemented as one or more components and may be implemented as part of the SGSN50 or separate from the SGSN 50. The one or more components may be distributed throughout the wireless network 100 or co-located. Other embodiments are also possible.

There are several possibilities for the wireless network 100. In the illustrated embodiment, the wireless network 100 is a UMTS (universal mobile telecommunications system) network. More generally, however, wireless network 100 may be any wireless network in which routing areas limit the number of IP sessions established for a given mobile device.

There are a number of possibilities for the mobile device 10. Referring now to FIG. 1C, there is shown a block diagram of another mobile device 80 that may perform any of the methods described herein. It should be understood that the mobile device 80 is shown with very specific details for exemplary purposes only.

A processing device (microprocessor 128) is illustratively shown coupled between the keyboard 114 and the display 126. The microprocessor 128 controls the operation of the display 126, as well as the overall operation of the mobile device 80, in response to key operations by the user on the keyboard 114.

The mobile device 80 has a housing that may be elongated vertically or take on other sizes and shapes (including clamshell housing structures). The keyboard 114 may include a mode selection key or other hardware or software for switching between text entry and telephony entry.

In addition to the microprocessor 128, other components of the mobile device 80 are shown schematically. Which comprises the following steps: a communication subsystem 170; a short-range communications subsystem 102; a keyboard 114 and a display 126, as well as other input/output devices, including a set of LEDs 104, a set of auxiliary I/O devices 106, a serial port 108, a speaker 111, and a microphone 112; and storage devices including flash memory 116 and Random Access Memory (RAM) 118; and various other device subsystems 120. The mobile device 80 may have a battery 121 to power the active components of the mobile device 80. In some embodiments, the mobile device 80 is a two-way Radio Frequency (RF) communication device having voice and data communication capabilities. In addition, in some embodiments, the mobile device 80 has the capability to communicate with other computer systems via the Internet.

Operating system software executed by the microprocessor 128 is stored in a persistent store, such as the flash memory 116, in some embodiments, but may be stored in other types of memory devices, such as a Read Only Memory (ROM) or similar storage element. In addition, system software, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as the RAM 118. Communication signals received by the mobile device 80 may also be stored in the RAM 118.

The microprocessor 128, in addition to its operating system functions, enables execution of software applications on the mobile device 80. A predetermined set of software applications, such as a voice communication module 130A and a data communication module 130B, which control basic device operations, may be installed on the mobile device 80 during manufacture. In addition, a Personal Information Manager (PIM) may also be installed on the mobile device 80 during manufacture. In some embodiments, the PIM application is capable of organizing and managing data items, such as e-mail, calendar events, voice mails, appointments, and task items. The PIM application is also capable of sending and receiving data items, in some embodiments, via the wireless network 100. In some embodiments, data items managed by the PIM application are seamlessly integrated, synchronized and updated via the wireless network 110 with the device user's corresponding data items stored or associated with a host computer system. Meanwhile, an additional software module, shown as another software module 130N, may be installed during manufacture.

Communication functions, including data and voice communications, are performed through the communication subsystem 170, and possibly through the short-range communications subsystem 170. The communication subsystem 170 includes a receiver 150, a transmitter 152, and one or more antennas, shown as a receive antenna 154 and a transmit antenna 156. In addition, the communication subsystem 170 may include a processing module, such as a digital signal processor(s) ((DSP)158 and Local Oscillator (LO) 160. The particular design and implementation of the communication subsystem 170 is based upon the communication network in which the mobile device 80 is intended to operate. For example, the communication subsystem 170 of the mobile device 80 may be designed to communicate with Mobitex^TM、DataTAC^TMOr General Packet Radio Service (GPRS) mobile digital communication network, and may also be designed to operate with any voice communication network, such as the Advanced Mobile Phone Service (AMPS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Personal Communication Service (PCS), global system for mobile communications, etc. Any other type of data and voice network, both separate and integrated, may also be used by the mobile device 80.

Network access may vary with the type of communication system. For example, in Mobitex^TMAnd DataTAC^TMIn a network, mobile devices are registered on the network using a unique Personal Identification Number (PIN) associated with each device. In GPRS networks, however, network access is typically associated with a subscriber or user of a device. For operation on a GPRS network, therefore, a GPRS device typically has a subscriber identity module, commonly referred to as a Subscriber Identity Module (SIM) card.

Upon completion of the network registration or activation procedure, the mobile device 80 may send and receive communication signals over the communication network 110. Signals received by the receive antenna 154 from the communication network 110 are routed to the receiver 150, and the receiver 150 provides signal amplification, frequency down conversion, filtering, channel selection, etc., as well as analog to digital conversion. Analog-to-digital conversion of the received signal allows the DSP158 to perform more complex communication functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to the network 110 are processed (e.g., modulated and encoded) by the DSP158 and are then provided to the transmitter 152 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the communication network 110 via the transmit antenna 156.

In addition to processing communication signals, the DSP158 provides for control of the receiver 150 and the transmitter 152. For example, gains applied to communication signals in the receiver 150 and transmitter 152 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 158.

In a data communication mode, a received signal, such as a text message or web page download, is processed by the communication subsystem 170 and input to the microprocessor 128. The received signal is then further processed by the microprocessor 128 for output to the display 126 or alternatively to some other auxiliary I/O device 106. The device user may also generate data items, such as e-mail messages, using the keyboard 114 and/or some other auxiliary I/O device 106, such as a touchpad, a rocker switch, a thumb-wheel, or any other type of input device. The generated data items are then transmitted throughout the communication network 110 through the communication subsystem 170.

In the voice communication mode, the overall operation of the device is substantially the same as the data communication mode, except that the received signals are output to the speaker 111 and signals to be transmitted are generated by the microphone 112. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the mobile device 80. Additionally, the display 126 may also be employed in voice communication mode, for example, to display the identity of a calling party, the duration of a voice call, or other voice call related information.

The short-range communications subsystem 102 enables communication between the mobile device 80 and other proximate systems or devices, which need not necessarily be the same device. For example, the short-range communications subsystem may include an infrared device and associated circuits and components, or a Bluetooth (TM) communications module that provides for communications with similarly-enabled systems and devices.

Method in a mobile device

Referring now to fig. 2, a flow diagram of an example method of determining that a maximum number of IP sessions have been established is shown. The method may be performed within a mobile device, for example by the IP session priority management function 13 of the mobile device 10 shown in fig. 1B, or by the mobile device 80 shown in fig. 1C.

At step 2-1, the mobile device sends a request of a predetermined type. The wireless network receives and processes the request. In this example, it is assumed that the wireless network cannot satisfy the request because the maximum number of IP sessions have already been established for the mobile device. The wireless network sends a response, which is received by the mobile device at step 2-2. The response indicates that the request cannot be satisfied because the maximum number of IP sessions has been established for the mobile device. In step 2-3, the mobile device determines, based on the response, that the maximum number of IP sessions has been established.

There are a number of ways to enable the response to indicate that the request cannot be satisfied because the maximum number of IP sessions have been established for the mobile device. In some embodiments, the response includes a reason code indicating that the request cannot be satisfied because the maximum number of IP sessions have been established for the mobile device. More generally, the response may include any suitable indication that the request cannot be satisfied because the maximum number of IP sessions has been established for the mobile device.

Referring now to fig. 3A and 3B, tables of an example GMM cause information element are shown. It should be understood that the GMM cause information element shown in the illustrated example is merely an implementation of a particular cause code for exemplary purposes. The purpose of the GMM cause information element is to indicate the reason why the GMM request from the mobile device was rejected by the wireless network. As shown in fig. 3A, the GMM cause is a type 3 information element having a length of 2 octets. The second octet is used for the cause value. As shown in fig. 3B, there are a number of possible cause values. The cause value "01100110" indicates that the maximum number of PDP contexts has been activated. In some embodiments, the cause value is part of the causes related to PLMN-specific network failures and congestion/authentication failures.

Referring now to fig. 4A and 4B, tables of example SM cause information elements are shown. It should be understood that the SM cause information element shown in the illustrated example is merely an implementation of a specific cause code for exemplary purposes. The purpose of the SM reason information element is to indicate the reason why the session management request was rejected. As shown in fig. 4A, the SM cause is a type 3 information element having a length of 2 octets. The second octet is used for the cause value. As shown in fig. 4B, there are a variety of possible cause values. The cause value "01100110" indicates that the maximum number of PDP contexts has been activated. In some embodiments, the cause value is part of a GPRS specific cause value for GPRS session management.

In some embodiments, the cause value 102 indicates that the maximum number of PDP contexts have been activated. More generally, any suitable cause value may be implemented.

There are many possibilities for the predetermined types of requests and responses. In some embodiments, the type of response is based on the type of request. Examples are given below.

In one example, the request may be an activate IP session request for requesting establishment of a new IP session, and the response is an activate IP session rejection for rejecting the IP session request. In some embodiments, the activate IP session request is an activate PDP context request and the response is an activate PDP context reject.

In another example, the request is an IP session service request requesting service for an already existing IP session, and the response is an IP service rejection rejecting the IP session service request. In some embodiments, the IP session service request is a service request and the IP service rejection is a service rejection.

In another example, the request is an activate PDP context request requesting establishment of a new PDP context, and the response is an MT PDP deactivation request deactivating an already existing PDP context. This may occur, for example, if the mobile device sends an activate PDP context request in an area that does not support enough PDP contexts to satisfy the request. In this response, the request is considered to be unsatisfied because a new PDP context was not initially established in response to the activate PDP context request. However, in some embodiments, the requested new PDP context becomes established after the already existing PDP context is deactivated.

In another example, the request is a RAU request requesting a change to a new routing area, and the response is an MT PDP deactivation request deactivating an already existing PDP context. This may occur, for example, if the mobile device sends a RAU request after entering a new routing area that does not support enough PDP contexts to satisfy the request. Other requests and corresponding responses are also possible.

An example message has been provided for responding to the request. In some embodiments, the message is based on a message defined in 3GPP (third generation partnership project) TS 24.008 V7.5.0 with appropriate modifications to indicate that the request cannot be fulfilled because the maximum number of IP sessions have been established for the mobile device. Other embodiments are also possible.

In some embodiments, the type of request is based on the state of the mobile device. For example, the type of request may change based on whether the mobile device is in an idle state as compared to an active/connected state. In some embodiments, the mobile device may send an IP session service request message in the active/connected state to request service for an existing IP session. However, in some embodiments, the mobile device may never send an IP session service request while in the idle state. In some embodiments, the predetermined type of request is sent only if the mobile device is in an active/connected state. Other embodiments are also possible.

In some embodiments, the mobile device manages IP sessions based on the maximum number of IP sessions that can be supported for the mobile device. An example is given with reference to fig. 5. In step 5-1, the mobile device determines the maximum number of IP sessions that can be supported for the mobile device based on the response. At step 5-2, the mobile device manages IP sessions based on the maximum number of IP sessions that can be supported for the mobile device.

There are a number of ways for a mobile device to determine the maximum number of IP sessions that can be supported. In some embodiments, the mobile device determines the maximum number of IP sessions that can be supported based on a predetermined type of request. For example, if the request is an activate PDP context request and the mobile device knows the number of IP sessions established prior to the request, upon receiving a response indicating that the request cannot be satisfied because the maximum number of IP sessions has been established for the mobile device, the mobile device may determine that the maximum number of IP sessions that can be supported is equal to the number of IP sessions that have been established prior to the request. There are other possibilities to determine the maximum number of IP sessions that can be supported. Other examples will be provided later with reference to fig. 8.

There are a number of ways for a mobile device to manage IP sessions based on the maximum number of IP sessions that can be supported for the mobile device. Examples are provided below with reference to fig. 6 and 7. It should be understood that these examples are specific and are for exemplary purposes only. Other embodiments are also possible.

Referring first to fig. 6, at step 6-1, the mobile device receives a request from an application to establish a new IP session. The application may be any application running on the mobile device that is suitable for communicating over an IP session. At step 6-2, the mobile device determines whether to request a new IP session from the wireless network based on the maximum number of IP sessions that can be supported for the mobile device. For example, the mobile device may request a new IP session only if the number of IP sessions that have been established is less than the maximum number of IP sessions that can be supported for the mobile device.

Referring then to fig. 7, at step 7-1, the mobile device prioritizes the IP session. At step 7-2, the mobile device maintains a higher priority IP session before a lower priority IP session when the IP session is limited by the maximum number of IP sessions that can be supported for the mobile device.

It should be understood that an IP session is indicated as "higher" priority when the priority of the IP session is generally indicated as higher than other IP sessions. In some embodiments, this is the IP session with the highest priority. An IP session indicated as having a higher priority may not be a high priority IP session per se, but is indicated as having a higher priority than other IP sessions.

There are a number of ways for a mobile device to prioritize an IP session. In some embodiments, the mobile device receives user input that determines a respective priority for each IP session. Thus, the mobile device determines a respective priority for each IP session based on user input. In other embodiments, the mobile device maintains a record of predetermined priority levels for each predetermined type of IP session. Thus, the mobile device determines a respective priority for each IP session based on the record. Other embodiments are also possible.

Another method in a mobile device

In a specific example of a method of establishing a PDP context, when a GPRS mobile phone establishes a PDP context, an Access Point Name (APN) is determined and then used in a DNS query to a private DNS network. This process, called APN analysis, finally gives the IP address of the GGSN that should serve the access point. A PDP context may be activated at the access point.

GPRS and UMTS networks have limitations on the number of simultaneous PDP contexts supported. The number of PDP contexts may change as the mobile device moves between different parts of the network or between different networks. No information is currently provided to the mobile device to inform it of the number of supported PDP contexts. The result is that when the mobile device moves from a first cell that supports enough PDP contexts to meet the needs of the mobile device to a second cell where not enough PDP contexts are supported to meet the needs of the mobile device, the network may lose one or more existing PDP contexts in an unpredictable manner. This problem is common in UMTS networks, since many UMTS networks support only one PDP context. In such networks only one device functionality is connectable at a time, so always on-hold services like push e-mail cannot work with WAP (wireless access point) surfing on the network specific APN.

An event-based method is provided for determining the number of PDP contexts in a given network area. The network region may be the entire network or a portion of the network. The following is a specific example of an event that can occur when the activated PDP context exceeds the supported number by one:

an MT PDP deactivation request;

PDP activation rejection.

In some embodiments, a reason code in the message is used to distinguish between deactivation and rejection for other reasonable reasons. When any of these events with the correct reason code occurs, the number of active PDP contexts is counted and stored as a watermark as the number of PDP contexts supported by the network. In some embodiments, the step of determining the number of supported PDPs may be done preemptively at start-up (i.e. at discovery time) or in the context of a different APN being requested.

Referring to fig. 8, a flow chart of a method of determining the number of supported PDP contexts is shown. The method may be implemented within a mobile device, for example, by the IP session priority management function 13 of the mobile device 10 shown in fig. 1B or the mobile device 80 shown in fig. 1C. At step 8-1, the mobile device attempts to establish a simultaneous PDP context with a given network area and receives a response to such an attempt. At step 8-2, the mobile device determines the number of PDP contexts supported by a given network area on the basis of an attempt to establish a PDP context and a response to such an attempt.

In some embodiments, a default value for the number of PDP contexts supported by a network area is used, the default value being based on the capacity of the wireless network. Such default values also represent the maximum number of PDP contexts that the network can support from the perspective of a given device. For example, if a given mobile device supports a maximum number of 6 PDP contexts, the default value is initially 6 and will be decremented once the device's attempt to establish multiple simultaneous contexts is unsuccessful.

In some embodiments, establishing the plurality of PDP contexts supported by a given network area comprises performing a count of the number of simultaneous PDP contexts that have been established. This may be done as new contexts are added. Alternatively, the counting may be performed after a scenario occurs indicating that context is no longer supported.

In some embodiments, determining the number of PDP contexts supported by a given network comprises looking up a specifically defined response to an attempt to establish a PDP context. Upon receiving such a defined response, the last attempt to establish a PDP context is an attempt to establish one more PDP context than the PDP contexts supported by the current network. Thus, the number of PDP contexts supported by a given network area may be set to the number of simultaneous PDP contexts that have been established. This includes consulting the count being performed or performing the count based on receiving the defined response.

The response that triggers one or more definitions of the above-described behavior is implementation specific. The following is a particular set of defined responses, one or more of which may be implemented:

PDP activation reject response with cause code 26;

PDP activation reject response with reason code 38;

PDP activation reject response with reason code 101;

a response requesting to deactivate another existing context;

a response requesting release of a radio bearer related to another existing context; and

is specifically configured to indicate that no more PDP contexts are available.

Referring now to FIG. 9, a flow chart of a method of maintaining historical information is shown. The method may be performed within a mobile device, for example by the IP session priority management function 13 of the mobile device 10 shown in fig. 1B or the mobile device 80 shown in fig. 1C. In step 9-1, the mobile device maintains history information indicating the number of PDP contexts supported by each network area for previously visited network areas. In step 9-2, each time a network area change occurs, the mobile device looks up in the history information the number of PDP contexts supported by the network area if the network area is listed in the history information, otherwise establishes the number of PDP contexts supported by the new network area.

Referring now to FIG. 10, a table 200 of an example format in which history information may be maintained is shown. The first column 202 of the table 200 is used to store the network area identity and the second column 204 is used to store the number of PDP contexts supported. The total entries of this table are indicated at 206. The context support information can be maintained at a network region granularity defined based on the particular embodiment. In some embodiments, the granularity is of a PLMN identifier, and an example record is indicated at 208; in some embodiments, the granularity is a granularity of combined PLMN and LAC (local area code) and example records are indicated at 210; in some embodiments, the granularity is the granularity of a combined RAC (routing area code) and RNC ID, and an example record is indicated at 212. Alternatively, other granularities may be used. The granularity need not be consistent throughout the network area.

Context management based on number of contexts supported

In some embodiments, the number of contexts supported has been determined, and management of the contexts is done in view of this information, for example by controlling which PDP contexts are activated and deactivated to make the behavior more predictable. The management of the context is especially important when there are fewer PDP contexts than the number of device functions that require a PDP context.

Referring now to fig. 11, a flow diagram of a method of managing an IP session is shown. The method may be implemented within a mobile device, for example, by the IP session priority management function 13 of the mobile device 10 shown in fig. 1B or the mobile device 80 shown in fig. 1C. At step 11-1, using the information identifying the number of IP sessions supported by a given network area, the mobile device actively manages the allocation of IP sessions with respect to the number of IP sessions supported when there is less PDP context available than the functionality of the device requiring a PDP context.

The number of contexts may be determined using any of the methods described above. More generally, the mobile device needs to somehow determine or know the number of supported contexts. For example, in some embodiments, the mobile device receives context support information from a given network region, such as when the mobile device first connects in the network region. In some embodiments, the mobile device is preconfigured with context support information for multiple network regions. In some embodiments, each of the plurality of mobile devices determines the number of PDP contexts supported by the network area visited by the mobile device and makes this information available to the plurality of mobile devices. In some embodiments, the mobile device determines information identifying the number of PDP contexts supported by a given network area by performing a database query.

In one example of context management, the mobile device pre-emptively deactivates at least one selected PDP context prior to changing the network area from a first network area to a second network area that supports fewer PDP contexts than the first network area. For example, if it is known that a particular primary PDP context must be maintained, but a secondary PDP context can be dropped, the chance that the primary PDP context will not be dropped after the routing area is changed is increased by dropping the secondary PDP context before the routing area is changed. This example assumes that historical information for the next network is available.

In some embodiments, actively managing the allocation of the PDP context includes prioritizing device functions and allocating the PDP context according to the priorities.

In some embodiments, after changing the network area from a first network area to a second network area supporting fewer PDP contexts than the first network area, the mobile device selectively determines which device function is assigned a PDP context in the second network area and establishes these PDP contexts if not established and deactivates the other PDP contexts if not deactivated. The behavior of the new network may be unpredictable after moving from a first network area to a second network area supporting less PDP contexts than supported. The method essentially comprises: move, then observe which device functions are provided with PDP contexts and which are not, and then make the required adjustments by establishing and/or deactivating contexts.

The above summarized method may be applied in intra-RAT (radio access technology) scenarios (e.g. with WCDMA/UMTS networks) and in inter-RAT scenarios such as GRPR to UMTS handover.

The above description has assumed that the number of simultaneous PDP contexts supported is to be determined and then managed in some embodiments. More generally, a similar approach may be used to determine the number of simultaneous IP sessions supported, a PDP context being a specific example of an IP session.

Method in a wireless network

Referring now to fig. 12, a flow diagram of an example method of sending a response indicating that a request cannot be satisfied because a maximum number of IP sessions have been established is shown. The method may be implemented in a wireless network, such as by the IP session function 51 of the wireless network 100 shown in fig. 1A.

The steps of the flow chart are performed upon receiving a request of a predetermined type from a mobile device. At step 12-1, the wireless network determines whether a maximum number of IP sessions have been established for the mobile device. At step 12-2, if the maximum number of IP sessions has been established for the mobile device, the wireless network sends a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has been established.

The response has a number of ways to indicate that the request cannot be fulfilled because the maximum number of IP sessions have been established for the mobile device. Examples have been given above and are therefore not repeated here.

There are many possibilities for predetermined types of requests and responses. Examples have been given above and are therefore not repeated here.

IP session

In the above example, reference is made to an IP session. It should be appreciated that there are many possibilities for an IP session. For example, an IP session may include any of an always-on IP session, an IM (instant messaging) IP session, a WAP (wireless application protocol) IP session, an MMS (multimedia messaging service) IP session, a DUN (dial-up internet) IP session, an LBS (location based service) IP session, an IP modem IP session, and a PTT (push-to-talk) IP session. The nature of the IP session is implementation specific and typically depends on the wireless network. In some embodiments, the wireless network is a UMTS network and each IP session is part of a respective PDP (packet data protocol) context.

Many modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the application may be practiced otherwise than as specifically described herein.

Claims (31)

1. A method in a mobile device, comprising the steps of:

sending a request for a new internet protocol, IP, session;

receiving, in response to the request, an indication that the request cannot be fulfilled because the maximum number of IP sessions have been established for the mobile device;

after receiving the indication, the mobile device does not send any request for a new IP session when the maximum number of IP sessions is established.

2. The method of claim 1, further comprising:

based on the indication, a maximum number of IP sessions supported for the mobile device is determined.

3. The method of claim 2, further comprising:

the IP sessions are managed according to a maximum number of IP sessions supported for the mobile device.

4. The method of claim 1, wherein:

the step of sending the request comprises: sending a plurality of requests in an attempt to establish a simultaneous IP session;

the step of receiving an indication comprises: receiving responses to the plurality of requests; and

the method further comprises the steps of: the maximum number of supported IP sessions is determined based on an attempt to establish an IP session and a response to the attempt.

5. The method of claim 4, wherein the step of determining the maximum number of supported IP sessions further comprises:

a default value for the maximum number of IP sessions supported is established based on the capacity of the wireless network.

6. The method of claim 2, wherein the step of determining the maximum number of IP sessions supported further comprises:

a counting of the number of simultaneous IP sessions that have been established is performed.

7. The method of claim 6, wherein the step of determining the maximum number of supported IP sessions further comprises:

upon receiving a defined response to the attempt to establish an IP session, the number of supported IP sessions is set to a count of the number of simultaneous IP sessions that have been established.

8. The method of claim 7, wherein the defined response is any one of:

packet data protocol "PDP" activation reject response with cause code 26;

service option with cause code 34 temporarily disorganizes the response;

PDP activation reject response with reason code 38;

PDP activation reject response with reason code 101;

a response requesting to deactivate another existing context;

a response requesting release of a radio bearer related to another existing context; or

Is specifically configured to indicate that no more PDP contexts are available.

9. The method of claim 3, wherein the step of managing the IP sessions based on the maximum number of IP sessions supported comprises:

a supported number of IP sessions are established, and allocation of IP sessions is actively managed with respect to the supported number of IP sessions when there are fewer IP sessions than there are device functions requiring IP sessions.

10. The method of claim 9, wherein the step of actively managing allocation of IP sessions comprises any one of the following steps:

setting a priority to the device function and allocating the IP session according to the priority; or

After changing the network area from the first network area to a second network area having a smaller number of supported IP sessions than the first network area, it is selectively determined which device function is assigned an IP session in the second network area, and these IP sessions are established if not established and the other IP sessions are deactivated if not deactivated.

11. The method of claim 3, further comprising:

receiving a request from an application to establish a new IP session;

wherein the step of managing the IP session comprises: based on the maximum number of supported IP sessions, it is determined whether to request a new IP session from the wireless network.

12. The method of claim 3, further comprising:

setting a priority for the IP session;

wherein the step of managing the IP session comprises: when an IP session is limited by the maximum number of supported IP sessions, a higher priority IP session is maintained before a lower priority IP session.

13. The method of any of claims 1-12, wherein the step of receiving the indication comprises:

a response is received that includes a reason code indicating that the request cannot be fulfilled because the maximum number of IP sessions has been established.

14. The method of claim 13, wherein said reason code has a reason value 102 indicating that a maximum number of IP sessions have been activated.

15. The method of claim 13, wherein:

the request is an activate PDP context request requesting establishment of a new PDP context; and

the response is an activate PDP context rejection rejecting the activate PDP context request; or

The request is a PDP context service request requesting a service for an existing PDP context; and

the response is a service rejection rejecting the PDP context service request; or

The request is an activate PDP context request requesting establishment of a new PDP context; and

the response is a mobile terminal 'MT' PDP deactivation request to deactivate an existing PDP context; or

The request is a routing area update, 'RAU', request requesting a change to a new routing area; and

the response is an MT PDP deactivation request to deactivate an existing PDP context.

16. The method of any of claims 1-12, further comprising:

maintaining historical information indicating a maximum number of IP sessions supported by each network area for previously visited network areas; and

upon entering a new network area, if the new network area is listed in the history information, looking up the maximum number of IP sessions supported by the new network area in the history information, otherwise determining the maximum number of IP sessions supported by the new network area.

17. The method of claim 16, wherein the historical information is retained for a network region at a granularity of any one of: public land mobile network 'PLMN'; PLMN and local area code 'LAC'; or the routing area code 'RAC' and the radio network control identity 'RNC Id'.

18. The method of any of claims 1-12, further comprising:

the mobile device pre-emptively deactivates at least one selected IP session prior to changing the network area from the first network area to a second network area supporting fewer IP sessions than the first network area.

19. A method according to any one of claims 1 to 12 wherein each IP session is part of a corresponding PDP context.

20. An apparatus in a mobile device, comprising:

means for sending a request for a new internet protocol, IP, session;

means for receiving, in response to the request, an indication that the request cannot be fulfilled because the maximum number of IP sessions have been established for the mobile device;

means for causing the means for sending a request to not send any request for a new IP session when the maximum number of IP sessions is established after receiving the indication.

21. The apparatus of claim 20, further comprising:

means for determining a maximum number of IP sessions supported for the mobile device based on the indication.

22. The apparatus of claim 21, further comprising:

means for managing IP sessions according to a maximum number of IP sessions supported for the mobile device.

23. The apparatus of claim 20, wherein:

the apparatus for sending a request includes: means for sending a plurality of requests in an attempt to establish a simultaneous IP session;

the apparatus for receiving an indication includes: means for receiving responses to the plurality of requests; and

the apparatus further comprises: a maximum number of devices supported IP sessions is determined based on an attempt to establish an IP session and a response to the attempt.

24. The apparatus of claim 23, wherein the means for determining the maximum number of IP sessions supported further comprises:

means for establishing a default value for a maximum number of supported IP sessions based on a capacity of the wireless network.

25. The apparatus of claim 21, wherein the means for determining the maximum number of IP sessions supported further comprises:

means for performing a count of the number of simultaneous IP sessions that have been established.

26. The apparatus of claim 25, wherein the means for determining the maximum number of IP sessions supported further comprises:

means for setting the number of supported IP sessions to a count of the number of simultaneous IP sessions that have been established upon receiving a defined response to the attempt to establish an IP session.

27. The apparatus of claim 26, wherein the defined response is any one of:

packet data protocol "PDP" activation reject response with cause code 26;

service option with cause code 34 temporarily disorganizes the response;

PDP activation reject response with reason code 38;

PDP activation reject response with reason code 101;

a response requesting to deactivate another existing context;

a response requesting release of a radio bearer related to another existing context; or

Is specifically configured to indicate that no more PDP contexts are available.

28. The apparatus of claim 22, wherein the means for managing IP sessions based on the maximum number of IP sessions supported comprises:

means for establishing a supported number of IP sessions, and actively managing allocation of IP sessions with respect to the supported number of IP sessions when the IP sessions are less than the device function requiring the IP sessions.

29. The apparatus of claim 28, wherein the means for actively managing allocation of IP sessions comprises any one of:

means for setting a priority to the device function and allocating the IP session according to the priority; or

After changing the network area from the first network area to a second network area supporting a smaller number of IP sessions than the first network area, means for selectively determining which device function is assigned an IP session in the second network area, and if not established, establishing these IP sessions, and if not deactivated, deactivating other IP sessions.

30. The apparatus of claim 22, further comprising:

means for receiving a request from an application to establish a new IP session;

wherein the means for managing the IP session comprises: means for determining whether to request a new IP session from the wireless network based on the maximum number of IP sessions supported.

31. The apparatus of claim 22, further comprising:

means for setting a priority for the IP session;

wherein the means for managing the IP session comprises: means for maintaining a higher priority IP session before a lower priority IP session when the IP session is limited by the maximum number of supported IP sessions.