Mobile Video Gateway Configuration

This chapter provides configuration information for the Mobile Video Gateway.

Because each wireless network is unique, the system is designed with a variety of parameters allowing it to perform in various wireless network environments. In this chapter, only the minimum set of parameters are provided to make the system operational.

Before you perform the instructions in this chapter, confirm that the configuration for the mobile gateway upon which the Mobile Video Gateway software runs has been completed. Note that the Mobile Video Gateway features are not enabled by default, so you must follow the instructions in this chapter to configure and enable each required feature.

The following sections are included in this chapter:

Configuring CAE Re-addressing and Load Balancing

The Cisco CAE (Content Adaptation Engine) is an optional component of the Cisco Mobile Videoscape. The Mobile Video Gateway’s CAE re-addressing and CAE load balancing features are configured and enabled via system CLI commands using charging-action command options within an Active Charging Service, which is a component of the Enhanced Charging Services. Active Charging Services employ the system’s DPI capabilities and are configured in Global Configuration Mode so that the system performs DPI for CAE re-addressing and load balancing on all subscriber sessions over all system contexts.

To configure the CAE re-addressing and load balancing features, perform the following steps:

  1. Configure a CAE group for the CAEs in the server cluster by applying the commands in the section Configuring the CAE Group.
  2. Configure CAE re-addressing by applying the commands in the section Configuring CAE Re-addressing.
  3. Configure video optimization pre-processing by applying the commands in the section Configuring Video Optimization Pre-processing.
  4. Configure logging for CAE health-check monitoring by applying the commands in the section Configuring Logging for CAE Health-Check Monitoring.

Configuring the CAE Group

The CAE group is configured and enabled via system CLI commands in the context containing the interface to the CAEs, which is typically the destination context. Use the following commands to configure the CAE group:

configure
   context <context_name>
      cae_group <cae_group_name>
         local_address <IPv4_address>
         server
<cae_name>
address <IPv4_address>
port <port_number> 
         keepalive-server
deadtime <seconds>
interval <seconds>
num-retry <num-retries>
port <port_number> timeout
<seconds>
         end

The cae-group command specifies the name of the CAE group that will contain the CAEs servicing the video requests from the Mobile Video Gateway. <cae_group_name> can be a string between 1 and 79 characters. Note that there can be one and only one CAE group per context. Issuing this commands enters the Video Group Configuration Mode.

The local-address command specifies the local IPv4 address on the Mobile Video Gateway for the keep-alive TCP connection to the CAEs.

The server command specifies a CAE in the CAE group. This command must be repeated for all CAEs in the CAE group. Note that there is a system limit of 64 CAEs supported on a Mobile Video Gateway. <cae_name> can be a string between 1 and 15 characters. The address option specifies the IPv4 address of the CAE in dotted decimal notation. This address is used for the keep-alive TCP connection to the Mobile Video Gateway. The port option specifies the port number on the CAE for the keep-alive TCP connection. The port number can be between 1 and 65535. This value defaults to 80 if absent from the command.

The keepalive-server command enables health-check monitoring for all CAEs in the CAE group. The deadtime option sets the periodic retry interval, in seconds, after a CAE is detected down. <seconds> can be between 1 and 1800 seconds, with a default value of 120 seconds. The interval option specifies the health-check monitoring interval, in seconds, which is how often the Mobile Video Gateway sends a keep-alive message to the CAEs. <seconds> can be between 0 and 120 seconds, with a default value of 10 seconds. A value of 0 turns off keep-alive detection and marks the state of all CAEs to Up. The num-retry option specifies the number of keep-alive retries to send after a CAE does not respond. <num_retries> can be between 1 and 20 retries, with a default value of 3 retries. The port option specifies the TCP port number for health-check monitoring. <port_number> can be between 1 and 65535, with a default value of 5100. The timeout option specifies the keep-alive timeout in seconds. <seconds> can be between 1 and 30 seconds, with a default value of 3 seconds.

Configuring CAE Re-addressing

In addition to the command sequence for configuring a CAE group, you need to add a charging action for CAE re-addressing, enable CAE re-addressing, and specify the HTTP x-header format to use to insert the destination IP address and TCP port number of the OS (Origin Server). Use the following commands to configure CAE re-addressing:

