Authorized licensed use limited to:University ofTexas atArlington. Downloaded on April 24,2010 at22:39:32 UTC from IEEE Xplore. Restrictions apply. 2009 MAY/JUNE M services. IPTV mobile for QoS seamless to support scheme signaling efficient an propose also authors the adoption, widespread technology’s the in QoS of and field, the role critical the Given services. in IPTV mobile enhancing to challenges approaches technical related status, standardization’s IPTV mobile reliability. discuss and authors The networks. mobile to interactivity, services those extends IPTV security, Mobile experience, of quality of quality (QoS), support service to managed networks IP-based over delivered data, and TV, as such graphics, services, video,as audio, is multimedia text, defined IPTV and QoS Support Approaches, Challenges, Standards, IPTV Mobile took over the IPTV standardization role. standardization IPTV the over took (IPTV-GSI) Initiative Standards Global IPTV the 2008, January in Then, tions. organiza development standards and other groups study ITU-T of work existing the account into took which IPTV, called FG group focus a formed 2006 in T ITU- the standards, IPTV of global ment users. to mobile ser vices IPTV many short, extends IPTV In mobile interactivity. and mobility, security, (QoE), experience of quality and (QoS) the service of with quality of support networks IP-based through graphics, and text, audio, video, nals, To coordinate and promote develop promote and coordinate To ei tafc sc a T sig TV multi as such receive traffic, media users and mobile transmit lets IPTV obile - - - - - T- dfns h IT architecture IPTV the defines ITU-T Approaches and Architectures future work, we’ll incorporate the NGN- incorporate work, we’ll future In services. for IPTV mobile chitectures ar non-NGN-based address we this article, In next- architectures. and non-NGN-based into it (NGN)-based generation-network classifies further and a requirement for viewer satisfaction. for viewer a requirement and in the mobile pecially environment, es systems, delivery is video for support critical QoS seamless services. for IPTV mobile QoS support to scheme signaling Addition efficient an propose we challenges. ally, technical and approaches IPTV mobile as well as tion standardiza of IPTV mobile status rent In this article, we describe the cur the describe we article, this In IEEE ©2009 1089-7801/09/$25.00

- - - - - 1

Society Computer IEEE the by Published of Foreign Studies Foreign of University Hankuk Jeong Seong-Ho Electronics Samsung Park Soohong

23 IPTV IPTV

