(Full) The Impact of VoLTE On IP Backhaul Network

Internal Reference White Paper
IP Transport Network for Voice over LTE (VoLTE)

By Jae Bom Ok from APJC Mobility Architecture This paper is intended to provide the reader with a reference point and understanding of the relation between VoLTE evolution and the underlying IP transport network addressing requirements of IP transport network for voice service over LTE. Unlike LTE air interface and evolved packet core which have well defined standards, the relationship and stitching point between LTE mobile infrastructures and IP transport network has not been explicitly described. This whitepaper will highlight what implications VoLTE brings into IP transport network and how these interact with IP transport network. In addition, it will cover what factors IP transport network should take into consideration to design and implement VoLTE service. Since the intention of this paper is to fill a gap between mobile experts and IP specialists, the details of VoLTE specifications are out of scope. The final objective is for the readers to have a firm understanding of how VoLTE mobile requirements should be interpreted into IP transport network design.
Keywords: IP Transport Network, IP RAN, Mobile Backhaul, VoLTE, LTE, QoS, H-QoS, WAN Orchestration, Cariden, MATE
2013 Cisco and/or its affiliates. All rights reserved. This document is Cisco Internal Reference Information. Page 1 of 44
Table of Contents
Why Does VoLTE Matter? .............................................................................................................. 5 How Is Voice Supported In LTE? ..................................................................................................... 7 What Differences Does VoLTE Service Bring In?.............................................................................10 How Is Quality of Service Provided in IP Transport Network? ........................................................13 What Should IP Transport Network Consider To Support VoLTE? ..................................................18 How Can QoS Capabilities of Cisco Products Guarantee VoLTE?.....................................................33 How Can Cisco WAN Orchestration Enhance IP/MPLS Network for VoLTE? ....................................35 Summary ......................................................................................................................................42 References ...................................................................................................................................43 Document History ........................................................................................................................44
Table of Figures
Figure 1. APJC Mobile Revenues.............................................................................................................. 5 Figure 2. VoLTE Positioning ..................................................................................................................... 6 Figure 3. Concept of CSFB (Circuit Switched Fall Back) ........................................................................... 8 Figure 4. Concept of VoLTE (Voice over LTE) ........................................................................................... 8 Figure 5. Evolution of Voice in an LTE Network....................................................................................... 9 Figure 6. Simplified VoLTE Call Flow and EPS bearers ........................................................................... 10 Figure 7. Scope of Standardized QCI characteristics for client/server and peer/peer communication 11 Figure 8. Typical QoS model in IP transport network ............................................................................ 13 Figure 9. Typical QoS behavior: The inside of an IP transport device (e.g. router, switch) .................. 14 Figure 10. QoS identifier of IP network ................................................................................................. 16 Figure 11. Layered view of mobile and IP transport infrastructure (between UE and P-GW portion). 18 Figure 12. Example of egress QoS in an IP transport node ................................................................... 21 Figure 13. IP transport network for VoLTE call types ............................................................................ 21 Figure 14. Three different viewpoints of QoS ....................................................................................... 23 Figure 15. LTE voice end to end delay budget (Reproduced from assumptions) ................................. 25 Figure 16. Comparative example of processing and propagation delay ............................................... 27 Figure 17. User traffic path during handover procedure (assuming inter-VLAN/subnet) .................... 28 Figure 18. Narrowband vs. Wideband AMR (Adaptive Multi-Rate) ...................................................... 30 Figure 19. Distributing EPC in IP Transport network ............................................................................. 30 Figure 20. Signaling and media paths before/after SR-VCC with PS-to-CS handover request ............. 32 Figure 21. QoS policy enforcement points ............................................................................................ 33 Figure 22. Sample diagram of H-QoS to a microwave access link ......................................................... 33 Figure 23. WAN Orchestration (Cisco MATE) Portfolio ......................................................................... 35 Figure 24. Basic understanding of MATE GUI ........................................................................................ 37 Figure 26. Example of failure analysis of the impact on voice traffic ................................................... 39 Figure 27. Example of evaluating impact of adding a new cell site ...................................................... 40 Figure 28. Example of evaluating end-to-end latency under a failure .................................................. 40 Figure 29. Example of optimizing a network to mitigate high traffic utilization ................................... 41
Internal Reference
Table of Tables
Table 1. Service comparison with competing technologies .................................................................... 6 Table 2. Standardized QCI Characteristics (QoS model in LTE from mobile perspective) .................... 11 Table 3. IP precedence, DSCP and its Per-Hop Behavior ....................................................................... 17 Table 4. Examples of QoS policy mapping table.................................................................................... 20 Table 5. Requirements of IP multimedia ............................................................................................... 24 Table 6. Example of serialization delay ................................................................................................. 26 Table 7. Propagation delay vs. distance ................................................................................................ 26 Table 8. Overview of QoS capability of ASR 901, ASR 903, and ASR 9000 ............................................ 34
2013 Cisco and/or its affiliates. All rights reserved. This document is Cisco Internal Reference Information.
Page 4 of 44
Why Does VoLTE Matter?

As widely reported, the proportion of a Mobile Service Providers revenue coming from voice services is decreasing [Figure 1] as Data services become more popular, however Voice is still a critical part of the business. Simultaneously, voice service of mobile service providers has been threatened by communication services offered by OTT (Over the Top) players. [Table 1] show a potential possibility of competitive service offerings against OTT. Therefore, as mobile service providers launch LTE services, it is important to maintain and migrate existing voice service into LTE environment, with at least the same or even better quality to offer differentiated experience compared to OTT services.
Figure 1. APJC Mobile Revenues
Source: Pyramid Research, 2013
Internal Reference
Table 1. Service comparison with competing technologies
Source: Heavy Reading Jan. 2012
By taking one step further, mobile service providers may take VoLTE (Voice over LTE) as a foundation platform of which any future services can be added on top. Since voice will be needed with all new communication services, a well-framed VoLTE platform may play a crucial role for IPbased in-house and 3rd party application development [Figure 2].
Figure 2. VoLTE Positioning
Source: Heavy Reading Jan. 2012
Next question is then if there are any mobile service providers in markets who have actually launched or will begin VoLTE service near future. Several cellular phone manufacturers produce VoLTE-capable phones today. VoLTE is already available as commercial service in South Korea since 2012, and several LTE players also have plans to launch VoLTE service near future.
Page 6 of 44
Internal Reference
How Is Voice Supported In LTE?

