Aayush: weblog

Archive for the ‘3GPP TS 24.229’ Category

Recommended Inclusions in VoLTE IR.92/94 and the IMS standards to achieve GSM-like ubiquity

Posted by Aayush Bhatnagar on December 13, 2014


The industry has seen and tracked how the VoLTE standards have been evolving over time.

GSMA IR.92 – IMS Profile for Voice and SMS, has undergone several revisions. On the same lines IR.94 has been published for video calling.

However, if we compare mobile telephony available today – with the IMS and VoLTE standards – some key gaps remain in the IR.92 guidelines, which in my opinion should be included in the GSMA standards to maintain backwards compatibility for VoLTE deployments.

All open market VoLTE device networks, and IMS vendors follow IR.92 and IR.94 as the golden standard for their implementation, and hence this alignment is important.

Some of the key features, which are “candidates” for inclusion are mentioned below. Some of these have 3GPP references, while others exist in some form or the other in exiting 2G/3G networks which are live today.

In the absence of “golden” guidelines for these issues, getting a GSM-equivalent ubiquitous and mature standards based implementation for VoLTE becomes a challenge –

1. Support for USSD over IMS should be endorsed by IR.92

The USSD standards for IMS have finally been frozen and are available in 3GPP TS 24.390 since Release-11, which happened in Q3 2012.

In some countries, USSD is a central medium to enable Value added Services – which actually contribute to whatever is left in Voice and SMS revenues for the operator.

USSD is also a good medium to integrate customer self care applications directly with back-end content based application servers – for example, we may want the customer to preview and choose a ring back tone through an android application.

On Android OS, it is trivial to dial out a USSD request from an application by using the following lines of code:

String hashString = Uri.encode(“#”);
String shortCode = “*” + hashString + “131” +hashString;
startActivityForResult(new Intent(“android.intent.action.CALL”, Uri.parse(“tel:” + ussd)), 1);

Similarly, incoming USSD responses can be intercepted easily.

However, in order to enable this functionality on a large scale on VoLTE handsets – IR.92 has to endorse the 3GPP specification and provide clear guidelines for implementation at the device side as well as at the network side.

2. Over the Air Function (OTAF) – messages tunneled via SMS and USSD.

OTAF is required for remote provisioning of SIM card information. The secure packet structure of communicating these configurations is defined by 3GPP in TS 31.115.

IR.92 should endorse this specification and include the related call flows in the VoLTE implementation guidelines specification.

The OTAF function has an important role to play in the OSS activation processes, when the customer inserts the SIM card in the handset.

Most OTAF servers connect to the IMS network (IPSMGW) as an ESME function over SMPP. Alternatively, they connect to a USSD gateway if the USSD termination option has to be exercised.

3. Complete SMS over IMS call flows (Ref: 3GPP, IR.92 and GSMA Implementation Guidelines)

The GSMA implementation guidelines as well as the 3GPP specifications do not provide end to end and complete call flows for SMS over IMS, covering all the scenarios.

Only  part call flows are explained where there is no clarity on whether the call flow is depicting IMS to IMS SMS termination or whether one of the SMS legs is from the legacy network (circuit switched).

Moreover, important call flows pertaining to international breakout of SMS messages, SMS initiation/termination when the customer is roaming in UTRAN and GERAN networks are missing.

Clarity on the interconnection of the IPSMGW with ESMEs over SMPP are not mentioned in TS 24.341, and are side-stepped in both IR.92 and the GSMA VoLTE implementation guidelines. As a result, all ESME related services which ride on SMPP are missing in the context of VoLTE.

These details should be clarified and detailed out in subsequent releases of the standards hopefully with clear call flows.

In the interim, vendors are forced to fall back to extrapolating existing 2G architectural details for SMS provided by earlier releases in 3GPP.

4. Support for STAR Code based dialing and detailed guidelines

Star code dialing has been available since GSM. Star codes can be used for activation and de-activation of supplementary services.

The MMTEL standards described in TS 24.173 and its downstream standards for IMS and VoLTE do not standardize or provide any guidelines on the usage of star codes.

This is very important from the perspective of  VoLTE devices vendors as well.

The device vendor has to decide which call flow to invoke based on the user input from the screen (whether to send an INVITE with the star code, or whether to send a standard XCAP request to an Aggregation Proxy server via HTTP)

Star code dialing can also be used for vertical services such as televoting and for other purposes.

This gap needs to be addressed in 3GPP and then ideally endorsed by IR.92. Alternatively, IR.92 can publish guidelines based on the SIP-AS models provided in TS 23.218 and allow device vendors to use star code dialing in VoLTE handsets as a configurable option controlled by OMA-DM.

5. Introducing (IN-like) and Interconnecting with (Existing IN) Toll free services for VoLTE/IMS

The 3GPP IMS architecture defines the IM-SSF (IP Multimedia Service Switching Function), as an entity which interconnects existing 2G/3G IN services with the IMS core network. TS 23.218 defines the IM-SSF formally in the standards.

Some of these services include – Televoting, 1800 toll free calling services, calling card services (for subsidized international calling for example), premium rate services (ITU-T E.155) and others.

For operators with existing 2G and 3G circuit switched core networks, it is possible to use the IM-SSF for bringing these IN services to the IMS architecture and then finally deliver them to VoLTE customers.

However, if there is a greenfield deployment of VoLTE, or a complete migration to LTE is required with no dependency on the IN platform, then this functionality of the IN architecture has to be standardized as part of IMS, and endorsed by IR.92.

3GPP may either directly standardize these applications – like they did for CRS and CAT (Customized alerting tones – also known as CRBT in India) – or 3GPP may work with OMA to define these service enablers formally and then endorse these standards.

In the absence of either of these, IR.92 can directly endorse TS 23.218 IM-SSF architecture for incumbent deployments, and the existing ITU-T recommendations for the benefit of greenfield operators, so that vendors can align to a least common denominator.

At the moment, this service agility is missing from the standards and the SIP Application server models have been defined and the rest is left to vendor innovation (please read this as vendor lock-in).

6. SMS Gateway and peering functionality (think of ESMEs)

Standards define E(SMEs) and their interconnection with SMSCs as part of the SMPP v3.4 and v5 specifications for GSM and UMTS.

However, as we move forward to IMS and VoLTE, the IPSMGW standards do not define any such entity, nor endorse the existing standards of SMPP.

Due to this gap, most of the SMS VAS services, SMS hubbing and SMS gateway services remain un-addressed. Vendors and operators have no choice but to fallback to legacy architectural choices or to support SMPP in the IPSGMW network element.

In markets such as India, SMS VAS services are a major cash cow despite OTTs, and these SMS messages are charged at a premium rate.

The SMPP interface should be included and the ESME functionality should be formally defined in TS 24.341 so that vendor implementations and VoLTE deployments are aligned.

7. Inclusion of MSRP and HTTP(S) for multimedia messaging in VoLTE IR.92/IR.94

It is a well known fact that MSRP and HTTP(S) based file transfer is addressed by GSMA in the RCSe specifications. However, it is required that these are also inlcluded in the scope of VoLTE.

Current MMS messages (even though MMS is dead), rides upon HTTP for file transfer.

With the advent of high speed LTE networks and VoLTE, HTTP and MSRP based file transfer can fuel many applications such as multimedia advertising applications, native support for multimedia messaging in VoLTE handsets (outside RCSe) – to give an integrated multimedia chat and SMS experience on a high speed data network.

Moreover, MSRP can also help in purchasing content from operator-owned content stores or streaming unicast content on-demand.

It is quite surprising that the MMS architecture has been left behind in the IMS standards and IR.92, as it can deliver a lot of value in the current context through innovative content based services.

8. Golden IMS configurations for VoLTE devices

At many occasions, there are configurations required in the VoLTE device which are in addition to the bare minimum list of parameters defined by 3GPP in the IMS Management Object specification.

Some typical examples include the following:

a. RTP keepalive timer values

b. RTCP policies

c. Impact of radio conditions on IMS registration

d. Guidelines for camping priorities between GERAN, UTRAN and E-UTRAN

e. Endorsement of SIP timers given in TS 24.229

f. UE registration re-try behavior endorsement as given in Section-5 of TS 24.229

g. UE star code dialing behavior and resolving conflict of triggering XCAP requests vis-a-vis SIP INVITE requests for dialed star codes by the user

The absence of these details cause implementation and interoperability complexities.

Hence, it is desirable if IR.92 provides an annexure detailing out UE guidelines and golden configuration options which can be followed across VoLTE UE implementations.


In conclusion, there needs to be a mechanism to include practical implementation pain-points and ensure backwards compatibility in the current IR.92 standards.

All the points listed above are widely deployed in current GERAN and UTRAN implementations with the circuit switched core network.

In the long run as more and more VoLTE devices come in the open market, and IMS deployments expand – these inclusions will help move towards attaining a GSM-like ubiquity for VoLTE.

Please feel free to add to this list or suggest more details/feedback.

Posted in 3gpp, 3GPP TS 24.229, 4G, DIAMETER, DIAMETER charging, IMS, IMS data, IMS procedures, IMS Release 11, IMS UE, ipsmgw, IR.92, IR.94, LTE, MMTEL, MSRP, network elements, RCS, supplementary services, telecom, USSD, USSI, VoLTE | Tagged: , , , , , , , , , , , , , , , , , , , , | 3 Comments »

Policy Control and QoS Awareness for IMS and LTE – An evolving trend.

Posted by Aayush Bhatnagar on February 16, 2011

With the advent of LTE and IMS, policy awareness has become an important trend. Rising data rates in the operator’s network have led to a situation where the network carrier is fast becoming the infamous “dumb pipe”.

To avoid this situation, or to atleast improve upon this condition – it is necessary for the operator to introduce various avenues of network intelligence.

Network intelligence can manifest itself in the form of granular policy control, smart policy enforcement and QoS awareness.

3G HSPA defines 4 levels of QoS, Mobile WiMAX defines 5, while LTE defines 9 QoS levels as part of the standard. This provides ample opportunity to the operator to create a business case around Policy and QoS awareness and present a value add to the customer in the form of innovative plans.

Recent standardization trends have shown that there is greater cohesion between policy awareness and the way we charge the customer. Hence, this points to the fact that policy awareness is fast becoming an avenue of monetization for the operator.

In order for the operator to deliver policy awareness in an end to end manner, the following aspects need to be implemented:

1. The network facet of policy awareness:

The Policy and Charging Rules (PCRF) Function and the Policy and Charging Enforcement Function (PCEF) need to be present in the network. In the LTE infrastructure, the PCRF is a dedicated network element, while the PCEF is embedded in the PDN Gateway of the EPC core network.  These two nodes ensure that policy rules can be defined, controlled and enforced in all sessions. In addition to these nodes, we also have a Subscriber Profile Repository(SPR) which acts as a central database for Policy rule provisioning, management, updation and deletion alike. In addition to these nodes, the 3GPP Policy and Charging Control architecture (PCC) defines the OCS (Online Charging System) as an additional element of this logical grouping.

2. The Business facet of policy awareness:

The business facet of policy awareness is best implemented in the OSS and BSS stack. The operator has granular knowledge of customer behavior, his applications, data consumption practices and take-rate of new applications amongst the customer base. This knowledge can be leveraged upon to provide the customer with new plans and offers based on policy control and QoS. A recent report released in November 2010 and conducted by YouGov states that consumers are willing to pay for better QoS for mobile video services. Continuing with the business facet, it is interesting to note that Policy awareness is also a key enabler for loyalty management programs. With personlalized knowledge about the customer, the operator can launch special offers for high ARPU customers to improve “stickyness”.

3. Personalization of Customer QoE (Quality of Experience):

Policy control also provides a unique opportunity for personalization. Policy rules can be exposed to the customer using a Self care portal or a smartphone application. The customer can himself configure policy rules and personalize their experience. All this would eventually lead to greater customer satisfaction.

Some examples of policy awareness and QoS control with charging are as follows (non-exhaustive) —

— Bandwidth Boost for a specific period of time or a given session on a discounted rate.

— Policy control based on customer location and a special rating plan to be applied for that location (home zone).

— Policy and QoS control based on the time of the day and 10% rating discount for that time slab.

— Policy and QoS control based on the nature of content (video, audio, uploads etc) leading to differentiating LTE QCI levels.

— Policy and QoS control arising from loyalty management schemes (which may be based on ARPU).

— Confluence of parental controls on content consumption and policy/QoS.

The possibilities are infinite and there is no end to the practical use cases around policy control and charging.

However, there needs to be an interface between the PCRF and billing as well, to include post-paid services under the gamut of the policy based monetization story.

Some examples of use cases on the PCRF – Postpaid interface:

— ARPU based policy upgrades

— Unbilled amount thresholds leading to policy governed rewards and promotions

— Customers getting policy “voucher” numbers on their bill as a loyalty scheme which offers a free QoS upgrade

— Bandwidth boost for customers paying their bill on time etc.

— Policy control and QoS for enterprise services (which are predominantly postpaid).

Which are the most common and widespread applications of policy control experienced by you ? Please feel free to share your thoughts.

Posted in 3GPP TS 24.229, billing, BSS, DIAMETER, IMS, IMS data, post-paid, pre-paid, Services, user data | 1 Comment »

IPTV service delivery architecture over IMS and possible applications.

Posted by Aayush Bhatnagar on October 18, 2010

A. Introduction:

For long, it has been envisioned that IPTV services can be delivered over the IMS core network.

TISPAN has done a good job in trying to standardize an architecture for this purpose. With IMS gaining traction globally, it is a good time to review the architecture for IPTV service delivery.

This post describes the architecture for delivering IPTV services over an IMS network. Traditional IPTV services include the following offerings:

1. Video on Demand – VoD

2. Broadcast Television-BCAST

3. Network Personal Video Recording – nPVR

To successfully provide IPTV services, we need an architecture to deliver these three basic services. On top of these services, we can use IMS service enablers to enrich the user experience such as Presence and Instant Messaging (IM).

Moreover, with IPTV over the IMS core we have an opportunity for providing video-interactive services for the first time.

As expected, any application server providing IPTV services will reside on the IMS services layer. This means that this application server will need to support the ISC reference point. (IMS Services Control).

As per the TISPAN architecture, we have the following major servers:

1. Service Discovery Function (SDF).

2. Service Selection Function (SSF).

3. Service Control Function (SCF).

4. Media Control Function (MCF).

5. Media Delivery Function (MDF).

6. User Profile Server Function (UPSF).

7. XML Document Management Server (XDMS).

In addition to these TISPAN entities we also have the following network entities which are required for an end to end deployment:

1. Streaming Servers for TV channels.

2. Head Ends for VoD.

3. AD Injection Servers

4. Content Management System (CMS).

5. Operation Support Subsystem (OSS)

6. Business Support Subsystem (BSS).


B. TISPAN Network Elements:

The network architecture for IPTV service delivery looks like the one shown below:

The Service Discovery Function provides attachment information to the UE and also the addresses of the Service Selection Functions. The SDF functions in two modes:

1. Push Mode, wherein the SDF receives the 3rd party REGISTER request from the S-CSCF and sends a MESSAGE request with the XML payload containing the attachment information.

2. Pull Mode, wherein the UE subscribes to the “ua-profile” event package and the service attachment information is sent in the XML payload of the NOTIFY request.

Based on the attachment information received from the SDF, the UE contacts the Service Selection Function (SSF). The SSF provides the UE with a list of services available. This can be done by providing the UE with the electronic program guide (EPG).

The Service Control Function is divided into three logical sub-functions – one for Broadcast television, another for content on demand and the third for personal video recording.

The SCF is responsible for IMS session control and acts as a SIP-AS. The SCF also generates charging information on DIAMETER protocol for charging these sessions. The SCF refers to the IPTV UE profile stored in the UPSF or in the XDMS for delivering video services.

The Media Control and Delivery functions act as a split architecture similar to the IMS MRFC-P. The MCF is the control plane entity while the MDF is the data plane entity responsible for streaming video. However, in practical deployments, there are dedicated streaming servers available and Head-ends for delivering IPTV content.

In addition to content, there are dedicated servers to inject advertisements in the video streams.

The UPSF is the Tispan counterpart of the HSS. It stores use profile data. The SCF and the SSF can both store the IPTV user profile in the UPSF over the Sh interface.

However, apart from the UPSF there is another storage alternative in the form of XDMS. The XDM operates over the XCAP/HTTP protocol. The XDMS needs to support the “org.etsi.ngn.iptv” application usage for this purpose.

The choice of user profile between the HSS and the XDMS is implementation dependent.

C. The Role of OSS and BSS:

Traditional IPTV middleware solutions consisted of an OSS/BSS along with the functionality defined above. After standardization directions in the OSS/BSS space, and with the advent of the NGOSS architecture, there is a technology neutral approach in the OSS/BSS space. Irrespective of the line of business – IPTV, voice or video, the OSS/BSS remains common.

Hence, legacy IPTV middleware has been broken into two components:

— The realtime components have been standardized by Tispan as described in the previous section.

— The non-realtime components such as OSS/BSS have merged with the NGOSS architecture.

OSS is required for inventory management of the STBs, provisioning of users, provisioning of IPTV services and content, service activation/deactivation and service assurance/SLA management. The Content for IPTV is stored in dedicated Content Management Systems (CMS). However, the content is provisioned from the OSS infrastructure.

BSS is required to carry out traditional billing, rating, mediation and charging responsibilities for the service provider. BSS is also used for partner management for 3rd party IPTV content, executing settlements with content partners as well as generating business intelligence reports.

D. Possible IPTV Applications using IMS:

1. Interactive voice/video: With IMS integration, it will be made possible for integrating voice/video capabilities in IMS. For example, Celebrities can be interviewed by the media without actually needing to travel with the crew to their residence. Using IPTV, the TV studio can directly initiate a video communication with the celebrity and take their interview which can then be broadcast to millions of fans.

2. Messaging: Instant Messaging over IMS can be used as another important application for IPTV…especially amongst teenagers. Instant Messaging can also be used as an avenue for televoting in LIVE programs on TV.

3. Nomadic IPTV: As IMS is access independent, the IPTV program guide can be made nomadic. The user can access their favorite TV programs even when they are on the move and when they are roaming.

4. Video Conference: This can be a very useful application for corporates/educational institutions engaged in distance learning and training. Students can join into an educational broadcast channel or a group discussion from their homes using their IPTV set top box.

5. Video/Photo Share with Web 2.0: Users can record and upload videos from their IPTV set top boxes directly to web based applications such as YouTube. Similarly, set top boxes can also be used for uploading photos to popular services such as Flickr.

6. Security Services: Set top boxes with cameras can be used as home surveillance equipment. A series of cameras can be connected to the STB over WiFi that cover the entire house and its compounds. These live video streams can be sent from the Set top box to the user’s mobile handset.

These applications can be made possible only with IMS integration. IMS helps in bringing voice/video and messaging services to IPTV in a standardized and seamless manner.

It will not be wrong to say that “video” is the next killer application and a replacement for voice !

It will be interesting to invite feedback from visitors/regular readers of this blog on their thoughts on the Tispan IPTV over IMS architecture.

Some questions that beg to be answered are:

— What are the hurdles for its widespread adoption?

— How important is the acceptance of 3GPP MBMS in the adoption of IPTV over IMS ?

— Will IPTV over IMS be a success only with LTE Advanced (where multicast is supported) ?

— What about the devices ?

— Will NGOSS act as an enabler for a smooth rollout of IPTV services? (No need for proprietary IPTV middleware).

Your feedback is appreciated and invited.

Posted in 3gpp, 3GPP TS 24.229, IMS, SDF, Services, SIP, SSF, telecom, TISPAN, UPSF | Tagged: , | 4 Comments »

3GPP IMS Release-9 Highlights and Changes.

Posted by Aayush Bhatnagar on October 13, 2009

3GPP IMS Release- 9 has been around for some months now.

From the IMS core network perspective, there have been certain additions and modifications to the procedures given in TS 24.229.

This specification acts as the ‘bible’ for any vendor wishing to implement IMS. This specification also changes and updates itself very frequently and usually comes with scores of additions and modifications in its quarterly minor releases.

Some of the major highlights of Release 9 are discussed.

The current release at the time of this post is 9.1.0 which is being discussed here.

As these changes are very low-level and implementation specific, it seems that there is still heavy refactoring going on in 3GPP for aligning the procedures for IMS and coming out with a stable set of procedures (atleast for the core network entities).

Such changes can be very difficult to spot and implement from the developer’s perspective.  Some changes given below can even force you to modify some of your use cases. Personally speaking, it becomes very frustrating when the procedures change so frequently. Atleast, there should be no changes/bugs in the core procedures of the IMS nodes.

IMPORTANT NOTE: Read on at your own risk. Not for the weak at heart.

Highlights, Changes and Additions:

1. Clarification in UE procedures for sending requests on protected ports to the P-CSCF regarding subsequent registration requests.

2. Addition and clarification in UE procedures regarding the usage of the ‘outboud’ parameter in the Supported header. It also includes a check whether the ‘reg-id’ and “+sip.instance” Contact header field parameters are present in the 200 OK of the REGISTER request.

3. Elaboration on the decision making of the UE regarding the S-CSCF behavior,  if the ‘outbound’ parameter was not present in the 200 ok for the REGISTER.

4. A note providing an implementation option to the UE in case Timer F expires at the SIP Stack.

5.  Change of procedures on the number of REGISTRATION attempts by the UE and in case of failure, the procedures that follow it (exception handling).

6. Removal of procedures at the UE that needed a check for Retry-After header for re-attempts for Registration.

7. Removal of procedures at the UE (2 postulates) when it sends a SUBSCRIBE to the network.

8. Removal of a check at the UE for sending a SUBSCRIBE for the debug event package.

9.  Addition of a postulate for generic procedures except the REGISTER request handling where now the protected port has to be added by the UE in the Contact header.

10. Refactoring of the abnormal exception handling use cases at the UE when it receives 504 error response.

11. Refactoring of procedures for emergency call handling at the UE and parsing responsibilities of the 3GPP IMS XML file received from the network

12. Additional responsibility at the UE to advertize support for draft-ietf-sipcore-keep for emergency IMS sessions.

13. Major refactoring on pages 92 and 94 regarding the interpretation of certain XML elements for emergency sessions initiated by the UE when it was registered using non-emergency registration procedures.

14.  Clarification note in P-CSCF procedures regarding protected ports in section

15.  P-CSCF procedural support for draft-ietf-sip-outbound, and addition of the ‘ob’ parameter in the SIP URI.

16. P-CSCF procedural support for draft-ietf-sipcore-keep

17. Clarification on point 6 for P-CSCF registration procedures when the request needs to be sent to an I-BCF

18. Change in point 7 of P-CSCF registration procedures in case the request has to be sent to the I-CSCF

19. Clarifications in points 8 and 9 of P-CSCF registration procedures while dealing with a UE behind a NAT and alignment with draft-ietf-sipcode-keepalive.

20. P-CSCF can now not close the TCP connection with the UE in case it has been detected to be behind a NAT !

21. P-CSCF can add the “received” parameter and the “rport” parameter in case SIP Digest without TLS is being used as the security mechanism with that UE.

22. Additional check at the P-CSCF in case SIP Digest WITH TLS is being used, that the FQDN in the Contact header resolves correctly to the IP Address bound to that TLS session. Here the P-CSCF will perform a reverse DNS query !

23. P-CSCF has to check whether there is an I-BCF in the network while sending out SUBSCRIBES to reg event packages. If there is no I-BCF, do a DNS lookup and send it to the I-CSCF, else send it to the I-BCF.

24. Major refactoring of procedures for the P-CSCF for general request handling in Section

25. Inspection of the host portion of the sent-by field of the Via header received from the UE at the P-CSCF. Check whether the IP address given there differs from the source IP from where the packet was originally received. Also add the UEs protected server port over there.

26. P-CSCF abnormal cases postulate (a) asks it to add some elements of the 3GPP IM CN subsystem XML body while sending an error response.

27. P-CSCF procedures, initial request for a dialog handling procedures, Section, postulate 5C, remove any P-Preferred-Identity headers if present.

28. Clarification in postulate 6 of section

29. P-CSCF procedures, section, postulate 2A now asks to remove P-Preffered-Identity header if present

30. Clarifications for postulate 3 of section

31.  P-CSCF procedures for generic response handling now require the inspection of the rport and received parameters before sending out any responses to the UE.

32.  In section, P-CSCF now has to remove any P-Preferred-Identity header if present. This is an extra check now.

33. Postulate 3, section, P-CSCF needs to remove the “comp” SIP URI parameter from the Record-Route header.

34.  P-CSCF needs to remove the P-Preferred-Identity field in section postulate 1A.

35. Clarification that the P-CSCF needs to support draft-ietf-sip-outbound in addition to 3261 for section while deciding upon the forwarding the request to the UE.

36.  Major refactoring additions of the procedures for the P-CSCF in section postulate 1A. Some 3-4 checks have been added.

37. Refactoring of point 3 of section Point 3 has been changed to align towards draft-ietf-sipcore-keep. So this postulate needs to be re-implemented.

38. Inspection and addition of the 3GPP IMS XML schema elements in section, postulate OA, points II and IV.

39.  Major major refactoring, removal and additions in the procedures of the P-CSCF in points 1, 1A, 2 and 3 of section Almost everything has been modified here ! Reimplementation required.

40.  P-CSCF abnormal exception handling procedures aligned to the processing of the 3GPP IMS XML body.

41. S-CSCF procedures for initial registration have to inspect the P-Access-Network-Info header to decide the authentication scheme to use for the UE.

42. S-CSCF procedures for receiving an unprotected register request additions to handle the REGISTER from an MSC enhanced ICS node.

43. S-CSCF derivation of IMPI for NASS IMS bundled authentication in case  the Authorization header is missing.

44. S-CSCF inspection of the “reg-id” parameter, the “ob” parameter and the “outbound” parameter in case of IMS AKA authentication, and sending of a 439 response.

45. S-CSCF procedures section, point 11 has almost been scrapped and the earlier checks removed.

46.  Digest URI need not match the SIP URI in case a reg-await-auth timer is running and SIP Digest is the mechanism used at the S-CSCF for authentication.

47. Inspection of the Authorization header to contain the “auth-done” parameter at the S-CSCF.

48. Clarification for the <ims-3gpp> element in 3rd party registration procedures.

49. Check for P-Served-User header in S-CSCF procedures section and associated procedures if its not present.

50. Addition of the P-Asserted-Identity header in the 504 response at the S-CSCF and the <ims-3gpp> element as well in the body.

51. Section, points 10 a and 10d of S-CSCF procedures have undergone major additions and refactoring. Re-implement it.

52. Removal of authentication parameter checks in point 3 section of the S-CSCF procedures.

I hope you all enjoyed this list. What it does to the developer is, that you go in a forced fixing loop and your focus goes away from adding more features…..to fixing existing ones and aligning them to the standard !

I just hope that we do not get a list of such major changes in the procedures in the next incremental release.

Please note, that these changes only account for those in the procedures of the UE, P-CSCF and S-CSCF. I-CSCF was fortunately untouched in this 3GPP Release. There might be many more changes in the procedures of other nodes such as the BGCF, MGCF, I-BCF, E-CSCF etc…which i have not listed here.

Posted in 3gpp, 3GPP TS 24.229, I-CSCF, IMS, IMS procedures, IMS Release 9, IMS UE, P-CSCF, S-CSCF | 5 Comments »