Network Sender Receiver Wired equipment Wireless Digital Video Broadcasting’s Convergence of Broadcast and Mobile Services (DVB-CBMS;

• Non-NGN-based architecture www.dvb.org/groups_modules/technical Network Sender • NGN IMS-based architecture _module/tmcbms), DVB IP Infrastructure (DVB- Wireless equipment • NGN non-IMS-based architecture IPI; www.dvb.org/groups_modules/technical_ module/tmipi), and the World Digital Multimedia The network includes IPTV access routers or Broadcasting (WorldDMB) Forum (www.world source generator points of attachment Mobile terminal dab.org) are key standards groups in this area. DVB-CBMS is developing protocol specifications Figure 1. Mobile IPTV architecture. In the first stage, a wireless for bidirectional, IP-based broadcasting over interface enables communication between the access network and DVB-H, the specification for bringing broadcast the receiver. In the second stage, the wireless section extends to the services to battery-­powered handheld ­receivers sender, giving the sender’s and receiver’s devices mobility. (NGN: (www.dvb.org/groups_modules/technical next-generation network; IMS: IP-based Multimedia Subsystem) _module/tmh). DVB-IPI specifies technologies on the interface between an IP network and retail receivers, enabling the end user to receive DVB based mobile IPTV approach, which considers services over IP-based networks. The WorldDMB the IP-based Multimedia Subsystem (IMS). Forum is enhancing and extending Eureka 147, Figure 1 shows an overall mobile IPTV originally developed for digital radio applica- architecture. In the first stage, a wireless in- tions, to support IP-based and video services. terface enables communication between the Although this mobile TV plus IP approach access network and the receiver (mobile IPTV is classified as mobile IPTV, the use of broad- terminal). Because IPTV is access agnostic ac- casting networks might cause loss of IP indi- cording to ITU-T’s definition, various wire- viduality, such as point-to-point interactive less access networks, such as wireless LAN communication and personalized services. (WLAN),2 WiMAX,3 and cellular networks,4 can exist. Each wireless technology has its IPTV Plus Mobile own characteristics, which service providers Is networked TV the future of television? A lot should carefully consider when deploying mo- of services similar to IPTV are already on the bile IPTV. market, and more are in progress. Telco giants In the second stage, the wireless section ex- say IPTV is the new source of revenue. IPTV tends to the sender so that both the sender’s services originally targeted fixed terminals and receiver’s devices can be mobile. Moreover, such as set-top boxes, but mobility possibili- user-created content is becoming more popular ties have grown out of the fixed mobile con- in the Internet community; any mobile user can vergence trend. create IPTV content and provide it to other mo- The Alliance for Telecommunications In- bile IPTV users. dustry Solutions (ATIS) in the US and ITU-T Some of the approaches for mobile IPTV ser- IPTV-GSI internationally are primary standards vices we’ll discuss in this section are already in organizations in the IPTV plus mobile field. use. From the users’ perspective, no big func- Mobile IPTV specifications development is a tionality differences exist among the approach- relatively new effort. ITU-T FG IPTV has col- es, but the detailed technologies differ. lected requirements for IPTV, including mobile IPTV. ATIS, however, has yet to show interest in Mobile TV Plus IP mobility support. The main problem of this ap- Using traditional digital broadcast networks, proach is slow development, even for fixed wire- mobile TV plus IP delivers IP-based audio, less IPTV only. video, graphics, and other broadband data to mobile users.5 This approach aims to build an Cellular environment in which stable broadcasting facil- The Open Mobile Alliance’s Broadcasting Work- ities and content combine with diverse Internet- ing Group (OMA BCAST) is working on technol- based services. Additionally, mobile TV plus IP ogies for providing IP-based broadcast ser­vices uses wide area wireless networks, such as cel- in the mobile environment. The technique’s lular networks, to support interactivity. main goals are to define an end-to-end frame-

24 www.computer.org/internet/ IEEE INTERNET COMPUTING

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply. Mobile IPTV

work for mobile broadcast and compile the set of the mobile terminal’s screen size when sending necessary enablers. A key feature of the cellular a video stream. approach is the bearer agnostic, which means it can adopt any broadcast-distribution network Bandwidth as its transport means. Although the wireless link’s effective band- OMA BCAST currently applies only to mo- width is growing rapidly, it won’t be suffi- bile terminals, but its specification might ex- cient for mobile IPTV until the 4G wireless pand to cover fixed terminals. network’s full deployment. Only then will the wireless link bandwidth become broad enough Internet to accommodate high-definition video ser- A product of the entertainment business, In- vices. Even when the 4G wireless network is ternet or Web TV comprises numerous Internet available, the bandwidth might not be suf- video services worldwide. With the Internet ap- ficient if bandwidth-greedy services such as proach, the model form depends on the business ultra-definition (UD) video emerge and the types and infrastructures it will support. number of users increases rapidly. The wire- Anyone can use this approach to play a role less link will always have less bandwidth than in the value chain; the user can be a content the wired link, and the number of high-band- provider, service provider, or consumer. This width applications will continue to increase. flexibility enables a universe of highly diversi- Therefore, bandwidth-aware solutions are al- fied and dynamically independent production, ways desirable for mobile IPTV services in the as well as a global reach. wireless environment. However, QoS isn’t guaranteed because the approach is based on the best-effort service Wireless Link model. Nevertheless, through its rapid adapta- The wireless link is vulnerable to physical fac- tion to customer needs, the Internet approach tors. When the mobile IPTV terminal moves might become dominant in the near future. around, packets can suffer quality degradation from such factors as shadowing and fading as Technical Challenges they travel through wireless channels. Even Mobile IPTV services must overcome several when mobile IPTV terminals are stationary, obstacles to a successful launch and wide use. temporal reflectors and obstacles in the wire- Because of a lack of consensus, we don’t pres- less environment can affect the received sig- ent detailed solutions to each technical issue in nal quality and cause burst packet losses. Such this section. quality degradation is intrinsic in the wireless Mobile IPTV implies at least one wireless link. So, the mobile IPTV servers and terminals link between the source, such as a streaming should react adaptively to the wireless link’s server, and the destination, such as a mobile varying conditions. terminal. Therefore, most of the technical chal- lenges are related to the wireless link. Service Coverage The purpose of mobile IPTV devices is to pro- Terminal Capabilities vide anytime, anywhere access to IPTV servic- Moving IPTV content from a standard home es. However, it’s virtually impossible to deploy display to a mobile terminal with a small screen a wireless network that covers all geographi- raises various concerns. Compared to fixed ter- cal areas with no dead spots. Enabling verti- minals, mobile terminals have limited capa- cal handover between heterogeneous wireless bilities. This trait primarily affects portability, networks — for example, WiMAX, WLAN, and which leads to a small video display, low-power 4G networks — can resolve service-coverage processor (because of a small battery), limited limitations. Vertical handover occurs when a storage, and so on. Being lightweight is also an network node changes the type of connectivity important feature of a mobile terminal. it uses, usually to support node mobility. But, These capability limitations mean that the technical challenges of seamless handover only a restricted set of technologies is possible remain, such as how to sustain mobile IPTV through mobile IPTV solutions. For example, services while moving across different wireless the content-­providing server should consider networks without any significant performance

