SmartFren

Messaging

Solution Description

Version 9
2015-11-17

Confidential. Version: 9
Page 1 of 72
Contents
HISTORY ........................................................................................................................................................... 4
1. INTRODUCTION ....................................................................................................................................... 5
1.1 DOCUMENT GOAL ................................................................................................................................. 5
1.2 INTENDED AUDIENCE ............................................................................................................................ 6
1.3 GLOSSARY........................................................................................................................................... 6
1.4 REFERENCES ....................................................................................................................................... 8
2. SOLUTION OVERVIEW ............................................................................................................................ 9
2.1 MESSAGING SOLUTION OVERVIEW ........................................................................................................ 9
2.2 LIST OF MAVENIR SYSTEMS AND OVERVIEW ........................................................................................ 10
2.3 LIST OF 3RD PARTY SYSTEMS AND OVERVIEW ...................................................................................... 13
2.4 TIMEZONES ....................................................................................................................................... 13
2.5 ACCESS DEVICES............................................................................................................................... 14
3. SMSOIP ................................................................................................................................................... 15
3.1 AIRMESSENGER SMS ROUTER .......................................................................................................... 15
3.1.1 SMS Router Service-level Interworking ................................................................................... 16
3.2 AIRMESSENGER MESSAGE STORE...................................................................................................... 16
3.3 IPSM GW ......................................................................................................................................... 18
3.3.1 IPSM GW Transport-level Interworking ................................................................................... 18
3.3.2 IPSM GW Ro Interface Support............................................................................................... 19
3.4 PROVISIONING ................................................................................................................................... 19
3.5 ROAMING ........................................................................................................................................... 19
3.6 BILLING ............................................................................................................................................. 19
3.7 FUNCTIONAL INTERFACES ................................................................................................................... 19
3.7.1 AirMessenger SMS Router supports the following standard interfaces ................................ 19
3.7.2 IPSM GW supports the following standard interfaces ............................................................ 19
3.8 IMS REGISTRATION............................................................................................................................ 20
3.8.1 Refresh-Registration ................................................................................................................ 22
3.8.2 Registration with Messages Waiting ........................................................................................ 23
3.8.3 Deregistration........................................................................................................................... 23
3.9 CALL FLOWS ...................................................................................................................................... 24
3.9.1 MT SMS to CS ......................................................................................................................... 24
3.9.2 MT SMS to IMS........................................................................................................................ 25
3.9.3 User not in IMS ........................................................................................................................ 25
3.9.4 Deferred Delivery ..................................................................................................................... 26
3.9.5 MO IMS to IMS ........................................................................................................................ 27
3.9.6 MO IMS to CS .......................................................................................................................... 28
3.9.7 MO IMS to CS (Charging Failure)............................................................................................ 29
3.10 ANSI-41 SPECIFICS ........................................................................................................................... 30
3.10.1 REGNOT Mandatory parameters ............................................................................................ 30
3.10.2 Electronic Serial Number: ........................................................................................................ 30
3.10.3 Mobile Identification Number: .................................................................................................. 31
3.10.4 MSCID: .................................................................................................................................... 31
3.10.5 QualificationInformationCode .................................................................................................. 32
3.10.6 SystemMytype ......................................................................................................................... 32
4. RCS SERVICES ...................................................................................................................................... 33
4.1 PROVISIONING ................................................................................................................................... 33
4.2 BILLING ............................................................................................................................................. 34
4.2.1 Online/Alternate Billing methods.............................................................................................. 34
4.2.2 Immediate Event Charging ...................................................................................................... 34
4.2.3 Event Charging Triggers .......................................................................................................... 35
4.2.4 OCS rejection........................................................................................................................... 36
4.2.5 CDRs ....................................................................................................................................... 36
4.3 MULTI-DEVICE ................................................................................................................................... 36
4.4 INTERACTIONS: .................................................................................................................................. 36

Confidential. Version: 9
Page 2 of 72
 4.5 FUNCTIONAL INTERFACES ................................................................................................................... 36
4.6 REGISTRATION ................................................................................................................................... 37
4.6.1 De-Registration ........................................................................................................................ 38
4.6.2 Third party refresh- registration ............................................................................................... 39
4.7 1 – 1 CHAT ......................................................................................................................................... 40
4.8 GROUP CHAT ..................................................................................................................................... 41
4.9 FILE TRANSFER / IMAGE SHARE / GEOLOCPUSH .................................................................................. 42
4.10 RCS CHAT TO SMS INTERWORKING ................................................................................................... 44
4.10.1 Chat to SMS............................................................................................................................. 44
5. PRS, XDMS AND AG .............................................................................................................................. 45
5.1 PRESENCE SERVER ........................................................................................................................... 46
5.2 RESOURCE LIST SERVER.................................................................................................................... 46
5.3 XDMS............................................................................................................................................... 46
5.4 AG .................................................................................................................................................... 48
5.4.1 Implementation for SF ............................................................................................................. 49
5.5 USE CASES ....................................................................................................................................... 50
5.5.1 Third Party Register at Presence AS. ..................................................................................... 50
5.5.2 Publication call-flow: ................................................................................................................ 51
5.5.3 Watcher-Info Subscription ....................................................................................................... 51
5.5.4 List Subscription call flows: ...................................................................................................... 52
5.5.5 XCAP Call FLow ...................................................................................................................... 54
6. MINGLE AND CCPS ............................................................................................................................... 55
6.1 CLIENT CONFIGURATION AND PROVISIONING SERVER .......................................................................... 55
6.2 CCPS SUBDB ................................................................................................................................... 56
7. NETWORK MANAGEMENT ................................................................................................................... 57
7.1 OAM SOLUTION OVERVIEW ................................................................................................................ 57
7.2 MAVENIR ELEMENT MANAGEMENT SYSTEM (EMS) .............................................................................. 57
7.2.1 EMS Architecture ..................................................................................................................... 58
7.3 EMS SUBSYSTEM .............................................................................................................................. 60
7.4 FAULT MANAGEMENT ......................................................................................................................... 60
7.5 CONFIGURATION MANAGEMENT .......................................................................................................... 62
7.6 ACCOUNTING MANAGEMENT ............................................................................................................... 64
7.7 PERFORMANCE MANAGEMENT ............................................................................................................ 64
7.8 SECURITY MANAGEMENT .................................................................................................................... 65
8. DEPLOYMENT ........................................................................................................................................ 67
8.1 NODE PLACEMENT ............................................................................................................................. 67
8.2 RESILIENCE ....................................................................................................................................... 67
8.2.1 Local Redundancy ................................................................................................................... 67
8.2.2 Geo Redundancy ..................................................................................................................... 68
8.3 DIMENSIONING ................................................................................................................................... 69
8.3.1 SMSoIP requirements .............................................................................................................. 69
8.3.2 SMS Router and Message Store Requirements ..................................................................... 69
8.3.3 RCS requirements ................................................................................................................... 70
8.3.4 PRS requirements ................................................................................................................... 70
8.4 BOM ................................................................................................................................................. 71
8.4.1 For IP-SM-GW ......................................................................................................................... 71
8.4.2 For SMS Router ....................................................................................................................... 71
8.4.3 For RCS and IP-SM-GW ......................................................................................................... 71
8.4.4 For PRS ................................................................................................................................... 72

Confidential. Version: 9
Page 3 of 72
History
Version Date Author Changes

0.1 14/1/2015 Mike Aguilar Initial draft

1 10/2/2015 Mike Aguilar Draft for internal review
2 17/2/2015 Mike Aguilar Stable draft for review
3 22/2/2015 Mike Aguilar Cleanup
4 3-30-2015 Mike Aguilar For internal Review
5 4-03-2015 Mike Aguilar Update after review
6 4-26-2015 Mike Aguilar Further review updates
7 4-30-2015 Mike Aguilar Distributed to Customer
8 10-08-2015 Mike Aguilar Added reference to Roaming SolDesc
9 11-17-2015 Mike Aguilar Clarified Chat – SMS interworking

Confidential. Version: 9
Page 4 of 72
1. Introduction
SmartFren (SF) is an existing mobile operator in Indonesia with around 6.5M subscribers. SF intends to launch
VoLTE and Enhanced Communication Services on top of their existing CDMA network. As a CDMA operator,
SF strategy has been to offer advance services based on their partnership with Qualcom and CDMA device
manufacturers. Continuing with this strategy, for the new IMS/LTE network, SF will be introducing Single-
Radio LTE (SR-LTE) devices which are able to access both CDMA and LTE RAN simultaneously using SR-LTE
technology. This technology allows the UE to selectively choose the domain from which to obtain the
particular service, e.g. Voice service on CDMA1X and data services on LTE.

On top of SR-LTE, SF has also chosen Mavenir to embed the Mingle VoLTE + RCS client onto SF developed
UEs. This allows the user to use only one dialer – native dialer to access services such as voice and messaging
no matter what underlying RAN technology is used (CDMA, LTE or WiFi).

As SF cannot force their subscribers to use only their developed UEs. Subscribers who choose a device from
“open market handsets” (OMH) can still avail of SF’s advance services by using Mingle as an OTT client.

SF also requires multi-device capabilities for SIM-less devices such as Mifi dongles, tablets and PCs. For this,
SF has chosen webRTC technology as its client. Mavenir will provide a webRTC gateway that will allow these
webRTC clients to act like a normal IMS client on the Gm interface.

Similar to other CDMA operators, SF would like to migrate all of their subscribers from CDMA to LTE/VoLTE
in a short timeframe (1-2 years). SF’s current CDMA network is provided by ZTE – CDMA RAN, MSCs, HLR,
SCP, OSS/BSS and other value added service (VAS) nodes such as CRBT and voicemail. SF’s new network will
have multiple vendors on the RAN and EPC.

The IMS network together with the application servers: TAS, RMS and PRS will be provided by Mavenir. OSS
and BSS continue to be provided by ZTE, this include the OCS, HSS and NMS systems.

The new network will have to interwork with the legacy network to support a smooth migration. Particularly
for VAS, the existing legacy nodes will continue to be used: CRBT, Voicemail, Miss Call Alert by both the CDMA
network and the IMS network.

1.1 Document goal

This document describes the messaging solution for SF new IMS/LTE network. For the purpose of this
document, Messaging includes the following services:

- SMSoIP and transport level interworking with legacy SMS

- RCS 5.1/5.2 applications such as 1-1 chat, group chat, file transfer
- Enhanced address book using Presence, Resource List and XDMS services

To provide the above services, on top of the standard IMS Access and Core components, the following
Mavenir products are required:

Application Servers
- RMS: IPSM GW
- SMS Router
- RMS: RCS AS
- PRS: Presence and RLS servers

Confidential. Version: 9
Page 5 of 72
Support Nodes
- XDMS: network based address book XML database
- AG: Application Gateway/Authentication Gateway for network access via internet (for PRS & XMDS)
- Mingle Client – both embedded and OTT
- CCPS: client configuration and provisioning server to configure the RCS client (Mingle)

1.2 Intended audience

Intended audience of this document is SmartFren and Mavenir Systems teams working on the SF IMS project.

1.3 Glossary

Item Definition
3GPP Third Generation Partnership Program
ACL Access Control List
AMR Adaptive Multi-Rate (also called AMR-NB)
AMR-WB Adaptive Multi-Rate – Wide Band
AP Aggregation Proxy
A-SBC Access SBC
BGCF Breakout Gateway Control Function
CAMEL Customized Application for Mobile Enhanced Logic
CDR Call Detail Record
CSCF Call Session Control Function
CTAS Converged TAS
DNS Domain Name Server
EMS Element Management System
EPC Evolved Packet Core
FCAPS Fault, Configuration, Accounting, Performance and Security
GSM Global System For Mobile
HSS Home Subscriber Server
HTTP Hyper Text Transfer Protocol
IBCF Interconnection Border Control Function
I-CSCF Interrogating CSCF
ICS IMS Centralized Services
IFC Initial Filter Criteria
IM Instant Messaging
IMPI IMS Private User Identity
IMPU IMS Public User Identity
IMS IP Multimedia Subsystem
IMSI International Mobile Station Identifier
IP Internet Protocol
IP CAN IP Connectivity Access Network
IP SM GW IP Short Message GateWay
I-SBC Interconnect Session Border Controller
LEA Lawful Enforcement Agency
LI Lawful Interception
LIG Lawful Interception Gateway

