Command Line Supplementary services: Starting point.

The starting point for implementing IMS supplementary services will be the OIP and OIR services. These are the most basic supplementary services in the legacy world, widely understood and used.

After OIP/OIR, I will implement the TIP and TIR supplementary services.

Supplementary services will later on be integrated with the Personal Network Management application.

The 3GPP specs that are of interest for this implementation are:

1. 3GPP TS 24.173

2. 3GPP TS 24.607

3. 3GPP TS 24.608

For any queries, feel free to leave comments to this post.

Thanks.

Value proposition for PNM-enabled services:

A fews days ago, I had posted a unified architecture of the whitelassi PNM application server, fully integrated with IMS supplementary services and IMS service enablers such as the XDM server. 

The diagram showed the potential of user/device  management services such as that of PNM (Personal Network Management). It also gives insight and the value proposition that PNM can enrich and add value to IMS call control services. 

The entire architecture can be seen here:  PNM-IMS-SERVICE-INTEGRATION

This architecture shows, that a device management framework such as PNM can be leveraged upon to act as a valuable utility for other services as well, especially those services that rely on user preferences and privacy. Some of the services that are shown on the page are listed below. Let us talk about them briefly and discuss the possibilities that they present to us:

1. Wake up Call Reminder service, which the user can configure over SIP or from the GUI.

This service would enable the user to set a wake up call time on the GUI of the PNM server. The PNM application, will read the user’s input from the GUI, and schedule a timer to wake him/her up. This service can also be re-used as a reminder service. Hence, the PNM component here enables the user to manage his preferences and avail of a value added service in the form of Wake up service. The user who owns multiple devices, can also schedule a wake up call on multiple devices if he wishes so ! 

2. Communication on Hold ( or Call hold) supplementary service.

This is a famous and widely used service in the telecom world. The user can set preferences that whenever an active IMS session is put on hold, a special ringtone is played on the line. These preferences can be set on the GUI and stored as a XML file in the XDM server.

3. Incoming and Outgoing communication barring based on user preferences.

The user can specify preferences on blocking certain numbers (prank callers) on the GUI. Moreover, the PNM controller (master device) can also present restrictions on other devices (PNM controlees), such as those pertaining to parental control. 

4. Originating Identity Presentation and Restriction supplementary service.

This is a popular legacy supplementary service that has been carried forward in the SIP and IMS world. 

5. Terminating Identity Presentation and Restriction supplementary service.

Same as point 4 above, the only differnence being that this service is invoked for the terminating side of the call.

6. Call Blocking Service (Unconditional and partial)

This is a special variant of communication barring. Similarities can be invstigated further.

7. Intelligent Caller preferences that can be set on SIP or from the GUI.

From the GUI, the user can set multiple preferences, such as those for messaging, call control etc. SIP allows the user to set a variety of preferences to provide a customized experience to the user.

8. Subscriber privacy management based on the rules set on the GUI

The user can set privacy filters on the PNM server, that are enforced during call control. This is an essential enabler for call control supplementary services. 

9. Call Screening service (MCID: Malicious Caller Identification)

This service is a variant of lawful intercept. However, it does not intercept the bearer, but only records the call trace and signaling information, that can later be used for security purposes by the operator.

10. Closed User Group Service (CuG), which will drive the Call Forwarding Services, and other group services.

The user can define a closed user group (buddy list) here. This is in addition to the personal network of devices that the user may own. Special services and tariffs can be applied to calls within a CuG.

11. Call Forwarding Service (which has the following variants):

11 a) Call Forwarding Unconditional (CFU)

11 b) Call Forwarding Busy (CFB)

11 c) Call Forwarding No Reply (CFNR)

11 d) Call Forwarding Not Logged in (CFNL)

11 e) Call Forwarding No Reply Conditional (CFNRc)

11 f) Communication Deflection (CD) 

This is yet another popular supplementary service: both in the legacy world and the IMS world. 

12. Message Waiting Indication service can be coupled with the core PNM logic. 

MWI can be extended to all kinds of messages: SMS, IM, MMS and Voicemail. The user can get a reminder or alert that messages are waiting for him to be read/heard ! 

13. Communication Diversion (CDIV)

Communication sessions can be diverted based on user preferences on the GUI. 

14. Explicit Call Transfer (ECT)

This is a variant of third party call control. It enables consultative and immediate transfer of ongoing SIP sessions. The call transfer can be facilitated by the PNM communications server. 

 

So, this is the end game for the PNM server and the actual goal of this open source project:

“To provide value to the users, not by doing something very complicated or great, but by doing the simple things competently. “

By providing the user with simple utilities, everyday services can be enriched and made more user friendly. This is how we can add value to the user-experience for the customer. By clubbing existing services, we can create new ones, while still adding value to existing services. 

I invite suggestions/feedback/additions regarding this post and the project in general. Contributions in any form or shape are welcome !! 

Best Regards

Aayush

Stage-3 Service description.

Hello, 

We will discuss the Stage-3 service description of the PNM Server in this post. I understand that the Stages 1 and 2 are read and understood. 

They can be found here:

Stage-1 Service Description

Stage-2 Service Description 

 

It will be helpful if the above two posts are referred in concurrence with this post. It will give a more holistic view of the implementation challenge in front of us. 

The Stage-3 service description will be divided into the following parts: 

===========================================

AGENDA:

A) Procedures to be implemented as per 3GPP specifications

B) XML Handling procedures

C) Graphical User Interface requirements and integration

D) Forward Path

===========================================

A) Procedures to be implemented as per 3GPP specifications

