Implementing Value Added Applications in Next Generation Networks

Abstract

One of the major issues in the future Internet is the integration of telecom networks with the Internet. In many countries, large Internet Service Providers (ISPs) are also telecom operators that have been focusing on providing Internet services through their telecom networks with telecom-grade mechanisms. In this article, we show that IP Multimedia Subsystem (IMS) is a telecom-grade mechanism that addresses this important issue. In Next Generation Network (NGN), IMS supports IP-based multimedia services that can be accessed from various wireless and wired access technologies through fixed-mobile convergence. We show how to integrate Internet Protocol Television (IPTV) with NGN/IMS to offer enhanced IPTV services for subscribers with set-top boxes or mobile phones. We specifically describe the implementations of three services: weather forecasts, short messages on TV screens and TV shopping/food ordering for mobile users. Although these services can be directly implemented in the Internet, our commercial operation experiences indicate that the NGN/IMS implementation has advantages in terms of telecom-grade security, Quality of Service (QoS), and flexible service creation.

1. Introduction

One of the major issues in the future Internet is the integration of telecom networks with the Internet. In many countries, large Internet Service Providers (ISPs) are also telecom operators; for example, Chunghwa Telecom operates HiNet, the largest ISP in Taiwan. These telecom operators have been focusing on providing Internet services through their telecom networks using telecom-grade mechanisms. In this article, we show that IP Multimedia Subsystem (IMS) is a telecom-grade mechanism that addresses this important issue of future Internet. In the Next Generation Network (NGN), IMS supports IP-based multimedia services through access networks including Wideband Code Division Multiple Access (WCDMA), Wireless Local Area Network (WLAN), CDMA2000, broadband IP network and fixed lines [1,2].

Figure 1 illustrates a simplified NGN/IMS network architecture. In this figure, the NGN/IMS network [Figure 1(a) and Figure 1 (b)] provides a standard approach to access the application network [Figure 1 (d)] from User Equipment (UE) such as a mobile handset in the Public Land Mobile Network [PLMN; Figure 1(c)] or a Set-Top Box (STB)/TV in the broadband access network [Figure 1 (e)]. An example of PLMN network is Universal Mobile Telecommunications System (UMTS) with the General Packet Radio Service (GPRS) core network [1]. In Taiwan, Chunghwa Telecom has deployed the largest commercial NGN/IMS to provision enhanced voice, video, and Internet-based multimedia services. The capacity for this NGN/IMS network can accommodate about 500,000 subscribers in daily commercial operation [3].

Figure 1. The NGN/IMS Architecture.

Figure 1. The NGN/IMS Architecture.

Based on NGN/IMS, we have developed the Multimedia Middleware Adaptation System (MMAS) and IPTV Convergence Server (IPTV-CS) [4,5] for location-based multimedia services with Multimedia on Demand (MOD). MOD [6] is a commercial IPTV service that Chunghwa Telecom offers to over 800,000 subscribers with STBs. By integrating MOD [(9) in Figure 1] with NGN/IMS through the MMAS/IPTV-CS platform, we can offer enhanced IPTV services to MOD subscribers as well as mobile users when they are watching TV. Examples of the services are described below:

(1)

Weather Forecast Service provides local weather, the weather forecast next week, international weather, satellite images, video forecasts, and so on. The service also offers special weather reports for, e.g., typhoons, low temperature, heavy rain, and earthquakes. In this service, users can set their favorite cities or obtain weather information of their current locations through the Location Based Service (LBS).

(2)

Dining Information Service provides the menu/prices of dishes of a restaurant. The food description service allows a user to query neighborhood restaurant information, restaurant addresses and phone numbers.

(3)

Music Video (MV) Information Service allows a user to browse movie trailers and download music.

(4)

Living Information Service provides Lotto winning numbers and uniform-invoice prize winning numbers inquiries.

(5)

Traffic Information Service provides immediate road status, Department of Rapid Transit System (DRTS) road maps, and timetables for airlines, Taiwan High Speed Rail (THSR), Taiwan Railways, etc.

(6)

Health Care Information Service provides neighborhood hospital information inquiry.

(7)

My Service provides user billing information.

These services can be integrated with the click-to-talk function so that a user can talk directly to service representatives (e.g., a restaurant waitress) during access of the services.

