Packet radio network and method for activation of a packet data protocol context

[0001] The present invention relates to packet radio networks for communicating internet protocol packets to and / or from mobile user devices, such as, for example, a network operating in accordance with the GPRS (General Packet Radio System) standard. ).

Background of the Invention [0002] A GPRS standard has been developed to communicate internet packets through a radio access interface. The GPRS network can be created using a backbone network according to the GSM (Global System for Mobiles) or UMTS (Universal Mobile Telecommunications System) standard. GPRS supports packet services and tries to optimize radio resources to communicate packet data, e.g. Internet packets (IPs). GPRS provides a logical architecture that is related to the switching architecture of the mobile radio communication system.

[0003] In GPRS / UMTS networks, each mobile user device must establish at least one GPRS / UMTS communication session represented by a Packet Data Protocol (PDP) data context to send and receive data. Each GPRS / UMTS session is specific to the user's mobile device. Therefore, the mobile user device must work on its own specific PDP context to be able to send and receive data. In addition, the PDP context is determined for the type of internet packet data that the mobile user device sends for the GPRS / UMTS communication session. There are three different types of PDP contexts depending on the type of Internet Protocol connectivity set up by the user's mobile device:

• Point-to-point protocol • Internet protocol version 4 (IPv4) protocol • Internet Protocol version 6 (IPv6) protocol [0004] The version of the Internet Protocol applicable to the PDP context means that the mobile user device must set up the IPv4 protocol for the PDP context,

EP 1 861 982 B1 if it intends to send IPv4 Internet packets to the GPRS / UMTS network. Similarly, a mobile user device must set up an IPv6 protocol for the PDP context if it intends to send and receive IPv6 internet packets on the GPRS / UMTS network. This can cause inefficient use of communication resources in the packet radio network. In document XP002357851 "3GPP analysis- 07 (semi-) editorial issues" from December 10, 2003, by Juh Wiljakek, recommendations for mobile user devices with a dual Internet protocol stack in the IPv4 and IPv6 versions were disclosed to activate the IPv6 PDP context when communicating with an IPv6 peer and an IPv4 context when communicating with an IPv4 peer.

Summary of the Invention [0005] According to the present invention, a packet radio network is provided with a solution for communicating internet packets to and / or from a mobile user device. This packet radio network includes a gateway support node, a serving support node, and a radio network part. The gateway service node is used to provide a packet data protocol context to control the communication of internet packets to and / or from the radio network from and / or to the mobile user device via a packet communication medium. The transmission service node is used to control the communication of internet packets to and from the gateway handling node to and / or from the user's mobile device, to provide a packet communication medium. A part of the radio network is used to provide a radio access medium for communicating internet packets through a radio access interface to and / or from a mobile user device. In response to a request message to activate a packet data protocol requiring a common context for a packet data transmission service transmission nodeit works in conjunction with a gateway service node to set up a common packet data protocol in conjunction with a packet communication medium. The common context of the packet data protocol is established to communicate the internet protocol packets via the packet communication medium according to the version of the internet protocol determined by the mobile user device for one or more communication sessions. The request to activate the packet data protocol is communicated from the mobile user device to the service node

The transmission includes an element informing about the end user's address with a field containing a packet data protocol type number with a value set to a predetermined value to indicate a common packet data protocol context request and an address field indicating the address according to the version of the internet protocol determined by the mobile user equipment to communicate the internet packets using the common context of the packet data transmission protocol.

[0006] Embodiments of the present invention may solve the problem of limitations of known radio networks for communicating packets by reducing the constraints of a packet protocol version for a particular method of managing a GPRS / UMTS communication session by providing a common context for a packet data transmission protocol.

[0007] With the advancement of new radio access technologies, e.g. the availability of high-speed radio link technologies such as HSDPA (High Speed ​​Downlink Packet Data) and HSUPA (High Speed ​​Uplink Packet Data), it is desirable to share the same radio bearer between more than one user device to improve resource efficiency. In addition, with the rapid advancement of IPv6 technology, the use of IPv6 can gain in popularity in devices and end systems like mobile user devices. Furthermore, the presence of existing IPv4 systems results in the development of end user devices with a dual stack of IPv4 / IPv6 internet protocols. As a standard, IPv4 packets must be delivered via the IPv4 PDP context, while IPv4 packets must be delivered via the IPv6 PDP context. As a result, the use of resources may be less efficient than would be possible when sharing the same high / high speed GPRS media (e.g. HSDPA, HSUPA, which are radio bearers). In addition, in the case of modern mobile user devices equipped with a dual stack of IPv4 / IPv6 internet packets, it may be necessary to send both IPv4 and IPv6 packets, e.g. when communicating with IPv4 and IPv6 based services, respectively. However, the existing internet protocol type determined for the packet data protocol context may require that the user's mobile devices draw at least two packet data protocol contexts, one IPv4 type and the other type IPv6.

[0008] Embodiments of the present invention provide the ability to send both IPv4 and IPv6 internet packets from mobile user devices, as requested by such devices. This is possible because the mobile user device may have, for example, dual IPv4 / IPv6 stack. In addition, a radio network for communicating packets in accordance with embodiments of the present invention is implemented in a shared GPRS / UMTS sharing system by means of a common packet communication medium, including high speed broadband radio bearers. Typically, there will be only one common packet communication medium for communicating packets to a given gateway handling node.

[0009] The common context of the PDP is a common packet communication medium according to the packet data protocol for communicating internet packets via the GPRS network. As part of the protocol for communicating packets, there are principles of communication policy implementation, service quality and routing, which are implemented, for example, to organize internet protocol packets to communicate via a common packet communication medium established. However, a common PDP context is a common packet communications medium that is not specified with respect to any version of the internet protocol, and may be shared for more than one communication session. In addition, communication sessions may come from different mobile user devices.

