10.01.2015 Views

Why Latency Matters to Mobile Backhaul - O3b Networks

Why Latency Matters to Mobile Backhaul - O3b Networks

Why Latency Matters to Mobile Backhaul - O3b Networks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong><br />

<strong>Mobile</strong> <strong>Backhaul</strong><br />

by <strong>O3b</strong> <strong>Networks</strong> and Sofrecom<br />

This paper is presented by <strong>O3b</strong> <strong>Networks</strong> <strong>to</strong> provide an<br />

understanding of the impact of latency on mobile backhaul<br />

services. Several common voice and data applications are<br />

analyzed <strong>to</strong> assess the impact of latency on the quality of<br />

the end user’s experience. The paper compares the Quality<br />

of Experience (QoE) based on latency differences between<br />

Geosynchronous satellites and Medium Earth Orbit satellites.<br />

Contents<br />

About <strong>O3b</strong> <strong>Networks</strong> Ltd. 2<br />

About Sofrecom 2<br />

Proprietary Statements 2<br />

<strong>Mobile</strong> Industry Landscape 3<br />

<strong>Latency</strong> for satellite backhaul and impact of <strong>Latency</strong> on<br />

Quality of Experience 6<br />

Conclusion 14<br />

Annexes 15<br />

www.o3bnetworks.com 1


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

About <strong>O3b</strong> <strong>Networks</strong> Ltd.<br />

<strong>O3b</strong> <strong>Networks</strong> is a global satellite service provider building a new fiberquality,<br />

global Internet backbone for telecommunications opera<strong>to</strong>rs,<br />

internet service providers, enterprise and Government cus<strong>to</strong>mers in<br />

emerging markets. The <strong>O3b</strong> <strong>Networks</strong> system will combine the global reach<br />

of satellite with the speed of a fiber-optic network providing billions of<br />

consumers and businesses across 177 countries with low-cost, high-speed,<br />

low latency internet and mobile connectivity. With investments and<br />

operational support from SES, Google Inc. Liberty Global, Inc. HSBC Principal<br />

Investments, Northbridge Venture Partners and Allen & Company, the <strong>O3b</strong><br />

system will provide telcos and ISPs with a low-cost, high-speed alternative<br />

<strong>to</strong> connect their 3G, WiMAX and fixed-line networks <strong>to</strong> the rest of the<br />

world. <strong>O3b</strong> <strong>Networks</strong> is headquartered in<br />

St. John, Jersey, Channel Islands.<br />

About Sofrecom<br />

Sofrecom, a France Telecom – Orange Group Company, is a world leader in<br />

telecommunications consulting and engineering.<br />

With more than 45 years international experience, Sofrecom has acquired a<br />

unique know-how of successfully managing change in the<br />

telecommunications industry. Sofrecom has led major transformation<br />

programs and has participated in the green field launch of multiple<br />

opera<strong>to</strong>rs, including all Orange mobile opera<strong>to</strong>rs over the past 5 years.<br />

This rich international experience provides Sofrecom with an unparalleled<br />

expertise in all areas of telecommunications and makes it the natural<br />

strategic partner for opera<strong>to</strong>rs, governments, inves<strong>to</strong>rs and international<br />

financial organizations.<br />

Proprietary Statements<br />

<strong>O3b</strong> provides this information in good faith, and has taken all reasonable<br />

steps <strong>to</strong> ensure its accuracy and completeness as of the date hereof.<br />

However, <strong>O3b</strong> expressly disclaims any and all liability which may be based<br />

on the use of such information, errors therein, changes and omissions<br />

there<strong>to</strong>. <strong>O3b</strong> shall not be liable for damages of any kind, including special,<br />

incidental or consequential damages or damages for loss of goodwill or loss<br />

of prospective profits, on account of omissions or errors contained herein.<br />

<strong>O3b</strong>® and <strong>O3b</strong> <strong>Networks</strong>® are registered trademarks of <strong>O3b</strong> <strong>Networks</strong><br />

Limited. Other product names, company names, brand names, and trade<br />

names mentioned within the corporate information center may be the<br />

trademarks of their respective holders. All rights in the service marks,<br />

company names, trade names, and logos used for the products or services<br />

of <strong>O3b</strong> or of third parties belong exclusively <strong>to</strong> <strong>O3b</strong> or their respective<br />

