Session Models for Heterogeneous Multicasting Environments

Session Models for Heterogeneous Multicasting EnvironmentsCristian Hesselman and Henk EertinkTelematica Instituut, P.O. Box 589, 7500 AN Enschede, The Netherlands{hesselman, eertink}@telin.nlAbstractIn this paper, we describe ongoing work on a system that controls the Quality of Service (QoS) of streaming applications running in a heterogeneous fixed-mobile integrated environment. For thispurpose, the system dynamically composes and configures sets of IP multicast sessions that areinterconnected through proxies.1Motivation and overviewThe increasing capabilities of mobile terminals and mobile networks [16] allow the multimedia multiparty applications of the fixed environment (e.g. video conferencing, video on demand and gaming applications) to become available in the mobile environment as well. This opens up the opportunity to build advanced environment independent multimedia multiparty applications, provided the mobile and fixed parts of such applications are seamlessly integrated.A major problem for integration is that the parts of a distributed multiparty application that run on mobile terminals typically have to do with an operating environment that has fewer capabilities than the application parts that run on fixed terminals [10, 18]. For example, mobile operating environments typically have less available network bandwidth, a limited set of codecs, and smaller and lower quality displays. In addition, there is also a strong variation in the capabilities of mobile operating environments themselves [16]. For example, some mobile operating environments offer application parts high capacity network connectivity and full-color displays, whereas others offer a low network capacity and monochrome displays. The above two factors make it a difficult task to deliver each application part (fixed and mobile) with a sufficient QoS in a scalable manner.There are two extreme solutions to the above problem. One is to deliver a single QoS to all application parts, the other is to deliver a QoS that is fine-tuned to the capabilities of each application part’s operating environment. The first approach generally scales well, but typically provides a non-optimal overall QoS. The second approach generally provides an optimal overall QoS, but typically scales poorly.The middleware-based system that we discuss in this paper takes an approach that lies somewhere in the middle. In particular, our system deals with the heterogeneity of application parts’ operating environments by making groups of application parts that run in operating environments with similar QoS-related capabilities. The system then establishes an appropriate QoS level for each group and assumes that the capability variations within each group are small enough that active QoS control for the group can be kept to a minimum. The system can then focus on controlling the QoS differences between different groups of application parts. We argue that this approach delivers a sufficient QoS to the application parts while it at the same time ensures a high degree of scalability.In this paper, we focus on the delivery of QoS to the mobile part of distributed applications, in particular on how to provide QoS in the face of terminal mobility. We furthermore limit ourselves to three aspects of capability variations: media device variations, codec variations and network bandwidth variations. In a later stage, we also intend to consider aspects such as display sizes and display qualities (e.g. color, monochrome, etc.).The system that we describe relies on the ubiquitous presence of IP as the unifying glue for heterogeneous networks. In particular, our system relies on IP multicast because this transport technology forms a natural match with multiparty applications and because it proliferates rapidly.The rest of this paper is organized as follows. In Section 2 we first discuss the model with which we describe communication sessions. The system that we intend to construct will be built around this model. Section 3 gives an overview of our system in terms of the functions of which we think that they are necessary to control the QoS using the model of Section 2. Section 3 focuses on the functions related to joining an application part to a communications session, and on the functions required to deal with to terminal mobility. Section 4 presents related work and Section 5 closes with conclusions.2Session ModelThis section describes the session model that will form the basis of our middleware-based distributed system. Although it is generic model, we will for the sake of discussion present it by means of a specific example. We will do this at two levels of abstraction. On a high level of abstraction, our system supports sessions that carry media flows between application parts that operate on a variety of terminals that may connect to a variety of networks. This high level model describes the sessions that we want the system to support from an application’s perspective. Our system decomposes this model into a number of lower level homogeneous sessions (homogeneous in terms of media, media encoding and bandwidth consumption). Major requirements on the lower level model are scalability (large numbers of users should be able to simultaneously access the system), adaptivity (the system should be able to deal with variations in the availability of resources) and transparency (the lower level model should be transparent to the applications).Observe that both models deal with abstract sessions that need to be mapped to actual transports. For the sake of brevity, we will not discuss this mapping in this paper.2.1High Level Session ModelFigure 1 shows an example of the high-level session model that we have in mind. The model represents an instance of a distributed video conferencing application and consists of five User Agents (UAs) that are interconnected by a session. The system that we plan to develop will be responsible forestablishing and controlling the session, in particular forcontrolling the session’s QoS.User Agent X Bundle of flowsUA’s local view on session Global view on sessionFigure 1: Video conferencing session.The UAs shown in Figure 1 are application level programsthat represent the multimedia devices of a terminal (fixed or mobile) that are currently active. The devices produce or consume flows of audio or video information. Each UA sends and/or receives such flows to/from other UAs in the session.Based on the capabilities of each UA’s operating environment (supported media devices and network bandwidth), the session that interconnects the UAs delivers the right types of flows to the right UAs. The quality of the flows that a UA receives is less or equal to the quality of the flows such as they were transmitted. Quality degradations may occur as a result of several factors like variations in the capabilities of UAs’operating environments, terminal mobility, temporary unavailability of resources and RF interference.As an example, assume that the UAs A, B and E run on high-performance multimedia workstations that send and receive high-quality audio and video flows, whereas UAs C and D reside on GSM-like terminals that only receive low quality audio flows. In this setting, our system would not deliver the video flow from, for instance, UA A to C and D.That is, based on the characteristics of the mobile terminals and the bandwidth characteristics of their network connections, the system decides that sending video flows towards C and D makes no sense. The quality of A’s audio flow that UAs C and D do receive will furthermore typically be less than the quality of the same audio flow such as B and E receive it. This is for instance due to the mobiles’ low network capacity.The above example also reveals that each UA may generally have a different view of the session. UAs A, B and E for instance, perceive the session as a full-fledged multimedia conference that accepts and delivers audio and video flows.The UAs that run on the two GSM terminals, on the other hand, see the session as an audio-only conference that only accepts and delivers an audio flow. From a global perspective the session can therefore be considered heterogeneous with respect to the types of flows that it carries to and accepts from UAs. The example furthermore shows that different UAs may have different views on the quality of the same flow.Sessions may thus also be heterogeneous when it comes to QoS.2.2Lower Level Session ModelFigure 2 shows the lower level session model that refines the model of Figure 1. The model is a refinement in the sense that it also considers the codec and network bandwidth variations in the UAs’ operating environment. In a mobile setting, codec heterogeneity is particularly important to consider because unlike fixed terminals like PCs, mobile terminals often rely on hardware codecs. This makes mobile terminals more sensitive to the overall degree of codec heterogeneity because they generally cannot change codecs, nor can they easily extendtheir set of codecs. This is particularly true for small mobile terminals like PDAs.The idea behind the lower level communications model is to make groups of UAs that use the same codec for the same types of information flows and have approximately the same amount of network bandwidth at their disposal. The consequence of this grouping is that we can use a session with multicast capabilities to interconnect these UAs without having to perform per-UA transcoding between different coding schemes, per-UA filtering of flow types (cf. [1]) or per-UA bandwidth tuning. This ensures that our system possesses a high degree of scalability. The use of multicast sessions furthermore allows us to easily map the sessions onto transports with multicast capabilities, in particular on IP multicast groups. Observe that the multicast sessions are scoped (e.g. TTL scoped, organizationally scoped or link local scoped) to limit the amount of UAs that they will attract. This is particularly important for applications such as video conferencing where there is more than one UA that transmitsflows.Figure 2: Session of sessions.The multicast groups need to be interconnected to form the overall session of Figure 1. The interconnections between the different multicast groups perform functions like transcoding [15], filtering of flow types and rate adaptation for this purpose, but merely on a per-session pair basis rather than on a per-UA basis. The entities that are responsible for such tasks are application level programs that run on network nodes in LANs or access networks. We refer to these entities as proxies (cf. [8]). The proxies in our model are scoped for load-balancing purposes. Scoping may for instance be accomplished by limiting the range of ‘proxy advertisements’(cf. Agent Advertisements in Mobile IP [17]).Compared to the high level session of Figure 1, the lower level multicast sessions of Figure 2 are homogenous with respect to the types of flows that they carry as well as with respect to the flows’ quality (the flows rely on approximately the same network bandwidth). The multicast sessions will furthermore generally form a piece of the overall session because UAs will generally use different types of flows or different codecs. The lower level model can therefore be viewed as a decomposition of the higher level heterogeneous session in terms of several interconnected homogenous multicast sessions that each form a piece of the overall session.To complete the example, assume that UAs A and B use an MPEG-2 codec (for both their audio and their video flows), UAs C and D use a GSM codec (for their audio flows)and that UA E uses an MPEG-1 codec (also for both itsaudio and its video flows). According to the ‘grouping principle’, we end up with three groups: one interconnecting UAs A and B, one interconnecting UAs C and D and one with only UA E as a member. Observe that a UA becomes a member of two multicast sessions if it uses a different coding scheme for its audio and video flows.The three groups are interconnected by a number of proxies — three in this example. The proxies are labeled 1, 2 and 3 in Figure 2. Proxy 1, for instance, performs transcoding, filtering and rate adaptation tasks.3System OverviewOur middleware-based system is responsible for establishing structures such as the one shown in Figure 2 to provide the UAs in the heterogeneous session of Figure 1 with a sufficient QoS while retaining a high degree of scalability. The system is furthermore responsible for maintaining the established QoS level when the distributed application is used. Both tasks require the system to be aware of the heterogeneity of the environment. To maintain an established QoS level, the system furthermore needs to take the dynamics of the environment into consideration, especially that of the mobile environment.The establishment and maintenance of compositions of multicast sessions boils down to the execution of operations on the higher and lower level session models. UAs will typically invoke the operations that can be performed on the higher level session model, but the system may occasionally also do this. For instance, the system could autonomously decide to remove a video flow on a terminal because the terminal’s profile specifies that video flows should be dropped whenever it runs low on battery power. The operations that manipulate the lower level session model, on the other hand, will not be accessible to UAs. Instead, instances of the lower level model will only be visible and accessible to the middleware. The middleware will also be responsible for mapping instances of the higher level model to a lower level equivalent. This means that the middleware will be responsible for translating operations that the UAs invoke on a higher level session model into the equivalent operation(s) on the corresponding lower level model.We have identified a number of operations that can be executed on the higher and lower level session models. For the sake of brevity, we will limit the discussion to the operations of joining (or establishing) a session and the operations that occur as a result of terminal mobility. The join operation will be called by UAs to manipulate instances of the higher level session model and requires the middleware to perform one or more operations on an instance of the lower level session model. The operations that the middleware needs to execute to deal with terminal mobility apply to instances of the lower level session model only and will hence not be visible to UAs.Our focus in realizing the operations mentioned above will be on capability negotiation.Joining a session. If a UA intends to join a heterogeneous session (cf. Figure 1), the system needs to figure out which multicast sessions (cf. Figure 2) the UA can connect to. To this end the system will need to be made aware of the properties of the new UA’s operating environment. The system will furthermore have to be able to determine a ‘proxy path’ (requiring proxy discovery and routing) through the existing structure of multicast sessions. This path should not contain any loops. For example, if a UA running on a GSM terminal wants to join the session of Figure 1, it should connect to the GSM session of Figure 2 and use proxies 1 and 2 to reach the other UAs in the session. Proxy 3 should not be involved in the delivery of flows that emerge from the GSM session.In addition to finding a session to connect to and a proxy path, the system will also have to determine whether or not the addition of the new user will keep the load on proxy 1 within bounds (load balancing). This issue is particularly relevant for non-broadcast applications such as video conferencing because these applications require the system to deal with upstream as well as with downstream traffic. If the load on the proxy gets too high, the system will have to take appropriate actions to solve the problem. It may for instance decide to fire up a new proxy, attach the new proxy and the new UA to a new multicast session and plug the whole into the existing structure of multicast sessions.Terminal mobility.Consider the example of Figure 2 and suppose that UA C roams. At a certain point in time UA C will get ‘out of range’ of proxy 1 (proxies are scoped) or the GSM session (sessions are scoped, too). When this happens, UA C and its codec will be forced to leave the GSM session and join a new GSM session at another ‘location’. If such a session already exists, the system can deal with this event simply by having UA C leave the current GSM session and have it join the other GSM session. If no such session exists, the system will have to create one, attach the new session to the already existing structure of multicast sessions and proxies and join AE C to the new session. An application level handoff of this type needs to be completed as soon as possible so as not to disrupt communications for UA C.In a UMTS-like network environment that exists of various mobile network technologies and where terminals are equipped with either multiple radio interfaces or a software radio, a UA may also run into a new network that has other properties than the one the UA is currently using. For example, if the terminal on which UA C runs moves from a GSM-like network to an indoor wireless LAN, the available network capacity will generally increase. The UA C and its codec may then be moved to a higher capacity group. This transition will generally also involve adjusting a UA’s codec parameters to exploit the additional capacity and thus obtain a better quality. The system may alternatively respond by choosing a new codec (if more than one is available) or by adding new flows. The system may perform the inverse of one of the above actions when the mobile terminal runs into a network with less capacity.4Related WorkThe use of proxies to deal with capability variations of networks and terminals is not new. [2], [18], [8], [19] and [20] are examples of initiatives that take this approach. In particular, [18], [8] and [20] use proxies to overcome capability variations for mobile networks and terminals.[6] and [7] discuss an approach that uses multiple multicast sessions to control the bandwidth of video flows that destined for a set of heterogeneous clients. This approach is known as Receiver-driven Layered Multicast (RLM). RLM exploits the fact that advanced coding schemes such as MPEG-2 [13] and MPEG-4 [14] allow information flows to be encoded at multiple quality levels. Each quality level produces a flow of a certain bandwidth each of which RLM transmits onto a separate multicast session. This allows receivers to ‘tune in’ to as many sessions as they are capable of receiving given their current network capacity and ‘add up’ the quality levels they receive. We believe that our model also supports RLM. TheMPEG-2 session of Figure 2 could for instance consist of three multicast sessions each carrying flows of a different quality.We are also aware of work that makes use of combinations of proxies and multicast sessions, for instance [9], [10] and [11]. [9] and [11] also use IP multicast at the transport level, but neither of them deals with mobile communications. [10] does, but does not use IP multicast transports and focuses on reliable communications rather than on multimedia streaming.[9], [11] and [10] furthermore pay little attention to the dynamic composition and configuration of proxies and multicast sessions. [11] does consider this for a fixed environment, but only allows server applications to express their characteristics. As far as we know, it is not possible for, say, a terminal to describe its currently available bandwidth and request to be included in an existing session based on that bandwidth. [9] and [11] furthermore focus on broadcast applications while we also intend to consider non-broadcast applications like video conferencing.Work on session models for multimedia communication is part of a large number of other architectures, for instance in the IP-telephony world [3, 4, 5] or in the TINA telecommunications environment [12]. Our session model, however, has a different purpose in that it strongly focuses on dealing with terminal and network heterogeneity, on capability negotiation and on controlling compositions of IP-multicast sessions. Similar to the TINA session models, our session model uses multiple levels of abstraction. The higher level model describes communication sessions from an application’s perspective, while the lower level model describes communication sessions from a middleware perspective. To our knowledge, this two-level model-based approach does not exist in any of the work that deals with compositions of multicast sessions and proxies.In summary, our system is unique in that is built around a two-level model-based approach and focuses on the dynamic composition of multicast sessions and proxies as a result of terminal mobility.5Conclusions and StatusWe have presented our initial ideas about a middleware-based system that controls the QoS of distributed multimedia multiparty applications that run in fixed-mobile integrated environments. We have discussed the session model on which our system will rely. The model decomposes a heterogeneous communications session into several homogenous multicast sessions that are interconnected by proxies. We have also presented the first ideas about the system’s functions that will be responsible for establishing and controlling these sessions of sessions. In particular, we have discussed the functions of which we expect that the system will need them to be able to deal with UAs that want to join a session and to be able to deal with terminal mobility.We are currently implementing a first version of our system that will act as an initial proof of concept. References[1] R. Wittmann, M. Zitterbart, “AMnet: Active Multicasting Network”, Proc. of Intern. Conf. on Communications (ICC'98), Atlanta, GA, USA, June 1998[2] S. Cho, Y. Shin, “Multimedia Service Interworking over Heterogeneous Networking Environments”, IEEE Network, March/April 1999, pp. 61-69[3] M. Handley, V. Jacobson, “SDP: Session Description Protocol”, RFC 2327, April 1998[4] M. Handly, H. Schulzrinne, E. Schooler, J. Rosenberg,“SIP: Session Initiation Protocol”, RFC 2543, March 1999 [5] M. Handley, C. Perkins, E. Whelan, “Session Announcement Protocol”, IETF draft, draft-ietf-mmusic-sap-v2-03.txt, October 1999[6] S. McCanne, V. Jacobson, M. Vetterli, “Receiver-driven Layered Multicast”, ACM SIGCOMM, August 1996, Stanford, CA, pp. 117-130.[7] X. Li, M. Ammar, S. Paul, “Video Multicast over the Internet”, IEEE Network, March/April 1999, pp. 46-60 [8] E. Brewer et al., “A Network Architecture for Heterogeneous Mobile Computing”, IEEE Personal Communications Magazine, October 1998, pp. 8-24[9] E. Amir, S. McCanne, R. Katz, “An Active Service Framework and its Application to Real-time Multimedia Transcoding”, Proceedings of ACM SIGCOMM’98, Vancouver, British Columbia, September 1998[10] Y. Chawathe, S. Fink, S. McCanne, E. Brewer, “A Proxy Architecture for Reliable Multicast in Heterogeneous Environments”, Proceedings of ACM Multimedia '98, Bristol, UK, September 1998.[11] K. Jonas, M. Kretschmer, J. Moedeker, “Get a KISS —Communication Infrastructure for Streaming Services in a Heterogeneous Environment”, Proceedings of ACM Multimedia '98, Bristol, UK, September 1998[12] TINA Consortium, “Service Architecture”, June 1997, [13] T. Sikora, “MPEG-1 and MPEG-2 Digital Video Coding Standards”, http://wwwam.hhi.de/mpeg-video/papers/sikora/mpeg1_2/mpeg1_2.htm[14] R. Koenen, “MPEG-4 — Multimedia for Our Time”, IEEE Spectrum, Volume 36, Number 2, February 1999 [15] E. Amir, S. McCanne, H. Zhang, “An Application Level Video Gateway”, Proc. ACM Multimedia, San Fransisco, CA, USA, Nov. 1995, pp. 255-265[16] A. Fasbender, F. Reichert, E. Geulen, J. Hjelm, T. Wierlemann, “Any Network, Any Terminal, Anywhere”, IEEE Personal Communications, April 1999, pp. 22-30 [17] J. Solomon, “Mobile IP — The Internet Unplugged”, Prentice Hall, 1998[18] A. Fox, S. Gribble, E. Brewer, E. Amir, “Adapting to Network and Client Variability via On-Demand Dynamic Distillation”, ASPLOS-VII, Oct 1996, p. 160-170[19] N. Yeadon, A. Mauthe, F. Garcia, D. Hutchison, “QoS Filters: Addressing the Heterogeneity Gap”, Proc. of the Interactive Distributed Multimedia Systems and Telecommunication Services (IDMS’96), Berlin, Germany, May 1996[20] A. Balachandran, A. Campbell, M. Kounavis, “Active Filters: Delivering Scaled Media to Mobile Devices”, 7th International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV’97), May 1997, St. Louis, Missouri, USA。