OMA Open Service Environemnt and J2EE Realization

After working few years as J2EE Developer in mobile content provider company specialist in location based services, I had jump to an organization that focusing on core network development or integrations (SS7, IN, MAP, TCAP etc...) using C/C++. I would say there is some big gap in terms of mindset/knowledge/skill when you development mobile application (e.g. televotes, value added SMS) and the core network infrastructure development (SMSC, Virutal HLR for Prefered Roaming etc). This is pretty much like jumping from IT worlds into Telecomms world.

Fews year ago, operators already stared to have content provider arggregation platform like (MSDP in Maxis, CPA in DiGi) which provide the API of performing some SMS, MMS, WAP Push, Charging without understanding the low-level of core-network functionality. At that time, those platform are useful and increase the ARPU of the operator by allowing more content providers to join in the telco world with more valued added services.

With the emerge of 3G, LTE or NGN, telco industry is going to transform from old days TDM E1 to Ethernet based IP (SIGTRAN, SIP based) networks for the upcoming IMS(IP Multimedia Subsystems) or other SDP platform etc. Parlay group and OMA(Open Mobile Alliance) had come out lots of concept, framework to link this two world IT and Telecomms. The Open Service Environment (OSE) that been proposed by OMA are here to further define the framework for Service Delivery irregarless of legacy GSM Network (SS7, PSTN, ISUP,MAP) and the new emerging IMS (SIP, Diameter etc).

The OMA OSE Framework:- (source from Parlay Group Publishcation)

• IO : The interface that expose to Application (3rd Party or Internal) to communicate with the Enabler (Service Capable Server e.g. Call Control, Location Function, Messenging etc.)
• IO+P: Same as IO but with the extra parameter that required for the Policy Enforcer to perform soem execution
• I1: Interface to of the Enbaler to the OnM, Monitoring, Load Balancing Execution Environment
• I2: Interface to the network resources here can be Parlay X, to the Parlay Gateway or propietory implementation using JCA. (Java Connector Architecture)

The J2EE Realization of OSE with Oracle SDP Framework: (Source from Oracle Publication)-

• Enabler Framework can be as simple as a Java Bean of POJO or EJB Container that act as the Service Capable Server with the help of the Network Adapter.
• ESB (Enterprise Service Bus) as a back-bond messenging infrastructure in the Open Service Environment.It enable the communication between the BSS (Execution Environement for monitoring, version control, load balance, availibility status), Enabler component and the policy enforcer here by the SGW (Service Gateway) in Oracle SDP Architecture.
• BPEL(Business Processing Execution Language) ussage also enhance the work flow of the Service Gateway.
• JCA 1.5, SIP Servlet Container will be the network adapter to the SIP protocol for IMS implementation or legacy network protocol liked MAP, CAMEL etc. depending on the propietory implementation to the network resources.
• The Oracle SDP Architecture can be achieve using JBoss J2EE Application Server or Oracle Application Server. With the help of the load balancer to front the 3rd party application (HTTP, SOAP) traffic, scalabiliy of the Open Service Environment / Service Delivery Platform can be achieved.
  

The Enabler Framework to be intergrate into J2EE (Source from Oracle Publication):-

The sample of the Enabler Framework that can be an J2EE Application component or as small as the EJB comprise in the EJB container.

Hope with this post will give an ideal on how the Service Delivery Framework should be designed so that it is fully plugable and the scalability of the feature can be added by additonal Enabler component for different network to achieve a Service Gateway that transparent to the underlaying network no matter is (GSM, 3G IMS, NGN for Fix Line etc). Telecomms world and technology is changing fast, a good designed of platform can promise fast deployment and compete in the challenging and fast changing industry.


Material Source From:-

Alert Service Center of Short Message Service in the view of VLR, SGSN and HLR

Alert-SC or Alert Service Center is one of the flow in Short Message Service Systems under ETSI GSM Specification or later 3GPP. It is used to inform the Service Center (SMSC) of the availability of the handset (Mobile Station) for the readiness of recieving the Mobile Termination (MT) SMS. A particular Mobile Station can be undergoes different state e.g. Idle, Deatch From Network, Busy etc. The Alert-SC feature in return to help the Service Center(es) to deliver/terminate the MT SMS efficiently.

