HLD_244_RMS_v03

Mavenir Systems, Inc. Confidential

Author: LorbyTitle: High Level Design Document RMS

Date: 2009-5-15

Revision: v0.3Document Number: 244 Page: 1 of 52

High Level Design DocumentRMS

Version 0.3

2009-5-31

Copyright © 2008All Rights Reserved

Mavenir Systems, Inc.



Date: 2009-5-15


Table of Contents

1. Revision History............................................................................4

2. Reference.....................................................................................5

3. Acronyms.....................................................................................6

4. Overview......................................................................................7

4.1. Scope.............................................................................................................74.2. Solution Diagrams..........................................................................................74.3. Functionality Summary...................................................................................84.4. Assumption and Restriction............................................................................84.5. System Architecture.......................................................................................94.5.1. Module Deployment............................................................................................................114.5.2. Deployment......................................................................................................................... 114.5.3. Routing Policy..................................................................................................................... 114.5.4. INTERFACE Definition........................................................................................................13

5. Components Design.................................................................14

5.1. SipIf..............................................................................................................145.2. Device..........................................................................................................145.2.1. StateMachine...................................................................................................................... 155.3. Session.........................................................................................................195.3.1. State Machine..................................................................................................................... 20

6. Interaction Scenarior................................................................25

6.1. Overview......................................................................................................256.1.1. Registration and Deregistration...........................................................................................256.1.2. MO SMS/IM........................................................................................................................ 256.1.3. SRI and MT SMS................................................................................................................266.1.4. Status report....................................................................................................................... 286.1.5. TP-MR in MO...................................................................................................................... 296.1.6. Concatenated Message......................................................................................................296.2. Call flow........................................................................................................306.2.1. Registration......................................................................................................................... 306.2.2. Deregistration...................................................................................................................... 326.2.3. MO SMS............................................................................................................................. 346.2.4. GSM SMMA........................................................................................................................ 366.2.5. MT SMS—User Registered in RMS....................................................................................366.2.6. MT SMS—User not registered in RMS...............................................................................40



Date: 2009-5-15


6.2.7. STATUS REPORT..............................................................................................................41

7. Interface Definition....................................................................43

8. Theory of Implementation........................................................46

9. System wide feature.................................................................48

9.1. Resilience.....................................................................................................489.2. Event and Alarm...........................................................................................489.3. CDR and TRL...............................................................................................489.4. KPI................................................................................................................48

10. Configuration.............................................................................49

11. FRS Compliance Matrix............................................................50

11.1. FRS............................................................................................................50

12. Test Recommendations............................................................51

12.1. Unit Test.....................................................................................................5112.2. Integration..................................................................................................5112.3. System Test...............................................................................................51

13. Open Issues / Review Comments............................................52

14. Appendix.....................................................................................53



Date: 2009-5-15


1. Revision History

Version Author Comments Date0.1 Lorby Initial Draft May 15th,20090.2 Lorby 1. Add call model

2. Change according to review comments

3. Update INTERFACE definition

4. Correct the IMDN handling5. Follow the last FRS6. Update the SRI handling7. Update the long SM

handling8. Refine the StatusReport

handling9. Update state machine, add

new section 5.1

May 29th, 2009

0.3 1. Add section 6.1.6 which describe the long SM handling

May 31st,2009



Date: 2009-5-15


2. Reference

The reader should be familiar with the following documents:

FRS244: "FRS_244_IP_SM_GW_V0.6.doc"

3GPP TS 29.002 v8.8.1 – MAP Specifications

3GPP TS 23.040 “Technical realization of the Short Message Service (SMS)”

3GPP TS 23.204 “”Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2”

3GPP TS 24.229 “IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3”

3GPP TS 24.341 v8.0.0 – Support of SMS over IP networks

3GPP TS 29.311 v8.0.0 – Service Level Interworking for Messaging Services

3GPP TS 29.228 “IP Multimedia (IM) subsystem Cx and Dx interfaces; Signalling flows and message contents”

3GPP TS 29.328 v8.3.0 – Sh Interface Signalling flows and message contents

3GPP TS 29.329 v8.2.0 – Sh Interface based on the Diameter Protocol

OMA TS SIMPLE IM v1.0_20080903-C

IETF RFC 5438 “Instant Message Disposition Notification”

IETF RFC 3428 “Session Initiation Protocol (SIP) for Instant Messaging”

IETF RFC 3680 “A Session Initiation Protocol (SIP) Event Package for Registrations”

IETF RFC 3840 “Indicating User Agent Capabilities in the Session Initiation Protocol”

3GPP TS 24.011 v8.0.0 – Point-to-Point SMS support on mobile radio interface



Date: 2009-5-15


3. Acronyms

