Mobile Video Gateway Overview

This chapter contains general overview information about the Cisco® Mobile Video Gateway, including:

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.