Unlike previous cellular telecommunications standards including GSM, LTE does not have dedicated channels for circuit switched telephony. Instead LTE is an all-IP system providing an end-to-end IP connection from the mobile equipment to the core network and out again. In other words, LTE initially aimed at the accommodation of exploding data traffic, but the need for IP based voice was added. There are three common technologies available to support voice in LTE network. CSFB (Circuit Switched Fall Back) SV-LTE (Simultaneous Voice LTE) VoLTE (Voice over LTE)
CSFB is the most common initial deployment model today as LTE service launches. The key reasons are that CSFB has the following advantages: Enables us to start offering voice services without requiring a full-fledged IMS (IP Multimedia Subsystem) network Enables us to start offering voice services with low LTE coverage. Enables us to start offering voice services without VoIP support on LTE UE.
However, there is one critical disadvantage in that non-voice PS service sessions (e.g. data, IP video conferencing, etc.) are handed over to legacy network, adversely affecting the users service quality. During CSFB, two options exist based on operator configuration and network capabilities: 1) Data stays with LTE and no data transfer occurs as long as the voice call lasts, and 2) Data also goes to 2G/3G and data may resume at lower rates. In CSFB deployment, the LTE network carries circuit- switched signaling over LTE interfaces, allowing the subscriber to be registered with the 2G/3G MSC even while on the LTE network. When there is a CS-event, such as an incoming voice call, the MSC sends the paging message to the LTE core network which delivers it to the subscriber device. The device then switches to 2G/3G operation to answer the call [Figure 3].
Page 7 of 44
Internal Reference
Figure 3. Concept of CSFB (Circuit Switched Fall Back) E-UTRAN (LTE) Legacy CS (1xRTT, GERAN, UTRAN)
Go to Legacy CS for CS (voice) Services

CSFB-capable UE
SV-LTE solely depends on the handset which works simultaneously with LTE mode for data and circuit switched mode for voice service. The drawback of this approach is expensive phone with high power consumption. SV-LTE is adopted today but some CDMA based operators.
For VoLTE (Voice over LTE), some form of VoIP (Voice over IP) must be used in order to provide some form of voice connection over a standard LTE bearer. VoLTE using VoIP requires IMS infrastructure. To facilitate IMS-based voice, vendors and operators created the One Voice initiative to define required baseline functionality for user equipment, LTE access network, Evolved Packet Core, and for the IMS. GSMA adopted the One Voice initiative in what it calls VoLTE (Voice over LTE), specified in GSMA reference document IR.92.
Figure 4. Concept of VoLTE (Voice over LTE)
E-UTRAN (LTE)
Legacy CS (1xRTT, GERAN, UTRAN)
1) PS Services (Data)
2) Voice call initiates or 3) arrives PS Services (Voice)
VoLTE-capable UE
Page 8 of 44
Internal Reference
Since, in VoLTE, VoIP is added to ongoing data applications, the subscriber continues to remain with the same LTE network ensuring the same service data experience [Figure 4]. Therefore, VoLTE has the following advantages: Subscriber QoE essentially remains the same when a voice call is added. Call setup delay may be shorter because the call setup signaling does not involve interaction between the LTE EPS and the legacy technology.
There are three stages how a voice service in LTE network evolves [Figure 5]. All LTE operators begin with the same initial stage where LTE performs only data service and the underlying 2G/3G network provides voice service via CSFB. As moving toward VoLTE, some LTE operators evolve to the second stage with a blueprint of third stage. In this case, VoLTE is available where LTE covers a portion of the total 2G/3G coverage area. Hence, voice in 2G/3G can occur via CSFB with or without SR-VCC. On the other hand, there are also some LTE operators who have a plan to jump right into the final stage when LTE coverage will match 2G/3G coverage, and LTE devices will be able to stay only within LTE network.
Figure 5. Evolution of Voice in an LTE Network
Source: Mobile Broadband Explosion, 4G Americas, Aug. 2013
Page 9 of 44
Internal Reference
What Differences Does VoLTE Service Bring In?

Since LTE is an all-IP packet-data network, voice is carried inside an IP packet. In order to make this happen, VoLTE uses an overall framework that includes how to support VoIP using specific features of IMS (IP Multimedia Subsystem), other entities in the LTE EPS (Evolved Packet System), and PCC (policy and charging control) [Figure 6]. IMS provides a variety of operator-controlled IP services and consists of CSCF (Call Session Control Function) for IMS registration/SIP session control and Interworking for existing PSTN/PLMN networks. PCC helps implement end-to-end QoS for the UEs sessions and makes QoS and charging decisions. Further details are out of scope in this paper.
Figure 6. Simplified VoLTE Call Flow and EPS bearers
Note) Above is an oversimplified figure. Voice signal and media path beyond PGW are different, but not shown here.
What matters in correlating with IP transport network is the new EPS bearers introduced by VoLTE [Figure 6]. These additional bearers are added on top of default bearer (shown as Internet APN Default EPS bearer in above figure) for general data services (Web, mail, etc.): 1) one is for IMS SIP signaling packet, and 2) another is user's voice media packet. How to differentiate one from another is specified in 3GPP TS 23.203 [Table 2].
Page 10 of 44
Internal Reference
Table 2. Standardized QCI Characteristics (QoS model in LTE from mobile perspective)
Source: 3GPP TS 23.203
According to 3GPP, LTE associates an EPS bearer to one of 9 QCI (Quality of Service Class Identifier) values which are further divided into two groups: GBR (Guaranteed Bit Rate) bearer and Non-GBR Non-Guaranteed Bit Rate) bearer. For VoLTE the IMS SIP signaling is QCI value of 5 and voice media packet is QCI value of 1.
Figure 7. Scope of Standardized QCI characteristics for client/server and peer/peer communication
Source: 3GPP TS 23.203 2013 Cisco and/or its affiliates. All rights reserved. This document is Cisco Internal Reference Information. Page 11 of 44
Internal Reference
In addition, there are minimum level of packet delay and loss associated with each QCI application type. [Figure 7] shows the scope (red color) where QCI characteristics are applicable, as specified in 3GPP TS 23.203. As one can notice, these delay and loss values are between mobile components from mobile infrastructure perspective, hence dont go down into IP backhaul network, and furthermore dont include IP backbone network that each application may traverse for end-to-end communication, depending on topologies. Therefore, these values are not directly interpreted as the requirements of IP transport network which provides the underlying path.
Page 12 of 44
Internal Reference
How Is Quality of Service Provided in IP Transport Network?