owners, and are protected from reproduction, imitation, dilution, or<br />

confusing or misleading uses under national and international trademark<br />

and copyright laws.<br />

www.o3bnetworks.com 2


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

<strong>Mobile</strong> Industry Landscape<br />

The <strong>Mobile</strong> industry is changing rapidly, as it evolves from 2G <strong>to</strong> 3G and on<br />

<strong>to</strong> 4G networks. This evolution is driven by the need <strong>to</strong> provide better<br />

performance in three main areas:<br />

− Provide subscribers with higher data rates<br />

− Support a wider variety of end user applications<br />

− Reduce the latency of the mobile network<br />

Increasing sales of 3G smartphones, USB modems, tablets and PCs with<br />

built in wireless radios is pushing data traffic on mobile networks <strong>to</strong> record<br />

levels. While email, social networks and Internet browsing are very popular<br />

among nomadic users, the deployment of mobile broadband services has<br />

the biggest impact on network traffic. In rural areas, mobile networks are<br />

often the only way <strong>to</strong> support applications his<strong>to</strong>rically delivered over<br />

copper based networks. Video streaming is a major contribu<strong>to</strong>r <strong>to</strong> the boost<br />

in traffic, with the success of Internet services such as YouTube and<br />

DailyMotion. The latest Cisco Visual Networking Index forecasts<br />

unprecedented global mobility demand.<br />

Figure 1 – <strong>Mobile</strong> Data Growth<br />

www.o3bnetworks.com 3


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Data services are projected <strong>to</strong> grow by a staggering 78% annually over just<br />

the next four years. It is also clear that the mix of applications is changing,<br />

particularly with the shift <strong>to</strong>wards mobile video.<br />

While the increasing data rates and the changing application mix are easily<br />

unders<strong>to</strong>od, the impact of latency on performance requires a closer look.<br />

How does latency affect application quality and the end user experience<br />

We will explain the significant difference lower latency can make in the<br />

delivery of voice, video and data services. We will strive <strong>to</strong> answer the<br />

question: <strong>Why</strong> does latency matter <strong>to</strong> mobile backhaul<br />

QoE is the new challenge<br />

Fierce market competition is driving network opera<strong>to</strong>rs <strong>to</strong> identify true<br />

differentia<strong>to</strong>rs capable of separating them from the rest. The innova<strong>to</strong>rs, in<br />

turn, are intensifying efforts <strong>to</strong> boost the Quality of Experience for their<br />

subscribers. As a result, QoE is now one of the latest buzzwords in the<br />

mobile industry.<br />

The QoE experienced by a mobile subscriber for a voice call is influenced by<br />

a number of fac<strong>to</strong>rs, including mouth-<strong>to</strong>-ear delay, voice call set-up delay<br />

and audio quality/noise. The QoE for data services is influenced by web<br />

page response time and download speeds.<br />

Network segment QoS indica<strong>to</strong>rs<br />

For mobile network elements, such as components of the access, backhaul<br />

and core networks, several indica<strong>to</strong>rs are used <strong>to</strong> define and moni<strong>to</strong>r the<br />

target performance.<br />

− <strong>Latency</strong> - <strong>Latency</strong> is the duration of time for information <strong>to</strong> transit from<br />

one point <strong>to</strong> another point of the network. Depending on the type of<br />

service, it can be measured either in one direction (Ear-<strong>to</strong>-mouth or<br />

One-way latency) or as a round trip time (RTT or Two-way latency).<br />

− Jitter - Jitter is the variation of the measured latency. It is generated by<br />

the variation of the load on the network due <strong>to</strong> usage levels.<br />

− Packet loss - Packet loss is the ratio of packets being lost during transit<br />

from one point <strong>to</strong> another point of the network. It is generally caused<br />

by transmission errors, congestion of links, faults or the routing process.<br />

In modern IP based networks jitter is easily compensated for by<br />

implementing buffers in the endpoints. Likewise packet loss is very low on<br />

<strong>to</strong>day’s networks, which employ high performance error correction codes<br />

such as LDPC which is used in DVB-S2. <strong>Latency</strong>, however, is more difficult <strong>to</strong><br />

avoid. The root cause is linked <strong>to</strong> long distances and the speed of light.<br />

Once present in a system, latency cannot be removed. This is exactly why<br />

the mobile industry has consistently engineered each new technology<br />