3GPP Third Generation Partnership ProgramCE mOne Compute Engine CardCS Circuit SwitchedCS_PS Circuit and/or Packet SwitchedDM mOne Distribution ModuleDNS Domain Name System - translate names into IP addressesEM Enhanced MessagingENUM E.164 Number MappingGPRS General Packet Radio ServiceGSM Global System For MobileHLR Home Location RegisterHSS Home Subscriber ServerIM Instant MessageIMS IP Multimedia SubsystemIMSI International Mobile Station IdentifierMAP Mobile Application PartMSC Mobile Switching CentreOMA Open Mobile AllianceP-CSCF Proxy Call Session Control FunctionPS Packet SwitchedRFC Request For CommentsRMS Rich Messaging ServerS-CSCF Serving Call Session Control FunctionSGSN Serving GPRS Session NodeSIP Session Initiation ProtocolSL Service Level (interworking)SM Short MessageSMS Short Message ServiceSMSC Short Message Service CentreSOS SMS Offload SolutionSTP Signal Transfer PointTL Transport Level (interworking)TPR Third Party RegistrationTS Technical SpecificationUE User EquipmentURI Uniform Resource Identifier



Date: 2009-5-15


4. OverviewMavenir’s RMS combines functionality of both IP-SM-GW and IM AS functions as defined by 3GPP standard into single AS.

The solution utilizes interface with both HSS and HLR to deliver service transparency to the SIP/IMS or Dual Mode subscriber attached in both IMS and GSM/GPRS domain. mOne in this solution will act as a AS in pure IMS terminology.

4.1. ScopeThis document defines the overall architecture, the detail design of the application including the call flows.The present document mainly focuses on application layer, please refer to Ss7 HLD to get the detail info of Ss7 part.

4.2. Solution Diagrams

Figure 4-1 External InterfaceAs shown in Figure 4-1,the following interface are adopted by IPSMGW:

ISC: Based on SIP MAP(C,E,J) Interface



Date: 2009-5-15


Sh: Based on Diameter DNS

4.3. Functionality SummaryThe following procedures/function should be implemented in the IPSMGW.

Link managemento Monitor the virtual ISC Link statuso Allow the operator manually control the links

Registration/Deregistration, Processing the 3p-reg, includingo Subscribe to the reg-event of the registered usero Download the user-data from HSSo Update the user state to HSS

MO SMo Support TL interworking and SL interworkingo Support IMDNo Retry between upmost 2 SMSCs

MT SMo SRI relayo Domain selection/Retry between IMS and CS/PS domaino TL/SL level interworkingo SM relayo Unregistered MT forwardingo Error status report

Subscriber ready notification CDR/TRL/KPI

4.4. Assumption and RestrictionRMS do not need cache undeliverable message, hence the memory will not be a major concern in this product, while thinking about high TPS is required for SMS service, the CPU performance will be a challenge, so, it is tried to remove any unnecessary message interaction between different modules.



Date: 2009-5-15


4.5. System Architecture

Figure 4-2 System diagramFigure 4-2 illustrates the system hierarchy, the call model is shown in the below diagram.

Figure 4-3 Call modelFull call model is adopted for the sms service, which means only one session will be involved for either MO or MT message delivery. Currently, the IPSMGW just acts as gateway to perform the service exchange from IMS client to SMSC and vice versa. In the future, if the offload is needed, MO session will perform real routing selection and trigger a MT session internally if the destination can be routed in this server. In which case, the



Date: 2009-5-15


basic logic in MO session and MT session will not change just like there’s a virtual SMSC inside.As a protocol adapter, Endpoint handles the protocol related service data, esp. it takes care of the content related data. With the introduction of Endpoint, Session merely handles the common service logic such as routing. In other word, the endpoint handle the concrete interworking.

All the supported/platform components are inherited from 5.x and 4.x, the following modules will be impacted

SipMgr: SipMgr should support MESSAGE and the new product. FacMgr: FacMgr takes the responsibility of link management,

o monitor the ISC link via SIP interface Ss7UMgr: The framework of SS7 does not need be changed, while the MAP

should support Rel8 SipLib: Support MESSAGE, OPTION and SUBSCRIBE client DM: Besides the functionality in 5.0, the DM need support the extra function,

Each DM Key can be set a forceful flag includes:o Report conflict: if confliction happens, do not perform further action but

respond erroro Ignore conflict: if confliction happens, do not reset it, record it in the

response, continuing set the otherso Forceful: set it regardless the confliction

SipIfMgr: o Support MESSAGE, OPTIONo support the MIME type: cpim, textplain, cpim/imdno support subscription client

RmsMgr: A new introduced application which handle the service logic of IPSMGW, which includes

o DeviceMgr: Maintain the user data Handle the registration/deregistration logic Trigger the service: Subscribe and download the user data from

HSS Trigger the management service: ATM,User availability report Providing user data to session, session managing

o SessionMgr: Handle the SMS logic, policy checking Separated to MT session and MO session Including Session and Endpoint

Utility Library:Support XML parser



Date: 2009-5-15


4.5.1. Module Deployment

IPSMGW is based on the 5.x infrastructure, including RM/DM/SIP/CDR/Platform, the SS7 part is migrated from 4.x.In the application level, a new application RmsMgr which includes Session and Device is introduced.In phase1, all the cards(except for ADM) are run in active-active mode. If the resilience is required in the future, the CE card could be run in active-standby mode or introduce a centralized DB.

Figure 4-4 Solution Diagram-Detailed view

4.5.2. Deployment

SI card: Ss7LMgr, SipMgr, DiamMgr, DnsResolverMgr1

