- Open Access
The multicast system for seamless live multimedia in WLAN
© Woo and Kim; licensee Springer. 2013
- Received: 22 March 2013
- Accepted: 4 October 2013
- Published: 17 October 2013
This paper proposes the multicast system for seamless live multimedia in a wireless network. The multicast technique for live multimedia and a part of handover mechanism are performed on the buffered multicasting/switching agent (BMSA) in a wireless local area network (WLAN). The rest of the handover mechanism is performed on access points (APs). This paper uses a new Internet Protocol (IP) header that is composed of three AP numbers (AP_#s) and 1-bit overwrite bit (OB) to perform seamless service. The three AP_#s support a smooth handover for solving the cutoff service when mobile nodes (MNs) move among other APs in WLAN. The overhead for a new IP header (2 bytes long) is negligible in comparison with multimedia service, and the overhead for the multicast group address (MGA) packet that is used in the transmission of MGA is only 11 bits. The MGA packet is composed of two AP_#s, an overwriting group address (OGA) bit, and MGA. We confirmed that the proposed multicast system can decrease the number of channels required, the delay of service, and the possibility of packet duplication because multicast is not provided on the multimedia server but on the BMSA in WLAN.
The multimedia service on the Internet has many problems including insufficient network bandwidth in a wire/wireless network and an excessive load of the server. Especially, these problems are critical in a wireless network. Many technologies such as multicast, web caching, and content distributive network (CDN) have been studied to solve these problems, but they have their own problems too [1–3].
Nowadays, a smooth multimedia service is one of the most important services in a wire/wireless network. Providing multimedia service in a wireless local area network (WLAN) has many problems including cutoff service and reconnection to the server caused by the movement of mobile nodes (MNs) such as tablet PCs (iPad and Galaxy tab), laptop computers, and personal digital assistants (PDAs) [4, 5]. Even though the MNs are moving among access points (APs) in WLAN, seamless multimedia services have to be achieved.
This paper presents a seamless multimedia system that can reduce the number of service channels to overcome deficient wireless network bandwidth, alleviate the load of the server, and prevent reconnection to the server and cutoff service according to the MNs' movement. For solving these problems, this paper adopts the multicast technique to reduce the number of channels of a server and the service delay. It also adopts handover mechanism using AP identification numbers (AP_#s) as the Internet Protocol (IP) header to prevent cutoff service and reconnection caused by the MNs' movement [6, 7].
This paper uses the buffered multicasting/switching agent (BMSA) to perform multicast in WLAN. The BMSA and AP perform handover mechanism using a 2-byte-long IP header that is made up of three AP_#s and overwrite bit. Because the multicast technique is not provided at the server on the Internet but on the BMSA in WLAN, the delay of multicasting service and the duplication of multicast packet can be reduced.
In the case of multicast, we confine our interest to live multimedia such as news, public TV programs, and sports events except on-demand services, but in the case of unicasting, we study all the multimedia programs whether they are live or not.
The rest of this paper is as follows: Section 2 describes the structure and operation of a seamless live multimedia system and explains the proposed multicast and handover mechanism using BMSA applied for this system in WLAN. Sections 3 and 4 deal with the algorithm and the results of the simulation for the proposed system, respectively. Finally, we discuss our conclusions in Section 5.
Furthermore, along with AP, the BMSA provides a smooth handover mechanism that prevents reconnection to the server caused by cutoff service when MN moves among APs. Therefore, the BMSA has to possess a MG table for multicast and an AP:MNs mapping table to indicate that MNs are on the coverage of a certain AP. The BMSA can switch the live multimedia streams transmitted from the server to the corresponding APs using the MG table and AP:MNs mapping table.
The AP assigns an IP address to MNs through DHCP generally. MNs are reassigned a new one whenever they travelling among APs. Thus, MNs have to reconnect to the server to sustain service when they are connected to other APs. In this paper, however, the AP assigns 2-byte-long AP_# fields as an IP header and IP address only if MN enters WLAN for the first time. After the AP assigns them to MN, the MN receives only an AP_# except IP address when the MN moves to other APs. Also, only 11 bits is added to the MGA packet in comparison to the traditional multicast. Thus, our proposed mechanism performs a seamless live multimedia service using the MGA packet and the AP_#s added as an IP header .
2.1. The structure of IP header
The proposed system uses three AP_# fields (2 bytes long) as a new IP header in addition to the IP address. Only the AP that was accessed for the first time when MNs enter into the WLAN can assign an IP address with an AP_# field. The other APs except the first accessed AP never assign an IP address to the MNs when they are moving among other APs. In this case, the APs generate their own AP_# only within AP_# fields. The IP address and AP_# assigned for the first time remain unchanged even though the MN travels among APs except the case that MN receives a MGA packet from the BMSA [5, 6]. Thus, the two AP_#s of three AP_# fields are changed according to the MN's movement among APs. As mentioned earlier, we confine our interest for multicast to live multimedia programs and not on-demand ones. A study on using the proposed multicast system for all multimedia including on-demand services such as VOD, MOD, and NOD is in progress.
The third row of Figure 2a shows that the MNi moved to AP_#23 from AP_#12, and the first AP_#12 and IP address (IP_#32) never changed according to the MNi's movement. Then the fourth row of Figure 2a shows that the MNi moved to AP_#23 and AP_#07 from AP_#12 sequentially. AP_#23 and AP_#07 assign only their own AP_# to the MNi, and they do not reassign an IP address even if the MNi enters within their coverage areas. At the moment, AP_#07 sends an IP header with OB = 1 to the BMSA and MNi. The BMSA changes AP:MNs' mapping table to indicate that MNi moved AP_#23 to AP_#07. Then the BMSA switches smoothly the transmission path for successive multimedia streams to AP_#07 for the MNi. As soon as the MNi receives an IP header from AP_#07, it overwrites the second field AP_#23 to AP_#07 and sets to 1 the third AP_# field. The MNi clears OB to 0 (the fifth row of Figure 2a) at the same time. Therefore, Figure 2a explains that multimedia streams requested can be switched smoothly from AP_#12 to AP_#23 and AP_#07 sequentially. In the fifth row of Figure 2a, the third AP_# field (11111) can be reused when the MNi moves AP_#07 to other APs. As shown in Figure 2a, even though the MNi accesses AP_#23 and AP_#07, AP_#12 and IP_#32 assigned by AP_#12 for the first time are never changed.
The 5-bit-long AP_# can manage 31 APs (AP_#00 to AP_#30) in WLAN, and it will be expanded if the number of APs is increased. The length of the three AP_# fields (2 bytes) is negligible in comparison with multimedia streams.
Figure 2b shows the MGA packet that transmits MGA to a number of MNs when they request the same live multimedia. The MGA packet is composed of two AP_# fields, an IP_# field, multicast group address, and overwriting multicast group address (OMGA). The BMSA sends the MGA packet to the MNs through the corresponding APs using AP:MNs' mapping table.
Figure 2b indicates that five MNs are receiving the same MGA (MGA_#005) from the BMSA: two MNs (AP_#12:IP_#012, AP_#05:IP_#005) within the coverage area of AP_#07, another two MNs (AP_#00:IP_#213, AP_#27:IP_#123) within that of AP_#15, and a MN (AP_#30:IP_#087) within that of AP_#23. Thus, Figure 2b shows that five MNs within the range of three different APs (AP_#07, AP_#15, and AP_#23) are grouped with MGA_#005. The length of the MGA packet is 75 bits. Even though it has 75 bits, the added bits in this paper are only 11 bits (two AP_# fields and 1 bit for OMGA). The remaining parts of the MGA packet are the IP address and MGA, and those are the same as the traditional multicast . The OMGA notifies that MNs received the MGA packet and overwrites MGA into the IP address for joining the multicast group.
The parts of Figure 2a, b are used as an AP:MNs mapping table and MG table on the BMSA, respectively. The former uses the third and the first AP_# and IP address of the IP header packet, and the latter uses the second AP_# and MGA fields of the MGA packet. The OMGA = 1 in Figure 2b notifies MNs to join with MGA_#005.
Figure 2c shows the IP header packet with MGA. This packet is used for joining a specific MG. The first row of Figure 2c shows that a MN within the range of AP_#07 joins MGA_#005. Therefore, it can receive multicast live multimedia streams transmitted with MGA_#005. The second row of Figure 2c notifies the BMSA that more than one MNs serviced multicast within AP_#07 are moved to the coverage of AP_#08. The BMSA knows that it has to send the successive live multimedia streams to AP_#08 because a part of MG in AP_#07 already moved to AP_#08. Also, the BMSA sends multimedia streams (MGA_#005) to AP_#07 because other MNs that joined MGA_#005 may reside within AP_#07. However, AP_#07 has to notify the BMSA to stop sending successive multimedia streams with MGA_#005 when MNs do not join the group (MGA_#005 in AP_#07) anymore.
As mentioned above, the assigned AP_# and IP address by AP accessed for the first time are never changed. Also, other APs do not reassign a new IP address to MNs and assign only AP_# that indicates the MNs' movement. The BMSA can switch the successive multimedia streams from old AP to current AP because the BMSA manages the MNs' movement using its AP:MNs' mapping table. Therefore, the proposed mechanism supports a seamless live multimedia service without reconnection to the server and cutoff caused by the MNs' movement among APs.
The multicast technique is initiated on the BMSA when some MNs controlled by the same AP or different APs request the same live multimedia. The BMSA checks whether the live multimedia requested is already servicing. Then the BMSA generates MGA as soon as it receives the same request from other MNs when the requested live multimedia is servicing, and it sends MGA to the MNs requesting service. Next, the BMSA transmits live multimedia streams with MGA to the corresponding APs, and the APs transmit these streams to the multicast group. In traditional papers, the multimedia server makes multicast groups and is in charge of multicast transmission. However, the proposed mechanism performs multicast on the BMSA in WLAN. Thus, the necessary time for multicast transmission is shorter than that for the traditional one. Also, there is scarce data duplication, and the load of all routers on the Internet does not change because the multicast mechanism is performed in WLAN. The BMSA is the core of the proposed mechanism because multicast and a part of handover techniques are performed by the BMSA.
As mentioned in Section 2, the proposed multicast and handover mechanism are simple and effective techniques for live multimedia service in WLAN. The proposed technique can reduce the service delay without cutoff and reconnection according to the MNs' movement among APs and the number of service channels. In Section 3, to provide a seamless live multimedia service using multicast and smooth handover in WLAN, we present the algorithm written as a pseudo-code as follows:
Number of contents
50 ~ 300
Multimedia running time (min)
Request rate (request/min)
10 ~ 50
Number of BMSA
Number of AP
5 ~ 20
where N is the total number of live multimedia serviced in the system. The popularity of live multimedia serviced is represented in i (i = 1, 2,…, N). The probability P N (i) is the conditional requesting probability for each live multimedia item. The α in Equation 1 is a skew factor that indicates the degree of concentration for the MNs' request for live multimedia. We set the skew factor α to 0.75 (0 < α < 1) in order to simulate as closely as possible the real environment. The simulation was executed in Java programming.
This paper presents a combined mechanism that reduces the load of the multimedia server, uses efficiently insufficient network bandwidth, and prevents cutoff service and reconnection to the multimedia server caused by the MNs' movement among APs. The combined technology is made up of multicast for grouping the same live multimedia requests and smooth handover mechanism using AP_#s. The multicast and smooth handover are performed by the BMSA that is the core of the proposed system in WLAN. Therefore, this paper has no burden on the Internet for multicast. The smooth handover is performed using three AP_# fields (2 bytes long). The overhead for the combined mechanism is negligible in comparison with multimedia. The performance for the proposed mechanism enhanced about 10% to 46% for the number of channels required and about 7% to 47% for the delay according to the rates of multicast request and service request. This paper confirmed that the format of the MGA packet and AP:MN mapping table is simpler than references.
- Cai Y, Tavanapong W, Hua KA: A double patching technique for efficient bandwidth sharing in video-on-demand systems. J. Multi. Appl. T 2007, 32(1):115-136.View ArticleGoogle Scholar
- Katsaros D, Manolopoulos Y: Web caching in broadcast mobile wireless environment. IEEE. Internet. Comput 2004, 8(3):37-44. 10.1109/MIC.2004.1297272View ArticleGoogle Scholar
- Zhan-Sheng L, Da-Wei L, Hui-Juan B: CRFP: a novel adaptive replacement policy combined the LRU and LFU policies. In Proceedings of the IEEE 8th International Conference on Computer and Information Technology Workshops, 2008. Sydney: CIT Workshops 2008; 8–11 July 2008:72-79.View ArticleGoogle Scholar
- Puangkor W, Pongpaibool P: A survey of techniques for reducing handover latency and packet loss in mobile IPv6. 2006.Google Scholar
- Gomaa H, Messier G, Davies B, Williamson C: Media caching support for mobile transit users. In Proceedings of the IEEE WiMob 2009. Marrakech; 79-84. 24–26 SeptGoogle Scholar
- Sarddar D, Mani P, Biswas U, Naskar M: Fast handoff mechanism in wireless local area networks (WLAN) using neighbor graph algorithm. Int. J. Comput. Appl. T 2011, 25(9):36-40.Google Scholar
- Seoungyeol L, Iksoo K: Multimedia service using equi-loaded cache in wireless network. J. Korean Ins. Inf. Tech 2012, 10(3):83-90.Google Scholar
- Seoungyeol L, Iksoo K, Yoseop W: A seamless multimedia service in wireless network, in Future Information Technology, Application, and Service. FutureTech 2012. In Proceedings of the 4th International Workshop on IT Service and Cloud Computing (ISCC 2012). Lecture Notes in Electrical Engineering, vol. 164. Edited by: Park JJ(JH), Leung VCM, Wang C-L, Shon T, vol. 2. Dortdrecht: Springer; 2012:477-483. ISBN 2Google Scholar
- Lee S, Kim I, Woo Y: Live-video service using multicast in wireless network. Int. J. Multi. Ubiquitous. Eng 2012, 7(4):17-22.MathSciNetGoogle Scholar
- Daniel M: IP Multicast with Applications to IPTV and Mobile DVB-H. New York: Wiley; 2008.Google Scholar
- Breslau L, Cao P, Phillips G, Shenker S: Web caching and Zipf-like distributions: evidence and implications. In Proceedings of the IEEE INFOCOM ’99. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies, vol. 1. Piscataway: IEEE; 1999:126-134.Google Scholar
This article is published under license to BioMed Central Ltd. This is an open access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.