E2E VoLTE call setup(2/4) : IMS registration

Once the UE attaches to the LTE network and the default EPS bearer is created successfully with the IMS APN, the UE registers to the IP Multimedia Subsystem (IMS) network before accessing the VoLTE service. The IMS registration procedure includes the IMS authentication, e.g., IMS-AKA, and security negotiation between UE and IMS network. After successful IMS registration, the IMS network becomes aware of UE context such as subscription profile, registration status, etc. After the initial IMS registration, the UE shall refresh the IMS registration status by periodically sending re-Registration.

Introduction

It is assumed that the UE has established a PDN connection to the IMS APN with the QCI value of its default EPS bearer set to ‘5’. The IMS registration signal goes through the default EPS bearer and gets inside the IMS core via the P-CSCF. The P-CSCF, I-CSCF and the S-CSCF consists the IMS core and they controls SIP signaling for VoLTE. The I-CSCF and the S-CSCF interworks with the HSS via Diameter Routing Agent (DRA) to retrieve subscriber’s profile, authentication vector, etc. At the front of the P-CSCF lies the Session Border Controller (SBC). The SBC provides a security function like IPSec, topology hiding, media controlling, etc. It can either be co-deployed with the P-CSCF or separated from the IMS Core.

NOTE the DRA between Diameter clients and Diameter servers (i.e., PCRF, HSS) is omitted in the diagram to clarify the reference points.

Figure 1. Overall architecture

I. IMS Authentication and Key Agreement (AKA) during IMS registration

The IMS AKA is a mutual authentication methodology used by the IMS network to authenticate a UE. In this authentication procedure, both server and client runs the same authentication algorithm using the same secret key and several public parameters. The secret key is known to both UE and the IMS network. It can be stored in IP Multimedia Services Identity Module (ISIM) and at the same time, be provisioned to the Home Subscriber Server (HSS) in advance. After running the authentication algorithm, the server and the client exchanges their outcome with each other and authenticate the peer by comparing the received authentication parameter with the outcome of their own. The following is the conceptual diagram of the IMS AKA mechanism.

Figure 2. IMS AKA

(1)   The secret-key K and the sequence number SQN are commonly stored in both server and client.

(2)   The UE sends the initial registration with the user identifier towards the IMS Core.

(3)   The S-CSCF (i.e., registrar) queries the HSS for the authentication vector of that subscriber. The HSS generates the random number RAND using the SQN. The HSS uses K, SQN and RAND parameters as input to the authentication algorithm and as a result, obtains a set of authentication parameters, i.e., the authentication vector (AV), as listed below:

• AUTN : Authentication token represented as a concatenation of MAC and SQN and used by the client to authenticate the server.
• XRES: Expected correct result of running authentication algorithm and used by the server to authenticate the client.
• CK: Cipher Key (Optional)
• IK: Integration Key

