IMS Dedicated bearers

Email exchange! Hope it helps!

-------------------------------------------------------------------------------------------------------------------------------------

My understanding of VoLTE bearers:

• A default bearer is automatically created as part of UE attach (This is UE-initiated IP-CAN session initiation). 
• It is possible to also include a dedicated bearer for signalling on UE attach but this is not compulsory (This is UE-initiated IP-CAN session modification).  
• A UE initiates an IMS session by sending a SIP INVITE message and IMS elements (typically the P-CSCF) triggers the activation of the dedicated bearer for the session via Rx/PCRF/Gx/PGW.  
• Similarly when a session is terminated the UE sends a SIP BYE message and the P-CSCF triggers removal of the dedicated bearer via Rx/PCRF/Gx/PGW.  (This is network initiated IP-CAN session modification for the VoLTE dedicated media bearer.)

The problem I see with this is the following scenario

• UE terminate an IMS call and sends a SIP BYE.  Typically the dedicated bearer is removed through Rx/PCRF/Gx.  BUT if the SIP BYE is lost in the network, the dedicated bearer remains and the user is still charged even though the call is "ended".

I think it is also possible to use UE initiated IP-CAN session modification for the IMS dedicated media bearer (I had a look at 4.5.1 Request for PCC rules in 3GPP TS 29.212 where it talks about IP-CAN session modification initiated by UE) - and I think it should work as follows:

• UE sends SIP INVITE and initiates dedicated bearer activation which goes PGW/Gx/PCRF.
• With SIP preconditions full IMS signalling only takes place once both sides have completed UE initiated dedicated bearer activation.  (Rx is still used but differently .. not 100% sure how)
• When the UE terminates the call it sends a SIP BYE message and activates the removal of the dedicated bearer.
• If a SIP BYE message is lost the dedicated bearer is still removed, the PCRF is informed, and in turn the IMS elements are informed via Rx.  The session will be fully torn down and charging will be stopped.

 -------------------------------------------------------------------------------------------------------------------------------------
- Have you explored anything in IMS that can provide a solution to lost SIP Bye?
- Is it a really good idea to rely on UE to establish/teardown the SIP signalling? How do you plan to interop with tons of UEs that will available in market soon.
- To me the solution should be driven from the network, based on the UE subscription. You can establish a non GBR dedicated bearer when UE is initially attached to the network for the purpose of SIP signaling, that can just stay there as long as UE is attached. QCI - 1 is designated for this. This will be inline with further SRVCC procedure.
- If dedicated bearer creation and deletion needs to be triggered by Rx, then I am afraid there is no trivial solution to deal with lost SIP Bye, unless IMS presents us with one.

-------------------------------------------------------------------------------------------------------------------------------------

If the signalling bearer is QCI 5 then the packet loss error rate is 10^-6.  This means that 1 in 1000 000  packets are lost.  So if the BYE is lost it seems likely that the signalling bearer will be torn down.  It is possible on IMS registration to register for notifications on the status of the signalling bearer - if the signalling bearer is lost then all media bearers are removed (no more charging) and the user is unregistered.

So maybe this is not a problem after all?

-------------------------------------------------------------------------------------------------------------------------------------

Regarding the QCI: From my understanding - the network will detect if the QCI guarantees for a bearer can no longer be met (i.e. if the signalling bearer - QCI 5 - can no longer receive loss rate of 10^-6).
 If this is detected the bearer will be torn down - PCRF informed etc.  Though I've yet to see this demonstrated I am pretty sure this capability exists in standard EPC.  So I think my original concern is
actually not a problem at all - what do you think?

LTE: QoS (Part 2)

In the last post we understood TFT and QoS behavior in LTE. What's important to understand is bearers are all about achieving QoS. The whole concept of bearers is just to provide proper quality of service to user thus enhancing the quality of experience. So what we know at this point is a default bearer always exists once the UE is switched ON, until it is powered off. Any other bearer is a dedicated bearer which is associated with a TFT and QoS.

In this post lets try to understand few more terms like TAD and QCI (QoS Class Identifier). The concentration is on UE requested bearer creation/modification procedure.

Basically a UE may request for dedicated bearer. Lets say we are running a web browser on our mobile phone. Now UE wants to establish a dedicated bearer for that. So UE sends out a request for bearer creation procedure. MME here sends sends out a bearer resource command which includes LBI (Linked Bearer ID), PTI (Procedure Transaction ID), TAD (Traffic Aggregate Descriptor), QoS.

TAD is a partial TFT. It includes packet filters for a particular L7 activity. In our case as we are running HTTP, TAD will include packet filter for HTTP. Now MME will send this information to PGW. Now PGW understands that a dedicated bearer has to be created for running HTTP traffic. So it sends out a create bearer request with TFT (HTTP) and QoS. Here UE may request for particular QoS.

Lets look at QCI here. QCI field may be mapped to a diff serv. (Assured Forwarding?) . Say QCI value is set to 2 which indicates a particular class of assured forwarding, say AF12. We have MBR and GBR values in QoS which may be set to some value.

Once MME requests create bearer request it responds with a bearer response creating a dedicated bearer for HTTP activity with a QoS value (QCI: AF12). After this our mobiles should start displaying the web pages with a speed equal to Roger Federer's ace. :)

Now, you remember that your boss has asked something and you want to email him. So another dedicated bearer for this email? Ok... lets stop and understand this a bit clearly. If your http dedicated bearer QoS is fine for running email then we may just use it. But you need to indicate this to PGW. So we do a bearer modification (update?) procedure instead of bearer creation. MME here will send bearer resource command with TAD mapped to email traffic, say IMAP(?). But note here the QoS is same. (QCI still is AF12). PGW looks at this and thinks that may be I should update the dedicated bearer to include IMAP too. So it sends out Update bearer request with newly added TFT for IMAP. (We already have TFT for HTTP). MME responds to saying OK.

