multimedia service interworking over heterogeneous networking environments

Multimedia Service Interworking over He te rog en eo us Networking En viron men ts

Sehyeong Cho and Youngmee Shin Electronics and Telecommunications Research Institute (ETRI)

Abstract This article discusses technical issues related to delivery of multimedia services, such as videoon-demand, over heterogeneous networking environments. In particu- lar, it describes the design and implementation of an experimental system for multimedia service interworking between a DAVIC (Digital Audio Visual Council) domain and an Internet domain. The system, called MIDDLEMEN (MIDDLEmen for Multimedia ENvironment), consists of the broker and the interworking unit, which work together to provide multimedia services across different types of networks in a seamless manner. The broker acts as a guide to multimedia services, and comple- ments servers or clients that are not equipped with full functionality. The broker also controls the resources in MIDDLEMEN. The interworking unit performs various translation functions under the control of the broker, including stream transport p r o tocol conversion, traffic monitoring and bit-rate control, service gateway conversion, and stream control conversion. Current implementation supports delivery of DAVIC-compliant VOD service from an ATM network to an IP network.

iversity and heterogeneity of networks and services characterize the modern networking environment. In the early days of networking, each network served different purposes in isolation. That is no

longer true today. “lntenvorking” is a way of making different networks cooperate to serve a purpose. Bridges and routers are well-understood examples of intenvorking equipment. Multimedia service intenvorking is conceptually similar, but more complicated, because we have to resolve the differences in numerous components. Important elements of video-on- demand (VOD) are as follows.