configure
   require
active-charging
   active-charging
service <service_name>
      charging-action
cae_redirect
         video
cae-readdressing xheader-format <xheader_format_name>
         video
bitrate <bit_rate_in_bps>
         end

The require active-charging command enables active charging on the Mobile Video Gateway.

The active-charging service command specifies the name of the Active Charging Service. The <service_name> can be an alpha and/or numeric string between 1 and 15 characters.

The charging-action command specifies the name of the charging action. The <charging_action_name> can be an alpha and/or numeric string between 1 and 63 characters.

The video cae-readdressing command enables CAE re-addressing, allowing video content to be fetched from the CAEs. This command also enables CAE load balancing.

The xheader-format option specifies an HTTP x-header (Extension header) format for readdressing. When specified, the Mobile Video Gateway inserts a destination IP address and TCP port number in a proprietary HTTP x-header in the HTTP request to the CAE. The CAE uses this information to connect to the OS to retrieve selected video clips for adaptation. The <xheader_format_name> can be between 1 and 63 characters.

The video bitrate option specifies a suggested maximum bit rate value for video in bits per second.

Configuring Video Optimization Pre-processing

In addition to creating a CAE group and adding a charging action for CAE re-addressing, you need to add commands under the rulebase configuration to enable video optimization pre-processing for CAE re-addressing. Use the following commands to configure video optimization pre-processing:

      rulebase
base1
         tcp
proxy-mode dynamic all
         video
optimization-preprocessing cae-readdressing
         no
tcp check-window-size
         action
priority 15 group-of-ruledefs video_group charging-action
cae_redirect
         route
priority 10 ruledef http_routing analyzer http
         exit

The rulebase command creates the rulebase. The <rulebase_name> can be an alpha and/or numeric string between 1 and 63 characters.

The tcp proxy-mode dynamic all command enables the dynamic TCP proxy for subscriber-initiated TCP flows, and specifies that all TCP connections are split for all enabled Active Charging Service features.

The video optimization-preprocessing cae-readdressing command enables CAE re-addressing by enabling Enhanced Charging Services to process video requests for optimization per rulebase configuration.

Configuring Logging for CAE Health-Check Monitoring

Use the following commands to configure logging for CAE health-check monitoring:

logging active event-verbosity full
logging filter active
facility vpn level warning

Note that the logging commands need to be issued from the context in which the CAE group resides (in the destination context, for example).

Sample CAE Re-addressing and Load Balancing Configuration

The following is a sample CAE re-addressing and load balancing configuration that includes a sample rule base, which acts as a subscriber’s policy in a charging service, and sample rule definitions (ruledefs), which define the packets to take action on and what action to take on them. Note that operators must create a unique configuration based on their own requirements.

configure
   context
destination
      cae-group
cae_group_1
         local-address ip_address
         server
server_1 address ip_address port 80
         server
server_2 address ip_address port 8080
         keepalive-server
deadtime 120 interval 10 num-retry 3 port 5100 timeout 3
         exit
      exit
   context
source
      apn.cisco.com
         accounting-mode
radius-diameter
         active-charging
rulebase base1
         ip
context-name destination
         exit
      exit
   active-charging
service service_1
      ruledef
http_youtube
         http
uri contains videoplayback
         http
host contains googlevideo
         multi-line-or
all-lines
         exit
      ruledef
video
         http
uri contains .m4v
         http
uri contains .3gp
         http
uri contains .mp4
         http
uri contains .mov
         http
uri contains .f4v
         multi-line-or
all-lines
         exit
      group-of-ruledefs
video_group
         add-ruledef
priority 1 ruledef http_youtube
         add-ruledef
priority 2 ruledef video
         exit
      charging-action
mvg_1
         video
cae-readdressing xheader-format xheader_format_name
         exit
      rulebase
base1
         action
priority 1 ruledef no_redirect charging-action default
         action
priority 2 group-of-ruledefs video_group charging-action
mvg_1
         route
priority 5 ruledef rr_http_80 analyzer http
         route
priority 6 ruledef rr_http_8080 analyzer http
         exit
      end