At this point we have two activities running on single dedicated bearer. That means when there is no QoS change a single bearer may be used to run various traffics. This brings us to square one where I said bearer is all about QoS. Once email is done, PGW may remove that TFT (IMAP) from dedicated bearer.

This was just a short post to look at things when no QoS is changed. I will try to analyze the whole QoS with various IE's in coming days.

I hope it was useful and as usual comments are greatly welcomed.

LTE : Tunnel Identifiers (GTPv2)

From my LTE mind map in the last post, understanding bearers is the most important thing. I must agree with one my readers who pointed out that "MindMap" looks horrific and ugly. I know. I am very bad with sketches and that was the main reason for me to drop off from choosing medical sciences. :) Rest apart, lets get going.

First step in understanding bearers is tunnels. How are tunnels identified? I want to elaborate this post with complete LTE call flow where two activities are running on mobile phone, one is using default bearer and other is using dedicated bearer.

The trick is not to understand the whole message in single gulp. Divide the message into IE's and take up the activity of each IE separately. Note that we are only dealing with mandatory and conditional IE's here. The concentration is on TEID and FTEID fields.

The above call flow is self explanatory and is pretty simple. We see two fields TEID and FTEID. TEID is the field present in the GTP-C header and using which the tunnel is identified. FTEID is Fully Qualified Tunnel End Point Identifier. This IE is used to send TEID/GRE Key and IP info of sending entity.

Create Session Request is always sent with TEID value set to zero. There are bunch of other messages where TEID value is set to zero and sent. Refer to spec for details. The S-FTEID is senders FTEID. MME sends this field with a TEID value say 0x111 and IP address of it to S-GW.

Once S-GW receives this message it learns the IP address of MME and TEID field to be used in the response. S-GW creates create session Response message with TEID value 0x111 and S-FTEID. S-FTEID value here contains the TEID value,say 0x222, to be used by MME and IP address of the S-GW.

At this stage the control plane for communication between MME and SGW is set. MME uses TEID: 0x222 for sending any control plane info to S-GW and S-GW uses TEID 0x111 to send any control plane info to MME.

Once the control plane is set traffic has to flow. Modify Bearer Request is used to indicate the S1-U interface of eNB. So S-FTEID (S1-U eNB FTEID) value is set to say 0x0a + IP address and sent to S-GW. S-GW replies with its S1-U interface FTEID. At this stage the TEID for the user plane are set. User plane traffic will flow using the TEID's exchanged. Thus the traffic flows on default bearer.

Bearer Resource Command is used by MME to request for a dedicated bearer. Once S-GW receives bearer resource command it initiates a Create Bearer request. Observe that same TEID field is used which was negotiated earlier. In create bearer request S-GW includes S1-U SGW F-TEID for user plane traffic.

MME sends a Create Bearer Response message with the S1-U eNB FTEID. At this point the a dedicated bearer is created and user plane traffic tunnel is negotiated. Dedicated bearer user plane traffic flows using the TEID's exchanged.

The interface described above is S11. This interface is mapped to S5/S8 and S1-MME interfaces. TEID are used to identify and map the tunnels in various interfaces.

There have been significant changes in the messages from Dec spec to March spec. The above details are with respect to March spec (3GPP 29.274 v8.1.1). I hope I got them correct. Else please correct me.

In next posts I want to look at the EBI fields and QoS. Comments are greatly welcomed.

UE initiated Bearer Resource Modification : a.k.a Dedicated Bearer

Source : 3GPP TS 23.401 : Clause : 5.4.5 and 3GPP TS 29.274 Clause : 7.2.5

Some time back I wrote about Dedicated Bearer establishment in LTE. i was still under confusion about how dedicated bearers are established and how different are they from secondary PDP context. I closed that post with an open question can MME initiate a dedicated bearer. After much reading and lot of questions which readers asked me, I understand the behavior of Dedicated bearers to certain extent now. In this post I want to concentrate on UE requested Dedicated bearers, just like secondary PDP contexts yet so different. In GTP v1 UE initiates the secondary PDP context with a new TFT, but in LTE UE starts with Bearer Resource Modification procedure. (3GPP TS 29.274 Clause : 7.2.5)

Bearer resource modification procedure can do more, but lets just consider that we are trying to get a dedicated bearer established.

The UE sends a Request Bearer Resource Modification (LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options) message to the MME.

TAD : Traffic Aggregate Description indicate add packet filters operation. EPS Bearer Identity may not be sent here. Linked Bearer Identity is sent to indicate to which PDN connection additional bearer resource is linked to. PTI is dynamically allocated by UE.

The MME sends the Request Bearer Resource Modification (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options) message to the selected Serving GW. The MME validates the request using the Linked Bearer Id

The Serving GW sends the Request Bearer Resource Modification (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol Configuration Options) message to the PDN GW

If requested is accepted then dedicated bearer establishment is invoked. The PTI allocated by the UE is used as a parameter in the invoked Dedicated Bearer Activation Procedure to correlate it to the UE Requested Bearer Resource Modification Procedure. This provides the UE with the necessary linkage to what EPS Bearer to be used for the new traffic flow aggregate. The PDN GW shall not modify the QoS parameters requested by the UE  

Now go back to the dedicated bearer establishment post.

This takes one more step towards understanding bearers better. As usual comments are welcome.