Saturday, June 2, 2012

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?