Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.402  Word version:  18.3.0

Top   Top   Up   Prev   Next
0…   4…   4.2…   4.2.2   4.2.3   4.3…   4.4…   4.5…   4.5.7…   4.6…   4.7…   4.7.2…   4.8…   4.8.2a…   4.9…   5…   5.2…   5.4…   5.5   5.6…   5.7…   5.8…   6…   6.2…   6.3   6.4…   6.4.3…   6.5…   6.6…   6.7…   6.8…   6.10…   6.13…   6.15…   7…   7.2…   7.3   7.4…   7.5…   7.6…   7.8…   7.10…   8…   8.2.1.2   8.2.1.3…   8.2.2   8.2.3…   8.2.6…   8.3…   8.4…   8.5…   9…   9.3…   9.4…   10…   13…   16…   16.1.2…   16.1.6…   16.2…   16.2.1a…   16.3…   16.4…   16.7…   16.8…   16.10…   17…   A…   C…   E…

 

6.2  Initial Attach on S2ap. 117

6.2.1  Initial Attach Procedure with PMIPv6 on S2a and Anchoring in PDN-GWp. 117

PMIPv6 specification, RFC 5213, is used to setup a PMIPv6 tunnel between the trusted non-3GPP IP access and the PDN-GW. In both roaming and non-roaming cases, S2a is present. It is assumed that MAG exists in the trusted non-3GPP IP access.
Copy of original 3GPP image for 3GPP TS 23.402, Fig. 6.2.1-1: Initial attachment with Network-based MM mechanism over S2a for roaming, LBO and non-roaming scenarios
Up
The optional interaction steps between the gateways and the PCRF in the procedures only occur if dynamic policy provisioning is deployed. Otherwise policy may be statically configured in the gateway.
This procedure applies to the Non-Roaming (Figure 4.2.2-1), Roaming (Figure 4.2.3-1) and Local Breakout (Figure 4.2.3-4) cases. For the Roaming and Local Breakout cases, the vPCRF forwards messages between the non-3GPP access and the hPCRF. In the Local Breakout case, the vPCRF forwards messages between the PDN-GW and the hPCRF. In the Roaming and LBO cases, the 3GPP AAA Proxy serves as an intermediary between the Trusted Non-3GPP IP Access and the 3GPP AAA Server in the HPLMN. In the non-roaming case, the vPCRF is not involved at all.
This procedure is also used to establish the first PDN connection over a trusted non-3GPP access with S2a when the UE already has active PDN connections only over a 3GPP access and wishes to establish simultaneous PDN connections to different APNs over multiple accesses.
Step 1.
The initial Non-3GPP access specific L2 procedures are performed. These procedures are Non-3GPP access specific and are outside the scope of 3GPP.
Up

Step 2.
The EAP authentication procedure is initiated and performed involving the UE, Trusted Non-3GPP IP Access and the 3GPP AAA Server. In the roaming case, there may be several AAA proxies involved. Subscription data is provided to the Trusted non-3GPP IP Access by the HSS/AAA in this step. The list of all the authorized APNs along with additional PDN-GW selection information is returned to the access gateway as part of the reply from the 3GPP AAA Server to the trusted non-3GPP access as described in clause 4.5.1. The 3GPP AAA Server also returns to the trusted non-3GPP access the MN NAI to be used to identify the UE in Proxy Binding Update and Gateway Control Session Establishment messages (steps 4 and 10). If supported by Non-3GPP access network, the Attach Type is indicated to the Non-3GPP access network by the UE. The mechanism for supporting attach type is access technology specific and out of scope for 3GPP standardization. Attach Type indicates "Handover" when the UE already has active PDN connection(s) due to mobility from 3GPP access to non-3GPP access.
Up

Step 3.
After successful authentication and authorization, the non-3GPP access specific L3 attach procedure is triggered. The UE may send requested APN to the Non-3GPP IP access in this step.
If the UE sends a requested APN in this step, the Trusted non-3GPP Access verifies that it is allowed by subscription. If the UE does not send a requested APN the Trusted non-3GPP Access uses the default APN.
The PDN Gateway selection takes place at this point as described in clause 4.5.1. This may entail an additional interaction with the Domain Name Server function in order to obtain the PDN-GW address. If the PDN subscription profile returned by the 3GPP AAA Server in step 2 contains a PDN-GW identity for the selected APN and the Attach Type does not indicate "Handover", the Non-3GPP access GW may request a new PDN-GW as described in clause 4.5.1, e.g. to allocate a PDN-GW that allows for more efficient routeing.
The UE may request the type of address (IPv4 address or IPv6 prefix or both) during this step.
If supported by the non-3GPP access, the UE may send Protocol Configuration Options in this step using access specific mechanisms. The Protocol Configuration Options provided by the UE may include the user credentials for PDN access authorization. In that case, in order to handle situations where the UE may have subscriptions to multiple PDNs, the UE should also send a requested APN to the non-3GPP IP access.
Up