Confidential. Version: 9
Page 6 of 72
LIMs Lawful Interception Management Server
LTE Long Term Evolution
MAP Mobile Application Part
MGCF Media Gateway Controller Function
MGW Media Gateway
MRF Media Resource Function
MSC Mobile Switching Centre
MSISDN Mobile Station Integrated Services Digital Network
MSRP Message Session Relay Protocol
MSS Mobile Switching Server (Soft switch)
NMS Network Management System
NTP Network Time Protocol
OAM Operation, Administration and Maintenance
OCS Online Charging Subsystem
OSS Operation Support System
OTT Over the Top Application
P-CSCF Proxy CSCF
PS Presence Server
PSTN Public Switched Telephone Network
QoS Quality of Service
RCS Rich Communication Suite
RLS Resource List Server
RMS Rich Messaging Server
RTP Real Time Protocol
SBC Session Border Controller
S-CSCF Serving CSCF
SCC Service Centralization and Continuity
SCC AS Service Centralization and Continuity Application Server
SDP Session Description Protocol
SFTP Secure File Transfer Protocol
SIP Session Initiation Protocol
SNMP Simple Network Management Protocol
SOAP Simple Object Access Protocol
TAS Telephony Application Server
TCP Transmission Control Protocol
TCSI Terminating Camel Subscription Information
UAG Universal Access Gateway
UDP User Datagram Protocol
UE User Equipment
URI Unified Resource Identifier
VCC Voice Call Continuity
VCC-AS VCC Application Server
VoLTE Voice over LTE
WebRTC Web Real Time Communication
WebRTC GW WebRTC Gateway
XDMS XML Document Management Server

Confidential. Version: 9
Page 7 of 72
1.4 References
[1] B2 - Annex 1 - Smartfren -IMS VoLTE RCS Solution - Technical Proposal - v3_3

[2] B2 - Annex 2 - Smartfren VoLTE RCS Dimensioning guidelines and Technical Bill of
Material for Smartfren v3_0

[3] SMS TADs Feb16-2015 v1

[4] IPSM GW Ro Interface specification

[5] AirMessenger SMS Router Product Description

[6] AirMessenger Store Product Description

[7] 3GPP 23.040

[8] 3GPP 29.002

[9] ANSI-41 North American MAP

[10] IS-637 CDMA SMS

[11] SF Roaming SolDesc v08

Confidential. Version: 9
Page 8 of 72
2. Solution Overview
The following network diagram shows the overall solution for the SF IMS project.

SMS Router/Store

MML/SOAP
MAP for USSD CB

CG

SIP-T

SIP/

SIP to other IMS

CCPS

S2b
ePDG

internet Gm

HTTP

WebRTC client RCS Client (incl.

VoWifi calling
capability)

2.1 Messaging Solution Overview

The messaging solution provides the following services:
- SMSoIP via Mavenir’s SMS Router and RMS:IPSM GW node interworking with the existing SMSC,
MSCs and HLR
- RCS 5.1 services via the RMS:RCS AS node
- Presence and Resource List Servers interworking with the XDMS
- Application Gateway (AG) that allows UE to access presence and contact information via
HTTPS/XCAP.

Confidential. Version: 9
Page 9 of 72
2.2 List of Mavenir Systems and Overview

The following table provides the list of the Mavenir systems offered as part of the end-to-end solution. The
detailed list of components and sites considered for this project are covered in the CIQ which is part of the
Low Level Design documentation. Those in grey font are not required for the messaging solution.
Table 1: Mavenir Components List Overview
Mavenir Node Overview Functionalities
Included

This application server provides the voice and video services SCC AS
to the SF IMS subscribers. These subscribers can be using
TAS any of the following access methods: VoLTE or VoWiFi; TAS
NBative or downloadable client; webRTC client
USSI GW

Mavenir IMS core (IMC) interacts with the application S-CSCF

S-CSCF modules TAS and IP-SM-GW, authentication entity HSS and
the SF CS network via the MGCF. This is the core BGCF
component of the IMS solution and all the IMS application
servers interact with it as per 3GPP specifications. The IMS I-CSCF
I-CSCF core is interchangeably referred as CSCF or IMC in the
present document.

Universal Access Gateway (UAG) provides the SBC P-CSCF

functionality in the IMS network as well as the Proxy-CSCF
(P-CSCF) functionality for different types of access (VoLTE, A-SBC
VoWiFi, webRTC. It provides all the standard functions like
UAG media anchoring, transcoding, media transfer, firewall, IMS-AGW
access control functionality of a standard SBC. This is the
first point of contact for an IMS capable handset into the E-CSCF
IMS network.
webRTC GW

AG provides the Aggregation Gateway functionality of AP

AG translating/proxying the XCAP URLs on the Ut interface.
BSF

Media Resource Function (MRF) is used in conjunction with MRFC

TAS to provide announcements to the VoWifi network. It
MRF interacts with TAS on the control plane and interacts with MRFP
UAG for the media plane.

The IP-SM-GW is an IMS Application Server entity which IP-SM-GW

offers SMS services over IP for all the SF IMS subscribers.
IP-SM-GW IP-SM-GW provides transport-level interworking from SMSoIP to GSM
SMSoIP to GSM MAP thereby allowing IMS subscribers to transport level
send and receive SMS from the legacy networks (CDMA, interworking
3G..)

Confidential. Version: 9
Page 10 of 72
Mavenir Node Overview Functionalities
Included

AirMessenger Router gives mobile operators the traffic FDA, ANSI41 to GSM
capacity expansion and optimized SM routing required to Service level
AirMessenger launch new high-value applications, creating new revenue interworking
SMS Router streams and exciting new entertainment and information
services for their customers while maintaining the overall
QoS of the SMS service.

AirMessenger Store works in conjunction with SMS Deferred Delivery

AirMessenger Router for deferred delivery in case of FDA
failure cases. AirMessenger Store intelligent message SMPP interface to
AirMessenger AirMessenger Router
engine uses sophisticated retry schedules to maximize the
Store
probability of delivery , even to subscribers who have
temporarily turned off their mobile phones or are out of
network coverage.

The RCS application server provides the RCS services: 1-1 GSMA RCS 5.1 services
RCS AS Chat, Group Chat, File Transfer, Image Share and
Geolocation push.

Presence and Resource List Servers OMA SIMPLE v1.0.1

PRS PRS is the Presence and Resource list server. It allows for
periodic updating of the status and tagline information of a
user’s contact in the XDMS.

XDMS XML Database Management Servers Ut, XCAP

Enhanced Packet Data Gateway Media Anchor

ePDG Provides for mobility (handover) between VoLTE and Entry point for non-
VoWiFi LTE access networks

Mavenir Client Configuration and Provisioning Server (CCPS) CCPS

provides a client provisioning and configuration solution
based on the RCS auto configuration architecture. This is
CCPS based on the client performing HTTP requests to a
dedicated server that manages configuration data and
interacts with customer’s IT and network platforms to
authenticate and control client behavior.

Confidential. Version: 9
Page 11 of 72
Mavenir Node Overview Functionalities
Included

This is the RCS Client offered by Mavenir. The client is VoWifi, VoLTE Client
downloaded on the handset and interacts with the handset
components to latch on a Wifi or LTE connection and RCS Client
Client
register with the SF IMS network. Once registered, the
Client will work seamlessly to offer voice/video call, RCS and Presence
SMS services over IP to the end user.

Confidential. Version: 9
Page 12 of 72
2.3 List of 3rd Party Systems and Overview
Table 2: 3rd Party Nodes Overview

Functionalities
3rd Party Node Overview Included

HSS provides the Home Subscriber Service as per IMS 3GPP HSS
standard and provides a 3GPP standard interfaces to the
IMS core and Application servers for subscriber profile Subscriber Database
exchange and other functions.
HSS & Sub DB
Subscriber Database (Sub-DB) hosts the list of all the IMS
subscribers and subscriber profile content. Sub-DB is an
Oracle based high performance database entity.

Home Location Register for the CS CDMA network ANSI-41

HLRe

CDMA Short Message Service Center ANSI-41

SMSC Store & Forward

Online Charging itf

Online Charging System Ro Interface

OCS IEC for SMS and RCS

applications

Charging Collection Function Periodic SFTP pull

CCF/Billing
System

2.4 TimeZones
Mitel nodes present time in the form of UTC+Offset. This way, the actual time can be interpreted
dependent on the region within Indonesia where the service was performed.

Confidential. Version: 9
Page 13 of 72
2.5 Access Devices
The following devices will be used by the subscriber in accessing SF network.

1. SF custom UEs

These are UEs custom-developed for SmartFren using Single Radio LTE (SR-LTE)
technology. SR-LTE allows the device to camp on both CDMA and LTE radio. Depending
on the available radio signal and its quality, the device can switch between CDMA and IMS
access. CDMA access uses the native dialer and the CDMA A-interface. IMS uses Mingle
embedded with the native dialler and either WiFi or LTE Gm interface.

2. OMH (other manufacturer handset) – smartphones

These smartphones will use CDMA access when in CDMA only coverage. As soon as there
is sufficient WiFi or LTE signal, the smartphones can use the downloaded Mingle client.

3. SIM-less devices or Dongle / MiFi / CPE

These UEs will use webRTC as client

For the first two, Mingle will be the user interface to access SMSoIP, RCS and PRS services.
webRTC as a client will be discussed in a separate solution description.

More information on Mingle is provided in chapter 6.

Confidential. Version: 9
Page 14 of 72
3. SMSoIP
The overall SMSoIP Messaging solution is shown in the figure below:

SF CDMA NW

CDMA ANSI-41
MSC
OCS SMSC 3gpp2 payload
A MSC B
3gpp2 payload
ANSI-41

SMSoIP in GSM (3GPP) UAG

payload format
P-CSCF
Ro

C
OLO (GSM)
D GSM
IMC GSM IWF MSC
HLRe MSC
I/S-CSCF
E
Roaming GSM
GSM HLR
IPSM does 3rd party ANSI-41
SMSC
registration, incl. SMSREQ
updating subs
profile in HLRe to IPSM SMS
ANSI-41
3gpp2 payload
set the GSM GSM MAP Router *GSM MAP
SMSADDR=SMS 3gpp payload 3gpp payload
Router using ANSI- SMS Router: New Mavenir node to do GSM to ANSI-41 MAP and 3gpp to 3gpp2 payload transcoding. For
41 REGNOT Terminating Access Domain selection, it will use the SMSAddr received from HLRe during SMSREQ
interaction. If SMSAddr = SMS Router address, it then sends MT SMS towards IPSM-GW

*GSM MAP Note: From SMS Router direct to OLO SMSC is not planned in the initial phase. This
can be done at a later stage once IOT has been established between SF SMS Router
(AirMessenger) and the OLO network.

3.1 AirMessenger SMS Router

The AirMessenger Router for SMS is responsible for the intelligent handling and optimized delivery
of P2P, P2A, and A2P SMS traffic.

For the SF project, it will accept incoming SMS from the CDMA network via the existing CDMA SMSC
and will deliver IMS originated SMS to the CDMA network directly to the CDMA MSCs based on the
SMSAddr field stored on the HLRe (CDMA HLR).

The SMS Router will also provide FDA (First Delivery Attempt) as shown in the figure below. This
will relieve the existing CDMA SMSCs from having to store all SMS before delivering.

Confidential. Version: 9
Page 15 of 72
3.1.1 SMS Router Service-level Interworking

This type of interworking allows conversion of MAP signalling: ANSI-41 to GSM and SMS payload: 3gpp to
3gpp2. For the SF project, this is required to be able to interwork with SF’s existing CDMA network.

3.2 AirMessenger Message Store

The AirMessenger Store is an intelligent storage and retry engine that can be used for deferred SMS delivery.
In case of first delivery attempt failure, the SMS Router will send the SMS to AirMessenger Store which will
apply the retry algorithm configured for different types of users.

In summary, Message Store provides

- Scalable storage
- Independent scalable storage for messaging platforms - can interwork with other SMSCs using
SMPP
- Built-in Intelligence for QoS and SLA speeds delivery
- Queue management and intelligent retry based on prioritization and recipient availability
- Active congestion management of traffic and load-balancing
- Easy operation and maintenance reduces costs
- Integrated management tools for message tracing and comprehensive traffic statistics

The benefits to SF are described in the following table. More information is provided in reference [6]
AirMessenger Message Store Product Description.

Confidential. Version: 9
Page 16 of 72
Confidential. Version: 9
Page 17 of 72
3.3 IPSM GW

CCF SMSC HLRe

Rf ANSI-41 MAP ANSI-41 MAP

Rich Messaging Server

(RMS)

RCSe AS IP SM GW

Sh

HSS ISC Mavenir component

Cx Operator or 3rd party Component

S-CSCF
Currently not used in this phase
SIP / MSRP
Mw

P-CSCF

Gm SIP / MSRP

IMS UE

Mavenir’s IPSM GW is part of the RMS product. The IP SM GW provides SIP to MAP interworking for
conversion of SIP: Message to SMS and delivery towards the legacy or other IMS networks. The functions of
the IP-SM GW for this messaging solution are described below.

3.3.1 IPSM GW Transport-level Interworking

This type of interworking is performed on behalf of SIP clients that support SMSoIP messages as defined by
3GPP TS 24.341. IPSM GW need only provide interworking at the transport layer, allowing the RPDU to pass
between SIP and the MAP legacy interface. Messaging clients indicate support for SMSIP via the
+g.3gpp.smsip feature tag during registration.

This interworking is useful for enabling SMS-specific services in the SIP domain which are not defined by any
SIP standard. Examples include SMSoIP delivery to CS domain, SMS delivery to IMS domain and other
network services that require an SMS notification towards the IMS user.

Confidential. Version: 9
Page 18 of 72
3.3.2 IPSM GW Ro Interface Support

IPSM GW can provide online charging using the Diameter Ro interface towards the OCS. IPSM GW uses
Immediate Event Charging (Debit/Refund) method for charging SMS. Use of refund is configurable.

More details on this interface are provided in reference [4] IPSM GW Ro Interface specification.

3.4 Provisioning
For this project, there is no specific subscription information that is required to be provisioned and stored
on the HSS.

IPSM GW will use a default profile that is common amongst all SF subscribers.

There is no subscriber provisioning for the AirMessenger SMS Router foreseen in this phase of deployment.

3.5 Roaming
For S8 and GSM based roaming, details are provided in ref. [11] SF Roaming Solution Description v08.

3.6 Billing
Online billing will be provided by IPSM GW for SMSoIP initiated from IMS. The IPSM Ro implementation is
the same IEC Debit / Refund mechanism as with RCS services – see below. Note IPSM GW provides online
billing only for SMSoIP initiated by an IMS subscriber. CDMA NW originated SMS will continue to be handled
by the CDMA SMSC.

Mavenir’s Ro interface specification is provided in reference [4].

For statistical and revenue assurance purposes CDR files will be provided by IPSM GW and AirMessenger
Router .

3.7 Functional Interfaces

3.7.1 AirMessenger SMS Router supports the following standard interfaces

 GSM MAP and payload – to IPSM GW to send/receive SMS to/from CS domain

 ANSI-41 MAP and payload – to CDMA MSCs to send SMS to CS domain and from CDMA SMSC to
receive SMS from CS domain
 ANSI-41 MAP – to HLRe to obtain the SMSAddress for SMS delivery
SMS Router and Message store communicate via SMPP.

3.7.2 IPSM GW supports the following standard interfaces

 ISC – Connectivity to IMS core (S-CSCF)

Confidential. Version: 9
Page 19 of 72
  DNS - RMS connects to DNS DB over DNS protocol to do address resolution for given FQDN. RMS
supports both IPv4 and IPv6 addressing. This means RMS has both IPv4 and IPv6 addresses assigned
to be used while communicating with remote end.

 ANSI-41 MAP – to HLRe to register IPSM GW as the SMSAddress during Third Party Registration.

3.8 IMS Registration

IPSM GW is a 3GPP TS 24.229 compliant IMS Application Server which supports both methods of obtaining a
subscriber’s registration information, specifically via 3rd party REGISTER inclusion of the UE registration and
registration response messages, or via subscription to the “reg” event towards the S-CSCF. Mavenir
recommends the former as it avoids the cost associated with stateful subscription dialogs at the AS and S-
CSCF.

When the user registers on IMS, IPSM-GW as part of third-party registration (TPR) will interact with the HLRe
using ANSI-41.

Confidential. Version: 9
Page 20 of 72
 SMS
UE P-CSCF I-CSCF S-CSCF IP-SM-GW HSS HLRe TAS
Router
REGISTER
UAR

UAA

REGISTER MAR
401 Unauthorized
(auth challenge) MAA (auth vectors)

REGISTER
UAR
UAA (S-CSCF address)

REGISTER auth
Resp)
SAR
SAA (iFCs with ServiceInfo containing MSISDN)
200 OK

