JP4629075B2 - System and method for determining that a maximum number of IP sessions has been established - Google Patents

Description

(Field of the Invention)
The present application relates generally to wireless communications, and in particular to IP sessions.

(Background of the present invention)
Communication between the mobile device and the corresponding node is processed in a UMTS (Universal Mobile Telecommunications System) network via a GPRS (General Packet Radio Service) server node. The GPRS server node includes an SGSN (Serving GPRS Support Node) and a GGSN (Gateway GPRS Support Node). Such a communication exchange between a mobile device and a corresponding node includes a communication exchange between the mobile device and the SGSN. Communication exchange, eg, user plane communication (ie, IP data traffic) between a mobile device and an SGSN node uses one or more PDP contexts. There may be many PDP contexts depending on how many different applications of the mobile device communicate with the PDP context. However, the number of PDP contexts for a mobile device can be limited by the number of PDP contexts supported in the routing area in which the mobile device exists.

  Different routing areas may support different numbers of PDP contexts. However, the mobile device is unaware of how many PDP contexts are in a given routing area that supports the mobile device. This can lead to undesirable situations. For example, the mobile device may request a new PDP context to be established without realizing that the maximum number of IP sessions has already been established. As a result, the mobile device may fail to establish a new PDP context. Further, in some examples, the mobile device does not realize why it failed to establish a new PDP context. If the mobile device is unaware of the maximum number of IP sessions supported for the mobile device, the mobile device cannot properly manage the PDP context. If more services using the PDP context are requested by the user than are supported by the network, a kind of multiplexing may occur (such as some services being delayed).

  A possible approach for mobile devices is to always assume that only one PDP context is supported. However, this approach misses when additional PDP contexts are supported. This can lead to dissatisfaction with users on networks where more than one PDP context is supported.

(Outline of the present invention)
(Item 1)
A method on a mobile device,
Sending at least one request of a predefined 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 has already been established for the mobile device;
Determining the maximum number of IP sessions supported for the mobile device in a given network area based on the instructions;
Managing IP sessions based on the maximum number of IP sessions supported for the mobile device.

(Item 2)
Sending the at least one request includes sending multiple requests in an attempt to establish a simultaneous IP session;
Receiving the instruction includes receiving responses to the plurality of requests,
Determining the maximum number of supported IP sessions is supported by the given network area based on the attempt to establish an IP session and the response to such an attempt. Including determining the number of IP sessions;
The method according to item 1.

(Item 3)
Determining the maximum number of IP sessions supported is
3. The method of item 2, further comprising establishing a default value for the maximum number of supported IP sessions based on the capabilities of the wireless network.

(Item 4)
Determining the maximum number of IP sessions supported is
4. A method according to any one of items 1 to 3, further comprising performing a count on how many simultaneous IP sessions are established.

(Item 5)
Determining the maximum number of IP sessions supported is
When a defined response to an attempt to establish an IP session is received, the number of IP sessions supported by the given network area is related to how many simultaneous IP sessions are established. 5. The method of item 4, further comprising setting to the count.

(Item 6)
The above defined response is
A packet data protocol “PDP” activation rejection response with cause code 26;
PDP activation rejection response with cause code 38;
PDP activation rejection response with cause code 101;
A response requesting deactivation of another existing context;
A response requesting the release of a radio bearer associated with another existing context;
6. A method according to item 5, wherein the response is any of a response specifically configured to indicate that there is no longer a PDP context available.

(Item 7)
Maintaining historical information indicating the maximum number of IP sessions supported by each network area for network areas already visited;
When moving to a new network area, if the new network area is listed in the history information, look in the history information for the maximum number of IP sessions supported by the network area; 7. The method of any of items 1-6, further comprising: determining the maximum number of IP sessions supported by the new network area.

(Item 8)
The above history information is for the network area.
Public land mobile network “PLMN” granularity,
8. The method of item 7, maintained at either of the granularity of PLMN and local area code “LAC” or the granularity of routing area code “RAC” and radio network controller identifier “RNC Id”.

(Item 9)
Prior to changing the network area from a first network area to a second network area where fewer IP sessions are supported than in the first network area, the mobile device is selected with at least one selected The method according to any one of items 1 to 8, further comprising preemptively inactivating the IP session.

(Item 10)
Based on the above maximum number of supported IP sessions, managing IP sessions
Once the maximum number of IP sessions supported by the current network area has been established, with respect to the number of supported IP sessions, there are fewer IP sessions than the device functions require, The method of item 1, comprising actively managing assignment of IP sessions.

(Item 11)
Actively managing the above assignment of IP sessions is
Prioritize device functions and assign the IP session by priority, or from a first network area to a second network area where fewer IP sessions are supported than in the first network area, After changing the network area, selectively determine which device functions to which the IP session in the second network area should be assigned, and if not already established, establish these and 11. A method according to item 10, comprising any of the following: inactivation of others when not activated.

(Item 12)
Receiving the above instructions
Receiving a response to the given request, the response including a cause code, since the cause code has already established the maximum number of IP sessions for the mobile device; 12. A method according to any one of items 1-11, comprising: indicating that the given request cannot be fulfilled.

(Item 13)
13. The method of item 12, wherein the cause code has a cause value of 102, the cause value indicating that the maximum number of IP sessions is already activated.

(Item 14)
The given request is an activation PDP context request for requesting a new PDP context to be established, and the response is an activation PDP context rejection for rejecting the activation PDP context request. Or
The given request is a PDP context service request for requesting a service for an existing PDP context, and the response is a denial of service for rejecting the PDP context service request;
The given request is an activation PDP context request for requesting a new PDP context to be established, and the response is a mobile terminal “MT” for deactivating an existing PDP context Whether it is a PDP deactivation request,
The given request is a routing area update “RAU” request to request a change to a new routing area, and the response is an MT PDP non-pass to inactivate an existing PDP context. Activation request,
14. The method according to item 12 or item 13.

(Item 15)
Further including accepting a request from the application to establish a new IP session;
Managing an IP session includes determining whether to request the new IP session from the wireless network based on the maximum number of supported IP sessions.
Item 15. The method according to any one of Items 1-14.