[0010] Alternatively, in other examples, a common PDP context may be implemented for more than one communication session, although the communication session may use separate internet protocol bearers. Therefore, a common PDP context is defined as a PDP context that is common to PPP data frames, IPv4 and IPv6 packets, or packets that use any other version of the Internet Protocol or other data protocols to communicate.

[0011] Taking the GPRS / UMTS as an example, a communication session may be implemented over a GPRS / UMTS network with a common PDP context, the common PDP context being a common packet communication medium that can be used to transmit and receive PPP frames, IPv4 packets and IPv6 and data packets in other formats, according to the data transport protocol or other versions of the Internet protocol.

[0012] Various other aspects and features of the present invention are defined in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the present invention will be described by way of example only with reference to the accompanying drawings, in which similar elements bear the corresponding numerical indications on which:

Figure 1 is a block diagram of a telecommunications system, including a packet radio network compliant with the GPRS / UMTS standard.

Figure 2 is a block diagram of a simplified representation of the GPRS / UMTS network of Figure 1 showing the communication of internet packets via a packet communication medium.

Figure 3 is a block diagram of the GPRS / UMTS network of Figure 2, showing a system in which a mobile user device composes a common context of a packet data transmission protocol;

FIG. 4 is a flowchart of a process for executing a packet data protocol activation request message.

Figure 5 is a block diagram of the GGPRS / UMTS network of Figure 3, showing the further course of the process for compiling a common packet data protocol context;

Figure 6 is a schematic view of an element informing about the end-user's address, sent as part of the activation of the packet data protocol context;

Figure 7 shows an array of values ​​that can be used to fill the PDP organization field in an element informing about the end user from ^FiGury ⁶;

Figure 8 shows a schematic view of an element informing about an end-user's address to establish a PDP context for an IPv4 version;

Figure 9 is a schematic view of an element informing about the end-user's address to establish a PDP context for an IPv6 version;

Figure 10 shows a schematic view of an end address information entity to establish a common context of a packet data transmission protocol when the mobile user device wants to communicate using IPv4;

EP 1 861 982 B1

Figure 11 is a schematic view of an end address information entity to establish a common context of a packet data transmission protocol when the mobile user device wants to communicate using IPv4;

Figure 12 is a schematic view of an element informing about a traffic flow template;

Figure 13 is a schematic view of the GPRS / UMTS network of Figure 3, showing multiple mobile user devices establishing packet data protocol contexts, including common packet data protocol contexts that may communicate using a common GPRS bearer;

Figure 14 is a schematic view of a portion of the GPRS / UMTS network of Figure 3 and Figure 5 showing separate GPRS bearers for two mobile user devices of Figure 13 using a common context of a packet data protocol;

Figure 15 is a schematic view of a portion of the GPRS / UMTS network of Figure 3 and Figure 5, showing common GPRS bearers supporting communication via internet protocols to and / or from two mobile user devices of Figure 13 using a shared context of a packet data protocol;

Figure 16 is a schematic view of a portion of the GPRS / UMTS network of Figure 15 showing the operation of a radio network controller to communicate internet packets to two mobile user devices that share a common packet data protocol context and a common packet data protocol carrier using a carrier filter radio access; Figure 17 is a block diagram of a part of a GPRS / UMTS network corresponding to the situation of Figure 3 and Figure 5, using an Internet-based multimedia subsystem (IMS) protocol via which three mobile user devices share an IMS session;

Figure 18 is a block diagram of a general view of the elements used for the session setup with media authentication for communication by IMS;

EP 1 861 982 B1

Figure 19 is a schematic view of an authentication token generated for the session of the authentication procedure of Figure 18, adapted for the authentication of a single IMS session or a group IMS session;

Figure 20 is a schematic view of another example of a authentication token generated for an authentication session of Figure 18, adapted to authenticate a single IMS session or a group IMS session; and

Figure 21 illustrates a flowchart of a message process by which multiple mobile devices perform session assembly and group communication session authentication with a common GPRS bearer.

DESCRIPTION OF THE PREFERRED EMBODIMENTS [0014] Figure 1 is a block diagram of a radio network for communicating GPRS / UMTS packets 1 for communicating internet packets between a UE (User Equipment) 2 and a corresponding node (CN) 12 that is associated to an external packet data transmission network 15. In Figure 1, the UE 2 mobile user device functions as the host of an application program that provides to the user e.g. a multimedia service. Figure 1 shows the elements of the GPRS network: GPRS gateway service node (GPRS) support mode 4 supporting GPRS support mode (SGSN) 6 and radio network controller (RNC) 8 In accordance with Figure 2, which is a simplified form of the GPRS network shown in Figure 1, The GGSN 4 and SGSN 6 generally form part of the core network, CN, where the radio network controller RNC 8 is part of the radio network RN. According to Figure 2, which is a simplified form of the GPRS network shown in Figure 1, the GPRS network 1 is an Internet Protocol carrier 14 for which a packet data context has been implemented. According to a brief explanation provided hereafter, the context of the packet data protocol is provided by a protocol guaranteeing the establishment of a suitable medium, provided the quality of services covered by the EU subscription is 2 and the authorization to use the medium. The medium 14 is provided on the UE 2 user device to communicate the internet packets via the GPRS network to the respective node.

Internet protocol for which an internet protocol carrier has been established.

[0015] It is preferred that the GPRS is one example of a radio network for communicating packets in which the described art is applicable. In accordance with the above, the GGSN may more generally act as a node serving gates, whereas SGSN may more generally serve as a transmission service node.