In this section, QoS (Quality of Service) in an IP network is briefly explained. In wireline networks, carrying packetized voice over IP packet network, so-called VoIP (Voice over IP) has been widely deployed. The VoIP could be either a residential service offered by the service provider, a business IT service from an enterprise itself, or it could be a managed VoIP enterprise service from the service provider. In a network wide view, deploying QoS is a strategic process in a sense that well-framed QoS policy could facilitate adding multiple services one after another. At the same time, tuning QoS parameter is generally not a one time job but a continuous process. [Figure 8] shows how QoS is typically planned. The key building blocks are categorized as follows: Classification (and optionally remarking) Policing or Shaping (in other words, metering, rate-limiting) Queuing and Scheduling Congestion Avoidance
Figure 8. Typical QoS model in IP transport network

Optionally, Remarking or Policing (Metering) per node basis Classification / Queuing & Scheduling / Congestion Avoidance per node basis Optionally, Remarking or Policing or Shaping (Metering) per node basis
An Incoming Application Packet
IP/MPLS Network
An Outgoing Application Packet
An Outgoing Application Packet
An Incoming Application Packet
Optionally, Remarking or Policing or Shaping (Metering) per node basis
Classification / Queuing & Scheduling / Congestion Avoidance per node basis
Optionally, Remarking or Policing (Metering) per node basis
Page 13 of 44
Internal Reference
As an IP packet enters a network, classification must be done properly according to the QoS policy of the service, because all subsequent QoS functionalities rely on this classification and this policy is usually applied throughout the IP network. Policing or shaping is for admission control either into or out of the IP network. In other words, this is the method how an IP network limits a bandwidth resource allowed to a class (done by classification in the previous step) or physical link. This is usually performed at the edge of network. Queuing and scheduling is the heart of QoS. This is the process which actually prioritizes a delaysensitive packet and guarantees a certain bandwidth to one class over others. One needs to keep in mind that QoS in IP network is DiffServ model in most cases, meaning that each node (e.g. router, switch) functions independently. Therefore, a proper QoS treatment at each node leads to an achievement of successful end-to-end QoS guarantee. Congestion avoidance is a feature which attempts to avoid that a queue becomes full. This is because one cannot control and guarantee queuing and scheduling once a queue is full, i.e. nothing but a blind tail-drop. WRED (Weighted Random Early Detection) is the commonly used queue management algorithm which drops a packet in a weighted form, resulting in traffic slow-down due to reduced TCP window size. As one may notice, this algorithm relies on TCP characteristics, so doesnt help UDP traffic like VoIP. As mentioned, QoS in IP network is mostly PHB (Per-Hop Behavior) of DiffServ model. [Figure 9] shows how each node performs QoS functionality (Regardless of this QoS behavior, IP destination look-up for routing/switching occurs as normal). A service guarantee through end-to-end QoS is a combination of edge PHB and core (non-edge) PHB. Usually, core PHB QoS is based on aggregated volume of traffic, while edge PHB QoS may be based on more specific traffic level of in/egress link. Figure 9. Typical QoS behavior: The inside of an IP transport device (e.g. router, switch)
Page 14 of 44
Internal Reference
Although the implementation of scheduling algorithm may be different, depending on products, the key concept remains same. As depicted in [Figure 9], two types of queue characteristic exist: (Strict) Priority queue Weighted queue Priority queue means that any packet placed here will be served first by scheduler and sent on a wire while packets in weighted queue should wait. This was designed to give higher priority to important and/or delay-sensitive traffic, such as voice. One thing to be aware is that packets in weighted queue will not be served and starved bandwidth if strict priority queue is overwhelmed by bad QoS policy or mis-marked traffic. To avoid this situation, policing can be configured along with strict priority queue. However, since the policer doesnt have application-level visibility, this should be considered as last resort. Weighted queue means that fair bandwidth is provided among weighted queues. Multiple weighted queues can be used to allocate different guaranteed bandwidth to different traffic classes. For example, business and internet traffic may be assigned to different weighted queue because the required treatment is not equal. No matter which queuing is being used, any unused bandwidth can be used by other class of traffic as long as there is no policing configured for a class. Now, a question is how each node differentiates each IP packet, enforces a policy, and places into a different queue? What is the identifier? The key identifiers are as follows depending on packet format: CoS value in IEEE 802.1Q tag ToS value in Ethernet header (e.g. IP precedence, DSCP) EXP value in MPLS label IP transport networks recognize, classify, police, queuing and scheduling based on the above identifiers. Therefore, one of above values should be used for QoS in IP transport network. Which value will be used depends on the type of network as depicted in [Figure 10]. Optionally, other parameters, such as incoming interface, combination of IP address and TCP/UDP port number, etc., can be also used for classification. Relations among IP precedence, BE/CS/AF/EF, and DSCP is illustrated in [Table 3] for reference.
Page 15 of 44
Internal Reference
Figure 10. QoS identifier of IP network
(a) Identifier in layer 2 Ethernet network
(b) Identifier in layer 3 native IP network
Page 16 of 44
Internal Reference
(c) Identifier in layer 2 and layer 3 MPLS network
Table 3. IP precedence, DSCP and its Per-Hop Behavior
Page 17 of 44
Internal Reference
What Should IP Transport Network Consider To Support VoLTE?