The above services can be directly deployed in the Internet. However, our commercial operation experiences indicate that implementing these services in NGN/IMS has several advantages. First, the users of these services can be directly identified by telephone numbers and can be authenticated through IMS with telecom-grade security and Quality of Service (QoS) (see [7] for the implementation details). Second, new services can be flexibly and efficiently created through the well defined interfaces of IMS such as Session Initiation Protocol (SIP) [1] and Parlay-X. In particular, new IP services can be nicely integrated with existing telecom services through this architecture. Non-IMS Internet solutions typically interact with telecom network through a gateway (such as Gateway GPRS Support Node (GGSN) in GPRS). Such approaches cannot easily manipulate telephone numbers, and cannot take full advantages of telecom-grade call control, QoS, and security because GGSN does not provide access to such telecom features as Call Session Control Function (CSCF) does.

With NGN/IMS, Chunghwa telecom has experimented with several potential services [3] to identify the restrictions and shortcomings of the overall service platform by service verification technique, a prototyping approach to verify if the related network components qualify for fulfilling the service requirements.

2. The MMAS/IPTV-CS Architecture and the Registration Procedure

In the MMAS/IPTV-CS architecture, the CSCF [(1) in Figure 1] is responsible for call control. The Session Border Controller [SBC; (2) in Figure 1] supports the functions of topology hiding and Network Address Translation (NAT)/firewall traversal. In our deployment, the CSCF is a Nokia Siemens Networks (NSN) CFX-5000, the SBC is an ACME SD 4000. The Media Server [(5) in Figure 1] converts image files into base64 encoding format and text data into defined Extensible Markup Language (XML) files for delivering contents to STBs/TVs [(11) in Figure 1] or UEs such as multimedia phones and mobile phones [(3) and (10) in Figure 1]. Equipped with both SIP and HyperText Transfer Protocol (HTTP) signaling interfaces, the MMAS Server [(4) in Figure 1] provides the IPTV Convergence Server [IPTV-CS; (7) in Figure 1] the access to the NGN core network. It also interacts with the Media Server to transfer the contents (voice, text, and images) from the content servers [e.g., Central Weather Bureau, Transportation Bureau, and so on; see (12) in Figure 1] to the UEs. The Geographic Information System (GIS) Server [(6) in Figure 1] supports LBS. The IPTV-CS is a service agent and signal adapter between the UE and other application servers [(4) and (5) in Figure 1], which consists of four functional modules and a database system. The Back-end Management Module [BMM; Figure 2(a)] performs service access control (including user authorization) and manages service related data for system notice and service configuration. The Service Integration Module [SIM; Figure 2(b)] instructs the BMM to access the contents from the Media Server, and reorganizes various content types to be compatible with the STBs and the browsers. This module communicates with an STB through the HTTP proxy of the MOD Service Delivery Platform [MOD-SDP; (9) in Figure 1]. Dispatched by the BMM, the Message Push Module [MPM; Figure 2(c)] receives short messages or Multimedia Messaging Service (MMS) messages from other application servers and forwards them to a subscriber’s TV screen through the STB. The Integrated Communication Module [ICM; Figure 2(d)] interacts with the MMAS Server to provide call control.

Figure 2. The IPTV-CS Architecture.

Figure 2. The IPTV-CS Architecture.

Before the UE can access the MMAS/IPTV-CS services, it must register to the NGN network (as illustrated in Figure 3):

Step 1: 

The UE (with the phone number +886233111111) sends a SIP REGISTER request to the CSCF with the domain name ims1.cht.com.tw. Therefore, the Request-URI of the SIP REGISTER is <sip: [email protected]>.

Step 2: 

When the CSCF receives this request, it selects the authentication vector [8] to challenge the UE. Then the CSCF sends the authentication vector to the UE through 401 Unauthorized message.

Step 3: 

After receiving 401 Unauthorized message, the UE produces an authentication response, and sends it back to the CSCF through a SIP REGISTER message.

Step 4: 

The CSCF compares the received response with the expected response. If they match, then the authentication is successful. The CSCF replies a positive SIP 200 OK response to the UE.

After this registration procedure, the mobile user can access the MMAS/IPTV-CS services.

Figure 3. IMS Registration.

Figure 3. IMS Registration.

3. Message Flow for Location Information

