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        
Dedicated Bearer setup in LTE and impact on VoLTE Precondition
March 29, 2017 | By Arindam Ghosh @ Qualcomm
Online viewer:
Comments (2)
14

We are pleased to share with you all an interesting article contributed by Arindam Ghosh who is VoLTE/IMS solution development, enhancement and optimization engineer at Qualcomm SoCs.

 
 
Arindam Ghosh

VoLTE/IMS Engineer at Qualcomm

 

 

All Articles by Arindam Ghosh

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

 

 
     
 

When the callee has been alerted by the provisional response, the chances of a session establishment failure are minimum assuming network resources are available. So in this case network reservation is the most important and mandatory task.

 

So precondition can be defined as a network resource reservation acknowledgement procedure by which the both termination user can establish a specific QCI before going to the ringing state. Depending upon the presence of the SDP in initial INVITE request, desired and local network reservation condition there are several call flows but now we will only consider  the primary one.

 

Suppose UE-A and UE-B are two precondition enabled VoLTE client and want to establish a media session between them. Consider UE-A is the initiator of the session.

 

 

1. INVITE

UE-A starts the session by sending INVITE request(SDP offer) to user B. Within the INVITE request UE-A indicates its capability for precondition by adding precondition supported header.

 

2. 183/INVITE

Upon receiving the INVITE request as UE-B is precondition capable, so it sends 183 Session Progress message with precondition required header and start exchanging the required qos parameters.

 

UE Initiated Dedicate Bearer Setup Request :

 

 

After sending this 183 Session In Progress UE-B starts reserving the network resources required for this session by sending BEARER RESOURCE ALLOCATION REQUEST to MME. This message contains QoS class indicator, guaranteed and maximum bit rates for the uplink and downlink, TFT of UE-A. MME sends this towards S-GW as GTP-C BEARER RESOURCE COMMAND. Now PCEF sends CC-Request to PCRF. PCRF is responsible for checking the subscription status from SPR. Now PCRF invoke RE-AUTH-REQUEST request to AF. RE-AUTH-ANSWER contains corresponding QoS and charging parameters and PCRF sends these information within CC-ANSWER to PCEF so that it can establish dedicated bearer. This procedure is called UE initiated dedicated bearer setup.

 

Network Initiated Dedicate Bearer Setup Request :

 

 

Similarly after receiving the 183 response by serving P-CSCF of UE-A sends Diameter AA-Request to PCRF indicating mobile using its IP address, and describes the requested media using parameters such as the media type, codec and port number, and the maximum uplink and downlink data rates. PCRF is responsible for fetching all required subscriber information from SPR and provide the AA-Answer to AF. Then PCRF defines new PCC rule and sends Re-Auth-Request to PCEF so that it can establish dedicated bearer. This procedure is called network initiated dedicated bearer setup.

 

Dedicated Bearer Setup:

 

 

After receiving the new PCC rules from PCRF P-GW sends QoS parameters, uplink TEI and uplink TFT for the UE using CREATE DEDICATED BEARER REQUEST. S-GW forwards this to MME. Now MME creates ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST with the information received from S-GW and embed within S1-AP E-RAB SETUP REQUEST and forwards to eNB.  

      

After receiving this request from MME, eNB sends RRC CONNECTION RECONFIGURATION MESSAGE to the UE, which specify the information received from MME along with the new radio bearer configuration data. The mobile configures the bearer as instructed and acknowledges with RRC CONNECTION RECONFIGURATION COMPLETE to eNB. Now eNB acknowledge with E-RAB SETUP RESPONSE.

 

3. PRACK

In parallel of the bearer setup procedure, if 183/INVITE contains ‘Require: 100rel’ UE-A issue PRACK to acknowledge that it received the provisional response containing the SDP body(as well as QOS parameters).Sometimes this PRACK request can also carry the SDP offer but now we will not consider that flow.

 

4. 200/PRACK

Response of PRACK from UE-B. Sometimes this PRACK request can also carry the SDP answer but now we will not consider that flow.

 

5. UPDATE

After the resource reservation on the UE-A side, VoLTE client invoke the UPDATE request to acknowledge that required resource reservation is complete and specify this within the SDP message body.

6. 200/UPDATE

Now after receiving the UPDATE by UE-B, if resource reservation is complete in MT side then it acknowledge its status within the 200 OK response.

7. 180 Ringing

Now after sending the 200OK/UPDATE response if resource reservation status matches then UE-B sends 180.

 

8. PRACK

If 180 response contains 100rel then UE-A acknowledge with PRACK request.

 

9. 200/PRACK

Response of PRACK from UE-B.

 

10. 200/INVITE

Now if user accept the call, UE-B sends the 200 Ok response of INVITE. As the SDP negotiation is already complete so this 200OK does not contain the SDP body.

 

11. ACK

In response of 200OK/INVITE caller acknowledged with ACK.

 

Ref: RFC 3312, 3gpp 24.229, RFC 4032

 
     
Sam 2018-10-29 16:43:05

Please I need your advice as we changed the normal atributes that we were using for the default bearer "QCI, GBR and MBR" as well from the HSS side and it's assumed that the parameters is clearly configured from the MME side. However, we are facing "attach rejection" issue for the dial used for this test scenario, soo what we need to know is what could be the route cause for this issue and how it can be solved.

Sinniah RK Kumar 2018-11-14 22:55:14

Very good call flow explanation. Thank you for sharing.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (799)
4.5G (1) 5G (82) AI (6) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) Big Data (2) Blockchain (3) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (54) KT (41) Korea (19) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (3) MPLS (1) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (20) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) QoS (3) RCS (4) Roaming (1) SD-WAN (15) SDN/NFV (66) SIM (1) SK Broadband (2) SK Telecom (33) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (29) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password