Its been quite a while since I posted about QCI and end-to-end bearer QoS in EPC. In LTE Release-12 some new QCI values were added to handle mission critical communications.
This picture is taken from a new blog called Public Safety LTE. I have discussed about the Default and Dedicated bearers in an earlier post here (see comments in that post too). You will notice in the picture above that new QCI values 65, 66, 69 & 70 have been added. For mission critical group communications new default bearer 69 would be used for signalling and dedicated bearer 65 will be used for data. Mission critical data would also benefit by using QCI 70.
LTE for Public Safety that was published last year provides a good insight on this topic as follows:
The EPS provides IP connectivity between a UE and a packet data network external to the PLMN. This is referred to as PDN connectivity service. An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment. It is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. All traffic mapped to the same EPS bearer receives the same bearer level packet forwarding treatment. Providing different bearer level packet forwarding treatment requires separate EPS bearers.
An EPS bearer is referred to as a GBR bearer, if dedicated network resources related to a Guaranteed Bit Rate (GBR) are permanently allocated once the bearer is established or modified. Otherwise, an EPS bearer is referred to as a non-GBR bearer.
Each EPS bearer is associated with a QoS profile including the following data:
• QoS Class Identifier (QCI): A scalar pointing in the P-GW and eNodeB to node-specific parameters that control the bearer level packet forwarding treatment in this node.
• Allocation and Retention Priority (ARP): Contains information about the priority level, the pre-emption capability, and the pre-emption vulnerability. The primary purpose of the ARP is to decide whether a bearer establishment or modification request can be accepted or needs to be rejected due to resource limitations.
• GBR: The bit rate that can be expected to be provided by a GBR bearer.
• Maximum Bit Rate (MBR): Limits the bit rate that can be expected to be provided by a GBR bearer.
Following QoS parameters are applied to an aggregated set of EPS bearers and are part of user’s subscription data:
• APN Aggregate Maximum Bit Rate (APN-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers and across all PDN connections associated with the APN.
• UE Aggregate Maximum Bit Rate (UE-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers of a UE. The UE routes uplink packets to the different EPS bearers based on uplink packet filters assigned to the bearers while the P-GW routes downlink packets to the different EPS bearers based on downlink packet filters assigned to the bearers in the PDN connection.
Figure 1.5 above shows the nodes where QoS parameters are enforced in the EPS system.
Related links:
This picture is taken from a new blog called Public Safety LTE. I have discussed about the Default and Dedicated bearers in an earlier post here (see comments in that post too). You will notice in the picture above that new QCI values 65, 66, 69 & 70 have been added. For mission critical group communications new default bearer 69 would be used for signalling and dedicated bearer 65 will be used for data. Mission critical data would also benefit by using QCI 70.
LTE for Public Safety that was published last year provides a good insight on this topic as follows:
The EPS provides IP connectivity between a UE and a packet data network external to the PLMN. This is referred to as PDN connectivity service. An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment. It is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. All traffic mapped to the same EPS bearer receives the same bearer level packet forwarding treatment. Providing different bearer level packet forwarding treatment requires separate EPS bearers.
An EPS bearer is referred to as a GBR bearer, if dedicated network resources related to a Guaranteed Bit Rate (GBR) are permanently allocated once the bearer is established or modified. Otherwise, an EPS bearer is referred to as a non-GBR bearer.
Each EPS bearer is associated with a QoS profile including the following data:
• QoS Class Identifier (QCI): A scalar pointing in the P-GW and eNodeB to node-specific parameters that control the bearer level packet forwarding treatment in this node.
• Allocation and Retention Priority (ARP): Contains information about the priority level, the pre-emption capability, and the pre-emption vulnerability. The primary purpose of the ARP is to decide whether a bearer establishment or modification request can be accepted or needs to be rejected due to resource limitations.
• GBR: The bit rate that can be expected to be provided by a GBR bearer.
• Maximum Bit Rate (MBR): Limits the bit rate that can be expected to be provided by a GBR bearer.
Following QoS parameters are applied to an aggregated set of EPS bearers and are part of user’s subscription data:
• APN Aggregate Maximum Bit Rate (APN-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers and across all PDN connections associated with the APN.
• UE Aggregate Maximum Bit Rate (UE-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers of a UE. The UE routes uplink packets to the different EPS bearers based on uplink packet filters assigned to the bearers while the P-GW routes downlink packets to the different EPS bearers based on downlink packet filters assigned to the bearers in the PDN connection.
Figure 1.5 above shows the nodes where QoS parameters are enforced in the EPS system.
Related links:
- LTE QoS and prioritization for mission critical communication
- LTE QCI and End-to-end bearer QoS in EPC
- VoLTE Bearers
- New book by Nokia experts on LTE for Public Safety a must read
11 comments:
Thanks for valuable update . Just wondering why still packet delay budget of real time gaming is kept smaller (50msec) as compared to packet delay budget of Mission critical signalling (60msec) , shouldn't later one be smallest ?
Thats because one is GBR and other is non-GBR. 60ms is good enough in mission critical scenarios. Real time gaming on the other hand has strict requirements and would only be allowed when the network is not overloaded.
Great post & great to see you are now focused on mission-critical applications. This is one of the most important parts of R12 for public safety as we move from stable 2G networks to more challenging, data-rich, open, shared - and therefore potentially more vulnerable - broadband networks. Do you see mobile operators actually deploying this in their networks & do you therefore see it as a precursor to a new paradigm of QoS & priority/preemption in next-gen networks, or is it simply too complex to ever be implemented? It also seems to challenge network neutrality, but as a public safety advocate, that's OK for me!
Peter, not all operators will implement public safety related enhancements in their network. It will always be some government policies, regulatory pressures or commercial arrangements/agreement that will make any operator go on this path. Once an operator starts implementing public safety enhancements, they will have to implement these changes.
As we move towards 5G, will these features in R12/R13 make it easier to also handle critical IoT/M2M?
I think these changes will not impact or be impacted by 5G developments. Critical IoT/M2M is more about taking immediate action in case of anything goes wrong. In a way, it could be tied with Mission Critical communications but it could also be left separate. I am sure there are others who are better qualified to comment.
Thanks for the comments. It will be interesting to see if operators start to promote their networks as "public-safety-ready" to highlight the increased security & resilience of their networks, or if they prefer to keep quiet because they are afraid that their commercial customers will be nervous about being bumped off the network when a major incident occurs!
Even with new QCI support there are quite a few challenges to provide public safety networks.
Can you please give an example of what a mission critical delay sensitive signal would be (QCI 69)? How is this different from mission critical data (QCI 70)?
I don't know if it makes much sense to add an answer after a year, but still ... Mission critical signaling could be used e.g. to set up a Push-to-talk (PTT) or Push-to-video (PTV) session but the media transferred using these sessions could be prioritized based on the mission critical data settings. (On Rx interface between AS and PCRF settings are distinguished by media type: control/audio/video.)
What is the likely the cause for an distorted audio with SIP signalling on QCI 5 and RTP in QC1. From the log, we found there is a delay packets and occasionally, there is jitter. The app has a 120mesec jitter buffer cater for the delay. We are not using EVS codec as well
Not sure is the distorted audio is due to we did not set voice to QC65.
Any advise on whether changing the RTP to QC65 help?
Post a Comment