(Item 16)
Further including prioritizing IP sessions,
Managing IP sessions is to maintain high priority IP sessions prior to low priority IP sessions when the IP sessions are limited by the maximum number of IP sessions supported. Contains,
Item 15. The method according to any one of Items 1-14.

(Item 17)
The method according to any one of items 1 to 16, wherein each IP session is part of a respective PDP context.

(Item 18)
A computer-readable medium having computer-executable instructions stored thereon for execution on a processor of a computing device to implement the method of any one of items 1-17. A computer readable medium having instructions that can be executed.

(Item 19)
A mobile device,
A radio access radio configured to communicate with a wireless network;
An IP session management function, and the IP session management function includes:
Send at least one request of a predefined type,
Receiving an indication that the request of the at least one request cannot be satisfied because the maximum number of IP sessions has already been established for the mobile device;
Based on the indication, determining the maximum number of IP sessions supported for the mobile device in a given network area;
A mobile device configured to manage IP sessions based on the maximum number of IP sessions supported for the mobile device.

(Item 20)
A method in a wireless network, comprising:
When a predefined type of request is received from a mobile device residing in a given network area,
Determining whether there is a maximum number of IP sessions already established for the mobile device for the given network area;
Sending a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions is already established when the maximum number of IP sessions is already established; Including the method.

(Item 21)
The method of item 20, wherein the response includes a cause code, which indicates that the request cannot be satisfied because the maximum number of IP sessions has already been established. .

(Item 22)
Item 22. The method of item 21, wherein the cause code has a cause value of 102, and the cause value indicates that the maximum number of IP sessions is already activated.

(Item 23)
The request of the predefined type is an activation IP session request for requesting a new IP session to be established, and the response is an IP for rejecting the activation IP session request. Session rejection or
The request of the predefined type is an IP session service request for requesting a service for an existing IP session, and the response is an IP service rejection for rejecting the IP session service request. Is there
The request of the predefined type is an activation PDP context request to request a new PDP context to be established, and the response is a mobile to inactivate an existing PDP context Whether the terminal “MT” PDP deactivation request,
The request of the predefined type is a routing area update “RAU” request to request a change to a new routing area, and the response is to inactivate an existing PDP context MT PDP deactivation request
Item 23. The method according to any one of Items 20-22.

(Item 24)
24. A method according to any one of items 20-23, wherein each IP session is part of a respective PDP context.

(Item 25)
23. A method according to any one of items 20-22, wherein the computer-readable medium is computer-executable instructions stored thereon and is executed on a processor of a computing device or system. A computer-readable medium having instructions capable of implementing

(Item 26)
A wireless network having an IP session function,
The IP session function is
When a predefined type of request is received from a mobile device residing in a given network area,
Determining if there is a maximum number of IP sessions already established for the mobile device for the given network area;
If the maximum number of IP sessions has already been established, send a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has already been established. A configured wireless network.

(Item 27)
26. A method according to any one of items 22 to 25, wherein the computer-readable medium is computer-executable instructions stored thereon and is executed on a processor of a computing device or system. A computer-readable medium having instructions capable of implementing

(Item 28)
A wireless network having an IP session function,
The IP session function is
When a predefined type of request is received from a mobile device residing in a given network area,
Determining if there is a maximum number of IP sessions already established for the mobile device for the given network area;
If the maximum number of IP sessions has already been established, send a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has already been established. A configured wireless network.

(Item 29)
By using information identifying the number of IP sessions supported by a given network area, the mobile device has fewer IP sessions than the IP sessions that the device capability requires for the number of IP sessions supported Actively managing the assignment of IP sessions when there is only one.

(Item 30)
30. The method of item 29, wherein the IP session is a PDP context.

(Item 31)
The mobile device further includes determining information identifying a number of PDP contexts supported by the given network area, the determination comprising:
The mobile device attempts to establish a PDP context while in the given network area and receives a response to such an attempt;
Based on the attempt to establish a PDP context and the response to such an attempt, the mobile device establishes the number of PDP contexts supported by the given network area, Or
31. The method of item 30, wherein the mobile device is made by receiving the information from the given network area.

(Item 32)
The method of item 30, further comprising: the mobile device is pre-configured with information for a plurality of network areas.

(Item 33)
Further comprising each of the plurality of mobile devices determining the number of PDP contexts supported by the network area visited by the mobile device and making this information available to the plurality of mobile devices. The method according to item 30.

(Item 34)
The method of item 30, further comprising the mobile device determining information identifying a number of PDP contexts supported by the given network area by executing a database query.

(Item 35)
35. A computer-readable medium having computer-executable instructions stored thereon and executing on a processor, the method of any one of items 30-34 can be implemented. A computer readable medium having instructions.

(Item 36)
A mobile device,
A radio access radio configured to communicate with a wireless network;
An IP session management function, and the IP session management function includes:
By using information identifying the number of IP sessions supported by a given network area, there are fewer IP sessions with respect to the number of IP sessions supported than the IP sessions required by the device function A mobile device configured to actively manage IP session assignments.

  Systems and methods are provided for determining that a maximum number of IP sessions has been established. A mobile device may send a request to a wireless network. According to one aspect, if the maximum number of IP sessions is already established for the mobile device, the wireless network sends a response indicating that the request cannot be satisfied. The mobile device determines that the maximum number of IP sessions is already established based on the response. This allows the mobile device to determine the maximum number of IP sessions that can be supported so that IP sessions can be managed accordingly.

