Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
Core Network Evolution - How CUPS changes the Call Flow?
April 02, 2018 | By Karim Rabie @ Saudi Telecom Company
Online viewer:
Comments (3)
12
SUMMARY
Control and User Plane Separation of EPC nodes (CUPS) is one of the main Work Items of 3GPP Release 14. An Architectural enhancement feature that introduces the concept of separation between Control Plane and User Plane of EPC nodes (SGW, PGW, & TDF) following the architecture below. Opposite to the expectations of having the new interfaces (Sxa, Sxb) based on GTP; the new reference points introduced a new protocol (PFCP - Packet Forwarding Control Plane).
 

Karim Rabie

Senior PS Core / EPC Consultant at Saudi Telecom Company

 

 

All Articles by Karim Rabie

 
     
  How to contribute your article to Netmanias.com !  
     
  List of Contributors  

 

 

     

  Table of Contents  

   1. E-UTRAN Attach Procedure

   2. SGW-U/PGW-U Selection Criteria

   3. References

 

Control and User Plane Separation of EPC nodes (CUPS) is one of the main Work Items of 3GPP Release 14. An Architectural enhancement feature that introduces the concept of separation between Control Plane and User Plane of EPC nodes (SGW, PGW, & TDF) following the architecture below.

 


Opposite to the expectations of having the new interfaces (Sxa, Sxb) based on GTP; the new reference points introduced a new protocol (PFCP - Packet Forwarding Control Plane).

 

In this article, I am covering two CUPS technical bullets that - together with the last article - may cover the main CUPS technical aspects.

1. How CUPS changes Call Flows.
2. The Selection Criteria for SGW-U and PGW-U.

 

 

E-UTRAN Attach Procedure

 

To keep the call flow simple and organized, I am cutting the flow into 5 parts with a simple description for every message flow and I am also highlighting the CUPS added messages in red. I will also make use of the call flow to explain the Sx Session Establishment procedure.

 


Steps from 1 to 8 are the same following the standard EUTRAN Attach Call Flow (3GPP TS 23.401) so I am just providing a summary below.

 

1- The UE initiates the Attach procedure by the transmission, to the eNodeB, of an EMM message - Attach Request - with an ESM message Container (piggybacked) that carries PDN Connectivity Request.

 

2- If the UE identifies itself with GUTI and the MME has changed since detach, the new MME uses the GUTI received from the UE to derive the old MME/SGSN address and send an Identification Request (old GUTI, complete Attach Request message) to the old MME/SGSN to request the IMSI. The old MME first verifies the Attach Request message by NAS MAC and then responds with Identification Response (IMSI, MM Context). 

 

3- If the UE is unknown in both the old MME/SGSN and new MME, the new MME sends an Identity Request to the UE to request the IMSI. The UE responds with Identity Response (IMSI). 

 

4- MME shall send The authentication data request shall include the IMSI, the Serving Network identity i.e. MCC + MNC, and the Network Type (i.e. E-UTRAN). Upon the receipt of the authentication data request from the MME, the HSS may have pre-computed the required number of EPS authentication vectors (RAND, Kasme, XRES, AUTN) and retrieve them from the HSS database or may compute them on demand and send the requested info to MME.

 

5- The MME sends to the USIM via ME the random challenge RAND and an authentication token AUTN for network authentication from the selected authentication vector. Upon receipt of this message, the USIM shall verify the freshness of the authentication vector by checking whether AUTN can be accepted as described in TS 33.102[4]. If so, the USIM computes a response RES. 

 

6- The MME sends an Update Location Request (MME Identity, IMSI, ME Identity (IMEISV), MME Capabilities, ULR-Flags, Homogeneous Support of IMS Over PS Sessions) message to the HSS. 

 

7- The HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME. The old MME acknowledges with Cancel Location Ack (IMSI) and removes the MM and bearer contexts. 

 

8- The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription data) message to the new MME. 

 


9- The new MME selects a Serving GW as described in 3GPP TS 23.401 clause 4.3.8.2 on Serving GW selection function and allocates an EPS Bearer Identity for the Default Bearer associated with the UE.

 

10- MME sends a Create Session Request to SGW. The message includes the PDN GW Address selected by MME.

 

11- At this point, SGW-C selects the SGW-U that will be the Tunnel endpoint for eNB/S1-U and PGW/S5 interfaces. SGW-U Selection Criteria is described later in this article.

 

12a- SGW-C sends Session Establishment Request message to the selected SGW-U for creating a Sx session for the UE/PDN Connection. 

 

