Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | About Us | List of Contributors | Become a Contributor |  How to Advertise  
 
  KT SK Telecom LG U+ Korean Vendors Network Architectures  
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung  
 
CHANNELS HFRFRONTHAUL NetvisionMPTCP Springwave1588 PTP   Korea Communication Review      
Do Google Global Caches (GGCs) serve YouTube live traffic as well, or not?
November 20, 2013 | By Ricky Yang and Dr. Harrison J. Son (tech@netmanias.com)
Online viewer:
Comments (1)
14

Google Global Caches (GGCs) have already been deployed in many telecom operators' data centers around the world, caching YouTube video files like Psy's Gangnam Style for the local users. This allows people around the globe to watch Psy singing and dancing without buffering through their local GGCs. Korean operators like SK Telecom, LG U+ and KINX have also made the same move in February 2012.

 

These days, many people like to watch not only VoDs, but also live broadcasts like sports games at YouTube.     


Then, what if GGCs do not serve this ever-increasing live traffic? What if they do not support application-level multicast?  
 
For example, a lot of Major League baseball fans in Korea love to watch games LIVE, especially when Hyun-Jin Ryu pitches. If they all watch his game LIVE through YouTube, there will be a massive influx of traffic into Korean operators' networks from Google data centers located outside of Korea. Since a 720p video requires about 3 Mbps, it will take 300 Gbps (3 Mbps x 100,000) throughout the game for 100,000 users to watch the game (Well, even KT, the No. 1 operator in Korea, has only 355 Gbps of capacity for international peering, and SK SK Telecom and LG U+ have less than that). 


So, it would be practically impossible for the users to use the Internet properly. Of course watching the game will be quite unpleasant because of extreme buffering throughout the game.  


Only if GGCs in a local operator's network serve this live traffic, what it takes to serve 100,000 local users will be a single streaming from a Google data center abroad to local GGCs.  Once streamed into a local GGC, the content can be simply multicasted by the GGC to the users. Only 3 Mbps used, so no more bottleneck effect.
  
 

We conducted some tests to check whether GGCs serve live traffic or not, and if they do, how contents are delivered.  

 

 ※ For more information about GGCs, please refer to our previous posts, "Who wins? - OTT Cache vs. Operator Cache" and "Google Global Cache (GGC) Operations for YouTube (Part 2. LG U+)". For information about YouTube's live streaming, see "YouTube's Live TV Streaming in Mobile Devices - HLS & Adaptive".

 

 

GGC Call Flow: Live

 

The figure below illustrates how a GGC works as a user (using Galaxy S4 with LTE-A through SK Telecom LTE-A network) runs a YouTube APP to access YouTube, and watches SPOTV Live channel. 

 

In the figure above, the user runs YouTube on his mobile device and selects SPOTV, a live channel. The device sends the YouTube server a request for a Variant Playlist, and receives a Variant Playlist file as follows. Now from the list, we can see SPOTV Live provides six different quality levels (profiles) ranging from 64Kbps (128x72) to 2.8Mbps (1280x720). 

 

You can download "Manifest(hls_variant).m3u8" file.


From the list, the device selects the file with the lowest video quality (i.e. Profile 1: itag=151, 64Kbps, 128x72), and sends the YouTube server a message requesting a Playlist for the selected video quality. The device then receives a Playlist as follows:

 

You can download "Manifest(hls_playlist).m3u8file.


In the list that the YouTube server sends are five URLs where each chunk is located. We can tell from the URI parameters that the chunks are very small, all about 37 KB (obviously because these are for 64 Kbps).    

 

