There are three types of session trace functions available.

Caution

Session tracing is a resource intensive application in terms of CPU utilization and will affect call rates and data throughput when in use. The use of this feature in a production network should be restricted to minimize the impact on existing services.

Activation of a trace is similar whether it be via the management interface or via a signaling interface. In both cases, a trace session state block is allocated which stores all configuration and state information for the trace session. In addition, an (S)FTP connection to the Trace Collection Entity (TCE) is established if one does not already exist. The NE will store up to 2 MB of XML data on its local disk to allow for the (S)FTP connection to be established and the files to be pushed to or pulled from the TCE.

If the session to be traced is already active, tracing may begin immediately. Otherwise, tracing activity waits until the start trigger occurs (typically when the subscriber/UE under trace initiates a connection). A failure to activate a trace (due to the maximum being exceeded or some other failure reason) results in a notification being sent to the TCE indicating the failure.

Deactivation of a Trace Session is similar whether it was management or signaling activated. In either case, a deactivation request is received by the NE that contains valid trace reference results in the de-allocation of the trace session state block and a flushing of any pending trace data. In addition, if this is the last trace session to a particular TCE, the (S)FTP connection to the TCE is released after the last trace file is successfully transferred to the TCE.

Data collection is done inline by each of the NEs. In order to reduce the overhead on a per-control packet basis, a copy of the entire packet is made and stored into an internal database (DB) of packets.

The local internal path for the trace database is /hd-raid/trace.

This storage is done regardless of the trace depth. After xx bytes (or xx messages) have been stored or a configurable number of seconds have elapsed, all cached data is encoded in the standard XML format and written out to a file to be forwarded to/pulled from the TCE. If there is no TCE active, the UMTS/EPC network element will continue to cache data and create trace files as long as there is space available before stopping the trace recording session. Once the connection to the TCE becomes active, all cached data will be sent immediately to the TCE.

When a session is activated, the IP address of the TCE is supplied in the session activation request. Upon activation and if the push mode is used, a check is made to see if there is already an (S)FTP connection to the TCE. If so, it is used for all traffic associated with this trace session. If not, an (S)FTP connection is made to the TCE using the supplied IP address. Data is buffered locally and trace files generated until the connection is established. Once the connection is established, all previously created trace files are sent to the TCE. Note that the (S)FTP connection is established to the TCE at session activation regardless of whether or not a trace recording session has been triggered. The (S)FTP connection is maintained until the trace session is deactivated.

Note the following:

Support for the following standards and requests for comments (RFCs) have been added for the Session Trace feature:

Session Tracing functionality must first be enabled before a specific management, random, or signaling session trace can be configured.

The following commands enable or disable the subscriber session trace functionality based on a specified subscriber device or ID on one or all instances of a session on a specified UMTS/EPC network element.

Use the following example to enable session tracing on the UMTS/EPC network element:

config
   session trace network-element { all | ggsn | hnbgw | mme | pgw | saegw | sgw } [  file-type <a-type  |  b-type>  ]   tce-mode none | push transport  ftp | sftp  username  username encrypted password password  path  directory_path  collection timer  ctimer_value
   end

Notes:

Example:

session trace network-element saegw tce-mode push transport sftp path /SessionTrace username root encrypted password 5c4a38dc2ff61f72 collection-timer 5

Operators must create a template for a management trace in Global Configuration Mode. Management traces executed in Exec mode will use the template. Once created, the template can be associated with different subscribers to trace the interfaces configured in the template.

Note that to activate subscriber session traces for specific IMSI/IMEI, the operator will use the Exec mode session trace subscriber command specifying a pre-configured template and the IMSI/IMEI, trace reference, and TCE address.

Use the following example to configure a template for use with the session trace subscriber command:

config
   template-session-trace network-element { ggsn | hnbgw | mme | pgw | saegw | sgw } template-name template_name

Once this command is entered, the user is placed in Session Trace Template Configuration Mode. In this mode, the operator selects the interfaces to be traced for the selected network element.

For the GGSN, MME, P-GW and S-GW, enter the following command in Session Trace Template Configuration Mode:

      interface interface_name
      end

For the SAEGW, enter the following command in Session Trace Template Configuration Mode:

      { func-pgw | func-sgw } interface interface_name
      end

GGSN

Available ggsn interfaces include:

HNBGW

Available hnbgw interfaces are:

MME

Available mme interfaces include:

P-GW

Available pgw interfaces are:

SAEGW

The interfaces that can be traced on the SAEGW are broken down by the interfaces available on a P-GW configured under an SAEGW (func-pgw), and the interfaces available on a S-GW configured under an SAEGW (func-sgw).

S-GW

The available sgw interfaces are:

Session tracing functionality must be enabled before a management trace can be configured. Refer to Enabling Session Tracing for the procedure.

To configure a management session trace on the UMTS/EPC network element from Exec Mode:

session trace subscriber network-element { ggsn | hnbgw | mme | pgw | saegw | sgw } template-name template_name { imei id | imsi id } { all | interface } } trace-ref id collection-entity ip_address

Notes:

Example:

This following is a complete example showing the configuration of a subscriber management trace for all S-GW and P-GW interfaces. It consists of enabling session tracing on the SAEGW, creating the session trace template for all S-GW and P-GW interfaces, and then executing the subscriber management trace for a specific IMSI using the template.

config
   session trace network-element saegw
   end
config
   template-session-trace network-element saegw template-name saegw_all
      func-pgw interface all
      func-sgw interface all
      end
session trace subscriber network-element saegw template-name saegw_all imsi 123456789012345 trace-ref 123456789012 collection-entity 1.1.1.1

Session trace functionality must be enabled before a signaling session trace can be configured. Refer to Enabling Session Tracing for the procedure.

To configure a signaling session trace:

session trace signaling network-element { ggsn | hnbgw | mme | pgw | saegw [ func-pgw | func-sgw ] | sgw } 

Notes:

Example:

This example configures a signaling session trace for all S-GW and P-GW interfaces under an SAEGW:

session trace signaling network-element saegw 

Session trace functionality first must be enabled on the UMTS/EPC network element before a random trace can be configured. Refer to Enabling Session Tracing in this chapter for the procedure.

The following command enables or disables the subscriber session trace functionality based on a random trace on the UMTS/EPC network element. If enabled, the subscriber selection will be based on random logic for all instances of session on a specified network element.

To configure a random session trace:

session trace random range network-element { ggsn | hnbgw | pgw | saegw | sgw [ func-pgw | func-sgw ] } interface [ all | interface } collection-entity ipv4_address

Notes:

GGSN

Available ggsn interfaces are:

HNBGW

Available hnbgw interfaces are:

P-GW

Available P-GW interfaces are:

SAEGW

The interfaces that can be traced on the SAEGW are broken down by the interfaces available on a P-GW configured under an SAEGW (func-pgw), and the interfaces available on a S-GW configured under an SAEGW (func-sgw).

Available SAEGW func-sgw interfaces are:

S-GW: Available sgw interfaces are:

Example:

To enable random tracing on a range of 40 SAEGW subscribers on all S-GW interfaces and the s5 interface of the P-GW in the SAEGW, enter the following sample command:

session trace random 40 network-element saegw func-pgw interface s5 func-sgw interface all collection-entity 1.1.1.1 

To disable random session tracing for a specific network element:

no session trace random network-element { ggsn | hnbgw | pgw | saegw | sgw [ func-pgw | func-sgw ] }