Common context of the PDP [0016] Figure 3 depicts an example of the described technique where the UE mobile UE may provide a common PDP context. The parts shown in Figure 2 are assigned the corresponding numbers. According to Figure 3, the UE mobile device has a dual stack of protocols. This means that UE 2 has an internet protocol stack in the IPv4 version (20) and an internet protocol stack in the IPv6 version (22). Therefore, UE 2 can use one address or both IPv4 and IPv6 addresses, implementing a communication session according to IPv4 and IPv6, respectively. For this purpose, UE 2 sends a request to activate the packet data protocol context to SGSN 4 in the direction indicated by arrows 24. The characteristics of the GPRS standard are known to that the packet data protocol (PDP) context activation procedure performs appropriate control and routing to activate the medium in the GPRS network according to the packet data protocol. The procedure for activating the packet data protocol (PDP) context is shown in Figure 4. The packet data protocol (PDP) context activation procedure is not described in detail because its course is known from 3GPP No. TS 24.229. After the GPRS medium is established, the UE 2 communicates information to the Traffic Flow template (TFT) 19 on the gateway service node (GGSN) as well as shown in Figure 2. As explained later in the description, the TFT template is adapted to filter incoming packets, to identify the appropriate PDP context,

A known method for activating a packet data protocol context for a GPRS / UMTS session set-up, as defined in existing GPRS / UMTS specifications, requires the following elements defining the GPRS / UMTS session / internet protocol type of the packet data protocol (PDP) context:

EP 1 861 982 B1

1. The request to activate the packet data protocol (PDP) context must indicate the type of PDP to be set: PPP type, IPv4 type, IPv6 type.

2. The end-user address that contains the PDP address (IP address) must be empty so that an Internet Protocol address can be assigned following a successful PDP context specification if the UE decides to use the dynamic IP address assignment.

[0018] Both the PDP type and the PDP address are encoded in the information element of the end user's address (see TS 29.060), which will be discussed in greater detail later in the description.

[0019] As shown in Figure 5, according to the current technique, a common PDP is implemented to communicate packets in an IPv4 internet protocol standard or IPv6 packets or both IPv4 and IPv6 packets to and from UE2 device. Therefore, the device UE 2 may receive internet packets from an IPv6 source (30) or an IPv4 source (32) via a packet data network (PDN).

[0020] As described above, the PDP context is implemented for both the IPv4 address and the IPv6 address, or the peer-to-peer protocol (PPP) address. To set up an IPv4 or IPv6 medium, the UE mobile device communicates as part of the PDP context - an element informing about the end-user's address including fields with a predetermined number of bytes identifying specific parameters. An example of a general form of an element informing about an end user's address is given in Figure 6. According to Figure 6, one of the fields 40 comprises a method for organizing the PDP protocol type, the further field defines a PDP type number (42) and the subsequent field 44 defines the PDP address. According to the current 3GPP standard, values ​​relating to the PDP organization and the PDP type number are transmitted in data fields 40, 42 of the information element of Figure 6,

[0021] If the UE 2 is to activate the PDP context for the IPv4 medium, the end-user address element of Figure 6 is adapted to the embodiment shown in Figure 8. On the other hand, if the UE 2 is to activate the PDP context for the IPv6 medium, the address information element The end user of Figure 6 is adapted to the embodiment shown in Figure 9. As is apparent from Figures 8 and 9, the PDP organization field (40) has a value of 1 according to the table shown in Figure 7. In the PDP context for IPv4,

The element informing about the field with the PDP type number (42) keeps the value in the hexadecimal system (21). For the PDP for IPv6 context, the end user information element of Figure 9 also holds the PDP organizational value of 1, but the PDP numeric field (42) is provided in a hexadecimal system (57) indicating that the medium should be IPv6.

[0022] There are therefore two alternative ways to determine the PDP context for IPv6 and IPv4. If the UE 2 decides to use its own IPv4 or IPv6 addresses, the element informing about the end user's address contains in the IP address field (44) an IPv4 or IPv6 address, which is filled by the terminal device with a specific IPv4 or IPv6 address. Alternatively, according to Figures 2 and 3, the internet protocol address that the UE will use may be requested as part of the PDP context activation process, in which case the address is forwarded by the DHCP server. Therefore, in the case where the UE requests an IP address, the address field 44 remains blank (zero bytes) for each address field 44 shown in Figure 8 and 9.

[0023] According to the present technique illustrated in Figures 3 and 5, the UE mobile UE may establish a common PDP context. The common context of the PDP establishes a carrier according to the packet data protocol for communicating internet packets on the GPRS network. As part of the protocol for communicating packets, there are rules for the implementation of communication policy, quality of services and routing, which are implemented in order to organize internet protocol packets to communicate via an established carrier. However, the common PDP context establishes a medium that is not specified for any version of the Internet Protocol, and may be shared for more than one communication session. In addition, communication sessions may come from different mobile user devices. Alternatively, a common PDP context may be established for more than one communication session, although the communication session may use separate media for Internet protocols. Therefore, a common PDP context is defined as a PDP context that is common to PPP data frames, IPv4 and IPv6 packets, or any other data protocols. A GPRS / UMTS session with a common PDP context can be used to send and receive PPP frames, IPv4 and IPv6 packets and data packets in other formats, according to the data transport protocol. IPv4 and IPv6 packets or any other data protocols. A GPRS / UMTS session with a common PDP context can be used to send and receive PPP frames, IPv4 and IPv6 packets and data packets in other formats, according to the data transport protocol. IPv4 and IPv6 packets or any other data protocols. A GPRS / UMTS session with a common PDP context can be used to send and receive PPP frames, IPv4 and IPv6 packets and data packets in other formats, according to the data transport protocol.

[0024] The procedure for configuring the GPRS / UMTS session with a common PDP context is similar to the conventional PDP context, but the PDP type is null zero. The PDP type is configured as NULL to maximize the work efficiency of existing GPRS / UMTS session management processes. In the case of a UE requesting a dynamic IP address (IPv4 or IPv6), the PDP address in the end user's address is left blank because it is defined during the configuration process of the GPRS / UMTS session. In fact, a specific IP address determining element allows a UE to generate and receive IPv4 or IPv6 packets when sharing a PDP context.