CE card: Ss7UMgr, DeviceMgr, SipIfMgr,SessionMgr, ADM card: FacMgr, CdrMgr

The data related to each user is anchored in one card. Furthermore, as the internal module of RmsMgr, the associated device and session are run in the same thread, the interaction between Session and Device is based on function call but not MX message.

4.5.3. Routing Policy

The communication between SipIfMgr, SessionMgr and DeviceMgr is always via local card internal MX message or function call.

Registration: o SipMgr SipIfMgr: FWD_SET, DMKey=UserId

1 Generally, it should run in SI card(as shown in the diagram), while according to the FRS, it is required Dns run in the same card as application



Date: 2009-5-15


o SipIfMgrDeviceMgr: Local card Deregistration:

o SipMgrSipIfMgr: FWD_NO_SET, DMKey=UserId Incoming MESSAGE(message)

o SipMgrSipIfMgr: FWD_NO_SET, DMKey=UserId; SipIfMgr will create an object for each MESSAGE request

o SipIfMgrSessionMgr: Local card, to any SessionObject Incoming MESSAGE(report)

o SipMgrSipIfMgr: FWD_NO_SET, DMKey=UserId (or as optimization forward based on In-Reply-To)

o SipIfMgrSessionMgr: Sms: Forward to the specific SessionObject which is encoded in

In-Reply-To Imdn: Forward to the specific SessionObject which is encoded in

imdn.messageid Incoming SRI

o Ss7LMgrSs7UMgr: mxLBSend() is used to select arbitrary instance of Ss7UMgr

o Ss7UMgrSessMgr: FWD_NO_SET,DMKey=MSISDNo Session will encode the objected in the MT correlationId

Incoming MT-SMo Ss7LMgrSs7UMgr: mxLBSend() is used to select arbitrary instance of

Ss7UMgro Ss7UMgrSessMgr: Send to the particular session object based on MT

correlationId1 if MT correlationId is presented, otherwise, FWD_NO_SET, DMKey=IMSI(LMSI)

Outgoing MT-SMo SessionMgrSipIfMgr: Local cardo SipIfMgr should encode the session oid in callId and imdn.messageIdo SessionMgrSs7UMgr: Local card

Subscriptiono DeviceMgrSipIfMgr: Local cardo SipIfMgr should encode the oid of itself in the contact header which will

be used by SipMgr to forward subsequent requesto DeviceMgrDiamMgr: mxLBSend()

PNR(NA for phase1):o DiamMgrDeviceMgr: FWD_NO_SET, DMKey=UserId/MSISDN

4.5.4. INTERFACE Definition

SipIfMgr:

1 Thinking about the codec length limitation, INTERFACE cannot be encoded in, hence the dest interface will be INTERFACE_RMS, the rmsMgr should check it accordingly.



Date: 2009-5-15


o INTERFACE_RMS_SIPIF: The main interface of SipIfMgr, all the initial request is sent to this interface, the SipIfMgr will deliver to internal function block based on message type. SipIfMgr may define the following INTERFACE for subsequent message delivering

INTERFACE_IMGW_SIPIF_TXN: Handle the MESSAGE/OPTION/REGISTER request

INTERFACE_IMGW_SIPIF_SUBS: Handle the subscripition request

RmsMgro INTERFACE_RMS: The main interface of RmsMgr, all the initial request

is sent to this INTERFACE. RmsMgr will dispatch to internal module.o DeviceMgr:

INTERFACE_IMGW_DEVICEo SessionMgr:

INTERFACE_IMGW_SESS_MO INTERFACE_IMGW_SESS_MT



Date: 2009-5-15


5. Components DesignOnly SipIfMgr, DeviceMgr and SessionMgr are included in this section.

5.1. SipIfSipIf, a thin pad which is at the top of SipLib that implements the SIP protocol, provide the protocol translation between SIP and internal MX message.As for MESSAGE request, SipIf should check whether In-Reply-To header1 is presented or whether it is an imdn report to determine the destination.When sending out a request, SipIf should comply with the following rules:

MESSAGE: encode the SessionOid in the CallId and the imdn.messageid if presented

SUBSCRIBE: encode the SipIfOid in the contact All request: encode the SipIfOid in the via header

5.2. DeviceDevice maintains the user profile, the ongoing session index. The registration related process is also handled in Device.Each Device object represents one user.The table shows the main user data should be stored in Device

Table 1 User profileName Description Related Procedure

UserInfos A set of UserId, including IMPU,MSISDN,IMSI, together w/ UserCapabilities for the particular Id,contact Info(refer to FRS)

Registration, Subscription AND/OR Get from HSS

AssociatedUserInfos A set of UserId, including IMPU, together w/ UserCapabilities for the each userId, contact Info(refer to FRS)

Subscription AND/OR Get from HSS

UserCapabilities A member of UserInfo. The capabilities of the user, including sms/im/textplain only

Registration, Subscription, MO Message, Local configuration

ScscfAddress Uri of associated SCSCF which is used for outgoing SIP request

Registration

RegTimeStamp The timestamp of the recent registration (Expires will be handled by timer implicitly)

Registration

