Product Description
The Cisco® Mobile
Video Gateway is the central component of the Cisco Mobile Videoscape.
It employs a number of video optimization techniques that enable
mobile operators with 2.5G, 3G, and 4G wireless data networks to
enhance the video experience for their subscribers while optimizing
the performance of video content transmission through the mobile
network.
Platform Requirements
The Mobile Video
Gateway software runs on a Cisco ASR 5000 chassis functioning as
a mobile gateway, enabling the ASR 5000 to function as an integrated
Mobile Video Gateway. In this software release, the Mobile Video
Gateway software can be integrated with the Cisco P-GW (Packet Data
Network Gateway), the Cisco GGSN (Gateway GPRS Support Node), and
the Cisco HA (Home Agent). The Mobile Video Gateway software runs
on the StarOS operating system. The chassis can be configured with
a variety of components to meet specific network deployment requirements.
For additional information, refer to the installation guide for
the chassis and/or contact your Cisco account representative.
Licenses
The Mobile Video
Gateway is a licensed Cisco product. Separate session and feature
licenses may be required. Contact your Cisco account representative
for detailed information on specific licensing requirements. For
information on installing and verifying licenses, refer to the "Managing
License Keys" section of the "Software Management Operations" chapter
in the System Administration Guide.
Summary of Mobile
Video Gateway Features and Functions
The following figure
shows the Mobile Video Gateway features and functions.
Figure 1. Mobile
Video Gateway Features and Functions
The Mobile Video Gateway
features and functions include:
- DPI (Deep Packet Inspection)
to identify subscriber requests for video vs. non-video content
-
Transparent
video re-addressing to the Cisco CAE (Content Adaptation Engine)
for retrieval of optimized video content
- CAE load balancing of
HTTP video requests among the CAEs in the server cluster
- Video optimization
policy control for tiered subscriber services
- Video white-listing,
which excludes certain video clips from video optimization
- Video pacing for “just
in time” video downloading
- TCP link monitoring
- Dynamically-enabled
TCP proxy
- Traffic performance
optimization
- N+1 redundancy
support
- SNMP traps and alarms
(threshold crossing alerts)
- Mobile video statistics
- Bulk statistics for
mobile video
The Cisco CAE is an
optional component of the Cisco Mobile Videoscape. It runs on the Cisco
UCS (Unified Computing System) platform and functions in a UCS server
cluster to bring additional video optimization capabilities to the
Mobile Videoscape. For information about the features and functions
of the Cisco CAE, see the CAE product documentation.
Network Deployments
and Interfaces
This section shows
the Mobile Video Gateway as it functions in various wireless networks.
The section also includes descriptions of its logical network interfaces.
The Mobile Video
Gateway in an E-UTRAN/EPC Network
In this software
release, the Mobile Video Gateway software can be integrated with
the Cisco P-GW in an E-UTRAN/EPC (Evolved UTRAN/Evolved
Packet Core) network.
In the EPC (Evolved
Packet Core), the Cisco P-GW (Packet Data Network Gateway) is the
network node that terminates the SGi interface towards the PDN (Packet Data
Network). The P-GW provides connectivity to external PDNs for the
subscriber UEs by being the point of exit and entry of traffic for
the UEs. A subscriber UE may have simultaneous connectivity with
more than one P-GW for accessing multiple PDNs. The P-GW performs
policy enforcement, packet filtering for each user, charging support,
lawful interception, and packet screening.
The following figure
shows the integrated Mobile Video Gateway and P-GW in an E-UTRAN/EPC
network.
Figure 2. Mobile Video Gateway
in an E-UTRAN/EPC Network
For more information
about the Cisco P-GW and its connectivity to related network elements,
see the Packet Data
Network Gateway Administration Guide.
The Mobile Video
Gateway in a GPRS/UMTS Network
In this software
release, the Mobile Video Gateway software can be integrated with
a GGSN (Gateway GPRS Support Node) in a GPRS/UMTS (General
Packet Radio Service/Universal Mobile Telecommunications
System) network.
The GGSN works in
conjunction with SGSNs (Serving GPRS Support Nodes) in the network
to perform the following functions:
- Establish and maintain
subscriber IP (Internet Protocol) or PPP (Point-to-Point Protocol)
type PDP (Packet Data Protocol) contexts originated by either the
MS (Mobile Station) or the network.
- Provide CDRs (Call
Detail Records) to the CS (Charging Gateway), also known as the
CGF (Charging Gateway Function).
- Route data traffic
between the subscriber’s MS and a PDN (Packet Data Network)
such as the Internet or an intranet.
PDNs are associated
with APNs (Access Point Names) configured on the system. Each APN consists
of a set of parameters that dictate how subscriber authentication
and IP address assignment is to be handled for that APN.
The following figure
shows the integrated Mobile Video Gateway and GGSN in a GPRS/UMTS
network.
Figure 3. Mobile Video Gateway
in a GPRS/UMTS Network
For more information
about the Cisco GGSN and its connectivity to related network elements,
see the Gateway GPRS
Support Node Administration Guide.
The Mobile Video
Gateway in a CDMA2000 Network
In CDMA2000
networks, the Cisco HA (Home Agent) enables subscribers to be served
by their home network even when their mobile devices are not attached
to their home network. The Cisco HA performs this function through
interaction with the Cisco PDSN/FA (Packet Data Serving
Node/Foreign Agent). The PDSN/FA provides the
packet processing and redirection to the subscriber's home network
via the HA. The following figure shows the integrated Mobile Video
Gateway and HA with a PDSN/FA in a CDMA2000 network.
Figure 4. Mobile Video Gateway
in a CDMA2000 Network
For more information
about the Cisco HA and its connectivity to related network elements, see
the Home Agent Administration
Guide.
Mobile Video Gateway
Logical Network Interfaces
The following
figure shows the logical network interfaces on the Mobile Video
Gateway.
Figure 5. Logical Network
Interfaces on the Mobile Video Gateway
The following table
provides descriptions of the logical network interfaces on the Mobile Video
Gateway. The Mobile Video Gateway also supports the logical network
interfaces of the Cisco P-GW and Cisco HA when integrated with those
products.
Table 1. Logical Network Interfaces
on the Mobile Video Gateway
Interface |
Description |
PCRF Interface
|
The Mobile Video Gateway
can use the Gx interface to connect to a PCRF (Policy and Charging
Rules Function) server to receive subscriber policy information and
charging rules.
|
RADIUS Interface
|
The Mobile Video Gateway
uses a RADIUS interface to exchange signaling messages with the
external RADIUS server.
|
Video Origin Server Interface
|
The Mobile Video Gateway
uses the Gi or SGi interface to connect to the video origin servers
in the network. The Mobile Video Gateway also uses the Gi or SGi interface
to connect to non-video origin servers.
|
CAE Interface
|
The Mobile Video Gateway
uses a Cisco-enhanced HTTP interface called the Ua interface to
connect to the Cisco CAE. The Cisco CAE is an optional component of
the Cisco Mobile Videoscape.
|
Features and Functionality
The following
features and functions are supported on the Mobile Video Gateway:
Deep Packet Inspection
The Mobile
Video Gateway performs DPI (Deep Packet Inspection) of HTTP traffic
to identify video vs. non-video traffic based on configured Active
Charging Service rule definitions. An Active Charging Service is
a component of the Enhanced Charging Services on the Cisco ASR 5000.
While SPI (Shallow
Packet Inspection) examines IP headers (Layer 3) and UDP and TCP
headers (Layer 4) for an Active Charging Service, DPI on the Mobile
Video Gateway examines URI information (Layer 7) for HTTP message
information to identify video vs. non-video content based on configured
rules. The following information is used for DPI:
- HTTP Request headers
for matching hostnames.
- HTTP Request URLs of
the destination websites to identify the video content OSs (Origin Servers).
- HTTP Response headers
for matching the content type.
For more information
about Enhanced Charging Services on the ASR 5000, see the Enhanced Charging Services
Administration Guide.
Transparent Video
Re-addressing
The Mobile
Video Gateway can re-address HTTP video requests intended for video
content OSs toward the Cisco CAE for retrieval of optimized video
content. The Cisco CAE is an optional component of the Cisco Mobile
Videoscape. It functions in a video server cluster to bring additional
optimization capabilities to the Mobile Videoscape.
IMPORTANT:
The transparent video
re-addressing feature is not fully qualified and is not supported
for field deployment. It is available for lab demo/lab
trial only.
The transparent video
re-addressing feature works in conjunction with the dynamic TCP proxy
feature to send video requests to the CAE cluster without using
HTTP redirection, so that the re-addressing to the CAEs remains
transparent to the video clients on the subscriber UEs.
For configuration instructions
and a sample configuration, see Chapter 2.
HTTP X-Header Use
in Transparent Video Re-addressing
To enable the
CAE to reach an OS to retrieve selected video clips for adaptation,
the Mobile Video Gateway inserts the Layer 3 destination IP address
and Layer 4 destination port number of the OS in a proprietary HTTP
x-header in the HTTP video request to the CAE. The CAE uses the
information to recreate the Layer 3 and 4 headers to connect to
the OS.
The following figure
shows how the HTTP x-header is used in transparent video re-addressing
to the CAE. In this example, in the original HTTP request from the
subscriber UE, the source IP address is 10.1.1.233 and the destination
IP address is 200.2.3.4. The destination TCP port is 8080.
Figure 6. HTTP X-Header Use
in Transparent Video Re-addressing
Mobile Video Gateway
to the CAE
When sending
HTTP video requests to the CAE for retrieval of optimized video
content, the Mobile Video Gateway inserts the following x-headers:
-
x-forwarded-dest-addr-port: The
IPv4 destination address and TCP port number of the OS.
- x-adaptation-profile-index: The
index number of the video quality profile for the CAE to use to
select the level of video quality for adaptation.
CAE to the OS
When sending
HTTP video requests to the OS for video content, the CAE removes
the following x-headers:
-
x-forwarded-dest-addr-port: The
IPv4 destination address and TCP port number of the OS.
- x-adaptation-profile-index: The
index number of the video quality profile for the CAE to use to
select the level of video quality for adaptation.
When sending HTTP video
requests to the OS for video content, the CAE inserts the following
x-header: x-forwarded-for: The
IPv4 address of the subscriber UE.
CAE Load Balancing
The optional
Cisco CAE runs on the Cisco UCS platform and functions in a UCS
server cluster to bring additional optimization capabilities to
the Mobile Videoscape. The Mobile Video Gateway interfaces directly
with each CAE in the server cluster. The CAE server cluster can
serve multiple Mobile Video Gateways simultaneously. In turn, each
Mobile Video Gateway is able to support up to 64 CAEs in the server
cluster.
IMPORTANT:
The CAE load balancing
feature is not fully qualified and is not supported for field deployment.
It is available for lab demo/lab trial only.
The following figure
shows the CAE in a server cluster.
Figure 7. CAE Server Cluster
The CAE load balancing
feature enables the Mobile Video Gateway to distribute HTTP video
requests from the subscriber UEs equally among the CAEs in the server
cluster.
The CAE load balancing
feature is configured and enabled in the context containing the interface
to the CAEs, typically the destination context, via system CLI commands.
During configuration, each CAE in the server cluster gets defined
in a CAE group representing the cluster. Each context on the Mobile
Video Gateway can have one and only one CAE group. There can be
multiple contexts that contain a CAE group, but there is a system
limit of 64 CAEs supported on a Mobile Video Gateway.
In addition to the
CAE group configuration above, the CAE load balancing feature gets configured
as part of an Active Charging Service, which is a component of the
Enhanced Charging Services on the ASR 5000. The feature is configured
by creating an Active Charging Service for the Mobile Video Gateway,
specifying charging and routing rule definitions, and then creating
a charging action for CAE re-addressing, which enables video optimization
and CAE load balancing for the CAEs in the CAE group.
For configuration
instructions and a sample configuration, see Chapter 2.
CAE Load Balancer
Function
When the Mobile
Video Gateway identifies a video request during DPI, the CAE load
balancer function performs three main operations, as follows:
- It performs CAE load
balancing using a round-robin selection of the next available CAE
to service the video request.
- It ensures that multiple
video flows for a subscriber are serviced by the same CAE once a CAE
is selected. This is required for some mobile devices such as the
Apple® iPhone®, which can serve video clips using
multiple TCP sessions, such as when an iPhone user skips forward
in the middle of playback and the iPhone closes the existing TCP
session and starts a new one.
- It maintains health-check
monitoring for each of the configured CAEs in the server cluster.
If a CAE is currently down, the load balancer function prevents
video requests from being sent to the down CAE until is up and available
again. All of the CAEs in a CAE group optimize the same video content,
so the Mobile Video Gateway can direct the video request to any
of the other CAEs until the down CAE is up and available again.
CAE Health-Check
Monitoring Function
The CAE health-check
monitoring function is part of the CAE load balancing feature. It
triggers a health-check request sent to the CAEs based on a configurable
keep-alive timer. If a CAE does not respond, and after a configurable
number of retries and timeouts, it marks the state of the CAE as
Down. It also generates an SNMP Server-State-Down trap message,
indicating that the CAE is down and unavailable. When a configurable
dead-time timer expires, it sends another health-check request to
the down CAE, and if the CAE sends a positive response indicating
that it is back up, it marks the state of the CAE as Up and generates
an SNMP Server-State-Up trap message, indicating that the CAE is
back up and available.
Video Optimization
Policy Control
The video optimization
policy control feature provides the necessary information for the
Mobile Video Gateway to select the highest quality video content
for a subscriber, based on information received from a PCRF or RADIUS
server, or based on the subscriber’s policy profile configured
on the Mobile Video Gateway. The feature enables mobile operators
to offer tiered video services to their subscribers with different
levels of service (Gold, Silver, and Bronze levels, for example).
A video policy defines
a subscriber’s entitlement to the video content provided
by the Mobile Video Gateway. A video policy contains various video-specific attributes,
including the subscriber’s video QoE (Quality of Experience).
In this software release,
the video policy includes a CLI charging-action command
option for specifying a suggested maximum bit rate value for video.
This value, specified in bits per second (bps), is used by two of
the video optimization modules on the Mobile Video Gateway, the
video pacing module and the video transrater module.
The following figure
shows the flow of information for the video optimization policy
control feature on the Mobile Video Gateway.
Figure 8. Video Optimization
Policy Control System Flow
Figure 9. Video Optimization
Policy Control System Flow
Functional Overview
The video optimization
policy control feature assigns a video policy to a subscriber via
one of the following methods:
-
PCRF via the Gx interface: Acting
as a RADIUS endpoint, the Mobile Video Gateway can obtain the video
policy for a subscriber using the Gx interface to the PCRF. With
this method, the Charging-Rule-Name attribute received in the Charging-Rule-Install
AVP in the CCA-I message contains a rule definition name that maps
to the video policy. This rule definition is part of the rulebase
assigned to the subscriber. The Mobile Video Gateway can assign
the rulebase to the subscriber through a static configuration at
the subscriber or APN level, or obtained from the RADIUS server
in an Access-Accept message.Alternately, the Mobile
Video Gateway can be configured to obtain the rulebase name itself from
the PCRF via the Charging-RuleBase AVP.
-
RADIUS Server via the
RADIUS interface: In the absence of a Gx interface, the Mobile
Video Gateway can obtain the video policy from the RADIUS server
through the Access-Accept message. With this method, the Mobile
Video Gateway applies the RuleBase-Name AVP in the Access-Accept
message to the subscriber, and one of the rule definitions in the configured
rulebase selected in this manner maps to the video policy. Note
that one rulebase gets associated with one level of subscriber entitlement
(GOLD_RULEBASE, for example).
-
Static assignment at
the subscriber or APN level: The Mobile Video Gateway can assign
a video policy by assigning a rulebase at the subscriber or APN
level, so that one of the rule definitions in the configured rulebase
maps to the video policy. As in the RADIUS server method, one rulebase
gets associated with one level of subscriber entitlement.
The video optimization
policy control feature gets configured as part of an Active Charging Service,
which is a component of the Enhanced Charging Services on the ASR
5000. The feature is configured by creating an Active Charging Service
for the Mobile Video Gateway, specifying charging and routing rule
definitions, and then creating charging actions for the tiered video service
levels. Within each service level charging action, the suggested
maximum video bit rate is specified.
During configuration,
a rulebase is defined for each subscriber or APN and contains multiple
rule definitions. When obtaining the video policy from the PCRF
via the Gx interface, and when obtaining the video policy via the
Charging-Rule-Install AVP, the Mobile Video Gateway enables a particular
rule definition when a rule definition name matches the received Charging-Rule-Name
attribute. This is achieved by using the dynamic-only option
in the action
priority command when configuring the rulebases. When
obtaining the video policy via the RuleBase-Name AVP, note that
there can be one and only one rule definition and its corresponding
charging action associated with a video policy.
When a rule definition
gets matched, the Mobile Video Gateway applies the corresponding charging
action. For example, when the VIDEO_GOLD rule definition
is matched, the Mobile Video Gateway applies the corresponding GOLD_CHARGING_ACTION.
This charging action determines the video policy for the subscriber.
If no rule definitions get matched, the Mobile Video Gateway uses
the default value for the suggested maximum bit rate.
For configuration instructions
and sample configurations, see Chapter 2. For detailed instructions
for configuring the Gx interface on the Cisco P-GW, see the Packet Data Network
Gateway Administration Guide.
Video Optimization
Policy Control Call Flows
This section includes
call flows of the Mobile Video Gateway obtaining the video policy
for a subscriber in two ways:
- From the PCRF over
a Gx interface as it functions as a RADIUS endpoint.
- From the RADIUS server
over a RADIUS interface as it functions as a RADIUS proxy.
The following figure
shows the Mobile Video Gateway functioning as a RADIUS endpoint
obtaining the video policy via the PCRF over a Gx interface.
Figure 10. Mobile Video Gateway
as a RADIUS Endpoint Obtaining the Video Policy via the PCRF
The following figure
shows the Mobile Video Gateway functioning as a RADIUS proxy obtaining
the video policy via the RADIUS server over a RADIUS interface.
Figure 11. Mobile Video Gateway
as a RADIUS Proxy Obtaining the Video Policy via the RADIUS Server
Video White-listing
Certain video
clips can be excluded from video optimization. This is referred
to as white-listing. The video white-listing feature can either
be configured using empty charging actions that match the white-listed
URLs, or using DPI rule definitions that do not match the white-listed
URLs.
For configuration instructions,
see Chapter 2.
Video Pacing
The video pacing
feature enables mobile operators to limit the download speed of
over-the-top, progressive download video (video clips provided to
subscribers via HTTP downloads over TCP flows) so that their subscribers
download just enough video content in time for smooth playback.
By limiting the bit rate of progressive downloads to the actual
encoded bit rate of each video clip, mobile operators can significantly
reduce their air interface bandwidth usage.
IMPORTANT:
The video pacing feature
has been qualified to run on the ASR 5500 for the Mobile Video Gateway
integrated with the Cisco P-GW (Packet Data Network Gateway) and
the Cisco HA (Home Agent).
The video pacing feature
determines the optimal download speed for a video by calculating the
average bit rate of the video and then, after allowing an initial
burst to fill a video buffer on the subscriber UE before playback
begins, by enforcing the average bit rate for the duration of the video
download.
The video pacing feature
is an Active Charging Service, which is a component of the Enhanced
Charging Services on the ASR 5000. The video pacing feature is configured
using the system CLI commands by creating an Active Charging Service
for video pacing, and then specifying charging and routing rule
definitions.
For configuration instructions
and a sample configuration, see Chapter 2.
Video Pacing Operation
The video pacing
feature operates as follows:
Assume a video-encoding
bit rate R and a video playback start time of 0. At time t, the
subscriber UE needs to receive Rt bytes of video content just in
time for smooth playback. To address fluctuations over the wireless
channel, assume that a video buffer is kept on the subscriber UE
to accommodate these fluctuations. Assume this buffer size is the standard
burst size b.
Because many software
media players do not begin playback until a certain amount of video data
has been buffered, the video pacing feature allows an initial burst
of data, so in addition to the standard burst size b, assume an
initial burst size B. This initial burst size is configured based
on time duration (as t seconds of video data) and calculated for
each video flow based on the determined video bit rate. The video
pacing feature allows this initial burst just once, before the video
begins playing.
The video pacing feature
employs a token bucket algorithm to enforce the permitted video data
bytes. When a video download begins, for any given time t, the token
bucket algorithm disallows more than (Rt + B + b)
data bytes, which is the maximum allowed data bytes. After the initial
burst B is completed, the video pacing feature disallows more than
(Rt + b) data bytes, and the optimal “just in
time” video download rate is achieved.
The following figures
show video pacing during good and bad channel conditions.
Figure 12. Video Pacing During
Good Channel Conditions
In the figure above showing
good channel conditions, notice that there is a small difference between
the ideal pacing rate (the black line on top) and the actual downloaded
video bytes (the red line). This difference is due to network delay,
and when the pacing feature begins to take action, the video content
OS or Cisco CAE does not respond immediately. Even with this delay, because
the video pacing feature allows the standard burst size b, the download
rate never falls below the blue line representing the minimum video
data required for smooth video playback. Also notice that the media
player needs B (not 0) bytes of data for the video to start playing.
This is why the video pacing feature allows a bigger initial burst
of data (B + b), and then begins enforcing the burst size
b until the completion of the download.
Figure 13. Video Pacing During
Bad Channel Conditions
In the figure above
showing bad channel conditions, when channel conditions worsen,
the actual downloaded video bytes cannot keep up with the ideal
pacing rate. Nonetheless, if the channel recovers in time, the download
rate is still above the blue line representing the minimum data
required for smooth playback, and video pacing continues to maintain
b bytes of data above this lower limit.
Video Pacing Functions
The video pacing
feature includes four main functional components, as follows:
-
Pacing Start Trigger: The
pacing start trigger is part of the Active Charging Service for
video pacing. When a rule definition in the Active Charging Service
identifies a packet flow as a video flow, and the corresponding
charging action for video pacing is enabled, the pacing start trigger
invokes video pacing enforcement for the video flow. It sets the
video bit rate and initial burst size from the subscriber policy,
which is configured for subscribers in the source context as part
of the active charging rulebase. It then becomes dormant.Some mobile devices such
as the Apple iPhone can serve video clips using multiple TCP sessions,
such as when an iPhone user skips forward in the middle of playback
and the iPhone closes the existing TCP session and starts a new
one. When multiple TCP sessions are used to download the same video,
the pacing start trigger gets invoked once per video flow, and the
video pacing feature correlates these flows to the same video object
to continue pacing enforcement from where the last TCP flow left
off. When multiple TCP flows are used to download different videos,
video pacing is performed independently per flow.
-
Video Pacing Enforcement: After
the initial burst of video content, the video pacing enforcement
function sets the optimal video download rate for the incoming downlink packets
using a token bucket algorithm. Video pacing occurs based on the
settings configured via CLI command options.
-
Video Rate Determination: The
video rate determination function is a software algorithm that examines
the initial HTTP RESPONSE packets and video metadata packets to determine
the encoded bit rate of the video. It examines the HTTP RESPONSE
headers to determine the content length of the video in total bytes
as well as the total video playback duration, and then calculates
the average video bit rate as: (Content length/Video playback duration).
It then triggers the video pacing enforcement function to enforce
the new average bit rate when the next downlink packet is received.
-
CLI Command Options: The
video pacing feature includes a set of CLI command options for the
Active Charging Service charging-action command. For a description of
these command options, see the Command Line Interface Reference.
Video Pacing Call
Flows
When the Mobile
Video Gateway receives an HTTP GET request from a subscriber UE,
it performs DPI to determine whether it is a request for video content.
If the Mobile Video Gateway cannot make this determination by inspecting
the HTTP GET request, it performs DPI again when it receives the HTTP
RESPONSE from the OS.
The following figures
show the message flow during inspection for video content and the
subsequent triggering of video pacing functions. The first figure
shows the identification of a video request from an HTTP GET request,
the second shows the identification of a video request from an HTTP
RESPONSE.
Figure 14. DPI of HTTP GET
Identifying a Video Request
Figure 15. DPI of HTTP RESPONSE
Identifying a Video Request
Interactions with
Related Functions
The video pacing
feature is designed to work with related functional components as
follows:
-
Video Pacing and the
CAE: The video pacing feature is an independent software module
and has no interface with the Cisco CAE. It performs its function
in the same way whether a video is downloaded from the OS or from
the CAE. The CAE is an optional component of the Cisco Mobile Videoscape.
-
Video Pacing and the
TCP Proxy: The video pacing feature can be configured to work
with or without the TCP proxy feature with no change in its function.
-
Video Pacing and Traffic
Performance Optimization: The traffic performance optimization
feature works over the interface on the client side of the TCP proxy.
It handles re-transmission, TCP window size adjustment, and so on.
Video pacing works over the interface on the video server side of
the TCP proxy, and works independent of traffic performance optimization.
Supported Video Container
File Formats
In this software
release, the video pacing feature supports the following standard
video container file formats:
- MP4 File Format
- FLV Files
MP4 follows the ISO
Base Media File Format (MPEG-4 Part 12). We provide comprehensive
support for progressive download of .FLV files, playable in Adobe® Flash® Player.
TCP Link Monitoring
TCP is the
dominant transport protocol for the majority of Internet traffic,
including video. For mobile networks, the available transport bandwidth
can fluctuate depending on changing conditions over the wireless
connections. Knowledge of the available transport bandwidth is especially
important for video over mobile networks, since this bandwidth affects
video delivery rates, video encoding and compression techniques,
and ultimately the video playback experience of the subscribers.
The TCP link monitoring
feature adds the capability to enable monitoring and logging of
TCP behavior towards the subscriber UEs. Monitoring TCP behavior enables
the Mobile Video Gateway to estimate transient bandwidth and identify
network congestion for all TCP connections toward the clients on
the subscriber UEs.
The Mobile Video Gateway
services two types of TCP connections. A TCP connection can either
pass through the Mobile Video Gateway intact or can be split into
two connections by the TCP proxy. For the downlink data towards
the subscriber UEs, the TCP link monitoring feature invokes its
bandwidth estimation and statistical logging functions, which are
enabled for both proxy and non-proxy modes.
TCP link monitoring
statistics are gathered on a system-wide basis. This information
can be periodically exported to a collection server as bulk statistics,
upon which post-processing can be performed.
TCP Link Monitoring
System Flow
The following
figure shows the flow of information to and from the TCP link monitoring module
on the Mobile Video Gateway.
Figure 16. TCP Link
Monitoring System Flow
The TCP link monitoring
feature calculates the RTT (Round Trip Time) and estimates the link
bandwidth based on the downlink data sent towards the UE and the
current congestion conditions. It then collects this information
at the system level to report to the bulk statistics collection
server.
Note that the throughput
calculation for the TCP link excludes duplicate, out-of-order, and retransmitted
packets.
Functional Overview
The key functions
of the TCP link monitoring feature are bandwidth estimation and
system-level TCP statistical logging.
Bandwidth Estimation
Because mobile
devices are served by a variety of TCP variants, either from the
OS or from the Mobile Video Gateway’s TCP proxy, the TCP
link monitoring feature employs an independent bandwidth estimation
technique proposed by TCP Westwood+ (see “Performance
Evaluation of Westwood+ TCP Congestion Control” by
Mascolo, et al).
Westwood+ estimates
bandwidth by calculating the ratio of the number of bytes of acknowledged
TCP payload over every RTT. This rate sample is then filtered by
a weighted moving average to derive a per-flow average bandwidth
estimate for every RTT interval.
Statistical Logging
Statistical
logging of TCP traffic supports two types of plots: histogram and
time-series.
For histogram logging,
the TCP link monitoring feature keeps a counter for every bit rate
or RTT range. Whenever a new sample of TCP traffic is generated,
a corresponding counter is updated. The collection server retrieves
these values based on the configured sampling rate. There are four
histogram plots: video bit rate, video RTT, non-video bit rate,
and non-video RTT. For each of these plots, a total of 36 counters
are used for logging.
For time-series logging,
the sampling rate is the same as that of the remote update time
for the collection server. Typically, this can be configured in
30-minute intervals. As with histogram logging, there are four time-series
counters: video bit rate, video RTT, non-video bit rate, and non-video
RTT.
Dynamically-enabled
TCP Proxy
The Mobile
Video Gateway can act as a dynamically-enabled TCP proxy that provides
the following functions:
- Transparent video re-addressing
- Traffic performance
optimization
Note that these features
require the TCP proxy to function as expected.
The TCP proxy can be
dynamically enabled based on Active Charging Service rule definitions.
For information about the dynamically-enabled TCP proxy, including
configuration instructions, see the Enhanced Charging Services
Administration Guide.
Traffic Performance
Optimization
The Mobile
Video Gateway can use traffic performance optimization to improve
latency and accelerate the delivery of video content, especially
when network congestion and packet drops are present. The feature
runs on the dynamically-enabled TCP proxy and can be enabled statically
based on the subscriber profile or dynamically based on a DPI match
in a charging action.
For information about
traffic performance optimization, including configuration instructions,
see the Traffic Performance
Optimization Administration Guide.
N+1 Stateful
Redundancy
In the telecommunications
industry, over 90 percent of all equipment failures are software-related.
With robust hardware failover and redundancy protection, any card-level
hardware failures on the system can quickly be corrected. However,
software failures can occur for numerous reasons, many times without
prior indication.
This software release
supports N+1 stateful redundancy for mobile video sessions.
N+1 stateful redundancy provides seamless failover and
reconstruction of subscriber session information in the event of
a hardware or software fault within the system, preventing fully-connected
subscriber sessions from being disconnected. Sessions are maintained over
a software failure of a process or hardware failure.
This is an existing
feature of the ASR 5000. Note that Layer 4 flows will not be maintained across
switch-overs.
Threshold Crossing
Alerts
Thresholding on
the system is used to monitor the system for conditions that could
potentially cause errors or outages. Typically, these conditions
are temporary (high CPU utilization or packet collisions on a network,
for example) and are quickly resolved. However, continuous or large
numbers of these error conditions within a specific time interval
may be indicative of larger, more severe issues. The purpose of
thresholding is to help identify potentially severe conditions so
that immediate action can be taken to minimize and/or avoid
system downtime.
The system supports threshold
crossing alerts for certain key resources such as CPU, memory, IP
pool addresses, etc. With this capability, the operator can configure
a threshold on these resources whereby, should the resource depletion
cross the configured threshold, an SNMP trap would be sent.
The following thresholding
models are supported by the system:
-
Alert: A value is
monitored and an alert condition occurs when the value reaches or
exceeds the configured high threshold within the specified polling
interval. The alert is generated, then generated and/or
sent again at the end of the polling interval.
-
Alarm: Both high
and low threshold are defined for a value. An alarm condition occurs
when the value reaches or exceeds the configured high threshold
within the specified polling interval. The alert is generated, then
generated and/or sent again at the end of the polling interval.
Thresholding reports
conditions using one of the following mechanisms:
- SNMP traps: SNMP
traps have been created that indicate the condition (high threshold
crossing and/or clear) of each of the monitored values.
Generation of specific traps can be enabled or disabled on the chassis,
ensuring that only important faults get displayed. SNMP traps are
supported in both Alert and Alarm modes.
- Logs: The system
provides a facility for which active and event logs can be generated.
As with other system facilities, logs are generated messages pertaining
to the condition of a monitored value and are generated with a severity
level of WARNING. Logs are supported in both the Alert and the Alarm
models.
- Alarm System: High
threshold alarms generated within the specified polling interval
are considered outstanding until a condition no longer exists or
a condition clear alarm is generated. Outstanding alarms are reported
to the system’s alarm subsystem and are viewable through
the Alarm Management menu in the Web Element Manager.
For more information
about threshold crossing alert configuration, see the Thresholding Configuration
Guide.
Mobile Video Statistics
The mobile video
statistics feature enables mobile operators to collect detailed
statistics on mobile video usage to understand how subscribers behave
when viewing video content, how much network resources are consumed
by video, and what trends develop as video use cases evolve. The
mobile video statistics feature collects important statistical data
for video and presents this information in three ways: per user
device type, per radio access type, and per video container type.
With this information, operators can better understand evolving
trends in their network and further adapt and fine tune their video
optimization solution accordingly.
In this software release,
the identification of a video flow is dependent on charging actions
defined within the corresponding Active Charging Service. When a
flow matches a rule definition for video during DPI, the mobile
video statistics feature begins collecting the following statistics
for the video flow:
-
Total size of the
video file (the HTTP content length): This is the size given
in the HTTP RESPONSE header for the video file, represented in bytes.
-
Total duration of
the video clip: This is the video play duration identified from the
video metadata, represented in seconds. If the mobile video statistics
feature cannot get this information from the metadata (due to non-standard
metadata formatting, etc.), this field shows 0.
-
Total bytes sent to
the UE: This is the payload data bytes (excluding TCP/IP headers)
permitted to be sent towards the UE. Note that this counter includes
end-to-end (TCP) retransmissions.
-
Total duration that
the video object is on: This is the time it takes for the UE
to finish downloading the video, which is from the creation of the
first flow to the deletion of the last flow comprising this video.
-
Total number of TCP
flows used to download the video: The total count of TCP sessions
used for this video object.
The mobile video statistics
feature also derives the following information from the statistics above:
-
Video delivery rate: Total
bytes sent to the UE/Total duration that the video object
is on. This is the average bit rate of the video payload bytes being
delivered to the UE, represented in bps.
-
Percentage of video
download: Total bytes sent to the UE/Total size of
the video file. This is the percentage of the video file that the
user actually downloaded. The number reflects whether users tend
to watch the entire video or only a small part of it. Note that
since “Total bytes sent to the UE” includes retransmissions,
this number can be larger than 100%.
-
Video encoding bit
rate: Total size of the video file/Total duration of
the video clip. This is the average video encoding bit rate, represented
in bps.
The feature collects
the information above per video object, in which each video object
is defined by a unique URI. When multiple HTTP flows can be used
to obtain one video object, as with Apple iOS® devices,
the feature combines these flows when collecting statistics and
treats them as one video object. The statistics are then aggregated
per ACS manager and at the Global system level. This aggregation
occurs using the following operations:
- For the first five statistics
described above, when each video object terminates, the numbers
are added to the aggregator at the ACS manager level. Aggregation
among ACS managers happens when triggered by CLI commands or when
bulk statistics are generated.
- The three derived statistics
are calculated using the first five statistics after aggregation
at the ACS manager level and the Global system level.
During aggregation,
the mobile video statistics feature categorizes the information
above based on UE device type, radio access type, and video container
type, as follows:
-
UE device type: Apple
iOS devices (iPhone, iPad®, and iPod®), Android™ devices,
laptops, and other devices.
-
Radio access type: 2G,
3G, 4G-LTE, CDMA, HSPA, WLAN, and other types.
-
Video container type: flv/f4v,
mp4 (includes related types such as m4v, 3gp, 3g2, and mov), and
other types.
The statistics include
the total video object count for each of these categories, which
is the total number of video files downloaded for a particular category.
The feature maintains
two statistical arrays. The first array is arranged per UE device
type, per radio access type. The second array is arranged per UE
device type, per video container type.
For configuration instructions,
see Chapter 2. For information about the variables in the MVS schema,
see the Statistics and
Counters Reference.
Bulk Statistics
for Mobile Video
Bulk statistics
on the ASR 5000 allow operators to choose to view not only statistics
that are of importance to them, but to also configure the format
in which they are presented. This simplifies the post-processing
of statistical data, since it can be formatted to be parsed by external,
back-end processors.
The system can be configured
to collect bulk statistics and send them to a collection server
called a receiver. Bulk statistics are statistics that are collected
in a group. The individual statistics are grouped by schema. The
following is a partial list of supported schemas:
- System: Provides
system-level statistics.
- Card: Provides card-level
statistics.
- Port: Provides port-level
statistics.
- MVS: Provides statistics
to support the Mobile Videoscape (MVS).
The system supports
the configuration of up to four sets (primary/secondary)
of receivers. Each set can be configured to collect specific sets
of statistics from the various schemas. Statistics can be pulled
manually from the system or sent at configured intervals. The bulk
statistics are stored on the receiver(s) in files.
The format of the bulk
statistic data files can be configured by the user. Users can specify
the format of the file name, file headers, and/or footers
to include information such as the date, system host name, system
uptime, the IP address of the system generating the statistics (available for
headers and footers only), and/or the time that the file
was generated.
When the Web Element
Manager is used as the receiver, it is capable of further processing the
statistics data through XML parsing, archiving, and graphing.
The Bulk Statistics
Server component of the Web Element Manager parses collected statistics
and stores the information in the PostgreSQL database. If XML file
generation and transfer is required, this element generates the
XML output and can send it to a northbound NMS or an alternate bulk
statistics server for further processing.
Additionally, if archiving
of the collected statistics is desired, the Bulk Statistics Server writes
the files to an alternative directory on the server. A specific
directory can be configured by the administrative user or the default
directory can be used. Regardless, the directory can be on a local
file system or on an NFS-mounted file system on the Web Element
Manager server.
For configuration instructions,
see Chapter 2.
How the Mobile Video
Gateway Works
This section shows
how the Mobile Video Gateway works during DPI in a number of call scenarios,
including scenarios involving the Mobile Video Gateway with the
CAE and the Mobile Video Gateway without the CAE.
Mobile Video Gateway
with the Content Adaptation Engine
This section shows
call scenarios involving the Mobile Video Gateway with the Content
Adaptation Engine.
DPI of HTTP GET Request
Identifying a Non-Video Request (MVG with the CAE)
When the Mobile Video
Gateway receives an HTTP GET request from a subscriber UE, it performs
DPI to determine whether it is a request for video content. The figure
below shows the Mobile Video Gateway with the CAE performing DPI
on an HTTP GET request and identifying it as a non-video request.
The table that follows the figure describes each step in the message
flow.
Figure 17. DPI of HTTP GET
Request Identifying a Non-Video Request
Table 2. DPI of HTTP GET Request
Identifying a Non-Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and identifies it as a non-video request (the DPI on
GET/POST fails).
|
3.
|
The Mobile Video Gateway
forwards the HTTP request to the OS transparently, using the URL
source IP address as the client address and the destination IP address
as the OS address.
|
4.
|
The OS responds with
an HTTP 200 OK, including the content of the page.
|
5.
|
The Mobile Video Gateway
forwards the HTTP 200 OK to the UE transparently. The connection
is not proxied, and the TCP flow continues to the UE.
|
DPI of HTTP RESPONSE
Identifying a Non-Video Request (MVG with the CAE)
When the Mobile Video
Gateway cannot determine whether an HTTP GET request is a request
for video content during DPI, it performs DPI again when it receives
the HTTP RESPONSE from the OS. The figure below shows the Mobile
Video Gateway with the CAE performing DPI on an HTTP RESPONSE and
identifying it as a response to a non-video request. The table that
follows the figure describes each step in the message flow.
Figure 18. DPI of HTTP RESPONSE
Identifying a Non-Video Request
Table 3. DPI of HTTP RESPONSE
Identifying a Non-Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and cannot determine whether it is a video request.
|
3.
|
The Mobile Video Gateway
forwards the HTTP request to the OS transparently, using the URL
source IP address as the client address and the destination IP address
as the OS address.
|
4.
|
The OS responds with
an HTTP 200 OK, including the content of the page. The Mobile Video
Gateway performs DPI again and identifies it as a response to a
non-video request (the DPI on the RESPONSE headers fails).
|
5.
|
The Mobile Video Gateway
forwards the HTTP 200 OK to the UE transparently. The connection
is not proxied, and the TCP flow continues to the UE.
|
DPI of HTTP GET Request
Identifying a Video Request (MVG with the CAE)
When the Mobile Video
Gateway receives an HTTP GET request from a UE, it performs DPI
to determine whether it is a request for video content. The figure below
shows the Mobile Video Gateway with the CAE performing DPI on an
HTTP GET request and identifying it as a video request. The table
that follows the figure describes each step in the message flow.
Figure 19. DPI of HTTP GET
Request Identifying a Video Request
Table 4. DPI of HTTP GET Request
Identifying a Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and identifies it as a video request (the DPI on GET/POST succeeds).
|
3.
|
The TCP connection gets
proxied. The Mobile Video Gateway closes the TCP connection with
the OS and opens a new one with the CAE.
|
4.
|
The Mobile Video Gateway
sends the original HTTP GET request to the CAE with x-headers for
transport, quality, and UE identity.
|
5.
|
The CAE creates a TCP
proxy connection with the OS.
|
6.
|
The CAE sends the original
HTTP GET request from the UE to the OS.
|
7.
|
The CAE processes the
HTTP RESPONSE packets from the OS and performs video optimization.
|
8.
|
The Mobile Video Gateway
performs additional video optimization and sends the optimized packets
to the UE.
|
DPI of HTTP RESPONSE
Identifying a Video Request (MVG with the CAE)
When the Mobile Video
Gateway cannot determine whether an HTTP GET request is a request
for video content during DPI, it performs DPI again when it receives
the HTTP RESPONSE from the OS. The figure below shows the Mobile
Video Gateway with the CAE performing DPI on an HTTP RESPONSE and
identifying it as a response to a video request. The table that
follows the figure describes each step in the message flow.
Figure 20. DPI of HTTP RESPONSE
Identifying a Video Request
Table 5. DPI of HTTP RESPONSE
Identifying a Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and cannot determine whether it is a video request.
|
3.
|
The Mobile Video Gateway
forwards the HTTP request to the OS transparently, using the URL
source IP address as the client address and the destination IP address
as the OS address.
|
4.
|
The OS responds with
an HTTP 200 OK. The Mobile Video Gateway performs DPI again and
identifies it as a response to a video request (the DPI on the RESPONSE
headers succeeds).
|
5.
|
The TCP connection gets
proxied. The Mobile Video Gateway closes the TCP connection with
the OS and opens a new one with the CAE.
|
6.
|
The Mobile Video Gateway
sends the original HTTP GET request to the CAE with x-headers for
transport, quality, and UE identity.
|
7.
|
The CAE creates a TCP
proxy connection with the OS.
|
8.
|
The CAE sends the original
HTTP GET request from the UE to the OS.
|
9.
|
The CAE processes the
HTTP RESPONSE packets from the OS and performs video optimization.
|
10.
|
The Mobile Video Gateway
performs additional video optimization and sends the optimized packets
to the UE.
|
Mobile Video Gateway
without the Content Adaptation Engine
This section shows
call scenarios involving a Mobile Video Gateway without the Content Adaptation
Engine.
DPI of HTTP GET Request
Identifying a Non-Video Request (MVG without the CAE)
When the Mobile Video
Gateway receives an HTTP GET request from a UE, it performs DPI
to determine whether it is a request for video content. The figure below
shows the Mobile Video Gateway performing DPI on an HTTP GET request
and identifying it as a non-video request. The table that follows
the figure describes each step in the message flow.
Figure 21. DPI of HTTP GET
Request Identifying a Non-Video Request
Table 6. DPI of HTTP GET Request
Identifying a Non-Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and identifies it as a non-video request (the DPI on
GET/POST fails).
|
3.
|
The Mobile Video Gateway
forwards the HTTP request to the OS transparently, using the URL
source IP address as the client address and the destination IP address
as the OS address.
|
4.
|
The OS responds with
an HTTP 200 OK, including the content of the page.
|
5.
|
The Mobile Video Gateway
forwards the HTTP 200 OK to the UE transparently. The connection
is not proxied, and the TCP flow continues to the UE.
|
DPI of HTTP RESPONSE
Identifying a Non-Video Request (MVG without the CAE)
When the Mobile Video
Gateway cannot determine whether an HTTP GET request is a request
for video content during DPI, it performs DPI again when it receives
the HTTP RESPONSE from the OS. The figure below shows the Mobile
Video Gateway performing DPI on an HTTP RESPONSE and identifying
it as a response to a non-video request. The table that follows
the figure describes each step in the message flow.
Figure 22. DPI of HTTP RESPONSE
Identifying a Non-Video Request
Table 7. DPI of HTTP RESPONSE
Identifying a Non-Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and cannot determine whether it is a video request.
|
3.
|
The Mobile Video Gateway
forwards the HTTP request to the OS transparently, using the URL
source IP address as the client address and the destination IP address
as the OS address.
|
4.
|
The OS responds with
an HTTP 200 OK, including the content of the page. The Mobile Video
Gateway performs DPI again and identifies it as a response to a
non-video request (the DPI on the RESPONSE headers fails).
|
5.
|
The Mobile Video Gateway
forwards the HTTP 200 OK to the UE transparently. The connection
is not proxied, and the TCP flow continues to the UE.
|
DPI of HTTP GET Request
Identifying a Video Request (MVG without the CAE)
When the Mobile Video
Gateway receives an HTTP GET request from a UE, it performs DPI
to determine whether it is a request for video content. The figure below
shows the Mobile Video Gateway performing DPI on an HTTP GET request
and identifying it as a video request. The table that follows the
figure describes each step in the message flow.
Figure 23. DPI of
HTTP GET Request Identifying a Video Request
Table 8. DPI of HTTP GET Request
Identifying a Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and identifies it as a video request (the DPI on GET/POST succeeds).
|
3.
|
The Mobile Video Gateway
forwards the HTTP request to the OS transparently, using the URL
source IP address as the client address and the destination IP address
as the OS address.
|
4.
|
The OS responds with
an HTTP 200 OK.
The Mobile Video Gateway
proxies the TCP connection and the HTTP RESPONSE packets are processed
through the video optimization features.
|
5.
|
The Mobile Video Gateway
forwards the HTTP 200 OK to the UE.
|
6.
|
The optimized TCP video
flow continues to the UE.
|
DPI of HTTP RESPONSE
Identifying a Video Request (MVG without the CAE)
When the Mobile Video
Gateway cannot determine whether an HTTP GET request is a request
for video content during DPI, it performs DPI again when it receives
the HTTP RESPONSE from the OS. The figure below shows the Mobile
Video Gateway performing DPI on an HTTP RESPONSE and identifying
it as a response to a video request. The table that follows the
figure describes each step in the message flow.
Figure 24. DPI of
HTTP RESPONSE Identifying a Video Request
Table 9. DPI of HTTP RESPONSE
Identifying a Video Request
Step |
Description |
1.
|
The UE creates a TCP
connection with the OS.
|
2.
|
The Mobile Video Gateway
receives an HTPP GET request from the UE. The Mobile Video Gateway
performs DPI and cannot determine whether it is a video request.
|
3.
|
The Mobile Video Gateway
forwards the HTTP request to the OS transparently, using the URL
source IP address as the client address and the destination IP address
as the OS address.
|
4.
|
The OS responds with
an HTTP 200 OK. The Mobile Video Gateway performs DPI again and
identifies this as a response to a video request (the DPI on the
RESPONSE headers succeeds).
The Mobile Video Gateway
proxies the TCP connection and the HTTP RESPONSE packets are processed
through the video optimization features.
|
5.
|
The Mobile Video Gateway
forwards the HTTP 200 OK to the UE.
|
6.
|
The optimized TCP video
flow continues to the UE.
|