[0025] According to the current technique, a common PDP context is established for an undefined version of the Internet Protocol using an endpoint user information element that includes a PDP number with a predetermined value indicating whether the gateway's support node should establish a common PDP context. After the PDP context is established, if the gateway support node receives a subsequent common PDP context request, a communication session for which the PDP context has been initialized will be put together to be included in the common PDP context. However, although a common PDP context is not specified for a particular version of the Internet Protocol, the UE 2 still indicates the address to be used, according to the version of the Internet Protocol for which the communication session was established. Hence, the UE establishes a common PDP context using e.g. an IPv4 or IPv6 address. According to the current technique, an end-user address element for a common PDP context with respect to IPv6 indicates that the PDP type is common by indicating in the PDP numeric field (42) predetermined characters, e.g., characters with the value "NULL". The PDP address field (44) is then stored with the IPv6 address, if the UE determines the IPv6 address to be used, or the byte 6 - 21 of the info element is set to a "null" value - see Figure 10. In this way, the gateway operating node knows that a common PDP context should be established for the IPv6 address using the specified address, and if the PDP address field is set to zero, send an IPv6 address request to the DHCP server (17).

[0026] Correspondingly, if the UE 2 establishes a common PDP context for the IPv4 address, then according to Figure 11, with the PDP numeric field (42) set

As "NULL", the IPv4 address is set to the younger four bytes of the PDP address field (44). The remaining nine bytes are set to "1". Alternatively, if the mobile user device is to request an IPv4 address from the gateway support node, the younger four bytes are set to a predetermined value, e.g. "0" with the remaining nine bytes set to "1". Accordingly, the gateway service node (2) receives the IPv4 address from the DHCP server (17) and populates the four younger bytes with the IPv4 address.

[0027] As described above with reference to Figures 2 and 3, after establishing the common PDP context, the UE 2 sets up the Traffic Flow Template TFT template in the GGSN 3. To do this, as part of the PDP context activation process , the UE transmits an element informing about the traffic flow template to the GGSN. Figure 12 is a schematic view of each element field informing of a traffic flow template in accordance with the known 3GPP standard. According to Figure 12, one of the information element fields 50 includes a list of packet filters, while another field 52 - a list of parameters. The packet filter field 50 defines the type identifier of the packet filter element according to which the internet packets are filtered. Annex 1 specifies the specification of type identifiers for packet components. They include the IPv4 or IPv6 source address type or various other parameters. Therefore, after determining the type of component in the packet filter list field 50, the parameter corresponding to the type to be filtered is determined in the parameter list field 52.

Traffic flow template (TFT) for common PDP context [0028] According to the current technique, once the UE has established a common PDP context, the packet filter type identifier is determined to filter the IP packets to identify the common PDP context. Therefore, the mobile user device establishes a TFT template for the common PDP context. For this purpose, a further identifier of the type of the packet filter component is established, e.g. one with the bit pattern "00110001". Therefore, after establishing the common PDP context for the UE, a TFT template for the UE is configured, which specifies the packet filter component for the common PDP address type.

[0029] The packet filter components in the TFT template for the common PDP context are not defined for the IP type. In order to maximize interoperability with the existing working requirements and procedures of the underlying operators and TFT templates (e.g., selecting a secondary PDP context / differentiation of QoS services), two new fields have been defined to connect to the TFT information element according to the current technique, these fields being a common type of PDP address and a common PDP address. The modified TFT information element for the common PDP context with the common PDP address type field as one of the components of packet filters is defined as follows:

7 6 5 4 3 2 1 0 0 1 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 1 0 1 0 0 0 0 0 1 0 1 0 0 0 1 0 1 1 0 0 0 0 0 0 1 1 1 0 0 0 0

0 0 0 0 0 0 0

The type of common PDP address

IPv4 source address type

IPv6 source address type

Type of protocol identifier / next header

The type of a single destination port

The type of destination port range

The port type of a single source

The type of source port range

Index type of the security parameter

Type of services / type of traffic class

Flow Label Type [0030] When the UE creates a TFT template to use a common PDP context, it sets the common PDP source address type as "0 0 1 1 0 0 0

1 "and the PDP common packet filter component contains 16 bytes. The common PDP address type no longer uses the source address type, because a packet filter based on the destination address may be needed to distinguish the common PDP context from the primary / secondary PDP context. For UE devices that send and receive IPv4 packets, the packet filter component for the PDP address takes 4 younger bytes from the 16-byte PDP address filter component, while the 12 older bytes fill the "0" value. For a UE that sends and receives IPv6 packets, the packet filter component for the PDP address occupies the entire 16-byte packet filter component. In a situation where more than one UE shares a common PDP context, there is respectively more than one TFT template associated with the common PDP context,

Each TFT template is used to match the packet incoming to the common PDP context, which is necessary when the common PDP context, the PDP primary context, and the PDP secondary context together are shown in the following description.

Choosing a Common PDP Context from Other PDP Contexts As described above, many UEs may have different types of PDP contexts running simultaneously, all of which are managed and brought to the GGSN. Different PDP contexts may be a common PDP context, a primary IPv4 or IPv6 context, and a secondary IPv4 or IPv6 context, of which the last two are defined according to the 3GPP standard. The packet received in GGSN must be provided for the relevant PDP context due to specific requirements such as service quality, billing, security, etc. A TFT template defined in accordance with the 3GPP standard is used to distinguish and select primary and secondary PDP contexts (IPv4 or IPv6) using using a combination of packet filters. In the case of common PDP contexts,

[0032] In a first variant, it is possible to use a combination of TFT templates. Any UE using a common PDP context can generate its own TFT template as described above. The packet arriving at the GGSN goes through the same procedure as the operations for the standard TFT template, i.e. to use the PDP address packet filter. The difference is that the TFT template for using the PDP context sharing has the PDP address type code in the form "0 0 1 1 0 0 0 1", as described above. When there is only one common PDP context (at the primary or secondary PDP context), the internet protocol packet arriving at the GGSN will by default use the common PDP context to reach the UE by selecting the appropriate medium.