The association of a charging action to the CAE group in the configuration example above has the following logic:
  • The system performs DPI on the HTTP GET request and determines that it is a video request based on the rule action priority 2 group-of-ruledefs video_group charging-action mvg_1.
  • The system applies the charging action mvg_1. The video cae-readdressing command enables CAE re-addressing. The system examines the subscriber record and locates the interface to the CAEs in the destination context.
  • The xheader-format option specifies an HTTP x-header format for readdressing. When specified, the Mobile Video Gateway inserts a destination IP address and TCP port number in a proprietary HTTP x-header in the HTTP request to the CAE. The CAE uses this information to connect to the OS to retrieve selected video clips for adaptation. The xheader_format_name can be between 1 and 63 characters.
  • The system locates the CAE group cae_group_1 in the destination context.
  • The system selects a CAE in the group to service the video request using a round-robin selection method. The selected server information is stored in a subscriber session record. If the previously-selected server for the same subscriber goes down, the system selects the next available CAE and updates the subscriber session record. If the system fails to find a CAE group in the configuration, or no CAEs in a group are available, the system redirects the video request to the OS.

Configuring Video Optimization Policy Control

The video optimization policy control feature is configured and enabled via system CLI commands using charging-action command options within an Active Charging Service. Active Charging Services employ the system’s DPI capabilities and are configured in Global Configuration Mode so that the system performs DPI for video optimization policy control on all subscriber sessions over all system contexts.

Use the following commands to configure video optimization policy control:

configure
   require
active-charging
   active-charging
service <service_name>
      charging-action <charging_action_name>
         video
pacing by-policing initial-burst-duration <seconds> normal-burst-duration <seconds>
         video
bitrate <bit_rate_in_bps>
         video
cae-readdressing xheader-format <xheader_format_name>
         end

The require active-charging command enables active charging on the Mobile Video Gateway.

The active-charging service command specifies the name of the Active Charging Service. The <service_name> can be an alpha and/or numeric string between 1 and 15 characters.

The charging-action command specifies the name of the charging action. The <charging_action_name> can be an alpha and/or numeric string between 1 and 63 characters.

The video pacing by-policing command in this example enables video pacing by policing. Note that the video pacing feature is not enabled by default.

The initial-burst-duration option specifies the initial burst duration allowed before the feature begins to limit the bit rate to the actual encoding bit rate of the video. Note that the initial burst is configured in terms of time, so that for video files with different encoding bit rates, the amount of bytes allowed without enforcing pacing gets adjusted accordingly. The amount of bytes allowed is calculated by (video encoding rate * initial-burst-duration). The default value is 10 seconds.

The normal-burst-duration option specifies the normal burst duration allowed after the initial burst is completed. Like the initial burst, the normal burst is also configured in terms of time, so that for video files with different encoding bit rates, the amount of bytes allowed without enforcing pacing gets adjusted accordingly. The amount of bytes allowed is calculated by (video encoding rate * normal-burst-duration). The default value is 3 seconds.

The video bitrate option specifies a suggested maximum bit rate value for video. This default bit rate, in bits per second, is used on each video flow until the rate determination function calculates the optimal bit rate to use for video pacing. The default value is 0, which means that if rate determination fails on a flow identified as video, video pacing is not applied to the flow. If a value is configured for this CLI option, and if rate identification fails on a flow, instead of turning off pacing for the flow, the configured bit rate will be enforced on the flow.

The video cae-readdressing command enables CAE re-addressing and load balancing, allowing video content to be fetched from the CAEs.

The xheader-format option specifies an HTTP x-header format for readdressing. When specified, the Mobile Video Gateway inserts a destination IP address and TCP port number in a proprietary HTTP x-header in the HTTP request to the CAE. The CAE uses this information to connect to the OS to retrieve selected video clips for adaptation. The <xheader_format_name> can be between 1 and 63 characters.

Sample Video Optimization Policy Control Configurations

This section includes two sample video optimization policy control configurations, as follows:

Note that in both sample configurations, the narrower the rule match, the higher the priority number assigned to the ruledef (rule definition) entry. Note also that operators must create a unique configuration based on their own requirements.

Obtaining the Video Policy via the PCRF over a Gx Interface