Step 4.
The Trusted non-3GPP access initiates the Gateway Control Session Establishment Procedure with the PCRF, as specified in TS 23.203. The Trusted non-3GPP access provides the information to the PCRF to correctly associate it with the IP-CAN session to be established in step 6 and also to convey subscription related parameters to the PCRF, including the APN-AMBR (if forwarded by the trusted non-3GPP IP access) and Default Bearer QoS.
Up

Step 5.
The MAG function of Trusted Non-3GPP IP Access sends a Proxy Binding Update (MN-NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, Charging Characteristics, Additional Parameters) message to PDN-GW. The MN NAI identifies the UE. The Lifetime field must be set to a nonzero value. Access Technology Type is set to a value matching the characteristics of the non-3GPP access. The MAG creates and includes a PDN connection identity if the MAG supports multiple PDN connections to a single APN. Handover Indicator is set to indicate attachment over a new interface as the UE has provided Attach Type indicating "Initial" attach. The Additional Parameters include the Protocol Configuration Options provided by the UE in step 3 and may also include other information. The MAG requests the IP address types (IPv4 address and/or IPv6 Home Network Prefix) based on requested IP address types and subscription profile in the same way as the PDN type is selected during the E-UTRAN Initial Attach in TS 23.401. If the PDN requires an additional authentication and authorization with an external AAA Server, the PDN-GW performs such an additional authentication and authorization at the reception of the Proxy Binding Update.
Up

Step 6.
The PDN-GW initiates the IP-CAN Session Establishment Procedure with the PCRF, as specified in TS 23.203. The PDN-GW provides information to the PCRF used to identify the session and associate Gateway Control Sessions established in step 4 correctly. The PCRF creates IP-CAN session related information and responds to the PDN-GW with PCC rules and event triggers. If available, the PCRF may modify the APN-AMBR and provides the APN-AMBR and Default Bearer QoS to the PDN-GW in the response message.
Up

Step 7.
The selected PDN-GW informs the 3GPP AAA Server of its PDN-GW identity and the APN corresponding to the UE's PDN Connection. The message includes information that identifies the PLMN in which the PDN-GW is located. This information is registered in the HSS as described in clause 12. The PDN-GW shall only use the APN-AMBR and Default Bearer QoS received from the 3GPP AAA server in this step if these parameters have not been received in step 6.
Up

Step 8.
The PDN-GW processes the proxy binding update and creates a binding cache entry for the UE. The PDN-GW allocates IP address(es) for the UE. The PDN-GW then sends a Proxy Binding Acknowledgement (MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, charging ID, Additional Parameters) message to the MAG function in Trusted Non-3GPP IP Access, including the IP address(es) allocated for the UE. The UE Address Info includes one or more IP addresses. The Lifetime indicates the duration of the binding. If the corresponding Proxy Binding Update contains the PDN connection identity, the PDN-GW shall acknowledge if multiple PDN connections to the given APN are supported. The Charging ID is assigned for the PDN connection for charging correlation purposes. The Additional Parameters may include Protocol Configuration Options and other information.
Up

Step 9.
The PMIPv6 tunnel is set up between the Trusted Non-3GPP IP Access and the PDN-GW.
Up

Step 10.
The PCRF may update the QoS rules in the trusted non-3GPP access by initiating the GW Control Session Modification Procedure, as specified in TS 23.203.
Up

Step 11.
L3 attach procedure is completed via non-3GPP access specific trigger. IP connectivity between the UE and the PDN-GW is set for uplink and downlink directions. At this step the IP address information is provided to the UE. Unless already known from step 3, the Non-3GPP IP access should indicate the connected PDN identity (APN) to the UE. If supported by the non-3GPP access, the Protocol Configuration Options provided by the PDN-GW in step 8 are returned to the UE in this step using access specific mechanisms.
Up

Up

6.2.2Void

6.2.3  Initial Attach procedure with MIPv4 FACoA on S2a and Anchoring in PDN-GWp. 120