ChVector ChargingVector, Including orig-ioi and icid for each registration procedure

Registration

ChAddress Charging Address RegistrationUNRIFlag The UNRI MT SM, Registration , MO

SM, READY_FOR_SM, SMMA

MOSessList List of MO Session Info, Session should record the index of the entry in the list

Created w/ MO-SM, destroyed when MO-SM terminated

MTSessList List of MT Session Info including status and SessionOid, Session should record the index of

Created w/ MT-SM, destroyed when MT-SM terminated, if a

1 Thinking about Session will not maintain the mapping of MSISDN and SessionOid, if In-Reply-To is not provided for sms report, there’s no way to find the serving session object.



Date: 2009-5-15


Name Description Related Procedurethe entry in the list, to optimize the searching procedure, a queue and an array is used together2

ongoing session is terminated, Device should resume the next pending session

SRISessList List of MT Session Info which waiting for SRI, if MT SessList is not empty, this list must be empty, so it can share the same member w/ MTSessList in theory

SRI to Unregistered Device

State Record the state of the Device: Registered, Registering, Deregistering, Unregistered

MtReference Mapping to the TP-MR, it MUST be increment by 1 for EACH SUBMIT (NOT each sm). The type MUST be u8_t.Device should provide a function to get this value, in which increase it by 1 for each get operation.

MapEp must fill the TP-MR field w/ this value when submitting each piece of a sm.

ImdnCacheList Record the object info of cached imdn info or maintain the ImdnCacheTable per subscriber, it depends on the implementaiotn

As mentioned above, Device will be separated as the following functionality: UserProfile(VLR), All the user data is stored in Device object DevReg, Which handles the 3rd party registration/deregistration procedure, the

DevReg process mainly focus on the state change in Device. DevService, Which includes several different service process and data related to

these service as following:o DevHlrUpdator, maintains the ATM interaction w/ HLRo DevSubs, maintains the SUBSCRIBE reg state info and procedureo DevHssSubs, maintains the Sh related processo DevSess, maintains the interaction w/ SessionMgr

Each functionality must have an individual state machine.

5.2.1. StateMachine

RegistrationIt is not taken into account to cache the UNRI flag after deregistered, to implement this feature, simply adding an extra expires in deregistered state is fine.

2 A pending session could be terminated before others



Date: 2009-5-15


Figure 5-5 Device State MachineFigure 5-5 shows the state machine of the Device object, the main concern of having so many states is there are multi-publicId for one user, in which all the publicIds could be registered simultaneously, while all the publicIds should be anchored in the same card if they sharing the same user data.An exception is from registered to SubsDmKeySetting, at this point, the MSISDN related data is already set in the current node, the Device does not care the other publicIds if they do not have the same MSISDN and IMSI.

DevHlrUpdator



Date: 2009-5-15


Figure 5-6 DevHlrUpdator State Machine

DevSubs



Date: 2009-5-15


Figure 5-7 DevSubs State Machine

DevHssSubs

Figure 5-8 DeviceHss State Machine



Date: 2009-5-15


DevSessNo particular state transition for DevSess. Generally, the process is as following:

o MO: GetUserData will always successfulo MT: SRI, if is registered, always return the corresponding data, or else,

send back the corresponding data after unregistered data is downloaded or notify the session to move if the user is anchored in other node.

o MT: MTSmInd, record the sessioOid respond w/ success, error or pending. Upon MTSessTerminated, resume the next Session.

o When a MO is received, Device should clear UNRI flag(including informing HLR) if it is set

o When a MT is succeed, Device should clear UNRI flag(including informing HLR) if it is set

o When a MT is unsuccessful, Device should set UNRI flag according to the causeCode1

5.3. SessionThe only responsibility of session is to handle the SMS service. Two types of session: MO Session and MT Session are adopted to handle MO/MT service.To isolate the generic routing logic and the protocol specific handling, Session is divided into Session and Endpoint layer as shown in Figure 5-9, in which the session focus on the routing logic, domain selection, the general message handling (such as incoming SRI and SRI relay), while the Endpoint take care of the content conversion and the other protocol specific handling such as the report mechanism for SIP, the MT relay logic in MAP, message fragment in MAP, etc.

Figure 5-9 Session StructureThere are many different types of endpoint, with each type mapping to a particular protocol service. While all the endpoints provide the same interface to session. So,

1 Notifying the HLR is done in session



Date: 2009-5-15


session does not care the actual type of the endpoint. On the other hand, endpoint does not care about the type of session as well.Currently, two types of endpoint are defined:

SipEndpoint, which handles sm/im come from/to SIP client. In fact, SipEndpoint maintains the following three types of service: IM/IM wtih imdn/smsip, thinking about it’s not complex, all the three types of service are handled in the one endpoint but not be separated to different endpoints.

MapEndpoint, which maintains the interaction with peer based on MAP protocol.

To handle the long SM and the Status report, three mapping table, SmSessionMapping, StatusSessionMapping and ImdnCache are maintained in SessionMgr.

5.3.1. State Machine

MO Session

Figure 5-10 Session State Machine-MO Session

MT SRI



Date: 2009-5-15


Figure 5-11 Session State Machine-SRI MT Session