MAY/JUNE 2009 25

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply. IPTV

degradation and how to select the best network User interface is another obstacle to a suc- among them for mobile IPTV. cessful mobile IPTV business. The small mo- bile device form hinders development of a Dynamic Environment fancy user interface. Mobile IPTV growth Unlike the wired channel’s more static proper- will require a highly creative and innovative ties, the wireless channel’s characteristics vary human-­machine interface suitable for the mo- because of the effects of fading, shadowing, re- bile device. flection, refraction, scattering, diffraction, and Watching live TV while mobile is one of interference. Vertical handover, which changes mobile IPTV’s most attractive features. So, the media access control and physical layers access to popular real-time TV programs and (MAC/PHY), available bandwidth, and, possi- rich content should be provided. Content tai- bly, IP address, might also greatly affect mobile lored for mobile environments, such as small IPTV service quality. Therefore, because most of screen size and random and short watching the wired network solutions won’t work proper- time, is key. ly, mobile IPTV should employ wireless-specific and mobility-aware technologies. Standardization Status The standards groups in mobile IPTV-related Scalable Video Coding standardization include DVB-CBMS, OMA- The scalable video coding (SVC) technology BCAST, Third Generation Partnership Project lets the system consider the network’s terminal Multimedia Broadcast Multicast Service, and types and available bandwidth. Although SVC WiMAX-Multicast Broadcast Service. For uni- enables scalable representation of video content fied mobile IPTV services, these organizations with high coding efficiency, it’s difficult to per- should harmonize their efforts. form real-time encoding because of the SVC en- Currently, ITU-T is trying to coordinate coders’ complexity. Additionally, further study ­IPTV-related standardization activities to devel- is needed on how to best control the SVC rate op global IPTV standards for the market. Table 1 according to network resource availability. shows the ITU-T FG IPTV requirements directly related to mobile IPTV.6 After FG IPTV activi- QoS and QoE ties closed, IPTV-GSI formed to promote greater For high-quality mobile IPTV services, support- efficiency in producing IPTV recommendations. ing key QoS factors, such as packet loss, band- width, delay and jitter, and packet-error ratio, is QoS Support important. Mobile IPTV delivery systems must QoS support is crucial for successful mobile be able to handle such factors through careful IPTV business. In the mobile environment, mo- system design (for example, over-provisioning bile IPTV services can frequently suffer from an or use of NGNs), careful traffic control in the unreliable network connection and insufficient network (such as traffic engineering and ser- bandwidth. Thus, service continuity requires an vice differentiation), and optimized buffering awareness of varying wireless-link conditions, and error-correction at the receiver. In particu- such as shadowing and fading. lar, reacting quickly to varying conditions in We propose an efficient signaling scheme to the wireless link is critical. support QoS for seamless mobile IPTV service. Supporting user-perceived QoE by provid- The scheme defines a new option in high-layer ing a resource-aware mobile IPTV service is protocols for carrying link characteristics infor- also important — for instance, increasing or de- mation (LCI). Ji Zhang and colleagues used the creasing the transmission rate according to the LCI as an extension of TCP Quick-Start to let end user’s expectation. nodes quickly adjust their sending rate for ongo- ing connections according to the link condition.7 Business Issues For high-layer protocols for mobile IPTV The major business concern regarding mobile services, we selected the Datagram Conges- IPTV is the possibility of low consumer demand tion Control Protocol (DCCP) and Real-Time for mobile IPTV viewing on tiny screens. Wide Transport Protocol/Real-Time Transport Con- adoption requires a business model for making trol Protocol (RTP/RTCP). We extended these mobile IPTV services attractive to users. protocols to provide a reliable means for deliv-