To put things in perspective, the PNM application server will be acting as a User Agent Server (UAS) in the sense of RFC 3261 and as a third-party registrar. It will also need to initiate SUBSCRIBE requests (UAC) and proxy INVITE requests (proxy server). Procedures of RFC 3261 for these behaviors apply. In addition, the major procedures to be handled by the PNM server are as follows:

1.  Accept the REGISTER request from the IMS core network

2.  Perform certain checks as per 3GPP TS 24.229 Section 5.7.1, Page 148 

3.  Schedule a timer for the duration indicated by the REGISTER request

4.  Send back a success response to the REGISTER (only if the checks pass)

5.  Initiate a SUBSCRIBE request for the ‘reg’ event package

6.  Once the subscription is established, schedule a timer for the subscription duration.

7.  Expect SIP NOTIFY requests for the duration of the subscription. 

8.  If a REGISTER with expires=0 is received, cancel the REGISTER timer and also send a SUBSCRIBE with expires = 0 and release the subscription timer. 

9.  Perform SIP session redirection depending upon the XML policy document stored in the XDM server by the mobile device. This XML document can be seen in 3GPP TS 24.259. All specs can be downloaded from here:  WHITELASSI FILES SECTION

10. Point 9 above is subject to defining a new XCAP application usage as given in TS 24.259, in the XDM Server. This is a pending issue and can be viewed here: WHITELASSI ISSUES SECTION

11. Apart from the procedures on SIP, there are procedures that have to be implemented as part of another SBB, which will use the XCAP client resource adaptor and the HTTP servlet Resource adaptor. This SBB will be used to interact with the XDM (XML Document Manager) server for checking the policy document stored as XML and then invoking the relevant procedures on SIP. Details on XCAP protocol are given in RFC 4825. The exact configuration procedures on XCAP are given in 3GPP TS 22.259, 23.259 and 24.259, all of which are downloadable from the WHITELASSI FILES section. 

12. Details on what the XDM Server is and how it works are given in the form of a specification in the  WHITELASSI FILES section. The document name is OMA-TS-XDM_Core-V2_0-20080916-c.pdf

13. Implement the procedures for a UAC, UAS and proxy servers as per RFC 3261 (keeping them in mind). 

The basic call flow is given as below:

—————————————————-

B) XML Handling procedures:

—————————————————-

The very first requirement is to define a new application usage for the XDM server. The XDM server acts as a central XML metadata repository for the PNM Server. The XDM server stores a XML document for each user, which specifies the preferences of the user. During SIP call control, this XML document may be consulted to decide the routing of the call. 

For the XDM server to correctly understand and store such per user XML data, an XML application usage has to be added to the XDM server. The procedure for adding an application usage to the XDM server is given here: XDMS application usage addition

Once this application usage is completed, we will need to create a SBB named CallControlSbb. This SBB will take care of the SIP INVITE call control flows and will need to make the InternalXDMClientControlSbb as the child sbb. This child sbb is present in the XDM code. 

This CallcontrolSbb will create a child Sbb, which will perform XML lookups during the call to decide the further routing of the call. When we get to implementing the CallControlSbb, i will discuss it in more detail.

————————————————————

C) Graphical User Interface requirements and integration

—————————————————–

The major GUI requirements are outlined here in this thread: GUI Requirements for PNM

The graphical user interface for the PNM server will act as a XCAP client in the context of RFC 4825. The user will log into the GUI, specify his preferences and save them. Upon saving, the GUI application bean class will marshal an XML document as per the XML schema defined in the PNM specifications using the JAXB APIs and create a unique XML document for this user. Then the GUI will insert this document in the XDM server. This will be the PNM user provisioning process flow.

Hence the GUI acts as a XCAP client. The interface between the GUI application and the XDM server is XCAP/HTTP. XCAP is not a seperate protocol in itself, but only rides over HTTP. However, it has its own terminology as explained in RFC 4825. XCAP enables us to create a document tree for the users of PNM server. Each document will be created during the provisioning once, as explained above. 

The call controller SBB defined in point B above, will also act as a XCAP client, with the help of InternalXDMClientControlSbb, and will query this document in the XDM server to take routing decisions. Hence from the perspective of the XDM server, there are 2 actors: the GUI applications and the CallControllerSbb, as shown below:

—————————————–

D) FORWARD PATH:

—————————————–

1. Some of the procedures mentioned above are already under works. You can browse the code here: WHITELASSI TRUNK CODE

2. Moreover, it is recommended, that the links given in this post are studied and the documents downloaded from the FILES section. 

3. I would be needing help in implementing the CallControllerSbb and integrate it with the Child Sbb. 

4. Adding a new XCAP application usage to the XDM Server

5. Start working on the GUI application using JSF/RichFaces technologies and prepare a GUI specification document.

 

If there are any doubts, leave me a message here.

Regards

Aayush

Project structure and source up in the SVN

Hello, 

The first skeleton of the PNM Server source code has been committed in the Googlecode repository. Now in the coming days, I will be posting the Stage-3 service description, so that members can map the domain knowledge directly with the Source code that has been shared in the SVN

To browse the source code, please visit: 

http://code.google.com/p/whitelassi/source/browse/#svn/trunk/whitelassi-PNM-server

I have preserved the entire project structure of a JSLEE project, so that even if you dont have an eclipse plugin installed for JSLEE, you can import the project in eclipse and try it out. However, i recommed that everyone installs the Eclipse plugin. The link can be found in the BLOGROLL on the right side bar of this blog. 

For details about the code that has been committed, please refer to this thread: 

http://groups.google.com/group/whitelassi/t/ed333a932f3bc287

I invite all members to volunteer to help me out in the coding effort that lies ahead. Any help is appreciated.

Thanks 

Aayush