The following is a sample configuration for obtaining the video policy via the PCRF over a Gx interface.

configure
   require
active-charging
   active-charging
service_1
      ruledef
rr_http_80
         tcp
either-port=80
         rule-application
routing
         exit
      ruledef
rr_http_8080
         tcp
either-port=8080
         rule-application
routing
         exit
      ruledef
http_youtube
         http
uri contains videoplayback
         http
host contains googlevideo
         multi-line-or
all-lines
         exit
      ruledef
video
         http
uri contains .m4v
         http
uri contains .3gp
         http
uri contains .mp4
         http
uri contains .mov
         http
uri contains .f4v
         multi-line-or
all-lines
         exit
      ruledef
FACEBOOK
         http
uri contains fbcdn
         exit
      group-of-ruledefs
VIDEO_GOLD
         add-ruledef
priority 1 ruledef http_youtube
         add-ruledef
priority 2 ruledef video
         exit
      group-of-ruledefs
VIDEO_SILVER
         add-ruledef
priority 1 ruledef http_youtube
         add-ruledef
priority 2 ruledef video
         exit
      group-of-ruledefs
VIDEO_BRONZE
         add-ruledef
priority 1 ruledef http_youtube
         add-ruledef
priority 2 ruledef video
         exit
      xheader-format
XHDR_GOLD
         insert
X-adaptation-profile-index string-constant 4
         exit
      xheader-format
XHDR_SILVER
         insert
X-adaptation-profile-index string-constant 3
         exit
      xheader-format
XHDR_BRONZE
         insert
X-adaptation-profile-index string-constant 2
         exit
      charging-action
GOLD_ACTION
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_GOLD
         video
pacing by-policing initial-burst-duration 10 normal-burst-duration
5
         exit
      charging-action GOLD_ACTION_NO_PACING
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_GOLD
         exit
      charging-action
SILVER_ACTION
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_SILVER
         video
pacing by-policing initial-burst-duration 10 normal-burst-duration
5
         exit
      charging-action
BRONZE_ACTION
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_BRONZE
         video
pacing by-policing initial-burst-duration 10 normal-burst-duration
5
         exit
      rulebase
base1
         tcp
proxy-mode static
         video
optimization-preprocessing all
         action
priority 10 dynamic-only group_of_ruledefs VIDEO_GOLD
charging-action GOLD_ACTION
         action
priority 20 dynamic-only group_of_ruledefs VIDEO_SILVER
charging-action SILVER_ACTION
         action
priority 30 dynamic-only group_of_ruledefs VIDEO_BRONZE
charging-action BRONZE_ACTION
         action
priority 5 dynamic-only group_of_ruledefs VIDEO_GOLD_NO_PACING
charging-action GOLD_ACTION_NO_PACING
         route
priority 2 ruledef rr_http_8080 analyzer http
         route
priority 1 ruledef rr_http_80 analyzer http
         exit
      exit
   context
pgw
      interface
20/2-next
         ip
address <ip_address> <subnet_mask>
         exit
      subscriber
default
         ip
access-group acl1 in
         ip
access-group acl1 out
         active-charging
rulebase base2
         exit
      radius
group default
      end

Obtaining the Video Policy via the RADIUS Server over a RADIUS Interface

The following is a sample configuration for obtaining the video policy via the RADIUS server over a RADIUS interface.

configure
   require
active-charging
   active-charging
service_1
      ruledef
rr_http_80
         tcp
either-port=80
         rule-application
routing
         exit
      ruledef
rr_http_8080
         tcp
either-port=8080
         rule-application
routing
         exit
      ruledef
http_youtube
         http
uri contains videoplayback
         http
host contains googlevideo
         multi-line-or
all-lines
         exit
      ruledef
video
         http
uri contains .m4v
         http
uri contains .3gp
         http
uri contains .mp4
         http
uri contains .mov
         http
uri contains .f4v
         multi-line-or
all-lines
         exit
      ruledef
FACEBOOK
         http
uri contains fbcdn
         exit
      group-of-ruledefs
VIDEO_GOLD
         add-ruledef
priority 1 ruledef http_youtube
         add-ruledef
priority 2 ruledef video
         exit
      group-of-ruledefs