MIPv4, RFC 5944 is used to setup a MIP tunnel between the Trusted non-3GPP IP Access and the PDN-GW. It is assumed that a Foreign Agent (FA) is located in the Trusted non-3GPP IP Access.
Copy of original 3GPP image for 3GPP TS 23.402, Fig. 6.2.3-1: Initial attachment when MIPv4 FACoA mode MM mechanism is used over S2a
Up
When the Attach procedure occurs in the Non-Roaming case (Figure 4.2.2-1), the vPCRF is not involved. The optional interaction steps between the gateways and the PCRF in the procedures only occur if dynamic policy provisioning is deployed. Otherwise policy may be statically configured with the gateway.
This procedure applies to the Non-Roaming (Figure 4.2.2-1), Roaming (Figure 4.2.3-1) and Local Breakout (Figure 4.2.3-4) cases. For the Roaming and Local Breakout cases, the vPCRF forwards messages between the non-3GPP access and the hPCRF. In the Local Breakout case, the vPCRF forwards messages between the PDN-GW and the hPCRF. In the Roaming and LBO cases, the 3GPP AAA Proxy serves as an intermediary between the Trusted Non-3GPP IP Access and the 3GPP AAA Server in the HPLMN. In the non-roaming case, the vPCRF is not involved at all.
This procedure is also used to establish the first PDN connection over a trusted non-3GPP access with MIPv4 FACoA on S2a when the UE already has active PDN connections only over a 3GPP access and wishes to establish simultaneous PDN connections to different APNs over multiple accesses.
The event that triggers Authentication and Authorization in step 2 between the Trusted Non-3GPP IP Access and the 3GPP AAA Server, depends on the specific access technology.
Step 1.
The initial Non-3GPP access specific L2 procedure and Non-3GPP access specific authentication procedures may be performed. These procedures are outside the scope of 3GPP.
Step 2.
The EAP-based authentication procedure for trusted non-3GPP access networks between UE and the 3GPP EPC shall be performed as defined by TS 33.402. The PDN Gateway information is returned as part of the reply from the 3GPP AAA Server to the FA in the trusted non-3GPP access as described in clause 4.5.1. The Attach Type is indicated to the Non-3GPP access network by the UE as described in the step 2 of clause 6.2.1.
Step 3.
The UE may send an Agent Solicitation (AS) RFC 5944 message. Specification of this message is out of the scope of 3GPP.
Step 4.
The FA in the Trusted Non-3GPP IP Access sends a Foreign Agent Advertisement (FAA) RFC 5944 message to the UE. The FAA message includes the Care-of Address (CoA) of the Foreign Agent function in the FA. Specification of this message is out of the scope of 3GPP.
Step 5.
The UE sends a Registration Request (RRQ) (MN-NAI, lifetime, APN) message to the FA as specified in RFC 5944. The MN NAI identifies the UE. Reverse Tunnelling shall be requested. This ensures that all traffic will go through the PDN-GW. The RRQ message shall include the NAI-Extension RFC 2794. The UE may not indicate a specific Home Agent address in the RRQ message, in which case the PDN Gateway/Home Agent is selected by the FA as per step 2. The UE then receives the IP address of the PDN Gateway in step 13 as part of the Registration Reply (RRP) message. The UE should then include the PDN Gateway address in the Home Agent address field of subsequent RRQ messages. Subscription data is provided to the Trusted non-3GPP IP Access by the HSS/AAA in this step. The UE may request connectivity to a specific PDN by using an APN as specified in RFC 5446. If the UE provides an APN the FA verifies that it is allowed by subscription. If the UE does not provide an APN the FA establishes connectivity with the default PDN. The PDN Gateway selection takes place at this point as described in clause 4.5.1. This may entail an additional name resolution step.
Step 6.
The Trusted non-3GPP access initiates the Gateway Control Session Establishment Procedure with the PCRF, as specified in TS 23.203. The Trusted non-3GPP access provides the information to the PCRF to correctly associate it with the IP-CAN session to be established in Step 9 and also to convey subscription related parameters to the PCRF, including the APN-AMBR (if forwarded by the trusted non-3GPP IP access) and Default Bearer QoS.
Step 7.
The FA processes the message according to RFC 5944 and forwards a corresponding RRQ (MN-NAI, APN) message to the PDN-GW.
Step 8.
The selected PDN-GW obtains Authentication and Authorization information from the 3GPP AAA/HSS.
Step 9.
The PDN-GW allocates an IP address for the UE. The PDN-GW initiates the IP-CAN Session Establishment Procedure with the PCRF, as specified in TS 23.203. The PDN-GW provides information to the PCRF used to identify the session and associate Gateway Control Sessions established in step 6 correctly. The PCRF creates IP-CAN session related information and responds to the PDN-GW with PCC rules and event triggers.
Step 10.
The selected PDN-GW informs the 3GPP AAA Server of the PDN-GW identity and the APN corresponding to the UE's PDN Connection. The message includes information that identifies the PLMN in which the PDN-GW is located. This information is registered in the HSS as described in clause 12.
Step 11.
The PDN-GW sends a RRP (MN-NAI, Home Address, Home Agent Address, Lifetime) as defined in RFC 5944 to the FA. The Home Address includes UE Home IP address, the Home Agent Address contains the IP address of Home Agent. The Lifetime indicates the duration of the binding.
Step 12.
In case the QoS rules have changed, the PCRF updates the QoS rules in the Trusted non-3GPP access by initiating the GW Control Session Modification Procedure, as specified in TS 23.203.
Step 13.
The FA processes the RRP (MN-NAI, Home Address, Home Agent Address) according to RFC 5944 and sends a corresponding RRP message to the UE.
Step 14.
IP connectivity from the UE to the PDN-GW is now setup. A MIPv4 tunnel is established between the FA in the Trusted Non-3GPP IP Access and the PDN-GW.
Up

