WO2010076043A1

WO2010076043A1 - Method and device for data processing and system comprising such device

Info

Publication number: WO2010076043A1
Application number: PCT/EP2009/050044
Authority: WO
Inventors: Robert Ropolyi; Gyorgy Tamas Wolfner
Original assignee: Nokia Siemens Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2009-01-05
Filing date: 2009-01-05
Publication date: 2010-07-08
Anticipated expiration: 2011-07-05

Abstract

A method and a device for data processing are provided, said method comprising the step of: Providing multiple PDN connections to an APN for a mobile terminal in particular being attached to a non-3GPP access network, wherein a connection identifier is assigned for each of the multiple PDN connections. Furthermore, a communication system is suggested comprising said device.

Description

Method and device for data processing and system comprising such device

The invention relates to a method and to a device for data processing and to a system comprising such a device.

In a 3GPP Evolved Packet System, the terminal (also referred to as mobile terminal or user equipment UE) is connected to an Evolved Packet Core (EPC) via a 3GPP (UTRAN, E-UTRAN) access network or via a non-3GPP (e.g. HRPD, WiMAX or WLAN) access network.

The 3GPP documents TS 23.401, TS 24.301, TS24.008 and TS29.274 describe an architecture, procedures and communication protocol details between the UE and the network and in particular within the EPC network for the 3GPP access network .

3GPP documents TS 23.402 and TS 24.302 describe an architecture and procedures for providing an IP connectivity for using non-3GPP accesses in an evolved 3GPP PS domain.

Security requirements and the requested authentication methods for trusted and non-trusted non-3GPP access networks are set forth in specification 3GPP TS 33.402.

IP mobility management based on DSMIPvβ and PMIP6 is described in 3GPP documents TS 24.303 and TS 29.275, respectively. 3GPP document TS 29.273 describes EPS AAA interfaces .

Underlying protocols MlPvβ, DSMIPvβ, PMIPvβ and the MlPvβ Vendor Specific (Mobility) Options are in particular specified in IETF RFC 3775, I-D draft-ietf-mext-nemo- v4traversal, RFC5213 and RFC 5094. An Extensible Authentication Protocol (EAP) , in particular EAP-AKA and EAP-AKA' authentication mechanisms are defined by IETF RFC 3748, RFC 4187 and I-D draft-arkko-eap-aka-kdf, respectively. A Generic Routing Encapsulation is defined in IETF RFC 2784. IETF RFC 4739 specifies Multiple

Authentication Exchanges in a Internet Key Exchange (IKEv2) Protocol .

Disadvantageously, there does not exist a possibility to provide multiple Packet Data Network (PDN) connections to the same Access Point Name (APN) for a UE, in particular in case the UE is attached via a non-3GPP access.

The problem to be solved is to overcome the disadvantages addressed above and in particular to provide for an efficient handling of a UE ' s multiple PDN connections to the same APN, especially for a UE that is attached to a non-3GPP access, including handovers to/from a 3GPP access.

This problem is solved according to the features of the independent claims. Further embodiments result from the depending claims.

In order to overcome this problem, a method for data processing is provided comprising the step:

- Providing multiple PDN connections to an APN for a mobile terminal, wherein a connection identifier is assigned for each of the multiple PDN connections.

In particular, said method may comprise at least a portion of the following steps:

- Providing multiple PDN connections to the APN for the mobile terminal, wherein the connection identifier is assigned for each of the multiple PDN connections at a creation of each such connection shared between the mobile terminal and a packet data network gateway (PDN GW) in an Evolved Packet Core and ^■ when applicable, used to identify a PDN connection to be released; and

^■ when applicable, preserved after handovers within 3GPP access, non-3GPP access and between these; and ■ when applicable, reused for re-establishing, removing, or in general, identifying the PDN connections .

It is noted that said mobile terminal may be any terminal connected to a 3GPP Evolved Packet Core (EPC) network via any type of access network, e.g., using a radio or a fixed network interface. The mobile terminal can be associated with a computer, a PDA, a mobile phone or any device. The mobile terminal may in particular a cell phone or a user equipment (UE) .

PDN refers to any packet data network and APN comprises an access point name that is used to identify an access point to such a network.

The name "APN" may be used to identify access to a PDN for the mobile terminal (in particular the UE) and/or for the user. For example, the term "Internet" is a well known and frequently used APN that identifies the (access to the) public Internet. Hence, "multiple PDN connection to same APN" rephrases in particular that the mobile terminal or UE has two independent connections to the public Internet in case of this APN. Hence, two applications in the mobile terminal may require these two connections, wherein each application requests and maintains (eventually may terminate) a connection for itself.