generation with lower latency, as seen in Figure 2.<br />

www.o3bnetworks.com 4


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Figure 2 – <strong>Latency</strong> in <strong>Mobile</strong> Technology Evolution<br />

Every new mobile technology generation has reduced network latency. The<br />

right side of the chart shows the latency of satellite backhaul for traditional<br />

GEO satellite and <strong>O3b</strong>’s MEO constellation. It is easy <strong>to</strong> see that for later<br />

generation mobile networks satellite backhaul is the dominant contribu<strong>to</strong>r<br />

<strong>to</strong> end-<strong>to</strong>-end latency and the resulting subscriber QoE.<br />

www.o3bnetworks.com 5


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

<strong>Latency</strong> for satellite backhaul and impact of <strong>Latency</strong> on<br />

Quality of Experience<br />

End-<strong>to</strong> End latency Model<br />

Each network component contributes <strong>to</strong> latency. The chart below, extracted<br />

from a study by Nokia Siemens <strong>Networks</strong> (NSN), shows the latency<br />

distribution for a mobile network (exclusive of backhaul or international<br />

network latency).<br />

Figure 3 – <strong>Latency</strong> Distribution for <strong>Mobile</strong> Network (NSN 1 )<br />

(1) Extracted from “The impact of latency on application performance, Nokia Siemens <strong>Networks</strong>”<br />

With each release there has been a tremendous engineering effort <strong>to</strong><br />

optimize each network element and terrestrial link <strong>to</strong> provide the lowest<br />

possible latency. Individual components have been optimized, frame<br />

lengths reduced, pro<strong>to</strong>cols streamlined, and in the case of LTE, an entire<br />

network layer has been eliminated.<br />

The satellite backhaul element is much more difficult <strong>to</strong> optimize.<br />

Technologies, such as ComtechEFData’s VersaFEC, have improved the<br />

modem processing delay, but the fundamental distance of the path length<br />

<strong>to</strong> the satellite is what drives the delay.<br />

www.o3bnetworks.com 6


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

<strong>Mobile</strong> Service Classification<br />

From a mobile network perspective, the ITU and the 3GPP have grouped<br />

the end-user services in<strong>to</strong> four classes based on their sensitivity <strong>to</strong> latency.<br />

Figure 4 – User services classification<br />

This paper focuses on the three major service classes for mobile opera<strong>to</strong>rs<br />

and the practical impact of latency on:<br />

− Conversational Voice<br />

− Interactive Applications, such as cloud-based applications, online<br />

shopping, instant messenger and online search.<br />

− Non real-time data, such as web browsing, email SMS/Text messaging,<br />

file sharing, and video streaming.<br />

Conversational Voice Services<br />

Voice quality is measured in the ITU model by the R fac<strong>to</strong>r, which can also<br />

be translated in<strong>to</strong> a Mean Opinion Score (MOS) score, a scale widely used<br />

<strong>to</strong> evaluate the quality of a voice call. The MOS score and voice call quality<br />

degrades rapidly when the ear-<strong>to</strong>-mouth latency increases beyond 200ms.<br />

Annex 1 provides a detailed explanation of the ITU model.<br />

A latency comparison for a UMTS Release 99 voice call for two cases using<br />

MEO and GEO satellites is shown below.<br />

Figure 5 – End <strong>to</strong> end latency distribution for a voice call with <strong>O3b</strong> satellite backhaul<br />

www.o3bnetworks.com 7


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Figure 6 – End <strong>to</strong> end latency distribution for a voice call with GEO satellite backhaul.<br />

For <strong>O3b</strong>’s MEO constellation, the fiber return path adds 30ms of latency,<br />

representing the case of more than 5000km of optical fiber.<br />

The following diagram shows the resulting MOS scores for these two cases.<br />

Figure 7 – Voice Quality / MOS score degradation as a function of latency<br />

A side-by-side comparison of end-<strong>to</strong>-end latency values results in an MOS<br />

score of 4.4 for <strong>O3b</strong>’s MEO constellation and a MOS score of 3.8 for<br />

traditional GEO satellite.<br />

www.o3bnetworks.com 8


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Interactive user services<br />

The impact of latency on interactive services is more subjective. As the<br />

delay increases, the applications continue <strong>to</strong> function. However, the sense<br />

of immediacy and the usability degrades. At some point, the user becomes<br />

