Geekly Articles each Day
📜 ⬆️ ⬇️

How does cellular operator billing work?


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

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

There are 2 main types of calculation:
Post-payment appeared historically earlier, but the prepayment turned out to be more convenient for customers (controllable - just something is wrong, there is a shutdown, and not a big bill).

Postpaid system


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

The interaction scheme of the Postpaid platform with the core network of the operator.
CSN - circuit switching network; Presented by channel switches (MSC).
PSN - packet switching network; Presented 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 platform response in real time: the subscriber does not need to be warned about reaching zero (and, accordingly, there is no need to change the nature of network interaction with it).

Advance system


In the case of an advance billing of the telecom operator, in addition to accounting for the scope of services provided, it is required to solve the task of tracking the subscriber’s current account and, if it reaches zero, inform the subscriber on / off the service provision. 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 billing protocols to solve the subscriber invoice monitoring task, for example:


The interaction scheme of the prepaid platform with the operator’s network.

Let us consider 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).


Place the protocol on the SS7 stack. The figure also shows a popular version using SIGTRAN technology (SS7 extension, which allows using the G7 protocols over an IP network).

OCS communicates with a circuit switching network using this protocol. Here is an example of charging for an outgoing voice call:


Dialogue charging according to CAP protocol, ISUP messages are shown by dashed lines.
  1. First, a message (Initial Detection Point) arrives in the billing from the switch MSC1, 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 certain Detection Point - that is, the state of the call. OCS determines whether the subscriber can make a voice call (if there are funds in the account), if possible, for what maximum time.
  2. After that, the OCS responds to the Request Report BCSM Event switchboard (“I initialized the Detection Point, waiting for further information about the call status from you”). And sends Apply Charging (“the subscriber has funds on 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, initializes the voice connection between subscribers via the ISUP protocol, sending an IAM (Initial Address Message) message to the MSC2.
  4. MSC2 responds to MSC1 with ACM (Address Complete Message), in this case it means “yes, my subscriber, he is now on the network, starting to call him”. Having received this message, MSC1 includes long beeps to subscriber A.
  5. Subscriber B picks up the phone, MSC2 sends an ANM (Answer Message) to MSC1 - “my subscriber picked up the phone, connect them”.
  6. MSC1 connects subscriber A and B, the conversation begins. MSC1 sends an Event Report BCSM (O_Answer) message to OCS. OCS changes the call status for the subscriber. From this moment the charging begins (taking into account that the first 3 seconds are free).
  7. While subscribers are talking, MSC1 keeps track of the time for a call. If time is short, the MSC alerts the subscriber with a beep.
  8. In our case, subscriber B is the first to hang up, MSC1 and MSC2 make a friendly handshake using REL (Release Message) and RLC (Release Complete Message) messages.
  9. MSC1 sends Event Report BCSM (O_Disconnect - “subscribers have successfully disconnected”) and Apply Charging Report to OCS (how many seconds the conversation lasted).
  10. OCS accepts 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 trace. We see that the applyCharging message is sent via CAP, the maximum talk time (MAX CPD - Maximum Call Period Duration) is 437.0 seconds.


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


And here the call is long and you can see how the system itself requests the status of the call (activityTest) from MSC every 6 minutes. This was done in order that, in the event of any error, the conversation did not last for days (until the subscriber writes all the money).

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

OSA


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

Consider the operation of this protocol on the example of mobile Internet service pricing:



  1. When an attempt is made to activate the PDP Context (the phone receives an IP address in the mobile operator’s network), the GGSN asks the platform if this subscriber can activate the charging session (CreateChargingSessionReq).
  2. In our case, everything is good (the subscriber is in the database, there are funds), the platform creates a billing session and allows you to activate the PDP Context (CreateChargingSessionResp).
  3. Now the subscriber wants to start downloading data. To allow him to do this, GGSN requests the platform to reserve funds (ReserveUnitReq). In general, a unit is an abstract thing, it can be anything - a kilobyte of data, text messages, a second conversation, a ruble, pizza, a barrel, and so on. In our case, the unit is 100 KB.
  4. The platform checks whether there are funds for 100 kB of traffic for this subscriber, in accordance with its tariff, and responds with a ReserveUnitResp message (“funds are reserved”). By accepting this message from the platform, the GGSN allows the subscriber to download traffic.
  5. When the subscriber downloaded the reserved portion of traffic, GGSN accesses the platform with the message DebitUnitReq (“you can write off reserved funds”).
  6. The platform debits funds and responds with a DebitUnitResp message (“funds successfully withdrawn”).
  7. The ReserveUnitReq-DebitUnitResp cycle is repeated until the subscriber downloads the entire Internet and closes the Internet session.
  8. When the PDP Context is deactivated, the GGSN sends a message on the completion of the billing session to the platform; the memory allocated for this session is released.



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

Conclusion


Changes in customer needs (including an increase in the amount of transmitted data), the creation of new types of services, entails the evolution of the mobile operator's network, primarily in the field of VAS platforms and billing systems.

If the subject of the AAA family of protocols is interesting to you, then I will tell you later about RADIUS, DIAMETER and other interesting things.

Links


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

Source: https://habr.com/ru/post/162175/

More articles:


All Articles