The approach provided in particular allows for a consequent handling of a unique PDN connection identifier over different accesses and mobility protocols.

It is noted that said multiple PDN connections may comprise at least two PDN connections associated with one APN. It is further noted that in case an additional PDN connection is created, the UE may assign a new connection identifier (also referred to as PCID (PDN Connection Identifier) herein) to it. In case a PDN connection is released, the UE may add the corresponding PCID to a set of available PCIDs that could be used for assignment purposes.

Advantageously, the approach provided allows for handling of multiple connections of a UE that is attached to non-3GPP access and makes a handover to/from a 3GPP access. Also, the handover to a non-3GPP access node that does not support communication of APNs is improved.

Hence, the approach provided allows to preserve the APN identifier (s) during different types of handover within

3GPP's scope, e.g., from 3GPP access (with both GTP and PMIP based S5 and/or S8 reference points) to non-3GPP access (using IP mobility management based on PMIP or DSMIPvβ protocols) and vice versa.

In particular, the identifier can be preserved during handovers and used by the UE to express the requirement to setup a specific PDN connection among several ones that existed prior to a handover.

In an embodiment, the connection identifier is assigned at or during setup of the PDN connection.

Such assignment of the connection identifier could be triggered or initiated by the mobile terminal.

In another embodiment, the connection identifier is unique for a combination comprising the mobile terminal and the APN.

Hence, it is possible to provide a unique connection identifier for each PDN connection and/or for each combination of the mobile terminal's identification and the APN. According to another embodiment, the connection identifier is unique for the mobile terminal.

In particular a default EPS bearer ID can be selected that is unique not only for the UE and the APN, but also for the UE. In some cases, e.g., handover from 3GPP to non-3GPP with PMIP, the APN may be sent together with the connection identifiers .

Thus, the PCID may identify the PDN connection for the UE uniquely or it may identify the PDN connection via a unique UE+APN combination.

In a further embodiment, the connection identifier is used after handover.

It is noted that the mobile terminal may connect to a non- 3GPP network, and a handover to or from a 3GPP network could be performed.

Also, some extension is suggested for PDN connection handling of the UE that is attached to a 3GPP access (exchanging PCID between UE and PDN GW) . This may be advantageous as a preparation for the handover to the non-3GPP access so that multiple PDN connections can be maintained and/or identified after the handover has been conducted.

It is an option that the UE conveys all PCIDs for PDN connections to be preserved.

In another embodiment, the mobile terminal assigns a connection identifier when a new default EPS bearer to an APN is setup.

Hence, in case of a 3GPP access with PMIP based S5/S8, the setup of a new default bearer may correspond to the setup of a new PDN connection. In a next embodiment, the connection identifier is communicated between the mobile terminal and a PDN gateway.

Such PDN gateway may be a network component comprising a gateway functionality regarding the respective packet data network and it may act as a Home Agent (HA) or as a Local Mobility Anchor (LMA) .

It is also an embodiment that the mobile terminal is attached and/or handed over to a 3GPP access.

According to an embodiment, the connection identifier is communicated to the PDN gateway. In particular the connection identifier can be communicated between the mobile terminal and the gateway (e.g., a PDN GW) using the Protocol Configuration Options (PCO) .

The "Protocol Configuration Options" (PCO) are based on the definition pursuant to 3GPP TS 24.008 (information element in NAS signaling, see clause 10.5.6.3) . The PCO is transparently forwarded by all network elements between the PDN GW - it appears as a direct communication channel between the UE and PDN GW, which can be used to transfer additional protocol data without any support by the other network elements (like MME and Serving gateway) .

According to an embodiment, the connection identifier is assigned the same value by the mobile terminal as an EPS bearer identifier of the setup bearer.

Said EPS bearer may be any bearer of a packet system, in particular of an evolved packet system, e.g., it may be the default EPS bearer.

According to another embodiment, the mobile terminal is attached and/or handed over to a non-3GPP access. In yet another embodiment, the connection identifier is assigned by using and/or extending IP mobility management messaging and/or protocol. In particular, the connection identifier may be conveyed to the (PDN) gateway using and/or extending IP mobility management messaging and/or protocol.

According to a next embodiment, a DSMIPvβ signaling is used to convey the connection identifier from the mobile terminal to a gateway, in particular acting as a home agent (HA) .

This approach may in particular be applied in case of host- based mobility.