Now, its time to look into what IP transport network should take care of for successful VoLTE implementation. [Figure 11] illustrates how both SIP signaling and Voice media packets traverse between mobile infrastructure and IP transport network. One should notice that both default and dedicated EPS bearer exist only in mobile infrastructure layer. The IP transport layer is not aware of any EPS bearers because GTP header resides solely on IP data portion at the inside of IP packet. The IP transport network just forwards the IP packet, based on IP header information, to a corresponding GTP tunnel destination (e.g. eNB, S-GW, P-GW), resulting in eventually forming complete EPS bearer between eNB and P-GW.
Figure 11. Layered view of mobile and IP transport infrastructure (between UE and P-GW portion)
Page 18 of 44
Internal Reference
The aim for any voice service is to utilize the low latency and QoS features available within LTE to ensure that any voice service offers an improvement over the standards available on the 2G and 3G networks. 3GPP defines bandwidth guarantee and low latency as the characteristics of voice traffic as shown in [Table 2] in the previous section. From IP transport network viewpoint, both can be provided through queuing and scheduling. Routers or switches, however, don t understand 3GPP QCI values. Therefore, a mapping policy between 3GPP QCI and IP QoS values (e.g. IP precedence or DSCP for native IP, 802.1p for L2 Ethernet, or EXP for MPLS) must be created, especially IMS IP signaling (QCI value of 5) and voice media (QCI value of 1). In building the mapping table, there is no one right answer. In other words, operators may have their own way of mapping policy. However, here are some guidelines: Build a complete QoS policy at the beginning (with future services in mind), instead of completely rewriting QoS policy as new services add in the future. Group traffic types with similar characteristics or requirements, because most routers/ switches have only up to 8 queues of the same hierarchical level (compared to 9 QCI values). Also note that most routers/switches have only one priority queue. Only few products have dual priority queues (for example, Cisco ASR 9000, Cisco ASR 903, etc.) Marking DSCP1 from QCI value based on mapping policy should be done by mobile infrastructure (for example, eNB, P-GW, etc.) which has a visibility/knowledge of type of traffic. Marked DSCP values should be preserved as packets traverse IP transport network for consistent QoS treatment. Implement consistent QoS policy and treatment at all nodes within one administrative IP transport network. For VoLTE, SIP signaling and voice media packet treatment needs to be considered. Voice media packets should be allocated to priority queue for low latency.
Two examples of QoS policy mapping are given for reference in [Table 4]. In Example 1, both SIP signaling and voice traffic are marked as EF/46/5 and placed into a priority queue for low latency and, as a result, bandwidth for voice media traffic will be guaranteed under congestion. In Example 2, SIP signaling is marked as CS5 and voice traffic is marked as EF. No matter whichever QoS policy an operator creates, corresponding QoS configuration should be done on every IP transport node along the traffic path. Then, each IP transport node is ready to provide corresponding bandwidth guarantee for each defined class and prioritization for voice packet through priority queuing. An example is given in [Figure 12].
1
From here, DSCP term could represent any QoS identifiers (IP precedence, DSCP, EXP, 802.1p) in IP packet for simplicity. Page 19 of 44
Internal Reference
Table 4. Examples of QoS policy mapping table
(a) Example 1
(b) Example 2
Internal Reference
Figure 12. Example of egress QoS in an IP transport node
Suppose mobile infrastructure is well set up to treat VoLTE traffic according to QoS policy. Now, question is where exactly QoS should be implemented in IP transport network. A simple answer is wherever IP transport network carries either SIP signaling or voice media traffic. [Figure 13] is depicted to give an idea from various call cases. The demarcation of backhaul and backbone network may vary from one operator and another, depending on EPC locations and geographical size.
Figure 13. IP transport network for VoLTE call types
(a) VoLTE IMS Calls

Internal Reference
(b) VoLTE IMS to IMS calls
(c) VoLTE IMS calls to PSTN interworking

