We have connected a server-log system at a Gi interface of one of the Gateway GPRS Support Nodes (GGSNs) deployed by the European largest mobile career in France. We captured 1.763.516 adaptive streaming sessions. We logged exactly 92.595.115 HTTP GET requests. Each HTTP request corresponds to a chunk request. In our study, the considered GGSN serves 230 NodeB/BTS. This area is covered by 3G/HSPA/HSPA+ and 2G (EDGE) radio access networks and served 246.913 unique active client during the measurement period. The data collection was conducted over a period of 9 weeks from November 7t h 2012 until January 9t h 2013, involving mainly Apple HTTP Live Streaming (HLS) and Microsoft smooth streaming sessions (MSS). However, we limit our analysis to HLS sessions since they form more than 99% of HAS sessions in our dataset.
3.2.2 Content types
Currently, HTTP adaptive streaming is mainly used by Over-The-Top TV industries. Telecom companies, on their side, offer their subscribers the TV-service as a free value-added service. Our dataset mainly contains:
• Live TV sessions, where clients watch live TV sessions;
• Catch-up TV sessions, where TV content providers offer clients a catalog of videos previ- ously broadcasted in live.
In our dataset, we observe that around 76% of HAS sessions correspond to Live streaming sessions, while the rest corresponds to catch-up sessions. In the following we give insights on the requested domain names:
Domain names for Catch-up videos Figure 3.1(a) shows that the domain wat.tv is the most frequently requested domain name (25% of client requests) by mobile clients when requesting catch-up videos. wat.tv is a TV service provider that hosts catch-up videos of most of the local French-TV broadcasters. Other TV channels delegates to world wide CDNs to deliver their content on their behalf. For example: "vod-flash.canalplus.fr" cnames Akamai servers. 28
3.2. The Dataset overview wat.tv26% others28% orange.fr14% cdn.m6web.fr8% medias2.francetv.fr7% vod-flash.canalplus.fr4% videos.prismamediadigital.com3% download.od.tv-radio.com2% ncdn.adam.sfr.fr2% cdn.hexaglobe.net2% streamer1.medfon.com2% akamihd.net2%
(a) catch-up hosts
orange.fr: 75% others: 8% chunk-output-1.live.tv-radio.com: 7% m6-hls-live.adaptive.level3.net: 4% live02.netechangisme.com: 3% tf1hlsioslive-i.akamaihd.net: 2% vipwowza.yacast.net: 2% (b) live hosts
Figure 3.1: Hosting servers for both catch-up content videos and live channels
Other TV companies also play the role of content service providers (CSPs) by using their own streaming infrastructure such as the domain cdn.m6web.fr.
Domain names for Live sessions Figure 3.1(b) shows that 75% of live HAS sessions are
streamed from servers with domain name orange.fr: This means that subscribers usually access live TV channels through the Orange application. Orange provides streaming servers to enable local TV channels to broadcast their videos to mobile clients. The domain chunk-
output-1.live.tv-radio.com is the second most requested domain (7% of client requests) which
cnames Akamai servers.
3.2.3 Data processing
We identify a session through the first HTTP-GET request of the first chunk for which the URL address ends with either a .ts for a HLS stream, or with a .ism for a MSS stream. Each HAS session corresponds to the set of chunks sent to a client over the TCP connection. Our logging system captures all packet headers of HAS streams which contain useful information, such as the packet size and sequence number. All information is aggregated per TCP connection and exported into a database, from where they are analyzed. Each persistent-TCP connection corresponds to one downloaded video segment. This means that the number of downloaded chunks during one session is equal to the number of persistent TCP connections established between the server side and the end-user over time. The encoding scheme of the different profiles may differ among content videos since each of the TV service providers may define
Chapter 3. HTTP adaptive streaming in mobile networks : characteristics and caching opportunities
his own range of encoding profiles.
Figure 3.2(a) shows the distribution of the encoding profiles (bi ∈[1..N ]) where N represents the number of profiles defined for each catch-up content within the data-set. We observe that most of the defined encoding profiles are below 1000 kbps.
Nbr of profiles 1 2 3 4 5 6 7 8
percentage 17% 22% 32% 13% 7% 4% 4% 1%
Table 3.1: Breakdown of the number of proposed profiles per HAS content
In Table 3.1, we show the breakdown of number of the available profiles for catch-up TV videos requested during the measurement period. In Figure 3.2(b), we estimate the average distance in kbps between the encoding profiles defined for each catch-up video:
d i st ance = PN −1 i =2 (bi +1− bi) N = bN− b2 N
We observe that in 95% of catch-up videos, the average difference between the encoding profiles is higher than 100 kbps. For this reason and since we are interested in aggregated statistics to draw conclusions about HAS characteristics, we define a scale of 8 different profiles (see Table 3.2) that will be used to map each requested chunk in each HAS session to the appropriate profile (P).
0 500 1000 1500 2000 2500 3000 0 10 20 30 40 50 60 70 80 90 100 kbps
catch-up video index (Normalized) Encoding profiles
(a) encoding profiles
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 100 200 300 400 500 600 700 800 proportion distance (kbps) Distance
(b) distance between profiles
Figure 3.2: Profiles presentation used for catch-up contents
We assume that the encoding rate is equal to the volume of data contained in the packet payloads per chunk and divided by the chunk’s duration. The measurement of the encoding rate of each chunk is initiated the time we capture the HTTP-200 response from the hosting 30
3.2. The Dataset overview
server. When the download finishes, we map the encoding rate to the corresponding profile.
Profile i Encoding bitrate (kbps) Profile 0 (P0) < 50 Profile 1 (P1) [50-150) Profile 2 (P2) [150-280) Profile 3 (P3) [280-420) Profile 4 (P4) [420-600) Profile 5 (P5) [600-1000) Profile 6 (P6) [1000-2000) Profile 7 (P7) ≥ 2000
Table 3.2: Profiles settings
3.2.4 Fields description
The dataset consists of hundreds of thousands of rows. A new row is added each time a user switches to a different encoding rate. For each HAS session and during each transition, we record the timestamp and the newly visited profile (Pi).
In the following we describe the fields we report in each row:
Sessi oni d
• Session Start (in timestamp).
• Requested URL.
• Cumulative number of requested chunks in sessi oni d.
• Current profile Pj²[0..7].
• Next profile Pk²[0..7],k6=j (when a bitrate-switching happens).
• Cumulative number of requested chunks within profile Pj²[0..7].
• Cumulative Bytes downloaded in profile Pj²[0..7].
Chapter 3. HTTP adaptive streaming in mobile networks : characteristics and caching opportunities