Pursuant to yet an embodiment, the connection identifier is conveyed from the mobile terminal to a gateway, comprising the steps:

- The connection identifier is conveyed to a AAA server via an authentication messaging, in particular via an EAP-AKA or via an EAP-AKA' authentication messaging; - the connection identifier is conveyed by the AAA server to a network element acting as a Mobile Access Gateway, in particular utilizing Diameter authentication and/or authorization messages;

- the Mobile Access Gateway conveys the connection identifier to the gateway, in particular using a

Proxy Mobile IP signaling.

This approach may be applied in particular in case of network-based mobility.

According to another embodiment, the connection identifier is conveyed from the mobile terminal to the AAA server via the EAP-AKA or via the EAP-AKA' authentication messaging as follows : - In case of a trusted non-3GPP access, the mobile terminal conveys the connection identifier at access authentication in an EAP-AKA or in an EAP-AKA' message; - In case of an untrusted non-3GPP access, the mobile terminal conveys the connection identifier in an EAP- AKA message during an authentication for setting a tunnel towards a network element that acts as authenticator and/or as the Mobile Access Gateway.

Such a Mobile Access Gateway could be an evolved packet data gateway (ePDG) .

Pursuant to yet an embodiment, the connection identifier is conveyed from the AAA server to a network element acting as the Mobile Access Gateway, in particular utilizing Diameter authentication and/or authorization messages as follows:

- In case of a trusted non-3GPP access, a STa reference point is used;

- In case of a untrusted non-3GPP access, a SWm reference point is used.

According to just another embodiment, multiple connection identifiers are at least partially conveyed with corresponding APNs, in particular in case a request for setting up several PDN connections is signaled during a single authentication process.

According to a further embodiment, at least one connection identifier that is associated with the corresponding APN is conveyed to the Mobile Access Gateway via authentication and authorization messages, in particular via a STa reference point or via a SWm reference point.

It is noted that said network element to convey the connection identifier to the gateway may be a trusted non- 3GPP GW (in case of trusted non-3GPP access) or an ePDG (in case of untrusted non-3GPP access) and the PDN connection identifier may be conveyed to the gateway via a PBU.

Pursuant to yet an embodiment, IKEv2 and proxy mobile IP communication is used to convey the connection identifier from the mobile terminal to a PDN gateway, comprising the steps :

- The connection identifier is conveyed from the mobile terminal to an ePDG, during access authentication, using IKEv2 signaling in particular during tunnel setup to the ePDG;

- the ePDG acting as Mobile Access Gateway conveys the connection identifier to the (PDN) gateway, in particular using a Proxy Mobile IP signaling.

This approach may be applied in particular in case of network-based mobility and untrusted non-3GPP access.

The problem stated above is also solved by a device comprising a and/or being associated with a processor unit and/or a hard-wired circuit and/or a logic device that is arranged such that the method as described herein is executable thereon.

According to an embodiment, the device is a communication device, in particular a or being associated with network element .

The problem stated supra is further solved by a communication system comprising the device as described herein.

Embodiments of the invention are shown and illustrated in the following figure:

Fig.l a block diagram comprising steps to be processed to preserver PCIDs in particular in case of a handover.

Thus, in order to meet the objective for a mobile terminal, in particular a UE, to provide multiple PDN connections to the same APN, e.g., in case of non-3GPP access, the PDN connections may have to be uniquely identified so that (a) the UE can require the release of a specific PDN connection when several connection have been set up to the same APN - while using any access types;

(b) after a handover to the same or to any different access type, the UE can preserve the PDN connections, by requesting the establishment of the PDN connections using a unique identifier of the PDN connection that was assigned to this connection before the handover.

Access types may comprise in particular at least one of the following:

- 3GPP access (the network using a GTP based S5 and/or S8 reference points) ; - trusted non-3GPP access network supporting and/or not supporting MIP, PMIP or any derivates thereof;

- untrusted non-3GPP access network connected to the EPC via an evolved Packed Data Gateway

(ePDG) supporting or non-supporting PMIP.

In particular, as the support for multiple PDN connections to the same APN is not part of 3GPP Rel-8, the solution provided is advantageously backward compatible, i.e. if, e.g., it may be part of 3GPP Rel-9 standards, it might ensure that - a Rel-9 UE supporting the new function can use the services of a Rel-8 network or a network in which some network elements (e.g. in the non-3GPP AN, in the HPLMN or in the VPLMN) are Rel-9 compatible, but other network elements need not be Rel-9 compatible; - a Rel-9 network can serve a Rel-8 UE and provide it with IP connectivity and mobility services as set forth in Rel-8.