(Overview)
According to a broad aspect, a method in a mobile device is provided, the method sending at least one request of a predefined type; a maximum number of Internet Protocol “IP” sessions to the mobile device Receiving an indication that a given request of at least one request cannot be fulfilled because is already established; based on the indication, supported for mobile devices in a given network area Determining the maximum number of IP sessions being managed; and managing IP sessions based on the maximum number of IP sessions supported for the mobile device.

  According to another broad aspect, a mobile device is provided, the mobile device comprising: a radio access radio configured to communicate with a wireless network; and an IP session management function; The management function: sends at least one request of a predefined type; the request of at least one request cannot be fulfilled because the maximum number of IP sessions has already been established for the mobile device Receiving an indication; based on the indication, determining a maximum number of IP sessions supported for the mobile device in a given network area; based on the maximum number of IP sessions supported for the mobile device Configured to manage IP sessions To have.

  In accordance with another broad aspect, a method in a wireless network is provided, wherein the method receives a predefined type of request from a mobile device residing in a given network area: a given network Determining whether there is a maximum number of IP sessions already established for the mobile device for the area; and if the maximum number of IP sessions is already established, the maximum number of IP sessions is Sending a response to the mobile device indicating that the request cannot be satisfied because it has already been established.

  According to another broad aspect, there is provided a wireless network with an IP session function, which receives: a predefined type of request from a mobile device residing in a given network area. When: Determines if there is a maximum number of IP sessions already established for the mobile device for a given network area; if the maximum number of IP sessions is already established, It is configured to send a response to the mobile device indicating that the request cannot be satisfied because the maximum number of sessions has already been established.

  According to another broad aspect, there is provided a wireless network with an IP session function, which receives: a predefined type of request from a mobile device residing in a given network area. When: Determines if there is a maximum number of IP sessions already established for the mobile device for a given network area; if the maximum number of IP sessions is already established, It is configured to send a response to the mobile device indicating that the request cannot be satisfied because the maximum number of sessions has already been established.

  In accordance with another broad aspect, a method is provided that supports mobile devices by using information identifying the number of IP sessions supported by a given network area. Active management of IP session assignments when there are fewer IP sessions than the number of IP sessions needed by the device function.

  According to another broad aspect, a mobile device is provided, the mobile device comprising: a radio access radio configured to communicate with a wireless network; and an IP session management function; Session management function: By using information identifying the number of IP sessions supported by a given network area, the number of IP sessions supported is less than the IP sessions that the device function requires It is configured to actively manage the assignment of IP sessions when only sessions exist.