less <strong>to</strong>lerant of waiting for the response, eventually giving up and moving<br />

on <strong>to</strong> something more satisfying. A great deal of research has been done<br />

by companies whose revenues are impacted when users abandon their<br />

transactions.<br />

The importance of latency on web commerce was first showcased by Zona<br />

Research in 1999 with the popular “8-second rule”. Zona found that more<br />

than $4 billion e-commerce sales were lost due <strong>to</strong> poor site performance,<br />

which ultimately led <strong>to</strong> transaction abandonment. In a follow up study in<br />

2006, Jupiter Research concluded that the threshold had been reduced <strong>to</strong> 4<br />

seconds, as more users experience the performance of high-speed<br />

broadband.<br />

Google discovered that the number of web searches and ad revenue<br />

declined as they increased the number of user search results from 10 <strong>to</strong> 30.<br />

Further research found the result was due <strong>to</strong> the additional time required <strong>to</strong><br />

compute and present more results <strong>to</strong> the user. Increasing the results from<br />

10 <strong>to</strong> 30 required an additional 500ms <strong>to</strong> compute and resulted in a 25%<br />

drop in the number of searches done by users. Following this initial study,<br />

Google performed additional tests focused exclusively on the latency. They<br />

injected artificial delay in<strong>to</strong> the display of the search results. An increase in<br />

display time of 400ms actually decreased the number of searches per users<br />

by 0.44% <strong>to</strong> 0.76%. While these drops in usage appear small, they had a<br />

direct and meaningful impact on ad revenue.<br />

Similarly with Amazon: “We tried delaying the page in increments of<br />

100 milliseconds and found that even very small delays would result in<br />

substantial and costly drops in revenue,” said researcher Greg Linden.<br />

Linden provides a precise figure: -1% sales for 100ms or more latency.<br />

(Greg Linden in “Make Data Useful”, Data Mining course Stanford in 2006).<br />

Steve Souders from O’Reilly adds more examples in a blog posting<br />

http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html.<br />

In “Performance Related Changes and their User Impact,” Eric Schurman<br />

(Bing) explains that Bing researchers have conducted tests adding a static<br />

delay of 50 ms <strong>to</strong> 2 seconds <strong>to</strong> their servers. A negative impact on the Bing<br />

performance indica<strong>to</strong>rs resulted as soon as the delay increased by more<br />

than 50ms. The degradation noticed was linear.<br />

www.o3bnetworks.com 9


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Distinct<br />

Queries/User<br />

Query<br />

Refinement Revenue/User Any Clicks Satisfaction<br />

Time <strong>to</strong> Click<br />

(increase<br />

in ms)<br />

50ms – – – – – –<br />

200ms – – – -0.3% -0.4% 500<br />

500ms – -0.6% -1.2% -1.0% -0.9% 1200<br />

1000ms -0.7% -0.9% -2.8% -1.9% -1.6% 1900<br />

2000ms -1.8% -2.1% -4.3% -4.4% -3.8% 3100<br />

Figure 8 – Bing table of latency impact for user search service<br />

Phil Dixon (Shopzilla.com) presented results from the Shopzilla site<br />

redesign at the Velocity 2009 Conference. He illustrated that a reduction in<br />

page load time from 7 <strong>to</strong> 2 seconds resulted in a 25% increase in page<br />

views and a 7-12% increase in revenue.<br />

Below, a mobile subscriber is using a HSPA session over a satellite backhaul<br />

<strong>to</strong> access Internet data services.<br />

Figure 9 - End <strong>to</strong> end latency for data services using <strong>O3b</strong> backhaul<br />

Figure 10 - End <strong>to</strong> end latency data services using GEO satellite backhaul<br />

www.o3bnetworks.com 10


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

The increase in latency of 420ms between <strong>O3b</strong>’s MEO solution and a GEO<br />

satellite has a significant impact on interactive services.<br />

As demonstrated, revenue loss is a significant consequence of the quality<br />

degradation of a users’ experience caused by download delays. End users<br />

perceive latency increases of a few hundred milliseconds in a negative<br />

way, which translates in<strong>to</strong> a loss of business for providers and advertisers.<br />

Users are unaware whether the delay in response time is due <strong>to</strong> a slow<br />

server or a satellite link. The end result in both cases is the same: a poor<br />

user Quality of Experience.<br />