26 www.computer.org/internet/ IEEE INTERNET COMPUTING

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply. Mobile IPTV

Table 1. Mobile IPTV requirements. Feature Optional Content management Support bandwidth request and congestion control capabilities. IPTV terminal device Have the capability to provide information regarding its bandwidth availability. IPTV architecture Support signaling capabilities for transmitting bandwidth-related information. IPTV architecture Use bandwidth-related information to determine the appropriate content coding means to deliver the content. Feature Recommended IPTV content Deliver content in several optional versions to be selected according to the capabilities (such as access rate, resolution, and supported formats) of the IPTV terminal receiving the content. IPTV architecture Allow delivery of IPTV services over different access networks, such as cable, optical, xDSL, and wireless.­ IPTV architecture Allow delivery of IPTV services to any IPTV terminal device, such as a mobile phone, PDA, or set-top box. IPTV architecture Adapt dynamically to change in wireless networks characteristics, such as bandwidth and packet-loss ratio, when the system delivers the service over a mobile network. IPTV architecture Support capabilities for the interoperability and user mobility between IPTV networks, allowing customer access to IPTV services whether or not the customer is mobile. IPTV architecture Allow service continuity over heterogeneous networks. IPTV architecture Support an IPTV terminal with the capability to choose the desired content format if multiple formats are available. IPTV architecture Support the ability to identify wireless-network characteristics information that the IPTV terminal sends.

ering the LCI information from a mobile IPTV terminal to an IPTV content provider. The IPTV content provider can quickly adjust its sending rate for the ongoing session accord- Low bandwidth Internet ing to the bandwidth information contained network (10 Mbps) in the LCI option, as Figure 2 illustrates. Our scheme can apply to both horizontal and ver- tical handovers.

Using a DCCP LCI Extension Figure 3 illustrates the procedure for DCCP mo- High bandwidth Low bandwidth bility support for QoS-enabled mobile IPTV.8 network (100 Mbps) network (10 Mbps) After handover, the mobile IPTV terminal Movement LCI delivery sends a DCCP-Request message with an Attach- ­Gencon (generalized connection) option to the Figure 2. Link characteristics information (LCI) delivery. The LCI IPTV content server. The system uses the Gen- delivery mechanism for mobile IPTV during a vertical handover. con to implement the subprotocols that create When the mobile IPTV terminal senses a significant change in the and update generalized connections.9 wireless-channel capacity, the higher-layer protocol message carries For LCI delivery, we define a new DCCP LCI the LCI. option included in the option field of the DCCP- Request and other related messages. This option can include parameters such as network type, Detailed signaling procedure. The signaling interface type, and bandwidth. procedure for message exchange after hand­ The system uses the DCCP LCI option in the over begins with the mobile IPTV terminal DCCP-Request message with the Initiate-Gencon collecting information on the new wireless option for opening an early session, and also in link’s characteristics and including it in the the DCCP-Request message with the Attach- LCI option. Then, the system includes the LCI Gencon option for handover. The system can option in the DCCP-Request with the Attach- also use it in the DCCP-Data message when the Gencon option and sends it to the IPTV con- wireless-link status changes abruptly. tent server.

MAY/JUNE 2009 27

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply. IPTV

Mobile IPTV terminal Content server