By dialing the service access numbers, a user [the UE; (3) in Figure 1] can access MMAS/IPTV-CS services. In our example, the service access number for dining information service is 1270181. These service access numbers are stored in the service configuration table of the MMAS Server. The service scripts corresponding to these service access numbers are stored in the Media Server under the directory /home/ivr. Furthermore, every service access number is mapped to the MMAS Server’s IP address mmas_ip (i.e., 172.28.41.6) in the routing table of the CSCF. Figure 4 illustrates how location information can be retrieved. For example, when a user dials the service access number 1270181 to access the location information of a restaurant (just like a typical phone number dialing), the following steps are executed:

Step 1: 

The UE sends a SIP INVITE request to the CSCF. The Request-URI is <sip:[email protected]>. The Session Description Protocol (SDP) [9] of this request specifies UE’s audio and video formats (e.g., the voice codec is AMRnb, the audio Real-time Transport Protocol (RTP) port is 17946, the video codec is H263, Common Intermediate Format (CIF) (352 x 288) resolution, and the video RTP port is 42360). The restaurant name is indicated in SDP session information field.

Step 2: 

When the CSCF receives this SIP INVITE request, it replies a SIP 100 Trying response to UE to indicate that the setup procedure is in progress.

Step 3: 

In parallel with Step 2, the CSCF uses 1270181 to retrieve the MMAS Server’s IP address from the routing table, and forwards the SIP INVITE request to this IP address.

Step 4: 

If the service access number 1270181 (retrieved from the Request-URI of the INVITE) is found in the service configuration table, the MMAS Server replies the SIP 100 Trying response to inform the CSCF that the request is being handled.

Step 5: 

The MMAS Server sends SIP INVITE to the Media Server to execute service script 1270181.

Step 6: 

The Media Server replies 100 Trying response and starts a thread for this service with the following command:

Creation of ExecBox id:5 pid:14473 userid:0 directory:'/home/ivr/1270181' and the script 1270181 located at directory /home/ivr/ is executed.

Step 7: 

The script 1270181 instructs the GIS Server to provide the electronic map by issuing the command http://map.cht.com.tw/IntegratedMapService/GetAPI.aspx?key=xxxx, setCenter (new CLatLng(X, Y), 9)), where map.cht.com.tw is the GIS Server’s domain name, IntegratedMapService is the directory of the map service functions, and GetAPI.aspx?key=xxxx instructs the GIS Server to perform the authentication procedure with key xxxx. Function setCenter(new CLatLng(X, Y), 9) specifies the restaurant geographic coordinate (X, Y) translated from the restaurant name by the Media Server, and the radius 900 meters of the map to be retrieved.

Step 8: 

If the request is authorized, the GIS Server copies the map picture and sends it back to the Media Server.

Step 9: 

In parallel with Step 7, the Media Server replies the SIP 200 OK with the SDP (i.e., the negotiated audio and video formats) to the UE through the MMAS and the CSCF.

Step 10: 

The UE sends the SIP ACK to the Media Server.

Step 11: 

At this point, the RTP session is established, and the requested map is delivered from the Media Server to the UE through path (5)-(2)-(c)-(3) in Figure 1.

Step 12: 

Besides the RTP connection, the Media Server will also provide touch screen information to the UE. This information provides the grid location translation to Dual Tone Multi-Frequency (DTMF) digits. For example,

<dtmf len="2" value="*1"/> <grid x1="123",y1="456",w1="24",h1="3"/> means that when the user presses the screen area of width 24 and height 3 at the coordinate (123, 456), the UE will generates two DTMF digits *1. The Media Server sends the touch screen information to the UE through SIP INFO message.

Step 13: 

The UE replies the 200 OK to the MMAS Server. At this point, the user can appropriately touch the screen.

Step 14: 

When the user touches the screen (e.g., he/she wants to see the menu of this restaurant), the UE will sends the corresponding DTMF digits to the Media Server through the RTP connection [10]. The Media Server then sends the new screen to the user based on the DTMF signals.

In the above example, the UE is assumed to be a mobile phone. This service can also be accessed from STB/TV.

Figure 4. Location Information Message Flow.

Figure 4. Location Information Message Flow.

4. Weather Forecast Service

When an MOD subscriber watches the TV, he/she can access weather/traffic information by selecting an icon on the screen. Figure 5 shows how the weather forecast service is presented in the UE.

Figure 5. Weather Forecast Service.