iFC execution

REGISTER (MSISDN])

MSISDN stored

200 OK
SUBSCRIBE (reg)
200 OK

Feature tags, capabilities in

reginfo XML doc

NOTIFY (reginfo XML)

200 OK
Sh query (UDR)

UDA (subs profile)

IP-SM-GW stores the user Reg-Info on HSS. This will User profile stored
be used by another IP-SM-GW to find if and with at ip-sm-gw
which ip-sm-gw the UE is registered during MT-SM Sh: PUR

Sh: PUA

IP-SM-GW registers for that subscribers on HLR. When HLR

ANSI-41 MAP: REGNOT
receives SRI-SM for this subscriber, it shall return SMS Router
(MSISDN, Modification
address
Request for IP-SM-GW data)
IPSM GW updates SMSADDR = SMSRouter address and this is
used by SMSC to determine where to deliver the SMS to. MAP: regnot -Resp

S-CSCF selects TAS for REGISTER (IMPU)

Third-Party-Registration
based on iFC execution. User Data Req

UDA (user Profile,

SS-Data)

SNR (SS-Data
Subscription Req)

SNA

200 OK

IPSM GW will register to the HLRe for both IPSM GW and TAS as it is not possible to send two REGNOT, one
for SMS and another for Voice.

Confidential. Version: 9
Page 21 of 72
3.8.1 Refresh-Registration

IMC / UAG
IPSM-GW HSS HLRe SMSC MSC / UE-A
UE-A

SIP: REGISTER
REGNOT (SMSADDR = SMS Router
GT address)
regnot
200 OK

IMC / UAG
IPSM-GW HSS HLRe SMSC MSC
UE

When UE performs refresh registration, IPSM again does TPR procedure including setting of SMSADDR = SMS
Router GT Address.

Confidential. Version: 9
Page 22 of 72
3.8.2 Registration with Messages Waiting

The following call flow shows how deferred messages (stored on CDMA SMSC) are delivered to the
IMS subscriber when he registers.

IMC / UAG
IPSM-GW SMS Router HSS HLR SMSC Old MSC
UE-A

UAR/MAR/SAR
Registration/authentication/profile retrieval msgs from I-CSCF/S-CSCF
not shown. MIN is derived from IMSI, ESN is not passed
SIP: REGISTER

Third Party Register (TPR)

REGNOT (SMSADDR =SMS Router GT)

REGCANC
regcanc
regnot(SMSMWI)

200 OK SMSNOT (SMSADDR = SMS Router GT)

SMDPP (MIN)
SRI-SM(IMSI)

SRI-SM Ack
(IPSM-GW)

MT FSM
(IMSI)
SIP: MESSAGE

200 OK
MT FSM
Response
smdpp

IMC / UAG
IPSM-GW SMS Router HSS HLR SMSC Old MSC
UE

The trigger for sending the SMSNOT is the SMSMWI flag on HLR. This is set as per normal ANSI-41 procedures
in the CS domain.

3.8.3 Deregistration

IMC / UAG
SMS Router HSS HLR SMSC New MSC
UE-A

REGNOT (SMSADDR = New MSC)

REGCANC
regcanc

regnot

IMC / UAG
SMS Router HSS HLR SMSC MSC
UE

Confidential. Version: 9
Page 23 of 72
This call flow shows the normal behaviour of the HLR when a user registers onto another MSC. In this case,
since SMS Router is acting as an MSC, it should expect to receive the REGCANC message and send the regcanc
response according to the ANSI-41 procedures. Apart from sending the response, SMS ROuter is not required
to do anything with the REGCANC message.

3.9 Call Flows

Note: Please also see reference [11] SF Roaming Solution Description as the flows may have
changed due to addition of roaming use cases.

3.9.1 MT SMS to CS

Terminating UE-A /
UE-B HSS HLR SMSC
MSC MSC

HLR forwards the SMSREQ to the SMDPP

node identified by SMSADDR in
smdpp (ack)
subscribers profile

SMSREQ (MIN)

smsreq(MSC Addr)

SMDPP (MIN)
SMD-REQ
smd-req
smdpp

Terminating UE-A /
UE-B HSS HLR SMSC
MSC MSC

In the above call flow both UE-A and UE-B are on the CDMA network.

SMSC uses SMS Address provided by HLR to determine whether to route to IMS or CS. In this case, the SMS
Address points to an MSC in the CS domain.

If coming from MSC, the CDMA SMSC does the Ro interaction (not shown in figure above).

Confidential. Version: 9
Page 24 of 72
3.9.2 MT SMS to IMS
CDMA SMSC Ip-sm-
HLR HSS S-CSCF UE
SMSC Router gw
SMDPP Deliver SMS-Router does MAP and
payload conversion: ANSI41
to GSM and 3gpp2 to 3gpp Determines that subscriber is
registered in IMS domain.
SRI-SM (MSISDN)
Sh query (UDR)
Ip-sm-gw gets UE profile if not available
UDA (subs profile) RMS will do the UDR for service
indication (RMS_DYNAMIC_DATA)
SRI-SM-Resp (IMSI, RMS GT)

MT FSM (IMSI) Ip-sm-gw recognizes subscriber is

registered in IMS domain and hence
performs IMS domain delivery.

MESSAGE <IMPU>
(SMS-DELIVER)

200 OK
MESSAGE
(SMS-DELIVER-
REPORT)

202 Accepted
MT-FSM-Resp (SMS-DELIVER-REPORT)

When the user registers to the IMS network, as part of TPR, IPSM-GW will update the SMSAddress in the
subscriber’s profile on the HLR with SMS Router’s SS7 identity.

As in previous scenario, HLR/CDMA SMSC will do the same processing whether terminating towards IMS or
CS. It sees SMS Router as just another MSC. In this case, IPSM GW does not do any Ro interaction as it is an
MT SMS (towards IMS). The CDMA SMSC is responsible for the Ro charging of the MO leg.

3.9.3 User not in IMS

In this call flow, the SMSADDR in the terminating user’s profile on the HLR points to SMS Router and therefore
SMS is sent to SMS Router and onto IPSM GW. However in case IPSM GW does not find the user registered
in IMS or in case there is no acknowledgement from the user, it will fail the SMS delivery and send the result
back to SMS Router. SMS Router will send the SMS to Message Store for deferred delivery.
CDMA Message SMSC Ip-sm-
HLR HSS S-CSCF UE
SMSC Store Router gw
SMDPP Deliver SRI-SM (MSISDN)

Sh query (UDR) Ip-sm-gw gets UE profile if not available

RMS will do the UDR for service
UDA (subs profile) indication (RMS_DYNAMIC_DATA)

User not registered in IMS

sendNegativeSriSmAck flag is true
SRI-SM-Resp (negative)

Message Store does

deferred delivery
based on retries

Confidential. Version: 9
Page 25 of 72
3.9.4 Deferred Delivery

AirMessenger Store implements deferred delivery using a sophisticated retry mechanism based on the failure
cause of the original SMS delivery. So for example, if the failure reason is something like a No Page Response,
a more aggressive retry mechanism will be launched, but for something like absent subscriber it would be
much less aggressive as normally an SMSNOT would be the one to trigger delivery.