Fig.l shows a block diagram comprising steps to be processed to preserve PCIDs in particular in case of a handover.

In a step 101, a UE assigns PDN Connection Identifiers (PCIDs) for its PDN connections in particular at the setup of an EPS bearer. All EPS bearers that belong to the same PDN connection may be assigned the same PCID. In a step 102 the PCIDs are preserved, e.g., to be used after a handover. In a step 103, the PCIDs preserved are used after the handover has been conducted.

It is noted that while the UE is attached to the 3GPP access, the "PDN connection" as such may not exist for the UE, at least it may not "directly" exist. Hence, the UE may utilize the fact that the EPS bearers that have been set up implicitly belong to the same or to different PDN connections: A new default bearer may indicate that a new PDN connection is set up.

The PCIDs shall be communicated between the UE and PDN GW (s), in the 3GPP access (UTRAN and E-UTRAN) and/or non-3GPP access .

For the 3GPP access, Protocol Configuration Options (PCO) are used and extended; in case of the non-3GPP access, an IP mobility management determines the possible means.

For non-3GPP access with host based mobility, a DSMIPvβ signaling can be used to convey the PCIDs from the UE to the PDN GW. In case of PMIP, the UE can communicate the PCIDs and the APN names to a gateway, in particular a MAG, via an AAA infrastructure and the PMIP may be extended to forward such information to the PDN GW.

For the communication between the UE and the AAA infrastructure, an extension of the EAP-AKA/EAP-AKA' authentication messages may be applied. For example, when communicating the PCID between the AAA infrastructure and the MAG, an extension of Diameter messages over the SWm interface or over the STa interface can be used.

Hereinafter, implementation and advantages are described regarding various adaptations according the introduction of PCID in particular based on existing 3GPP specification TS 23.402.

1. Initial attach

When a PDN connection is set up at an initial attach, the UE may assign an identifier to it that is unique within the UE. This identifier will be referred to as "PDN connection Id" (PCID) .

The PCID can be encoded by an integer; its usable range may be limited by a maximum number of EPS bearer ID which can be encoded in 4 bits (see 3GPP TS 29.274) .

It is noted that a PCID unique only within a UE and APN pair (i.e. combination of UE and APN) could be used as well.

If the attach is made to a 3GPP access, the PDN connection creation is implemented by the creation of a default EPS bearer. During this, the UE may send the PCID directly to the PDN GW, within the Protocol Configuration Options (PCO) :

(1) To enable this, a new element for the "additional parameters list" in the PCO can be defined for the PCID.

(2) The UE may assign the EPS bearer ID of the first setup bearer belonging to a new PDN connection as PCID.

(3) The UE may assign the same PCID to any further EPS bearers (e.g. dedicated EPS bearers) belonging to the same PDN connection.

If the UE attaches to the EPC via a non-3GPP access network, the process of creating the PDN connection and also the way of communicating the PCID may depend on the non-3GPP AN being trusted or non-trusted and/or on a IPMM protocol that is used (e.g., preconfigured or selected) : (a) In case of DSMIPvβ, the UE may include the PCID to the Binding Update (BU) request sent to the PDN GW.

- It is noted that if dynamic IP mobility mode selection is used, the IPMM decision is made (by an AAA Server) after the access authentication over an

STa reference point (in case of trusted non-3GPP access) or after the authentication for tunnel setup to the ePDG via an SWm reference (in case of untrusted non-3GPP access) has been processed; therefore, the UE may send the PCID during this process to satisfy PMIP needs; this PCID may not be utilized, but sent by the UE again, directly to the PDN GW. The STa reference point is defined between a trusted non-3GPP GW and a 3GPP AAA Server or between a trusted non-3GPP GW and the 3GPP AAA Proxy. The SWm reference point is defined between an ePDG and a 3GPP AAA Server or between an ePDG and the 3GPP AAA Proxy. The definition of these reference points and their functionalities is provided by 3GPP TS 23.402.

(b) In case of PMIP and a trusted non-3GPP AN, the UE may include the PCID in the EAP Response/AKA' -Challenge message. Hence, it may send it to the AAA Server. The AAA server may in turn send the PCID to the trusted non- 3GPP GW in the final authentication and authorization answer. A new Attribute Value Pair (AVP) can be defined to carry the PCID. The trusted non-3GPP GW may include the PCID into a Proxy Binding Update (PBU) sent to the PDN GW, using, e.g., Vendor Specific Mobility Option (VSMO) .