The Mobile Application Part protocol (MAP) operation Alert-SC is triggered from HLR to Service Center Address and there can be more than 1 service centers in a PLMN(Public Land Mobile Network).

Each of the MT termination will need 2 MAP operation which is SRI-SM to obtain the routing information for Short Message which include the current MSC, IMSI, LMSI or SGSN Address that is required. Followed by MO-FSM operation which terminate the SMS content to the targeted MSC/SGSN.

There is few assumption for the Alert-SC process:-

• It is optional for HLR to have the Alert-SC Feature; In case does,'t have the SMSC will need to have retry mechanism.
• MT SMS termination can be done in 2 approach; via MSC and via SGSN using GPRS barrier service.

The Alert Service Center flow will need the cooperation or integration of different network node/element in the 2G GSM network(HLR, VLR(MSC), SGSN(GPRS).

• MNRF flag - Mobile Station Not Reachable Flag (Mandatory for VLR) in VLR is to indicate whether that particular MS can be approached. This flag will be set if the MT SMS can not be terminated by the MSC after the SendRoutingInfoForMT query. MNRF Flag in VLR is also important to determine whether the operation ReadyForSM need to be triggered from VLR to HLR informing the availability of the Mobile Station whether is Memory available or MS present. The same flag will be appear in the Waiting Message Data(WMD) in HLR.

• MNRG flag - Mobile Station not Reachable Flag For GPRS the same purpose as MNRF and it is used for MT-SMS that terminate using GPRS

• MCEF flag - Mobile Station capacity Exceed Flag in HLR which indicate the particular MS is not able to received MT SMS due to the memory capacity full.

• MNRR - Mobile Station Not Reachable Reason in HLR will store the reason for the MS being absent. The reason can be:- No paging response from MSC or SGSN, IMSI detach etc and other AbsentSubscriber Diagnostic information which can refer GSM 09.02 for the MAP operation error code parameter.

MNRF, MNRG in VLR flag will be cleared or set depending on the MSC and SGSN termination of the MT SMS via BSC. While the MNRF, MNRG, MCEF and MNRR and Service Center Address state/flag changed will rely on Service Center's Report-SM-Deliver operation after the MO-FSM Operation to the MSC/SGSN depending on the result of the MO-FSM. Besides, certain MSC will also inform the HLR for the status of MNRF, MNRG, MECF and MNRR ahead of Service Center normal operation.

There is few Alert-SC condition that able to obtain from the ETSI specification:=

• When either the HLR or VLR detects that the MS has recovered operation the HLR will invoke operations to alert the SCs within the MWD Once the Alert SC operations have been invoked, the MNRF and MNRR via the MSC are cleared. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. If the MCEF is set in the HLR, the HLR clears the MNRF and MNRR via the MSC, but does not invoke operations to alert the SCs.

• When the HLR receives a notification that the MS has memory capacity available to receive one or more short messages, the HLR will invoke operations to alert the SCs within the MWD Once the Alert SC operations have been invoked, the MNRF is cleared in the VLR and the MCEF, MNRF and MNRR via the MSC are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD.
  

• When the HLR receives from the SMS-GMSC a notification that a SMS has been successfully delivered from an SC to an MS via the MSC for which the MCEF is set and the MWD are not empty, the HLR will invoke operations to alert other SCs within the MWD Once the Alert SC operations have been invoked, the MCEF, MNRF and MNRR via the MSC are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. The SC which successfully delivered the message is also deleted fromthe MWD, if present.
  

• When the HLR receivesa notification that the MS has memory capacity available to receive SMS but the MCEF is not set and the MWD are empty, the HLR acknowledges the notification but does not alert any service centre.
  

Hope this post will help in understanding the SMSC relation with the MSC, HLR and VLR to deliver a quality Data Messaging Service in GSM Network.

3GPP Specification

I believe lots of people come across this word “3GPP” when searching some telecomms specification or some protocol standard, but seldom of us really look into how the 3GPP specification versioning and numbering. When we see the 1st page of some specification (either for ETSI or etc.), oftenly wording like “3GPP TS 09.02 version 6.15.0 Release 1998″ will be shown.

What is 09.02 ? and what’s the different of Release 1998 and how often 3GPP release the lastest specification?

‘09′ will be the series of 3GPP specifications, while ‘02′ will be the document number under this specification

Series 21- Requirements (Entry level of any new specification)

Series 22 - Service aspects (Stage 1 Specification that define service feature)

Series 23 - Technical realization (Stage 2 specification that define functional blocks)

Series 24 - Signalling Protocol (UE to Network) protocol specification btw. User Equipment and Core Network

Series 25 - Radio aspects (specifications for the radio aspects.)

Series 26 - CODECs (specifications for codecs for speech and video)

Series 27 - Data (specifications for defining functions necessary to support data applications0

Series 28 - Signalling Protocol (stage 3 protocols btw radio subsystem BSS to Edge of Core Network MSC)

Series 29 - Signalling Protocol (stage 3 specification for network elements btw. Core Network, VLR,HLR, MSC etc in UMTS network)

Series 09 - Signalling Protocol (stage 3 specification for network elements btw. Core Network, VLR,HLR, MSC etc in GSM 2G network)

Series 31 - SIM/USIM (Subscriber Identity Module - GSM and Universal Subscvriber Ideniity Module (UMTS)

click here for more series listing in 3GPP official website.

Up till now there are 7 phases which will stated below:-

Released 98 - earlier releases specify pre-3G GSM networks

Released 99 - forezen in March 2000. Introducing WCDMA-based Universal Terrestrial radio Access, LCS (Location Service), CAMEL phase 3

Released 4 - [2001 Q2] Seperation MSC into media gateway and MSC Server to provide bearer indepentent circuit-switched network, Introduction of SIGTRAN in core network, GERAN EDGE and GPRS establish

Released 5 - [2002 Q1] Introduction of IMS (IP Multimedia Subsystem), SIP, HSDPA(High-Speed Downlink Packet Access) to enhance UMTS, CAMEL phase 4

Release 6 - [2004 Q4] Wireless LAN interworking, HSUPA (High-Speed Uplink Packet Access), Multimedia Broadcast, Push services, Digital Right Management, Enhance to LCS,

Release 7 - [2007 Q4] improvements to and real-time applications such as VoIP and focusing on HSPA+

Release 8 - [Progressing] LTE (Long Term Evolution) All-IP Core Network; another new technology to be compete with WiMAX towards 4G networks.

There are 5 Technical Specification Group (TSG) to cover different areas of standardization ofMobile Network Technology (GSM, UMTS etc) ; Core Network(CN), GSM/EDGE Radio Acess Network(GERAN), Radio Access Network (RAN), service and System Aspects (SA) and Terminal.

Core Netowrk (CN) - Responsible for Call Control, Session Management (Packet Data Protocol, PDP), Mobility Management (Roaming) btw. User Equipment and Core Network.

GSM/EDGE Radio Acess Network(GERAN) - 2.5G(GPRS) and 2.75G(EDGE) layer 1, 2 and 3 radio interface

Radio Access Network (RAN) - Defining the functions, requirement and interface of the UTRA(UMTS Terrestrial Radio Access) network

Service and System Aspect (SA) - responsible for overall architecutre and service capabiliities of systems based on 3GPP, coordinates with other TSG.

Terminal TSG - deail with Termianl Equipment (TE) interfaces. UTRAN-based TE, USIM interface with Mobile Terminal.

Hope, by this it will be clearer on how 3GPP govern the exsiting 3G and the legacy technology GSM(2G) and how it help to growth the telecomms industry into a challenging world…… 4G

Welcome…..

After working three years in telecommunications industry as software development engineer, the experiences and the challenging technology had brough up my mind to start up this blog. This blog ‘Telco knowledge with Elbert’ will disucss and share the knowledge in telecomms sector and some IT computing topic.