Figure 5-12 Session State Machine-MT Session Status Report



Date: 2009-5-15


Figure 5-13 Session State Machine-Status ReportBasically, the Pending and Delivering state is the same as the MT SMS, the only difference is the data that impacts the routing selection. Such as for imdn report, the status report should not try other iw or domain even the imdn report fails.

SipEndPoint



Date: 2009-5-15


Figure 5-14 Session State Maching-SipEndpoint

MAPEndPoint

Figure 5-15 Session State Machine-MAPEndpoint outgoing



Date: 2009-5-15


Figure 5-16 Session State Machine-MAPEndpoint Incoming and Status report



Date: 2009-5-15


6. Interaction Scenarior

6.1. OverviewAll the initial request from protocol layer will arrive to INTERFACE_RMS firstly, the RmsMgr will delegate to the concrete module, generally, a new related object will be allocated to handle the request.The response and the subsequent request will be destined to the dedicated object.

6.1.1. Registration and Deregistration

When a REGISTER message is received, device will set the MSID as key firstly, after which, it respond with success immediately. Then, the following service will be triggered, currently, there’s no sequence dependency among them.

Update HLR with the RMS’ address, ATM Download repository data from HSS, UDR Subscribe to reg-event, SUBSCRIBE/NOTIFY Subscriber availability notification if it is a refresh registration

When both SUBSCRIBE and UDR succeed, Device should check whether it is necessary to update repository data in HSS, if the answer is yes, PUR procedure should be invoked.

There are three types of deregistration: Subscriber DEREGISTERED, in which case, device should clear DmKey after

Sip transaction timeout Scscf NOTIFY with user deregistered state. Timeout

Upon deregistration, the following service should be triggered without sequence dependency.

Update HLR with clearing the RMS’ address, ATM Remove the repository data if it is updated by this RMS.(UDR/PUR) Unsub reg-event if the deregistration is not triggered with NOTIFY or the

subscription state is not terminated.

6.1.2. MO SMS/IM

According to the current requirement, the MO SM is always sent to the SMSC, hence it is not required to concatenate the long MO SM in RMS. In the future, if it is required, the SessionMgr should maintain an association between split SM and the dedicated session object.

Upon MO SMS/IM from SipIfMgr, SessionMgr will Session will perform the 1. Session create a SipEndpoint to handle the incoming service request.2. SipEndpoint recognize the service type(smsip/im/im with imdn) and notify to

Session



Date: 2009-5-15


3. Session performs the policy checking(with the data from Device), build the destination list (SMSC list, currently only 1, twice), then create the corresponding outgoing endpoint and send the message to which.

4. SipEndpoint should a. If service is smsip, respond with 202 prior at notify the session; send the

submit report in MESSAGE when session return error or a submit report is received(see below)

b. If service is im, respond with 202 or an error response code depending on the return value from session.

c. If service is im with imdn, respond with 202 or an error response code depending on the return value from session.

5. The outgoing MapEndpoint shoulda. Decide to split the SM or notb. Fill the TP-MR with the RMS’ TP-MR value for EACH piece of sm if it is

service interworking, otherwise do not touch this area.c. Set TP-SRR accordingly.

6. Upon SubmitReport, MapEndpoint should notify the session which send to SipEndpoint for further processing

7. Upon SubmitReport, SipEndpoint shoulda. If service is smsip, send submit report in MESSAGEb. If service is imdn with “positive-delivery” or “negative-delivery”

indication, and the SubmitReport does not contain user-error, do NOT send imdn with success, just cache the following info into ImdnCache: RequestUri, P-AssertedId, imdn.MessageId, TP-SCTC, the key is TP-SCTS and RP-OA(MSISDN of the orignator).

c. If service is imdn with “negative-delivery” inidication, and the SubmitReport contains user-error, send imdn with failed, do NOT cache anything

d. Otherwise, discard it.8. Session should try all the destination until a successful response is received.

6.1.3. SRI and MT SMS

In theory, SRI and MT SMS are individual procedure which should not be combined together; Currently SessionMT is borrowed to handle SRI as well, although it looks not good. While a new SRI object may make more sense.

Concatenated SM should be taken into account. According to the spec, each piece of sm is delivered independently.

When SRI is received, a session object is allocated to handle the request.1. If the user is not registered in the RMS, device will download the user profile to

satisfy the request from session, if downloading fail, SRI relay is performed in session, otherwise,



Date: 2009-5-15


2. If MTcorrelationId is configured to be used, the node-inst-sequenceId is encoded in the MTcorrelationId, else, IMSI/LMSI is used. Session MUST BE TERMINATED immediately after SRI response is sent.

3. When a MT SM comes from SMSC, the SessionMgr should check the message type firstly, here it’s a MT SM, then it should check whether it is part of long message based on IE001 or IE08(if presented) in TP-UD2.

a. If it’s a short SM (MaxNum =1), create a new SessionMT object and deliver the request to the session

b. Else if it’s a long SM, find the session object based on the MTCorrelationId/IMSI, if no matched object, create one and cache the mapping (MTCorrelationId/IMSI+IED0 of IE00 or IE08 in TP-UD3 Session object), deliver the request to the session