VIDEO_SILVER
         add-ruledef
priority 1 ruledef http_youtube
         add-ruledef
priority 2 ruledef video
         exit
      group-of-ruledefs
VIDEO_BRONZE
         add-ruledef
priority 1 ruledef http_youtube
         add-ruledef
priority 2 ruledef video
         exit
      xheader-format
XHDR_GOLD
         insert
X-adaptation-profile-index string-constant 4
         exit
      xheader-format
XHDR_SILVER
         insert
X-adaptation-profile-index string-constant 3
         exit
      xheader-format
XHDR_BRONZE
         insert
X-adaptation-profile-index string-constant 2
         exit
      charging-action
GOLD_ACTION
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_GOLD
         video
pacing by-policing initial-burst-duration 10 normal-burst-duration
5
         exit
      charging-action GOLD_ACTION_NO_PACING
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_GOLD
         exit
      charging-action
SILVER_ACTION
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_SILVER
         video
pacing by-policing initial-burst-duration 10 normal-burst-duration
5
         exit
      charging-action
BRONZE_ACTION
         flow
idle-timeout 200
         video
bitrate 1000000
         video
cae-readdressing
         xheader-insert
xheader-format XHDR_BRONZE
         video
pacing by-policing initial-burst-duration 10 normal-burst-duration
5
         exit
      rulebase
GOLD_RBASE
         tcp
proxy-mode static
         video
optimization-preprocessing all
         action
priority 10 group_of_ruledefs VIDEO_GOLD charging-action
GOLD_ACTION
         action
priority 5 ruledef FACEBOOK charging-action GOLD_ACTION_NO_PACING
         route
priority 2 ruledef rr_http_8080 analyzer http
         route
priority 1 ruledef rr_http_80 analyzer http
         exit
      rulebase
SILVER_RBASE
         tcp
proxy-mode static
         video
optimization-preprocessing all
         action
priority 10 group_of_ruledefs VIDEO_SILVER charging-action
GOLD_ACTION
         route
priority 2 ruledef rr_http_8080 analyzer http
         route
priority 1 ruledef rr_http_80 analyzer http
         exit
      rulebase
BRONZE_RBASE
         tcp
proxy-mode static
         video
optimization-preprocessing all
         action
priority 10 group_of_ruledefs VIDEO_BRONZE charging-action
BRONZE_ACTION
         route
priority 2 ruledef rr_http_8080 analyzer http
         route
priority 1 ruledef rr_http_80 analyzer http
         exit
      exit
   context
pgw
   interface
20/2-next
      ip
address <ip_address> <subnet_mask>
      exit
   subscriber
default
      ip
access-group acl1 in
      ip
access-group acl1 out
      active-charging
rulebase BRONZE_RBASE
      exit
   radius
group default
   end

Configuring 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.

Use the following commands to configure video white-listing:

      rulebase
whitelist
         action
priority 5 ruledef facebook charging-action VIDEO_NO_PACING
         action
priority 10 group-of-ruledefs all_video charging-action
VIDEO_PACING
         route
priority 1 ruledef rr_http_80 analyzer http
         route
priority 2 ruledef rr_http_8080 analyzer http
         exit

The rulebase command creates the white-list rulebase. The <rulebase_name> can be an alpha and/or numeric string between 1 and 63 characters.

In the example above, the first action priority command specifies the action priority as 5 for the facebook ruledef, with a charging action of VIDEO_NO_PACING. When the facebook ruledef is matched during DPI, the corresponding video flows are excluded from video pacing. The second action priority command specifies the action priority as 10 for the all_video group-of-ruledefs, with a charging action of VIDEO_PACING. When matched during DPI, the corresponding video flows are included in video pacing.

The two route priority commands control the routing of packets to the appropriate protocol analyzers.

Configuring Video Pacing

The video pacing feature is configured and enabled via system CLI commands as a charging action within an Active Charging Service. Active Charging Services employ the system’s DPI capabilities and are configured in Global Configuration Mode so that the system performs DPI for video pacing on all subscriber sessions over all system contexts.

Use the following commands to configure video pacing:

configure
   require
active-charging
   active-charging
service <service_name>
      charging-action <charging_action_name>
         video