Video and audio formats: Digital audio formats will be characterized by many factors such as sampling rates or compression schemes. Video formats may differ in picture sizes, color characteristics, numbers of frames per second, encoding schemes, o r compression schemes. When the server and the client adopt different video or audio formats, transcoding [ 11 will be necessary. This may happen when the client does not have an appropriate decoder or when the access network has significant bandwidth limitations. Transcoding will not be discussed in this article. Synchronizing and system encoding: Each elementary (video or audio) stream should be merged to form a single bit- stream for transmission, and they should be synchronized. When the server and the client employ different schemes, the stream should be repackaged and resynchronized as necessary.

Session control: Different networks may adopt different methods for reserving resources and maintaining session information. There should be a way of managing two independent sessions to form a composite session. Connection control/QoS control: In the telecommunications world, QoS can be negotiated by way of signaling. In other networks, the QoS concept may not exist at all, or different QoS schemes [2] or pseudo-QoS may be adopted [3]. When two networks have different QoS schemes, there should be a function that translates one negotiation method to the other. When the client network is a “best- effort” network, other means such as bit-rate control may be adequate. Navigation/selection: There should be a way for the user to navigate the content space by viewing the lists, searching, previewing part of the contents, and selecting the desired video title. Application control: The user should be able to control the stream. For example, the user must be able to play or stop the stream. Fast-forwarding, rewinding, or recording may be desirable. Management and administration: Administrative functions such as user profile management, authentication, and billing will be necessary in most commercially offered VOD services. Service interworking, achieved bv resolving the differences

in these elements, wi’l enable seamless provision of VOD across networks. This article first provides an introduction to

IEEE Network March/Aprill999 0890-8044/99/$10.00 0 1999 IEEE 61

standards related to VOD service, and then discusses experi- ence in implementing an interworking system that delivers DAVIC VOD service to Internet users.

DAVlC DAVIC [4], founded in 1994 with the task of promoting broadband multimedia services, produced a series of specifications, from DAVIC 1.0 [5] released in December 1995 to DAVIC 1.4 [6] released in June 1998. VOD is one of the first services that are given priority in DAVIC. Teleshopping, broadcasting, and near-VOD were also classified as having priority. DAVIC operated with the assumption that although MPEG was clearly set to become a global audio-visual standard, the coding technique was only one component of a complete system [7]. The philosophy of DAVIC is not to define a whole new set of standards, but to integrate existing ones as long as they are available. It is beyond the scope of this article to describe the specification in detail. Instead, we will briefly describe the components of DAVIC that are most relevant to interworking. Therefore, detailed descriptions of supporting protocols will be kept to minimum.

DAVIC defines five information flows: S1 flow is unidirectional from the server to the client and carries encoded time-sensitive multimedia data. DAVIC has chosen ISO/IEC 11172 [8] and ISO/IEC 13818 [9] (commonly known as MPEG-1 and MPEG-2, respectively) as the mechanism for coding the audio/video content.

AALS, a streamlined ATM adaptation layer protocol adequate for high-speed data, is used to provide the mapping between the ATM and the MPEG-2 Transport Stream. S2 information flow is for bi-directional control information. DAVIC has selected the MPEG-2 Digital Storage Media Command and Control [9] User-to-User (DSM-CC UU) interface for the high-level S2 interface between the client and the server. S3 is session/transport services layer peer flow for the connection control of a session. DAVIC has selected the DSM- CC User-to-Network (DSM-CC UN) interface for session control. S4 is for connection control and uses the ITU-T Q.2931 signaling protocol [lo]. Q.2130 and Q.2110 are supporting protocols for Q.2931, and will not be discussed further. S5 represents administration information flow and is used for network management. Although S5 implementation is essential for any systems that offer real services, we shall not be concerned with the details. Figure 1 shows the protocol stack for a DAVIC system. In

the following sections we will provide an introduction to three of the most important standards adopted by DAVIC: MPEG, MHEG, and DSM-CC.

MPEG In DAVIC, the standard for coding of audio and moving pictures is ISO/IEC 13818, or MPEG-2 as it is commonly known.

Figure 2. Le@: textual notation for an MPEG-5 application. Right: displayed in an MHEG browser.

62 IEEE Network March/April 1999

The MPEG-2 system specification desc video streams are multiplexed to form a gram comprises one or more elementary

stream identifier. Each “packetized elementary nsists of a header and a mation such as stream mps. In order to multi- ~*

m stream (PS), a number of PES packets preceded by a header form a “pack.” A pack can be of arbitrary length, except that a pack header must occur at least every 0.7 seconds. An MPEG-2 PS is intended for use in error-free environments [ll]. In order to multiplex the elementary streams into a Transport Stream (TS), PES packets are divided into a series of fixed transport packets. ISO/IEC 11172-1 (MPEG-1 system) s are carried within transport streams by first replacing MP 1 system packet headers with MPEG-2 system PES pa headers. MPEG-1 system packet header field values copied to the equivalent MPEG-2 system PES packet header fields. The transport network is often assumed to be an ATM network, but can be other types, such as a non-ATM HFC (Hybrid Fiber Coaxial) network.

M HEG-5 DAVIC 1.0 selected MHEG-S 1121 for encoding base-level applications. MHEG-5 is one of the family of standards issued by the ISO/IEC JTCl WG12 subcommittee SC29, commonly called the “Multimedia-Hypermedia Experts Group.” MHEG defines a system-independent encoding of the structure information used for storing, exchanging, and executing multimedia presentations 1131. MHEGJ , or “support for base level interactive applications,” is conceptually a simplified profile of MHEG-1 1141, or “MHEG object repre- sentation -base notation.” In MHEG-S, a multimedia application can be conceived as a set of self-contained objects based on synchronization and spatial-temporal relationships of multiple media formats, structural composition, event- action association, navigation, and user-interaction capabili- ties. MHEG-5 is object-oriented, and its classes are specified by attributes, events, and actions. Figure 2 shows an application consisting of a scene object, a bitmap object, a hotspot object, and a link object.

DSM-CC Digital Storage Media-Command and Control (DSM-CC) is an ISO/IEC standard developed for the delivery of multimedia services. ISO/IEC 13818 proposed the DSM-CC protocol for the purpose of managing and controlling the MPEG-1 and MPEG-2 bit streams. Initially, DSM-CC was aimed at the digital storage media (e.g., CD-ROM) application program of a single user, but was later extended for networked applications such as video-on-demand, Incidentally, the standardization has been accelerated because DAVIC chose the DSM-CC as the stream control protocol, and ISO/IEC 13818 finished standardization in 1996. DSM-CC considers three logical entities, as shown in the reference model in Fig. 3: the client, the server, and the SRM(session and resource manager). DSM-CC messages consist of UU (user-to-user) messages, which are exchanged between a server and its clients, and UN (user-to- network) messages, which are used between a client and the SRM or a server and the SRM. Connection control can be implemented using the signaling protocols of the underlying transport network. In the case of ATM, Q.2931 can be used for setting up and tearing down switched virtual connections. DSM-CC is also used to deliver M H E G J objects to remote runtime engines.

-- __c __ ____ r - - - - - User Network

Figure 3. DSM-CC reference model.

lnternet Protocols: RTC RTCC and RTSP Real-time Transport Protocol (RTP) [ E ] is an IETF proposed standard suitable for transporting multimedia data over the Internet. RTP is a lightweight transport protocol based on the concept of application-level framing [ 161. Since the reliable transmission mechanism offered by TCP incurs considerable overhead by retransmission, RTP does not rely on TCP. Instead, applications are put on top of UDP. How to cope with the lost packets is up to the applications. Following the application-level framing principle, RTP functionality is usually integrated into the application rather than being implemented as a separate protocol enti- ty. RTP provides basic packet format definitions to support real-time communication but does not define control mech- anisms or algorithms. The packet formats provide information required for audio and video data transfer, such as the incoming video data packet sequence. Continuous media such as non-compressed PCM audio can be synchronized by the use of sequence numbers. Non-continuous data such as MPEG can be resynchronized by using the time stamp fields [17].

RTCP is the control protocol for RTP, and provides mech- anisms for data distribution monitoring, cross media synchronization, and sender identification 1181. The sender transmits a multimedia data stream by using RTP packets. The receiver periodically sends RTCP packets that contain information about the received RTP packets. The information includes statistics such as the highest sequence number received, inter- arrival jitter, or packet loss rate.

RTSP [19] is an IETF proposed standard that can be

Figure A. Typical RTSP operation.

IEEE Network MarcWAprill999 63

~~ ~

W Figure 5. Sketch of the service scenario.

used for initiating and controlling delivery of stored and live multimedia content to both unicast and multicast destina- tions. RTSP borrows time concept from DSM-CC, but unlike DSM-CC, it does not depend on an entire set of supporting protocols [20]. RTSP is transport-independent, and can use either TCP or UDP as the transport protocol. The state machine makes RTSP suitable for remote digital edit- ing. RTSP is a text-based protocol, and therefore easy to parse. RTSP reuses the HTTP concept, but unlike HTTP, RTSP is a stateful protocol. Figure 4 shows a typical RTSP operation.

MlDDLEMEN in the Networking Environment A MIDDLEMEN system consists of a service broker and an interworking unit(s) as shown in Fig. 5 to provide seamless multimedia services between the ATM network and the Inter- net. The interworking function must be located between two networks, and becomes the termination points for both networks.

MIDDLEMEN provides control and management of communication between service providers and clients, and also provides brokerage functions that bridge the gap between the network and user applications. Potential services that MID- DLEMEN can offer are virtually anything that can help bridge the gap between the service user and the service provider. These services can be either client-support or server- support. Client-support services include navigation support, client profile management, proxy signaling [21] for terminals without user-to-network signaling capability, application module download, and so on. MIDDLEMEN can support servers in authentication and authorization, proxy level-2 gateway, server content management service, proxy video pump for content-only servers, charging and billing on behalf of the server, and so on.

The service guide and navigation support helps users inter- act with MIDDLEMEN for the purpose of selecting a service provider. Using this capability, MIDDLEMEN provides the user’s initial entry point to the service and it guides the user in service selection. Thus, users can search different program

W Figure 6. MIDDLEMEN services andfunctions.

64 IEEE Network March/Aprill999

Figure 7. Protocol stack for conversion of stream transport.

titles or previews of the program titles simultaneously. Also, MIDDLEMEN performs various functions on behalf of the server in case the server does not provide all necessary functions such as program guidance. Content-only servers are good examples. MIDDLEMEN, in that case, can act as a virtual server with the service gateway capability in the distribut- ed server environment [5]. Figure 6 depicts the services and functions of MIDDLEMEN. The circles in the picture represent the services. Only “ATM to Internet multimedia” is described in detail in this article. Rectangles represent functions. Grey shaded rectangles are implemented in the interworking unit; blue shaded rectangles a re in the broker subsystem.

The lnterworking Unit The interworking unit contains functionality that should be located at the border between two network - in this case, the ATM network and the Internet. Because the ATM network and Internet use different protocols for real-time multimedia service, the interworking unit of the MIDDLEMEN converts protocols between the ATM network and the Internet. The stream conversion function denotes transport protocol conver-

AAL5 protocol, recovers the PES packets, and sends the PES packets over RTP. In the actual implementation, MPEG-1 streams are used instead of MPEG-2 streams, considering that for economic reason, the current Internet hardly provides the bandwidth for MPEG-2 streams, which usually require 3 to 10 Mb/s. Fig- ure 7 shows the protocol stack for stream transport conversion.

Traffic Monitoring and Bit Rate Control

Although there is ongoing work in the Integrated Services (intserv) [23], the Dif- ferentiated Services (diffserv) [24] and the Resource Reservation Setup Protocol

(rsvp) [25] working groups of the IETF to provide QoS support in the Internet, it is currently a best-effort network. Hence, the presence of traffic congestion can greatly affect the quality of real-time multimedia services. Unlike ordinary data services, multimedia services are sensitive to delay, jitter, and loss, which in turn are affected by the volume and pattern of completing traffic in the network. A Transport Control Protocol (TCP)-based stream will respond to losses or exces- sive delays by triggering a retransmission and exerting window flow control, both of which will have negative effects on the quality of the multimedia service. RTP, being based on User Datagram Protocol (UDP) will not degrade the service further by taking these inappropriate control actions, but will still suffer from the service degradation caused by the underlying loss or delay. Once the congestion has occurred, loss of packets is inevitable. Therefore, it is better to reduce the traffic in a controlled manner, with a controlled reduction in quality, rather than losing packets in an unpredictable manner. There are at least two possibilities. One is to transcode [l] the video and/or audio into another format that requires less bandwidth. The other is to selectively drop packets that have minimal effect on the audio/video quality. The interworking unit of the MIDDLEMEN adopts the second approach. The interwork-

sion for video stream. The gateway conversion function converts level 2 gateway, and the stream control conversion converts stream control protocols. Other functions are not in the focus of this article, but depicted in the figure for the sake of consistency.

Stream Transport Conversion A DAVIC-compliant system uses MPEG-2 TS (transport stream) for transporting a real-time multimedia stream. MPEG-2 PS (program stream) can also be used, provided multiplex- ing of more than one program is not required and the network is error-free. On the other hand, RTP (Real-time Transport Protocol) [15] over UDP/IP is widely used for transport of a real- time multimedia stream in the Internet community. A proposed standard for transporting MPEG streams using RTP packets is also available [22]. The interworking unit of the MIDDLEMEN receives packetized streams carried by fixed size MPEG-2 TS packets over Figure 8. Pictures of MPEG video.

IEEE Network MarcWAprill999 65

ing unit detects the onset of congestion by analyzing reception report RTCP packets sent from the client. It then pro- ceeds to discard packets that convey cer- tain pictures. An MPEG-1 video consists of I-pictures, P-pictures, and B-pictures, as defined by ISO/IEC 11172-2 and 11172-3 [SI (Fig. 8). I-pictures are stand- alone pictures, whereas coding of P-pictures depends on the preceding I-picture or P-picture. I and P-pictures are called reference pictures for that reason. B-pictures depend both on preceding and following reference pictures. Discarding a B-picture results in the loss of only one picture frame. On the other hand, losing an I-picture will result in being unable to decode two B pictures in the previous group of pictures (GOP) plus all 12 pictures in the current GOP. Loss of a P3, P2, PI picture results in being unable to decode 5 , 8, and 11 pictures, respectively. Therefore, the priority of pictures is: I,

~~

W Table 1 . Reyiirrrd bit rates when cer- lain pictures ure discarded. (2OOKII- picture, 12OKIP, XOKIR awinied)

we describe translation of RTSP into the DSM-CC UU, which enables an Internet client to control a DAVIC server. Figure 9 shows the structure of the stream control converter.

The Internet client has an RTSP user handler and a user interface (e.g., a VCR-like control panel). The service provider has server skeleton, server application program and stream type objects, which are created and freed dynamically by the server application program. The stream control converter is comprised of three entities: the RTSP server handler, the RTSP to DSM-CC UU converter, and the UU client handler. The RTSP server handler receives RTSP request messages from the Inter- net client, and analyzes the syntax of the received RTSP messages. Then the RTSP handler makes requests for translation of the received RTSP messages into corresponding DSM-CC U U mes-

P1, P2, P3, and then B’s. Table 1 shows the bit rates required when pictures are discarded.

Stream Control lnterworking Stream control interworking enables the user connected to one network to control the stream served from another network, just as one controls one’s own VCR. In this section,

sages, and sends RTSP reply messages io the Internet client. The RTSP-UU converter performs the translation of the RTSP messages into DSM-CC UU messages. The UU client handler receives the translated DSM-CC UU messages, and then performs the proper actions relevant to the message type of the translated DSM-CC UU messages. For example, if the translated message is a primitive of the session interface, then

W Table 2 . Mapping between RTSP messages and DSM-CC messages.

~ ~- ~~ ~- ~_

Internet user Stream control converter Service provider

~ - ___ -. ~. .- U - _ _

W Figure 9. The stream control converter.

66 IEEE Network MarchiApril 1999

the UU client handler invokes the DSM-CC UN (user-network) function, and requests the service provider for the creation of a stream object, and then receives the reference to the created object. If the translated message is a primitive of stream interface, then the UU client handler sends the translated message to the service provider. Table 2 shows the mapping between RTSP messages and DSM-CC messages.

Service Gateway In terworking Table 3. Comparison of MHEG-5 and HTML.

The service navigation process is guided by MHEG-5 objects in DAVIC-compliant systems. In the Internet world, HTML [26] is the de facto standard for hypermedia markup and navigation. While HTML has gained more popularity than MHEG, the latter is richer in features. Table 3 compares the important features of the two standards. In order to support HTML-based browsing for Internet users, the interworking unit translates the MHEGJ objects on the fly. This also eliminates the need for CORBA implementation in the client terminal, since the client application is now a simple Web browser.

Since MHEG-5 is richer in features compared to HTML, it is not possible to translate all MHEG-5 objects into HTML documents. However, for practical purposes, such as VOD control, most objects are translatable. The translator receives MHEG objects from the DSM-CC module. A scene object, after translation, is stored as an HTML file. Hotspots are translated into HTML maps, and link objects are used to find action objects. The service gateway conversion function is tightly coupled to the stream control interworking function. For instance, the button objects for play or stop are translated into HTML; the user clicks at the “play” or “stop” button shown in the web browser, then the action is conveyed as an RTSP message, and then the RTSP message is translated to a DSM-CC UU message. The result of translating MHEG-5 objects shown in Fig. 2 is shown in Fig. 10. The translator is constructed by combining an MHEG-5 runtime engine (RTE) and a modified HTTP server. Figure 11 depicts the interworking scenario.

Session Con fro/ Interworking DAVIC systems make use of explicit session management by DSM-CC UN session messages. The UN messages are used for session set-up, release, addfdelete resource, status check- ing, and session transfer. In the TCP/IP world, explicit session control is not commonly used for video delivery. For confer- ence applications, session is clearly meaningful, and protocols for session handling are being proposed in the Multiparty Mul- timedia Session Control (mmusic) working group of the IETF [27]. When setting up a session that spans the Internet domain and the DAVIC domain, the Internet side does not use explicit session messages; only the DAVIC side uses DSM-CC UN messages. The session and resource manager resides in the MIDDLEMEN broker subsystem. When an Internet client makes a service request, the resource manager allocates a resource in the interworking unit, which in turn acts as a client in the DAVIC domain. The rest of the session management is exactly the same as DAVIC session management.

Connection Control Inferworking DAVIC systems use Q.2931 signaling protocol for establishing ATM virtual channels. Despite ongoing work on bandwidth reservation such as RSVP [25] in the IETF, the current Inter- net is still a “best-effort’’ network. In an RSVP-capable network, Q.2931 and RSVP need not interoperate per se, but instead, the session manager should be responsible for alloca- tion of channels in both networks with appropriate band- widths.

. . . . . _ _ . . ..- --

Figure 10. Resulting HTML document (lej?) displayed in a Web browser (right).

IEEE Network MatchlAprill999 67

Figure 1 1 . Example interworking scenario for service gateway interworking.

The implementation The prototype system described here has been implemented in PCs and workstations. A Sun Sparcstation was used for the video server. The clients and the interworking unit were implemented on Pentium PCs. The interworking unit and t h e DAVIC server were connected by an 8-port ATM switch. Internet connections were made by 10M Ethernet. All PCs ran the Windows 95 operating system. The prototype was designed to handle only one stream at a time. To be able to handle multiple VOD sessions at the same time, various components should be multithreaded. Among them are the server, the stream control translator, the stream transport translator, and the session manager. As for the performance of the interworking unit, the stream transport interworking function plays the central role,

with a PCI-type card, and the same PC was able to translate five streams. Adding the stream control interworking would add to the CPU load, but the added load is expected to be only marginal. Figure 12 shows the delay variation (from the point the packet was received by the interworking unit until it was received by the client) measured in a LAN environment (separate buildings, one router and two switches away).

The other direction of interworking, namely, Internet to ATM multimedia, is similar in technical difficulties, but the direction of interworking is exactly the opposite. H T M L t o MHEG-5 translation is more complete than the reverse translation because MHEG-5 is richer in features. More buffer space is necessary because the server side network has fluctuation. However, most ATM terminals are expected to have the TCP/IP protocol suite. For example, later versions of the DAVIC specification [6] supports TCP/IP access. This makes the translation of TCP/IP-based multimedia service into DAVIC less meaningful.

Concluding Remarks In this article, we explained one of the MIDDLEMEN services, namely, delivery of DAVIC VOD service to Inter- net users. The current configuration

was not intended for multi-stream interworking for commercial use, but can easily be modified to handle up to five streams. The net result of interworking by MIDDLEMEN is that the end users need not be aware that they are accessing services offered from a different network. Their terminal equipment need not have the DAVIC protocols or ATM interfaces. The Internet users might well have the impression that it is a service offered by an Internet site. This is what we call a “seamless service interworking.” A wireline telephone user can make a call to a cellular phone user without having to know what coding schemes are used. Multimedia service users basically want the same level of homogeneity and trans- parency. MIDDLEMEN offers one way of fulfilling this requirement. Theoretically, it is required to provide O ( v ) number of interworking functions for N different networks or

because of its sheer-amount of data . In order to see how a Pentium PC would per- form as an interworking unit, we performed a simulation. In the simulated environment, there was no session management or stream control interworking. The interworking unit received packets for several 1.4 Mb/s video streams from the ATM side, and sent it in RTP packets to the client. The operating system was changed to Windows NT 4.0. In the first round of simulation, the CPU was able to handle only two streams without being overrun. More than half of the CPU time was taken by the kernel. In the second round, we replaced the ISA-type LAN card Figure 12. Delay variation.

68 IEEE Network MarcWApriI 1999

services. Practically, however, we can prioritize the combina- tions, and select only a few that are most popular. I t is still too early to assess the commercial viability of MIDDLEMEN and the intenvorking approach. We will have to wait and see how networked multimedia services make their way into the market, from expectations and hype to real commercial services. In the near future, we plan to explore the possibility of creating a middleware architecture for intenvorking, in order to more easily accommodate intenvorking functions for various networks and services.

Acknowledgment The authors are grateful to Kyung Pyo Jun, Sung Won Sohn, Jong So0 Jang, Jung Hoon Choi, Jum Ja Kang, and Choong- jae Im for helpful comments, and to Professor Seung Joon Oh, Professor Kwang So0 Jung, and the students of Kwang Woon University for providing tools.

References [ l I P. N. Tudor and 0. H. Werner, "Real-time Transcoding of MPEG2 Vi&

Bit Streams," Proc. Sroadcasting Convention, Sept. 1997, pp. 296-301, [2] R. Braden et al., "Resource Reservation Protocol (RSVP) - Version 1 Func-

tional Specification," IETF RFC 2205, Sept. 1997. [3] S. Blake et al., "An Architecture for Differentiated Services," IETF RFC 2475,

Dec. 1998. [4] H. Yasuda and H. J. F. Ryan, "DAVIC and Interactive Multimedia Services,"

IEEE Commun. Mag, vol. 36, no. 9, Sept. 1998, pp. 137-1 43. [5] Digital Audio-Visua Council, "DAVIC 1 .O Specifications," Dec. 1995. [6] Di ita1 Audio-Visual Council, "DAVIC 1.4 Specifications," June 1998. [7] Joln Thompson, "DAVIC: Strivin to Achieve the Benefits of Openness," E/ec-

tronics and Commun. Eng. J., vc!. 9, no. 1, Feb. 1997, pp.43-45. [8] ISO/IEC International Standard 11 172, "Coding of Moving Pictures and

Associated Audio for Digital Storage Media up to about 1.5 Mbits/s," Nov. 1993.

[9] ISO/IEC International Standard 1381 8, "Generic Coding Of Moving Pictures and Associated Audio Information," Nov. 1994.

[ 101 ITU-T Recommendation Q.2931, "Broadband Integrated Services Digital Network (B-ISDN) - Digital Subscriber Signaling System no. 2 (DSS 2) - User-network interface (UNI) - Layer 3 specification for basic call/connection control," Feb. 1995.

[ 1 1 ] P. A. Sarginson, "MPEG2: A Tutorial Introduction to the Systems Layer," Proc. IEE Coloquium on MPEG2, 1995, p 4/1 4/13.

[ 121 ISO/IEC 13522-5 "Information TechnoLgy --Coding of Multimedia and Hypermedia Informotion - Part 5: Support for Base level Interactive Appli- cations," 1996.

[13] M. Echiffre et a/., "MHEG-5 - Aims, Concepts, and Implementation Issues," IEEEMultimedia, vol. 5, no.1, Jan./Mar. 1998, pp. 84-91.

[ 141 ISO/IEC 13522-1, "Information Technology - Coding of Multimedia and Hypermedia Information - Part 1 : Base Notation (ASN.1): Oct. 1995.

[15] H. Schulzrinne et a/., "RTP: A Transport Protocol for Real-Time Applica- tions," IETF RFC 1889, Jan. 1996.

[16] D. Clark and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols," Proc. ACM Sigcomm '90, ACM Press, New York, 1990, pp. 200-208.

[ 171 T. Braun, "Internet Protocols for Multimedia Communications," lEEE Multime- dia, vol. 4, no. 4, Oct./Dec. 1997, pp.74-82.

[ 181 I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS Control Of Multi- media Applications Based on RTP," Computer Commun., vol. 19, 1996, pp. 49-58.

[ 191 H. Schulzrinne, A. Roo, and R. tanphier, "Real-Time Streaming Protocol (RTSP)," IETF RFC 2326, Apr. 1998.

[20] H. Schulzrinne, "A Comprehensive Multimedia Control Architecture for the Internet," Proc. /E€€ 7th Workshop on Nefwork and Operating System Sup- port for Digital Audio and Video, May 1997, pp. 65-76.

[21 ] M. Li, R. Counterman, and V. Shukla, "Simple Access Signaling for ATM-based VOD Services," Proc. 2nd Int'l Wksp on Communiv Nefwork- ing, June 1995. pp.95-100.

[22] D. Hoffman and G. Fernando, "RTP Payload Format for MPEGl /MPEG2 Video," IETF RFC 2250, Jan 1998.

[23 ] IETF lntserv (Integrated Services) working group charter, http://www.ietf.org/html.charters/intserv-charter.html, Feb. 1998.

[24 ] IETF Diffserv(Differentiated Services) working group charter, http://w,ietf.org/html.charters/diffsew-charter. html, Jan. 1 999.

[25 ] IETF Resource Reservation Protocol (rsvp) working group charter, hnp://www.ietf.org/html.charters/rsvp-charter,html, Nov. 1998.

[26] T. Berners-Lee and D. Connolly, "Hypertext Markup Language 2.0," IETF RFC 1866, Nov. 1995.

[27] IETF mmusic (Multiparty Multimedia Session Control) working group charter, http://www.ietf.org/html.charters/mmusic-charter. html, Nov. 1 998.

Biographies SEHYEONG CHO ([email protected]) received his B.E. and M.S. de rees from Seoul National University in 1981 and 1983, respectively. He receive! a Ph.D. degree from the Pennsylvania State University in 1992. He is currently a rincipal member of engineering staff and project leader at the Electronics an8Telecommuni- cations Research Institute (ETRI) in Korea. His research interests include networked multimedia, intelligent networks, and agent applications.

YOUNGMEE SHIN received her B.E. and M.S. degrees from K un Pook National University in 1993 and 1995, respectively. Since 1995, she ias%een a member of engineering staff in ETRI, where she took part in the development of an intelligent network service creation environment, and a multimedia interworking system. Her recent research is focused on multimedia telephone service.

IEEE Network MarcWAprd 1999 69

multimedia service interworking over heterogeneous networking environments

Documents