Note) Some signal flows (e.g. TAS, ENUM server, etc.) are not shown here for simplicity.
Bottom line is that this QoS treatment is the key requirement on the IP transport network for VoLTE service.
Internal Reference
Although, depending on voice codec in-use, a fixed amount of bandwidth per call is consumed, it is not as important as QoS implementation discussed previously. This is because IP transport network has no knowledge of a session or a call. Furthermore, a router or switch doesn t know if an incoming packet is a part of one call, dozens of calls, voice, or SIP signaling. That is nothing but an independent IP packet. What it does is to simply look up IP destinations, classifies packets according to configured QoS rules, performs queuing and scheduling accordingly, and forwards packets out. As long as proper QoS policy is configured at IP transport devices, there is nothing to worry about because VoLTE traffic will be served under non-congested environment and even prioritized under congested condition. Just note that there are some network devices which enforce to configure an upper bandwidth limit to priority queue by using a policer. This is to prevent malformed priority packets from consuming whole bandwidth, leaving other traffic unserved. In this case, configuring the upper limit to be higher than the expected aggregated volume of priority traffic will do fine. This upper limit is usually configured as a unit of '% of link bandwidth' or 'Kbps/Mbps'. Last but not least, one must not design IP transport networks with any always-congested links that are purely relying on QoS. In other words, QoS should be considered as a last resort that protects VoLTE service under any expected and unexpected circumstances. The meaning of QoS should be looked into three different angles as shown in [Figure 14].
Figure 14. Three different viewpoints of QoS
Page 23 of 44
Internal Reference
The low latency of LTE provides clear benefits for VoLTE. Shorter delays and faster call set-up times enable high quality voice and data connections, helping to improve the customer experience. However, as discussed [Table 2] and [Figure 7] in the previous chapter, IP transport specific requirements are specified nowhere. Therefore, it's not possible to derive exact figures for IP transport network only. To narrow down further, one may take the requirements of IP multimedia from wireline network, as shown in [Table 5], into account since VoLTE is a form of VoIP using IMS in cellular world. Callers usually notice round-trip voice delays of 250 ms or more. ITU-T G.114 recommends a maximum of a 150 ms one-way latency (mouth to ear). Since this value includes the entire voice path, part of which may be on the public Internet, ones own network should have transit latencies of considerably less than 150 ms.
Table 5. Requirements of IP multimedia
Source: QoS & Policy Mgmt in Mobile Data Network, IXIA, Jul. 2011
[Figure 15] elaborates which components are involved in VoLTE delay budget calculations. All assumptions used in this calculation are noted. With these assumptions, the mouth to ear one-way delay is approximately 160 ms, illustrating that LTE VoIP can provide lower end to end latency than circuit switched voice calls today (below 200 ms). Although the transport delay is assumed to be 10
Page 24 of 44
Internal Reference
ms, it will heavily depend on the network configuration and may also vary depending on how much delay budget actually consumed by other components in reality.
Figure 15. LTE voice end to end delay budget (Reproduced from assumptions)
Source: Voice over LTE (VoLTE), Wiley, 2012
More specific to backhaul network, NGMN recommends below latency figures to support various applications (not specific to VoLTE, though).
R48: The NGMN Backhaul solution MUST guarantee E2E maximum two-way delay of 10 ms as specified in [1] and SHOULD guarantee 5 ms when and where required by the operator. This requirement SHOULD be met even in user mobility procedure.
Source: NGMN Optimised Backhaul Requirements, NGMN, 2008
Above number may not be achievable in an IP backhaul network, depending on geographic size. However, there should be no issue as long as the requirements of voice service are achievable. In order to meet such targets, it is important for administrators or network designers to understand the components of IP network latency so they know which factors they can and cannot control with network and QoS design. Network latency can be broken down into fixed and variable components: Processing (fixed) Serialization (fixed) Propagation (fixed) Queuing (variable) Processing refers to the time it takes for each router or switch in the data path to add a finite amount of delay as the packet is received, processed, and then forwarded. Latency with a hardwareassisted device will be in the microsecond range while the processing delay on a software-based device can be relatively higher. Since this is not under users control and not significantly high, the processing delay should not be a main concern in IP network as long as the number of device hop is
Internal Reference
not unnecessarily big at both steady and failed topology, except a specialized market segment like a high performance trade market. Serialization refers to the time it takes to convert a Layer 2 frame into Layer 1 electrical or optical pulses onto the transmission media. Therefore, serialization delay is fixed and is a function of the line rate (i.e., the clock speed of the link) [Table 6]. By considering the fact that most link speed today is 1 Gbps and above, the size of a voice packet is small, and the value is not under users control, this serialization delay should not be a concern.
Table 6. Example of serialization delay
Usually, the most significant network factor in meeting the latency targets for over the WAN is propagation delay. Propagation delay is also a fixed component and is a function of the physical distance that the signals have to travel between the originating endpoint and the receiving endpoint. The propagation delay for most fiber circuits works out to be approximately 6.3 s per km or 8.2 s per mile [Table 7]. Except a large continent or oversea link, this may not have a significant impact.
Table 7. Propagation delay vs. distance
Page 26 of 44
Internal Reference
Lets take an example in [Figure 16]. Suppose processing delay of each node is 20 s. In (a), Node A reaches to an aggregation node via 1 direct hop of 63 s ( = 6.3 s/km x 10 km) in a steady network. Under the direct link failure, Node A has to go all the way around reaching an aggregation node via 4 indirect hops with an additional 0.395 ms delay ( = 5 x 63 s of propagation + 4 x 20 s of processing). In (b), Node B reaches to the aggregation node with the same hop and delay as Node A in the steady network. However, under the direct link failure, Node B has to go all the way around reaching the aggregation node via 15 indirect hops with an additional 1.308 ms delay ( = 16 x 63 s of propagation + 15 x 20 s of processing). Although the extra delay may not be significant in
Figure 16. Comparative example of processing and propagation delay
(a) Access ring example: Smaller number of nodes and shorter span
(b) Access ring example: Smaller number of nodes and shorter span
Internal Reference
this example, network designers need to be aware that a large ring may introduce an additional 1 ms or more latency into the network. Furthermore, having large number of nodes in a ring may also affect the accuracy of IEEE 1588v2 synchronization. The final network latency component to be considered is queuing delay, which is variable (variable delay is also known as jitter). Queuing delay is a function of whether a network node is congested and if so, what scheduling policies have been applied to resolve congestion events. Real-time applications including voice are often more sensitive to jitter than latency as a whole, as packets need to be received in de-jitter buffers prior to being played out. Given that the majority of factors contributing to network latency are fixed, careful attention has to be given to queuing delay, as this is the only latency factor that is directly under the network administrator's control-via their queuing policies. This was covered in Guaranteeing and Prioritizing part previously. Regarding latency, handover is another case to look into. During handover, the latency can be different between layer 2 and layer 3 backhaul network [Figure 17]. Data service less suffers from this latency while VoLTE may be more sensitive to this extra delay. However, the advantage of shortest path is expected to be much more obvious when low latency communication between eNBs is required, such as Cooperative Multi-point (CoMP), Self Optimising Networks (SON), etc.
Figure 17. User traffic path during handover procedure (assuming inter-VLAN/subnet)
(a) Layer 2 backhaul network
(b) Layer 3 backhaul network
When it comes to redundancy, failover, or convergence time, a common trap is to look at localized failure scenarios and claim to achieve 50 ms for all cases. The main reasons of this ask are 1) 50 ms is what my existing SONET/SDH TDM transmission network provides, 2) I dont know the reason, but isnt it good to have?. Should we really stick to 50 ms? Otherwise, will my application services be broken? The simple answer is not really. The several reasons are given as follows: 50 ms, in itself, is not relevant to most of the applications running over IP transport networks. The 50 ms figure historically originated from the specifications of APS
Page 28 of 44
Internal Reference
(Automated Protection Switching) subsystems in early digital transmission systems and was not actually based on any particular service requirement. Furthermore, as networks become more intelligent, other mechanisms can mitigate the effect of network outages. VoIP deployments over networks designed to converge in 800 ms or more are very common. Looking at protection from the applications point of view should be the ultimate goal. After all, networks ultimately carry applications traffic. In all IP network, it is very difficult to have 50 ms convergence time at all cases. In addition, there is not much gain by doing so, compared to the amount of effort and investment to be made, because that is not applications view point.
Cisco's UMMT generally recommends ~ 200 ms for overall applications. There is no one defined outage time for VoLTE, meaning that depends on VoLTE-related systems. For example, one VoLTE service provider has recently tuned its VoLTE system to be sustainable at up to 1 second outage.
The IP transport network is not aware of the codec and modulation technique in use for VoLTE.. To IP transport network, all signaling, voice and data over LTE are fundamentally the same IP packets but requiring different packet treatment for service quality. The mandatory codec set in VoLTE is limited to AMR and G.711, while other codecs are optional. Most mobile service providers specify the wideband AMR codec, for example the three mobile service providers in South Korea launched commercial VoLTE service in 2012 with wideband AMR, so-called HD Voice instead of narrowband AMR. When the wideband is used in mobile phone networks, there are three different configurations (combinations of bit rates) that may be used for voice channels: Configuration A (Config-WB-Code 0): 6.6, 8.85, and 12.65 kbit/s Configuration B (Config-WB-Code 2): 6.6, 8.85, 12.65, and 15.85 kbit/s Configuration C (Config-WB-Code 4): 6.6, 8.85, 12.65, and 23.85 kbit/s The reason is that HD voice can provide more vivid audio quality for better voice experience [Figure 18], but this service is currently limited among its own subscribers. Also, when the audio stream leaves the IP network (for PSTN call), the voice is returned to a PCM encoding, thereby losing the full benefit of wideband audio. If a mobile operator plans to use AMR-WB in 3GPP, then the biggest voice channel would be 23.85 kbps per channel. Again, however, this is all about VoLTE-related system and doesn't really matter to IP transport network because it simply doesnt need to know.
Page 29 of 44
Internal Reference
Figure 18. Narrowband vs. Wideband AMR (Adaptive Multi-Rate)
In most cases, operators start LTE service in small scale by centralizing EPC. As LTE coverage expands and/or VoLTE service launches, the need of distributing EPC (either physical or virtual EPC) may rise over time. [Figure 19] depicts how much work should be done while distributing EPC in accordance with IP backhaul network architectures. (a) and (b) represents end-to-end layer 2 architecture between eNB and EPC, while (c) represents existence of layer 3 at least somewhere in backhaul network. In (a) and (b), some modification may be needed at existing eNB and IP transport network. (c) has flexibility to accommodate a new insertion. Ciscos UMMT architecture greatly takes an advantage of (c).
Figure 19. Distributing EPC in IP Transport network
(a) Layer 2 point-to-point backhaul network (EVC, EoMPLS, T-MPLS)