The number of retries, periodicity and validity are configurable per failure cause code. For more details,
please see reference [6] AirMessenger Store Product Description.
CDMA Message SMSC Ip-sm-
HLR HSS S-CSCF UE
SMSC Store Router gw

Message Store has flexible retry

configs based on the cause code
for SMS delivery. When triggered
it will re-send SMS via SMS Router

SMPP Deliver
SRI-SM (MSISDN)

Sh query (UDR) Ip-sm-gw gets UE profile if not available

RMS will do the UDR for service
UDA (subs profile) indication (RMS_DYNAMIC_DATA)

SRI-SM-Resp (ok)

MT FSM (IMSI)
Same IMS MT SMS scenario follows

Confidential. Version: 9
Page 26 of 72
3.9.5 MO IMS to IMS

UE A UE B P-CSCF S-CSCF OCS IP-SM-GW HSS HLR SMS Router MSC

MESSAGE (SMS-
SUBMIT)

iFC execution

MESSAGE (SMS-SUBMIT)

Ro: CCR(IEC
debit)

Ro: CCA(ok)

MO-FSM (SMS-SUBMIT, 3gpp

payload)

SMSREQ

smsreq(SMS
Addr=SMS
Router)

SRI-SM

SRI-SM Ack

200 OK

200 OK

UE A UE B P-CSCF S-CSCF OCS IP-SM-GW HSS HLR SMS Router MSC

SMS Router checks if SMSAddr received from HLRe smsreq response is equal to SMS Router address. If
equal, then deliver SMS to IMS (IPSM GW).

Confidential. Version: 9
Page 27 of 72
3.9.6 MO IMS to CS
UE A UE B P-CSCF S-CSCF IP-SM-GW HSS HLR OCS SMSC Router MSC

MESSAGE (SMS-SUBMIT)

iFC execution
MESSAGE (SMS-SUBMIT)

202 Accepted

Ip-sm-gw gets UE profile if not available Sh query (UDR)

RMS will do the UDR for service indication UDA (subs profile)
(RMS_DYNAMIC_DATA) Mav SMSC will translate the GSM SMS to CDMA
Charging req CCR SMSC and submit it to CDMA SMSC
towards OCS CCA(Success)

MO-FSM (SMS-SUBMIT)

SMSREQ
smsreq(SMSCAddr=MSC
addr)

SMDPP Submit and Ack

MESSAGE (SMS-SUBMIT- MO-FSM-Resp (SMS-SUBMIT-REPORT)

REPORT)

200 OK

SMS Router checks if SMSAddr received from HLRe smsreq response is equal to SMS Router address. If not
equal, then deliver SMS to CDMA MSC address received.

Confidential. Version: 9
Page 28 of 72
3.9.7 MO IMS to CS (Charging Failure)

UE A UE B P-CSCF S-CSCF IP-SM-GW HSS HLR OCS SMS Router

MESSAGE (SMS-SUBMIT)

iFC execution
MESSAGE (SMS-SUBMIT)

202 Accepted

Ip-sm-gw gets UE profile if not available Sh query (UDR)

RMS will do the UDR for service indication UDA (subs profile)
(RMS_DYNAMIC_DATA)
Charging req CCR
towards OCS
CCA(failure)

MESSAGE (RP-
ERROR[SMS-SUBMIT-
REPORT])

200 OK

UE A UE B P-CSCF S-CSCF IP-SM-GW HSS HLR OCS SMS Router

Confidential. Version: 9
Page 29 of 72
3.10 ANSI-41 Specifics

3.10.1 REGNOT Mandatory parameters

3.10.2 Electronic Serial Number:

ESN will be set to a dummy value – system wide configurable. ESN will be provisioned on HSS.
IPSM GW will retrieve ESN from HSS via the Sh interface.

Confidential. Version: 9
Page 30 of 72
3.10.3 Mobile Identification Number:

The CDMA version of IMSI = MIN. The MIN has the same digits as the IMSI without the MCC and
MNC. Since MIN is supposed to be 10 digits, a prefix of “8” or “9” is normally added in the SF
network. For the SMS router, the prefix should be configurable for all users.

3.10.4 MSCID:

MSCID will be set to a fixed value representing a default MSC address. This should be
configurable.

Confidential. Version: 9
Page 31 of 72
3.10.5 QualificationInformationCode

QUALCODE will be set to value 1 or 2 based on the application logic.

3.10.6 SystemMytype

MYTYP should be set to a system-wide configurable parameter.

Confidential. Version: 9
Page 32 of 72
4. RCS Services
CCF OCS

Rf Ro

Rich Messaging Server

(RMS)

RCS AS

ISC
MSRP
SIP
XDMS PS/RLS S-CSCF
XCAP

Ut/XCAP Mw

AG P-CSCF

Gm
MSRP

RCS Client

The RCS AS provides all the functionalities which are required for RCS in compliance with 3GPP and OMA
standards. For SF messaging solution, the RCS AS will provide the following services:
 1-1 chat
 Group chat
 File transfer (FT)
 Image Share (IS)
 GeoLocation Push

FT and IS are treated by RCS AS as the same function and uses the same configuration. The maximum size
for FT and IS is the same and is configurable.

FT, IS and Geolocation push is done using MSRP and not via HTTP. This limitation is due to the requirement
of OCS interaction for these services.

4.1 Provisioning
SF requests that a subscription flag for each of the 5 RCS 5.1 services are stored per subscriber on the HSS.
This will require Mavenir to provide its SPS. Customer care (BOSS) interacts with SPS using SOAP and SPS
updates RCS AS with the new information using Sh.

Confidential. Version: 9
Page 33 of 72
The user profile data is shown in the list below (default values shown):

 pageModeEnabled: TRUE
 largeModeEnabled: TRUE
 grpPageModeEnabled: TRUE
 grpLargeModeEnabled: TRUE
 p2pChatEnabled: TRUE
 grpChatEnabled: TRUE
 imageShareEnabled: TRUE
 p2pFtEnabled: TRUE
 grpFtEnabled: TRUE
 convHistoryEnabled: FALSE
 geoLocationShareEnabled: TRUE

4.2 Billing
In the messaging solution, only the following RCS services will require Ro interaction (online billing):

- 1-1 Chat
- 1-N Chat
- File Transfer
- Image Share
- GeoLocation Push

All other services will not be subject to Ro interaction.

4.2.1 Online/Alternate Billing methods

a) Monthly add-on bill for RCS whether in LTE Data or public internet
b) Online billing via P-GW using DPI; applicable only if access to network is via LTE Data
 RCS via public internet allowed but free
 RCS via public internet not allowed
c) As per 3GPP Online charging specifications – see 4.2.2 below

4.2.2 Immediate Event Charging

For the above services, Immediate Event Charging (IEC) is the method used when interacting with the OCS.

Online charging consists of the following two sub-functions:

 Unit determination – This refers to the calculation of the number of non-monetary units that shall be
assigned prior to starting service delivery.
 Rating – This refers to the calculation of a price out of the non-monetary units calculated by the unit
determination function.
RMS (RCS AS and IPSM GW) supports centralized unit determination and rating for IEC, which means:

 The OCF is responsible for determining the amount of units that a user can consume for messaging
services, i.e. the OCF tracks the subscriber’s prepaid balance.

Confidential. Version: 9
Page 34 of 72
  The OCF is responsible for converting the messaging service units consumed by a user into monetary
units.
The IEC debit “unit” supported by RMS is “one” message or file.

The “Event Based Request” can have four subtypes as Debit Request, Balance Check Request, Refund Request
and Price Enquiry Request. RMS will only support Debit Request/Response and Refund Request/Response
for supporting online charging for RCS services.

RMS will initiate an IEC Debit Request to the OCF upon receipt of a chat message or file transfer from/to the
user and will continue the processing for delivery upon successful IEC Debit Response from the OCF. Upon
the failure to deliver a chat message or file transfer RMS will initiate an IEC Refund Request to the OCF. These
two operations will be based on configurable charging events for Debit action and Refund action.

4.2.3 Event Charging Triggers

RCS AS allows the operator to enable or disable each individual event trigger, which provides control over
what is considered the chargeable event. When multiple triggers are enabled for a certain RCS service
scenario, RCS AS will generate the charging event upon the first trigger that occurs and ignore any subsequent
triggers for that same messaging transaction.

Event Charging Triggers for File Transfer / Image Share /GeoLocPush

Event Trigger Description

Initial INVITE This trigger applies to a SIP initial INVITE request for a file
transfer, image share or GeoLocation Push.
This will be the trigger for IEC Debit Request. The IEC
Debit Response decides if RMS will continue with
processing of the file transfer/image/GeoLocPush share.
Final Error Response to INVITE This trigger applies to a final SIP failure response to an
INVITE request for a file transfer or image share or
GeoLocPush.
This will be the trigger for IEC Refund Request.
First MSRP SEND This trigger is optional trigger and can be used if trigger
point is to be defined at MSRP instead of initial INVITE
shown above.
This trigger applies to the first MSRP SEND request for a
file transfer, image share or GeoLocPush. If the sender
breaks the message into chunks, the trigger is applied
upon receiving the first MSRP chunk.
This will be the trigger for IEC Debit Request and the IEC
Debit Response decides if RMS will continue with
processing of the file transfer/image share.
Intermediate chunk/final chunk MSRP This trigger applies to interruption/failure of file transfer
SEND failure response or MSRP failure as indicated by Intermediate/Final MSRP SEND failure
REPORT if enabled. response or MSRP failure REPORT if enabled.
This will be the trigger for IEC Refund Request.

Confidential. Version: 9
Page 35 of 72
4.2.4 OCS rejection
In case OCS rejects the request for the RCS service due to

 no subscription or
 insufficient balance

A notification will be sent to the user encouraging them to subscribe to the service or add money to
their account, using SIP MESSAGE (SMSoIP).

4.2.5 CDRs

Existing CDRs for RCS service will be created and stored for up to 7 days.

4.3 Multi-Device
The RCS solutions should support multi-device using the SIP Instance ID tag.

4.4 Interactions:
Lawful Intercept: LI; X1 and X2 for the messaging solution is done on the UAG
UE capability checking can be done via RCS SIP OPTION or using PRS. Both methods are able to co-exist.
Voice and video services as defined in RCS will be performed by TAS.

4.5 Functional interfaces

RMS supports the following standard interfaces

 ISC – Connectivity to IMS core (S-CSCF)

 MSRP - The Message Session Relay Protocol (MSRP) is a protocol for transmitting a series of related
instant messages in the context of a communications session.

 DNS - RMS connects to DNS DB over DNS protocol to do address resolution for given FQDN. RMS
supports both IPv4 and IPv6 addressing. This means RMS has both IPv4 and IPv6 addresses assigned
to be used while communicating with remote end.

Confidential. Version: 9
Page 36 of 72
4.6 Registration
When a SIP client registers, the S-CSCF initiates a third party registration message to the RMS. The RMS
supports third party registration containing embedded REGISTER and 200 OK response which carries UE
specific feature capabilities. If network doesn’t support embedded REGISTER/200 OK in THIRD PARTY
REGISTRATION then RMS subscribes for the UEs capabilities using the SUBSCRIBE/NOTIFY mechanism.

A1 P-CSCF I-CSCF S-CSCF RMS HSS

RCS client on A1 registers with

IMS, including its feature tags.

REGISTER (From/To: IMPU-2

Authorization: username=IMPI-2,
algorithm=Digest, …)
UAR(Public Identity: IMPU-2, User Name: IMPI-2)

UAA(S-CSCF Name)

REGISTER
MAR(Public Identity: IMPU-2, User Name: IMPI-2)

MAA (Digest, QoP, HA1 ...)

401 Unauthorized

REGISTER (From/To: IMPU-2

Authorization: username=IMPI-2,
algorithm=Digest, Response= XYZ,
…)
UAR(Public Identity: IMPU-2, User Name: IMPI-2)
UAA (S-CSCF Name)

REGISTER

Authentication
Successful
SAR

SAA (iFCs with ServiceInfo containing MSISDN)

200 OK

iFC execution based on

RCS messaging services,
route to RMS.

