-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 1 of 44
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 2 of 44
Internal Reference White Paper
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 3 of 44
Internal Reference White Paper
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 4 of 44
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 5 of 44
Internal Reference White Paper
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 6 of 44
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 IP-based 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 7 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].
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 8 of 44
Internal Reference
Figure 3. Concept of CSFB (Circuit Switched Fall Back)
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)
CSFB-capable UE
Legacy CS
(1xRTT, GERAN, UTRAN)
Go to Legacy CS
for CS (voice) Services
E-UTRAN
(LTE)
VoLTE-capable UE
Legacy CS
(1xRTT, GERAN, UTRAN)
3) PS Services
(Voice)
1) PS Services
(Data)
2) Voice call initiates or arrives
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 9 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 10 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].
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 11 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 12 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 13 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
IP/MPLS Network
An Incoming Application Packet
An Outgoing Application Packet
An Outgoing Application Packet
An Incoming Application Packet
Classification / Queuing & Scheduling /
Congestion Avoidance per node basis
Classification / Queuing & Scheduling /
Congestion Avoidance per node basis
Optionally, Remarking or Policing (Metering)
per node basis
Optionally, Remarking or Policing or Shaping (Metering)
per node basis
Optionally, Remarking or Policing or Shaping (Metering)
per node basis
Optionally, Remarking or Policing (Metering)
per node basis
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 14 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 delay-sensitive 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)
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 15 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 16 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 17 of 44
Internal Reference
(c) Identifier in layer 2 and layer 3 MPLS network
Table 3. IP precedence, DSCP and its Per-Hop Behavior
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 18 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)
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 19 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, dont 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 20 of 44
Internal Reference
Table 4. Examples of QoS policy mapping table
(a) Example 1
(b) Example 2
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 21 of 44
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 22 of 44
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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 23 of 44
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 doesnt 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 24 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 25 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
hardware-assisted 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 26 of 44
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 27 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 28 of 44
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 29 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 30 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)
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 31 of 44
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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 32 of 44
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 33 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 34 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 guaranteeing
voice traffic over LTE network.
Table 8. Overview of QoS capability of ASR 901, ASR 903, and ASR
9000
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 35 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 36 of 44
Internal Reference
MATE is specialized in IP/MPLS and traffic-engineering but also
effective under non-traffic-engineering 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 37 of 44
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 38 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 orchestration 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 39 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
2 A demand means a specified amount of traffic from one node
(source) to another node (destination).
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 40 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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 41 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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information.Page 42 of 44
Internal Reference White Paper
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.
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 43 of 44
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
-
2013 Cisco and/or its affiliates. All rights reserved. This
document is Cisco Internal Reference Information. Page 44 of 44
Internal Reference
Document History
Version Date Author Changes
0.1 26 Aug. 2013 Jae Bom Ok Initial Draft.
0.9 5 Sep. 2013 Jae Bom Ok 1st Draft.
0.9 9 Sep. 2013 APJC Mobility 1st Draft Review.
1.0 10 Sep. 2013 Jae Bom Ok Minor correction in format.
1.1 1 Oct. 2013 Andrew Mackay Revision.
1.2 23 Oct. 2013 Jae Bom Ok WAN orchestration. QoS capability of
Cisco Products.
1.3 25 Oct. 2013 Jae Bom Ok WAN orchestration reviewed by Sonny
Franslay.