4. Session notify to device about the service and deliver the request to Incoming MapEndpoint who will concatenate long message and respond to each piece (except the last one) if response from device indicate that the session can be continued.

5. MapEndpoint send the entire SM to Session after all are received and concatenated, session check the operator policy and decide the domain and interworking level based on the user capability and configuration, after which session create a appropriate outgoing endpoint to handle message delivery.

6. If CS/PS domain is selecteda. The outgoing endpoint is MapEndpoint. The endpoint should send SRI to

get the routing info and send out the SM based on the info in SRI responseb. When the last DeliveryReport is received, notify to session of the

response.7. If IMS domain is selected, a SipEndpoint is allocated

a. If service is IM, the SipEndpoint should send out the SM with MESSAGE without including imdn (RMS do not want to get the imdn report since it is assumed there’s no IM entity between RMS and UE); Upon a final response of the MESSAGE, the endpoint respond DeliveryReport to the session with corresponding info.

b. If service is SMSIP, the SipEndpoint should sent out the SM with MESSAGE, if a 4xx/5xx/6xx response is received, the endpoint should respond error DeliveryReport to session; if 2xx is received, the endpoint should respond corresponding DeliveryReport to session after a DeliveryReport is received with MESSAGE request(SipEndpoint should respond with 200 immediately to this request) or timeout happens.

8. Session should try all possible destination until success, if all faila. Session should waiting for the Report Delivery Status request from HLR

and forward back with filling the detail reason.

1 Refer to 23.040,Section 9.2.3.24

2 TP-MMS cannot be depended here, since no more send does not mean it is not a concatenated SM.

3 TP-MR should not be depended here, since it’s per each SUBMIT



Date: 2009-5-15


b. Set the UNRI flag in device.9. Delete the entry cached in SmSessionMapping table when session is terminated.

6.1.4. Status report

Status report is a MT procedure, while not like the normal MT SMS, the Status report is associated with the previous submitted SM/IM, and hence the handling is different.

For transport level interworking, RMS do not need additional action but just forwarding the status report, but if the original MO service is IM with imdn, RMS have to get the original info and construct a corresponding imdn report. To combine the two interworking level, the RMS should search the imdn cache firstly, if mtaching is found, the imdn report can be constructed, otherwise, RMS will try transport level interworking, if it is not allowed, an error reponse will be generated.

SessionMgr should distinguish whether a MT_FSM is a status report or normal short message at first, if it is status report

1. Find the corresponding session object based on MTCorrelationId/IMSI+TP-SCTS, if no matching, create a new session object and insert the mapping to StatusSessionMapping table

2. Session passes the request to the incoming MapEndpoint. The MapEndpoint indicate Session a StatusReport is received. Upon the indication, Session try to find the corresponding imdn entry in imdn cache with key = MSISDN+TP-SCTS.

3. If a imdn entry is found (and removed from the cache), Session indicate the MapEndpoint to collecting all the related report.

a. After collecting all the report, the MapEndpoint indicate the Session with success report if all the received report are successful otherwise with failure report

b. Upon the report from MapEndpoint, Session create a outgoing SipEndpoint to send the corresponding imdn report

c. Upon response from Sip side, SipEndpoint respond corresponding DeliveryReport to Session who will forward to upstream via MapEndpoint.

4. If no matching imdn entry, Session indicate the MapEndpoint to send the report immediately

a. Upon the report, Session check the policy, if transport level interworking and CS/PS doman forwarding is not allowed, an error report is responded

b. Otherwise, Session send the status report to the corresponding outgoing Endpoint

c. The Endpoint handle the report just like the normal MT short message.5. For the transport level interworking, the optimization of using one session to

collect all the related status report is not adopted in this phase thinking about it may introduce additional complexity to handle multi-endpoint at the same time.



Date: 2009-5-15


6. Delete the entry cached in StatusSessionMapping table when session is terminated.

6.1.5. TP-MR in MO

How to handle the TP-MR in MO case? Two choices may be adopted RMS reset TP-MR when submitting to SMSC regardless SL iw or TL iw. The

problem is the STATUS-REPORT will carry wrong TP-MR to UE in TL iw since RMS just forward the report

RMS does not change TP-MR if it’s TL iw. The problem is, there’s two source of TP-MR that cannot ensure it is unique.

Currently, the first approach may make sense since according to the spec it is possible that a status report may arrive at UE after the related message was deleted.

6.1.6. Concatenated Message

MT case, the incoming endpoint (MapEndpoit) should concatenate the long SM so that it can be used to deliver as either im or smsip

o An alternative is, checking the policy firstly, if TL is selected, Rms forwards the SM piece by piece without concatenating. The problem is, if the first trying failed, it may fall back to SL or trying other domain, extra complexity may be involved. If performance is not an issue, this approach will not be tried.

MO case, currently, if the originating side is smsip, only TL will be invoked, so, RMS does not concatenate the SM but forwarding it piece by piece, which means, SipEndpoint does not need care about concatenating.



Date: 2009-5-15


6.2. Call flow

6.2.1. Registration

Figure 6-17 Call flow--Registration-1



Date: 2009-5-15