Internal Reference
(b) Layer 2 point-to-multipoint backhaul network (e.g. VPLS)
(c) Layer 3 backhaul network (IP/MPLS)
In many cases, operators build and expand their LTE networks gradually, adding cells and capacity in line with their business plans and subscriber demand. As a result, LTE networks and the VoLTE services built on top of them must be able to coexist with legacy CS networks and to ensure handover to the legacy CS network when LTE coverage is insufficient. Since LTE and VoLTE services are a fundamental part of next-generation mobile networks, voice handover to legacy CS systems is a key capability while LTE coverage continues to be spotty. A VoLTE call should be transferred from the LTE PS network to the legacy CS voice network while the call is in progress, while satisfying existing user experience expectations for minimal call interruption and low call drop rates. This handover needs to be well engineered with performance levels comparable to the Inter-Radio Access Technology (IRAT) handover procedures for voice calls available in CS networks today. These established QoS standards are less than 0.3 seconds voice interruption time and call drop rates less than one percent.
Internal Reference
SR-VCC is the solution to this requirement for voice call continuity, and uses a single radio in the users device along with upgrades to the supporting network infrastructure . [Figure 20] shows signaling and media paths when SR-VCC handover occurs. Assuming the same QoS-enabled IP transport network is serving both LTE and 3G voice, one should give attention to the additional signaling and media paths introduced by SR-VCC implementation. Complete QoS scheme should be able to handle SR-VCC session messages to minimize voice interruption delay during handover (0.3 second target by 3GPP TS22.278). If a legacy backhaul network is not good enough to serve voice calls then proper action should be taken.
Figure 20. Signaling and media paths before/after SR-VCC with PS-to-CS handover request
Page 32 of 44
Internal Reference
How Can QoS Capabilities of Cisco Products Guarantee VoLTE?