The PDP context. If not matching, the PDP primary context is used without a TFT template.

When the common PDP context coexists with the PDP primary context and the PDP secondary context, each having a related TFT template (especially useful when different service qualities are required for each PDP context), the incoming Internet Protocol packet can be matched to the common context. PDP or primary or secondary PDP context using packet filtering based on the TFT template. This is because the packet header information is insufficient to distinguish which PDP context to use because of the overlapping packet filter parameters between the TFT templates associated with the common PDP context and the primary / secondary PDP context. In this case, the second variant may be used.

[0034] In addition to using different PDP address types to distinguish the TFT template used for common PDP contexts from the primary / secondary PDP contexts, additional information is needed to decide which PDP context to use to deliver the incoming packet when they occur together, the primary and secondary PDP context. According to the method of implementing the second variant, the destination address of the internet protocol packet (IPv4 or IPv6) is added on the principle of one of the packet filter components used for the common PDP context. As a result, when the UE activates or joins the common PDP context, it creates a TFT template with the PDP address type in the form "0 0 1 1 0 0 0 1" and the packet filter component using its own IP address (IPv4 or IPv6).

[0035] When the incoming packet arrives at the GGSN, the operative procedure based on the TFT template proceeds as follows:

1. I check each TFT template corresponding to the types of PDP 00010000 source for IPv4 and 00100000 for IPv6) to check if any matching PDP context is available. If so, a matching PDP context (primary or secondary) is used to deliver the packet.

2. In the absence of a matching TFT template in accordance with point 1, check the TFT template of the common PDP address type (00110001) to check that the destination address of the incoming packet matches one of the filter components

EP 1 861 982 packages in the TFT template. If so, a common PDP context is used to provide the package.

3. In the absence of a matching TFT template in accordance with point 1 or 2 checks if there is a PDP context without a TFT template. If so, the PDP context is used to deliver the packet. Otherwise, the package is rejected.

Establishing / merging a common PDP context [0036] Because a common PDP context may be shared by more than one UE, a UE activating a common PDP context will have to attach to an existing common PDP context if it has already been established (for static or dynamic configuration) .

Modifying a GPRS / UMTS session with a common PDP context [0037] The same processes defined in existing GPRS / UMTS subject standards (TS23.060) can be used to modify a communication session. However, instead of modifying an existing common PDP context used by other UEs, the UE will first have to leave the common PDP context and decide and initiate or join another common PDP context.

Leaving or deleting a common PDP context [0038] The same process defined in existing GPRS / UMTS subject standards for deleting a PDP context may be applied to a common PDP context. However, if the common PDP context is still used by another UE, the common PDP context will not be released. The UE, which requires the removal of the common PDP context, will leave the common PDP context by deleting its TFT template and associated GTP_C / GTP_U tunnels that have been released.

Examples of co-existence of different PDP contexts [0039] Figure 13 illustrates an example of a system in which multiple UEs have established PDP contexts. Two UE devices have established a common PDP context. According to Figure 13, three UE devices (UEa, UEb, UEc) communicate internet protocol packets on a GPRS network. Two UEa mobile devices, UEb have established a common GPRS medium (90). For example, the first UE may establish a common GPRS bearer by requesting to activate the PDP context specifying that the PDP context should be shared as described above. Then, the GGSN (3) establishes a common PDP context (100) for the first

EP 1 861 982 of the UE device, i.e. UEa. The first UE (UEa) then establishes in connection with the GGSN (3) a TFT traffic flow template that includes the common PDP address type in the parameter list. With reference to the example in Figure 13, the first mobile user device (UEa) determines that the internet protocol address to be used during a communication session will be an IPv4 address. Therefore, the common PDP address type specified by the TFT template is the IPv4 address shown for the TFT template (102) in the parameter list (104). [0040] The second UE, i.e. UEb, also configures a common PDP context in the GGSN (3). Because the common PDP context (100) has already been established by the first UE (UEa), the GGSN (3) is designated to join the second UE (UEb) to the common PDP context. However, a separate common PDP context (100) is associated with the TFT template of the second UE device having the TFTb template. The TFTb template also determines that the packet filter component is a type of common PDP address, and for the second UE device the IPv6 address is specified in the form of a filter component in field 108. Therefore, each mobile user device (UEa, UEb, UEc) sets its own TFT template. For comparison, a third UE (UEc) device requests a activation of a conventional PDP primary context for its own dedicated GPRS medium (112). The third UEc may establish a secondary PDP context that is also configured to communicate IP packets via the GPRS medium (only one carrier 112 is shown in Figure 13). For the third UEca device, the TFTc template (114) is established to filter the packets relative to the primary or secondary PDP context according to the convention. Therefore, according to Figure 13, two UEa and UEb mobile user devices communicate via a common GPRS (90) carrier using a common PDP (100) context, although each device has its own traffic flow template, i.e. TFTa and TFTb. In an alternative embodiment, the first and second UEs, UEb may establish separate GPRS bearers (90, 114) and communicate the internet packets via separate bearers although they use a common PDP context. two UEa and UEb mobile user devices communicate via a common GPRS (90) carrier using a common PDP (100) context, although each device has its own traffic flow template, i.e. TFTa and TFTb. In an alternative embodiment, the first and second UEs, UEb may establish separate GPRS bearers (90, 114) and communicate the internet packets via separate bearers although they use a common PDP context. two UEa and UEb mobile user devices communicate via a common GPRS (90) carrier using a common PDP (100) context, although each device has its own traffic flow template, i.e. TFTa and TFTb. In an alternative embodiment, the first and second UEs, UEb may establish separate GPRS bearers (90, 114) and communicate the internet packets via separate bearers although they use a common PDP context.

Common GPRS medium [0041] There are two possible scenarios for the first and second mobile user devices (UEa, UEb) of the example in Figure 13 for communication in a GPRS network (1) using a common PDP context. One

