Related Work and Comparison

24.5.1 Distribution of Multimedia Resources over the Internet

Recently, there has been much emphasis about the possibility of an effective, secure, and reliable access to multimedia information on the Internet from mobile terminals. This has determined the evolution of architectural solutions and technologies based on content. In essence, so-called content networks deal with the routing and forwarding of requests and responses for content using upper-level application protocols. Typically, data transported in content networks amount to images, movies, and songs which are often very large in dimension. ^[24], ^[25], ^[26], ^[27], ^[28] Simply put, a content distribution network (CDN) can be seen as a virtual network overlay of the Internet that distributes content by exploiting multiple replicas. A request from a client for a single content item is directed to a good replica, where "good" means that the item is served to the client quickly compared to the time it would take if that item were fetched from the original server. A typical CDN has some combinations of a content-delivery infrastructure, a request-routing infrastructure, and a distribution infrastructure. The content-delivery infrastructure consists of a set of replicated servers that delivers copies of content to users who issue requests for a certain content. The request-routing infrastructure consists of mechanisms that enable the connection of a given client with a selected replica. The distribution infrastructure consists of mechanisms that copy content from the origin server to the replicas. Finally, a set of software architectural elements constitute the core of the content distribution internetworking (CDI) infrastructure that uses commonly defined protocols to share resources so as to reach to the most-distant participants.

Another important issue related to the design of our wireless Internet application is concerned with the use of P2P technologies. Modern P2P technology embraces a class of applications that take advantage of resources, computing cycles, content, and human presence available at the edges of the Internet. Traditionally, a P2P architecture comprises a decentralized system where all peers communicate symmetrically and exhibit equal roles. ^[29]

It is possible to observe that our designed system resembles traditional P2P systems because it aims at sharing multimedia resources anywhere, anytime. However, because accessing decentralized musical resources from UMTS devices entails operating in an environment of unstable connectivity, our system rests on a centralized entity (the application gateway and the download manager), which operates like a standard wired client with respect to the decentralized replicas. Additionally, our architecture embeds a centralized discovery subsystem that collects the references for a requested song. This centralized architectural solution provides the advantage to permit songs to be shared even in the presence of musical content of large dimensions, as well as with devices with scarce computational capacity.

24.5.2 Wireless Access to the Internet

It is well known that a typical approach to providing wireless access to the Internet amounts to selecting a specific protocol especially designed for the wireless environment. A protocol gateway uses this specific wireless protocol to enable the interaction of the wireless device with the Internet. An example of this type of solution is the Wireless Application Protocol (WAP), incorporating a protocol gateway able to translate requests from the wireless protocol stack to the Web protocols. Moreover, instead of using HTML, WAP uses the Wireless Markup Language (WML), a subset of XML, to recode the Internet content for the wireless device. ^[30]

It is important to observe that the application gateway embodied in our proposed architecture performs different functions with respect to the protocol gateway of the WAP solution. The WAP-based gateway performs translations from HTML-based content to the proprietary format that is understandable at the mobile terminal. Contrariwise, our application gateway does not recode content, but simply provides interconnection between two different CDNs.

Beyond WAP, microbrowser technology continues to move forward with innovative solutions such as, for example, i-mode and the Pixo Internet Microbrowser. ^[31], ^[32] Those protocols are specifically aimed at the wireless Internet, because they recode Internet content for wireless devices and utilize Compact HTML (CHTML) or Extensible Hypertext Markup Language (XHTML) as their markup languages.

Unlike WAP and similar approaches, middleware often offers an alternative to manually replicating content. Its basic purpose is to transparently transcode content on the fly without maintaining Web content in multiple formats. ^[33] The Parlay Project, ^[34] the micro version of Java (J2ME), ^[35] the Mobile Execution Environment (MexE), ^[36] the micro edition of JINI (JMatos), ^[37] Online Anywhere, ^[38] and Proxinet, ^[39] along with the use of the Relational Markup Language (RML), are all examples that fall in the category of middleware-based approaches.