iFC configured with REGISTER (embedded

<IncludeRegisterRequest> and REGISTER and 200 OK,
<IncludeRegisterResponse> Expires > 0)

200 OK

Confidential. Version: 9
Page 37 of 72
4.6.1 De-Registration

Confidential. Version: 9
Page 38 of 72
4.6.2 Third party refresh- registration

A1 P-CSCF I-CSCF S-CSCF RMS HSS

RCS client on A1 registers with

IMS, including its feature tags.

REGISTER (From/To: IMPU-2

Authorization: username=IMPI-2,
algorithm=Digest,Response=
XYZ,Expires: <non-zero value> …)
UAR(Public Identity: IMPU-2, User Name: IMPI-2)

UAA(S-CSCF Name)

REGISTER
Expires: <non-zero
value
SAR

200 OK SAA (iFCs with ServiceInfo containing MSISDN)

iFC execution based on RCS

messaging services, route to RMS.

REGISTER (embedded
iFC configured with
REGISTER and 200 OK,
<IncludeRegisterRequest> and
<IncludeRegisterResponse>
Expires > 0) Reg-Timer is reset with the
value received in the Expires
200 OK header.

SUBSCRIBE(reg)

200 OK

iFC configured with

<IncludeRegisterRequest> and
<IncludeRegisterResponse>

Confidential. Version: 9
Page 39 of 72
4.7 1 – 1 chat
SBC/ SBC/
A1 S-CSCF O-RMS T-RMS S-CSCF B1
P-CSCF P-CSCF
Client is already registered and starts a chat session
with B1. INVITE is multipart with SDP and CPIM. CPIM
contains text/plain and IMDN request headers

INVITE (SDP:
a=sendrecv, INVITE (SDP:
C=A;m=port a, a=sendrecv, C=P1;
path=msrp://A:a m=port p1,
setup: actpass) path=msrp://A:a
setup: active )
iFC execution

INVITE (SDP) Executes originating services and using

SBC shall not update the INVITE (SDP: translations routes message in IMS
path. SBC acting as a=sendrecv, C=R1; domain. SIP signaling and MSRP gets
MSRP B2BUA changes m=port r1, anchored on RMS
setup to active path=msrp://R1:r1
setup: actpass)
iFC execution

Recipient is IMS registered, so perform

