December 11, 2012 at 13:19

How does mobile operator billing work?


    The platform processes InitialDP 37 ms; the subscriber listened to beeps for 10 seconds; conversation duration - a little more than 5 minutes.

    Billing collects information on the use of telecommunication services, their charging, is responsible for billing subscribers and processing payments.

    There are 2 main types of calculation:
    • Postpay - invoicing for the period based on its results (postpaid)
    • And the advance system (prepaid), when the money is entered in advance.

    Postpay appeared historically earlier, but prepayment turned out to be more convenient for customers (more controlled - just a little bit wrong, a shutdown occurs, and not a big bill).

    Postpaid system


    When a subscriber of a post-broadband settlement system uses the services of an operator, special CDR (Charging Data Record) files are generated on the switches. In fact, these are ordinary logs that indicate the subscriber’s number, date, talk time / volume of downloaded traffic, etc. Billing, at a certain time (for example, once a day) connects to the switch, downloads CDRs for itself, calculates the cost of services and stores everything in a database (usually, Oracle). Then at the end of the month the subscriber is issued a total bill.


    Scheme of interaction between the Postpaid platform and the network operator core.
    CSN - circuit switching network; Introduced by Channel Switches (MSC).
    PSN - packet switching network; Represented by packet switches and gateways (SGSN and GGSN, respectively).

    The principle of operation of the postpaid system is relatively simple, because it does not require a real-time reaction of the platform: after all, the subscriber does not need to be warned about reaching zero (and, accordingly, there is no need to change the nature of the network interaction with it).

    Advance system


    In the case of advance charging, the telecom operator, in addition to accounting for the volume of services provided, needs to solve the problem of tracking the current account of the subscriber and, if it reaches zero, inform the subscriber / disable the provision of the service. Therefore, such systems are also called Online Charging System (OCS).

    Since the operator provides different types of services and different types of networks are used (channel / packet switching system), billing has to use different charging protocols to solve the problem of monitoring the subscriber’s account, for example, the following:


    Interaction scheme of the prepaid platform with the operator’s network.

    We will analyze these protocols in more detail.

    Cap


    CAP (CAMEL Application Part) is an application layer protocol of the SS7 stack that implements intelligent services in GSM / UMTS networks (for example, prepaid).


    The place of the protocol in the SS7 stack . The figure also shows a popular version using SIGTRAN technology (SS7 extension, which allows the use of protocols "seven" over the IP network).

    Through this protocol, OCS communicates with a circuit switched network. Here is an example of an outgoing voice call charging :


    CAP billing dialog; ISUP messages are shown with dashed lines.
    1. First, a message (Initial Detection Point) arrives at the billing from the MSC1 switch, in which the subscriber's parameters are transmitted. These are incoming and outgoing numbers, cell address of the called subscriber and others. Based on this, it is possible to start a call analysis. Billing creates a specific Detection Point - that is, the state of the call. OCS determines whether a subscriber can make a voice call (is there money in the account), if so, for what maximum time.
    2. After that, the OCS responds to the Request Report BCSM Event switch (“I initialized the Detection Point, I’ll wait for further information about the call status from you”). And sends Apply Charging (“the subscriber has funds in the account, I allow the call”). The maximum time that the subscriber can use is also sent there.
    3. The switch, having received permission from OCS, initiates a voice connection between subscribers using the ISUP protocol, sending an IAM (Initial Address Message) to the MSC2.
    4. MSC2 responds in the direction of MSC1 with an ACM (Address Complete Message) message, in this case it means “yes, my subscriber, he is now online, I’m starting to call him”. Upon receiving this message, MSC1 turns on long beeps to subscriber A.
    5. Subscriber B picks up the phone, MSC2 sends MSC1 an ANM (Answer Message) - “my subscriber picked up the phone, plug them in”.
    6. MSC1 connects subscriber A and B, the conversation begins. MSC1 sends an Event Report BCSM (O_Answer) message to the OCS. OCS changes the call state for this subscriber. From this moment, charging starts (taking into account that the first 3 seconds are free).
    7. While subscribers communicate, MSC1 monitors the time for a call. If time is running out, the MSC warns the subscriber with a beep.
    8. In our case, subscriber B hangs up first, MSC1 and MSC2 make a friendly handshake using REL (Release Message) and RLC (Release Complete Message) messages.
    9. MSC1 sends an Event Report BCSM (O_Disconnect - “subscribers successfully disconnected”) and Apply Charging Report (how many seconds the conversation lasted) to OCS.
    10. OCS receives this data and responds that it is now possible to close the session.


    --- INVOKE ---
 A1 TAG: A1h [1]
 1B LEN: 27
      --- INVOKE ID ---
 02 TAG: 02h INTEGER
 01 LEN: 1
 02 INVOKE ID: 2
       === CAP ===
         --- INVOKE ---
         --- OPERATION ---
 02 TAG: 02h INTEGER
 01 LEN: 1
 23 OPERATION: 35 = applyCharging
       --- APPL CHARG ---
 30 TAG: 30h SEQUENCE
 13 LEN: 19
         --- ACH BCC ---
 80 TAG: 80h [0]
 0C LEN: 12
       --- TDC ---
 A0 TAG: A0h [0]
 0A LEN: 10
         --- MAX CPD ---
 80 TAG: 80h [0]
 03 LEN: 3
 01 19 40 MAX CPD: 4370


    This is part of the course. We see that the applyCharging message was sent via CAP, the maximum talk time (MAX CPD - Maximum Call Period Duration) is 437.0 seconds.


    I’ll duplicate the picture to kat: this is an example of communication using the CAP protocol. You can evaluate the timestamps: the platform processes InitialDP 37 ms; the subscriber listened to beeps for 10 seconds; conversation duration - a little more than 5 minutes.


    And here the call is long and it is visible how the system every 6 minutes itself asks the MSC for the call status (activityTest). This was done so that, in case of any error, the conversation would not last for days (until the subscriber has written off all the money).

    CAP protocol can charge not only voice calls - it is also able to charge Internet connections, SMS, MMS and so on. Although in practice, specially sharpened protocols (DIAMETER / OSA) are most often used for these needs.

    OSA


    OSA (Open Service Access) is an open software interface developed by the consortium of 3GPP and ETSI, often used to charge for VAS services and mobile Internet.

    Consider the operation of this protocol using the example of tariffing mobile Internet services:



    1. When trying to activate the PDP Context (receiving the IP address in the mobile operator’s network by the phone), the GGSN asks the platform whether this subscriber can activate the billing session (CreateChargingSessionReq).
    2. In our case, everything is fine (the subscriber is in the database, there are funds), the platform creates a billing session and allows you to activate PDP Context (CreateChargingSessionResp).
    3. Now the subscriber wants to start downloading data. To allow him to do this, GGSN turns to the platform with a request for reservation of funds (ReserveUnitReq). In general, unit is an abstract thing, it can be anything - a kilobyte of data, SMS, a second of conversation, a ruble, pizza, a barrel and so on. In our case, unit is 100 kB.
    4. The platform checks whether there are funds for 100 kB of traffic for this subscriber in accordance with his tariff and responds with the message ReserveUnitResp (“funds are reserved”). Having received this message from the platform, GGSN allows the subscriber to download traffic.
    5. When the subscriber downloaded the reserved portion of the traffic, GGSN addresses the platform with the message DebitUnitReq (“you can write off reserved funds”).
    6. The platform debits the funds and responds with a DebitUnitResp message (“funds successfully debited”).
    7. The ReserveUnitReq-DebitUnitResp cycle is repeated until the subscriber downloads the entire Internet, closes the Internet session.
    8. When PDP Context is deactivated, GGSN sends to the platform a message about the completion of the billing session; the memory allocated for this session is freed.



    Request debitUnitReq; OSA commands are wrapped in a SOAP protocol, which in turn is encapsulated by the HTTP protocol.

    Conclusion


    Changing customer needs (including increasing the amount of data transferred), creating new types of services, entails the evolution of the mobile operator’s network, primarily in the field of VAS platforms and billing systems.

    If you are interested in the subject matter of the protocols of the AAA family , then later I will talk about RADIUS, DIAMETER and other interesting things.

    References


    3GPP: www.3gpp.org/index.php
    ETSI: www.etsi.org
    OSA: www.3gpp.org/ftp/Specs/html-info/29198-01.htm
    ISUP: www.asknumbers.com/SS7ISUPMessages.aspx
    Tags:

    Also popular now: