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 Online and Offline charging mechanisms. They may be performed simultaneously and independently for the same charging events.
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.
It’s very interesting (and well, a bit suspicious) that the main focus of most VoLTE textbooks and trainings is signalling. But from the user-point-of-view, it is the voice data, what matters. As an end-subscriber I don’t care about signalling. My only interest is the call quality. But times they are a changin and engineers are asking about how to improve the overall voice-call quality and user experience. Today we’ll go through the basics as jitter, mouth-to-ear delay, packet loss rate or MOS, needed for QoS analysis.
For real-time multimedia we used to have dedicated telephone/radio networks. That has changed and voice/video streams are transported over IP network now.
We should understand that these IP networks were originally designed for data transport. To transport data we prefer the best-effort service model, which allows an easy network scaling and simple routers’ logic. On the other hand we don’t care much if packets arrive in-order or what are the delays between particular packets. We simply wait until we receive a whole file. If any packet is lost, TCP will re-transmit it.
Packets in Data Networks
It’s a different story with the real-time communication services though. RTC applications are less sensitive to packet loss, but they are very sensitive to packet delay. Usage of IP data network as a carrier brings a lot of challenges which have to be addressed by media protocols and network elements.
Maybe you have already heard about some features as Dynamical Network Slicing, CloudRAN, Network-as-a-Services, … Some basic 5G principals we’ll briefly discussed also in this post. However my question is: What will be the change from the real-time communication point of view? What will be the 5G calling look like? Is the IMS (IP Multimedia Services, don’t confuse with International Microwave Symposium) to stay in the operators’ networks?
5G Deployments Sep, 2019 by 5G Americas
Seems that at the first stage the change will be less dramatic than when we introduced 4G. 4G was in many ways a revolution, whereas 5G is “only” an evolution. In fact 4G and 5G, at least in the beginning, will coexist and complement one each other. Still 5G will have a big impact on our existing technologies and the way we work with telecommunication networks.
5GS + EPC + IMS
Before I’ll finish a new post about 5G I decided to take a break and create a presentation which would complement VoLTE Basic Flows.
Btw. I can’t find the option on slideshare which would allow to update the material .. does anyone know??
I have never planned to talk about such an operator specific matter as KPIs. But since I posted NEWS: Telco Monitoring I’m receiving many questions related to this topic and I guess we can discuss at least the basic principles.
Inside AT&T’s Network Operations Center by PCWorldVideos
If you have read the VoLTE standards such as GSMA IR.92 or VoLTE Service Description and Implementation Guidelines, you probably noticed that performance monitoring is more or less ignored. And at the same time all operators are asking about it. What KPIs to watch, how, what are the guidelines?
Btw. I always enjoy being in NOC (Network Operation Centre) or war or crisis rooms. Especially during events like NYE. However mostly it is not allowed to take any photos there, so instead I’ve linked some youtube videos showing the scene. Respect to you bros working day and night to keep the network running!
I’ve just recently changed my job and that reminded me, what it means to start from the beginning again. To help those of you who have just started with VoLTE/IMS I’ve created a short presentation.
Let me know if it works (and maybe one day I’ll find some to make a recording too 🙂 ). Good luck!
Even in 2017 the telephone number remains the most universal identifier for real-time communication. And as the word is moving to be All-IP, we have to be able to translate the number into something more meaningful for routing in IP networks. The GSMA organization selected for this purpose the Electronic Number Mapping System (ENUM) and in 2007 released the first version of PRD IR.67.
ENUM based Routing
Moreover Mobile Operators in over 50 countries have to support Mobile Number Portability (MNP). Although for MNP is a great feature for end subscribers, it makes the signalling more complex and costly for the Operators. The MNP is not just a problem for signalling (routing) but also for billing and management of interconnect agreements. Last but not least it can be a significant issue for content and application providers who may not be aware of the change of the operator for a particular user.