It has been discussed that IP transport network uses a Differentiated Services (DiffServ) QoS model across all network layers of the transport network in order to guarantee proper treatment of all services being transported. This QoS model guarantees the service-level agreement (SLA) requirements of all mobile backhaul services including voice across the transport network. QoS policy enforcement is accomplished with the following approach: Flat QoS (Non-H-QoS) policies with DiffServ queuing on all Network-to-Network Interfaces. H-QoS policies with parent shaping and child queuing on the User-to-Network Interfaces (UNIs) and interfaces connecting to microwave access links.
[Figure 21] depicts the collapsed view of IP transport network layer and mobile infrastructure layer in a row. Point (a) and (b) may need H-QoS because there is a high possibility of speed mismatch caused by processing performance between a router and eNB/microwave. Therefore, to prevent the prioritized traffic from being tail-dropped at the bottleneck, it is preferred for prioritizing/scheduling to jump in after this mismatch is handled by H-QoS [Figure 22]. Point (4) depends upon the network design of mobile infrastructure attached to MTG (Mobile Transport Gateway) device. If multiple mobile service nodes are logically separated under the same physical interface, then there may be a need for H-QoS.
Figure 21. QoS policy enforcement points
Figure 22. Sample diagram of H-QoS to a microwave access link
Page 33 of 44
Internal Reference
Cisco IP transport products all provide necessary capabilities. [Table 8] provides a glimpse of Cisco products comprehensive QoS capabilities. For successful QoS design and implementation, it would be valuable to take a moment and understand what each feature means and how well it aligns with ones service and network needs. For instance, one would not want the performance of a device to be affected by QoS. In a certain case, one would not want to find out that ingress H-QoS is not supported when needed. In aggregation point, one may want a system with internally hardened QoS architecture because there is a higher chance of internal congestion caused by many-to-one traffic direction. Cisco IP transport products will best suit ones purpose of guarant eeing voice traffic over LTE network.
Table 8. Overview of QoS capability of ASR 901, ASR 903, and ASR 9000
Page 34 of 44
Internal Reference
How Can Cisco WAN Orchestration Enhance IP/MPLS Network for VoLTE?
In the previous sections, various aspects for successful VoLTE service were discussed. However, it may be still challenging to mobile service providers because they usually dont have enough visibility and confidence that their complex networks are ready for voice service. Therefore, this section will elaborate on how Cisco WAN orchestration can help mobile service providers enable VoLTE more effectively.
Although the details of Cisco WAN orchestration are out of this paper, some basics need to be explained in order to understand how it will enhance VoLTE service. Cisco WAN orchestration (Cisco MATE, also formerly known as Cariden MATE) portfolio consists of MATE Collector, MATE Design, and MATE Live [Figure 23]. Each of these components is tightly integrated and simultaneously supports planning, engineering, and operational tasks.
Figure 23. WAN Orchestration (Cisco MATE) Portfolio
Page 35 of 44
Internal Reference
MATE is specialized in IP/MPLS and traffic-engineering but also effective under non-trafficengineering environment. Each component has the following characteristics and functionalities: MATE Collector: o This is a mandatory component, and the key functionality is to automatically discover and continuously maintain network data. o The input sources can be both offline and online, such as configurations, statistics, flow data, SNMP, CLI, etc. o One of the beauties is that multi-vendor network devices from Huawei, Juniper and Alcatel-Lucent are also supported as data input sources. o The collected data from various inputs at a given time is stored as a snapshot of the network, called a plan file. These series of snapshots over time is also stored at the time-series data store. MATE Design: o The key functionality is to design, engineer and plan IP/MPLS networks. In other words, o In other words, a key differentiating feature of MATE Design is that it provides a series of detailed what-if scenario simulation in a timely and accurate manner. Therefore, MATE Designs demystifies complex networks to present clear, understandable and usable results of simulations. One can load a snapshot (plan file) and design/simulate a new node, circuit (interfaces) utilization, traffic demands as a predictive modeling. A snapshot can be loaded, and either a particular case or worst-case failure can be simulated and analyzed without impacting the real network. MATE Live: o The key functionality is to provide operational infrastructure analytics, meaning that it is excellent at interactively visualizing, navigating, and reporting on near real time and historical data. Explore enables you to interactively navigate to current and historical data, and Analytics allows you to generate reports on this data. MAP provides a high-level view of the current network health through a near-real-time weathermap in a highly visual way. Because the Map and Explore capabilities are tightly coupled, you can immediately drill down to detailed information to troubleshoot network issues. As one may notice, MATE is not a replacement or competitor of Cisco PRIME, but a complementary solution. Mobile service providers may select one of the following combinations, depending on their needs.
Internal Reference
Option 1 - MATE Collector + MATE Design Option 2 - MATE Collector + MATE Live Option 3 - MATE Collector + MATE Design + MATE Live [Figure 24] illustrates how to interpret visual MATE GUI. One should understand that the terminology of circuit represents one physical link, broken into each direction. Since one physical link between sites or nodes has bi-directional connectivity, one circuit contains two interfaces in MATE GUI. Traffic utilization of each interface is colored accordingly. Double-clicking on a site brings up intra-site view in detail. Figure 24. Basic understanding of MATE GUI
Figure 25. Path information in MATE
Page 37 of 44
Internal Reference
Since all routing information is also fed into a snapshot, MATE can actually show you which path(s) will be taken from site A to Z [Figure 25] regardless of the existence of traffic-engineering. This empowers you to design, engineer, plan, and monitor various simulation scenarios.
Now its time to look into what the concerns are and how Cisco WAN orche stration can address them. When it comes to enable the new voice service on top of the existing LTE network, the main concerns would be as follows: Does my current network is healthy? Isnt there any instability issue? Does my network have an optimal path between cell site and VoLTE systems? How do I check whether my network can support the expected voice traffic flows in the requested paths without causing congestion leading to service outages? Does the intended path provide resilience in the event of failures in the layer 3 and layer 1 network? Is the configured QoS sufficient to protect voice traffic even under single and multiple failure events? If a new cell site is added, then what would be the impact? What was the trend in the past several months? How do I make projections for the next 2 ~ 3 years? How can I estimate if the maximum latency would meet VoLTE requirement under failures?
Cisco WAN orchestration will be able to assist mobile service providers to deal with these concerns effectively. One may take advantages of followings as examples: The health of the network on a near-real-time basis can be presented or the historical data can be navigated using MAP in MATE Live which is generated by the network topology and traffic information that MATE Collector discovers. The Events health panel in MAP can assist to evaluate the stability of network by listing the number of current events and the number of changes since the last snapshot was taken. Traffic reports with Analytics in MATE Live enable you to trend interface traffic, LSP traffic, and demands over a specified time range by offering the trend algorithms such as exponential, linear, logarithmic, power.
Page 38 of 44
Internal Reference
With MATE Design, if one requests a set of traffic demands2, then the routes are automatically calculated and visualized showing which path will be chosen along with its estimated traffic utilization information. MATE Design offers an offline analysis which allows you to simulate the failure of a specific interface to see what would be the impact on the rest of the network. Even greater value is that you can perform this for a specific service class (e.g. voice). This enables you to verify and ensure that a QoS policy protects your voice service in not only steady state but also a network failure [Figure 26]. In worst-case failure analysis in MATE Design, the interfaces are colored based on their worst-case utilizations over all the scenarios specified for the simulation analysis (e.g. multiple failures). This also helps you discover the cause of their worst-case loading (e.g. which interface imposes the most loads to this worst case scenario).
Figure 26. Example of failure analysis of the impact on voice traffic
A demand means a specified amount of traffic from one node (source) to another node (destination). Page 39 of 44
Internal Reference
With MATE Design, you can assess the impact of the increase in data/voice traffic on the network when adding new cell sites [Figure 27]. Optimization feature in MATE Design suggests you how to tune parameters in your network in order to meet the network requirements such as maximum latency [Figure 28], traffic utilization on an interface [Figure 29], etc.
Figure 27. Example of evaluating impact of adding a new cell site
Figure 28. Example of evaluating end-to-end latency under a failure
Page 40 of 44
Internal Reference
Figure 29. Example of optimizing a network to mitigate high traffic utilization
As discussed in this section, Cisco WAN orchestration solution will be able to greatly enhance mobile service providers experience in designing, planning, and operating IP transport network. Moreover, MATE Collector is expected to evolve toward a programmable service control platform in a longer term. WAN orchestration solution, MATE, today is the first step toward pragmatic SDN provides visibility and validates algorithms.
Page 41 of 44
Summary
As LTE service launches and expands its coverage, VoLTE service is seen as next evolution step because it can be a foundation of all upcoming multimedia services to mobile service providers. While preparing mobile components for VoLTE, concerns and questions about IP transport network also rise. As a VoIP service using IMS, the key to IP transport network is how to set up and implement appropriate end-to-end QoS policy across mobile and transport infrastructure. To establish firm understandings, various aspects are evaluated. By considering and applying those factors, there should not be a big concern in terms of IP transport network. Cisco products of IP transport network have been designed and developed with priority given to QoS. The service level of VoLTE in ones network will certainly be reinforced. With Cisco WAN orchestration solution, mobile service providers now plan for and controls what is happening on their network. They can predict service-impacting problems before they happen and take mitigating action before their customers experience performance degradation and start complaining.
Internal Reference
References
Pyramid Research, 2013 Heavy Reading Jan. 2012 Mobile Broadband Explosion, 4G Americas, Aug. 2013 3GPP TS 23.203, Policy and charging control architecture QoS & Policy Mgmt in Mobile Data Network, IXIA Voice over LTE (VoLTE), Wiley NGMN Optimised Backhaul Requirements Design Best Practices for Latency Optimization GSM Association IR.92, IMS Profile for Voice and SMS 3GPP TS 22.278, Service requirements for the Evolved Packet System (EPS) Introduction to the MATE Design - User Interface, Simulation and the Simulation Analysis Tool MATE Design Tutorials MATE Live User Guide
Page 43 of 44
Internal Reference
Document History
Version Date 0.1 0.9 0.9 1.0 1.1 1.2 1.3 26 Aug. 2013 5 Sep. 2013 9 Sep. 2013 10 Sep. 2013 1 Oct. 2013 23 Oct. 2013 25 Oct. 2013 Author Jae Bom Ok Jae Bom Ok APJC Mobility Jae Bom Ok Andrew Mackay Jae Bom Ok Jae Bom Ok Changes Initial Draft. 1st Draft. 1st Draft Review. Minor correction in format. Revision. WAN orchestration. QoS capability of Cisco Products. WAN orchestration reviewed by Sonny Franslay.
Page 44 of 44