DCCP-Request and after employing the LCI option. The Linux kernel (version 2.6.16) embodies DCCP, which 10 DCCP-Response uses congestion control identifiers (CCIDs) 2 and 3.11 We used CCID 2 and detailed scenarios for performance evaluation and comparison. DCCP data streaming After a mobile IPTV terminal establishes a communication channel with the IPTV content server using the DCCP protocol, the IPTV con- Handover period tent server sends data to the mobile IPTV ter- minal. After some time, the mobile IPTV device performs the handover to move to a new access DCCP-Request with LCI option network. The types of movement include WLAN- to-LAN (the low- and high-bandwidth networks DCCP-Response in Figure 2, respectively) and LAN-to-WLAN. We measured the performance in all cases. DCCP-Ack Figure 4a shows data throughput from a case in which the mobile IPTV terminal moves from DCCP data streaming according to LCI a high-bandwidth network to a low-bandwidth network. Data throughput equals the amount of data received for stabilization time divided Figure 3. Signaling process for link characteristics information (LCI) by stabilization time. As the figure shows, the delivery using the Datagram Congestion Control Protocol. Using the data throughput measured without using the information, the IPTV content server can adjust the sending rate LCI option is about 1.87 megabits per second, according to the network condition (for example, handover). and the data throughput measured using the LCI option is about 6.64 Mbps. Using the LCI, the stabilization time decreases, and the data Upon receiving the DCCP-Request message, throughput increases more than three times, as the IPTV content server extracts the Gencon-ID Figure 4 shows. included in the message and prepares for data communication with the mobile IPTV terminal. Using an RTP/RTCP LCI Extension During this time, the IPTV content server ana- To provide the mobile IPTV user with seamless lyzes the mobile IPTV terminal’s network infor- services, this approach newly defines the trans- mation contained in the LCI option. mission of RTP/RTCP feedback (FB) messages, Based on the LCI option’s content, the IPTV including the network-link characteristics. We content server can determine the congestion- provide QoS support at the application level us- window size that early data communication ing the RTCP FB message, which is designed to used since the handover by comparing it with transport application-defined information (see the standard congestion-window size. After data Figure 5). communication begins, the congestion-window The mobile IPTV terminal notifies the server size increases continuously until it reaches the of its network-link characteristics via the RTCP optimal size. FB message if either the network-link charac- Using the result from the LCI analysis, the teristic is changed without handover or hand­ application adjusts the sending rate. For exam- over occurs to another network (either vertical ple, the application increases the sending rate or horizontal). The mobile IPTV server should if the new network’s link status is better than adapt the transmission behavior according to the previous one, which results in increased the current link condition. throughput. The application decreases the send- ing rate if the new network’s link status is worse Detailed signaling procedure. The LCI includes the than the previous one, which results in reduced link characteristics of the current network, where packet loss. the mobile IPTV terminal is attached, or the new network, where the mobile IPTV terminal will Performance evaluation and comparison. We move. The RTCP FB message carries the LCI. evaluated QoS performance in two cases: before LCI transmission involves four general steps.

28 www.computer.org/internet/ IEEE INTERNET COMPUTING

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply. Mobile IPTV

8 4,000

7 3,500

6 3,000

5 New mechanism 2,500 New mechanism Existing mechanism Existing mechanism 4 2,000

3 1,500 Milliseconds Mbits per second 2 1,000

1 500

0 0 135791113151719 135791113151719 (a) Experimental trials (b) Experimental trials

Figure 4. Comparing data throughput and stabilization time using the Datagram Congestion Control Protocol. (a) Data throughput increases and (b) stabilization time decreases.