(Wireless communication system)
Referring now to FIG. 1A, a block diagram of an exemplary wireless network 100 and mobile device 10 is shown. The wireless network 100 has a first routing area 30 and a second routing area 40. Other routing areas may exist, but for simplicity they are not shown. Each routing area has at least one RNC (Radio Network Controller). In the illustrated example, the first routing area 30 has a first RNC 31 and a second RNC 32, while the second routing area 40 has a single RNC 41. Yes. Each RNC 31, 32, 41 is associated with a respective RNC Id. The first RNC 31 and the second RNC 32 in the first routing area 30 have RNC Id 31a and RNC Id 32a, respectively, while the single RNC 41 in the second routing area 40 is RNC Id Id 41a. Each cell (not shown) in the RNC (via Node B) is hierarchically associated with RAI (Routing Area Identification). The RAI may include one or more cells and may bridge the RNC. In some implementations, each RAI may be a combination of country code, network code, and routing area code. The RAI can be different for other wireless networks.

  In the illustrated embodiment, each RNC 31, 32, 41 is coupled to a SGSN (Serving General Packet Radio Service Support Node) 50, which in turn is coupled to a GGSN (Gateway GPRS Support Node) 60. This is then coupled to a PDN (Packet Data Network) 70. The PDN 70 can be, for example, the Internet. SGSN 50 has an IP session function 51 coupled to processor 52 and may have other components, which are not shown for simplicity.

  Wireless network 100 is shown with a single mobile device, namely mobile device 10. There may be other mobile devices, but they 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, which is coupled to a radio access radio 11, an IP session management function 13, an application 14, and a user interface 15. Mobile device 10 may include other components, which are not shown for simplicity. Referring back to FIG. 1A, the mobile device 10 is now located in 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 configured to communicate with the wireless network 100 by using its wireless access radio 11. Such communication can be, for example, voice communication, electronic messaging, or any other suitable form of communication supported by application 14. At least some communication with the wireless network 100 is via one or more IP sessions between the mobile device 10 and the SGSN 50. A PDP (Packet Data Protocol) session is an example of an IP session. There can be many IP sessions between the mobile device 10 and the SGSN 50 depending on how many applications 14 have established IP sessions. However, the number of IP sessions is typically limited by the routing area in which the mobile device 10 is present, which is here the first routing area 30.

  There are examples where the mobile device 10 sends a predefined type of request, for example, an Activate IP Session Request or an IP Session Service Request. The wireless network 100 receives the request and determines whether there is a maximum number of IP sessions already established for the mobile device 10. In accordance with an embodiment of the present application, the IP session function 51 implements the method in the wireless network 100, so that the wireless network 100 if the maximum number of IP sessions has already been established for the mobile device 10. Can send a response indicating that the request cannot be satisfied because the maximum number of IP sessions has already been established. The mobile device 10 receives the response. According to another embodiment of the present application, the IP session management function 13 implements the method in the mobile device 10 and as a result determines based on the response that the maximum number of IP sessions has already been established. To do. This allows the mobile device 10 to determine the maximum number of IP sessions that can be supported, so that the IP sessions can be managed accordingly by the mobile device 10. Further details are provided below with reference to FIGS.

  In the illustrated example, it is assumed that the same number of IP sessions are supported for the mobile device 10 regardless of how many RNCs exist within each routing area. Typically, the routing area has a single RNC. This is the case for the second routing area 40, for example. The number of IP sessions supported for a given mobile device is here limited by the RNC. Thus, although the limiting factor is actually the RNC, typically the routing area can be considered as the limiting factor. However, a routing area may have more than one RNC. This is the case for the first routing area 30, for example. Thus, it is possible for a mobile device that the routing area supports a different number of PDP contexts depending on where the mobile device is in the routing area. In this case, the routing area cannot be regarded as a limiting factor. Although the examples presented herein refer to a “routing area” as limiting the number of IP sessions to a mobile device, a more general “area” of a network is an IP session to a mobile device. It should be understood that the number of An “area” can be a routing area, eg, a part of a routing area defined by an RNC Id, a network, a cell Id, or any other area, in which the mobile device The number of IP sessions supported is limited.

  In some implementations, there is a subtlety between the connected / active state (CELL_DCH, CELL_FACH) and the idle state (CELL_PCH, URA_PCH, IDLE) for mobile devices. While the routing area is known to the mobile device during idle state, the RNC id is typically not known. During the idle state, the mobile device transitions to the combined / active state to find its server RNC id. This can waste battery life and the like. Thus, in some implementations, the number of supported IP sessions is considered for the routing area, regardless of whether this is the lowest level of granularity.

  There are many possibilities for the IP session management function 13 of the mobile device 10. In the illustrated example, the IP session management function 13 is implemented as software and executed 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 example, the IP session management function 13 is shown as a single component. More generally, however, the IP session management function 13 may be implemented as one or more components. An example where the IP session management function 13 includes more than one component is described below.

  In some implementations, the IP session management function 13 includes NAS (Non Access Stratum) and AS (Access Stratum). The NAS includes a session management layer and manages IP sessions. The NAS may issue an active PDP context request message to be sent to the SGSN 50, for example. The AS manages the radio interface of the radio access radio 11 and includes a respective RAB (Radio Access Bearer) for each active IP session. RAB is an identifier for an RF (Radio Frequency) pipe. There may be a dormant IP session without each RAB. The AS may, for example, issue a service request message to be sent to the RNC.

  There are many possibilities for the IP session function 51 of the wireless network 100. In the illustrated example, the IP session function 51 may be implemented as software and executed on the processor 52. More generally, however, the IP session function 51 may be implemented as software, hardware, firmware, or any combination thereof. In the illustrated example, 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 SGSN 50 or may be implemented separately from the SGSN 50. One or more components may be distributed across the wireless network 100 or may be in a common location. Other implementations are possible.

  There are many possibilities for the wireless network 100. In the illustrated example, the wireless network 100 is a UMTS (Universal Mobile Telecommunications System) network. More generally, however, the wireless network 100 can be any wireless network in which the routing area limits how many IP sessions can be established for a given mobile device.

  There are many possibilities for the mobile device 10. Referring now to FIG. 1C, a block diagram of another mobile device 80 is shown, which may implement any method described herein. It should be understood that the mobile device 80 is shown with very specific details for illustrative purposes only.

  The processing device (microprocessor 128) is shown schematically coupled between the keyboard 114 and the display 126. Microprocessor 128 controls the operation of display 126 as well as the overall operation of mobile device 80 in response to user activation of keys on keyboard 114.

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

  In addition to the microprocessor 128, other parts of the mobile device 80 are shown schematically. These include: communications subsystem 170; short-range communications subsystem 102; keyboard 114 and display 126, and other input / output devices (a set of LEDs 104, a set of auxiliary I / O devices 106, a serial port) 108, speaker 111, and microphone 112); further memory devices (including flash memory 116 and random access memory (RAM) 118); various other device subsystems 120. The mobile device 80 can have a battery 121 that can power an active element of the mobile device 80. The mobile device 80 is a bi-directional radio frequency (RF) communication device having voice and data communication capabilities in some embodiments. In addition, in some embodiments, mobile device 80 has the ability to communicate with other computer systems over the Internet.

  The operating system software executed by the microprocessor 128 may be stored in a persistent storage device, such as flash memory 116, in some embodiments, although other types of memory devices, such as read only memory ( ROM) or other similar storage element. In addition, system software, specific device applications, or portions thereof may be temporarily loaded into volatile storage, such as RAM 118, for example. Communication signals received by mobile device 80 can also be stored in RAM 118.

  In addition to its operating system functions, the microprocessor 128 can also execute software applications on the mobile device 80. A predetermined set of software applications that control basic device operations, such as voice communication module 130A and data communication module 130B, may be attached to mobile device 80 during manufacture. In addition, a personal information manager (PIM) application module 130C may also be attached to the mobile device 80 during manufacture. A PIM application can organize and manage data items in some embodiments, such as email, calendar events, voice mail, appointments, and task items. The PIM application may also send and receive data items over the wireless network 110 in some embodiments. In some embodiments, the data items managed by the PIM application are stored via the wireless network 110 and are stored in the device user's corresponding data items (stored in or associated with the host computer system). Are seamlessly integrated, synchronized, and updated. Similarly, additional software modules (shown as another software module 130N) may be installed during manufacture.

  Communication functions including data communication and voice communication are performed via the communication subsystem 170 and, in some cases, are performed via the short-range communication subsystem 170. Communication subsystem 170 includes a receiver 150, a transmitter 152, and one or more antennas, which are illustrated as receive antenna 154 and transmit antenna 156. In addition, the communication subsystem 170 also includes a processing module, such as a digital signal processor (DSP) 158, a local oscillator (LO) 160, for example. The specific design and implementation of the communication subsystem 170 depends on 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 operate in a mobile data communication network of Mobitex®, DataTAC®, or General Packet Radio Service (GPRS), and any Various voice communication networks, for example, Advanced Mobile Phone Service (AMPS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Personal Communication Services (CDMA), and Personal Communication BTS (Personal Communication). Also to be designed. Other types of data networks and voice networks (both separate or integral) may also be utilized with mobile device 80.

  Network access may vary depending on the type of communication system. For example, in the Mobitex® and DataTAC® networks, mobile devices can be registered on the network by using a unique PIN (Personal Identification Number) associated with each device. However, in GPRS networks, network access is typically associated with device subscribers or users. Thus, GPRS devices typically have a subscriber identity module for operation over a GPRS network, which is commonly referred to as a subscriber identity module (SIM) card. .

  Once the network registration or activation procedure is complete, the mobile device 80 may transmit and receive communication signals over the communication network 110. Signals received from communication network 110 by receive antenna 154 are routed to receiver 150, which provides signal amplification, frequency down conversion, filtering, channel selection, etc., and also provides analog to digital conversion. obtain. Analog to digital conversion of the received signal allows the DSP 158 to perform more complex communication functions (eg, demodulation and decoding). Similarly, signals to be transmitted to the network 110 are processed (eg, modulated and encrypted) by the DSP 158 and then digital to analog conversion, frequency up conversion, filtering, amplification, and a communication network via the transmit antenna 156. Provided to transmitter 152 for transmission to 110 (or multiple networks).

  In addition to processing communication signals, DSP 158 provides control of receiver 150 and transmitter 152. For example, the gain applied to the communication signal at receiver 150 and transmitter 152 may be adaptively controlled via a gain control algorithm implemented on DSP 158.

  In the data communication mode, the received signal (eg, 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 or output to some other auxiliary I / O device 106 for output to the display 126. The device user may also use a data item (e.g., a touch pad, rocker switch, thumbwheel, or some other type of input device) using the keyboard 114 and / or some other auxiliary I / O device 106 (e.g., touchpad, rocker switch, thumbwheel, or some other type of input device). email message). Thereafter, the configured data item may be transmitted over the communication network 110 via the communication subsystem 170.

  In the voice communication mode, the overall operation of the device is substantially the same as that in the data communication mode except that the received signal is output to the speaker 111 and the signal for transmission is generated by the microphone 112. It is similar. Alternative voice or audio auxiliary I / O subsystems, such as a voice message recording subsystem, may also be implemented on the mobile device 80. In addition, the display 126 may also be utilized in a voice communication mode, such as displaying the caller's identity, displaying the duration of the voice call, or displaying other voice call related information. .

  The short range communication subsystem 102 enables communication between the mobile device 80 and other nearby systems or devices. These do not necessarily have to be similar devices. For example, the short-range communication subsystem may include infrared devices, related circuitry and related components, or Bluetooth® communication modules to provide communication with similarly usable systems and devices.

(Method on mobile device)
Referring now to FIG. 2, a flowchart of an exemplary method for determining that a maximum number of IP sessions has already been established is shown. This method may be implemented in 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.

  In step 2-1, the mobile device transmits a predefined type of request. 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 has already been established for the mobile device. The wireless network sends a response, which is received by the mobile device in step 2-2. The response indicates that the request cannot be satisfied because the maximum number of IP sessions has already been established for the mobile device. In step 2-3, the mobile device determines that the maximum number of IP sessions has already been established based on the response.

  There are many ways in which the response may indicate that the request cannot be satisfied because the maximum number of IP sessions has already been established for the mobile device. In some implementations, the response includes a cause code, which indicates that the request cannot be satisfied because the maximum number of IP sessions has already been established for the mobile device. To do. More generally, the response may include any suitable indication that the request cannot be satisfied because the maximum number of IP sessions has already been established for the mobile device.

  Referring now to FIGS. 3A and 3B, a table of exemplary GMM cause information elements is shown. It should be understood that the cause information element of the GMM shown in the illustrated example is a specific implementation of the cause code for illustrative purposes only. The purpose of the GMM cause information element is to indicate the reason for why the GMM request from the mobile device was rejected by the wireless network. As shown in FIG. 3A, the cause of GMM is a type 3 information element of two octets length. The second octet is for the cause value. There are many possible cause values, as shown in FIG. 3B. The cause value “01100110” indicates that the maximum number of PDP contexts has already been activated. In some embodiments, the cause value is part of the cause associated with PLMN-specific network failures and congestion / authentication failures.

  Referring now to FIGS. 4A and 4B, a table of exemplary SM cause information elements is shown. It should be understood that the SM cause information element shown in the illustrated example is a specific implementation of the cause code, for illustrative purposes only. The purpose of the SM cause information element is to indicate the reason for why the session management request was rejected. As shown in FIG. 4A, the cause of the SM is two octet length type 3 information elements. The second octet is for the cause value. There are many possible cause values, as shown in FIG. 4B. The cause value “01100110” indicates that the maximum number of PDP contexts has already been activated. In some embodiments, the cause value is part of a GPRS specific cause value for GPRS session management.

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

  There are many possibilities for predefined types of requests and responses. In some implementations, the type of response depends on the type of request. Examples are provided below.

  In one example, the request can be an Activate IP Session Request to request a new IP session to be established, while the response is for rejecting an IP session request. , It can be an Activate IP Session Reject (Activate IP Session Reject). In some implementations, the activation IP session request is an Activate PDP context request, while the response is an Activation PDP context Reject.

  In another example, the request is an IP session service request (IP session service request) for requesting a service for an existing IP session, while the response is for rejecting an IP session service request. IP Service Reject (IP Service Reject). 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 activation PDP context request to request a new PDP context to be established, while the response is an MT PDP inactivity to inactivate an existing PDP context. Request (MT PDP Deactivate Request). This can occur, for example, when a mobile device sends an activated PDP context request in an area that does not support enough PDP context to satisfy the request. In this example, the request is considered unsatisfied because no new PDP context was initially established in response to the activation PDP context request. However, in some implementations, after the existing PDP context is deactivated, the requested new PDP context will be established.

  In another example, the request is a RAU request that requests a change to a new routing area, while the response is an MT PDP deactivation request to deactivate an existing PDP context. It is. This can occur, for example, when a mobile device sends a RAU request after moving to a new routing area that does not support enough PDP contexts to satisfy the request. Other requests and corresponding requests are possible.

  Above, exemplary messages for responding to requests have been provided. In some implementations, the message is based on the message defined in 3GPP (3rd Generation Partnership Project) TS 24.008 V7.5.0, and the maximum number of IP sessions to the mobile device is already Appropriate modifications have been made to indicate that the request cannot be satisfied because it has been established. Other implementations are possible.

  In some implementations, the type of request depends on the type of mobile device. For example, the type of request may vary depending on whether the mobile device is in an idle state compared to an active / coupled state. In some implementations, the mobile device may request service for an existing IP session during the active / binding state by sending an IP session service request message. However, in some implementations, the mobile device never sends an IP session service request message while idle. In some implementations, a predefined type of request is sent only while the mobile device is in the active / coupled state. Other implementations are possible.

  In some implementations, the mobile device manages IP sessions based on the maximum number of IP sessions that can be supported for the mobile device. One example is provided with reference to FIG. 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. In step 5-2, the mobile device manages the IP session based on the maximum number of IP sessions that can be supported for the mobile device.

  There are many ways for a mobile device to determine the maximum number of IP sessions that can be supported. In some implementations, how the mobile device determines the maximum number of IP sessions that can be supported depends on a predefined type of request. For example, if the request is an activation PDP context request and the mobile device is aware of the number of IP sessions established prior to the request, the request has been established because the maximum number of IP sessions has already been established. Upon receiving a response indicating that cannot be satisfied, the mobile device may determine that the maximum number of IP sessions that can be supported is equal to the number of IP sessions established prior to the request. There are other possibilities for determining the maximum number of IP sessions that can be supported. Other examples are provided below with reference to FIG.

  There are many ways in which a mobile device can manage IP sessions based on the maximum number of IP sessions that can be supported for the mobile device. An example is provided below with reference to FIGS. It should be understood that these examples are specific and intended for illustrative purposes only. Other implementations are possible.

  Referring first to FIG. 6, in step 6-1, the mobile device accepts a request from an application to establish a new IP session. The application can be any application configured to run on a mobile device, and the mobile device is configured to communicate over an IP session. In 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. The mobile device requests a new IP session only if, for example, the maximum number of IP sessions established is less than the maximum number of IP sessions that can be supported for the mobile device.

  Referring now to FIG. 7, in step 7-1, the mobile device prioritizes the IP session. In step 7-2, the mobile device sends a higher priority IP 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. Maintain a session.

  It should be understood that an IP session is indicated as being a “higher” priority IP session, usually when its priority is indicated as higher than other IP sessions. In some implementations, this is the highest priority IP session. An IP session indicated as having a higher priority is not necessarily a high priority IP session, but nevertheless has a higher priority than other IP sessions. Have been instructed.

  There are many ways in which mobile devices can prioritize IP sessions. In some implementations, the mobile device accepts user input to determine a respective priority for each IP session. The mobile device determines the appropriate priority for each IP session based on user input. In other implementations, the mobile device maintains a record of predefined priority levels for each predefined type of IP session. Based on the record, the mobile device determines the priority for each IP session accordingly. Other implementations are possible.

(Another method on mobile devices)
In a specific example of how to establish a PDP context, when a GPRS mobile phone sets up a PDP context, an access point name (APN) is determined and the access point is used in a DNS query for a private DNS network. This process (referred to as APN resolution) ultimately gives the IP address of the GGSN that can serve the access point. At this point, the PDP context can be activated.

  GPRS and UMTS networks have a limit on the number of simultaneous PDP contexts supported. The number of PDP contexts may vary as the mobile device moves between different parts of the network or between different networks. Here, no information is provided to the mobile device informing the mobile device of the number of supported PDP contexts. As a result, the mobile device meets the needs of the second area (here, the mobile device needs) from the first area (here, sufficient PDP contexts are supported to meet the needs of the mobile device). The network may drop one or more of the existing PDP contexts in an unpredictable manner when moving to (not enough PDP contexts are supported). This problem can occur particularly in UMTS networks. This is because many things support only one PDP context. In such a network, only one device function may have connectivity at the same time, so an always-on device function (eg, push email) may be a WAP (wireless access) that surfs a particular APN in the network. (point) cannot operate simultaneously.

An event-based method is provided to determine the number of PDP contexts in a given network area. The network area can be the entire network or part of the network. The following are specific examples of events that can occur when more than the supported number of PDP contexts are activated:
MT PDP deactivation request;
PDP activation reject (PDP Active Reject).

  In some embodiments, the cause code in the message is used to allow a distinction between inactivation and rejection for other legitimate reasons. When any of these events occur with the correct cause code, the number of activated PDP contexts is counted and stored as a watermark for the number of PDP contexts supported by the network. Is done. In some embodiments, the step of determining the number of supported PDPs can be actively performed at startup (ie, at discovery) or in the background when a different APN is requested. Can be done.

  Referring to FIG. 8, a flowchart of a method for determining the number of supported PDP contexts is shown. This method may be implemented in 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. In step 8-1, the mobile device attempts to establish a simultaneous PDP context for a given network area and receives a response to such an attempt. In step 8-2, based on the attempt to establish a PDP context and the response to such an attempt, the mobile device determines the number of PDP contexts supported by a given network area.

  In some embodiments, a default value for the number of PDP contexts supported by the network area is used, which is based on the capabilities of the wireless network. Such a default may also represent the maximum number of PDP contexts that the network can support from the point of view of a given device. For example, if a given mobile device supports up to 6 PDP contexts, the default value is initially 6, which causes the device to attempt to establish many simultaneous contexts and fails At the end, it can be reduced.

  In some embodiments, establishing the number of PDP contexts supported by a given network area includes performing a count on how many simultaneous PDP contexts are established. This can be done continuously as new contexts are added. Alternatively, the count may be performed after one of the scenarios occurs indicating that no more context is supported.

  In some embodiments, determining the number of PDP contexts supported by a given network area includes looking for a specific defined response to an attempt to establish a PDP context. Once such a defined response is received, as a result, the latest attempt to establish a PDP context attempts to establish one more PDP context than is supported by the current network. It was an attempt. In this way, the number of PDP contexts supported by a given network area may be set to the number of simultaneous PDP contexts that are established. This may include noting the ongoing count performed, or performing the count when a defined response is received.

The set of one or more defined responses that can trigger the above behavior is implementation specific. The following is a specific defined set of responses, one or more of which may be implemented:
PDP activation rejection response with cause code 26;
PDP activation rejection response with cause code 38;
PDP activation rejection response with cause code 101;
A response requesting deactivation of another existing context;
A response requesting the release of a radio bearer associated with another existing context;
A response specifically configured to indicate that there are no more available PDP contexts.

  Referring now to FIG. 9, a flowchart of a method for maintaining history information is shown. This method may be implemented in 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. In step 9-1, for network areas that have already been visited, the mobile device maintains historical information indicating the number of PDP contexts supported by each network area. In step 9-2, if the network area is listed in the history information, each time there is a change in the network area, the mobile device determines the number of PDP contexts supported by the network area in the history information. Check, otherwise, establish the number of PDP contexts supported by the new network area.

  Referring now to FIG. 10, an example format table 200 is shown in which history information can be maintained. The table 200 has a first column 202 for storing network area identifiers and a second column 204 for storing the number of supported PDP contexts. A general entry in the above table is indicated at 206. Context support information can be maintained at the granularity of the network area defined on an implementation specific basis. In some embodiments, the granularity is maintained at the PLMN identifier granularity and an exemplary record is indicated at 208. In some embodiments, the granularity is maintained at the granularity of a combination of PLMN and LAC (local area code), an exemplary record is indicated at 210. In some embodiments, the granularity is maintained at the granularity of a combination of RAC (routing area code) and RNC ID, and exemplary recording is indicated at 212. Alternatively, other particle sizes can be used. The granularity does not necessarily have to be consistent across the entire network area.

(Context management based on the number of supported contexts)
In some embodiments, once the number of supported contexts has been determined, this information can be taken into account, for example by controlling which PDP contexts are activated and deactivated. To make the behavior more predictable. Context management is particularly useful when there are fewer PDP contexts than the PDP contexts that the device function requires.

  Referring now to FIG. 11, a flowchart of an exemplary method for managing an IP session is shown. This method may be implemented in 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. In step 11-1, by using information identifying the number of IP sessions supported by a given network area, the mobile device can determine the IP that the device function needs with respect to the number of IP sessions supported. When there are fewer IP sessions than sessions, IP session assignment is actively managed.

  The number of contexts can be determined by using any of the methods described above. More generally, the mobile device must somehow determine the number of supported contexts or be aware of the number of supported contexts. For example, in some embodiments, a mobile device receives context support information from a given network area, for example when the mobile device is initially connected at a given network area. In some embodiments, the mobile device is preconfigured with context support information for multiple network areas. 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 executing a database query.

  In one example of context management, before changing a network area from a first network area to a second network area (less PDP contexts are supported than in the first network area), the mobile device Preemptively deactivate at least one selected PDP context. For example, if a specific first PDP context must be maintained, but it is known that a second PDP context can be dropped, dropping the second PDP context before changing the network area This increases the chance that the first PDP context is not dropped after changing the network area. This example assumes that the following network history information is available.

  In some embodiments, actively managing PDP context assignments includes prioritizing device functions and assigning PDP contexts by priority.

  In some embodiments, after changing the network area from the first network area to the second network area (less PDP contexts are supported than in the first network area), the mobile device Selectively determine which device capabilities are to be assigned a PDP context in the second network area, if they are not already established, let them be established, and if not already deactivated Inactivate others. New network behavior may become unpredictable after moving from a first network area to a second network area (less supported contexts). Basically, this approach involves performing a move, then evaluating which device function is a given PDP context and which device function is not a given PDP context, and then establishing a context And / or making any necessary adjustments by inactivation.

  The method outlined above may find applications in intra-RAT (radio access technology) scenarios (eg, WCDMA / UTMS networks) as well as in inter-RAT scenarios (eg, GPRS to UMTS handover).

  The above description assumes that what is determined and then to be managed in any application is the number of concurrent PDP contexts supported. More generally, a similar approach can be used to determine the number of concurrent IP sessions supported, and a PDP context is a specific example of an IP session.

(Method in wireless network)
Referring now to FIG. 12, a flowchart of an exemplary method for sending a response indicating that a request cannot be satisfied because the maximum number of IP sessions has already been established is shown. This method may be implemented in a wireless network, for example, by the IP session function 51 of the wireless network 100 shown in FIG. 1A.

  The steps in the flowchart are performed upon receiving a predefined type of request from a mobile device. In step 12-1, the wireless network determines whether a maximum number of IP sessions has already been established for the mobile device. In step 12-2, if the maximum number of IP sessions is already established for the mobile device, the wireless network responds indicating that the request cannot be satisfied because the maximum number of IP sessions has already been established. To the mobile device.

  There can be many ways in which the response may indicate that the request cannot be satisfied because the maximum number of IP sessions has already been established for the mobile device. Since an example has already been presented above, it will not be repeated here.

  There are many possibilities for predefined types of requests and responses. Examples have already been presented above and are therefore not repeated here.

(IP session)
In the example presented above, an IP session is described. It should be understood that there are many possibilities for IP sessions. The IP session is, for example, 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 NetworkLIP), or a DUN (Dial-Up Networking IP) session. It includes any IP session among Base Services (IP) sessions, IP modem IP sessions, and PTT (Push-to-Talk) IP sessions. The nature of the IP session is implementation specific and is typically dependent on the wireless network. In some implementations, 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 invention are possible in light of the above teachings. Accordingly, it is to be understood that this application may be practiced within the scope of the appended claims, even if not specifically described herein.