pacing by-policing initial-burst-duration <seconds> normal-burst-duration <seconds>
         video
bitrate <bit_rate_in_bps>
         end

The require active-charging command enables active charging on the Mobile Video Gateway.

The active-charging service command specifies the name of the Active Charging Service. The <service_name> can be an alpha and/or numeric string between 1 and 15 characters.

The charging-action command specifies the name of the charging action. The <charging_action_name> can be an alpha and/or numeric string between 1 and 63 characters.

The video pacing by-policing command in this example enables video pacing by policing. Note that the video pacing feature is not enabled by default.

The initial-burst-duration option specifies the initial burst duration allowed before the feature begins to limit the bit rate to the actual encoding bit rate of the video. Note that the initial burst is configured in terms of time, so that for video files with different encoding bit rates, the amount of bytes allowed without enforcing pacing gets adjusted accordingly. The amount of bytes allowed is calculated by (video encoding rate * initial-burst-duration). The default value is 10 seconds.

The normal-burst-duration option specifies the normal burst duration allowed after the initial burst is completed. Like the initial burst, the normal burst is also configured in terms of time, so that for video files with different encoding bit rates, the amount of bytes allowed without enforcing pacing gets adjusted accordingly. The amount of bytes allowed is calculated by (video encoding rate * normal-burst-duration). The default value is 3 seconds.

The video bitrate option specifies a suggested maximum bit rate value for video. This default bit rate, in bits per second, is used on each video flow until the rate determination function calculates the optimal bit rate to use for pacing. The default value is 0, which means that if rate determination fails on a flow identified as video, video pacing is not applied to the flow. If a value is configured for this CLI option, and if rate identification fails on a flow, instead of turning off pacing for the flow, the configured bit rate will be enforced on the flow.

Sample Video Pacing Configuration

The following is a sample video pacing configuration. Note that operators must create a unique configuration based on their own requirements.

configure
   require
active-charging
   active-charging
service_1
      charging-action
video_pacing 
         video
pacing by-policing initial-burst-duration 15 normal-burst-duration
5
         video
bitrate 1000000
         exit
      rulebase
base1
         route
priority 1 ruledef rr_http_80 analyzer http
         route
priority 3 ruledef rr_http_8080 analyzer http
         action
priority 5 group-of-ruledefs video_group charging-action
video_pacing
         exit
      ruledef
rr_http_80
         tcp
either-port=80
         rule-application
routing
         exit
      ruledef
rr_http_8080
         tcp
either-port=8080
         rule-application
routing
         exit
      ruledef
video
         http
content type contains video
         http
uri contains .m4v
         http
uri contains .3gp
         http
uri contains .mp4
         http
uri contains .mov
         http
uri contains .f4v
         multi-line-or
all-lines
         exit
      ruledef
http_youtube
         http
uri contains videoplayback
         http
host contains googlevideo
         multi-line-or
all-lines
         exit
      group-of-ruledefs
video_group
         add-ruledef
priority 1 ruledef video
         add-ruledef
priority 2 ruledef http_youtube
         end

Video pacing requires the HTTP analyzer in the Enhanced Charging Service to examine the packets before video pacing does. See the routing rule definitions in the example above for how to redirect packets to the HTTP analyzer based on TCP ports.

In this example, the operator defines a group of rule definitions called video_group. When any of the rule definitions in the group are matched, the packet flow is considered to be a video flow. As shown in the example, this can be either a URI match, which is useful for matching a certain file extension, or a string match that identifies a video from a certain website (for example, YouTube™ always has the string “videoplayback” in the URI), or a hostname match, which is useful for matching videos from a specific host, such as “googlevideo”.

Note that in ruledef video, we match with "http content type contains video". This works for most video websites, which properly identify their videos with the proper content type. However, not all websites do this correctly, thus we need to supplement the rule with matches using the common file extensions used for video files. Note a dot (.) is added before each file extension to ensure the match is applied only to the file extension, not some other character combination in the middle of a URI.

Also note that matching with file extensions works only if the original server delivers video files with extensions. If the video server identifies its video files with a random hash string (with no file extension), and does not identify it with the proper content type, we cannot identify those videos.

Configuring TCP Link Monitoring