- The EAP-AKA/EAP-AKA' protocol can be extended by a new attribute that carries the PCID (could be called, e.g. , AT_PCID) .

- It is noted that 3GPP standards already allow that the UE sends the supported and/or preferred mobility protocols (AT_IPMS_IND attribute) in the same EAP response . - In order to improve the PDN connection setup capabilities for RAT types that do not allow any signaling of APN names, the AAA infrastructure could also be used to convey multiple APN request at the initial setup. In this case, a more complex parameter may be utilized in the EAP-Response/AKA' -Challenge message that comprises both APN names and corresponding PCIDs. The procedure is similar in that the AAA server downloads these in the final authentication and authorization response: The trusted non-3GPP GW may then setup all PDN connections .

(c) In case of PMIP and an untrusted non-3GPP access, two alternative options can be identified for conveying the PCID from the UE to the PDN GW.

According to a first option, the UE may include the PCID in a EAP-Response/AKA-Challenge message during an authentication that is executed during tunnel setup to the ePDG and send it to the 3GPP AAA Server; the AAA Server may in turn send the PCID to the ePDG using Diameter messaging; subsequently, the ePDG may convey it within the PBU message to the PDN GW (as described above for the trusted non-3GPP access case) . According to a second option, the UE could utilize the IKEv2 protocol during the tunnel setup to send the PCID directly to the ePDG, which may in turn send it to the PDN GW.

2. Adding and releasing EPS bearers

When a new EPS bearer is created to the same PDN connection (e.g., a request that comes from an application that has already an active bearer to the given APN) , the UE shall assign the same PCID to such bearer. It is noted that on the PMIP based S5 and/or S8 reference points, or later if a handover is made to a non-3GPP access, such EPS bearer may correspond to the same PDN connection.

3. Creating additional PDN connections, releasing PDN connections

(a) When an additional PDN connection and/or an EPS bearer corresponding to a new PDN connection is created, the UE may assign a new PCID to it.

(b) When a PDN connection is released, the UE may add the corresponding PCID to the set of freely assignable PCIDs.

(c) In case of 3GPP access:

- The UE may send the PCID using the PCO, similarly to the initial attach described above.

- The creation of a new PDN connection may correspond to setting up an EPS bearer to an APN from an application that had no bearer so far to the given APN or setting up an EPS bearer to a new APN. ■ It is noted that in case of PMIP based S5 and/or S8 reference points, a new PMIP binding can be created under the same conditions.

- It is noted that if PMIP based on S5 and/or S8 reference points is used, multiple connections to the same APN may not be supported in the 3GPP Rel-8. Hence, such EPS bearer setup request could be rejected by a Rel-8 compatible Serving Gateway (SGW) .

However, a Serving Gateway supporting the multiple PDN connections for the same APN, also for PMIP based S5/S8 (e.g., a 3GPP Rel-9 compatible Serving Gateway could support it) may include a new identifier to the PBU, to allow for unique identification (in case the user ID and the APN are not sufficient) . As the PCID is carried in the PCO, the SGW may not be able to detect it. Therefore, the additional identifier of the PMIP binding shall be created by the SGW. A Generic Routing Encapsulation (GRE) key (already used in 3GPP Rel-8) may be utilized as such additional identifier . ■ It is also noted that this additional identifier is not required for handling the handover (the PDN GW may identify the "re-built" PDN connection based on the PCID, see below) .

- The PDN connection can be considered to be released when all corresponding EPS bearers are released.

^■ It is noted that in case of PMIP based S5 and/or S8 reference points, the PMIP binding can be released under the same conditions.

(d) In case of a non-3GPP access network, signaling the PCID from the UE to the PDN GW may depend on the IPMM and the trusted and/or untrusted access:

- In case of DSMIPvβ, the UE may include the PDN connection identifier to the BU request similar as done in the initial attach.

- In case of PMIP with untrusted access, the authentication (EAP-response / AKA-Challenge or IKEv2 signaling) can be used, as for the initial attach. This is possible, as there is a new authentication performed for each PDN connection.

