LTE End-to-End QOS Q&A
A special thanks to all of you who joined us for our fourth and final session of our LTE series of webinars. The LTE End-to-End QoS session was well attended and we had several questions we were not able to get to in the allotted time. Below are the questions that came in, with answers provided by our two architects DS and James.
Some final thoughts on LTE QoS: Our mindset has been that whenever we use our mobile device, the service, compared to our wired LAN connected service, will always be slower and have less capability. The technology of LTE presents us with the opportunity to have performance levels in our mobile device that rival the performance of high speed wired services. Wouldn’t it be great to no longer have two sets of performance expectations? The opportunities offered by LTE are unlike we have seen in the past with smaller incremental improvements in mobile wireless technology. And this provides us all with new revenue opportunities for years to come.
If you missed any of the sessions in the LTE series, you can view them online at anytime.
Q&A Session for End-to-End QoS in LTE
Q: Can you give an indication of the level of performance you would expect to get from the kind of packet classification system which you have described?
A: To date Radisys has built a number of such systems on our ATCA packet processing blades. As you might expect the realised performance is highly dependent upon the type of classification being undertaken. However, once a flow is learnt and in the look-up table we would expect to achieve full line rate for a 40GbE link through the 4 stage parse, extract, hash, look-up action pipeline with a single packet processor. Full line rate at 40GbE is with the smallest 64 byte packets and equates to roughly 60 million packets per second.
Q: In a video session where both UDP and TCP are used, are both protocols given the same classification as they are part of the same session or are they assigned classifications separately?
A: If the assumption is that the video control plane uses TCP while the video stream itself is over UDP then depending on the required capability of the platform these two transports could be independently assigned priority. In a more video-aware PCEF, the platform could associate the video stream with the control session and assign priority based on attributes extracted from the video stream setup process. Whether you would go to such lengths would almost certainly be governed by if the operator views certain content or content providers as requiring a premium service.
Q: Is the use of use of DPI limited only in the PDN-GW. For ex, if we want to throttle unwanted uplink data not adhering to the QoS subscribed, in for ex, in eNB, can DPI/traffic shaping be used over there or some other node?
A: DPI platforms make sense anywhere in the network where they offer a justified return on investment in terms of the ‘value’ that they bring. In better leveraging limited resources (i.e., bandwidth) then they are certainly applicable in a variety of nodes.
Q: You mentioned that your QoS provides for the ability to handle different packages to enable the ability for new subscriptions to receive greater “capabilities” for a period of time, how do you handle the management of individual routers and their “interpretation” of the DSCP field since it is configuration specific and therefore difficult to predict end-to-end behaviour. For example If a packet crosses two or more DiffServ domains before reaching its destination wouldn’t the different domains possible possibly handle the packets as different classes which would affect the end-to-end performance?
A: If we could sensibly use the DSCP field as a reliable indication of priority then it could save the need to do DPI. Unfortunately with the wide range of applications, which assign themselves arbitrarily L4 port numbers , DPI is often the only reliable way to truly classify a packet stream and so determine its priority. As well as assigning the scheduling queue, the PCEF could introduce an MPLS label or an agreed DSCP so that routers up stream can keep with the assigned priority scheme. This would almost certainly be a deployment specific configuration.
Q: When speaking of GBR bearers, how are non-LTE nodes (i.e. routers) forced to comply a QoS policy to make sure that GBR packets are routed with higher priority than non-GBR packets?
A: As well as assigning a packet stream to a scheduling queue, the PCEF could also assign an MPLS label or DSCP value to indicate the priority of the packet to upstream nodes.
Q: Are the number of QoS profiles supported (leves of QoS) and the number of application types that the NW supportes, a one to one mapping? ie, will be the NW be able to support any QoS (whose parameters are in the range of 3GPP specification) profile that the application asks (provided that the user is subscribed to that profile? or that a quantized version of that QoS profile is provisioned?
A: Multiple application types can map to a single QOS profile e.g., HTTP and email traffic types can map to a single EPS bearer in the network. This bearer dictates the level of QoS all these applications will get. The network or user will map the requested QoS to one of the 9 standard QoS class (QCI) values supported in the LTE network.