The device sends a request for the first chunk file (348760). When the YouTube server receives this HTTP GET message, it knows that the message is from a subscriber of SK Telecom which has employed GGCs in its network (because the device's IP is within the IP range of SK Telecom). So, the server sends a 302 Found message, redirecting the HTTP GET message to a GGC in SK Telecom's network.

 

 

Now, the device sends a chunk request message to the GGC server in SK Telecom's network, as redirected. After receiving the first chunk, the device knows that the current network conditions are pretty good. So, it wants to go for the highest quality in the Variant Playlist  (i.e. Profile 6: 2.8 Mbps, the highest in our actual measurement), but has no Playlist (chunk URL list) for Profile 6. The device hence sends the YouTube server a message requesting one. The device then receives a Playlist as follows:

 

You can download "(itag 95)Manifest(hls_variant).m3u8file.


 

In the list that the YouTube server sends are five URLs where each chunk of the video (in 2.8 Mbps) is located. We can tell from the URI parameters that the chunks are very big, all about 1.6 MB (obviously because these are for 2.8 Mbps).    

 

The device sends a request for the first chunk file (348760). When the YouTube server receives this HTTP GET message, again it redirects the message to the GGC in SK Telecom's network.

 

[Chunk File] 
You can download "1.tsfile.

 

After the device receives the first four chunks (of Profile 6) in a row, it pauses for about five seconds. Then after five seconds, it resumes requesting for a Playlist file (sliding Windows???) and receives chunks about every five seconds.   

 

In conclusion, yes, we confirmed GGCs served live traffic. To be more specific and technical, the YouTube server redirected the messages requesting chunks (HTTP GET) from a user to the GGC located in the operator network that the user is subscribing to. The other thing we found was that the video chunk files were delivered to the device through the GGC, whereas Manifest files (Variant Playlist and Playlist) were not  handled by the GGC. 


Video chunk files are downloaded from GGCs located in operator networks that each user is subscribing to (e.g. SK Telecom: r4---sn-n3hvcpax-bh2.c.youtube.com or LG U+: r4---sn-ab02a0n-jwwl.c.youtube.com). However, there is only one source for Manifest files, YouTube server (www.youtube.com). Users, no matter where they are, have to access the server to get the files.  


So, do GGCs server live traffic as well? Yes, they do!

 

 

<Appendix 1> Wireshark Capture Image

 

 

<Appendix 2> Media information of the received chunk file 

 

nuscumaan119@gmail.com 2017-05-21 14:21:56

we are hormuud telecom somalia we got two servers 10days ago ,there for hormuud want to install the servers data center .

hormuud needs google support in order to install the servers ,google support configaration and instraction 

 

pls contact us soon 

phone 252 615558882 abdiweli ahmed siyad (iSP Manager) Abdiweli.siyad@hormuud.com,Nuscumaan119@gmail,com 

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
banner

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 47,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

    (New contents, Korea ICT News)

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

 

     
         
     

 

     
     

KOREA ICT RESEARCH REPORT

SK Telecom's Massive IoT Deployment through LoRa for Small Things

 

 

SK Telecom commercialized the world’s first nationwide LoRa-based, IoT dedicated network in the end of June. This report will discuss how well SK Telecom is poised for the emerging IoST sector, and where it is heading.

 

     
     

 

     
         
     

 

     
         
     

 

     
     

How to contribute articles to Netmanias!

We always welcome contributed articles. Share your expertise and inspire others!

     
     

 

     
         
     

 

 

View All (706)
4.5G (1) 5G (62) AI (2) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (4) Big Data (2) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) China Mobile (2) Cloud (2) CoMP (6) Connected Car (4) DHCP (5) Ericsson (1) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (20) IoST (3) IoT (47) KT (40) Korea (18) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LTE (73) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (19) Network Slicing (4) New Radio (5) Nokia (1) OSPF (2) OTT (3) PCRF (1) QoS (3) RCS (3) SD-WAN (14) SDN/NFV (54) SK Broadband (2) SK Telecom (33) Samsung (5) Security (11) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (24) YouTube (6) eICIC (1) eMBMS (1) iBeacon (1)
Password confirmation
Please enter your registered comment password.
Password