Figure 6-18 Call flow--Registration-2



Date: 2009-5-15


6.2.2. Deregistration

Figure 6-19 Call flow--Deregistration



Date: 2009-5-15




Date: 2009-5-15


6.2.3. MO SMS

Figure 6-20 Call flow--MO SMS-1



Date: 2009-5-15


Figure 6-21 Call flow-MO SMS-2

6.2.4. GSM SMMA

Figure 6-22 Call flow--GSM SMMA



Date: 2009-5-15


6.2.5. MT SMS—User Registered in RMS

Figure 6-23 Call flow--MT SMS(Registered)-1



Date: 2009-5-15





Date: 2009-5-15





Date: 2009-5-15


6.2.6. MT SMS—User not registered in RMS

Figure 6-26 Call flow--MT SMS(Unregistered)



Date: 2009-5-15


6.2.7. STATUS REPORT

Figure 6-27 Call flow--Status report-1



Date: 2009-5-15


Figure 6-28 Call flow--Status report-2



Date: 2009-5-15


7. Interface DefinitionThe below table defined the main API/Messages and the related data(Shall the SIP message and MAP message type be separated?). Diameter related interface is not shown here, please refer to DiamMgr doc.

Table 2 Interface defnitionAPI/Message Modules Data carried DescriptionMSGTYPE_REGISTER_IND SipIfMgrDevice PublicId, Contact, Supported feature,

RegInfo(MSISDN, IMSI), ChargingVector, ChargingAddr

ChargingVector info can be stored in Sip, hence do not need pass to Device

MSGTYPE_REGISTER_RSP DeviceSipIfMgr Causecode, termIoiMSGTYPE_SUBSCRIBE_IND DeviceSipIfMgr PublicId, Server Addr(Scscf), expires,

ChargingVector, ChargingAddrMSGTYPE_SUBSCRIBE_RSP SipIfMgrDevice CausecodeMSGTYPE_NOTIFY_IND SipIfMgrDevice RegInfo(Associated pubId, contact,

feature tag)MSGTYPE_NOTIFY_RSP DeviceSipIfMgr CausecodeMSGTYPE_SMS_SUBMIT_IND SipIfMgrSessMO(S

ipEP)Calling party PublicId, Supported feature, content type, content (inside RP-DATA, SMSC and orig MSISDN will be provided)

MO SMS

MSGTYPE_SMS_SUBMIT_RSP SessMO(SipEP)SipIfMgr

Causecode Mapping to Sip MESSAGE response

MSGTYPE_SMS_SUBMIT_RPT_REQ SessMO(SipEP)SipIfMgr

Terminator PublicId, contact (Scscf), ChargingVector, content type, content(which include the status)

MO SMS report, Mapping to Sip MESSAGE request which include imdn or sms report in RP-DATA

MSGTYPE_SMS_SUBMIT_RPT_CFM SipIfMgrSessMO(SipEP)

Causecode

MSGTYPE_SMS_SUBMIT_REQ SessMO(MapEP)MapMgr

IWMSC/SMSC PC or GTT number, payload

Mapping to MAP_MO_FSM_REQ,Originator’s MSISDN should be encoded in the payload

MSGTYPE_SMS_SUBMIT_CFM MapMgrSessMO(MapEP)

Causecode, payload(submit report)

MSGTYPE_SRI_SM_IND MapMgrSessMT MSISDN inside the payload An indication of whether SM is to be sent should be cared

MSGTYPE_SRI_SM_RSP SessMTMapMgr Causecode, MTCorrelationId(node,instId,subOid is encoded)

MSGTYPE_SRI_SM_REQ SessMTMapMgrSessMT(MapEP)MapMgr

MSISDN, dest addess (PC of HLR) SRI relay or CS/PS SMS forwarding

MSGTYPE_SRI_SM_CFM MapMgrSessMTMapMgrSessMT(MapEP)

MTCorrelationId is included

MSGTYPE_SMS_DELIVERY_IND MapMgrSessMT(MapEP)

MTCorrealtionId,Payload(MAP RP Data)

MSGTYPE_SMS_DELIVERY_RSP SessMT(MapEP) Causecode (RP report)MSGTYPE_SMS_DELIVERY_REQ SessMT(SipEP)SipI

fMgrSessMT(MapEP)MapMgr

MTCorrelationId, Payload, next hop’s address

Payload is a buffer

MSGTYPE_SMS_DELIVERY_CFM SipIfMgrSessMT(SipEP)MapMgrSessMT(MapEP)

Causecode

MSGTYPE_SMS_DELIVERY_RPT_IND SipIfMgrSessMT(Si UserId(SMS receiver’s id), content Mapping to Sip



Date: 2009-5-15


API/Message Modules Data carried DescriptionpEP) type, content MESSAGE which convey

the sms RP_REPORT or imdn, SipIfMgr should parse the data to get the info

MSGTYPE_SMS_DELIVERY_RPT_RSP SessMT(SipEP)SipIfMgr

Causecode Mapping to Sip MESSAGE response

MSGTYPE_RPT_SM_DLV_STATUS_IND MapMgrSessMT Status,userinfo REPORT-SM-DELIVERY-STAUS