In Figure 14, GGSN (3) establishes a separate GPRS tunneling media (GTP) medium, i.e. GTP_UA, GTP_UB, for each of the devices (UEa, UEb). According to Figure 14, although the first and second devices use a common PDP context, internet protocol packets are communicated to the GPRS network via separate GTP carriers. When internet protocol packets reach the RNC (8) for communication via a radio access medium (RAB), separate tunneling protocols GTP_UA and GTP_UB are mapped onto the appropriate RABa radio bearers, RABb. Suitably, each radio access and GTP carrier established for the first and second UEs, UEb may determine a different quality of QoSa services, QoSb. Therefore, there is a one-to-one mapping between the radio access carrier and GTP. Thus, Figure 14 illustrates an example of a common PDP context with different GPRS bearers.

[0042] An alternative method is shown in Figure 15, where the first and second UEa, UEb, which have established a common PDP context, use a common GPRS bearer. In this case, there is no distinction between the GTP established by the GGSN (3). The above means that the GPRS carrier is shared between the first and second devices (UEa, UEb). In order to ensure correct transmission of Internet packets in the GPRS network via the radio access interface established by the RNC, this controller must communicate the internet protocol packets that are intended for the first (UE) or second (UEb) device. For this purpose, the RNC is provided with the radio access support filter (200). The radio access media filter (200) receives internet packets from the GTP_U and identifies one of the two RABa, RABb radio access media, respectively, to and from which the first and second UEs, UEb sends and receives internet packets. In order to properly filter the internet packets to the appropriate RABa radio access medium, the RABb RAB filter (200) receives the destination address of the first and second UEs, UEb. Therefore, according to Figure 15, the RAB (200) filter identifies the destination address in the header of the internet protocol packet (202) received in the GTP assemblies (204). According to the destination address for the first and second UEa devices, UEb the RAB filter filters internet protocol packets for the respective medium to be delivered to the respective UEa, UEb. to and from which the first and second UEs, UEb sends and receives internet packets. In order to properly filter the internet packets to the appropriate RABa radio access medium, the RABb RAB filter (200) receives the destination address of the first and second UEs, UEb. Therefore, according to Figure 15, the RAB (200) filter identifies the destination address in the header of the internet protocol packet (202) received in the GTP assemblies (204). According to the destination address for the first and second UEa devices, UEb the RAB filter filters internet protocol packets for the respective medium to be delivered to the respective UEa, UEb. to and from which the first and second UEs, UEb sends and receives internet packets. In order to properly filter the internet packets to the appropriate RABa radio access medium, the RABb RAB filter (200) receives the destination address of the first and second UEs, UEb. Therefore, according to Figure 15, the RAB (200) filter identifies the destination address in the header of the internet protocol packet (202) received in the GTP assemblies (204). According to the destination address for the first and second UEa devices, UEb the RAB filter filters internet protocol packets for the respective medium to be delivered to the respective UEa, UEb. The RABb RAB filter (200) receives the destination address of the first and second UEs, UEb. Therefore, according to Figure 15, the RAB (200) filter identifies the destination address in the header of the internet protocol packet (202) received in the GTP assemblies (204). According to the destination address for the first and second UEa devices, UEb the RAB filter filters internet protocol packets for the respective medium to be delivered to the respective UEa, UEb. The RABb RAB filter (200) receives the destination address of the first and second UEs, UEb. Therefore, according to Figure 15, the RAB (200) filter identifies the destination address in the header of the internet protocol packet (202) received in the GTP assemblies (204). According to the destination address for the first and second UEa devices, UEb the RAB filter filters internet protocol packets for the respective medium to be delivered to the respective UEa, UEb.

EP 1 861 982 B1

Providing different quality services for a common GPRS bearer. [0043] Figure 16 shows a system in which different levels of quality of internet packet messaging services can be granted via a common GPRS bearer. For example, one communication session may communicate Internet packets for a web browser, while another session may involve internet telephony packages. According to the current technique, the differentiation of service quality levels is done by mapping the quality of service (QoS) classes available in the EFTF Internet protocol standard at appropriate levels of quality of transmission services in the GPRS base network. From version v6 and v4 of the Internet Protocol standard, it is known that various levels of quality of QoS services are implemented in accordance with the IETF standard and occur in three categories: Expedited Forwarding (EF), Assured Forwarding (AF) and Best Effort (BE). According to Figure 16, internet packets IPa, IPb, communicated to the first or second UEa, UEb (220, 224), are received in the GGSN (3). In each corresponding header of internet packets IPa, IPb (220, 224) a different level of QoS is given. With reference to the example of Figure 16, the different levels of QoS services for the first internet packet destined for the first UE (IPa, 220) are EF, while for the second packet for the UE (IPb, 224) - AF. The GGSN (3) is ready to create a GTP filter that serves to map different QoS services (EF and AF) on the appropriate QoSa services, QoSb for transmission in the core network to RNC. The quality of services provided by GTP_U QoSa, QoSb may be identical to EF and AF in accordance with IETF standards, or an alternative class of service quality.

[0044] According to Figure 16, communication between each element of the GGSN base network, SGSN (3, 4) with the RNC (8) takes place at different protocol levels. These are high-level end-to-end Internet protocols (240), Internet protocol level GTP_U (242), UDP layer (244), and internet protocol transport layer (246). Hence, GGSN (3) is prepared to communicate Internet packets in the transport layer of Internet packets using the quality of QoSa, QoSb services identified based on different quality levels of AF, EF services identified in the header of each packet to be communicated to the first and second UEs respectively , UEb.

[0045] Once the internet packets have been received by the RNC, the RAB filter (200) operates in a corresponding manner to that explained with respect to Figure 15 to forward packets from each internet protocol transport layer to the appropriate RABa radio access medium, RABb. Suitable radio access bearers are identified by the destination address of the first and second UEa, UEb. In accordance with the current mobile user's device technique, the UE is ready to establish a RAB filter when a common PDP context is established. Therefore, in an analogous manner to establishing a TFT template, each UE device configures a corresponding component in the RAB filter for internet packets received from the IP transport layer to be filtered relative to the respective radio access medium.