First, using a low-layer (layer 2) triggering Mobile IPTV terminal Content server event, the mobile IPTV terminal detects the link status on the basis of the number of users in SIP: Invite the link and handover occurrence. For instance, SIP: 200 OK the increased number of users might cause in- SIP: ACK creased traffic and therefore reduce the avail- able network bandwidth. Handover to another RTP/RTCP message exhange network might also cause a change in the link characteristics. The system detects these link characteristics at the low layer (layer 2) and de- Handover period livers the information to the high layer, RTCP, as an event. Next, upon receiving the event, RTCP sends RTCP FB with LCI option the RTCP FB message containing the LCI to RTCP FB Reply the IPTV content server. In case of handover, the information will be the new network’s link SIP: Reinvite characteristics. Then, upon receiving the RTCP SIP: 200 OK FB message, the IPTV content server prepares SIP: ACK to adjust its transmission behavior accord- ing to the link characteristics of the network RTP data streaming according to LCI where the mobile IPTV terminal is attached and sends a response to indicate that the prep- aration is complete. Figure 5. Signaling process for link characteristics information (LCI) Finally, for the sake of reliable QoS, espe- delivery using Real-Time Transport Protocol/Real-Time Transport cially in case of handover, the mobile IPTV ter- Control Protocol. Using the information, the IPTV content server minal moves to another network after receiving can adjust the sending rate according to the network condition (for a response from the IPTV content server. This example, handover). can reduce the signaling and data transmis- sion delay because the content server can adjust the sending rate in advance of handover. If the and the IPTV content server establish a session response is delayed, the mobile IPTV terminal using the Session Initiation Protocol (SIP). The performs handover first and then retransmits IPTV content server’s initial transmission rate the RTCP FB message. is unchanged until the mobile IPTV terminal notifies the server of its changed link status. To Performance evaluation and comparison. In verify LCI delivery’s usefulness, we measured our implementation, the mobile IPTV terminal the following two parameters:

MAY/JUNE 2009 29

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply. IPTV

60 New mechanism 7 50 Existing mechanism 6

40 5 4 30

oughput (Mbps) 3 et-loss ratio (%) 20 2 Pack

10 Data thr New mechanism 1 Existing mechanism 0 123456789101112131415 0 123456789101112131415 (a) Experimental trials (b) Experimental trials

Figure 6. Link characteristics information (LCI) delivery’s value. We measured (a) packet-loss ratio using the Real-Time Transport Protocol (RTP) and (b) data throughput using RTP with and without LCI notification.

• Packet-loss ratio (%) = (the number of pack- ure 6 shows, the packet-loss ratio drops to 1.23 ets the sender transmits − the number of percent in WLAN, and the data throughput in- packets the receiver receives) / the number creases to 6.43 Mbps in LAN. of packets the sender transmits) × 100. • Data throughput (bits per second) = (the number of packets the receiver receives × echnical issues and work items remain for the number of bits per packet) / the measure- T mobile IPTV standardization. First, although ment time in seconds). our proposed mechanism, based on DCCP and RTP/RTCP options, works well in the mobile en- We measured the packet-loss ratio when the vironment, it’s not currently interoperable with receiver (mobile IPTV terminal) moved from systems that implemented the DCCP and RTP/ LAN to WLAN, and the data throughput when RTCP specifications. Wider use of the LCI option the receiver moved in the reverse direction — will require its standardization, particularly for that is, during handover from WLAN to LAN. DCCP and RTP/RTCP. Second, as mobile IPTV Because measuring handover performance isn’t standardization accelerates, the requirements this experiment’s focus, we ignored packets lost might change. during handover. We measured the packet-loss Other more general suggestions for future ratio and data-throughput parameters 15 times work include defining a common framework in two cases: handover without notification of for obtaining the dynamic network link char- LCI and handover after transmitting LCI. Figure acteristics information from various mobile 6 shows the measurement results. IPTV devices. Also, further experiments should For RTP/RTCP implementation, we used compare vertical handover scenarios, such as Vovida SIP-1.5.0, which comprises SIP and RTP/ WiMAX and WLAN, WLAN and cellular, and RTCP. In this implementation, the session is WiMAX and cellular. established between the sender (IPTV content Given the link information in the LCI op- server) and the receiver (mobile IPTV terminal) tion, the mobile IPTV content server must use through SIP. We added the mobility support a scalable media format, such as H.264 Scal- function to the existing implementation. able Extension or MPEG Scalable Video Cod- With the existing mechanism in which the ing. We used our own scalable solution based mobile IPTV terminal doesn’t send its LCI, the on MPEG-4, which is composed of frames. packet loss is approximately 40 percent when Finally, our experiments focused on measur- the terminal moves to WLAN from the higher- ing packet loss and throughput performance. speed LAN. When the mobile IPTV terminal Future studies should consider other perfor- moves to the higher-speed LAN from WLAN, mance aspects, such as latency. Moreover, data throughput is about 4.22 Mbps, which there should be a way to provide protection is lower than the available capacity. Our pro- from misbehaving users reporting unneces- posed mechanism resolves the problems of high sary network information to the mobile IPTV packet loss and low data throughput. As Fig- content server.

