Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Charging Data Records

    The MobileNext Broadband Gateway gathers charging information in Charging Data Records (CDRs). The broadband gateway supports different charging format versions.

    The broadband gateway generates CDRs that contain the following types of information to charge a mobile station user or subscriber for accessing data from access point name (APN) networks:

    • Data volume—Amount of data sent to and received from the APN networks.
    • Duration of packet data protocol (PDP) context—Length of PDP context or call.
    • Quality-of-service (QoS) classes—Priority at which requested data is transported.
    • Roaming—Charges imposed for subscriber roaming among SGSNs belonging to a mobile operator or between different mobile operators.
    • Tariff—Charges imposed based on the time of day.

    CDRs can be delivered by the following methods:

    • CDRs are transferred directly to a charging gateway server using the GTP Prime protocol.

      The GTP Prime protocol supports UDP or TCP as the transport protocol, and IPv4 addresses. You must configure the charging gateways as GTP Prime peers. The peers can be configured for use by transport profiles as primary, secondary, or tertiary servers.

      The broadband gateway supports sending the following messages:

      • Node Alive Response—Response to Node Alive Request received from the charging gateway function (CGF). The Node Alive Request message is used to indicate that a node in the network has started its service.
      • Echo Request and Echo Response—The Echo Request message detects the path status between the CGF and the broadband gateway and should not be sent more than once every 60 seconds using UDP as the transport protocol.
      • Redirect Request—CGF can send Redirect Request messages to the broadband gateway to advise that received CDR traffic is to be redirected to another CGF or that the next node in the chain (such as a mediation device or billing computer) has lost its connection to the CGF. When the request is to redirect to another CGF, the transport profile switches to the recommended CGF only if it is configured as a peer in the transport profile; otherwise, it switches to the next highest-priority peer in the transport profile.
    • CDRs are logged to the local persistent storage and eventually retrieved by a charging gateway using the File Transfer Protocol (FTP). In broadband gateways configured with a backup Routing Engine, a mirror directory of CDRs is available.

      Local persistent storage stores the CDRs in the form of files on the Routing Engine. When the transport profile is configured to use local persistent storage for CDRs, the session DPC sends the CDRs to the Routing Engine as temporary log files. When the triggers (such as file age, file size, or CDR count) acting on the temporary log files are reached, the temporary log file is closed and moved to the final log directory where it is available for transfer by the operator. By default, the configured user or root user is authorized to access the files. However, you can configure the log files to be readable by all users.

      The final CDR log files are stored in the /opt/mobility/charging/ggsn/final_log directory in the filename format NodeID_-_RC.date_-_time[.PI].cdr, where:

      • NodeID—Name of the host that generated the file.
      • RC—Running count or sequence number, starting with the value of 1.
      • date—Date when the CDR file was closed in the format YYYYMMDD, where YYYY is the year, MM is the month (01-12), and DD is the day (01-31).
      • time—Time when the CDR file was closed in the format HHMMshhmm, where HH is the local time hour of day (00-23), MM is the local time minute of the hour (00-59), s is the sign of local time differential from UTC (+ or -), hh is the local time differential hour (00-23), and mm is the local time differential minute (00-59).
      • PI—(Optional) Private information that is explicitly configured.
      • cdr—File extension is always cdr.

    The charging gateway consolidates charges for a particular PDP context from the broadband gateway. Each CDR is marked with a charging ID that identifies the mobile station user and the particular PDP session. This charging ID correlates information generated by the broadband gateway. Each CDR also includes a Local Record Sequence Number (LRSN) that is allocated sequentially and is unique for each CDR on the same session DPC. The LRSN is the IP address of the broadband gateway and the node ID. The charging gateway uses the LRSN to identify missing records. The billing gateway uses the charging ID and the LRSN to identify CDRs. The billing gateway server generates the information used in the bill that is sent to the subscriber.

    Information Collection and CDR Generation

    Upon establishment of a PDP context, the broadband gateway opens a first partial CDR if it is configured to generate CDRs for the PDP context. The broadband gateway generates this CDR in Abstract Syntax Notation 1 (ASN.1) format. This format provides a common syntax for data transmitted between different communication systems.

    This partial CDR contains static and dynamic information. The static information includes details such as the type of record (in this case, a CDR) and the international mobile station identifier (IMSI) of the subscriber. Additional information included in the CDR is based on the dynamic usage of an APN network by the subscriber. To collect dynamic usage information, the broadband gateway monitors the uplink and downlink bearer traffic associated with a PDP context.

    A container holds the incremental statistics for the bearer. Each CDR has the containers that belong to the same bearer. Depending on the event, a container can be added to the CDR. You can configure the maximum number of containers for the CDR. Upon reaching this limit, the CDR is closed and sent to the CGF. The broadband gateway adds a container to the partial CDR each time one of the following chargeable events occurs:

    • The QoS changes.
    • The tariff changes.
    • Other charging conditions are satisfied.

    For example, if the QoS changes, a container is added. If the tariff changes, another container is added. If the QoS changes again, another container is added and so on until the maximum number of containers is reached.

    The broadband gateway adds a container to the partial CDR and closes the CDR when one of the following chargeable events occurs:

    • The PDP context terminates.
    • The time limits are exceeded.
    • The volume limits are exceeded.

    The broadband gateway closes a partial CDR and opens a subsequent partial CDR if one of the following occurs:

    • The configured number of containers for the container limit attribute is reached.
    • A configurable data volume limit for the first partial CDR is reached. Each container has a data volume count associated with the chargeable event. Initially, the first partial CDR contains one container with 0 bytes of data volume.
    • A configurable time limit for the first partial CDR is reached.
    • The maximum of five SGSN or S-GW changes is reached. A container can include a list of up to five changes.

    A very active broadband gateway has to generate a large number of CDRs. Many CDRs contain a lot of information that is not necessary for a given PDP context or is known to the charging gateway by other means. To minimize the size of the generated CDR packets, the charging configuration contains a variety of CDR attributes that can be excluded from CDRs if the information is not necessary.

    After a PDP context terminates, a broadband gateway adds a container to the current partial CDR, closes it, and delivers it to a charging gateway using the configured CDR delivery method.

    CDR Delivery

    CDR delivery to a charging gateway is based on the transport profile configuration. You can configure primary, secondary, and tertiary external charging gateways or local persistent storage in the transport profile. You must configure either the external charging gateways or local persistent storage, or both.

    To support high throughput, the distributed control plane modules on the broadband gateway independently send CDRs to the charging gateway through their own UDP/TCP communication path. However, connectivity to the charging gateway is fate-shared. Thus, when one control plane reports loss of connectivity, all control planes switch to the next charging gateway in the peer order. This behavior also applies to GTP Prime echo failure, node alive, and redirect messages. The redirect message can contain the recommended charging gateway to switch to, but the transport profile switches to this charging gateway only if it is configured in the transport profile. Otherwise, it is redirected to the next higher-priority charging gateway in the peer order.

    If the broadband gateway loses connectivity to all the charging gateways or the charging gateway is too slow, each control plane has a staging area to temporarily prevent the loss of CDRs. To prevent CDR and charging container record loss, all records are backed up to the backup control plane if redundancy is configured.


    Published: 2011-11-16