The CP function assigns a new Session ID and provides it to the UP function. The Session ID is stored by both entities and used to identify the Sx session context during their interaction. The CP function stores also the relation between the Session ID and PDN connection in unsolicited reporting mode and can then correlate events reported by the UP function to them. 

 

The Sx Session Establishment Request message is a very rich message that includes a set of Identifiers together with composite Information Elements/Rules such PDR (Packet Detection Rule), FAR (Forwarding Action Rule), URR (Usage Reporting Rule), QER (QoS Enhancement Rule), and BAR (Buffering Action Rule)which instruct and dictate the UP Function how to behave.

 

12b- The UP function responds with Sx session establishment response message with a "Cause" that shows with the acceptance or the rejection. SGW-UP will send the created PDR associated to the Sx Session in case of Success

 


13- The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request message to the PDN GW indicated by the PDN GW address received in the previous step.

 

14- If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW performs an IP-CAN Session Establishment procedure and thereby obtains the default PCC rules for the UE. 

 

15a- The PGW-C shall select new PGW-U. PGW-U Selection Criteria is described later in this article. If the network is configured to perform F- TEIDu allocation in the CP function then PGW-C allocates F-TEIDu for the default bearer. Then the PGW-C sends a Sx Session Establishment Request to the selected PGW-U for creating a Sx session for the UE. The PGW-C shall include the F-TEIDu of the default bearer received from the SGW. The F-TEIDu for the default bearer shall be included if the PGW-C has allocated the same. 

 

15b- If the network is configured to perform F-TEIDu allocation in the UP function, the PGW-U allocates F- TEIDu for the bearer. The PGW-U sends a Sx Session Establishment Response to the PGW-C confirming the successful creation of the Sx session. It shall include the F-TEIDu for the bearer if it has allocated the same. 

 

16- The PDN GW returns a Create Session Response message to the Serving GW that includes (PDN GW Address for the user plane, PDN GW TEID of the u ser plane, PDN GW TEID of the control plane, PD N Type, PD N Address, EPS Bearer Identity, .....).

 

17a- In this step, SGW-C instructs SGW-U with the TEID of the PGW-U received via SGW-C. For that, The SGW-C sends Session Modification Request to the SGW-U. The SGW-C shall include the F-TEIDu of the default bearer received from the PGW. 

 

17b- The SGW-U sends a Sx Session Modification Response to the SGW-C confirming the success of the Sx session modification. 

 


18- The Serving GW returns a Create Session Response message to the new MME. 

 

19- The new MME sends an Attach Accept message to the eNodeB. This message is contained in an S1_MME control message Initial Context Setup Request.

 

20- The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to the UE, and the Attach Accept message will be sent along to the UE.

 

21- The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB. For further details, see TS 36.331.

 

22- The eNodeB sends the Initial Context Response message to the new MME. This Initial Context Response message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference point.

 

23- The UE sends a Direct Transfer message to the eNodeB/MME, which includes the Attach Complete (EPS Bearer Identity, NAS sequence number, NAS-MAC) message.

 


24- The new MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, Handover Indication) message to the Serving GW. 

 

25a- In this step, SGW-C updates SGW-U with the TEID of the eNB-S1U received via MME/eNB. The SGW-C sends a Sx Session Modification Request to the SGW-U. The SGW-C shall include the F- TEIDu of the default bearer received from the eNodeB. 

 

25b- The SGW-U sends a Sx Session Modification Response to the SGW-C confirming the success of the Sx session modification. 

 

26- If the Handover Indication is included in step 24, SGW-C sends a Modify Bearer Request (Handover Indication) message to the PGW-C to prompt the PGW-C to tunnel packets from non-3GPP access to 3GPP access system and immediately start routing packets to SGW-C for the default and any dedicated EPS bearers established. 

 

27a- If the Handover Indication is included in step 26, the PGW-C updates the old PGW-U session corresponding to the non-3GPP access by sending "Sx session modification request" message to the PGW-U (session ID) and instructs the PGW-U to start routing the downlink packets to the SGW/SGW-U. 

 

27b- The PGW-U sends "Sx session modification response" message to the PGW-C. 

 

28- The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.

 

29- The Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity) message to the new MME. The Serving GW can then send its buffered downlink packets.

 

30- After the MME receives Modify Bearer Response (EPS Bearer Identity) message, if Request Type does not indicate handover and an EPS bearer was established and the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, and if the MME selected a PDN GW that is different from the PDN GW identity which was indicated by the HSS in the PDN subscription context, the MME shall send a Notify Request including the APN and PDN GW identity to the HSS for mobility with non-3GPP accesses. The message shall include information that identifies the PLMN in which the PDN GW is located. 

 