6.2.4  Initial Attach Procedure with PMIPv6 on S2a and Chained S2a and PMIP-based S8p. 123

This clause defines the initial attach procedure for the PMIP-based S8/S2a chaining. This procedure also applies to the initial attach for PMIP-based S8/S2b chaining.
Copy of original 3GPP image for 3GPP TS 23.402, Fig. 6.2.4-1: Initial attachment for chained PMIP-based S8-S2a/b roaming scenarios
Up
Step 1.
The attach initiation on the trusted or untrusted non-3GPP access is performed as described in steps 1-4 of clause 6.2.1 (for trusted non-3GPP access) and step 1 of clause 7.2.1 (for untrusted non-3GPP access). As part of the authentication procedure, the 3GPP AAA proxy obtains the PDN-GW selection information from the HSS/AAA as described in clause 4.5.1, and performs Serving-GW selection as described in clause 4.5.3. 3GPP AAA proxy provides both PDN-GW selection information and Serving-GW identity to the MAG function of the trusted non-3GPP access or ePDG. Then the MAG function performs the PDN-GW selection. If PCC is deployed, the MAG function of the Trusted Non-3GPP IP access is notified to interact with the PCRF when it is PMIP-based chained case.
Step 2.
The MAG function of Trusted Non-3GPP IP Access or ePDG sends a Proxy Binding Update (MN-NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, PDN-GW address, Additional Parameters) message to the Serving-GW in the VPLMN. The MN NAI identifies the UE. The Lifetime field must be set to a nonzero value, indicating registration. Access Technology Type is set to a value matching the characteristics of the non-3GPP access. The MAG creates and includes a PDN connection identity if the MAG supports multiple PDN connections to a single APN. Handover Indicator is set to indicate attachment over a new interface. The MAG requests the IP address types (IPv4 address and/or IPv6 Home Network Prefix) based on requested IP address types and subscription profile in the same way as the PDN type is selected during the E-UTRAN Initial Attach in TS 23.401. The Additional Parameters may include Protocol Configuration Options and other information.
Step 3.
The Serving-GW sends a corresponding Proxy Binding Update (MN-NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, Additional Parameters) message (as in step 2) to the PDN-GW. The GRE key for downlink traffic is allocated by the Serving-GW. If the MAG included the PDN connection identity in the Proxy Binding Update of the previous step and the Serving-GW supports multiple PDN connections to a single APN then the Serving-GW forwards the PDN connection identity to the PDN-GW.
Step 4.
The PDN-GW initiates the PCEF-initiated IP-CAN Session Establishment Procedure with the hPCRF, as specified in TS 23.203.
Step 5.
The selected PDN-GW informs the 3GPP AAA Server of the PDN-GW identity. The message includes information that identifies the PLMN in which the PDN-GW is located. The 3GPP AAA Server then conveys this information to the HSS for the UE.
Step 6.
The PDN-GW processes the proxy binding update and allocates IP address(es) for the UE. The PDN-GW creates a binding cache entry for the PMIPv6 tunnel towards the Serving-GW and sends a Proxy Binding Acknowledgement (MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, Charging ID, Additional Parameters) message to the Serving-GW. The MN NAI is identical to the MN NAI sent in the Proxy Binding Update. The Lifetime indicates the duration the binding will remain valid. The UE Address Info includes one or more IP addresses. If the corresponding Proxy Binding Update contains the PDN connection identity, the PDN-GW shall acknowledge if multiple PDN connections to the given APN are supported. The Charging ID is assigned for the PDN connection for charging correlation purposes. The Additional Parameters may include Protocol Configuration Options and other information.
Step 7.
The Serving-GW processes the proxy binding acknowledgement and creates a binding cache entry for the PMIPv6 tunnel towards the MAG function in the trusted non-3GPP access or ePDG. At this point, the Serving-GW also establishes the internal forwarding state for the concatenation of the PMIPv6 tunnels. The Serving-GW then sends a corresponding Proxy Binding Acknowledgement (MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, Charging ID, Additional Parameters) message (as in step 7) to the MAG function of Trusted Non-3GPP IP Access or ePDG. The GRE key for uplink traffic is allocated by the Serving-GW. The Charging ID is assigned for the PDN connection for charging correlation purposes.
Step 8.
The attach procedure is completed as described in steps 10-11 of clause 6.2.1 (for trusted non-3GPP access) and steps 6-8 of clause 7.2.1 (for untrusted non-3GPP access).
Up

Up   Top   ToC