MSGTYPE_RPT_SM_DLV_STATUS_RSP SessMTMapMgrMSGTYPE_RPT_SM_DLV_STATUS_REQ

SessMTMapMgr IPSMGW outcome

MSGTYPE_RPT_SM_DLV_STATUS_CFM

MapMgrSessMT

MSGTYPE_ATM_REQ DeviceMapMgr IPSMGW address(E.164), MSISDN of the user

MSGTYPE_ATM_CFM MapMgrDevice CausecodeMSGTYPE_RFS_REQ DeviceMapMgr UserInfo(IMSI), Reason READY_FOR_SMMSGTYPE_RFS_RSP MapMgrDevice CausecodeMSGTYPE_SESS_MOVE_REQ/CFM SessionSession SRI request infoMSGTYPE_DEVICE_MOVE_REQ/CFM DeviceDevice UserInfo(serialize)

GetRoutingInfo() SessMTDevice Input: MSISDN, SessionOid,Output: Status, DevAppIdReturn: Pending or not

Status include: Existed, Not exsited

GetRoutingInfoAck() DeviceSessMT Input: Status,DevAppId NewMOSmsInd() SessMODevice Input: SessionOid

Output: DevAppIdNewMTSmsInd() SessMTDevice Input: SessionOid, UserId

Output: DevAppId, UserCap, ConactInfo(Scscf Addr)Return: Pending or not

ResumeSession() DeviceSessMT Input: SessionOidMoveSession() DeviceSessMT Input: Dest node Session must be in the

state of waitingRoutingInfo, in the destination side, GetRoutingInfo will be called once more

SmsSubmitInd() SipEPSessMO Input: SMS data, userId(MSISDN) SmsSubmitRsp() SessMOSipEP SubmitReportSmsDeliveryInd() MapEPSessMT Input: The assembled sms dataSmsDeliveryRsp() SessMTMapEPSmsSubmitReq() SessMOMapEP Input: The message data MapEP will split it if

neededSmsSubmitCfm() MapEPSessMOSmsDeliveryReq() SessMTMapEP

SessMTSipEPMapEP will split it if needed

SmsDeliveryCfm SipEPSessMTMapEPSessMT

SmsGsmSmmaInd() SipEPSessMO SMMA is a type of RP data, SipEP interpret the SMS as SMMA

SmsGsmSmmaRsp() SessMOSipEPNewStatusReport() MapEpSessMTStatusReportInd() MapEpSessMTStatusReportRsp() SesssMTMapEpStatusReportReq() SessMTSipEp,Map

EpStatusReportCfm() SipEp,MapEpSess

MTCacheSplitSms() MapEPSessMT



Date: 2009-5-15


API/Message Modules Data carried DescriptionGetSplitSms() MapEPSessMT Return Error if no splited cache



Date: 2009-5-15


8. Theory of ImplementationThinking about the CPU performance will be the major concern, the multi-thread must be taken into account from beginning. On the other hand, it must be taken into mind trying to reduce the message interaction among different module, while the module independency should also be thought about to reduce the risk of debugging and maintaining.

It is decided: Session and Device interacted via function call which requires this two modules must be in the same thread. Endpoint is a member of Session object, the interaction between which must be function call. All the messages to the endpoint will pass through the owner session object.

To ensure the Session and Device are in the same thread, a shell object is introduced.

Figure 8-29 shows the basic data organization of Session and Device.

Figure 8-29 Static module organization for Session/DeviceInside the SessionObject, two endpoints are included to handle the protocol related media (payload), generally, the type of endpoint is decided when message is received or being sent, so, both of the incoming and outgoing endpoint have to be dynamic allocated from the EPPool. On the other hand, the SessMT and SessMO should provide the same interface to endpoint so that the behavior in endpoint is consistent. Figure 8-30 shows the object hierarchy.



Date: 2009-5-15


Figure 8-30 Structure of Session Object



Date: 2009-5-15


9. System wide featureNA for Ph1.

9.1. Resilience Redundancy Audit

9.2. Event and Alarm

9.3. CDR and TRLCDR will based on the R5 cdr infrastructure. For each transaction, Session will record the CDR data which is allocated by CdrLib.

9.4. KPI



Date: 2009-5-15


10. ConfigurationThe following tables have to be defined(refer to the FRS to get the detail info),

mapSupportForIpSmGw (MTCorrelationId enable or not)

smscSelectionForIpSmGw

shSupportForIpSmGw

ipsmgw_options

settingForIpSmGw

opRoutingIwForIpSmGw

timersForIpSmGw

AppQueueForIpSmGw

imdnActionForIpSmGw



Date: 2009-5-15


11. FRS Compliance Matrix

11.1. FRS Req # Compliance Status CommentsR-1R-2R-3R-etc.



Date: 2009-5-15


12. Test RecommendationsNA

12.1. Unit Test

12.2. Integration

12.3. System Test



Date: 2009-5-15


13. Open Issues / Review Comments



Date: 2009-5-15


14. Appendix

Date post:	31-Dec-2015
Category:	Documents
Upload:	atulbassi
View:	38 times
Download:	1 times

HLD_244_RMS_v03

Documents