- Email: [email protected]
An advanced call model to support multimedia multiuser communications
Computer Communications 20 (1997) 500±506
An advanced call model to support multimedia multiuser communications Seungchul Park a, Yanghee Choi b a
Information and Telecommunications R&D Center, Hyundai Electronics Industries Co. Ltd., Bubal-eup, Ichon-si, Kyoungki-do, South Korea b Department of Computer Engineering, Seoul National University, Shinlim-dong, Kwanak-ku, Seoul, South Korea Received 18 July 1995; accepted 11 October 1996
Abstract Multimedia multiuser applications such as the desktop multimedia conference, computer supported cooperative working, tele-education, and tele-medicine require more complex and dynamic communication services than the conventional single-medium point-to-point applications. In order to support those applications effectively, the underlying communication system should be able to support more structured and dynamically controlled call control services. Otherwise, the complexity of managing complex communication services should be resolved by the applications, and this increases the burden of individual application development. This paper presents an advanced call model that defines how the underlying communication services can be abstracted, structured, and dynamically controlled in order to support the multimedia multiuser applications effectively. The concept of communication resource abstraction, and superior structuring and controlling capability of the proposed call model, allows various multimedia multiuser applications to be supported more effectively and flexibly in various communication environments. q 1997 Elsevier Science B.V. Keywords: Multimedia multiuser applications; Advanced call model
1. Introduction In the context of communication systems, a call can be defined as a dynamic association between the communicating users of an application and the communication service provider [1]. The conventional communication systems based on open systems interconnection (OSI), transmission control protocol, internetwork protocol (TCP/IP), systems network architecture (SNA) and so on support monolithic, point-to-point, and best-effort calls, which provide with difficulty more complex and dynamic communication services required by the emerging multimedia multiuser applications [1–6]. Multimedia multiuser applications, such as the multimedia conference, computer supported cooperative working, and tele-medicine, consist of multiple different media interactions that require different QoS (quality of service) and communication topologies. In the applications, multiple users possibly with different access capabilities may be involved. And the media configuration and number of communicating users of an application may be dynamically changed during communication. In order to support such applications effectively, the underlying communication system should be able to support more structured and dynamically controlled call control services. Otherwise, the complexity of managing complex communication services should be resolved by the 0140-3664/97/$17.00 q 1997 Elsevier Science B.V. All rights reserved PII S 01 40 - 36 6 4( 9 7) 0 00 3 6- 4
applications, and this increases the burden of individual application development. Many call models have been proposed for the development of multimedia multiuser communication systems. In Bellcore’s touring machine model [3], an application association is provided by a ‘session’ which consists of multiple ‘connectors’. The connector abstracts a communication bridge which may be accessed by communicating users in the IN, OUT, and IN–OUT modes. The OSI-based model [1], proposed by Twente University, enhanced the touring machine call (or session) model so as to allow relationship specification among the related communication services. Multi-flow conversation protocol [5] groups several related media ‘flows’ of different control characteristics into a ‘conversation’ that can be managed in an integrated way. The new transport protocol [4] introduced the concept of ‘transport call’ which may contain multiple point-to-point simplex, point-to-point duplex, or point-to-multipoint simplex ‘transport connections’ to support multimedia applications. Multimedia conference control (MMCC) [7] and conference control channel protocol (CCCP) [8] are well-known conference control protocols in the Internet environment. And intensive research effort has been devoted to develop a more advanced call control protocol for B-ISDN [2,6]. The main design objective of our call model is to move the burden of managing complex communication services to
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
501
Fig. 2. General call structure.
Fig. 1. Examples of communication topologies.
the underlying communication system from applications as much as possible. This is achieved by enhancing the structuring and controlling capability of the communication services of the call model. Another objective is to define the call model in an abstract way. This means that various communication services provided by various communication resources can be managed via the common control interface of the call model. This is achieved by the abstraction of communication resources as various typed objects. The proposed call model defines how the typed objects are structured within a call and how the structured calls are dynamically controlled. The call model presented in this paper does not give a detailed description of the call control operations, but specifies what kinds of operations are required for the dynamic control. The detailed protocol description for the call control operations defined in this paper can be found in [9].
2. TC type definition and resource abstraction Multimedia multiuser applications may require various communication topologies. Fig. 1 shows some examples of the well-known communication topologies. The PP_ simplex, PP_duplex, PM_simplex, and PM_duplex topologies are trivial. The MM_nplex communication topology is most general in the multipoint communications, where all data simultaneously sent by the users is directly transferred to the other users. In the MM_mixed_nplex topology, the data of all communicating users is mixed. This topology may be mainly used for the voice conference application service element that allows freemode speaking. The MM_switched_nplex topology can be used for the voice conference or live video distribution service element where the voice or video of only one user may be sent at
any moment. The user selection in this topology will be handled by the external floor control mechanism. The MM_lectured_nplex topology allows the lecturer to send data in any time, but the other users’ floors are switched. Other communication topologies may be additionally defined according to the application requirements. The characteristics of a communication service provided for an application can be determined according to the corresponding communication topology and the provided communication resource(s). Communication resources may include network resources, transport protocols, communication servers (data bridge, voice mixer, video switch), and so on. Different communication resources can be combined in different ways to support communication services of different communication topologies and QoS. Applications may choose suitable communication services according to their topological and QoS requirements. In our call model, the communication resources required to provide a communication service of a specific topology are defined as a typed object, called TC (transport connection). Various TC types can be defined according to the communication topologies and the types of communication resources provided. Applications may select one or more typed TCs according to their communication requirements. A TC is an atomically controlled dynamic object which can be activated, deactivated, extended, and reduced during communication. The QoS provided by the TC may be dynamically changed. The communicating users attached to a TC may have different access mode and QoS requirements. This means that a TC may support heterogeneous QoS users. Each communicating user’s access mode and access QoS may be dynamically changed, too. All TC types do not have the same behavioral characteristics. When a TC type is chosen, the behavioral constraints are inherently determined. The TC control services can be defined in an abstract way. The abstraction means that the control services can be defined independently from the specific TC types as
502
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
Fig. 3. Formal specification of the call structure.
well as the physical control interfaces of the underlying communication resources. Actually, the call control services presented in the following sections defines how the typed TCs can be controlled in an abstract way. How to map the abstract TC control services with the physical control interfaces of the corresponding communication resources is a TC type dependent matter. Therefore, the applications of the TC control services do not have to know how the underlying communication resources are actually configured and controlled. The TC type independence enables new TC types to be easily incorporated.
3. Call structure The call structure defines how the typed TCs can be controlled in an integrated manner in order to provide communication services for a multimedia multiuser application effectively. In our call model, an association between the communicating users involved in an application and the communication service provider is represented as a call. Therefore, the call is the largest control unit for the communication services provided for an application. Within a call, one or more typed TCs can be contained to support the data transfer services among the users attached to the call. The TCs of a call can be controlled individually. For more flexible control of the TCs, our call model allows some TCs of a call to be grouped as a GTC (grouped TC), an integrated control unit. A GTC can be a member of another GTC. That is, the nested grouping of TCs within a call is allowed. This means that the communication services provided for an application can be controlled at the TC level, GTC level, and call level. To support the relationships between the component service elements of an application (for example,
lip-sync and audio-activated video), the call model allows the relation objects to be specified among the related TCs and/or GTCs of a call. The relations are maintained during communication. Fig. 2 shows the general call structure of our call model. The users attached to a call have owner–responders relationship. The call owner is responsible for maintaining the call in a consistent manner. Our call model allows the users to access each component TC of the call in a different access mode and QoS. And each user may have different permission to modify the call structure. The call structure can be formally defined as in Fig. 3. Each call has a unique identifier (call_id). The call type attribute (call_type) specifies the degree of openness of the call to external users. In the PRIVATE call, only the call owner is allowed to attach new users to the ongoing call. In the CONTROLLED call, the call owner has the option of refusing a new user’s request to join the call. In the OPEN call, any external user can join the call. The definition of a call includes the specification of characteristics of the constituent TCs and/or GTCs and the relations among them. And the specification of characteristics of the attached users (call_user) is also included. Two or more users may be attached to a call. A call user is characterized by the service access point (SAP) address (user _SAP_addr), the right to modify the configuration of the call (modifiability), and the access rights for the subordinate TCs (TC_access_right). If the value of the modifiability attribute is ON, the user is allowed to add/delete TCs and GTCs to/from the call. A user’s access right for a TC is described by the access mode (access_mode) and access QoS (access_QoS) attributes. A user’s access QoS for a TC is constrained by the maximum QoS (TC_QoS) provided by the corresponding TC.
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
503
Fig. 4. The call-level control operations.
The characteristics of a TC are represented by the TC identifier (TC_id), TC type (TC_type), TC QoS (TC_QoS) attributes, and the characteristics of the attached users. The TC identifier should be unique within a call. The TC_type attribute specifies the type of the TC. The TC_QoS attribute specifies the maximum QoS provided by the TC. A TC user (TC_user) is characterized by the SAP address (user_SAP_ addr) and the access right for the TC (TC_access_right). Since the users of a TC are always a subset of the users of its parent object, call or GTC, it is not necessary to specify the TC user information when the TC is described as a subordinate object of a call or GTC. The characteristics of a GTC are represented by a unique GTC identifier (GTC_id), the characteristics of the subordinate TCs and/or GTCs, the characteristics of the relation objects, and the characteristics of the attached GTC users. A GTC user is represented by the SAP address and the access rights for the subordinate TCs. When a GTC is described as a subordinate object of a call or another GTC, the GTC user information is not needed as in the TC case. The relation object is represented by a unique relation identifier (relation_id), relation type, and the identifiers of the related TCs and/or GTCs.
4. Call control operations The operations to control the structured call can be categorized into the call-level operations, TC-level operations, and GTC-level operations. The call-level operations control all subordinate TCs and/or GTCs of a call in an integrated manner. The TC-level operations control the designated TCs of a call individually. Similarly, the GTC-level operations control the designated GTC of a call individually. Fig. 4 shows the call-level control operations. A user (initiator) can establish a call with one or more users by using the establish_call()operation. The meaning of the parameters specifying characteristics of the call to be established is the same as in the definition of Fig. 3. The initiator will become the owner of the established call. A call can be
terminated via the release_call() and the abort_call() operations by the call owner. The release_call() terminates the call only when all communicating users agree on the termination, whereas the abort_call() always terminates the identified call. For these operations, the call_id and the reason for termination are given as the parameters. The add_user_to_call() operation is used when the call owner wants to invite external users to the existing call. As in the establish_call() operation, the characteristics of the call users to be added are given as the parameters of the operation. The delete_user_from_call() operation is used to exclude some existing users from the call by the call owner. The users to be excluded can be identified by the corresponding SAP addresses. The join_call() operation allows an external user to join an existing call. The call identifier and the SAP address of the call owner are given as the parameters of the operation. The request to join a call can be refused by the call owner if the call type is CONTROLLED, and this operation cannot be applied to the PRIVATE calls. Communicating users can leave the call by using the leave_call() operation. The change_call_owner() operation is used when the call owner wants to shift the ownership to another user, identified by the new_call_owner_SAP_addr parameter. The user_to_user _signal() operation is prepared for transferring applicationlevel control information among the communicating users. The TC-level control operations are defined as in Fig. 5. A new TC can be added to a call via the add_TC() operation by a permitted user. The TC can be added as a subordinate object of a specific GTC identified by the target_GTC_id, or as a direct subordinate object of the call. The characteristics of the TC are specified by the parameters of the operation. The owner of a TC (creator) can delete the TC from the call by using the delete_TC() and the abort_TC() operations. The delete_TC() operation deletes the TC only when the TC users agree on the deletion, whereas the abort_TC() operation always deletes the TC from the call. The add_User_to_TC() operation allows the TC owner to attach some users of the call, who are not involved in the TC, to the TC. The characteristics of the TC users to be
504
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
Fig. 5. The TC-level control operations.
added are given as parameters of the operation. The delete_user_from_TC() operation is used when the TC owner wants to exclude some existing users from the TC. The join_TC() operation allows a call user who is not involved in a TC to join the TC. The request to join the TC can be refused by the TC owner. The communicating users can leave a TC at any time by using the leave_call() operation without leaving the call. By using the change_ access_right() operation, a communicating user can change the access right for a TC. The TC owner can change the QoS of the TC via the change_QoS() operation. The request_ floor(), assign_floor(), return_floor(), and grab_floor() operations are used for the floor control for a TC. A user can request the floor for a TC to the TC owner by using the request_floor() operation. By using the assign_floor() operation, the TC owner can assign the floor for a TC to a specific user. The return_floor() operation is used by the user who wants to return the floor for a TC after finishing his work. The TC owner can grab the floor for a TC from the floor holder by using the grab_floor() operation at any time. The dynamic behavior of a GTC of a call can be con-
trolled by the GTC-level control operations specified in Fig. 6. The meaning of each operation is similar to the corresponding operation of the TC-level control operations. Since a GTC is just a logical container of TCs and/or other subordinate GTCs, it is independent of the actual data transmission. Thus, the actions for the access right change, QoS change, and floor control are not applicable to the GTCs.
5. Application: desktop multimedia conference case In general, the desktop multimedia conference application is composed of voice conference, live video distribution, shared working space, tele-pointer, and other miscellaneous service elements [1,5]. When a conference is activated, all data transport objects supporting necessary communication services for the constituent service element are activated. In our call model, this is simply enabled by invoking the establish_call() control operations. Multiple typed TCs correspondingly designated to the service elements may be specified as parameters of the call. The
Fig. 6. The GTC-level control operations.
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
destination users may also be specified. If necessary, synchronization relationship between the audio TC and video TC may be specified. After finishing the conference, the release_call() operation may be invoked to terminate all the constituent TCs. When the conference owner (call owner) wants to invite another user to the conference, he will just invoke the add_user_to_call() operation with the parameter of the designated user. Other call-level control operations can be similarly used. In the call establishment, the TCs for the audio conference and live video distribution can be grouped as a GTC so that they can be controlled in an integrated manner. In this case, when some participants may want to establish a subconference composed of audio conference and video distribution service elements for private communication, it will be enabled by just invoking the add_GTC() operation with parameters of audio and video TCs. The sub-conference may be extended to other users of the conference via the add_user_to_GTC() and/or the join_GTC() operation. Similarly it may be reduced via the delete_user_from_GTC() and/or leave_GTC() operation. After finishing private communication, the sub-conference can be terminated by invoking the delete_GTC() operation. When overall quality of the conference is decreased during the conference, the conference owner may want to delete the live video distribution service element to reduce the traffic burden. This will be enabled by invoking the delete_TC() operation with the TC identifier of the video TC. The conference owner may resume the video service by invoking the add_TC() control operation when the network condition is recovered. When the quality of the video service element is bad and related resources are available, the QoS of the video TC may be increased by invoking the change_QoS() operation. Some users of the conference may leave the live video service element without leaving the conference by invoking the leave_TC() operation. And the user may join the video service element later by invoking the join_TC() operation. When a user wants just to receive the video stream without sending his own video stream, he can change the access_ mode of the video TC to READ from READ–WRITE by invoking the change_access_right() operation. The request_floor(), assign_floor(), return_floor(), and grab _floor() operations may be used for the floor control of the switch type TCs.
6. Concluding remarks In this paper, we presented a new call model that supports multimedia multiuser applications more effectively. Since the proposed call model provides superior structuring and controlling capability of various communication services, various multimedia multiuser applications (from simple to complex) can be easily supported via the common interface of the call model. Moreover, since the call model is
505
defined in an abstract way, it can be easily applied to new communication environments, and easily extended to support new types of communication services. Based on the proposed call model, we developed an initial version of call control protocol and implemented it on an asynchronous transfer mode (ATM) environment that provides TCP/IP over ATM and native ATM application programming interface (API) [9]. The implementation was successfully used for the development of a desktop multimedia conference application. Currently we are trying to upgrade the call control protocol based on the feedback from the experimentation. The experimental implementation of the call control protocol will be extended as a generalpurpose multimedia multiuser communication platform.
References [1] G.J. Heijenk, X. Hou, G. Hiemegeers, Communication systems supporting multimedia multiuser applications, IEEE Network Magazine 8 (1) (1994) 34–44. [2] S. Minzer, A signaling protocol for complex multimedia services, IEEE Journal on Selected Areas in Communications 9 (9) (1991) 1383–1394. [3] M. Arango, L. Bahler, P. Bates, M. Cochinwala, D. Cohrs, R. Fish, G. Gopal, N. Griffith, G.E. Herman, T. Hickey, K.C. Lee, W.E. Leland, C. Lowery, V. Mak, J. Patterson, L. Ruston, M. Segal, R.C. Sekar, M.P. Vecchi, A. Weinrib and S-Y. Wuu, The touring machine system, Communications of the ACM 36 (1) (1993) 68–77. [4] L. Henckel, Multipeer transport services for multimedia applications, Proc. 5th IFIP Conference on High Performance Networking, Grenoble, France, June 1994, pp. 165–183. [5] R. Yavatkar, K. Kakshman, Communication support for distributed collaborative applications, Multimedia Systems 2 (2) (1994) 74–88. [6] L.A. Crutcher, A.G. Waters, Connection management for an ATM network, IEEE Network Magazine 6 (6) (1992) 42–55. [7] E.M. Schooler, A distributed architecture for multimedia conference control, ISI/RR-91-289, ISI, USC, USA, Nov. 1991. [8] M. Handley, I. Wakeman, J. Crowcroft, The conference control channel protocol (CCCP): a scalable base for building conference control applications, Proc. ACM SIGCOMM ’95, MA, USA, Aug. 1995, pp. 275–287. [9] S.C. Park, Call control and synchronization methods for multimedia multiuser communications, Ph.D. Thesis, Department of Computer Engineering, Seoul National University, Seoul, Korea, 1996. Seungchul Park received his B.S. in computer science and statistics from Seoul National University, M.S. in computer science from Korea Advanced Institute of Science and Technology, and Doctor of Engineering in Computer Engineering from Seoul National University, in 1985, 1987, and 1996 respectively. From 1987 to 1990 he was with the Electronics and Telecommunications Research Institute, where he served as research staff. He served as research staff in IBM Korea between 1990 and 1992. He was a research student at the Computer Network Research Center in the Research Institute of Advanced Computer Technology (RIACT) between 1992 and 1996. He is now leading the ATM software group at the Information and Telecommunications R&D Center of Hyundai Electronics Industries Co., Ltd. His research interests lie in the field of multimedia communication, B-ISDN, and network management.
506
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
Yanghee Choi received his B.S. in electronics engineering from Seoul National University, M.S. in electrical engineering from Korea Advanced Institute of Science, and Doctor of Engineering in Computer Science from Ecole Nationale Supe´rieure des Telecommunications (ENST) Paris, in 1975, 1977, and 1984 respectively. Before joining the department of Computer Engineering, Seoul National University, in 1991, he was with the Electronics and Telecommunications Research Institute between 1977 and 1991, where he served as director of the Data Communication Section and Protocol Engineering Center. He was a research student at the Centre National d’Etude des Telecommunications (CNET), Issy-lesMoulineaux, between 1981 and 1984. He was also Visiting Scientist to the IBM T.J. Watson Research Center for the year 1988–1989. He is now leading the Multimedia and Computer Communications Laboratory in Seoul National University. He is also director of the Computer Network Research Center in the Research Institute of Advanced Computer Technology (RIACT). His research interests lie in the field of multimedia systems and high-speed networking.
An advanced call model to support multimedia multiuser communications Seungchul Park a, Yanghee Choi b a
Information and Telecommunications R&D Center, Hyundai Electronics Industries Co. Ltd., Bubal-eup, Ichon-si, Kyoungki-do, South Korea b Department of Computer Engineering, Seoul National University, Shinlim-dong, Kwanak-ku, Seoul, South Korea Received 18 July 1995; accepted 11 October 1996
Abstract Multimedia multiuser applications such as the desktop multimedia conference, computer supported cooperative working, tele-education, and tele-medicine require more complex and dynamic communication services than the conventional single-medium point-to-point applications. In order to support those applications effectively, the underlying communication system should be able to support more structured and dynamically controlled call control services. Otherwise, the complexity of managing complex communication services should be resolved by the applications, and this increases the burden of individual application development. This paper presents an advanced call model that defines how the underlying communication services can be abstracted, structured, and dynamically controlled in order to support the multimedia multiuser applications effectively. The concept of communication resource abstraction, and superior structuring and controlling capability of the proposed call model, allows various multimedia multiuser applications to be supported more effectively and flexibly in various communication environments. q 1997 Elsevier Science B.V. Keywords: Multimedia multiuser applications; Advanced call model
1. Introduction In the context of communication systems, a call can be defined as a dynamic association between the communicating users of an application and the communication service provider [1]. The conventional communication systems based on open systems interconnection (OSI), transmission control protocol, internetwork protocol (TCP/IP), systems network architecture (SNA) and so on support monolithic, point-to-point, and best-effort calls, which provide with difficulty more complex and dynamic communication services required by the emerging multimedia multiuser applications [1–6]. Multimedia multiuser applications, such as the multimedia conference, computer supported cooperative working, and tele-medicine, consist of multiple different media interactions that require different QoS (quality of service) and communication topologies. In the applications, multiple users possibly with different access capabilities may be involved. And the media configuration and number of communicating users of an application may be dynamically changed during communication. In order to support such applications effectively, the underlying communication system should be able to support more structured and dynamically controlled call control services. Otherwise, the complexity of managing complex communication services should be resolved by the 0140-3664/97/$17.00 q 1997 Elsevier Science B.V. All rights reserved PII S 01 40 - 36 6 4( 9 7) 0 00 3 6- 4
applications, and this increases the burden of individual application development. Many call models have been proposed for the development of multimedia multiuser communication systems. In Bellcore’s touring machine model [3], an application association is provided by a ‘session’ which consists of multiple ‘connectors’. The connector abstracts a communication bridge which may be accessed by communicating users in the IN, OUT, and IN–OUT modes. The OSI-based model [1], proposed by Twente University, enhanced the touring machine call (or session) model so as to allow relationship specification among the related communication services. Multi-flow conversation protocol [5] groups several related media ‘flows’ of different control characteristics into a ‘conversation’ that can be managed in an integrated way. The new transport protocol [4] introduced the concept of ‘transport call’ which may contain multiple point-to-point simplex, point-to-point duplex, or point-to-multipoint simplex ‘transport connections’ to support multimedia applications. Multimedia conference control (MMCC) [7] and conference control channel protocol (CCCP) [8] are well-known conference control protocols in the Internet environment. And intensive research effort has been devoted to develop a more advanced call control protocol for B-ISDN [2,6]. The main design objective of our call model is to move the burden of managing complex communication services to
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
501
Fig. 2. General call structure.
Fig. 1. Examples of communication topologies.
the underlying communication system from applications as much as possible. This is achieved by enhancing the structuring and controlling capability of the communication services of the call model. Another objective is to define the call model in an abstract way. This means that various communication services provided by various communication resources can be managed via the common control interface of the call model. This is achieved by the abstraction of communication resources as various typed objects. The proposed call model defines how the typed objects are structured within a call and how the structured calls are dynamically controlled. The call model presented in this paper does not give a detailed description of the call control operations, but specifies what kinds of operations are required for the dynamic control. The detailed protocol description for the call control operations defined in this paper can be found in [9].
2. TC type definition and resource abstraction Multimedia multiuser applications may require various communication topologies. Fig. 1 shows some examples of the well-known communication topologies. The PP_ simplex, PP_duplex, PM_simplex, and PM_duplex topologies are trivial. The MM_nplex communication topology is most general in the multipoint communications, where all data simultaneously sent by the users is directly transferred to the other users. In the MM_mixed_nplex topology, the data of all communicating users is mixed. This topology may be mainly used for the voice conference application service element that allows freemode speaking. The MM_switched_nplex topology can be used for the voice conference or live video distribution service element where the voice or video of only one user may be sent at
any moment. The user selection in this topology will be handled by the external floor control mechanism. The MM_lectured_nplex topology allows the lecturer to send data in any time, but the other users’ floors are switched. Other communication topologies may be additionally defined according to the application requirements. The characteristics of a communication service provided for an application can be determined according to the corresponding communication topology and the provided communication resource(s). Communication resources may include network resources, transport protocols, communication servers (data bridge, voice mixer, video switch), and so on. Different communication resources can be combined in different ways to support communication services of different communication topologies and QoS. Applications may choose suitable communication services according to their topological and QoS requirements. In our call model, the communication resources required to provide a communication service of a specific topology are defined as a typed object, called TC (transport connection). Various TC types can be defined according to the communication topologies and the types of communication resources provided. Applications may select one or more typed TCs according to their communication requirements. A TC is an atomically controlled dynamic object which can be activated, deactivated, extended, and reduced during communication. The QoS provided by the TC may be dynamically changed. The communicating users attached to a TC may have different access mode and QoS requirements. This means that a TC may support heterogeneous QoS users. Each communicating user’s access mode and access QoS may be dynamically changed, too. All TC types do not have the same behavioral characteristics. When a TC type is chosen, the behavioral constraints are inherently determined. The TC control services can be defined in an abstract way. The abstraction means that the control services can be defined independently from the specific TC types as
502
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
Fig. 3. Formal specification of the call structure.
well as the physical control interfaces of the underlying communication resources. Actually, the call control services presented in the following sections defines how the typed TCs can be controlled in an abstract way. How to map the abstract TC control services with the physical control interfaces of the corresponding communication resources is a TC type dependent matter. Therefore, the applications of the TC control services do not have to know how the underlying communication resources are actually configured and controlled. The TC type independence enables new TC types to be easily incorporated.
3. Call structure The call structure defines how the typed TCs can be controlled in an integrated manner in order to provide communication services for a multimedia multiuser application effectively. In our call model, an association between the communicating users involved in an application and the communication service provider is represented as a call. Therefore, the call is the largest control unit for the communication services provided for an application. Within a call, one or more typed TCs can be contained to support the data transfer services among the users attached to the call. The TCs of a call can be controlled individually. For more flexible control of the TCs, our call model allows some TCs of a call to be grouped as a GTC (grouped TC), an integrated control unit. A GTC can be a member of another GTC. That is, the nested grouping of TCs within a call is allowed. This means that the communication services provided for an application can be controlled at the TC level, GTC level, and call level. To support the relationships between the component service elements of an application (for example,
lip-sync and audio-activated video), the call model allows the relation objects to be specified among the related TCs and/or GTCs of a call. The relations are maintained during communication. Fig. 2 shows the general call structure of our call model. The users attached to a call have owner–responders relationship. The call owner is responsible for maintaining the call in a consistent manner. Our call model allows the users to access each component TC of the call in a different access mode and QoS. And each user may have different permission to modify the call structure. The call structure can be formally defined as in Fig. 3. Each call has a unique identifier (call_id). The call type attribute (call_type) specifies the degree of openness of the call to external users. In the PRIVATE call, only the call owner is allowed to attach new users to the ongoing call. In the CONTROLLED call, the call owner has the option of refusing a new user’s request to join the call. In the OPEN call, any external user can join the call. The definition of a call includes the specification of characteristics of the constituent TCs and/or GTCs and the relations among them. And the specification of characteristics of the attached users (call_user) is also included. Two or more users may be attached to a call. A call user is characterized by the service access point (SAP) address (user _SAP_addr), the right to modify the configuration of the call (modifiability), and the access rights for the subordinate TCs (TC_access_right). If the value of the modifiability attribute is ON, the user is allowed to add/delete TCs and GTCs to/from the call. A user’s access right for a TC is described by the access mode (access_mode) and access QoS (access_QoS) attributes. A user’s access QoS for a TC is constrained by the maximum QoS (TC_QoS) provided by the corresponding TC.
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
503
Fig. 4. The call-level control operations.
The characteristics of a TC are represented by the TC identifier (TC_id), TC type (TC_type), TC QoS (TC_QoS) attributes, and the characteristics of the attached users. The TC identifier should be unique within a call. The TC_type attribute specifies the type of the TC. The TC_QoS attribute specifies the maximum QoS provided by the TC. A TC user (TC_user) is characterized by the SAP address (user_SAP_ addr) and the access right for the TC (TC_access_right). Since the users of a TC are always a subset of the users of its parent object, call or GTC, it is not necessary to specify the TC user information when the TC is described as a subordinate object of a call or GTC. The characteristics of a GTC are represented by a unique GTC identifier (GTC_id), the characteristics of the subordinate TCs and/or GTCs, the characteristics of the relation objects, and the characteristics of the attached GTC users. A GTC user is represented by the SAP address and the access rights for the subordinate TCs. When a GTC is described as a subordinate object of a call or another GTC, the GTC user information is not needed as in the TC case. The relation object is represented by a unique relation identifier (relation_id), relation type, and the identifiers of the related TCs and/or GTCs.
4. Call control operations The operations to control the structured call can be categorized into the call-level operations, TC-level operations, and GTC-level operations. The call-level operations control all subordinate TCs and/or GTCs of a call in an integrated manner. The TC-level operations control the designated TCs of a call individually. Similarly, the GTC-level operations control the designated GTC of a call individually. Fig. 4 shows the call-level control operations. A user (initiator) can establish a call with one or more users by using the establish_call()operation. The meaning of the parameters specifying characteristics of the call to be established is the same as in the definition of Fig. 3. The initiator will become the owner of the established call. A call can be
terminated via the release_call() and the abort_call() operations by the call owner. The release_call() terminates the call only when all communicating users agree on the termination, whereas the abort_call() always terminates the identified call. For these operations, the call_id and the reason for termination are given as the parameters. The add_user_to_call() operation is used when the call owner wants to invite external users to the existing call. As in the establish_call() operation, the characteristics of the call users to be added are given as the parameters of the operation. The delete_user_from_call() operation is used to exclude some existing users from the call by the call owner. The users to be excluded can be identified by the corresponding SAP addresses. The join_call() operation allows an external user to join an existing call. The call identifier and the SAP address of the call owner are given as the parameters of the operation. The request to join a call can be refused by the call owner if the call type is CONTROLLED, and this operation cannot be applied to the PRIVATE calls. Communicating users can leave the call by using the leave_call() operation. The change_call_owner() operation is used when the call owner wants to shift the ownership to another user, identified by the new_call_owner_SAP_addr parameter. The user_to_user _signal() operation is prepared for transferring applicationlevel control information among the communicating users. The TC-level control operations are defined as in Fig. 5. A new TC can be added to a call via the add_TC() operation by a permitted user. The TC can be added as a subordinate object of a specific GTC identified by the target_GTC_id, or as a direct subordinate object of the call. The characteristics of the TC are specified by the parameters of the operation. The owner of a TC (creator) can delete the TC from the call by using the delete_TC() and the abort_TC() operations. The delete_TC() operation deletes the TC only when the TC users agree on the deletion, whereas the abort_TC() operation always deletes the TC from the call. The add_User_to_TC() operation allows the TC owner to attach some users of the call, who are not involved in the TC, to the TC. The characteristics of the TC users to be
504
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
Fig. 5. The TC-level control operations.
added are given as parameters of the operation. The delete_user_from_TC() operation is used when the TC owner wants to exclude some existing users from the TC. The join_TC() operation allows a call user who is not involved in a TC to join the TC. The request to join the TC can be refused by the TC owner. The communicating users can leave a TC at any time by using the leave_call() operation without leaving the call. By using the change_ access_right() operation, a communicating user can change the access right for a TC. The TC owner can change the QoS of the TC via the change_QoS() operation. The request_ floor(), assign_floor(), return_floor(), and grab_floor() operations are used for the floor control for a TC. A user can request the floor for a TC to the TC owner by using the request_floor() operation. By using the assign_floor() operation, the TC owner can assign the floor for a TC to a specific user. The return_floor() operation is used by the user who wants to return the floor for a TC after finishing his work. The TC owner can grab the floor for a TC from the floor holder by using the grab_floor() operation at any time. The dynamic behavior of a GTC of a call can be con-
trolled by the GTC-level control operations specified in Fig. 6. The meaning of each operation is similar to the corresponding operation of the TC-level control operations. Since a GTC is just a logical container of TCs and/or other subordinate GTCs, it is independent of the actual data transmission. Thus, the actions for the access right change, QoS change, and floor control are not applicable to the GTCs.
5. Application: desktop multimedia conference case In general, the desktop multimedia conference application is composed of voice conference, live video distribution, shared working space, tele-pointer, and other miscellaneous service elements [1,5]. When a conference is activated, all data transport objects supporting necessary communication services for the constituent service element are activated. In our call model, this is simply enabled by invoking the establish_call() control operations. Multiple typed TCs correspondingly designated to the service elements may be specified as parameters of the call. The
Fig. 6. The GTC-level control operations.
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
destination users may also be specified. If necessary, synchronization relationship between the audio TC and video TC may be specified. After finishing the conference, the release_call() operation may be invoked to terminate all the constituent TCs. When the conference owner (call owner) wants to invite another user to the conference, he will just invoke the add_user_to_call() operation with the parameter of the designated user. Other call-level control operations can be similarly used. In the call establishment, the TCs for the audio conference and live video distribution can be grouped as a GTC so that they can be controlled in an integrated manner. In this case, when some participants may want to establish a subconference composed of audio conference and video distribution service elements for private communication, it will be enabled by just invoking the add_GTC() operation with parameters of audio and video TCs. The sub-conference may be extended to other users of the conference via the add_user_to_GTC() and/or the join_GTC() operation. Similarly it may be reduced via the delete_user_from_GTC() and/or leave_GTC() operation. After finishing private communication, the sub-conference can be terminated by invoking the delete_GTC() operation. When overall quality of the conference is decreased during the conference, the conference owner may want to delete the live video distribution service element to reduce the traffic burden. This will be enabled by invoking the delete_TC() operation with the TC identifier of the video TC. The conference owner may resume the video service by invoking the add_TC() control operation when the network condition is recovered. When the quality of the video service element is bad and related resources are available, the QoS of the video TC may be increased by invoking the change_QoS() operation. Some users of the conference may leave the live video service element without leaving the conference by invoking the leave_TC() operation. And the user may join the video service element later by invoking the join_TC() operation. When a user wants just to receive the video stream without sending his own video stream, he can change the access_ mode of the video TC to READ from READ–WRITE by invoking the change_access_right() operation. The request_floor(), assign_floor(), return_floor(), and grab _floor() operations may be used for the floor control of the switch type TCs.
6. Concluding remarks In this paper, we presented a new call model that supports multimedia multiuser applications more effectively. Since the proposed call model provides superior structuring and controlling capability of various communication services, various multimedia multiuser applications (from simple to complex) can be easily supported via the common interface of the call model. Moreover, since the call model is
505
defined in an abstract way, it can be easily applied to new communication environments, and easily extended to support new types of communication services. Based on the proposed call model, we developed an initial version of call control protocol and implemented it on an asynchronous transfer mode (ATM) environment that provides TCP/IP over ATM and native ATM application programming interface (API) [9]. The implementation was successfully used for the development of a desktop multimedia conference application. Currently we are trying to upgrade the call control protocol based on the feedback from the experimentation. The experimental implementation of the call control protocol will be extended as a generalpurpose multimedia multiuser communication platform.
References [1] G.J. Heijenk, X. Hou, G. Hiemegeers, Communication systems supporting multimedia multiuser applications, IEEE Network Magazine 8 (1) (1994) 34–44. [2] S. Minzer, A signaling protocol for complex multimedia services, IEEE Journal on Selected Areas in Communications 9 (9) (1991) 1383–1394. [3] M. Arango, L. Bahler, P. Bates, M. Cochinwala, D. Cohrs, R. Fish, G. Gopal, N. Griffith, G.E. Herman, T. Hickey, K.C. Lee, W.E. Leland, C. Lowery, V. Mak, J. Patterson, L. Ruston, M. Segal, R.C. Sekar, M.P. Vecchi, A. Weinrib and S-Y. Wuu, The touring machine system, Communications of the ACM 36 (1) (1993) 68–77. [4] L. Henckel, Multipeer transport services for multimedia applications, Proc. 5th IFIP Conference on High Performance Networking, Grenoble, France, June 1994, pp. 165–183. [5] R. Yavatkar, K. Kakshman, Communication support for distributed collaborative applications, Multimedia Systems 2 (2) (1994) 74–88. [6] L.A. Crutcher, A.G. Waters, Connection management for an ATM network, IEEE Network Magazine 6 (6) (1992) 42–55. [7] E.M. Schooler, A distributed architecture for multimedia conference control, ISI/RR-91-289, ISI, USC, USA, Nov. 1991. [8] M. Handley, I. Wakeman, J. Crowcroft, The conference control channel protocol (CCCP): a scalable base for building conference control applications, Proc. ACM SIGCOMM ’95, MA, USA, Aug. 1995, pp. 275–287. [9] S.C. Park, Call control and synchronization methods for multimedia multiuser communications, Ph.D. Thesis, Department of Computer Engineering, Seoul National University, Seoul, Korea, 1996. Seungchul Park received his B.S. in computer science and statistics from Seoul National University, M.S. in computer science from Korea Advanced Institute of Science and Technology, and Doctor of Engineering in Computer Engineering from Seoul National University, in 1985, 1987, and 1996 respectively. From 1987 to 1990 he was with the Electronics and Telecommunications Research Institute, where he served as research staff. He served as research staff in IBM Korea between 1990 and 1992. He was a research student at the Computer Network Research Center in the Research Institute of Advanced Computer Technology (RIACT) between 1992 and 1996. He is now leading the ATM software group at the Information and Telecommunications R&D Center of Hyundai Electronics Industries Co., Ltd. His research interests lie in the field of multimedia communication, B-ISDN, and network management.
506
S. Park, Y. Choi/Computer Communications 20 (1997) 500–506
Yanghee Choi received his B.S. in electronics engineering from Seoul National University, M.S. in electrical engineering from Korea Advanced Institute of Science, and Doctor of Engineering in Computer Science from Ecole Nationale Supe´rieure des Telecommunications (ENST) Paris, in 1975, 1977, and 1984 respectively. Before joining the department of Computer Engineering, Seoul National University, in 1991, he was with the Electronics and Telecommunications Research Institute between 1977 and 1991, where he served as director of the Data Communication Section and Protocol Engineering Center. He was a research student at the Centre National d’Etude des Telecommunications (CNET), Issy-lesMoulineaux, between 1981 and 1984. He was also Visiting Scientist to the IBM T.J. Watson Research Center for the year 1988–1989. He is now leading the Multimedia and Computer Communications Laboratory in Seoul National University. He is also director of the Computer Network Research Center in the Research Institute of Advanced Computer Technology (RIACT). His research interests lie in the field of multimedia systems and high-speed networking.