TCP in a nutshell<br />

The Internet uses the Transmission Control Pro<strong>to</strong>col (TCP) <strong>to</strong> provide end-<strong>to</strong>end<br />

services. In particular, TCP ensures the error free sequenced delivery of<br />

data transmitted from a source <strong>to</strong> a destination.<br />

Data is sent by the transmitter <strong>to</strong> the receiver in fragments called TCP<br />

segments. A maximum size is defined for the segments. The receiver will<br />

confirm the correct reception of sent TCP segments by acknowledging them<br />

(sending the transmitter a response “ACK message” with a correct<br />

sequence number). If an ACK message is not received or if it is not correct,<br />

the transmitter will return the message ensuring a reliable transfer. At the<br />

end of the session, it is correctly closed by exchange of FIN messages.<br />

The key fac<strong>to</strong>r in this context is that TCP will only send a limited amount of<br />

data before it needs an acknowledgement. The amount of data is governed<br />

by the TCP buffer size, which in Windows 7 is 64 kbytes. If 64 kbytes of<br />

data has been sent but the acknowledgements have not yet been received,<br />

TCP will wait for an acknowledgement before it sends another packet. This<br />

acknowledgement mechanism is what limits the transmission rate over<br />

high latency links.<br />

Non interactive data services<br />

The major complexity of TCP comes from its flow and congestion control<br />

mechanisms. The TCP flow control mechanism adjusts the TCP window size<br />

(the number of segments that can be sent and not yet be acknowledged)<br />

depending on the status of the end devices and congestion/latency on the<br />

link during the transfer.<br />

www.o3bnetworks.com 11


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Figure 11 – Messages exchanged for TCP connections.<br />

Each message is subject <strong>to</strong> transmission delay. For complex transmissions,<br />

such as web pages with multiple images and tables, the delay is<br />

cumulative. If a page has ten elements, a 500ms increase in latency will<br />

produce a 5 second increase in the page load time.<br />

TCP throughput and transfer time<br />

TCP throughput, and consequently file transfer duration, is a function of<br />

end-<strong>to</strong>-end latency, packet loss rate and maximum segment size (more<br />

details are available in Annex 2).<br />

− Throughput is increased by a maximum segment size increase.<br />

− Throughput is decreased by packet loss and/or latency increase.<br />

Figure 12 – Maximum TCP throughput decrease due <strong>to</strong> latency<br />

www.o3bnetworks.com 12


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Figure 12 shows that the maximum TCP throughput degrades rapidly as<br />

latency increases.<br />

The same illustration for an interactive service is considered: an HSPA<br />

access over satellite <strong>to</strong> Internet service (c.f. Figure 9 and Figure 10 for detail<br />

on each case).<br />

The maximum throughput for TCP Reno will be 2.1 Mbps for <strong>O3b</strong> and<br />

775 kbps for GEO satellite. This will be the maximum achievable rate for a<br />

TCP connection, such as a single user communicating with a server. Table 5<br />

estimates the transfer time for various media for both backhaul links for a<br />

single TCP stream.<br />

<strong>O3b</strong><br />

2 MB Song 10 seconds 28 seconds<br />

1.5GB Movie 1.66 Hours 4.5 Hours<br />

3.8GB HD Movie 4.25 Hours 11.4 Hours<br />

Table 1: Estimated transfer time comparison between <strong>O3b</strong> and GEO backhaul<br />

The subscriber QoE for these types of services is directly related <strong>to</strong> the<br />

download time. The lower latency of the MEO case results in a huge<br />

improvement in download times and subscriber QoE.<br />

GEO<br />

Non real time video streaming<br />

Video streaming was traditionally transported over UDP, but major web<br />

sites such as YouTube and DailyMotion now use either Adobe Flash Video or<br />

HTML5:<br />

− HTML5 is delivered using HTTP over TCP.<br />

− Adobe Flash Video can be delivered using:<br />

− FLW or SWF Files downloaded using a browser with HTTP over TCP<br />

− Progressive download over HTTP over TCP<br />

− Real Time Messaging Pro<strong>to</strong>col over TCP directly or through HTTP tunnel<br />

over TCP<br />

− HTTP Live Streaming format over TCP.<br />

With all the major providers of web video streaming now using TCP<br />

transport for video streaming, the latency impact on the degraded user<br />

experience will be exactly the same for Internet video streaming as it is for<br />