Support for IMS session authentication with multiplexing [0046] Figure 17 illustrates an example of a common GPRS bearer (300) used by three devices 302, 304, 306 during a communication session over a GPRS network, including, according to the above, GGSN (307), SGSN ( 309), RNC (311) and node B (315). In Figure 17, devices 302, 304, 306 decide to share a multimedia session implemented by the Internet protocol multimedia subsystem 308. The IMS subsystem includes a session reference session sender (SIP, 310), a function to control the service request state (S-CSCF, 312) and a home server subscriber (HSS, 314). The IMS subsystem also has a function for controlling the proxy state (PCSCF) 316.

[0047] The mobile user device may open an IMS session by sending a SIP message to the SIP server (300). This is done by sending a SIP: INVITE message to P-CSCF (316). The P-CSCF (316) creates a decision point for the IMS subsystem and analyzes the request for subscription information available on the HSS server. Upon validation of the request, the P-CSCF (316) issues a authentication token of the UE to use the appropriate medium for the IMS communication session. The token is generated in accordance with the 3GPP technical specifications: TS23.228 and TS23.207.

[0048] Figure 18 illustrates the IMS authentication procedure implemented in accordance with the above 3GPP technical specifications. Figure 18 shows an overall flowchart of a process generating an authentication token on demand of a UE and subsequent implementation of a communication session in accordance with the issued token

The validation method can be used. According to Figure 18, one of the devices (302) requests authentication for an IMS session. The UE (302) sends a media request to a policy implementation point (322). The policy implementation point (322) passes the token requesting the carrier to the policy decision point, i.e. the policy server (324). The policy server (324) then determines whether the mobile user device (302) is authorized to open the IMS session via the appropriate media in the GPRS network. The policy decision point (324) then generates an authentication token if the request has been accepted, constituting the authentication of the communication session and communicating the token to the policy implementation point (322). Then the policy implementation point informs the UE about the availability of a suitable IMS carrier for the device. For this reason,

[0049] Figure 17 depicts a GGSN (3), a policy implementation policy that is responsible for authenticating and establishing the appropriate medium supporting the IMS session. However, in Figure 17, a mobile user device 302, 304, 306 reports the establishment of an IMS session with a common GPRS bearer. [0050] From known procedures for issuing an authentication token for an IMS session, it is known that there is no way for UEs to request authentication for communication sessions with common GPRS bearer and receive a single authentication token for multiplex communication sessions with shared GPRS bearer. To this end, a hierarchical authentication mechanism is proposed in which the hierarchical authentication token is generated by policy servers, which act as policy decision points. An example of a hierarchical authentication token is shown in Figure 19. The hierarchical authentication token in Figure 19 provides a single authentication token for a group or single IMS communication session. According to Figure 19, the authentication token generated by the policy server 316, 324 according to the current technique includes a field of type 400 authentication, group session ID IMS 402, single session id IMS 404. The authentication type field 400 has a predetermined value that indicates whether the IMS communication session can use dedicated resources / GPRS media, and also whether the IMS communication session can The hierarchical authentication token in Figure 19 provides a single group authentication token or a single IMS communication session. According to Figure 19, the authentication token generated by the policy server 316, 324 according to the current technique includes a field of type 400 authentication, group session ID IMS 402, single session id IMS 404. The authentication type field 400 has a predetermined value that indicates whether the IMS communication session can use dedicated resources / GPRS media, and also whether the IMS communication session can The hierarchical authentication token in Figure 19 provides a single group authentication token or a single IMS communication session. According to Figure 19, the authentication token generated by the policy server 316, 324 according to the current technique includes a field of type 400 authentication, group session ID IMS 402, single session id IMS 404. The authentication type field 400 has a predetermined value that indicates whether the IMS communication session can use dedicated resources / GPRS media, and also whether the IMS communication session can

The use of GPRS bearer shared with other IMS communication sessions and UE devices. Sample values ​​of the authentication type field:

01: IMS 10 group authentication identifier IMS single session authentication identifier [0051] If the IMS communication session is to use dedicated GPRS media / media, the IMS session identifier field (402) has a value of "0" and the single IMS session ID field ( 404) receives a unique authentication token for the IMS session. If the communication session is to use a GPRS carrier shared with other IMS communication sessions, then the IMS session ID field (402) receives a unique authentication value specifying the session, while the IMS session ID field (404) is set to "0". Accordingly, the authentication token is generated by the policy server at the request of the UE, e.g. following a SIP: INVITE message. In response, the P-CSCF 316 message, which acts as a policy decision-making point, establishes communication with S-CSCF 312 in the IMS network. The SCSCF then retrieves the subscriber data from the HSS 314 server to determine if the authentication of the establishment of the common GPRS medium is allowed. Upon acceptance, the appropriate authentication token is transferred to mobile user devices 302, 304, 306.

[0052] According to the PDP context activation procedure establishing the communication session, each UE (302, 304, 306) sends a hierarchical authentication token to the GGSN (307), which is the session identifier. Then, the GGSN checks the authentication type to determine if the communication session should be in group or single mode.

[0053] If the value in the authentication type field (400) indicates that the IMS communication session is grouped with a shared GPRS bearer, the GGSN (307) will establish a common GPRS bearer. Then, the GGSN (307) analyzes the identifier of the group IMS session to send a query to the P-CSCF (316), which acts as a policy implementation point, to confirm the authentication for the IMS communication session requested along with the IMS.

[0054] If the value in the authentication type field (400) indicates that the IMS communication session should be single, then the GGSN (307) will establish a dedicated GPRS medium. Then, the GGSN (307) analyzes the ID of a single IMS session to send a query to the P-CSCF (316), which acts as a policy delivery point,

