Aayush: weblog

Archive for the ‘Services’ Category

IMS and LTE Policy Control for devices of different form-factors.

Posted by Aayush Bhatnagar on March 27, 2012


With the advent of LTE and IMS, Voice and Video over LTE (VoLTE) is fast becoming a reality. Customers are turning to video services rapidly and data consumption is increasing exponentially. 

Moreover, with multi-screen devices such as smart phones, tablets etc being churned out in millions – customers now own atleast 2 smart devices today. Customers also expect their applications to provide them with a uniform customer experience irrespective of the  device form factor. This holds true for all applications, and it will also be a natural expectation from IMS and VoLTE applications.

Policy Control to the Rescue:

In contrast to OTT (Over the Top) internet traffic and OTT video applications, IMS video applications have a slight edge of policy control and enforcement.

As the form factor of the device increases (from a smart phone to a tablet for example), its data consumption requirements also increase due to the bigger screen size. Moreover, if the customer chooses to play HD content, the throughput requirements would further increase accordingly.

Hence, in order to preserve the customer experience of video applications on multiple screens, it is also important that a sufficient data pipe is provided to the application in order for it to perform uniformly. In addition to the data pipe, video playback latency and jitter control also need to be controlled over the air.

This becomes increasingly important, if we wish to deliver Live TV services and VoD services over IMS.

To mitigate this situation for IMS video applications, we can effectively use the IMS and LTE policy control framework.

Solution Architecture:

The solution uses one of the most ‘ancient’ SIP headers defined by RFC 3261 in conjunction with the DIAMETER Rx interface.

The User-Agent header is defined in Section 20.41 of RFC 3261, and this header is used to provide ‘information’ on the user agent originating the SIP request. This header can be used by IMS User Equipment to provide details on the form factor of the device where the IMS client is executing. Moreover, it should also be possible to provide device pixel details (if available from the OS).

For example, on Android Operating System, the following Java code provides the screen display metrics which can be sent to the the IMS core by using the User-Agent SIP header:

DisplayMetrics dMetrics = new DisplayMetrics();
String str = “Display Metrics Are : ”
+ dMetrics.widthPixels
+ ” x ”
+ dMetrics.heightPixels;


The P-CSCF in the IMS core network can extract the User-Agent header and use the device form factor details on the Rx interface. Based on the device form factor and resolution, the PCRF can enforce appropriate QCIs, UL Bandwidth and DL bandwidth for the specific device in question.

In addition, the P-CSCF also sends the codec information as received in the SDP (Session Description Protocol) to the PCRF. This information coupled with the device form factor and resolution can enable the PCRF to calculate a very accurate measure of the UL and DL bandwidth to enforce. Moreover, this information can also help the LTE network to provide bandwidth boost to premium customers or premium video content.

Discovering the Policy Enabled Architecture:

Policy control is a distinctive edge that the VoLTE architecture provides over traditional OTT video content. The ability of the LTE and the IMS network to accurately calibrate session QoS characteristics is a true differentiator as opposed to best effort video. By leveraging age old SIP headers in conjunction with the PCRF can lead to truely differentiated customer experience.

OTT video provides provide a lot of jitter control, echo cancellation and buffering techniques to enhance customer experience, especially compensating for poor RF conditions or congestion scenarios.

However, none of those techniques can match the realtime QoS enabled architecture of VoLTE, which can guarantee high throughput even in low converage areas of LTE.

This is because LTE radio coverage is not a decisive factor for calculating throughput for customers. Throughput depends on the number of empty resource blocks available in a given eNode-B cell. For a three sector LTE base station, there are 100 resource blocks per sector. This gives a total of 300 resource blocks per base station available for customers.

Throughput is a factor of the number of free resource blocks available for a given subscriber in the LTE cell at that time. Even if the coverage is poor (cell edge conditions), it is possible to provide high throughput to the customer through the policy control architecture.

Operators need to realize the power of the IMS and LTE architecture to truly exploit it and create differentiation in their services.

There are a lot of other hidden nuggets in the combined IMS and LTE network architecture, which I will leave for another discussion and for some other day. Hopefully, engineers from around the world will discover these hidden nuggets and construct innovative policy enabled services for consumers.

Posted in 4G, Carriers, data management, IMS, Java, LTE, OTT, Services | Tagged: , , , , , , | 1 Comment »

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 »