Published online 1 July 2010 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/wcm.997
RESEARCH ARTICLE
Enhanced video phone services for NGN/IMS
Gong-Da Fan1, Chao-Chun Huang1, Yi-Bing Lin2∗, Chung-Shih Tang1, Chin-Ywu Twu1and
Yun-Hui Wen1
1Chunghwa Telecom, Taiwan, Republic of China
2Department of Computer Science, National Chiao Tung University, Hsinchu, Taiwan, Republic of China
ABSTRACT
A Next Generation Network (NGN) has been developed in Taiwan, where IP Multimedia Subsystem (IMS) plays an important role to offer IP-based multimedia services. Such NGN/IMS networks have also been deployed worldwide. However, details of commercial-grade NGN service implementations are seldom reported in public. In this paper, we show how existing video phone service can be enhanced through Chunghwa Telecom’s NGN/IMS. Specifically, we illustrate three examples including Multimedia on Demand (MOD) TV, Multimedia Ringback Tone (MRBT), and Easy Go (EzGo). We also measure the delay times for accessing these services. The measurements indicate that performance for these IMS-based services is satisfactory. Copyright © 2010 John Wiley & Sons, Ltd.
KEYWORDS
Next Generation Network; IP Multimedia Subsystem; mobile service *Correspondence
Yi-Bing Lin, Department of Computer Science, National Chiao Tung University, Hsinchu, Taiwan, Republic of China. E-mail: liny@csie.nctu.edu.tw
1. INTRODUCTION
In the Next Generation Network (NGN), IP Multimedia Subsystem (IMS) supports IP-based multimedia services through access networks including WCDMA, Wireless LAN, CDMA2000, broadband IP network, and fixed lines. Figure 1 illustrates a simplified NGN/IMS network archi-tecture [1,2]. In this figure, the NGN/IMS network (Figure 1(a) and (b)) connects to the Public Switched Telephone Network (PSTN) and Circuited Switched (CS) domain of the Public Land Mobile Network (PLMN; see Figure 1(e)) for fixed mobile convergence (FMC). IMS provides a stan-dard approach for access to the application network (Figure 1(d)) from User Equipment (UE) such as a fixed video phone (Figure 1(17)) in the broadband IP access network (such as xDSL and FTTx; see Figure 1(c)) or a mobile handset (Figure 1(4)) in the packet-switched (PS) domain of PLMN (Figure 1(f)). An example of PLMN-PS network is UMTS with the GPRS core network [1].
The Call Session Control Function (CSCF; Figure 1(2)) is responsible for call control. The Home Subscriber Server (HSS) or User Profile Server Function (UPSF; Figure 1(1)) is the master database containing subscription-related infor-mation for each IMS user. The Media Gateway Control Function (MGCF; Figure 1(5)) controls the connection of media channels in a Media Gateway (MGW; Figure 1(6)).
The MGW connects toward the PSTN/PLMN-CS to pro-vide user media transport. The Session Border Controller (SBC; Figure 1(3)) supports the functions of topology hiding and NAT/firewall traversal. The Connectivity ses-sion Location and repository Function (CLF; Figure 1(7)) is a function element of Network Attachment Subsystem (NASS) defined by TISPAN NGN [2], which holds the IP address and the location information binding of an IMS user (usage of the CLF will be discussed in Section 5).
Chunghwa Telecom has deployed the largest commer-cial NGN/IMS in Taiwan to provision enhanced voice, video, and Internet-based multimedia services. The current NGN/IMS capacity can accommodate about 500 000 sub-scribers in daily commercial operation. In this deployment, the CSCF is a Nokia Siemens Networks (NSN) CFX-5000, the MGCF is an NSN hiE9200, the MGW is an NSN hiG1100, the UPSF is an NSN CMS-8200, the SBC is an ACME SD 4000, the CLF is an Alcatel-Lucent SSC 5750. In Chunghwa Telecom’s NGN/IMS, video phone service is efficiently supported by the application network through the CSCF and the UPSF. The IMS application servers in this network will be elaborated in the subsequent sections. Based on Chunghwa Telecom’s video phone service, we have developed several enhanced services including Multi-media on Demand (MOD) TV, MultiMulti-media Ringback Tone (MRBT), and Easy Go (EzGo). In this paper we show how
Figure 1. The NGN/IMS architecture is composed of (a) NGN Core, (b) Managed IP Network, (c) Broadband IP Access Network, (d) Application Network, (e) PSTN or PLMN-CS network, and (f) PLMN-PS network.
standard video phone service can be modified to provision these services.
2. SERVICE PROVISION AND USER
REGISTRATION
This section introduces service provisioning mechanism and the phone registration procedure for NGN/IMS. The NGN-MOD service allows an IMS user to watch IPTV program in a mobile handset or a video phone (see Figure 2(a)). The MRBT service plays video clips as ringback tone (see Figure 2(b)). The EzGo service allows a store/company to display its location-related information (e.g., map) to a caller (see Figure 2(c)).
To provision the NGN-MOD service, for example, we only need to store the service access number (e.g., +886233333333) of the NGN-MOD Server (Figure 1(9)) and its IP address in the routing table of the CSCF. Then any legal IMS user can enjoy the TV programs by dialing the NGN-MOD Server’s service access number (which has the same format as a telephone number to be elaborated in Section 3).
For MRBT or EzGo services, a subscriber (an IMS user) must order these services at the subscription time. A record in the UPSF (Figure 1(1)) is created for each IMS user, which includes the trigger profile for the subscribed ser-vice. Table I lists the trigger profiles for two IMS users. In
the first entry, a user with phone number+886233111111 subscribes to the MRBT service. The service type is ses-sion terminating or mobile terminating (MT; which means that the service is triggered only when the subscriber is the callee). The initial filter criteria include the IP address mrbt ip of the MRBT Server (Figure 1(13)) and the SIP method that triggers this service (which is INVITE).
The EzGO service is typically subscribed by a store or a company for advertisement. In the current EzGO imple-mentation, the UE of the subscriber must be a fixed video phone located at the broadband IP access network (Figure 1(c)). In Table I, the second entry is the trigger profile for an EzGO subscriber (a store/company) with phone number +886233222222. The service type is MT. The initial filter criteria include the IP address EzGO ip of the EzGO Server (Figure 1(12)) and the SIP request that triggers this service (which is INVITE).
Every time when a UE (Figure 1(4)) attaches to the NGN/IMS (e.g., when the IMS user turns on the UE), the UE executes the registration procedure before it can access any IMS services. In the following steps of the registration procedure, we show how the messages travel among the network nodes (the notation, e.g., [(4)→ (f)] means that a message is sent from the UE (Figure 1(4)) to the PLMN-PS network (Figure 1(f))).
1. [(4)→ (f) → (3) → (2)] The IMS user sends
Figure 2. Enhanced video phone services for NGN/IMS: (a) NGN-MOD, (b) MRBT, and (c) EzGO.
This request includes the phone number +886233111111 of the UE and authentication-related parameters (e.g., the username and the realm). The Request-URI of the SIP request is <sip:+886233111111@ims domain>, where ims domain will be translated by Domain Name Service (DNS) to the CSCF’s IP address.
2. [(2)→ (1)] The CSCF uses the phone number +886233111111 to conduct the registration pro-cedure with the UPSF. Specifically, it sends the Diameter Multimedia-Auth-Request (MAR) to the UPSF. The MAR includes the authentication-related parameters.
3. [(1)→ (2)] If the password is correct, the authenti-cation is successful, and the UPSF returns a positive Multimedia-Auth-Answer (MAA).
4. [(2)→ (1)] The CSCF issues the Diameter Server-Assignment-Request (SAR) to the UPSF to down-load the user trigger profile for this user (i.e., the first entry in Table I).
5. [(1)→ (2)] The UPSF returns the user trigger profile to the CSCF by the Diameter Server-Assignment-Answer (SAA). This initial filter criteria is stored in the CSCF.
6. [(2)→ (3) → (f) → (4)] The CSCF sends the SIP 200 OK response to the user to inform him/her that the registration is successful.
We note that if a mobile phone (Figure 1(18)) locates at the PLMN-CS perform the above registration proce-dure, then the SIP path (2)-(3)-(f)-(4) is replaced by (2)-(5)-(e)-(18). After this registration, when someone dials +886233111111, the caller will hear the multimedia ring-back video for UE1 (to be elaborated in Section 4).
3. NGN-MOD TV PROGRAM
MOD is an IPTV service, which provides diverse multime-dia contents in the broadband IP access network. Several telecom operators have developed IPTV over NGN, for example, BT Vision of British Telecom [3] and Mega TV of Korea Telecom [4]. However, the implementation details and performance data are not accessible in public. In this section, we show how commercial-grade IPTV can be inte-grated in NGN.
Chunghwa Telecom’s MOD System (Figure 1(11)) is implemented in Alcatel-Lucent Open Media Platform (OMP). Through NGN/IMS, users are allowed to watch MOD channels via video devices (video phone, 3G mobile phone, or PC browser) instead of TV sets. In this NGN-MOD service, a user simply dials the service access number of MOD, which results in a video call that plays real-time TV program. This IMS application is offered through the Streaming Server (Figure 1(10)) and the NGN-MOD Server
Table I. Examples of the trigger profiles in the UPSF.
User telephone number Service trigger type Initial filter criteria
Entry Application Server Method
1 +886233111111 MT mrbt ip INVITE
(Figure 1(9)). Both of them are HP DL360 G5 servers. The Streaming Server is responsible for retrieving a set of specified real-time MOD TV programs from the MOD sys-tem, and transcoding video/audio from standard definition format of MPEG-2 to CIF-format H.263 and AMR-NB, respectively. Through program pre-arrangement, an IMS user can access the MOD TV program directly from the Streaming Server instead of channel arrangement at the remote MOD system. The NGN-MOD Server is an NGN video portal that retrieves video/audio contents from the Streaming Server by using the Real-Time Streaming Pro-tocol (RTSP) [5]. This server uses SIP to interact with the CSCF (Figure 1(2)) for session control, and uses the Real-time Transport Protocol (RTP) to provide MOD services to an IMS UE (Figure 1(4)) through the managed IP network (Figure 1(b)).
As mentioned in Section 2, the NGN-MOD service is provisioned by directly storing MOD’s service access num-ber+886233333333 and NGN-MOD Server’s IP address MOD ip in the routing table of the CSCF.
The message flow of the NGN-MOD service is described as follows:
1. [(4)→ (f) → (3) → (2)] UE1 makes a video call by dialing the number +886233333333, which results in a SIP INVITE request sent to the CSCF. In this request, the Request-URI is<sip:+886233333333@ims domain>. The INVITE request includes the Session Description Protocol (SDP) to specify the capabilities of media supported for UE1.
2. [(2)→ (3) → (f) → (4)] The CSCF sends the SIP 100 Trying response to the UE. This response indi-cates that the INVITE has been received and the CSCF is routing this request to the destination. 3. [(2)→ (9)] In parallel with Step 2, the CSCF uses
+886233333333 in the Request-URI of the SIP INVITE to retrieve MOD ip (the IP address of the NGN-MOD Server) from its routing table. Note that the MOD access number mapping is pre-configured in the CSCF’s routing table as described in Section 2. Then the CSCF forward the SIP INVITE to the NGN-MOD Server.
4. [(9)→ (2)] When the NGN-MOD Server receives the SIP INVITE request, it sends a SIP 100 Trying response to the CSCF to confirm the request. 5. [(9)→ (2) → (3) → (f) → (4)] The NGN-MOD
Server sends a SIP 200 OK response with the nego-tiated SDP to the UE. In this response, the SDP contains the media description negotiated by the NGN-MOD Server.
6. [(4)→ (f) → (3) → (2) → (9)] After receiving the response, the UE replies the SIP ACK, and the media session is established between the UE and the NGN-MOD Server ((9)-(3)-(f)-(4) in Figure 1). 7. [(9)→ (10)] In parallel with Step 5, the NGN-MOD Server issues two RTSP requests to the Stream-ing Server. This request specifies the DESCRIBE
command that contains the absolute RTSP-URL (rtsp://stream ip/channel no) of the TV program, where stream ip is the IP address of the Stream Server, and channel no is the TV channel selected by the UE at the last call.
8. [(10)→ (9)] If the request is accepted, the Stream-ing Server sends an RTSP 200 OK response with an SDP (containing the media information of audio/video about that TV program) to the NGN-MOD Server.
9. [(9)→ (10)] The NGN-MOD Server sends the Streaming Server an RTSP request containing command SETUP (rtsp://stream ip:554/channel no/trackID) based on the SDP specified by the Streaming Server. Each command sets up a media stream of the TV channel indicated by trackID, one for audio and the other for video). Port 554 of the Streaming Server is used by the RTSP to control the stream.
10. [(10)→ (9)] The Streaming Server sends an RTSP 200 OK response to establish the link between the NGN-MOD Server and the Streaming Server. 11. [(9)→ (10)] The NGN-MOD Server sends the
Streaming Server the RTSP request containing command PLAY (rtsp://stream ip/channel no). 12. [(10)→ (9)] The Streaming Server sends an RTSP
200 OK response to the NGN-MOD Server, and starts delivering the selected MOD TV content through RTP and RTCP connections. The RTCP connection is utilized to synchronize the interleaved audio and video streams.If the NGN-MOD Server correctly receives the content from the Streaming Server, it transparently forward the streams to the UE through the RTP path (see path 1 in Figure 3). If the caller wants to switch to another TV program, the following steps are executed:
13. [(4)→ (f) → (3) → (9)] The caller presses key ‘2’ to jump to the previous channel, key ‘8’ to the next channel, and key ‘#’ to exit the service. Pressing of a key results in a Dual-Tone Multi-Frequency (DTMF) signal sent from the UE to the NGN-MOD Server through the RTP connection [6].
14. [(9)→ (10)] According to the received DTMF sig-nal, e.g., key ‘8’, the NGN-MOD Server retrieves the specified TV program from the Streaming Server, and deliver the content to UE1 through path (see path 1 in Figure 3).
In Chunghwa Telecom’s IMS-MOD, the transport band-width ranges from 384 kbps (for video surveillance service) to 584 kbps (for real-time delivery). We have conducted measurements for NGN/MOD signaling. The average delay of SIP message exchanges for a MOD program setup (Steps 1--6) is 0.2 s. After the setup, the average delay to receive the first audio packet is 1.3 s (Steps 7--12), and the aver-age delay for the first video packaver-age is 1.4 s. The averaver-age delays on channel switching for the first audio and video packets are 1.3 and 1.7 s, respectively (Steps 13 and 14).
Figure 3. The RTP path of the three applications.
Note that if the caller uses a mobile phone from PLMN-CS domain, then the RTP path (9)-(3)-(f)-(4) is replaced by (9)-(3)-(6)-(e)-(18).
4. MULTIMEDIA RINGBACK TONE
(MRBT)
The MRBT service is an extension of audio ringback tone, which allows a user (the callee) to select music videos, advertisements, or recorded video clips as personal ring-back multimedia. Through ringring-back video, for example, an enterprise can show product advertisement to the callers for promoting business. MRBT services have been imple-mented involving MGW and MGCF [7]. Within NGN/IMS, this section shows that MRBT can be implemented with-out involving these IMS nodes and therefore reduce the complexity of the implementation.
In Chunghwa Telecom’s MRBT service, a BEA WebLogic SIP Server (WLSS) implements the MRBT Server (Figure 1(13)), which is responsible for MRBT signaling and control of the Media Server to offer multime-dia contents. The Memultime-dia Server (Figure 1(8); a Radvision Scopia) plays and records video, and is responsible for col-lecting DTMF digits.
As described in Section 2, the MRBT service is provi-sioned by the IMS service triggering mechanism. After an IMS user with phone number+886233111111 has sub-scribed to the MRBT service, the corresponding service trigger is included in that user’s user profile in the UPSF (see the first entry of Table I). When the user attaches to NGN/IMS, this user profile is retrieved by the CSCF, and the IP address of the MRBT Server is stored in the CSCF’s rout-ing table. Also, after an IMS user has finished the MRBT
service subscription, the user may select or upload his/her favorite video clips at the MRBT web portal (Figure 1(15)). The MRBT web portal automatically re-sizes and converts the video clips to a suitable format for video phones.
When UE2 (Figure 1(17)) with phone number +886233222222 makes a video call to an MRBT user UE1 (Figure 1(4)) with phone number+886233111111, the fol-lowing call setup procedure is executed:
1. [(17)→ (c) → (3) → (2)] UE2 dials UE1’s phone number (+886233111111), and a SIP INVITE request is routed to the CSCF. The SIP INVITE request contains the URI of the callee +886233111111@ims domain. The SDP of the request specifies the codecs of UE1 for playing the video clip.
2. [(2)→ (13)] The CSCF uses +886233111111 in the Request-URI of the INVITE to check if this SIP request matches any trigger criteria of UE2’s user profile. The MRBT service trigger is matched, the IP address mrbt ip is retrieved from the criteria (see the first entry in Table I), and the SIP message is routed to this IP address.
3. [(13)→ (2) → (8)] Implemented as a Back-to-Back User Agent (B2BUA), the MRBT Server sends a new INVITE request to the Media Server. The To header of the INVITE is<mrbt@media ip:5060>, where media ip is the IP address of the Media Server, 5060 is the Media Server’s port for SIP applications, and mrbt represents the MRBT pro-gram to be invoked in the Media Server.
4. [(8)→ (2) → (13)] The Media Server returns a 200 OK response to the MRBT Server with the negoti-ated codec for playing the video clips.
5. [(13)→ (2) → (3) → (c) → (17)] The B2BUA application of the MRBT Server forward this response to UE2.
6. [(17)→ (c) → (3) → (2) → (13) → (2) → (8)] The caller returns a SIP ACK message to the Media Server through the MRBT Server.The Media Server plays the video clip to the caller. The RTP session is set from the Media Server to UE2 through path (8)-(3)-(c)-(17) in Figure 1. The MRBT Server sets up the call between UE1 and UE2 with the following steps:
7. [(13)→ (2) → (3) → (f) → (4)] In parallel with Step 5, the MRBT Server sends an INVITE request to UE1, where the Request URI is <sip:+886233111111@ ims domain>, and the Contacts header is <sip: mrbt ip:5060>). This INVITE message does not include the SDP part. 8. [(4)→ (f) → (3) → (2) → (13)] When the callee
answers the phone, UE1 sends a SIP 200 OK response to the MRBT Server with the SDP. 9. [(13)→ (2) → (3) → (c) → (17)] The B2BUA
of the MRBT Server sends a re-INVITE request with the negotiated SDP of UE1 to UE2. The re-INVITE has the following header fields: From:
<+886233111111@ims domain>, To: <sip:+ 886233222222@ims domain>, and Contacts: <sip:mrbt ip:5060>.
10. [(17)→ (c) → (3) → (2) → (13)] UE2 replies the SIP 200 OK with the negotiated SDP to the MRBT. 11. [(13)→ (2) → (3) → (f) → (4)] The MRBT Server sends the SIP ACK to UE1 containing the negoti-ated SDP of UE2.
12. [(13)→ (2) → (3) → (c) → (17)] The MRBT Server sends the SIP ACK to UE2. At this point, UE1 and UE2 can start conversation. The RTP connection is (4)-(f)-(b)-(c)-(17) (see path 2 in Figure 3).
13. [(13)→ (2) → (8)] The MRBT Server sends a SIP BYE to the Media Server to stop the RTP session that plays the video clip.
14. [(8)→ (2) → (13)] The MRBT Server receives the SIP ACK from the Media Server to terminate the MRBT service.
An alternative to offer the MRBT service is to utilize the SIP 183 Session Progress response to carry video clip [8]. At Step 4 of the above MRBT procedure, when The MRBT Server receives the 200 OK response from the Media Server, the forwarded 200 OK response from the MRBT Server to UE 1 is replaced by a 183 Session Progress response containing the SDP of the Media Server. We note, however, some SIP phones do not support the 183 Session Progress message. In our experiments, the average delay for video phone (the caller) to receive the ringback video after it sends an INVITE is 0.84 s.
5. EZGO STORE INFORMATION
QUERY
EzGO is a location-based service that allows an IMS caller to access the transportation and geographical information of the callee during a video call. For example, when an IMS user (UE1) makes a call to a store (UE2), the EzGO service shows the area map and the transportation-related information of UE2 to UE1. This section shows that by re-using the MRBT mechanism with location servers, EzGO can be quickly and efficiently deployed.
In this service, the EzGO Server (Figure 1(12)) is a BEA WLSS, which provides EzGO services and the interoper-ability between SIP and Non-SIP platforms. The Media Server (Figure 1(8)) provides the multimedia contents in a video call. The Geographic Information System Server (GIS Server; see Figure 1(14)) provides geographic information query via web services.
Due to privacy concern, current EzGO version only pro-vides the location information of companies in the public domain. Unlike the mobile location-based service, the loca-tion informaloca-tion of a ‘fixed’ IMS user (e.g., a company or a department store) is stored in the CLF (see Figure 1(7)), where the longitude/latitude and the xDSL line identifier are used as the location information of a user.
Consider an EzGO store (UE2) with number
+886233222222. The trigger profile is stored in the second entry of Table I. When someone (UE1) attempts to access UE2’s EzGO information, the following procedure is exercised:
1. [(4)→ (f) → (3) → (2)] UE1 (Figure 1(4)) dials +886233222222 to make a video call to the EzGO store (Figure 1(17)). The SIP INVITE request is delivered to the CSCF. In this message, the User-Agent header is used to carry call agent type. Based on the type of call agent, the EzGO Server decides to use the map scale in either the Common Interme-diate Format (CIF) or the Quarter-CIF (QCIF). 2. [(2)→ (12)] By retrieving the phone number
+886233222222 in the Request-URI, the CSCF checks if the INVITE request matches the MT trigger criteria of the EzGO store’s user profile. Suppose that the service trigger is matched, and the IP address EzGO ip is obtained. The INVITE request is routed to the EzGO Server through this IP address.
3. [(12)→ (3) → (7)] The EzGO Server queries the CLF through a secure http connection (HTTPS) to obtain the longitude/latitude information related to the store (i.e., UE2). Specifically, the EzGO Server sends the following message to the CLF through TCP port 443: GET/EzGO/CLFQuery.jsp?number = +886233222222 HTTP/1.1 4. [(7)→ (3) → (12)] The CLF replies HTTP/1.0200 OK Location−in formation : adsl; 25, 120
which indicates that UE2 is connected to ADSL at longitude/latitude 25/120.
5. [(12)→ (14)] The EzGO Server sends the follow-ing HTTP Simple Object Access Protocol (SOAP) message to retrieve the area map and transportation-related data from the GIS Server:
GET http ://GIS ip/integratedMapService/ MapService.asmx/GetMap?ScaleLvl = 8&X = 120&Y = 25&width = 352&height = 288 where GIS ip is the IP address of the GIS Server. In this message, the map is centered at the coordinate specified in the X (longitude) and the Y (latitude) parameters. The width is 352 pixels and the height is 288 pixels (for the CIF format). The parameter integratedMapService instructs the GIS Server to execute the ‘Get Map’ operation.
6. [(14)→ (12)] The GIS Server then replies an HTTP 200 OK with the requested map file as a base-64 encoded string.
7. [(12)→ (2) → (8)] The EzGO Server translates the map file from the base-64 encoded string to a 3GP video file. Then it sends an HTTP GET message to the Media Server. This message includes the param-eters such as the store’s phone number and the 3GP video file.
8. [(8)→ (2) → (12)] When the Media Server receives the HTTP GET message, it replies an HTTP 200 OK to the EzGO Server to indicate that it is ready to display the map information.
9. [(12)→ (2) → (8)] The EzGo Server sends a new SIP INVITE request to the Media Server.
10. [(8)→ (2) → (12) → (2) → (3) → (f) → (4)] The Media Server sends back the SIP 200 OK response to the EzGO Server with the negotiated SDP (which is affected by the CIF or the QCIF formats). The EzGO Server forward this 200 OK response to UE1.
11. [(4)→ (f) → (3) → (2) → (12) → (2) → (8)] UE1 replies a SIP ACK to the Media Server through the EzGO Server.
The RTP connection is established (path (8)-(3)-(f)-(4); Path 3 in Figure 3), and the Media Server executes a V2XML script to display the map and the related trans-portation information to UE1. Like the NGN-MOD service, UE1 can use DTMF keys to perform the following opera-tions:
Directions: DTMF key ‘5’ centers the target on the map and keys ‘1’ to ‘9’ moves the map toward 8 directions.
• Information: DTMF key ‘*’ queries transportation information in text.
• Call Control: DTMF key ‘#’ transfers the call to the callee of the store. The call setup procedure is similar to that of the MRBT service.
• We have measured the delay for displaying the map (i.e., the execution of Steps 1--11). The average delay is 0.85 s.
6. CONCLUSIONS
Chunghwa Telecom has deployed the largest commercial NGN/IMS in Taiwan to provision commercial telecommu-nication services such as voice, video, and Internet-based multimedia services. In the NGN/IMS platform, the CSCF can be utilized to efficiently control the enhanced services. In this paper, we demonstrated how existing video phone mechanism can be enhanced through NGN/IMS to create enhanced services including MOD TV, MRBT, and EzGo. Measurements indicate that the performances (delays of control message) of these service implementations are com-mercially feasible.
REFERENCES
1. Lin Y-B, Pang A-C. Wireless and Mobile All-IP Networks. Wiley Publishing, Inc.: 2005. ISBN: 0-471-74922-2
2. ETSI, Telecommunications and Internet Converged Ser-vices and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture, ETSI ES 282 001Release 3.4.1, 2009.
3. British Telecom. www.ofcom.org.uk/consult/condocs/ ngndevelopments/summary.
4. Korea Telecom. www.aptsec.org/meetings/2005/ ASTAP10/WS-docs/ASTAP05-WS.IP & NGN-26 NGN-Implementation KT-Korea.ppt #270,7,Conclusion. 5. Schulzrinne H, Rao A, Lanphier R. Real Time Streaming
Protocol (RTSP), RFC2326, April 1998.
6. Schulzrinne H, Frederick R. RTP Payload for DTMF Dig-its, Telephony Tones and Telephony Signals, RFC2833, May 2000.
7. Wang P. Extended MRBT service, IP.com’s Prior Art Database, 2006.
8. Rosenberg J, Schulzrinne H. An Offer/Answer Model with the Session Description Protocol (SDP), RFC 3264, June 2002.
AUTHORS’ BIOGRAPHIES
Gong-Da Fan received his B.S. degree and M.S. degree in the Depart-ment of Information ManageDepart-ment from National Chi-Nan University (NCNU), Taiwan. He joined Broadband Network Lab., Telecommunication Laborato-ries, Chunghwa Telecom Co., Ltd., in October 2006. He has been working on network management, software design, system interoperability test, and NGN/IMS network.
Chao-Chun Huang received a B.S. degree in Computer and Information Science from National Chiao-Tung University (NCTU) and a M.S. degree in Computer Science and Informa-tion Engineering from NaInforma-tional Central University (NCU), Taiwan. He started his industry career as the Assistant Researcher in Broadband Network Lab., Telecommunication Laboratories, Chunghwa Tele-com Co., Ltd. He has been working in service design and prototype implementation, system interoperability, signal-ing and protocols testsignal-ing and validation, such as Softswitch and NGN/IMS.
Yi-Bing Lin is a Dean and Chair professor of College of Computer Sci-ence, National Chiao Tung University (NCTU). He is a senior technical edi-tor of IEEE Network. He serves on the editorial boards of IEEE Transactions on Vehicular Technology. He is Gen-eral or Program Chair for prestigious conferences including ACM MobiCom 2002. He is Guest Editor for several journals including IEEE Transactions on Computers. Lin is the author of the books Wireless and Mobile Network Architecture (Wiley, 2001), Wireless and Mobile All-IP Networks (John Wiley, 2005), and Charging for Mobile All-IP Telecommunica-tions (Wiley, 2008). Lin received numerous research awards including 2005 NSC Distinguished Researcher, 2006 Aca-demic Award of Ministry of Education, and 2008 Award for Outstanding Contributions in Science and Technology, Executive Yuen. He is in the advisory boards or the review boards of various government organizations including Min-istry of Economic Affairs, MinMin-istry of Education, MinMin-istry of Transportation and Communications, and National Sci-ence Council. He is a member of board of directors, Chunghwa Telecom. Lin is AAAS Fellow, ACM Fellow, IEEE Fellow, and IET Fellow.
Chung-Shih Tang received his B.S. and M.S. degrees in Industrial Engi-neering from National Tsing Hua University (NTHU), Taiwan, in 1988 and 1990, respectively. Then he joined Telecommunication Laboratories of Ministry of Transportation and Com-munications, which became a research center of Chunghwa Telecom Co., Ltd., since 1996. Now he is a Researcher in Broadband Net-work Lab., Net-working on NGN/IMS netNet-work technology and service innovation.
Chin-Ywu Twu graduated from Department of Computer Engineering of University of Southern California (USC). He joined Taiwan Chunghwa Telecommunication Laboratories in January 1991. He has worked
on CAD/CAM in Experimental
Workshop and Intelligent Network Technology in Network Plan Lab. And currently he, a Senior Researcher, works on NGN/IMS network and service technology in Broadband Network Lab.
Yun-Hui Wen graduated from Depart-ment of Electrical Engineering of Syracuse University (SU). He joined Taiwan Chunghwa Telecommunica-tion Laboratories in May 1998. He has worked on Intelligent Network Technology in Network Plan Lab and value-added service development in Multimedia Applications Lab. And currently he, an Associate Researcher, works on NGN/IMS network and service technology in Broadband Network Lab.