We conclude this overview by mentioning the JXTA technology. ^[40], ^[41] This is a set of open peer-to-peer protocols that allows any connected device on the network to communicate according to a peer-to-peer pattern. The focus of JXTA protocols is on creating a virtual network overlay on top of the Internet, allowing peers to directly interact independently of their network location, programming language, and different implementations. At the heart of JXTA technology we can find advertisements (XML documents) that are exploited to advertise all network resources (from peers to content). Advertisements are exploited to provide a uniform way to publish and discover network resources.

In this context, a final comment is due regarding our choice to design all our protocol architecture following an all-IP approach. This approach has the advantage of allowing mobile terminals to function as any other Internet-connected device. However, this choice requires that the end-to-end protocol function continuity be preserved in the wireless segments, and we must admit that many are the problems of providing such seamless internetworking between wired and wireless worlds with Internet protocols. Nevertheless, our decision of resorting to an additional session layer, along with the intense experimental monitoring we have conducted, have shown that the all-IP choice does not cause too many interferences (in terms of packet retransmissions) between TCP and the radio link layer. In addition, an all-IP approach overcomes the interoperability problems which may arise in the case of proprietary protocol solutions.

24.5.3 Multimedia Synchronization for Delivering Karaoke

One of the main concerns in the design of karaoke systems is the adopted synchronization strategy. In fact, it is clear that because a karaoke playout consists of a presentation of synchronized multimedia files, an underlying model is needed for specifying the synchronization rules to be adopted by different media streams. To accomplish this goal, we exploited the SMIL technology (and a SMIL player), but other solutions exist, e.g., the FLIPS model. ^[42] FLIPS is a model developed for specifying coarse synchronization for flexible presentations supporting a wide range of temporal synchronization specifications. It provides algorithms for attaining a consistent and coherent presentation state in response to user interaction and other state-changing events. Another traditional technology for playing back synchronized digital data is the MIDI technology that can also be used to play back karaoke clips. In essence, a computer program can play a MIDI-based karaoke file containing musical data, as well as the lyrics that are displayed on a computer monitor. Hence, MIDI karaoke files are standard MIDI files that may be executed on desktop computers. However, the most modern technology for the synchronized playback of multimedia data is the MP3 technology. Many vendors today produce MP3 players that are designed to display lyrics and other graphics while songs play out. For example, the Irock 680 player from Motorola plays out songs in both MP3 and MP3i formats. ^[43] (MP3i is the new interactive format that integrates graphical data with digital music files.) This allows content such as lyrics, artwork, text notes, photographs, and videos to be displayed as music plays back on a device.

Another important networked technology that has been extensively exploited to synchronize multimedia streams over the Internet and implement Internet-based karaoke systems is the RealMedia technology. ^[44] This is a client/server technology for streaming synchronized media on the Internet. For example, Karaoke/SureStream is a RealSystem feature that allows the RealServer to dynamically adjust the stream for each listener, depending on the dynamic network conditions of the user's connection. ^[45] SureStream manipulates media streams by providing an encoding framework allowing multiple streams at different bit rates to be simultaneously encoded and combined into a single file. Additionally, it provides a client/server mechanism for detecting changes in bandwidth and translating those changes into combinations of different streams. Karaoke Online uses the audio streaming technology provided by RealNetworks to deliver music and lyrics to a Web browser. ^[46]

Other interesting research experiences are those discussed in Lee and coworkers ^[47] (the SESAME project was presented where scalability issues for karaoke systems were investigated), and in Liu et al. ^[48] and Tseng and Huang ^[49] (client-server karaoke systems were proposed for video and audio streams that allowed a wired access through the public switched network). Many are the karaoke societies that use SMIL, SureStream, plus other synchronization technologies to implement karaoke systems on a client/server basis for the Internet. Relevant examples are Cyber-Karaoke-On-Demand, ^[50] Karaoke Jukebox, ^[51] StreamKaraoke, ^[52] and finally Streaming21. ^[53] We conclude by mentioning that all the cited experiences refer either to the wired Internet or to small-sized wireless LAN environments.