Figure 5. Weather Forecast Service.

The message flow for accessing the weather forecast service is illustrated in Figure 6 and is described as follows:

Step 1: 

The Central Weather Bureau (Transportation Bureau) periodically sends the weather/traffic information to the Media Server through FTP. The Media Server then forwards the information to the IPTV-CS. The BMM parses the received information and stores the results into the database [Figure 2 (e)].

Step 2: 

To access the weather information, the browser on the STB first access the location information described in Section 3, and then sends an HTTP request to the MOD-SDP (if MOD-SDP is equipped with SIP, then the following message exchange can also be implemented by SIP). The URI of the HTTP request is

http://cs_ip and port_no/weather/WeatherServlet?black={$string}&{other_parameters}

where cs_ip and port_no are the IP address and port number of the IPTV-CS, respectively. The parameter “black” is an encrypted string containing the IP address and the identification number of the originating STB, the customer ID, and the time stamp. Function WeatherServlet is located at directory weather/, which instructs the IPTV-CS to execute the user’s request. “other_parameters” specify area, time and data type (text, image, video, or mixed data) of the weather information to be retrieved.

Step 3: 

Upon receipt of the HTTP request, the IPTV-CS decrypts the “black” parameter by Data Encryption Standard (DES) or DES3 to authorize the request. Specifically, it queries the database [Figure 2 (e)] to obtain the subscriber’s data and compare them with the decrypted customer ID and IP address of the STB.

Step 4: 

The IPTV-CS retrieves the required weather/traffic content including texts and images from its database, and uses them to create the web pages for the ANT Fresco or Firefox browser according to the STB type. The HTTP response with the content (web page) is returned to the STB through the MOD-SDP, and the weather/traffic information is displayed on the TV screen.

Figure 6. Message flow of the weather information.

Figure 6. Message flow of the weather information.

5. SMS on Screen

In a mobile network, all short messages are sent to the Short Message-Service Center [SM-SC; see (8) in Figure 1] before they are delivered to the destinations (typically mobile handsets). By integrating MOD-SDP and SM-SC, the IPTV-CS can display an MOD user’s short messages on the TV screen. Figure 7 shows the message flow of SMS on TV screen. At the initialization phase (Step 0 of Figure 7), the IPTV-CS creates a SOCKET connection with the SM-SC and specifies the mobile phone numbers of the MOD users who subscribe to this service (and therefore, the short messages for the MOD users will be forwarded to the STBs/TVs). These mobile phone numbers are saved in the MOD user database of the SM-SC. When a short message is sent from a mobile user [UE2; (10) in Figure 1] to the MOD user [UE1; (3) in Figure 1] with the STB [(11) in Figure 1], the following steps are executed:

Step 1: 

The short message is first delivered to the SM-SC through the GSM-MAP protocol [11].

Step 2: 

The SM-SC confirms UE2 the receipt of this short message, and decodes it [12] to retrieve the called ID.

Step 3: 

If this phone number is found in its MOD user database, the SM-SC forwards the message to the IPTV-CS through the SOCKET interface. This SOCKET message contains the calling ID, the called ID and the message content.

Step 4: 

The IPTV-CS encapsulated the short message in an SNMP message sent to the target STB [(11) in Figure 1]:

snmpset–c private–v 2c [STB IP] [OID] “[text]:this is a short message from 0928123456 [xywh]:50,50,400,80[timeout]:300”

where private is the SNMP community name, STP_IP and OID are the IP address and the object identifier of the target STB, text is the tag for the message, xywh is the tag for the position and size of the message window, and timeout is the elapsed time to display the message on the TV screen.

The above message flow can be added some additional parameters such that when a short message arrives at the STB, the text is not shown on the TV screen (to enhance privacy).

Figure 7. Message flow of SMS on TV screen.

Figure 7. Message flow of SMS on TV screen.

6. TV Shopping/Food Ordering

On a TV shopping channel, viewers can purchase the products through the TV remote controller. Similarly, the TV food ordering service provides web pages for subscribers to order pizzas or meals. With the click-to-dial function, the IPTV-CS establishes a call for the MOD user [UE1; (3) in Figure 1] to contact the vender [UE2; (10) in Figure 1] when the user is watching the TV shopping channel. Note that UE1 can be a special MOD remote controller with phone features, a SIP-based video phone, or a mobile phone. We assume that both UE1 and UE2 are mobile phones. The call flow for click-to-dial is described as follows (see Figure 8):