31- The HSS stores the APN and PDN GW identity pair and sends a Notify Response to the MME. 

 

Note - I believe that this is the right time for

MBB professionals to start studying the PFCP protocol

with the same interest that the community

always showed for GTP.

 


SGW-U/PGW-U Selection Criteria

 

CUPS is bringing some interesting Selection features for both SGW-U and PGW-U selection with a flexibility that was missed in Pre-R14 EPC and I believe that the richness of these features will be one of the main differentiators between Vendors' solutions.

 

SGW-U is selected by SGW-C following the below scenarios.

  1. Close to UE; Based on SGW-U Location and the UE Location info sent in the Create Session Request message from MME to SGW.
  2. SGW-U Dynamic Load which can be reported by SGW-U to SGW-C.
  3. SGW-U Relative Static Capacity.
  4. Based on the Functionalities, Features, & capabilities that UE requires/declares together with the info that MME enriches in the Create Session Request to SGW-C. In this scenario, SGW-C can build a logic on the info communicated from UE/MME to SGW. An example of this parameters are
  • CIoT capabilities - Select SGW-U for NB-IoT Terminals
  • UE Usage Type - Select SGW-U for certain Usage Types (e.g. Smart Meter)
  • APN (for selection of combined SGW/PGW) - with CUPS, SGW-U can be selected for a certain APN/PDN - Great news!

On the other, PGW-U is selected by PGW-C following the below options.

  1. PGW-U dynamic load, either on node level or APN level.
  2. PGW-U relative static capacity (among PGW-Us supporting the same APN).
  3. The PGW-U location configured in the PGW-C and the UE location information provided by the MME.
  4. Based on the Functionalities, Features, & capabilities that UE requires/declares together with the info that MME enriches in the Create Session Request to SGW-C/ PGW-C (e.g. APN, mapped UE Usage Type, UE location information) or from the PCRF (e.g. need to perform DPI) with the capabilities of the UP function so as to fulfill the service for the UE, e.g. if L7 based traffic detection is needed then a certain PGW-U supporting corresponding functionality needs to be selected. 

I end this article with optimistic expectations for CUPS as I see that PoCs based on PFCP have already started with expected commercial deployments in 2018 and that actually opens the door to positioning the User Plane function in edge DCs and making the first steps towards MEC, Multi-access Edge Computing.

 

Thanks and waiting for your insights.

 

 

References

  • 3GPP TS 23.214 Architecture enhancements for control and user plane separation of EPC nodes; Stage 2 - R14.
  • 3GPP TS 29.244 Interface between the Control Plane and the User Plane of EPC Nodes; Stage 3 - R14.
  • 3GPP TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access - R14.
  • 3GPP TR 29.844 Study on Control and User Plane Separation of EPC Nodes - R14. 
onlyashu19 2018-04-03 15:35:29

Thanks for explaining in detail.......quite an effort !!

kangqiao 2018-04-03 18:24:52

Thanks

Abhishek @ Cisco via LinkedIn 2018-04-16 14:00:40

CUPS gives an opportunity to the operator to write policies that were not possible in non-SDN cases.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
08/16/2018
Netmanias Blog
08/01/2018
Netmanias Technical Documents
08/28/2017
Netmanias Blog
08/22/2014
Netmanias Technical Documents
06/11/2014
Netmanias Technical Documents
05/07/2014
Netmanias Technical Documents
04/23/2014
Netmanias Technical Documents
04/08/2014
Netmanias Technical Documents
View All (171)
5G (6) Backbone (2) Backhaul (3) Blockchain (1) CDN (1) Carrier Ethernet (3) Charging (1) DHCP (4) ECM (2) EMM (16) EPS (2) Google (1) HLS (1) HTTP Adaptive Streaming (3) Handover (5) IPTV (4) Initial Attach (2) IoT (2) Korea (1) LTE (39) LTE Identification (2) LTE-A (1) MPLS (2) Mobility (2) NAT (7) Netflix (1) Network Architecture (3) Network Protocol (20) New Radio (1) OTT (1) PCRF (3) QoS (3) RCS (3) SDF (2) SDN/NFV (2) SK Telecom (1) Samsung (2) Security (5) Sk Telecom (1) Transparent Cache (1) Video Streaming (4) VoLTE (2) Wi-Fi (1) YouTube (2)
Password confirmation
Please enter your registered comment password.
Password