The S-CSCF returns AV (i.e., RAND, AUTN, CK, IK) to the P-CSCF and the P-CSCF delivers RAND and AUTN in the response to the initial registration request (see the step#31 for the detail). XRES is stored in the S-CSCF for later use. The CK and IK is used for integrity and security check by the P-CSCF (or SBC).

(4)   The UE extracts MAC and SQN from the received AUTN. The UE verifies the range of SQN and uses AUTN, K and RAND as input to the authentication algorithm. The UE compares the resulting parameter, XMAC with the received MAC. As such, the UE authenticates the server.

(5)   The resulting RES is sent back to the server. The S-CSCF authenticates the client by comparing the received RES with the XRES.

II. IMS registration procedure

Right after the default EPS bearer is established, comes IMS registration procedure. The IMS registration is the procedure for a VoLTE client to register its contact information to the IMS network and it is performed through the existing EPS bearer of QCI=5 in general. The IMS registration procedure is composed of two transactions, that is, the first one is for the UE to obtain the authentication challenge and the other one is to be authenticated using the received authentication challenge.

In case it is a re-registration, the first transaction may not be necessary. The UE will include challenge parameters received in the previous registration procedure so the network is able to authenticate the UE as long as the challenge parameters are still valid. During the registration, the VoLTE client and the IMS network authenticate each other based on the agreed authentication algorithm and in the meantime, negotiate a security algorithm for IP layer transactions. 

Fig 3. IMS registration flow

[25] The UE initiates the IMS registration by sending the SIP REGISTER towards the P-CSCF.

• Authorization: Authentication information e.g., authentication scheme, nonce, realm, authentication algorithm, etc. The nonce value is empty as this is the first registration.
• Expires: The validity time of this registration. The UE is supposed to perform re-registration before the timer is expired. It is usual for the UE to re-register after 1/2*(timer value) seconds. When the UE is connected to the LTE network, the value of this header would be 3600 seconds and when it is connected to the Wi-Fi, it would be 60 seconds typically.
• Security-Client: A list of supported security algorithm by the UE.
• Contact: UE IP address, device capabilities and various feature tags.

The following snapshot shows an example of SIP REGISTER.

Fig 4. SIP REGISTER

The P-CSCF routes the SIP REGISTER to the I-CSCF as the P-CSCF does not know at this moment as to which S-CSCF is going to serve this UE yet.

[26] Upon receiving the SIP REGISTER, the I-CSCF performs user registration status query by sending User-Authorization-Request (UAR) to the HSS.

• User-Name AVP: IMS Private User Identity (IMPI) of the user and used to authenticate the user based on the username part of the value.
• Public-Identity AVP: IMS Public User Identity, which is either SIP URI or TEL URI of the user.
• Visited-Network-Identifier AVP: The domain of the visited PLMN

The following snapshot shows an example of UAR.

Fig 5. User Authorization Request (UAR)

[27] The HSS authorizes the user for IMS service (i.e., verifying the user’s IMPI and IMPU) and if successful, returns with the S-CSCF address for this user in the response, User-Authorization-Answer (UAA).

• Server-Name AVP: The S-CSCF address assigned for the IMS subscriber.
• Experimental-Result: DIAMETER_FIRST_REGISTRATION if it is the first time IMS access for the user and there is no S-CSCF assigned yet. If there is already assigned S-CSCF for the user, it will be set to DIAMETER_SUBSEQUENT_REGISTRATION and the Server-Name AVP will be provided.

The following snapshot shows the case where there is already assigned S-CSCF for the user, in which case the I-CSCF does not have to assign a new S-CSCF. If there is no assigned S-CSCF for the subscriber, the HSS returns a set of S-CSCF capabilities and the I-CSCF shall assign a new one based on the received capabilities.

Fig 6. User Authorization Answer (UAA)

[28] The I-CSCF forwards the SIP REGISTER towards the indicated S-CSCF.

[29] The S-CSCF sends the Multimedia-Auth-Request (MAR) to the HSS requesting the authentication information.

• User-Name AVP: IMS Private User Identity (IMPI) of the user and used to authenticate the user based on the username part of the value.
• Public-Identity AVP: IMS Public User Identity, which is either SIP URI or TEL URI of the user.
• SIP-Auth-Data-Item AVP: The authentication algorithm set to “Digest-AKAv1-MD5” in this example.
• SIP-Number-Auth-Items AVP: The number of authentication vectors.

Fig 7. Multimedia Auth Request (MAR)

[30] The HSS responds with the Multimedia-Auth-Answer (MAA) containing the authentication information.

• SIP-Authorization AVP: XRES, which is one of output obtained after running the authentication algorithm (e.g., AKAv1-MD5).
• SIP-Authenticate AVP: The concatenation of RAND and AUTN to be used for authentication.

Fig 8. Multimedia Auth Answer (MAA)

[31] The S-CSCF responds with the 401 UnAuthorized to the P-CSCF. The WWW-Authenticate header includes nonce parameter (i.e., a concatenation of RAND and AUTN), IK and CK. The AUTN is a concatenation of the MAC and SQN.

• WWW-Authenticate: Authentication challenge needed for mutual authentication.

Fig 9. 401 UnAthorized

[32] The P-CSCF responds with the 401 UnAuorized towards the UE. The WWW-Authenticate header includes nonce value. The IK and CK is stored in the P-CSCF and removed from the WWW-Authenticate header. As the UE and the P-CSCF negotiated the security method to use IPsec during the initial SIP registration, the subsequent registration and the call related signals like INVITE, 200 OK, PRACK, BYE, etc. are secured based on IPsec.

• Security-Server: a list of supported security algorithm by the server.

NOTE In this field test, the SBC takes over security functions of P-CSCF. Therefore the security negotiation and maintaining security parameters like IK and CK are done by the SBC.

Fig 10. 401 UnAthorized

Upon receiving the 401 UnAuthorized, the UE extracts the MAC and the SQN from the AUTN, calculates its own XMAC and checks if the XMAC is the same as the received MAC and if the SQN is in a correct range, thereby the UE authenticates the server. The UE also obtains the RES, IK and CK as a result of running the authentication algorithm.

[33] The UE sends the subsequent SIP REGISTER towards the P-CSCF and the P-CSCF to the I-CSCF.

• Authorization header: The response to the authentication challenge along with the private user identity, realm, nonce, URI and RES.
• P-Access-Network-Info: The radio access technology and radio cell identity.

Fig 11. Subsequent SIP Registration

NOTE the above snapshot has been captured between SBC and P-CSCF as the packet on SGi/Gm interface has been secured using IPsec as a result of security negotiation and it couldn’t be decoded by the wireshark in this test. In order to complete the security negotiation, the UE must have included the Security-Verify header in the subsequent REGISTER indicating IPsec, which is not shown in this snapshot as the SBC removes the header before forwarding the message to the IMS core.

[34] Upon receiving the SIP REGISTER, the I-CSCF performs user registration status query by sending User-Authorization-Request (UAR) to the HSS.

Fig 12. User Auth Request (UAR)

[35] The HSS authorizes the user for IMS service (i.e., verifying the user’s IMPI and IMPU) and if successful, returns with the S-CSCF address for this user in the response, User-Authorization-Answer (UAA).

Fig 13. User Auth Answer (UAA)

[36] The I-CSCF forwards the SIP REGISTER towards the indicated S-CSCF. Upon receiving the subsequent SIP REGISTER, the S-CSCF compares the stored XRES with the received RES (i.e., Digest Authentication response parameter). If they are identical and successfully authenticated, the public user identity is registered in the S-CSCF.

[37] The S-CSCF informs the HSS that the user has been registered by sending Server Assignment Request (SAR). Upon receiving the SAR, the HSS stores the mapping relation between the S-CSCF and the corresponding IMS subscriber.

• User-Data-Already-Available AVP: Indicator of whether or not the sending S-CSCF has user profile information which is required to service the user. If it is set to USER_DATA_NOT_AVAILABLE, the HSS is expected to provide the user data in the response.

Fig 14. Server Assignment Request (SAR)

[38] The HSS responds with the Server Assignment Answer (SAA) to the S-CSCF. As it was indicated in the SAR that the S-CSCF does not have user profile, the HSS includes the User-Data AVP in the response. 

Fig 15. Server Assignment Request (SAA)

The User-Data AVP may contain the following items as is shown below:

• Private Id
• Service Profile
• Public Identity
• a list of initial Filter Criteria (iFC)

Fig 16. User Data in SAA

[39] The 200 OK for the SIP REGISTER is sent back towards the UE following the reverse signaling path.

Fig 17. 200 OK to SIP EGISTER

NOTE the above message has been captured on the interface between SBC and P-CSCF as the 200 OK on SGi/Gm interface has been secured using IPsec.

After successful IMS registration, the UE subscribes to the reg event package for the public user identity registered at the S-CSCF. The UE will get notified of a registration status of public identities belonging to the same user.

Fig 18. Subscription for reg event package

[40] The UE subscribes to the reg event package by sending SIP SUBSCRIBE towards the S-CSCF.

• Event: “reg” indicating this is the subscription to the reg event package
• Expires: Validity time period during which this subscription session is valid..

Fig 19. SIP SUBSCRIBE

[41] The P-CSCF forwards the SIP SUBSRIBE to the S-CSCF which is known to P-CSCF during the registration procedure.

Fig 20. SIP SUBSCRIBE

[42-43] The S-CSCF returns with the 200 OK response and it is forwarded to the UE following the signaling path.

Fig 21. 200 OK response to SIP SUBSCRIBE

[44-45] The S-CSCF notifies the UE of its current registration status by sending SIP NOTIFY, which is forwarded to the UE

Fig 22. SIP NOTIFY

[46-47] The UE responds with 200 OK response towards the S-CSCF.

Fig 23. 200 OK response to SIP NOTIFY

REFERENCE

[1] IETF RFC4740, "Diameter Session Initiation Protocol (SIP) Application", Nov 2006

[2] IETF RFC3310, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", Sep 2002

[3] IETF RFC7315, "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for the 3GPP", July 2014

[4] IETF RFC3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", Jan 2003

[5] 3GPP TS 29.228, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signaling flows and message contents", v12.3.0, Sep 2014

[6] 3GPP TS 29.229, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", v12.6.0, Jun 2015

[7] 3GPP TS 24.228, "Signaling flow for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)", v5.15.0, Sep 2006

[8] 3GPP TS 33.203, "3G Security; Access security for IP-based services", v12.5.0, Mar 2014

 Last Updated: 8th Mar 2016

E2E VoLTE call setup(1/4) : Initial attach and default EPS bearercreation

When the UE is turned on, it establishes a PDN connection with a default APN. In this test for VoLTE call setup, the operator provides two APNs, i.e., “Internet” APN and the “IMS” APN. The default APN is an “Internet” APN that is used for internet data traffic and its default EPS bearer has a QCI value of ‘9’. After the PDN connection is established with the internet APN, the UE attempts additional PDN connection with the IMS well known APN, i.e., “IMS APN”. The IMS APN is preconfigured in the UE and its default EPS bearer has a QCI value of ‘5’ being used for SIP signaling. Once the PDN connection with the IMS APN is completed and the default EPS bearer is successfully created, the UE is able to communicate with the IMS Core for VoLTE call service.

Introduction

The UE's initial attach procedure consists of two routines. One is to establish a signaling path on RRC, S1AP and GTP-C interfaces and the other one is to establish the bearer path including Data Radio Bearer (DRB) and GTP-U (i.e., S1 and S5 bearer). The following diagram show overall LTE architecture and different signaling and media paths with multiple PDNs.

NOTE In this diagram, the S5 interface between the SGW and the PGW has been omitted for simplicity.

Figure 1. PDN Connectivity

The signaling connection procedure involves LTE authentication, NAS security procedure and the UE's location update procedure. Therefore, when the signaling connection is completed, the UE comes to have a secured connection to communicate with the network and the network becomes aware of the UE's context as to its location, subscriber's information, QoS requirements, etc. Along with the signaling connection, there comes a default EPS bearer established from the UE to the PGW, which covers the DRB, S1 bearer and S5 bearer.

I. Initial attachment 

A UE establishes an RRC connection with an eNB and the eNB creates an S1AP session with an MME for signaling. The NAS messages are exchanged between UE and the MME once the RRC and S1AP connection is established and it is composed of two layers, i.e., EPS Session Management (ESM) layer and EPS Mobility Management (EMM) layer. The ESM message is used to control PDN connectivity, bearer resource allocation/modification, activation/deactivation of a default/dedicated EPS bearer. The EMM message is used to maintain the mobility of the UE using e.g., Attach, Detach, Tracking Area Update (TAU). The NAS message transparently goes through the eNB contained in RRC and S1AP messages.

Figure 2. Initial Attach flow

[1-2] The UE in idle mode requests the eNB to establish a signaling connection by sending RRC Connection request. The eNB allocates the network resource based on the received radio configuration and initiates an RRC connection towards the UE by sending RRC Connection Setup.

[3] The UE configures a radio bearer and transport channel based on predefined parameters identified by a received predefined configuration identity and confirms RRC connection by sending the RRC Connection Setup Complete to the eNB. Meanwhile, the NAS messages (i.e., Attach Request at EMM layer and the PDN Connectivity Request at ESM layer) is transparently delivered to the MME via eNB being contained in the RRC and S1AP messages (i.e., RRC Connection Setup Complete and InitialUEMessage, respectively).

The following snapshot shows the NAS part of InitialUEMessage captured on S1AP interface.

Figure 3. InitialUEMessage

In case the UE wants to use both LTE and non-LTE, the EPS Attach type will be set to "Combined EPS/IMSI attach" and the Voice domain preference set to "IMS PS voice preferred, CS voice as secondary".

• EPS Attach Type : EPS attach/combined EPS/IMSI attach/EPS emergency attach
• Voice domain preference : a preferred network for voice call

The Protocol Configuration Option (PCO) is used by the UE to request a certain information like UE IP address, DNS IP address, etc. 

The following snapshot shows an example of PCO configuration included in the initialUEMessage.

Figure 4. PCO for initial attachment

The following snapshot shows other parameters of initialUEMessage, which contains the UE's location information (i.e., Tracking Area Identifier, E-UTRAN Cell Global Identity) and RRC establishment cause.

Figure 5. Parameters in initialUEMessage

[4-5] Upon receiving the Attach Request, the MME requests the authentication vector to HSS by sending Authentication Information Request (AIR) to authenticate the subscriber. 

Figure 6. Authentication Information Request

The HSS responds with the Authentication Vector in the Authentication Information Response (AIA) as shown in the following snapshot.

Figure 7. Authentication Information in AIA

The following diagram shows a conceptual data flow of LTE-AKA authentication. The MME delivers the AUTN and RAND to the UE among the received parameters. (2) The UE authenticates the network by running the authentication algorithm which uses the received RAND and local parameters as input and then (3) verifies if the output of the calculation is matched with the received AUTN. The UE sends the RES which is another output of the authentication algorithm to the MME so that (4) MME can verify the RES by comparing it with the XRES received from the HSS in (1).

Figure 8. LTE authentication

As such the UE and LTE network performs the mutual authentication. After successful authentication, there comes the NAS security establishment procedure between the UE and the LTE network in order to provide a secured data transfer and data integrity.

II. Location update and GTP-C session creation

In this part of the flow, the MME updates the UE's location information stored in the HSS and creates GTP-C session with the SGW. The GTP-C session is used to control GTP-U (i.e., S1 and S5 bearers) media session belonging to the same APN.

Figure 9. Location update and GTP-C session creation flow

[6-7] The MME registers the UE's location to the network by sending Update Location Request to the HSS. The following lists some of parameters as shown in the snapshot.

• User-Name AVP: IMSI
• Terminal Information AVP: IMEI, Software version
• Visited PLMN-Id AVP: MCC and MNC of a visited network
• RAT-Type AVP: EUTRAN

Figure 10. Update Location Request

In return, the MME receives the Update Location Answer from the HSS and it contains the APN list as shown in the snapshot below.

Figure 11. Update Location Answer

Upon receiving the list of APN in the Update Location Answer (ULA), MME determines the default APN. In this example, there are two APNs received as shown in the following snapshot.

Figure 12. APN list

The following snapshot shows the detailed APN configuration. One of APNs (bottom one) is an "Internet" APN as indicated by Service-Selection AVP. The other APN (upper one) is an “IMS” APN. The default APN is determined by comparing the Context-Identifier AVP under the APN-Configuration-Profile AVP with another Context-Identifier AVP in the APN-Configuration AVP. In this case, the context identifier value of "10" in the APN-Configuration AVP for “Internet” is matched with the context identifier value in the upper layer. Given this, the MME will select the “Internet” APN as a default APN.

Figure 13. APN Configuration Profile

[8] The MME requests S11 (GTP-C) session creation by sending the Create Session Request to the SGW. The Create Session Request contains the following parameters along with subscriber's information like MSISDN, IMEI and IMSI.

• APN : the access point name to which the GTP-C session is to be established.
• PDN Address Allocation (PAA) : UE IP address. It is empty at this moment in time as no IP address has been allocated for the UE.
• Serving Network : the MCC and MNC of the serving network which the UE is attached to.
• User Location Info: TAI, ECGI
• MME GTP-C TEID : Identifier of the MME as an end point of the GTP-C tunnel
• EPS Bearer ID (EBI) of the default EPS bearer 
• QoS Class Identifier (QCI) : ‘9’

In this case the QCI value of “9” for the default EPS bearer has been allocated as this is a PDN connection with the “internet” APN.

NOTE The UE can have up to 11 EPS bearers in total and assign the same amount of EPS Bearer Id (EBI) from 5 to 15.

NOTE The SGW will also establish the GTP-C session with the PGW on S5 interface which is not shown in this flow.

Figure 14. Create Session Request

[9] Upon receiving the Create Session Request, the PGW assigns an IP address for the UE from an IP pool. The PGW sends the Credit-Control-Request (CCR) to the PCRF indicating that this is an initial request and requests the PCC rule for the default EPS bearer. The Credit-Control-Request (CCR) contains the following parameters in this example.

• CC-Request-Type AVP: “INITIAL REQUEST”
• Subscription-Id AVP: IMSI, MSISDN
• Framed-IP-address AVP: the allocated UE IP address
• QoS-Information AVP: APN-AMBR (UL/DL)
• 3GPP-User-Location-Info AVP: TAI, ECGI
• Call-Station-Id AVP: APN (Internet)
• Default-EPS-Bearer-QoS AVP: QCI, ARP

The following snapshot shows the CCR captured on Gx interface.

Figure 15. Credit Control Request

[10] Upon receiving the CCR, the PCRF determines the PCC rule based on the received subscriber's information and responds with Credit-Control-Answer (CCA) including a PCC rule(s). When it comes to a default bearer, the PCRF may include only a PCC rule name which indicates the predefined PCC rule locally stored in the PGW. Henceforth, the PCC rule is applied to all the traffic by the PGW.

Figure 16. Credit Control Answer

[11] The SGW/PGW completes the GTP-C session creation procedure by sending the Create Session Response. The Create Session Response contains the following parameters:

• AMBR : Aggregated maximum bit rate that is allowed for this APN
• EPS Bearer ID : 5
• Protocol Configuration Options (PCO) : P-CSCF IP address, DNS IP address, etc, based on the requested configuration information by the UE in the Attach Request
• PDN Address Allocation (PAA): UE’s IP address
• SGW GTP-C TEID : Identifier of the SGW as the end point of the GTP-C tunnel
• Bearer Context: the information of the S1-U default EPS bearer to be created, which contains EBI, SGW GTP-U TEID, QCI, etc

Figure 17. Create Session Response

III. Default EPS bearer creation

Once the signaling path is successfully set up, the MME requests the eNB to activate the default EPS bearer with the SGW and the UE. The eNB establishes S1 bearer towards SGW and the Data Radio Bearer (DRB) towards the UE. The SGW will also establish the S5 bearer with the PGW, which is not shown in this flow.

Figure 18. Default EPS bearer creation flow

[12] The MME accepts the initial attach request by sending the Attach Accept and requests to activate the default EPS bearer to the UE which contains Activate default EPS bearer context request in the ESM message container. The NAS message (i.e., Attach Accept in EMM layer, Activate default EPS bearer context request in ESM layer) contains the following parameters.

• TAI list : the list of Tracking Area Identity within which the UE doesn't need to send Tracking Area Update (TAU) 
• EPS QoS : QCI (9)
• Access Point Name (APN) : Internet APN
• PDN address: the allocated UE IP address
• APN-AMBR: the maximum aggregated bit rate allowed for this APN
• Protocol Configuration Options (PCO) : DNS IP address, etc, based on the requested configuration information by the UE in the Attach Request

Figure 19. Attach Accept (Activate default EPS bearer context request)

The above NAS message is contained in the Initial Context Setup Request message on S1AP interface. Other than the NAS message, it also contains the following parameters.

• UE-AMBR : Aggregated maximum bit rates for the UE (UL/DL)
• E-RAB ID : identifier of the radio access bearer towards the eNB
• SGW GTP-U TEID : identifier of SGW as an end point of the GTP-U tunnel which was delivered in Create Session Response (step#11).

Figure 20. Initial UE Context Request

Upon receiving the Attach Accept and RRC Connection Reconfiguration, the UE establishes a DRB with the eNB and responds with RRC Connection Reconfiguration Complete to the eNB.

The eNB establishes the uplink S1-U bearer with the SGW. After successful GTP-U establishment, the eNB responds with the initial UE Context Response to the MME. In this response, the eNB contains the eNB GTP-U TEID, which will be routed to the SGW via the MME and used to identify the eNB as an end point of the GTP-U by the SGW.

NOTE The SGW GTP-U TEID is generated by the SGW and transparently routed to the eNB via the MME contained in Create Session Response and Initial Context Setup Request on S11 and S1AP, respectively. In the same way, the eNB GTP-U TEID is generated by the eNB and transparently routed to the SGW via the MME contained in the Initial Context Setup Response and Modify Bearer Request at step#14.

Figure 21. Initial UE Context Response

[13] The UE confirms the Attach Accept and informs the MME of the fact that the default EPS bearer has been activated by sending the Attach Complete, which contains the Activate Default EPS Bearer Context Accept as a response to a corresponding request.

Figure 22. Attach Complete (Activate default EPS bearer context accept)

[14] The MME sends the Modify EPS Bearer Request requesting the SGW to establish the downlink S1 bearer towards the eNB. The Modify EPS Bearer Request contains the following parameters:

• EPS Bearer ID : identifier of a default EPS bearer (5)
• eNB GTP-U TEID : identifier of the eNB as an end point of the GTP-U tunnel

Figure 23. Modify EPS bearer request

Upon receiving the Modify EPS Bearer Request, the SGW establishes the S1 bearer towards the eNB.

[15] The SGW responds with the Modify EPS Bearer Response.

Figure 24. Modify EPS bearer response

IV. PDN Connection to IMS APN

So far, the UE has performed the initial attachment procedure with the LTE network and as a result, the PDN connection has been established between the UE and the default APN, i.e., internet APN. After successful PDN connection with the default APN, if the default APN is not an IMS APN, the VoLTE UE initiates an additional PDN connection procedure with the “IMS” APN.

Figure 25. PDN connection with IMS APN flow

[16] The UE requests to establish an additional PDN connection with the IMS APN, which is typically used for VoLTE. There is no need of establishing RRC connection at this stage as it was already established at step#3. In this message, the Access Point Name (APN) is set to “IMS” and the UE may request the P-CSCF address and it is indicated by the Protocol Configuration Option (PCO) parameter. The following snapshot shows an example of PDN Connectivity Request which is contained by the uplinkNASTransport S1AP message.

Figure 26. PDN connectivity request for IMS APN

[17] Upon receiving the PDN Connectivity Request, the MME sends Create Session Request to the SGW. Refer to step #8 for overall description.

• APN : “IMS”
• MME GTP-C TEID: the same TEID that was allocated at step #8. The MME and the SGW use the same TEID for different PDNs.
• EPS Bearer ID (EBI): ‘6’ in this case as the EBI ‘5’ was already used in step#8. The EBI will be incremented along with a new EPS bearer.
• QoS Class Identifier (QCI): ‘5’ for IMS signaling.

Figure 27. Create Session Request

[18] Upon receiving the Create Session Request, the MME sends CCR to the PCRF. Refer to step #9 for overall description.

Figure 28. Credit-Control-Request

• CC-Request-Type AVP: “INITIAL REQUEST”
• Framed-IP-address AVP: The UE IP address is different from what was allocated at step #9. The UE is allocated with different IP address per PDN.
• Call-Station-Id AVP: IMS APN
• Default-EPS-Bearer-QoS AVP: In case of IMS APN, the default EPS bearer has a QCI=5.

[19] Upon receiving the CCR, the PCRF responds with CCA containing the PCC rule of the default EPS bearer for IMS APN. Refer to step #10 for overall description.

Figure 29. Credit-Control-Answer

[20] Upon receiving the CCA, the MME responds with Create Session Response containing the PCC rule of the default EPS bearer for IMS APN. Refer to step #11 for overall description.

• EPS Bearer ID: ‘6’
• Protocol Configuration Options (PCO) contains P-CSCF IP address and will be delivered to the UE.
• PDN Address Allocation (PAA): UE’s IP address and will be delivered to the UE.
• SGW GTP-C TEID: The same TEID that was allocated at step #11. The MME and the SGW use the same TEID for different PDNs.
• Bearer Context contains the SGW GTP-U TEID for the default EPS bearer which is different from what was used in step #11.

Figure 30. Create Session Response

[21] Upon receiving the Create Session Response, the MME requests to activate the default EPS bearer by sending Activate default EPS bearer context request towards the UE, which is contained in E-RAB Setup Request on S1AP interface. The E-RAB Setup Request is used to assign resources on Uu (i.e., air interface between UE and the eNB) and S1 for one or several E-RABs. The following shows parameters contained in the E-RAB Setup Request.

• UE-AMBR (UL/DL): The aggregated maximum bit rate of the UE associated with the same PDN.
• E-RAB to be setup parameters contains E-RAB ID=6 and SGW GTP-U TEID which was delivered at step #20.

The following shows parameters contained in the Activate default EPS bearer context request:

• EPS QoS QCI = 5
• Access Point Name (APN): “IMS”
• PDN address: The newly allocated UE IP address
• Protocol Configuration Options (PCO) contains the P-CSCF address which was delivered in step #20.
• APN-AMBR: aggregated maximum bit rate for the same APN.

Figure 31. E-RAB Setup Request (Activate default EPS bearer context request)

The eNB delivers the Activate default EPS bearer context request transparently to the UE, which is contained in RRC Connection Reconfiguration. Refer to step #12 for UE behavior after receiving RRC Connection Reconfiguration.

[22] ] The UE informs the MME of the fact that the default EPS bearer has been activated by sending the Activate Default EPS Bearer Context Accept as a response to a corresponding request.

Figure 32. Activate default EPS bearer context request

Figure 33. EPS bearer creation flow

[23] The MME sends the Modify Bearer Request requesting the SGW to establish the downlink S1 bearer towards the eNB. Refer to step #14 for overall description. The message contains eNB GTP-U TEID that shall be used by the SGW to identity the end point of the GTP-U of default EPS bearer.

Figure 34. Modify Bearer Request

[24] Upon receiving the Modify Bearer Request, the SGW establishes a downlink S1 bearer and responds with Modify Bearer Response.

Figure 35. Modify Bearer Response

Consequently, the default EPS bearer with QCI value of ‘5’ between the UE and the IMS APN is established. Hereafter all the SIP traffic goes through the default EPS bearer.

Red Mouse 

REFERENCES

[1] 3GPP TS25.331, "Radio Resource Control (RRC); protocol specification", v12.3.0, Sep 2014

[2] 3GPP TS24.301, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); stage3", v12.4.0, Mar 2014

[3] 3GPP TS36.413, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); stage3", v12.4.0, Mar 2014

[4] Red Mouse, "Tracking Area Update and Combined Attach", Jul, 2015

[5] Red Mouse, "Understanding of GTP TEID to use it in LTE troubleshooting", Jun, 2015

[6] Netmanias, "LTE Security II: NAS and AS security", Aug 5th 2013

[7] Netmanias, "LTE IP Address Allocation Schemes I: Basic", Feb 13th 2015

Last Update: Dec 30th 2015