The TCP link monitoring feature is configured and enabled via an active-charging command option in either APN Configuration Mode or Subscriber Configuration Mode. When TCP link monitoring is enabled, the system monitors the downlink TCP traffic towards the subscriber UEs for TCP proxy and non-proxy modes.

Use the following commands to configure TCP link monitoring in Subscriber Configuration Mode:

configure
   require
active-charging
   context context_name
      subscriber
default
         active-charging
link-monitor tcp log
         exit
      exit
   context context_name
      apn
cisco.com
         active-charging
link-monitor tcp log
         end

The require active-charging command enables active charging on the Mobile Video Gateway.

The active-charging link-monitor tcp log command in this example enables TCP link monitoring. Note that TCP link monitoring is not enabled by default. Also note that when this command is configured without the log option, TCP link monitoring is enabled without logging.

The log option enables logging with histogram and time-series logging for both RTT and bit rate.

For additional options for this command, see the “Subscriber Configuration Mode Commands” and “APN Configuration Mode Commands” chapters of the Command Line Interface Reference.

Configuring Mobile Video Statistics

The mobile video statistics feature is configured and enabled via system CLI commands as a charging action within an Active Charging Service. Active Charging Services employ the system’s DPI capabilities, and are configured in Global Configuration Mode so that the system performs DPI for mobile video statistics on all subscriber sessions over all system contexts. Bulk statistics can also be configured to generate mobile video statistics based on the MVS (Mobile Videoscape) schema.

Use the following commands to configure mobile video statistics:

configure
   require
active-charging
   active-charging
service <service_name>
      charging-action <charging_action_name>
         video
detailed-statistics
         end

The require active-charging command enables active charging on the Mobile Video Gateway.

The active-charging service command specifies the name of the Active Charging Service. The <service_name> can be an alpha and/or numeric string between 1 and 15 characters.

The charging-action command specifies the name of the charging action. The <charging_action_name> can be an alpha and/or numeric string between 1 and 63 characters.

The video detailed-statistics command in this example enables mobile video statistics. When a flow matches a rule definition for video during DPI, the mobile video statistics feature begins collecting detailed statistics for the video flow. Note that the mobile video statistics feature is not enabled by default.

Configuring Bulk Statistics

Use the following commands to configure bulk statistics for the MVS (Mobile Videoscape):

configure
   bulkstats
collection
   bulkstats
mode
      sample-interval <time_interval>
      transfer-interval <xmit_time_interval>
      file <number>
         receiver
<ip_address>
primary mechanism ftp login <username> password <pwd>
         receiver
<ip_address> secondary
mechanism ftp login <username>
password <pwd>
         mvs
schema <file_name>
format <format_string>
         end

The bulkstats collection command in this example enables bulk statistics, and the system begins collecting pre-defined bulk statistical information.

The bulkstats mode command enters Bulk Statistics Configuration Mode, where you define the statistics to collect.

The sample-interval command specifies the time interval, in minutes, to collect the defined statistics. The <time-interval> can be in the range of 1 to 1440 minutes. The default value is 15 minutes.

The transfer-interval command specifies the time interval, in minutes, to transfer the collected statistics to the receiver (the collection server). The <xmit_time_interval> can be in the range of 1 to 999999 minutes. The default value is 480 minutes.

The file command specifies a file in which to collect the bulk statistics. A bulk statistics file is used to group bulk statistics schema, delivery options, and receiver configuration. The <number> can be in the range of 1 to 4.

The receiver command in this example specifies a primary and secondary collection server, the transfer mechanism (in this example, ftp), and a login name and password.

The mvs schema command specifies that the MVS schema is used to gather statistics. The <file_name> is an arbitrary name (in the range of 1 to 31 characters) to use as a label for the collected statistics defined by the format option. The format option defines within quotation marks the list of variables in the MVS schema to collect. For example: “%date, %time%, %<variables_to_collect>%”. The <format_string> can be in the range of 1 to 3599.

For descriptions of the MVS schema variables, see the “MVS Schema Statistics” chapter of the Statistics and Counters Reference. Note that additional options can be used to configure bulk statistics for the Mobile Videoscape. For more information on configuring bulk statistics, see the System Administration Guide.