data file transfer.<br />

www.o3bnetworks.com 13


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Conclusion<br />

In the past, a boost in the subscriber data rate was all that was needed,<br />

and opera<strong>to</strong>rs could simply focus on increasing voice minutes and data<br />

volume. But as consumers become more sophisticated and networks<br />

become more complex with the introduction of mobile broadband, Quality<br />

of Experience has become an important indica<strong>to</strong>r of network performance.<br />

<strong>Latency</strong> is the critical fac<strong>to</strong>r in improving QoE across all services, including<br />

traditional voice services and the latest data services (i.e. interactive cloudbased<br />

applications and movie downloads).<br />

− Voice quality is measurably improved using the ITU model<br />

− The response of interactive applications is dramatically improved<br />

− File download times are reduced by over 60%<br />

The latency of <strong>O3b</strong>’s MEO constellation is substantially better than<br />

traditional GEO satellites. This has a direct improvement on QoE and<br />

provides a competitive advantage for opera<strong>to</strong>rs who are deploying modern<br />

mobile networks in rural areas.<br />

www.o3bnetworks.com 14


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Annexes<br />

Annex 1 Voice Codec, E-Model and MOS score<br />

The quality of voice services has been defined in several ITU standards,<br />

namely G.107, G.108 and G.109. Quality of the voice services is evaluated<br />

using a quality fac<strong>to</strong>r “R” ranging from 0 <strong>to</strong> 100.<br />

The R fac<strong>to</strong>r can be directly translated <strong>to</strong> a MOS score, as defined in the ITU<br />

G.107 recommendation. The mapping formula can be represented by the<br />

following curve.<br />

Figure 13: MOS Score and R Rating mapping (ITU G. 107 / P. 800)<br />

www.o3bnetworks.com 15


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

End <strong>to</strong> end latency, or so called “mouth <strong>to</strong> ear” has a strong impact on the<br />

voice quality, as illustrated by the following figure extracted from the G.114<br />

recommendation.<br />

Figure 14: End-<strong>to</strong>-end latency effect on R fac<strong>to</strong>r (ITU G.114)<br />

The higher the latency, the lower the voice quality. And as shown in the<br />

right side of the graph, voice quality is directly related <strong>to</strong> user’s QoE and<br />

overall satisfaction.<br />

www.o3bnetworks.com 16


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Finally, the absolute quality of the voice and latency impact is related <strong>to</strong><br />

the codec selected. Although in any case, higher latency means a decrease<br />

in quality. For <strong>Mobile</strong> backhaul, AMR-12.2 is widely used and corresponds<br />

<strong>to</strong> GSM-EFR codec.<br />

Ie= 0 5 7 10 15 19 19 20 26<br />

ms<br />

G.711 GSM-EFR<br />

G.726<br />

@32 G.729<br />

G.728<br />

@16<br />

~0 94 87<br />

G.723.1<br />

@6.3<br />

G.729A<br />

+VAD<br />

w/2% loss<br />

G.723.1<br />

@5.3<br />

G.723.1<br />

@<br />

6.3+VAD<br />

w/1% loss<br />

GSM-FR<br />

IS-54<br />

G.729A<br />

+VAD<br />

w/4% loss<br />

50 93 86 83 74 67<br />

100 92 87 85 82 77 73 73 72 66<br />

150 90 85 83 80 75 71 71 70 64<br />

200 87 82 80 77 72 68 68 67 61<br />

250 80 75 73 70 65 61 61 60 54<br />

300 74 69 67 64 59 55 55 54 48<br />

350 68 63 61 58 53 49 49 48 42<br />

400 63 58 56 53 48 44 44 43 37<br />

450 59 54 52 49 44 40 40 39 33<br />

Note 1 – R-values in this table have been calculated using the indicated values for Ie and T (T=Ta=Tr/2) along<br />

with the default values from Table 6 for all other parameters.<br />

Note 2 – Unless indicated otherwise, examples do not include packet loss or Voice Activity Detection (VAD).<br />

Note 3 – Blackened cells indicate combinations of delay and codec that are impossible <strong>to</strong> realize.<br />

Figure 15: R rating values for various voice codecs depending on End <strong>to</strong> end delay (ITU G. 108<br />

Annex B)<br />

Annex 2 TCP details and throughput calculation<br />

