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.
RCS could be probably deployed much faster if it wasn’t that general right from the beginning. To implement a simple 1-1 chat is not a big deal. The same applies for voice and video. And honestly one doesn’t expect much from a new product as long as the basic functionality is working fine.
Well, in case of RCS/RCSe group messaging was always referred as a basic one. But sometimes it was not without struggles. There are many ways how a Conference can be established. Just to find out all the relevant RFCs is not an easy task. RCS Group Chat technical realization is based on the “Ad-Hoc Session Mode messaging”. RCS is referencing to OMA-SIMPLE or OMA-CPM. OMA is defining their ways how to handle the chats and pointing to particular RFCs. Many of them. The basic one is the RFC 4353. In this document it is described the logical architecture. Simply put group messaging is a multi 1:1 chat. All the participants will establish a 1:1 chat with a center point called “focus”. This logical role is implemented as a part of RCS (CPM/SIMPLE) server functionality.
Group Chat – focus
As mentioned, in case of RCS we mostly talk about ‘Ad-hoc’ conferencing. That means that the conference does not need to be scheduled or reserved, but is created “on the fly”. The benefit of this approach is that the conference URI doesn’t need to be known to the user; instead it is created by the focus (RCS server) and used by the participants’ UAs. The SIP URI of the Conference Factory is usually provisioned in the client (as in a “create new conference” button). Continue reading
Very funny. Even in 2015 we still rely in many ways on the old good SMS. No, operators are not making the money on the service as they were used to in the past. However it is not easy for them to fully replace the service (e.g. by RCS). That’s why the VoLTE standard GSMA IR.92 says:
The UE must implement the roles of an SM-over-IP sender and an SM-over-IP receiver, the IMS core network must take the role of an IP-SM-GW.
In other words, the VoLTE network has to support the (legacy) SMS sent over SIP. The VoLTE phone will receive a common (binary) SMS and the native client will display this message as any other. The only difference is that this time the SMS is sent from an IMS network over SIP protocol. Mind the purpose is not just to support common text messages, but (more importantly) to support OTA messaging for (U)SIM provisioning, SMS ‘non-text’ applications or Message Waiting Indication for Voice Mail.
SMS over IP
The network functionality which provides messaging service in the IMS network is called IP-SM Gateway (IP-SM-GW) and from the IMS point of view it is an Application Server.
Instant (multimedia) messaging is a key feature for RCS as it should replace SMS service. There are more types of messages which can be sent through the IMS network.
When we will take a look on the SIP indication of capabilities by Accept header there are quite a few of supported formats:
For common Instant Messages we typically use Common Profile for Instant Messaging (CPIM). This format allows compatibility among various messaging technologies. Notifications are then sent as in Instant Message Disposition Notification (IMDN) format.
Messages can be exchanged over SIP or MSRP protocol. Sometimes also http/ws is being used for transfer of rich content.
Update: For the information about RCS Universal profile read the post GSMA Advanced Messaging – RCS Universal Profile.
RCS 5.2 defines two basic types of messaging. They are the Session Mode Messaging which is based on SIP INVITE and MSRP session and the Pager Mode Messaging which is based on SIP Message. The RCS refers to OMA CPM which is considered to be an evolution of the SMS/MMS messaging services.
Note that SIP MESSAGE can be used also for other than messaging purposes in IMS network (e. g. during eSRVCC registration)
Session Mode Messaging
Session mode does use SIP INVITE and SDP protocol to establish the session. Within the session MSRP protocol is used. This allows to split ones conversation into dialogs and use “..is typing” notifications. On the other hand more resources is needed.
IMS and MSRP