To confirm the authentication for the IMS communication session requested along with the IMS.

[0055] In an alternative example, the hierarchical authentication token could be generated according to the structure shown in Figure 20. As is apparent from Figure 20, the hierarchical authentication token includes a field of authentication type (400) that corresponds to the exemplary authentication token of Figure 19. However, only single field representing IMS session IDs that must be common to group and individual session IDs. Therefore, although the example of Figure 20 is simpler, the address range must be subdivided to correctly determine group or individual session identifiers.

[0056] A message flow illustrating the generation and communication of an on-demand authentication token from a mobile user device is shown in Figure 21. This flow can be summarized as follows:

S1: SIP message: INVITE is sent from the user's mobile device (302) to P-CSCF 316. S4: P-CSCF 316, in conjunction with SCFCF 312, acquires subscriber data from the HSS 314 server. According to the subscriber information, P- CSCF (316) determines whether the user is authorized to receive a shared IMS communication session, and whether the session can be done via a common GPRS medium. In the case of acceptance, the P-CSCF generates an authentication token with an authentication type (group or single) and a session identifier for a shared or dedicated medium that is forwarded to the GGSN. S8: The GGSN then passes the authentication token to the mobile user device (302). S10: The user mobile device (302) performs a request to activate the PDP context, provided that the authentication token is part of the protocol configuration option field. S12: The SGSN receives the request to activate the PDP context and forwards the authentication token to the GGSN (3). The GGSN then confirms that the mobile user device is authorized to establish a common communication session with another mobile user device by confirming the session identifier in the P-CSCF. S16: Next, the P-CSCF (316) confirms that the mobile user device is entitled to receive a common GPRS carrier for an IMS session. S17: Next, GGSN (307) establishes the carrier that the mobile user device is authorized to establish a common communication session with another mobile user device by confirming the session identifier in the P-CSCF. S16: Next, the P-CSCF (316) confirms that the mobile user device is entitled to receive a common GPRS carrier for an IMS session. S17: Next, GGSN (307) establishes the carrier that the mobile user device is authorized to establish a common communication session with another mobile user device by confirming the session identifier in the P-CSCF. S16: Next, the P-CSCF (316) confirms that the mobile user device is entitled to receive a common GPRS carrier for an IMS session. S17: Next, GGSN (307) establishes the carrier

EP 1 861 982 B1

GPRS and inform the mobile user device (302) about the assignment of a common GPRS medium.

[0057] Various other aspects and features of the present invention are defined in the appended claims.

[0058] The described embodiments of the invention are only examples, and the methods may be modified differently without departing from the scope of the present invention. For example, it is preferred that the GPRS / UMTS is an illustrative architecture for which the present invention finds application.

Annex No. 1 [0059] A content field of a variable packet filter comprising a variable number (at least one) of packet filter components. Each packet filter component should be coded in the form of a sequence of one octet packet component type identifier and a packet filter value field with a fixed length. First, the packet filter type identifier should be sent.

[0060] In each packet filter, each type of packet filter component should not occur more than once. Among the packet filter components for the "IPv4 source address type" and "IPv6 source address type", only one in one packet filter should occur. Among the packet filter components for the "single target port type" and "target port range type", only one in one packet filter should occur. Among the packet filter components for the "single source port type" and "source port range type", only one in one packet filter should occur.

[0061] The bit pattern of the packet filter component identifier

<td>8 7 6 5 4 3 2 1 0 0 0 1 0 0 0 0</td><td>IPv4 source address type</td>

<td>0 0 1 0 0 0 0 0</td><td>IPv6 source address type</td>

<td>0 0 1 1 0 0 0 0</td><td>Type of protocol identifier / next header</td>

<td>0 1 0 0 0 0 0 0</td><td>The type of a single destination port</td>

<td>0 1 0 0 0 0 0 1</td><td>The type of destination port range</td>

<td>0 1 0 1 0 0 0 0</td><td>The port type of a single source</td>

<td>0 1 0 1 0 0 0 1</td><td>The type of source port range</td>

<td>0 1 1 0 0 0 0 0</td><td>Index type of the security parameter</td>

<td>0 1 1 1 0 0 0 0</td><td>Type of services / type of traffic class</td>

EP 1 861 982 B1

0 0 0 0 0 0 0 Type of flow label

All other values ​​are reserved.

[0062] With respect to the "IPv4 source address type", the value field of the packet filter component should be encoded in the form of a sequence of four octet IPv4 address fields and four octet boxes of IPv4 address masks. First, the IPv4 address field should be sent. With regard to the "IPv6 source address type", the value field of the packet filter component should be encoded as a sequence of sixteen octet IPv6 address fields and sixteen octet IPv6 address mask fields. First, the IPv6 address field should be sent. With regard to "protocol identifier type / next header", the value field of the packet filter component should be encoded as a single octet sequence specifying the IPv4 protocol identifier or the next IPv6 header.

[0063] With reference to "type of single port of destination" and "type of single source port", the value field of the packet filter component should be coded in the form of two octets defining the port number. With regard to the "target port range type" and "source port range type", the value field of the packet filter component should be encoded in the form of a sequence of two octet lower limit fields and two octet upper limit fields of the port range. First, the field of the lower limit of the port range should be sent.

With regard to the "type of security parameter", the value field of the packet filter component should be coded in the form of a sequence of four octets defining the index of the IPSec security parameter. With regard to "traffic type / type of traffic class", the value field of the packet filter component should be encoded in the form of a single octet field of the service / traffic class type and one octet field of the service / traffic class mask. First of all, the field of the service type / traffic class should be sent.

[0065] With regard to the "flow label type", the value field of the packet filter component should be encoded in the form of three octets defining the IPv6 flow label. Bits 8 to 15 from the first octet should be free, while the remaining 20 bits should contain the IPv6 flow label.

EP 1 861 982 B1