- In case of PMIP and trusted access, there is no need to execute an authentication (the trusted AGW receives all APN related information and can act on UE ' s PDN connection request without further invocation of the AAA infrastructure) .

The following options to signal the PCID may be applicable :

^■ If the radio access signaling can be extended with the PCID, the UE can add this (besides the APN name) when requesting the creation of a new PDN connection or requesting the release of an existing connection. This method is efficient, however, it is access specific. ^■ If the radio access type does not allow for the signaling of PCID, but it allows for requesting a new APN, and there is a need to multiple connections to the same APN, the UE may advantageously send a request for a "new APN"

(using the same APN name) . Detecting such request, the trusted non-3GPP GW could initiate a new authentication (preferably a fast re-authentication will be used) at each PDN connection setup or release request received from the UE, to allow that the PCID is conveyed from the UE to the AAA Server and from the AAA Server to the trusted non-3GPP GW. This is a general approach, but it may require a significant amount of signaling for the purpose of signaling the PCID. Therefore, the access specific signaling (as described above) may preferably be used when the RAT enables it. Still, that could be an optional feature for the UE.

^■ If the radio access type does not allow any APN signaling, the limitation may remain that the UE cannot add any additional PDN connections after initial attach.

4. Handover in 3GPP and non-3GPP accesses

(a) If a handover is made within the 3GPP access network, the UE and the PDN GW may preserve the PCIDs (i.e. it may not be part of context transfer) . The bearer Id may identify the bearers in the PDN GW also after handover, so the same state is maintained in the UE and in the PDN GW.

(b) If the UE executes a handover in the non-3GPP access network, the mechanism depends on the used IP mobility management protocol:

- If DSMIPvβ is used after the handover, the UE may be responsible for setting up the PDN connections using the same PCIDs that were used before the handover. - If PMIP is used after the handover, the AAA server may download the PCIDs to the new MAG, e.g., in a final authentication and authorization response, as done for the initial attach. For that, the AAA Server may store the PCID information received from the UE, associated with the APN information.

- It is noted that the handover between different non- 3GPP access networks is not intended to be covered by 3GPP specifications. Still, the PCID can be provided as well as supported for such handovers according to the mechanisms provided herewith.

5. Handover between 3GPP and non-3GPP accesses

(a) The UE and the PDN GW are responsible to preserve the

PCID in case of intersystem handover. This ensures that a PDN connection (among several ones to the same APN) can be identified also after the handover.

(b) In case of handover from the 3GPP access to the non-3GPP access, the UE may include the PCID to the EAP- Response/AKA' -Challenge or AKA-Challenge similarly to the initial attach procedure.

- However, the UE may add all PCIDs for the PDN connections that it wants to preserve after the handover .

- If PMIP is used (preconfigured or selected by an AAA server) , the AAA server may download all of the received PCIDs to the MAG. This allows the MAG to set up all PDN connections that the UE wants to preserve, also in case when the RAT type does not allow the signaling of APNs.

^■ It is noted that the PCIDs can be coupled to the APNs in order to let the MAG know, which PCID to include in which PBU. As at this phase, the AAA server has no information on the PCIDs, it is advantageous for the UE to include APN-PCID pairs with the EAP-Response/AKA-Challenge message. - If DSMIPvβ is used, the AAA server may not download the PCIDs; the UE can be responsible for setting up the DSMIPvβ bindings to the PDN GWs after the handover; it shall include the same PCIDs that have been used prior to the handover.

^■ Consequently, if the UE has preconfigured information that DSMIPvβ is used in a given non- 3GPP access network, it may omit the PCID information from the EAP response/AKA-Challenge or AKA' -Challenge.

(c) In case of a handover from a non-3GPP access to a 3GPP access, the UE may send the EPS bearer setup requests including the PCIDs that it has assigned to the PDN connections earlier. The UE may in particular use the same PCIDs to set up connections for the same applications .

6. Backward compatibility

If the functionalities described above would become part of 3GPP Rel-9, backward compatibility may be ensured in particular by using the following approaches:

(a) Protocol extensions provided may ensure Rel-8 functionality if some network elements do not support PCID.

- In the AAA interfaces, the existing mechanisms (defined in 3GPP TR 29.909) can be used to signal that a Diameter peer (MAG, AAA Server, PDN GW) supports Rel-9. If only Rel-8 support is indicated or signaled, the PCID related parameters may not be sent and the UE can use the Rel-8 functionalities only. (The PDN GW may reject setting multiple PDN connections to the same APN if the PCID is not received. )

- New attributes in EAP-AKA and/or EAP-AKA' can be defined as optional. Therefore, the Rel-8 AAA server may discard this parameter but continue the authentication procedure.

- Vendor Specific Mobility Option is defined as optional, so a Rel-8 PDN GW can successfully process the first PDN connection request to an APN.

- If the GRE key is used to uniquely identify the PMIP binding, there may be no extension required for the PMIP based on S5 and/or S8 reference points.

- For the PCO, the existing backward compatibility concept applies.

- If IKEv2 is used to convey PCID, a new, non-mandatory configuration parameter can be used.

(b) The user and/or the UE may be notified by the network about the specific reason of rejecting an EPS bearer request or PDN connection setup request. Accordingly, if a Rel-9 UE initiates the actions as described above, it will receive an indication about the network not supporting the PCID. This is ensured by the following approaches:

- In case of 3GPP access, the PDN GW should signal the supported 3GPP release in the PCO; or if the mechanisms described above are defined as optional, e.g., in 3GPP Rel-9, it may signal the support of the PCID and the mechanisms described above. The UE not receiving such an indication may know that it cannot initiate multiple PDN connections to the same APN and it may inform the user in case such connection is requested. - In case of DSMIPvβ, the PDN GW may acknowledge the

PCID in the BA response, e.g., by including the same VSMO that was received in the BU. A UE not receiving this acknowledgment may know that multiple PDN connections to the same APN are not possible. - In case of PMIP, informing the UE depends on which network element does not support the PCID. ■ The UE can be informed if the AAA server does not support the PCID in case the AAA server is required to send an acknowledgement in the EAP Request / AKA-Notification that is already used in Rel-8 for informing the UE about the selected IP mobility mode . " If the MAG or the PDN GW does not support the PCID, this can be signaled to the AAA server, using the mechanism as set forth or based on 3GPP TR 29.909, chapter 5.4. Hence, the AAA server may know the MAG ' s support of the PCID already when receiving the first authentication request (with the EAP- identity in the EAP payload) . Consequently, the AAA server can omit the acknowledgment mentioned above. Thus, it becomes clear to the UE that multiple PDN connections to the same APN are not possible. ■ However, the AAA server may be contacted by the PDN

GW in particular after the successful access authentication. Therefore, the AAA server may not be able to inform the UE if the PDN GW does not support the PCID and/or multiple PDN connections. * This can be overcome if the MAG does not send the

AKA-Notification until the PMIP binding is set up . * Another way is that the indication is based on earlier communication with the PDN GW. This can be used in all cases, except when the UE

(connected to a non-3GPP access not supporting any APN signaling) requires the setup of multiple PDN connections already at initial attach. In all the other cases, the request to a second PDN connection to the same APN may use the same PDN

GW, about which the AAA server has already information. Therefore, the AAA server can omit the indication of PCID support in the AKA- Notification . * Also, the MAG can be informed about a PDN GW not supporting the PCID. Document RFC 5094 requests that the HA/LMA acknowledges that it understood the content. This mechanism may not be followed for those options that are supported by PDN GW in Rel-8, but it could be used for the new PCID type. If there is no VSMO acknowledgment, the MAG can conclude that the PDN GW does not support PCID.

* In case of an untrusted non-3GPP access, the ePDG has not yet sent an IKEv2 IKE AUTH response to the last request as it waits for the IP address allocated by the PDN GW. For this reason, it can still indicate to the UE the lack of support of

PCID by the PDN GW. This may require a new error type to be carried with a notify payload. In case of a trusted access, the trusted AGW can inform the UE as far as this is allowed by radio signaling.

(c) It is noted that non-3GPP access architecture and protocols, especially PMIP, as defined for Rel-8 have only limited functionality to inform the UE about the reasons of any unsuccessful request. Therefore, any problems identified above can be considered in a general manner, not being limited to the PCID.

List of abbreviations

3GPP 3rd Generation Partnership Project

AAA Authentication, Authorization and Accounting AGW Access GW

AKA Authentication and Key Agreement

AN Access Network

APN Access Point Name

AVP Attribute Value Pair BA Binding Acknowledgement

BU Binding Update

DSMIPvβ Dual-Stack Mobile IPv6

EAP Extensible Authentication Protocol

EPC Evolved Packet Core ePDG evolved Packet Data Gateway

EPS Evolved Packet System

E-UTRAN evolved UTRAN

GPRS General Packet Radio Service

GRE Generic Routing Encapsulation GTP GPRS Tunneling Protocol

GW Gateway

HA Home Agent

HO Handover

HPLMN Home Public Land Mobile Network HRPD High Rate Packet Data

HSS Home Subscriber Server

IKEv2 Internet Key Exchange, Version 2

IP Internet Protocol

IPMM IP Mobility Mode LAN Local Area Network

LMA Local Mobility Anchor

MAG Mobile Access Gateway

MIP Mobile IP

PBU Proxy Binding Update PCID PDN Connection Identifier

PCO Protocol Configuration Options

PDN Packet Data Network

PMIP Proxy Mobile IP PMIP6 Proxy Mobile IPv6

PS Packet Switched

RAT Radio Access Technology

Rel-8 Release 8

Rel-9 Release 9

SGW Serving Gateway

UE User Equipment

UMTS Universal Mobile Telecommunications System

UTRAN UMTS Terrestrial Radio Access Network

VPLMN Visited Public Land Mobile Network

VSMO Vendor Specific Mobility Option

WiMAX Worldwide Interoperability for Microwave Access

WLAN Wireless LAN

Claims

Claims :

1. A method for data processing comprising the step:

2. The method according to claim 1, wherein the connection identifier is assigned at or during setup of the PDN connection.

3. The method according to claim 1, wherein the connection identifier is unique for a combination comprising the mobile terminal and the APN.

4. The method according to any of claims 1 or 2, wherein the connection identifier is unique for the mobile terminal .

5. The method according to any of the preceding claims, wherein the connection identifier is used after handover .

6. The method according to any of the preceding claims, wherein the connection identifier is communicated between the mobile terminal and a PDN gateway.

7. The method according to any of the preceding claims, wherein the mobile terminal is attached and/or handed over to a 3GPP access.

8. The method according to claim 7, wherein the connection identifier is communicated to the PDN gateway by using Protocol Configuration Options.

9. The method according to claim 7, wherein the connection identifier is assigned the same value by the mobile terminal as an EPS bearer identifier of the setup bearer .

10. The method according to any of claims 1 to 6, wherein the mobile terminal is attached and/or handed over to a non-3GPP access.

11. The method according to claim 10, wherein the connection identifier is assigned by using and/or extending IP mobility management messaging and/or protocol.

12. The method according to claim 11, wherein a DSMIPvβ signaling is used to convey the connection identifier from the mobile terminal to a gateway in particular acting as a home agent.

13. The method according to claim 11, wherein the connection identifier is conveyed from the mobile terminal to a gateway, comprising the steps: - The connection identifier is conveyed to a AAA server via an authentication messaging, in particular via an EAP-AKA or via an EAP-AKA' authentication messaging;

- the connection identifier is conveyed by the AAA server to a network element acting as a Mobile Access Gateway, in particular utilizing Diameter authentication and/or authorization messages;

- the Mobile Access Gateway conveys the connection identifier to the gateway, in particular using a Proxy Mobile IP signaling.

14. The method according to claim 13, wherein the connection identifier is conveyed from the mobile terminal to the AAA server via the EAP-AKA or via the EAP-AKA' authentication messaging as follows: - In case of a trusted non-3GPP access, the mobile terminal conveys the connection identifier at access authentication in an EAP-AKA or in an EAP-AKA' message; - In case of an untrusted non-3GPP access, the mobile terminal conveys the connection identifier in an EAP- AKA message during an authentication for setting a tunnel towards a network element that acts as authenticator and/or as the Mobile Access Gateway.

15. The method according to any of claims 13 or 14, wherein the connection identifier is conveyed from the AAA server to a network element acting as the Mobile Access Gateway, in particular utilizing Diameter authentication and/or authorization messages as follows:

- In case of a trusted non-3GPP access, a STa reference point is used;

- In case of a untrusted non-3GPP access, a SWm reference point is used.

16. The method according to any of claims 13 to 15, wherein multiple connection identifiers are at least partially conveyed with corresponding APNs, in particular in case a request for setting up several PDN connections is signaled during a single authentication process.

17. The method according to any of the preceding claims, wherein at least one connection identifier that is associated with the corresponding APN is conveyed to the Mobile Access Gateway via a authentication and authorization messages, in particular via a STa reference point or via a SWm reference point.

18. The method according to claim 11, wherein the connection identifier is conveyed from the mobile terminal to a gateway, comprising the steps:

- The connection identifier is conveyed from the mobile terminal to an ePDG using IKEv2 signaling during tunnel setup to the ePDG;

- the ePDG acting as Mobile Access Gateway conveys the connection identifier to the gateway, in particular using a Proxy Mobile IP signaling.

19. A device comprising a and/or being associated with a processor unit and/or a hard-wired circuit and/or a logic device that is arranged such that the method according to any of the preceding claims is executable thereon .

20. The device according to claim 19, wherein said device is a communication device, in particular a or being associated with a network element.

21. Communication system comprising the device according to any of claims 19 or 20.