This annex gives more details on TCP Flow Control and TCP Congestion and<br />

Maximum TCP throughput and TCP transfer duration.<br />

Flow control<br />

Flow control is achieved using a feature called “sliding windows”.<br />

The receiver advertises the amount of data it can accept through time<br />

(generally related <strong>to</strong> buffering capacity). The transmitter is allowed<br />

<strong>to</strong> transmit data up <strong>to</strong> this advertised value until it receives an ACK<br />

message.<br />

www.o3bnetworks.com 17


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

For instance, the receiver advertised a maximum window size of 10<br />

segments. The transmitter will send the 10 segments (at a variable rate<br />

described in the congestion avoidance) and will then s<strong>to</strong>p until ACK is<br />

received. For each ACK (if window size stays constant) received, the<br />

transmitter may send another segment. The algorithm may advertise<br />

a variable window size depending on the actual state of the receiver<br />

(i.e. buffers filling or emptying), allowing it <strong>to</strong> transmit more or fewer<br />

segments and vary the actual throughput.<br />

Congestion Control<br />

Flow control enables the two end devices <strong>to</strong> regulate the transmission<br />

throughput, but it does not take in<strong>to</strong> account the status of the network links<br />

between them. Congestion control mechanisms are required <strong>to</strong> regulate<br />

the speed of the data transmission and the quality of the network link.<br />

Using a slow start mechanism, the sender begins <strong>to</strong> transmit TCP segments<br />

at a low rate, gradually increasing the number of segments simultaneously<br />

transmitted until the full window size is reached or congestion is detected.<br />

In case of congestion, an avoidance mechanism will drastically decrease<br />

the rate and initiate the step increase again, creating a saw-<strong>to</strong>oth effect.<br />

Various TCP flavors (Reno, Vegas, Cubic, Compound) have variations in the<br />

algorithm used <strong>to</strong> define the increasing and decreasing rate, based on a<br />

maximum segment size and/or queuing delay.<br />

Other optimizations include retransmission of selected segments and fast<br />

recovery <strong>to</strong> increase the transmission rate more quickly.<br />

TCP maximum throughput estimation<br />

TCP maximum throughput can be estimated using a formula based on TCP<br />

RENO (RFC2001) as described by Padhye et. al. in "Modeling TCP<br />

Throughput: a Simple Model and its Empirical Validation"<br />

The model used is the following one:<br />

⎛<br />

⎜Wmax<br />

B(<br />

p)<br />

≈ min ,<br />

⎜ RTT RTT<br />

⎝<br />

2bp<br />

3<br />

+ T min 1,<br />

0<br />

1<br />

( ) ( ) 3 bp<br />

2<br />

3 p 1+<br />

32 p ⎟⎟ 8<br />

⎠<br />

⎞<br />

www.o3bnetworks.com 18


<strong>Why</strong> <strong>Latency</strong> <strong>Matters</strong> <strong>to</strong> <strong>Mobile</strong> <strong>Backhaul</strong><br />

Where<br />

B(p): approximate model of TCP throughput [packet/s]<br />

Wmax: maximum window buffer size of receiver [packets]<br />

RTT: Round Trip Time [sec]<br />

b: number of packets that are acknowledged by a received ACK<br />

p: probability that a packet is lost<br />

T0: time-out for re-transmitting an unacknowledged (lost) packet [sec]<br />

RTT should take in<strong>to</strong> account the additional delay due <strong>to</strong> serial transmission<br />

of the packet (especially for low rate interfaces) and various TCP receive<br />

window sizes depending on the Operating System of the end-device.<br />

TCP transfer duration estimation<br />

Overall duration of file transfer can be approximated using the formula<br />

given by N. Dukkipati et al in “An argument for Increasing TCP’s Initial<br />

Congestion Window”<br />

S being the size of the file<br />

C being the bottleneck link-rate<br />

RTT being the two-way end-<strong>to</strong>-end latency<br />

being 1.5 if ACK are delayed of 2 else.<br />

Init_cwnd is the initial congestion windows, generally no more than three segments or about 4kB.<br />

The transfer time calculated does not take in<strong>to</strong> account packet loss<br />

(no packet loss) for simplicity. Packet loss further increases the duration of<br />

transfer due <strong>to</strong> retransmission of error packets and congestion control<br />

mechanisms.<br />

www.o3bnetworks.com 19

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!