recipient processing. Deliver to the S-CSCF INVITE (SDP:
using IMPU as destination number. MSRP a=sendrecv,
and SIP signaling anchored on RMS C=R2; m=port r2, INVITE (SDP:
path=msrp://R2:r2 a=sendrecv,
setup= actpass) C=P2;m=port p2,
SBC shall not update path=msrp://R2:r2
the path but setup to setup: passive)
passive
200 OK (SDP:
200 OK (SDP: a=sendrecv,
a=sendrecv, C=B1;m=port b1,
C=P1;m=port p1, path=msrp://B1:b1,
path=msrp://B1:b1 setup: active)
setup: active)

200 OK (SDP:
a=sendrecv,
C=R1;m=port r1,
path=msrp://R1:r1,
setup: passive)

200 OK (SDP:
200 OK (SDP: a=sendrecv, C=R2;
a=sendrecv, C=P2; m=port r2,
m=port p2, path=msrp://R2:r2
path=msrp://R2:r2 setup: passive)
setup: passive)
ACK Exchange

TCP SYN TCP SYN

TCP SYN

MSRP 200 OK MSRP SEND (msg 1)

MSRP 200 OK
MSRP
200 OK
MSRP 200 OK 200 OK

MSRP SEND
(IMDN)
MSRP (IMDN) MSRP SEND (IMDN)
MSRP 200 OK
User starts
typing.

MSRP SEND
MSRP (isComp) (isComposing)
MSRP SEND (isComposing)
MSRP (isComp) MSRP 200 OK
...

BYE/200 OK Exchange

Confidential. Version: 9
Page 40 of 72
4.8 Group chat

SBC/ SBC/
A1 S-CSCF O-RMS T-RMS S-CSCF B1 C1
P-CSCF P-CSCF
INVITE (R-URI=
AdHoc, MIME RLS)

INVITE (R-URI= Server goes through list of URI mentioned in MIME RLS and
iFC execution creates new INVITE for each IMS routable recipient.
AdHoc, MIME RLS)

Creates new INVITE offering its m/c line and path so UE-T can send
INVITE (R-URI=UE- MSRP SEND packet acting as active endpoint.
B, isfocus, MIME
RLS)
This portion of the flow is
repeated for each recipient in
the ad-hoc list who is found to
be registered in IMS, based
upon the repository data
INVITE (R-URI=UE-
query. This example
C, isfocus, MIME
assumes both recipients are
RLS)
registered.

200 OK (SDP)
Note: ACKs for 200 OK
are not shown for brevity

MSRP SEND (msg1)

MSRP 200 OK
MSRP 200 OK MSRP SEND (msg1)
MSRP SEND (msg1)
MSRP SEND (msg1)
MSRP 200 OK
200 OK
MSRP 200 OK
200 OK
...

MSRP SEND
(imdn)
MSRP SEND (imdn)
MSRP SEND (imdn) MSRP 200 OK
MSRP 200 OK

MSRP SEND (imdn)

MSRP SEND (imdn)
MSRP SEND (imdn) MSRP 200 OK
MSRP 200 OK

User B starts typing.

MSRP SEND
(isComposing)
MSRP SEND (isComposing)
MSRP SEND (isComposing) MSRP 200 OK
MSRP 200 OK

MSRP SEND (isComposing)

MSRP SEND (isComposing)
MSRP 200 OK
Note: All MSRP messages are sent
200 OK
hop by hop. TCP SYN messages not
shown for brevity

Confidential. Version: 9
Page 41 of 72
4.9 File transfer / Image Share / GeoLocPush
When a SIP client originates a non-text message (such as File-Transfer/ImageShare) the RCS AS applies
originating services as usual.

A SBC S-CSCF RMS-A S-CSCF RMS-B SBC B

INVITE
(SDP,CPIM)

iFC execution INVITE

INVITE

INVITE
INVITE

INVITE

INVITE

200 OK (SDP)

200 OK (SDP)

200 OK (SDP)

MSRP SEND (CPIM(imdn.msgID=1))

200 OK

MSRP SEND (CPIM(imdn.msgID=1))

...

200 OK 200 OK

MSRP SEND (CPIM(imdn.msgID=X))

200 OK
...

MSRP SEND (CPIM(imdn.msgID=X))

RMS times out waiting for 200 OK

response or TCP connection goes down.
...

RMS stores message for recipient in local DB and

doesn’t send MSRP Failure-Report to sender.
...

Messages stored:
MsgX --- IDX
…….
BYE MsgN --- IDN
BYE

BYE
200 OK 200 OK

Since RCS has not defined deferred message delivery concept for File-Transfer/ImageShare. The RCS AS
supports Store&Forward (deferred delivery) functionality for chat service only.

Confidential. Version: 9
Page 42 of 72
4.9.1.1 Store & Forward (S&F)

A group chat participant temporarily losing connection to access network shall still be able to receive all the
messages after registering back into the network or after rejoining the group chat. This is to be accomplished
by the messaging server supporting Store and Forward functionality for this group chat who has temporarily
lost the connection.
SBC/ SBC/
A1 S-CSCF O-RMS T-RMS I-CSCF S-CSCF HSS B1
P-CSCF P-CSCF
Client is already registered and starts a chat session
with B1. INVITE is multipart with SDP and CPIM. CPIM
contains text/plain and IMDN request headers

INVITE (SDP:
a=sendrecv, INVITE (SDP:
C=A;m=port a, a=sendrecv, C=P1;
path=msrp://A:a m=port p1,
setup: actpass) path=msrp://A:a
setup: active )
iFC execution
SBC shall not update INVITE (SDP) Executes originating services and using
the path but setup to translations routes message in IMS
active in SDP INVITE (SDP:
a=sendrecv, C=R1; domain. SIP signaling and MSRP gets
m=port r1, anchored on RMS
path=msrp://R1:r1
setup: actpass)
LIR(IMPU)
LIA (S-CSCF HSS returns default S-
Name) CSCF name in LIA

INVITE
iFC execution

Recipient is IMS registered, so perform

recipient processing. Deliver to the S-CSCF INVITE (SDP:
using IMPU as destination number. MSRP a=sendrecv, C=R2;
and SIP signaling anchored on RMS m=port r2, INVITE (SDP:
path=msrp://R2:r2 a=sendrecv,
setup= actpass) C=P2;m=port p2,
path=msrp://R2:r2
SBC shall not update setup: passive)
the path but setup to
passive within SDP
User is offline and
480 Temp UnAvail doesn’t respond
RMS accepts session on
ACK
behalf of recipient.
200 OK (SDP:
a=sendrecv,
C=R1;m=port r1,
path=msrp://R1:r1,
setup: passive)

200 OK (SDP:
200 OK (SDP: a=sendrecv, C=R2;
a=sendrecv, C=P2; m=port r2,
m=port p2, path=msrp://R2:r2
path=msrp://R2:r2 setup: passive)
setup: passive)

ACK Exchange

TCP SYN TCP SYN

MSRP 200 OK
MSRP 200 OK
MSRP
...

200 OK

Messages stored:
Msg1 --- ID1
MSRP 200 OK
MSRP 200 OK …….
MSRP MsgN --- IDN
200 OK

BYE/200 OK Exchange

Confidential. Version: 9
Page 43 of 72
4.10 RCS Chat to SMS Interworking
RCS AS supports Chat to SMS interworking in the Chat to SMS direction via SMPP.

The reverse direction is more complicated because of the interactions and requires further discussion with
customer regarding user experience. This feature if requested by SF is on the roadmap.

Mavenir suggest to move CHAT to SMS interworking to the next phase.

4.10.1 Chat to SMS

1-1 Chat (Legacy SMPP interworking to SMSC by T-RMS)

A SBC S-CSCF RMS-A S-CSCF RMS-B SMSC

INVITE (SDP,
CPIM message)

iFC execution INVITE

INVITE
INVITE
(1st chat
INVITE
message
)
RMS determines that user is not available in IMS domain or in
case of error response to Invite based on configured error code
to action, accepts the chat for smsc interworking on behalf of
user and provides local SDP in 200 OK. RMS to perform store
or perform legacy interworking is a configurable option.
SUBMIT_SM req (1st chat msg)

200 OK SUBMIT_SM resp

(SDP)
200 OK (SDP)

200 OK (SDP)

MSRP SEND (2nd msg))

200 OK

MSRP SEND (2nd msg)

...

SUBMIT_SM req (2nd msg)

200 OK
SUBMIT_SM resp

MSRP SEND (last msg)

...
...

200 OK

MSRP SEND (last msg)

200 OK
SUBMIT_SM req(last msg)

BYE SUBMIT_SM resp

BYE

200 OK 200 OK

© Mavenir Systems 2015 – Confidential Proprietary

Confidential. Version: 9
Page 44 of 72
5. PRS, XDMS and AG
The Presence solution includes the OMA SIMPLE based Presence and Resource List Servers integrated
onboard the mOne platform.

XCAP
AP XDMS

XCAP/SIP XCAP/SIP

PS RLS

ISC ISC
XCAP Mw Cx
P-CSCF I/S-CSCF HSS

SBC Presence Server (PS)

Resource List Server (RLS)
Gm Aggregation Proxy (AP)
IMS UE (Mobile or
Fixed)
XML Data Management Server (XDMS)

The Presence Enabler solution consists of a rich suite of services that are supported across the four primary
application components of the solution:

 Presence Server
 Resource List Server
 XDMS
 AP (Aggregation Proxy)

Interface Nodes Used

ISC PS/RLS  S-CSCF by S-CSCF to invoke PS/RLS services
Ma RLS  I-CSCF to route the backend subscriptions towards PS via
I-CSCF
Mw P-CSCF  I/S-CSCF for communication between P-CSCF and I/S-CSCF
Cx I-CSCF  HSS to retrieve S-CSCF capabilities from HSS via
Diameter interface and assign S-CSCF
XCAP PS/RLS  XDMS to obtain the presence related XML documents
from XDMS by PS/RLS
SIP PS/RLS  XDMS to subscribe for notifications of any change in the
XML documents in XDMS
Ut/XCAP UE  AP Used by UE to upload/delete any document in
XDMS via AP

Confidential. Version: 9
Page 45 of 72
5.1 Presence Server
Mavenir Presence Server conforms to OMA SIMPLE v1.0.1 standard. Presence Server (PS) is an entity that
accepts, stores and distributes presence information. The functionality provides by the PS is as follows:

 Handles subscriptions to presence information.

 Handles publications
 Generates notifications if the presence information is changed.
 Handles subscriptions to watcher information.
 Generates notifications if the watcher information is changed.
 Subscription authorization
 Notification filtering preferences
 Interaction with XDMS
 Subscriber Identities
 Queries ENUM to resolve E.164 numbers into SIP URIs

5.2 Resource List Server

Functionality implemented on the Mavenir RLS conforms to OMA SIMPLE v1.0.1. The functionality provided
by RLS is as follows:

 Handles subscriptions to presence lists

 Authorizes watchers usage of presence list
 Creates and manages back-end subscriptions.
 Sends notifications to the watcher.
 Applies aggregation and rate control mechanisms to the notifications
 Interaction with XDMS
 Queries ENUM to resolve E.164 numbers into SIP URIs
 Supports the AS mapping solution at S-CSCF. As part of AS mapping at S-CSCF all Application Servers
respond with their site specific FQDN address in the Contact header of 200 OK response to the
requests received.
 Supports the multiple list subscription from a watcher.

5.3 XDMS
The XDMS is a database which stores XML documents for later retrieval by IMS application servers and IMS
clients. The XDMS can be leveraged to function like a Cloud Address Book which can be an OMA compliant
Address repository. The XDMS is used for storing data such as

- Buddy lists which is effectively an Address book,

- Blacklists
- Contact information such as status, tagline, MSISDN etc.
- Authorization rules

Confidential. Version: 9
Page 46 of 72
Mavenir’s XDM server is a general purpose XDM Server that can serve any application as defined by the OMA
specifications. The main features of the XDMS are:

 Application usage: The XDM server supports the application usages as per the OMA specification. It
supports Presence Server XDMS, RLS-XDMS, SNG XDMS, IM XDMS, Shared Policy XDMS and Shared List
XDMS, Shared Group XDMS, and Shared Profile XDMS functions.
 Storage of structured XML documents: The XDM Server supports the storage and retrieval of XML
documents according to the XCAP protocol. The document will be validated against the XML schema
associated with the particular application usage.
 Subscription to changes in documents: The XDM Server supports a SIP interface where an entity can
subscribe to changes in the XML documents stored in the server. This is typically used both by the IMS
enablers and by clients to be informed of changes to the documents.
 Document Management: XDMS is responsible for Creation, Modification, Deletion and Retrieval of
user documents in the database.
 Database: XDMS database currently stores all the user related information in one table with the
document selector as the key. It is designed in such a way various application data can be logically
divided based on the application type. It uses an Application Unique ID (AUID) to differentiate among
different applications.
 Initial Subscription: XDMS creates a subscription dialog on receiving the first SIP SUBSCRIBE request
from IMS enables, it guards the subscription dialog based on the value received in the Expires header
of the request. After creating the dialog, it stores the subscription information in memory and is
replicated to the stand-by node.
 Refresh Subscriptions: XDMS refreshes existing subscription for a user on receiving a refresh
SUBSCRIBE request. If there is an already existing subscription dialog present for the user XDMS
considers the incoming SUBSCRIBE request as a refresh one. On receiving a refresh subscription, XDMS restarts
the expiry timer guarding the dialog.
 Subscription Termination: XDMS on receiving a SUBSCRIBE request with Expires header value set to
zero, considers it as a subscription termination request. As part of termination procedures, XDMS
removes the dialog related to this subscription. Also, the data stored for this subscription locally in
memory is removed.
 Subscription Expiry: XDMS as mentioned in the previous sections guards the subscription by starting a
timer. If the enablers doesn’t send a refresh subscription before the timer expire, XDMS considers the
subscription to be terminated and sends a NOTIFY back go the PS/RLS with subscription state set to
‘terminated’.

Confidential. Version: 9
Page 47 of 72
5.4 AG
AG or Application gateway is used for authentication of non-LTE access; i.e. for the Ut and XCAP
interface. Ut is required for subscriber management of voice supplementary services. Its use will
be described in the Voice and Video Solution description.

For the messaging solution, the AG is required when the user manages his contact information on
the XDMS via XCAP; e.g. changing of tagline, adding contacts, removing contact and so on.

For the messaging solution, Mavenir’s AG is the entry point for all communication from the XDM
clients towards XDMS. The main task of the AG is to authorize and authenticate the trusted and un-
trusted clients accessing the XDMS resources using XCAP. It appears to the UE / XDMCs as a
standard proxy that provides access to all expected or required data in the XDMS after authorization.
Standard access to the AG is via the Ut interface using XCAP from the clients.

The following diagram depicts the network architecture for Application Gateway and connectivity with
other network entities.

HSS

Zh/Diameter
AG
Zn/SOAP if externally
located
BSF Internal NAF
Mx_signalling if c o-located

Ub/HTTP Ua/HTTP

UE

BSF: A generic Bootstrapping Server Function (BSF) and the UE shall mutually authenticate using
the AKA protocol, and agree on session keys that are afterwards applied between UE and a Network
Application Function (NAF).

Following features are supported

1. Support Bootstrapping requests from the UE.

2. Support HTTP-Digest authentication scheme for authenticating the UE on the Ub
interface.
3. Support providing the keys for GAA when requested by the NAF.
4. Support the Zn interface over the SOAP protocol on the BSF towards the NAF.

Confidential. Version: 9
Page 48 of 72
NAF: As per the 3GPP TS 33.220 v9.3.0 GBA, after the bootstrapping has been completed, the
UE and NAF can run some application specific protocol where the authentication of messages will
be based on those session keys generated during the mutual authentication between UE and BSF.

The NAF is the starting point where all the requests get terminated from the clients before reaching
the application servers. The NAF authenticates the requests before forwarding them to appropriate
application servers

5.4.1 Implementation for SF

XDM clients in the SF network can be

- SF custom devices with embedded Mingle application,

- OMH devices with downloadable Mingle application
- webRTC clients

The main difference between SF custom devices and the other two is that in the first case (SF custom
device), it is able to read the SIM to be able to do AKA authentication. For the other two device
types this is not the case, instead HTTP digest is used.

The AGW must be able to support both types of authentication.

Confidential. Version: 9
Page 49 of 72
5.5 Use Cases

5.5.1 Third Party Register at Presence AS.

A1 P-CSCF I-CSCF S-CSCF HSS

RLS PS

client on A1 registers with IMS,

including its feature tags.

REGISTER (From/To: IMPU-2

Authorization: username=IMPI-2,
algorithm=Digest, …)
UAR(Public Identity: IMPU-2, User Name: IMPI-2)

UAA(S-CSCF Name)

REGISTER
MAR(Public Identity: IMPU-2, User Name: IMPI-2)

MAA (Digest, QoP, HA1 ...)

401 Unauthorized

REGISTER (From/To: IMPU-2

Authorization: username=IMPI-2,
algorithm=Digest, Response= XYZ,
…)
UAR(Public Identity: IMPU-2, User Name: IMPI-2)
UAA (S-CSCF Name)

REGISTER

Authentication
Successful
SAR

SAA (iFCs with ServiceInfo containing MSISDN)

200 OK

iFC execution

iFC configured with REGISTER (embedded REGISTER and 200

<IncludeRegisterRequest> and OK,
<IncludeRegisterResponse> Expires > 0)
Update Subscriber
200 OK Reg. Status

Confidential. Version: 9
Page 50 of 72
5.5.2 Publication call-flow:

UE A1 P-CSCF I-CSCF S-CSCF HSS RLS PS XDMS

User publishes his/her soft

state information (device/
service capabilities)

PUBLISH (expires
> 0, content-
type=pidf+xml

iFC Execution

PUBLISH (expires > 0, content-type: pidf+xml)

200 OK (etag #)

PS stores the soft state date in local

cache. It also notifies all the watchers
watching this presentity’s soft state
information.

Call flow for partial publication remains the same

5.5.3 Watcher-Info Subscription

UE A1 P-CSCF I-CSCF S-CSCF HSS RLS PS XDMS

User subscribes for watcher-info package to learn watchers who would

like to watch his/her presentity information.

SUBSCRIBE (From/To: UE A1,expires>0,event:

watcher-info)

iFC Execution

SUBSCRIBE(expires>0 watcher-info)

200 OK

NOTIFY(watcher-info+xml)

200 OK

Confidential. Version: 9
Page 51 of 72
5.5.4 List Subscription call flows:

UE P-CSCF I-CSCF S-CSCF HSS RLS PS XDMS

SUBSCRIBE (request contained list,

expires=30s ,event: presence, Supported:
eventlist)

iFC Execution

SUBSCRIBE sent with list-name in the SUBSCRIBE(presence, eventlist)

RURI with expires value set to 30 secs SUBSCRIBE(rls-services)
secs. Event header set to presence
Supported header et to eventlist 200 OK
Optional and guarded using
configuration parameter NOTIFY(rls-services)

200 OK

200 OK

GET(rls-services)
XCAP GET initiated to retrieve
the default rls-services 200 OK
document

SUBSCRIBE(resource-list)

200 OK

NOTIFY(resource-list)

Subscription and Retrieval of 200 OK

default resource-lists document

GET(resource-list)

200 OK

NOTIFY(Subs State =active, rlmi+xml w/state

= pending for each instance)

200 OK
RLS sends SUBSCRIBE
directly to I-CSCF
SUBSCRIBE(presence)

LIR

Return LIA with S-CSCF

LIA(S-CSCF Name) Name from local storage
SUBSCRIBE(
pres)

Same S-CSCF is used in the flow. Ideally S-CSCFs for the

iFC Execution
watcher and the presentity could be different
Repeat for every member in
SUBSCRIBE(pres)
buddy list received from UE in
SUBSCRIBE request SUBSCRIBE(pres-rules)

200 OK
Optional and guarded using
configuration parameter. NOTIFY(pres-rules)

200 OK

GET(pres-rules)
XCAP GET initiated to retrieve
the pres-rules document 200 OK(pres-rules)

Confidential. Version: 9
Page 52 of 72
 UE P-CSCF I-CSCF S-CSCF HSS RLS PS XDMS

SUBSCRIBE(resource-list)

200 OK

Optional and guarded using

NOTIFY(resource-list)
configuration parameter.

200 OK

GET(resource-list)
XCAP GET initiated to retrieve
the default resource-lists
200 OK(resource-list)
document
Repeat for every member in
buddy list received from UE in
SUBSCRIBE request SUBSCRIBE(pidf-
manipulation)

200 OK

Optional and guarded using

configuration parameter. NOTIFY(pidf-manipulation)

200 OK

GET(pidf-manipulation)
XCAP GET initiated to retrieve
the PIDF document 200 OK(pidf+xml)

200 OK

NOTIFY(pidf+xml)

200 OK

RLS aggregates all the notifies

from back end subscriptions
and send the aggregated
NOTIFY to the watcher
NOTIFY(rlmi+xml, pidf+xml, subscription state = active)

200 OK

When list subscription timer (30sec) expires, RLS terminates the subscription towards UE and also all back end subscriptions

Confidential. Version: 9
Page 53 of 72
5.5.5 XCAP Call FLow

The Presence Server interfaces with IMS core (S-CSCF) over the standard ISC interface. PS
server interfaces with XDMS over XCAP and standard SIP. UE interfaces with XDMS over Ut
(XCAP) interface. The call flow for XCAP operation is given below.

SBC/
A1 I/S-CSCF AGW RMS HSS XDMS
P-CSCF

RCS Client performs

XCAP Operation

XCAP METHOD (AUID: XYZ, X-3GPP-Intended-Identity, Authorization:

username set to RCS IMPI – IMPI-2, ...)

Request received with no credentials

or Authorization header.AGW
challenges the user request

AGW fetches auth

information from HSS

MAR (Public Identity: IMPU-1, User Name:

IMPI-2)

MAA (IMPU-1, IMPI-2, Digest ...)

401 Unauthorized (auth challenge)

UE A1 sends XCAP
request with credentials
XCAP METHOD (AUID: XYZ, X-3GPP-Intended-Identity, Authorization:
username set to RCS IMPI – IMPI-2, Response=XYZ, ...)

Successful Authentication. AGW includes

Asserted Identity header and stores the
credentials for configured duration

XCAP METHOD (AUID: XYZ, 3GPP-Asserted-Identity)

200 OK
200 OK

Confidential. Version: 9
Page 54 of 72
6. Mingle and CCPS
Mavenir will provide its client solution (Mingle) for the SF IMS project. It will come in two forms:

- Embedded Mingle

- Downloadable client

From a user perspective both clients should have the same functionality.

Mingle should be able to act as the access device for the services in the messaging solution as
described in previous chapters:

- SMSoIP
- RCS
- PRS

The downloadable client version should be available on both IOS and Android devices.

6.1 Client Configuration and Provisioning Server

The Client Configuration and Provisioning Server (CCPS) provides functionality to allow
RCS/RCSe/CPM based client applications such as Mavenir’s Mingle to retrieve and update their
configuration from the network. The solution is based on the RCS 5.1 specification for client auto
configuration.

The client based applications will interface with CCPS via the HTTP/HTTPS protocol and will
ultimately receive their configuration in the form of an XML document which will be created by the
CCPS.

The client request will only be received from the operators IP Packet Network where the client IP
address will be authenticated and HTTP headers will be enriched with the MSISDN and/or IMSI
before the request is received by the CCPS.

CCPS is involved in the first time activation of the downloaded Mingle client (or sometimes known
as the OTT client). Since OTT clients are not able to read the SIM information on the device, the
CCPS is required to send the user credentials (IMPU, IMPI) to the client.

First time activation requires the user to be attached on the LTE network. It cannot be done via any
other internet access. This is so that the PGW can use the information it received during the LTE
attach procedure to obtain the user’s IMPU and IMPI and pass it onto the CCPS via “header
enrichment”.

CCPS also sends the P-CSCF addresses to the Mingle client. Up to two FQDNs can be stored on
Mingle.

CCPS may not be required for the embedded Mingle client until there is a requirement to update
configuration data on the Mingle devices.

Confidential. Version: 9
Page 55 of 72
6.2 CCPS SubDB
The configuration parameters including the P-CSCF address and the following subscriber specific
information will be stored/provisioned in the HSS/SubDB:

a. IMS public Identity (impu): This can be a SIP URI. The IMPU format adopted in
this deployment is: +[CC][National Destination Code (Area
Code)][subscriber_number]@sf.net (just an example, details to be provided in
LLD).

b. IMS private Identity (impi). The IMPI format adopted in this deployment is:
[email protected].

c. Implicit Registration Set (This is the mapping of IMPU’s which can be implicitly
registered based on IMPI)

d. Authentication Scheme to be used for the subscriber (Digest-Aka or SIP-Digest)

including certificates and credentials

e. IMSI

f. MSISDN

g. Associated Services for the Sh interface – e.g. MMTEL services

h. Repository Data for the subscriber – e.g. registration info for ip-sm-gw,
supplementary-services related info etc.

i. Other info such as IMS-User-State (registered/not registered).

j. Client-side certificates (for EAP-TLS and others)

[design not yet finalized]

Confidential. Version: 9
Page 56 of 72
7. Network Management

7.1 OAM Solution Overview

The Mavenir operation and maintenance solution described herein applies to all Mavenir systems
that share the mOne common platform. The mOne integrated OAM solution is flexible and allows
integration with the operator out-of-band network, while offering the necessary toots for monitoring,
detecting and troubleshooting issues as they arise.

Only the framework of the overall OAM solution is described herein in the current document. For
more details on the various interfaces, list of the alarms, performance statistics and logging
information, please refer to the LLD documentation. In addition, please refer to the Mavenir product
description and user guide documentation for all the OAM specifics on a per entity basis (TAS,
CSCF, UAG etc..).

7.2 Mavenir Element Management System (EMS)

The Mavenir’s integrated EMS system provides an intuitive, easy-to-use GUI for all element
management functions. The EMS allows the operator to control and manage the full suite of essential
FCAPS functions: Fault, Configuration, Accounting, Performance and Security.

Mavenir’s EMS solution is fully integrated with the mOne system, whereas the EMS server is hosted
directly on the Administration Module (AM) of the mOne platform. Mavenir’s EMS solution doesn’t
require an external server.

The benefits of this type of EMS architecture include eliminating extra CAPEX cost, ready integration
to 3rd party OSS and carrier-grade reliability.

The EMS GUI is web-based; typical web browsers such as Internet Explorer and Firefox can be used
to remotely connect to the EMS server from the operator NOC (Network Operations Centre) to
manage the mOne system.

From the main GUI screen, the operator craftsperson has quick and intuitive access to all requisite
management functions via tabs (and pull-down menus) displayed across the banner. As the operator
craftsperson navigates through the EMS pages, the banner is constantly maintained across the top
to display a summary snapshot of the system’s operational state and key performance parameters.

The mView EMS is a common management platform for the mOne platform and is used to manage
all the applications and products based on the mOne platform. A complete functional description of
the management capabilities provided by the mView EMS for the mOne platform are described in
the Mavenir mOne EMS Description Reference Guide which is provided as part of Mavenir’s
standard product documentation suite.

Confidential. Version: 9
Page 57 of 72
7.2.1 EMS Architecture

The mView EMS solution provides centralized OAM for an entire mOne system. The EMS solution
is based on a centralized EMS server instantiated on the AM module, which is provisioned in a 1+1
Active/Standby redundancy.

The EMS GUI is a web-based GUI that can be launched from any remote location, such as the
operator NOC (Network Operations Centre). The figure below illustrates:

Figure 1: Logical mView EMS Solution

The EMS server resides on the AM module and consists of several distinct functional modules that
support each of the OAM subsystems. The architecture is depicted in the figure below. Please note
that the depiction does not cover the full list of supported interfaces (such as SPML, LDAP), but is
merely a representation of the internal architecture flexibility.

Confidential. Version: 9
Page 58 of 72
 Figure 2: mOne Management Architecture

The main functional modules are described as follows:

 Event Manager (EVM) - responsible for collection of events and alarms, and
maintains the current alarm database that reflects to currently active alarm states
in the system. EVM supports a number of essential FM (Fault Management)
functions such as alarm clearing, filtering, and reporting. The EVM writes SNMP
traps based on alarm conditions and reports them to either the NOC or the EMS
GUI for display.

 Logger (CDR) - responsible for collection of all types of logs created by

applications on the systems, including system, admin, transaction logs as well as
CDRs. The internal log files such as transaction/system logs are created and
stored locally in CSV format. The logger also creates external log files accordingly
such as CDRs in predefined format. For example, the default format for CDR files
is TLV structure and ASN.1 format; however, the logger may also be utilized to
create customized CDR files as per any specific needs.

 Traffic Monitoring Manager (TMM) - responsible for collection of operational

counters created by application software as well as within the system itself;
counter types created include individual and group counters. TMM creates
statistical files for performance management purposes, and reports them
externally to 3rd party OSS via SFTP

 mOne Configuration Manager (MCM) - responsible for configuration data

maintained across the mOne system. MCM manages release software and
configuration data files using a MySQL database, which in turn provides data
replication across hard disks on the active and standby AM blades. The MCM also
manages the software personality types that are defined on each Application Card;
in the event of a card failure within the mOne system, MCM ensures that the
recovered card is automatically configured with the proper software upon being
returned to service. MCM also manages the Backup & Restore functionality on the

Confidential. Version: 9
Page 59 of 72
 mOne system, and maintains pointers to the latest system release software and
configuration files

Each mOne System appears as a single OAM entity and is addressed via a single Virtual IP (VIP).
An OAM Virtual IP is configured between 2 Administrative Managers (AM) in each mOne™ System.
An Active AM hosts the VIP. If switchover occurs, the VIP switches over to new Active (previously
standby) AM. External OSS or NOC systems connect to the single OAM VIP for configuration
management, billing/performance stats collection and events/traps monitoring, and therefore are not
impacted by the switchover.

7.3 EMS Subsystem

The logical architecture of the mView EMS solution consists of five main subsystems, as follows:

 Fault Management

 Configuration Management

 Accounting Management

 Performance Management

 Security Management

7.4 Fault Management

The EVM Server on the mOne platform provides a centralized collection and management of all
system alarms and events. Event and Alarm Manager (EVM) clients running on each module within
the system send events and alarms to the EVM server using the internal messaging framework. In
turn, the EVM server consolidates and sends the overall systems events and alarms to the event
console and SNMP agent.

The mOne platform supports two integration models for Fault Management: the mView which can
be used in the NOC to monitor mOne faults and events, or the mOne system can report alarms to
an external 3rd party OSS for integrated Fault Management using SNMP v2/v3 interface to send
traps related information.

The mOne system has the capability to send SNMP traps to more than one system, thus providing
SF the ability to monitor the system across various NOC centers. As mentioned above, events and
alarms are collected by the Event Manager (EVM) from all applications and internal systems, and
then sent via SNMP to an external SNMP agent or directly to mView. The Fault Management process
ensures an appropriate alarm or event for failures associated with the hardware components,
communication links, and processing errors.

The following diagram describes the mView Fault Management architecture.

Confidential. Version: 9
Page 60 of 72
 Figure 3: mOne Fault Management Architecture

The mOne Fault Management subsystem provides industry standard alarm classification and
reporting capability conforming to ITU-T X.733. The Fault Management subsystem supports five
basic categories of alarm types, which are as follows

 Communications - an alarm of this type is principally associated with the

procedures and/or processes required to convey information from one point to
another

 Quality of Service - an alarm of this type is principally associated with a

degradation in the quality of a service;

 Processing - an alarm of this type is principally associated with a software or

processing fault;

 Equipment - an alarm of this type is principally associated with an equipment fault;

 Environmental - an alarm of this type is principally associated with a condition

relating to an enclosure in which the equipment resides

The Fault Management subsystem supports alarm severity levels as defined by ITU-T X.733 as
follows

 Critical - indicates that a service affecting condition has occurred and an

immediate corrective action is required. Such a severity can be reported, for
example, when a managed object becomes totally out of service and its capability
must be restored

 Major - indicates that a service affecting condition has developed and an urgent
corrective action is required. Such a severity can be reported, for example, when

Confidential. Version: 9
Page 61 of 72
 there is a severe degradation in the capability of the managed object and its full
capability must be restored

 Minor - indicates the existence of a non-service affecting fault condition and that
corrective action should be taken in order to prevent a more serious (for example,
service affecting) fault. Such a severity can be reported, for example, when the
detected alarm condition is not currently degrading the capacity of the managed
object

 Warning - indicates the detection of a potential or impending service affecting

fault, before any significant effects have been felt. Action should be taken to
further diagnose (if necessary) and correct the problem in order to prevent it from
becoming a more serious service affecting fault

 Cleared - indicates the clearing of one or more previously reported alarms. This
alarm clears all alarms for managed objects that have the same Alarm type,
Probable cause and Specific problems

SNMP is the interface used to pass traps related information from the mOne system to an external
entity, either the mView EMS or 3rd party OSS. The mOne system is configured with one or more
IP addresses to which it sends SNMP traps. Events are alarms collected by mView are displayed in
tabular format via the mView GUI. The alarm display is updated dynamically as new alarms are
received and existing alarms are cleared

Event & Alarm reporting is managed via a defined SNMPv2 MIB structure that contains relevant
information regarding the alarm or event. Relevant information includes Identifier, Description,
Severity, Type, Reported Object and Reported Object Instance ID. The mOne system group’s alarms
and events into objects and within each, specific alarms/events are assigned instance ids.

7.5 Configuration Management

mView EMS Configuration Management is integrated to external 3rd party OSS and can be
administered by the mView GUI. The following diagram describes the mView Configuration
Management sub-subsystem.

Confidential. Version: 9
Page 62 of 72
 mView EMS GUI/
3rd Party OSS

XML/SOAP EMS Server

provides data
verification and
managers
SOAP resource states
Adaptor

EMS Server
Database
repository for all
system
MX Database configuration data
replicated across
active and standby
blades
MCM

Mavenir
Configuration
MX manager provides
provisioning
capabilities and
manages
Application configuration data

Figure 4: Configuration Management Architecture

Provisioning is provided by the Configuration Management Database (CMDB) which is integral to

the EMS server hosted on the mOne system.

CMDB covers resources associated with the Physical Platform, System Operational Parameters,
Physical Interfaces and Application Settings. Users can view or make changes to the configuration
parameters via the mView EMS GUI.

mView EMS is generally designed for pre-provisioning so that equipment may be defined and
provisioned in the software prior to actual physical installation of the equipment. This minimizes
service turn-up times.

Equipment provisioning is supported with a user-friendly window that displays the current
provisioned values, typically with a list of allowable values for making configuration changes.

Using these features, the EMS users can create new equipment for pre-provisioning as well as to
provision existing equipment.

The basic construct for mView EMS provisioning exists from previous mOne system releases,
whereas the administrative user is fully able to configure and deploy the mOne system for live
network operation. mView provisioning provides an easy to navigate tree structure for configuring
the system; the applications components (TAS, CSCF etc..) are easily identified, and each have
logically partitioned configuration management menus for full provisioning capabilities.

There are three basic parts to the Configuration Management navigation tree, Platform, Interface
and the application (TAS, CSCF etc..)

Confidential. Version: 9
Page 63 of 72
  The “Platform” includes platform hardware / software and system management
related configuration data

 The Interface includes the SIP, Diameter, LDAP, SOAP etc.. interface related
configuration data

 The application includes all the relative application related configuration data

7.6 Accounting Management

The accounting management entity manages the billing and charging aspects on the
mOne platform and interfaces with external billing servers as needed.

The Mavenir platform can generate CDRs if call processing applies to the application
supported.

7.7 Performance Management

The Performance Management subsystem provides standard compliant (3GPP, RFC etc..)
performance counters for all the application components running on the mOne platform.
Two types of counters are supported, either Gauge or Cumulative counters. Gauge
counters are used to report measured values over some period of time based on a defined
sampling rate, and cumulative counters are used to report the cumulative number of pegs
of a specific event.

Performance Management (PM) data collection is activated by default whereby data is

collected and stored in periodic and daily registers. Performance data is stored in flat files
and can be up-loaded to an external system for display, data analysis and/or post-
processing purposes. The operator craftsperson may query the PM database by node, by
PM measurement parameters, PM data type, date and time to display basic PM reports in
tabular formats.

The following diagram describes the mView Performance Management sub-subsystem.

Confidential. Version: 9
Page 64 of 72
 3rd party
performance
management
system providing
reporting and
historical analysis
capabilities
SFTP

SFTP
Daemon

Local storage for

MX Database
statistics and log files,
stored for a
configurable duration

TMM
TMM function
provides centralized
collection of statistics
MX and logs

Application
Performance and log
files created locally by
application instances

Figure 5: Performance Management Sub-System

Depending on the application running on the mOne platform, different statistics will be
collected. The full list of the performance counter and statistics is not listed in the current
document and is provided in the LLD documentation.

7.8 Security Management

The mView EMS is designed with robust and secure administrative access controls. Access to
mView is centralized through the Web GUI interface where administration of individual user logins
and passwords is managed by a single secure management system.

The mView system administrator enforces policy management and assigns user access privileges
and roles to personnel using the EMS GUI or Centralized Management Server (CMS). There are
four types of roles defined as provided in the table below:

Table 3: mOne User Access Security Levels

User Roles Description

Super Administrator A Super Administrator is allowed to do the following:
 Add, delete and modify privileges for all parameters
 Add, delete and modify access permissions for all users
 Perform system backup
 Initiate software upgrades and downgrades

Confidential. Version: 9
Page 65 of 72
 User Roles Description
Administrator An Administrator is allowed to do the following:
 Add, delete and modify privileges for all parameters
 View permissions
User / Operator A User / Operator is allowed do to the following:
 View the privileges for all parameters
 Add, delete and modify a subset of all parameters
Guest A Guest is allowed to do the following:
 View the privileges for all parameters
 A guest cannot add, delete or modify any parameters within the
system.

Each user is defined with the following:

 User ID
 Password
 Name
 Email address
 User role (as shown above)
 Account lock status (locked or unlocked)
 User type (temporary, regular)

For each user type an access level can be defined. Access Management enables the assignment of
different access levels to different type of users for configuring different elements. Hence each user
group privilege is configurable on GUI. The access privilege is provided to different system elements
like Quick view, Fault Alarm, Fault Event, Fault Definition, Configuration, etc.

Confidential. Version: 9
Page 66 of 72
8. Deployment

8.1 Node Placement

Mavenir nodes will be placed in two central locations: Jakarta and Surabaya.

Each location will have the same set of equipment in active-active mode. In case of full failure on
one site, the other site should be able to take all of the traffic on both sites.

8.2 Resilience

8.2.1 Local Redundancy

Each logical system will have identical VM structure that will ensure in case of single point of failure
the traffic will be routed to other available logical IMS Core system at same site. This re-routing of
traffic is based on various SIP timers values configured at each node. Re-routing of traffic to identical
logical system at same site is done by provisioning node names as FQDNs and using DNS SRV
records to resolve to actual IP addresses. DNS system will also keep health record of each logical
system and will return IP list of only available/healthy logical IMS Core systems.

Confidential. Version: 9
Page 67 of 72
8.2.2 Geo Redundancy
The proposed solution for geo-redundancy is a two-site geo-redundant solution for each product.
Each site provides a full fault-tolerant solution with no single point of failure and each site provides
full capacity to support the whole network in the event that one site is lost (i.e. disaster protection).

In a standard geo-redundant deployment, it is assumed that each node has replicated hardware to
ensure no single point of failure (i.e. provides high availability). Geo-redundancy is typically deployed
to protect against site disasters or complete nodal failure (e.g. in the event of a fire). The
geographical redundancy is achieved by routing the traffic by the means of Dns responses.

8.2.2.1 Geo-redundant configuration overview (main elements)

As traffic enters the network and is passed through for processing, load balancing mechanisms are
used to distribute traffic and provide re-routing in the event of failure. This is done by provisioning
node names as FQDNs and using DNS SRV records to resolve to actual IP addresses.

The DNS is configured to favor local nodes over remote nodes. Traffic is only passed to the remote
site in the event of a nodal failure.

Note: that it is recommended that the capacity be engineered so that the entire traffic can be handled
by a single site. Also it is possible to deploy the geo-sites in active-active load balanced mode.

By using redundant hardware and geo-redundant replication, the goal is to provide the following
system behavior:

(1) Single Card or VM failure

 Does not result in traffic being routed to the second site
 Signaling – either the node is stateless, or subscriber state or context is replicated, so no impact to
new or in-progress sessions

Confidential. Version: 9
Page 68 of 72
(2) Nodal failure or site failure

• Results in re-routing of traffic to a second site

• Signaling – For new sessions, subscriber registration state is recovered (e.g. from HSS). Current
session state is not recovered, so depending on which node fails modifications to an established
session may fail with graceful termination of session.

Note on Capacity overload

Nodes are typically dimensioned for a maximum of 70% CPU occupancy which in normal operation
implies each platform will run at 35% CPU load. There is no license limit on the application
software (Mavenir nodes) so system capacity wholly relates to the capacity of the underlying
hardware.When the maximum capacity is reached, the nodes will reject any new requests with
“service unavailable” message (e.g. code 503). Requests may be sent to alternate geo-site.

8.3 Dimensioning
The SmartFren traffic requirements for messaging and presence is as follows:

8.3.1 SMSoIP requirements

 SMSoIP subscribers is 100% of VoLTE subscriber

o Phase 1 – 8,500,000 subscribers
o Phase 2 – 25,500,000 subscribers
 Call Model
o BH MO SMS per sub 1.5
o BH MT SMS per sub 1.5
o % of MO SMS which request status reports 0%
o % of MT SMS from legacy delivered in IMS 60%
o % of MT SMS from legacy where user is not IMS registered 30%
o % of MT SMS from legacy attempted in IMS, delivered in legacy 5%
o % of MT SMS from legacy attempted in IMS & CS but fail 5%
o % of MT SMS received from foreign SMSCs 70%

8.3.2 SMS Router and Message Store Requirements

SMS Router Phase 1 Phase 2

First delivery attempt (FDA)
= BH MT SMS * Num_of_Sub / 3600
= 0,6 * 8,5 Mill / 3600
= 1417 TPS

1417 TPS tbd

Message delivery attempt (MDA)
= FDA + (%MT IMS & CS but fail)
= 1417 * (100 + 5)%
= 1488 TPS
1488 TPS tbd

Confidential. Version: 9
Page 69 of 72
8.3.3 RCS requirements

 RCS subscribers is 10% of VoLTE subscriber

o Phase 1 – 850,000 subscribers
o Phase 2 – 2,550,000 subscribers
 Call Model
Avg IMs per 1:1 session 6
Avg 1:1 IM session duration (mins) 10
BH 1-N IM sessions created per sub 0.2
Avg IMs per 1-N session 10
Avg # of participants in 1-N chats 3
Avg 1-N IM session duration (mins) 30
Average size of file / photo transferred (KB) 300
BH 1:1 FT sessions created per sub 0.1

Maximum File size allowed = 10 Mb (configurable – applicable to FT, Image Share, Video Share

8.3.4 PRS requirements

 PRS subscribers is 10% of VoLTE subscriber

o Phase 1 – 850,000 subscribers
o Phase 2 – 2,550,000 subscribers
 Call Model
Avg entries in buddy list 40
Avg presence-enabled buddies 10
Avg watchers for each presentity 5

Confidential. Version: 9
Page 70 of 72
8.4 BOM
The following BOM is for one site. Each site has exactly the same elements as the other site.

8.4.1 For IP-SM-GW

IP-SM-GW Phase 1 Phase 2

# logical systems 1 1
# p-cores 80 152
# CPUs 10 19
GB or RAM needed (total for all VMs) 640 1216
TB of disk space needed (total for all VMs) 3.9 4.5
Integrated or Distributed? Distributed Distributed
Consolidated VM count
# Integrated VMs - -
# Distributed RM VMs 2 Small 2 Medium
# Distributed DM VMs 2 Small 2 Small
# Distributed AM VMs 2 Small 2 Medium
# Distributed TP VMs 4 Small 4 Medium
# Distributed SC VMs 10 Small 10 Medium

8.4.2 For SMS Router

SMS Router & Message Store Phase 1 Phase 2

# logical systems 2 Tbd
Integrated or Distributed? Integrated Tbd

8.4.3 For RCS and IP-SM-GW

RCS Phase 1 Phase 2

# logical systems 1 1
# p-cores 32 68
# CPUs 4 9
GB or RAM needed (total for all VMs) 256 544
TB of disk space needed (total for all VMs) 2.4 3.7
Integrated or Distributed? Integrated Distributed
Consolidated VM count
# Integrated VMs 2 Large -
# Distributed RM VMs - 2 Small

Confidential. Version: 9
Page 71 of 72
 # Distributed DM VMs - 2 Small
# Distributed AM VMs - 2 Small
# Distributed TP VMs - 7 Small
# Distributed SC VMs - 4 Small

8.4.4 For PRS

PRS
# logical systems 1 1
# p-cores 52 64
# CPUs 7 8
GB or RAM needed (total for all VMs) 416 512
TB of disk space needed (total for all VMs) 3.3 3.6
Integrated or Distributed? Distributed Distributed
Consolidated VM count
# Integrated VMs - -
# Distributed RM VMs 2 Small 2 Small
# Distributed DM VMs 2 Small 2 Small
# Distributed AM VMs 2 Small 2 Small
# Distributed TP VMs 5 Small 8 Small
# Distributed SC VMs 2 Small 2 Small

Confidential. Version: 9
Page 72 of 72