The recent earthquake in Türkiye and Syria reminded everyone how important the disaster and recovery management is. Mobile network was the first part of the critical infrastructure which was involved in the emergency situation. Although it was partially damaged itself, right from the beginning it had to withstand the initial load of calls and further support coordination of AFAD responders, police, gendarmerie, soldiers, volunteers and other personnel. At the same time it had to maintain the regular calls, which were not less important. Mobile communication was helping to reunite families as well as to provide access to important information and news.
The same way everyone should recap first aid procedures time to time, operators should recap the disaster and recovery plans and emergency communication flows. I’m currently working on mobile network deployment in Mexico, where earthquakes are a common place. Therefore we take this very seriously and we know there is no excuse for us if we fail.
Let’s quickly go through the basic requirements on emergency calling in mobile networks.
Hello, hello. Finally we are getting to Voice online charging! I admit it took me a long time, it be so nice to work just on posts … As a lesson learnt I’ll start to write shorter articles 🙂 And one more improvement – I’m adding quick overview video, so that you’re quickly briefed on the basics. Please let me know, if that works.
Rx interface is often overlooked in IMS training, yet from the network core standpoint it is the most important one. It makes possible for IMS to allocate the data resources required for a media session.
As we discussed in VoLTE Policy Control, the Rx Reference point is defined between P-CSCF (referred in spec as AF) and PCRF (the PCC architecture is defined in 3GPP 23.203 and 29.212). Via this interface the P-CSCF provides session information to the PCRF. The PCRF then informs the P-CSCF of traffic plane events. It can also verify that the service information provided by the P-CSCF is consistent with the operator defined policy rules. The service information is used to derive the QoS for the media service.
The PCRF can also reject the request received from the P-CSCF. In that case the PCRF indicates the result in the answer and provides to P-CSCF the service information that can be accepted.
In December 1992 there was sent the first SMS. At that time there were several different vendors working on their first SMSCs. I was lucky enough to work later with some of the engineers involved. Anyways that is an ancient history now. Since that the SMS Service and the SMSC have become a must for every mobile network. Perhaps we can go trough the general SMSC network architecture, list some of the typical features and then to discuss the SMS evolution in 5G networks.
The SMSC was designed as an integral part of 2G mobile network, supporting several basic message flows, which are mostly valid even in 2022:
Application-to-Person (A2P/P2A). This was a real game changer. People in late 90s were texting (and paying) as crazy to get new ringing tones, text-frames on their monochromatic displays or at least a weather forecast or bus schedule. The A2P is still a popular way how to create a significant wholesale interconnection and also valid for MIoT (Mobile Internet of Things). Last but not least we shouldn’t forget the importance of SMS in Two-Factor-Authentication (2FA).
Technical enabler: Over the Air OTA messaging for (U)SIM provisioning. OTA is still critical for many operators. Another example is an IP session wake-up, which might be a key technical enabler for some Machine Type Communication MTC/MioT applications.
Today we will start with Online Charging, or Ro interface in our terminology. And because Online Charging is a bit more complex than Offline Billing, we’ll split it into several posts. In this first one we will take a look at so-call Direct-Debiting, which is used mainly for charging of SMS Service.
Perhaps from our Charging Overview you remember that we can use two different approaches to the Online Charging – Session based or Event based. SMS Ro Charging is using Event based mechanism. It is easier than the Session based and we will also need it later to complement the Session based Charging for the Voice service.
The SMS Charging architecture is standardized in 3GPP 32.274, the SMS online charging then uses the Credit-Control application as specified in TS 32.299.
Ro Reference Point for SMS
The Online Charging is triggered over Ro Reference point. It is up to a Mobile Operator if they will signal charging operations from IP-SM-GW, SMSC, SMS Router or any combination of these. Typically the charging requests are sent from SMSC only. For simplicity we will refer only to the SMSC in the following text. SMSC may either directly support Ro interface, or it can use CAP (CAMEL) protocol which is then translated to Ro by an Interworking Function (IWF) as described in 3GPP 32.293.
The SMS charging may use two different models:
Immediate Event Charging (IEC)
Event Charging with Unit Reservation (ECUR)
In this post we will rather focus on IEC, as the ECUR is more complex and in my personal experience it is less common than IEC. The ECUR principle is specified in TS 32.299.
In the last post we talked about VoLTE charging on a high level. This time we will zero-in and focus on a role of Telephony Application Server (TAS) in offline charging during a Voice/Video Call. Charging on the TAS is described in the 3GPP 32.260 and 32.275. The basic charging is fairly simple, but we also have to count with Supplementary Services, Roaming Scenarios and rainy-days scenarios.
TAS Charging, Ro, Rf
We already know that the 3GPP specification requires Network Elements like TAS to provide offline billing so that service providers can collect and correlate charging information from a variety of sources as well as to generate CDRs. An IMS system is composed of many entities that can generate charging events which need to be collated in order to generate a bill for the customer. These elements are referred in our terminology as the Charging Trigger Functions (CTF). The CTF function works in connection with TAS call processing by receiving SIP call events, translating SIP messages into Diameter messages with call parameters copied into 3GPP-defined AVP set, and sending Accounting Request(ACR) messages to the external CDF. The CDF acknowledges the receipt of ACR message by sending back an Accounting Answer(ACA) message indicating success or failure of the operation. The communication between CTF (TAS) and CDF happens over the Rf interface, which uses the Base Diameter protocol.
Charging has been for a long time on my todo list. Now it’s the time and you can expect couple of posts related to charging, mainly Online Charging. Today we’ll go through the most basic stuff. For details refer to 3GPP 32.240.
Charging is a world of its own, it has its own rules, flows and well, also documentation. To really understand how to properly charge your calls, data, or messages is probably the same or even bigger challenge than to understand the actual service.
Charging Specification – source 3GPP 32.240
GSM/UMTS/EPC networks provide functions that implement offline and/or online charging mechanisms on the bearer (e.g. EPC), subsystem (e.g. IMS) and service (e.g. SMS) levels. In order to support these charging mechanisms, the network performs real-time monitoring of resource usage for those three levels in order to detect the relevant chargeable events.
In general we recognize Onlineand Offline charging mechanisms. They may be performed simultaneously and independently for the same charging events.
Support and operation engineers don’t need to understand the majority of algorithms hidden in telecom software. But time to time it helps if you have an understanding of how some particular functionality is implemented.
The typical situation is Traffic Shaping or Overload Protection. Many operators want to understand and test, how their system behaves under a huge load of calls or messages. There are many ways how to implement these features, so let’s take a look at the most common ones.
The easiest way how to protect the system is to define some limit. For example, we can say that our SBC is able to handle only 1.2 mil. parallel calls. If we receive a new invitate which exceeds this threshold, we respond with system error.
Similarly, we can set a limit for CPU or memory consumption. Whenever we reach, let’s say 60 % of the CPU we raise an alarm and don’t allow any new call/registration. As soon as the resource utilization drops below the threshold again, we can resume the standard system behavior and accept new calls.
Sounds reasonable and simple, however, in case that the load is close to our limit – 60 % of CPU – it can lead to so called throttling causing system instability. The last thing which you desire for if you are facing high traffic.
Maybe you remember what I said about Group Messaging. That all the RCS deployments would be done faster without this feature. A similar thing we can say about VoLTE Conferencing. Ad-Hoc Multi Party Conference Call (CONF) is one of the basic requirements we have on VoLTE calling. Simply put each VoLTE network has to support conference calling. But to troubleshoot this great functionality can be a nightmare.
Ad-Hoc Multi Party Conference is one of the Supplementary Services supported by Telephony Application Server (TAS) (a dedicated Conference AS is an option too) and it is described in GSMA IR.92, which then refers to 3GPP TS 24.605 and 24.147. Today we’ll take a look at the conference call flow, along with the Mr’ interface between TAS and Media Resource Function (MRF).
Add participant button
Although we talk about conferencing, in fact it’s just a multi-party call. We don’t schedule any conference call for a given list of participants. We can only add additional numbers to an existing call. That’s why we describe the service as an ad-hoc conference. From the mobile operator point of view the conferencing service provides the means for a user to create, manage, terminate, join and leave conferences as well as the ability to update the involved parties. But most of the stuff is truly hidden to the end subscribers.
In general both voice and video conference can be supported, but only the support of audio media is required by VoLTE standard. The maximum number of participants differs network to network, usually it is between 6 and 10. Note, that the functionality is not limited to VoLTE users only, we can add to the call the CS users too.
Our current economy is digitized and generates an exponential growth of person-to-person (P2P) transactions. On the other hand we often face challenges around flexibility, trust, identity and authorization that existing financial instruments are sometimes struggling to address.
And that’s where blockchain comes into play. Blockchain is designed as a secure distributed system with high Byzantine fault tolerance. The most successful use cases for blockchain today are related to financial transactions and the management of financial assets. The most famous examples include Bitcoin, Ethereum, Ripple or Hyperledger.