30 www.computer.org/internet/ IEEE INTERNET COMPUTING

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply. Mobile IPTV

Acknowledgments the Telecommunications Technology Association of We thank Cheolju Hwang at Samsung Electronics for his Korea. Contact him at [email protected]. contribution to the mobile IPTV standardization in Korea. Hankuk University of Foreign Studies Research Fund of Seong-Ho Jeong is a professor in the Department of Infor- 2009 supported this work. mation and Communications Engineering at Hankuk University of Foreign Studies. His research interests References include mobile multimedia communications systems 1. FG IPTV-DOC-0181, IPTV Architecture, Int’l Telecom- and applications and next-generation networks. Jeong munication Union, work in progress, 2007. has a PhD in electrical and computer engineering 2. I. Djama and T. Ahmed, “A Cross-Layer Interworking from the Georgia Institute of Technology. He’s vice of DVB-T and WLAN for Mobile IPTV Service Deliv- chairman of ITU-T SG16, a leading study group in ery,” IEEE Trans. Broadcasting, vol. 53, no. 1, 2007, pp. multi­media services, including IPTV. Contact him at 382–390. [email protected]. 3. F.E. Retnasothie, “Wireless IPTV over WiMAX: Chal- lenges and Applications,” Proc. IEEE Annual Conf. Wireless and Microwave Technology (WAMICON 06), IEEE Press, 2006, pp. 1–5. 4. F. Hartung, “Delivery of Broadcast Service in 3G Net- works,” IEEE Trans. Broadcasting, vol. 53, no. 1, 2007, pp. 188–196. 5. C. Carlsson and P. Walden, “Mobile TV — To Live or Die by Content,” Proc. 40th Ann. Hawaii Int’l Conf. System Sciences (HICSS 07), IEEE CS Press, 2007, pp. 51–60. 6. FG IPTV-DOC-0147R1, IPTV Service Requirements, Int’l Telecommunication Union, work in progress, 2007. 7. J. Zhang et al., “TCP Quick-Adjust by Utilizing Explicit Link Characteristic Information,” Proc. 22nd IEEE Ad- vanced Information Networking and Applications, IEEE CS Press, 2008, pp. 1291–1298. 8. L.M. Sales et al., “An Experimental Evaluation of DCCP Transport Protocol: A Focus on the Fairness and Hand- off over 802.11g Networks,” Proc. 5th IEEE Consumer Comm. and Networking Conf., IEEE CS Press, 2008, pp. 1149–1153. 9. E. Kohler, “Datagram Congestion Control Protocol Mo- bility and Multihoming,” IETF Internet draft, work in progress, Jan. 2006. 10. S. Floyd and E. Kohler, Profile for Datagram Congestion The magazine of computational tools Control Protocol (DCCP) Congestion Control ID 2: TCP- and methods for 21st century science. like Congestion Control, IETF RFC 4341, Mar. 2006; www.ietf.org/rfc/rfc4341.txt. 11. S. Floyd, E. Kohler, and J. Padhye, Profile for Datagram 2009 Peer-reviewed topics Top-flight departments in each issue! Congestion Control Protocol (DCCP) Congestion Con- Jan/Feb Reproducible Research Book Reviews Scientific trol ID 3: TCP-Friendly Rate Control (TFRC), IETF RFC Mar/Apr Computational Astrophysics Computer Programming Simulations Technologies 4342, Mar. 2006; www.ietf.org/rfc/rfc4342.txt. May/Jun New Directions Jul/Aug Cloud Computing Education Views and Opinions Sep/Oct Petascale Computing News Visualization Corner Soohong Park is a standard architect at Samsung Electron- Nov/Dec Software Engineering ics and a PhD candidate in computer engineering at Kyung Hee University. His research interests include MEMBERS $47/year mobility, Internet applications, and networking. He for print and online chairs the following IPTV-related standards groups: IETF 16ng Working Group, W3C Media Annotation Subscribe to CiSE online at http://cise.aip.org and www.computer.org/cise Working Group, and Mobile IPTV Working Group in

MAY/JUNE 2009 31

Authorized licensed use limited to: University of Texas at Arlington. Downloaded on April 24,2010 at 22:39:32 UTC from IEEE Xplore. Restrictions apply.