(Full) The Impact of VoLTE On IP Backhaul Network

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

(Full) The Impact of VoLTE On IP Backhaul Network

Загружено:

Авторское право:

Доступные форматы

Internal Reference White Paper

IP Transport Network for Voice over LTE (VoLTE)

Internal Reference White Paper

Internal Reference White Paper

Internal Reference White Paper

Why Does VoLTE Matter?

Figure 1. APJC Mobile Revenues

Source: Pyramid Research, 2013

Table 1. Service comparison with competing technologies

Source: Heavy Reading Jan. 2012

Figure 2. VoLTE Positioning

Source: Heavy Reading Jan. 2012

How Is Voice Supported In LTE?

Go to Legacy CS for CS (voice) Services

Figure 4. Concept of VoLTE (Voice over LTE)

Legacy CS (1xRTT, GERAN, UTRAN)

2) Voice call initiates or 3) arrives PS Services (Voice)

Figure 5. Evolution of Voice in an LTE Network

Source: Mobile Broadband Explosion, 4G Americas, Aug. 2013

What Differences Does VoLTE Service Bring In?

Figure 6. Simplified VoLTE Call Flow and EPS bearers

Source: 3GPP TS 23.203

How Is Quality of Service Provided in IP Transport Network?

Figure 8. Typical QoS model in IP transport network

An Incoming Application Packet

An Outgoing Application Packet

An Outgoing Application Packet

An Incoming Application Packet

Optionally, Remarking or Policing or Shaping (Metering) per node basis

Classification / Queuing & Scheduling / Congestion Avoidance per node basis

Optionally, Remarking or Policing (Metering) per node basis

Figure 10. QoS identifier of IP network

(a) Identifier in layer 2 Ethernet network

(b) Identifier in layer 3 native IP network

(c) Identifier in layer 2 and layer 3 MPLS network

Table 3. IP precedence, DSCP and its Per-Hop Behavior

What Should IP Transport Network Consider To Support VoLTE?

Table 4. Examples of QoS policy mapping table

Figure 12. Example of egress QoS in an IP transport node

Figure 13. IP transport network for VoLTE call types

(a) VoLTE IMS Calls

(b) VoLTE IMS to IMS calls

(c) VoLTE IMS calls to PSTN interworking

Figure 14. Three different viewpoints of QoS

Table 5. Requirements of IP multimedia

Source: Voice over LTE (VoLTE), Wiley, 2012

Table 6. Example of serialization delay

Table 7. Propagation delay vs. distance

Figure 16. Comparative example of processing and propagation delay

(a) Layer 2 backhaul network

(b) Layer 3 backhaul network

Figure 18. Narrowband vs. Wideband AMR (Adaptive Multi-Rate)

Figure 19. Distributing EPC in IP Transport network

(a) Layer 2 point-to-point backhaul network (EVC, EoMPLS, T-MPLS)

(b) Layer 2 point-to-multipoint backhaul network (e.g. VPLS)

(c) Layer 3 backhaul network (IP/MPLS)

How Can QoS Capabilities of Cisco Products Guarantee VoLTE?

Figure 21. QoS policy enforcement points

Figure 22. Sample diagram of H-QoS to a microwave access link

Figure 23. WAN Orchestration (Cisco MATE) Portfolio

Figure 25. Path information in MATE

Figure 26. Example of failure analysis of the impact on voice traffic