Step 1: 

To purchase a product, UE1 selects this product shown on the TV screen by pressing the button of the remote controller. Then the browser on the STB sends an HTTP request to the MOD-SDP. The URI of the HTTP request is

http://cs_ip:port_no/IMS/MakeCallServlet?black={$encrypted string}&item_id={$itemId}

where cs_ip:port_no are the IP address/port number of the IPTV-CS, item_id indicates the merchandise the subscriber wants to order, black specifies the calling ID (i.e., the phone number of UE1), and the script MakeCallServlet under the directory IMS/ instructs the IPTV-CS to perform the Third Party Call Control (TPCC) between the MOD user (UE 1) and the vendor (UE 2). The MOD-SDP forwards the message to the IPTV-CS for the authorization procedure.

Step 2: 

The authorization procedure is similar to Step 3 in Figure 6, and the details are omitted.

Figure 8. Message flow for TV shopping/food ordering.

Figure 8. Message flow for TV shopping/food ordering.

Step 3: 

After authorization, the IPTV-CS uses item_id to retrieve the called ID (the phone number of UE2) from its product database. Then the IPTV-CS sends the HTTP request to the MMAS Server with the following URI:

http://mmas_ip:port_no/TPCC/dotpcc.jsp?calling={$calling_no}&called={$called_no},

where mmas_ip:port_no are the IP address and port number of the MMAS Server, and the script dotpcc.jsp in directory TPCC/ instructs the MMAS server to perform the third party call control. Parameters called_no and calling_no are phone numbers of UE 2 and UE 1, respectively.

Step 4: 

The MMAS Server returns an HTTP “processing” response to the STB to indicate that the request is being processed.

Step 5: 

In parallel with Step 4, the MMAS Server initiates a SIP INVITE message without SDP to the Media Server. The Request-URI of the message is <sip:8890@ms_ip:5060>, where ms_ip is the IP address of the Media Server. The code 8890 is dedicated to a simple Interactive Voice Response (IVR) function of the Media Server to play an announcement, which requests UE1 to dial digit “#” as the agreement to continue the call. This action confirms that UE1 will make this order.

Step 6: 

When the Media Server is ready to provide the 8890 function, it answers a SIP 200 OK with SDP of the Media Server to the MMAS Server.

Step 7: 

The MMAS Server establishes an RTP session to UE 1 following the standard SIP call setup procedure (the details are omitted).

Step 8: 

After UE1 dialed the digit “#”, the Media Server sends this code to the MMAS Server by an HTTP request:

http://mmas_ip:port_no/TPCC/receiveinformation.jsp?call_id={$sip_callid}&result={1}&code={#},

where the script receiveinformation.jsp in directory TPCC/ instructs the MMAS Server to receive UE1’s dialed digit from the Media Server and then start to communicate with UE2 (with the called number stored in the MMAS server), call_id obtained in the Call-ID header field of the SIP INVITE request at Step 5 is used by the MMAS Server to retrieve the information about this call, result “1” means that the action is successful (other values mean failure), and code “#” is the dialed DTMF digit from UE1.

Step 9: 

At this point, the MMAS Server establishes another RTP session between UE 1 and UE 2 following the standard SIP call setup procedure (the details are omitted but are shown in messages 9.1–9.7 in Figure 8).

Step 10: 

The MMAS Server sends a SIP BYE message to the Media Server to withdraw its resource from this call.

Step 11: 

The Media Server replies a SIP 200 OK response to indicate that the session is terminated.

Besides the services described above, some potential services (such as taxi ordering, instant message, and TV yellow page) can be similarly implemented.

7. Conclusions

This paper showed how to integrate IPTV with IMS/NGN to offer enhanced IPTV services to subscribers with STBs/TVs, video phones or mobile handsets. We use MOD, the IPTV service of Chunghwa Telecom, to illustrate that such integration can be efficiently achieved in the NGN/IMS. The described services can be integrated with the click-to-the-talk function so that a user can talk directly to the service representatives during access of the services. Our study indicates that value added applications can be easily developed in our platform and how the platform interworks with NGN to provide service control mechanism for developing new services, which does not involve the delivery of MOD contents. Our future work will investigate the migration of the IPTV platform towards the NGN IMS-based architecture.