Embodiments are described with reference to the accompanying drawings.
FIG. 1A is a block diagram of an exemplary 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 flowchart of an exemplary method for determining that a maximum number of IP sessions has already been established. FIG. 3A is a table of exemplary GMM cause information elements. FIG. 3B is a table of exemplary GMM cause information elements. FIG. 4A is a table of exemplary SM cause information elements. FIG. 4B is a table of exemplary SM cause information elements. FIG. 5 is a flowchart of an exemplary method for managing IP sessions based on the maximum number of IP sessions that can be supported for a mobile device. FIG. 6 is a flowchart of an exemplary method for managing IP sessions based on the maximum number of IP sessions that can be supported for a mobile device. FIG. 7 is a flowchart of an exemplary method for managing IP sessions based on the maximum number of IP sessions that can be supported for a mobile device. FIG. 8 is a flowchart of a method for determining the number of supported PDP contexts. FIG. 9 is a flowchart of a method for maintaining history information. FIG. 10 is a table of an exemplary format in which the history method can be maintained. FIG. 11 is a flowchart of an exemplary method for managing IP sessions. FIG. 12 is a flowchart of an exemplary method for sending a response indicating that a request cannot be satisfied because the maximum number of IP sessions has already been established.

Claims (28)

A method on a mobile device,
Sending at least one request of a predefined 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 has already been established for the mobile device;
Determining the maximum number of IP sessions supported for the mobile device in a given network area based on the instructions;
Managing IP sessions based on the maximum number of IP sessions supported for the mobile device. Sending the at least one request includes sending a plurality of requests in an attempt to establish a simultaneous IP session;
Receiving the indication includes receiving a response to the plurality of requests;
Determining the maximum number of IP sessions supported is supported by the given network area based on the attempt to establish an IP session and the response to such an attempt. Including determining the number of IP sessions;
The method of claim 1. Determining the maximum number of IP sessions supported is
Based on the ability of the non-linear network, supported and further comprise possible to establish a default value of outermost large numbers of IP sessions The method of claim 2. Determining the maximum number of IP sessions supported is
The method according to any one of claims 1 to 3, further comprising performing a count as to how many simultaneous IP sessions are established. Determining the maximum number of IP sessions supported is
When a defined response to an attempt to establish an IP session is received, the number of IP sessions supported by the given network area is related to how many simultaneous IP sessions are established. The method of claim 4, further comprising setting to the count. The defined response is
A packet data protocol “PDP” activation rejection response with cause code 26;
PDP activation rejection response with cause code 38;
PDP activation rejection response with cause code 101;
A response requesting deactivation of another existing context;
A response requesting the release of a radio bearer associated with another existing context;
6. The method of claim 5, wherein the response is one of: a response specifically configured to indicate that there is no more PDP context available. Maintaining historical information indicating the maximum number of IP sessions supported by each network area for network areas already visited;
When moving to a new network area, if the new network area is listed in the history information, look in the history information for the maximum number of IP sessions supported by the network area; 7. The method of claim 1, further comprising: determining the maximum number of IP sessions supported by the new network area. The history information is for the network area.
Public land mobile network “PLMN” granularity,
The method of claim 7, wherein the method is maintained at one of: PLMN and local area code “LAC” granularity, or routing area code “RAC” and radio network controller identifier “RNC Id” granularity. Prior to changing the network area from a first network area to a second network area where fewer IP sessions are supported than in the first network area, the mobile device is selected with at least one selected The method according to claim 1, further comprising preemptively inactivating the IP session. Based on the maximum number of supported IP sessions, managing IP sessions
Once the maximum number of IP sessions supported by the current network area has been established, with respect to the number of supported IP sessions, there are fewer IP sessions than the device functions require, The method of claim 1, comprising actively managing IP session assignments. Actively managing the assignment of IP sessions is
Prioritize device functions and assign the IP session by priority, or from a first network area to a second network area where fewer IP sessions are supported than in the first network area, After changing the network area, selectively determine which device functions to which the IP session in the second network area should be assigned, and if not already established, establish these and 11. The method of claim 10, comprising any of the following: inactivating others when not activated. Receiving the instruction is:
Receiving a response to the given request, the response including a cause code, since the cause code has already established the maximum number of IP sessions for the mobile device; 12. A method according to any one of the preceding claims, comprising indicating that the given request cannot be fulfilled.   The method of claim 12, wherein the cause code has a cause value of 102, the cause value indicating that the maximum number of IP sessions is already activated. The given request is an activation PDP context request for requesting a new PDP context to be established, and the response is an activation PDP context rejection for rejecting the activation PDP context request Or
The given request is a PDP context service request for requesting a service for an existing PDP context, and the response is a denial of service for rejecting the PDP context service request;
The given request is an activation PDP context request for requesting a new PDP context to be established, and the response is a mobile terminal “MT” for deactivating an existing PDP context Whether it is a PDP deactivation request,
The given request is a routing area update “RAU” request to request a change to a new routing area, and the response is an MT PDP non-pass to inactivate an existing PDP context. Activation request,
14. A method according to claim 12 or claim 13. Further including accepting a request from the application to establish a new IP session;
Managing an IP session includes determining whether to request the new IP session from the wireless network based on the maximum number of supported IP sessions.
15. A method according to any one of claims 1-14. Further including prioritizing IP sessions,
Managing IP sessions is to maintain high priority IP sessions before low priority IP sessions when IP sessions are limited by the maximum number of IP sessions supported. Contains,
15. A method according to any one of claims 1-14.   The method according to claim 1, wherein each IP session is part of a respective PDP context.   18. A method as claimed in any one of the preceding claims by being executed on a processor of a computing device, computer-readable instructions stored on the computer-readable medium. A computer-readable medium having instructions that can be implemented. A mobile device,
A radio access radio configured to communicate with a wireless network;
An IP session management function, and the IP session management function includes:
Send at least one request of a predefined type,
Receiving an indication that the request of the at least one request cannot be satisfied because the maximum number of IP sessions has already been established for the mobile device;
Based on the indication, determining the maximum number of IP sessions supported for the mobile device in a given network area;
A mobile device configured to manage IP sessions based on the maximum number of IP sessions supported for the mobile device. A method in a wireless network, comprising:
When a predefined type of request is received from a mobile device residing in a given network area,
Determining whether there is a maximum number of IP sessions already established for the mobile device for the given network area;
Sending a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions is already established when the maximum number of IP sessions is already established; Including the method.   21. The response of claim 20, wherein the response includes a cause code, the cause code indicating that the request cannot be satisfied because the maximum number of IP sessions has already been established. Method.   The method of claim 21, wherein the cause code has a cause value of 102, the cause value indicating that the maximum number of IP sessions is already activated. The request of the predefined type is an activation IP session request for requesting a new IP session to be established, and the response is an IP for rejecting the activation IP session request. Session rejection or
The request of the predefined type is an IP session service request for requesting a service for an existing IP session, and the response is an IP service rejection for rejecting the IP session service request. Is there
The request of the predefined type is an activation PDP context request to request a new PDP context to be established, and the response is a mobile to inactivate an existing PDP context Whether the terminal “MT” PDP deactivation request,
The request of the predefined type is a routing area update “RAU” request to request a change to a new routing area, and the response is to inactivate an existing PDP context MT PDP deactivation request
23. A method according to any one of claims 20-22.   24. A method according to any one of claims 20 to 23, wherein each IP session is part of a respective PDP context.   23. A computer-readable medium, computer-executable instructions stored thereon, executed on a processor of a computing device or system, according to any one of claims 20-22. A computer readable medium having instructions capable of implementing a method. A wireless network having an IP session function,
The IP session function is
When a predefined type of request is received from a mobile device residing in a given network area,
Determining if there is a maximum number of IP sessions already established for the mobile device for the given network area;
If the maximum number of IP sessions has already been established, send a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has already been established. A configured wireless network. A computer-readable medium, a computer-executable instructions stored therein, by executing on a processor of a computing device or system, according to any one of claims 22 to 24 A computer readable medium having instructions capable of implementing a method. A wireless network having an IP session function,
The IP session function is
When a predefined type of request is received from a mobile device residing in a given network area,
Determining if there is a maximum number of IP sessions already established for the mobile device for the given network area;
If the maximum number of IP sessions has already been established, send a response to the mobile device indicating that the request cannot be satisfied because the maximum number of IP sessions has already been established. A configured wireless network.

Images