« PreviousContinue »
SYSTEM AND METHOD FOR CONTROLLING AND MANAGING SESSIONS BETWEEN ENDPOINTS IN A COMMUNICATIONS SYSTEM
REFERENCE TO RELATED APPLICATIONS
The present application is related to the following U.S. applications commonly owned together with this application by Motorola, Inc.: 10
Ser. No. 10/334,635, filed Dec. 31, 2002, 2002, now U.S. Pat. No. 7, 023, 813, titled "Methods for Managing a Pool of Multicast Addresses and Allocating Addresses in a Communications System" by Newberg, et al.;
Ser. No. 10/334,523, filed Dec. 31, 2002, now U.S. Pat. 15 No. 6, 798, 755 titled" Apparatus and Method for Controlling and Managing Individual Directed Sessions in a Communications System" by Lillie, et al.;
Ser. No. 10/334,439, filed Dec. 31, 2002, titled "Methods for Affiliating Endpoints with a Group and Determining 20 Common Communication Capabilities for the Affiliated Endpoints" by Newberg, et al.;
Ser. No. 10/334,521, filed Dec. 31, 2002, titled "Method and System for Group Communication" by Lillie, et al.;
1 FIELD OF THE INVENTION 25 The present invention relates generally to apparatus and
methods for enabling a group directed session between at least two endpoints in a communications system.
2 BACKGROUND OF THE INVENTION Multimedia and group communications have become an 30
important aspect of telecommunications, and the demand for such continues to increase. For instance, the Final Report of the Public Safety Wireless Advisory Committee to the Federal Communications Committee ("FCC"), dated 1996, expressed the critical need for communication resources for 35 multimedia. Subsequently in 1998, the FCC established a band plan for the 764 MHz frequencies that included spectrum set aside for public safety wideband. In addition, the Internet Engineering Task Force ("IETF") has developed a suite of protocols that are designed for use in multimedia 40 communications. These protocols include a Session Initiation Protocol ("SIP"), a Session Announcement Protocol ("SAP"), and a Session Description Protocol ("SDP").
Since its approval in early 1999 as an official standard, SIP has gained tremendous market acceptance for signaling 45 communications services on the Internet. As such, numerous products incorporate the SIP standard, including but not limited to SIP desktop telephones, SIP telephony servers, and personal computing ("PC") devices running SIP applications. SIP is a text-based signaling transactional protocol, 50 similar to Hypertext Transfer Protocol ("HTTP") and Simple Mail Transfer Protocol ("SMTP"), and works in the Application layer of the Open Systems Interconnection ("OSI") communications model. A SIP message is used to control interactive communications sessions, such as voice, video, 55 and chat, between users (also referred to herein as callers) in a communications network. Each user is typically associated with a communications device (also referred to herein as a terminal device) that is connected to the network.
SIP was designed for controlling media sessions and for 60 establishing media sessions between an initiating endpoint and one recipient endpoint or a small group of recipient endpoints. However, SIP is not readily scalable for establishing media sessions between an initiating endpoint and a large group of recipient endpoints. This is because in stan- 65 dard SIP, three messages (INVITE/OK/ACK) must be exchanged between the initiating endpoint and each recipi
ent endpoint in a given group. If a group is particularly large, this excessive messaging could cause bandwidth and timing problems, which is not desirable for communications that are time sensitive, e.g., as in the area of public safety.
Known systems for group communication have attempted to use standard SIP for enabling group communications. To do this, these systems have implemented a call control architecture in accordance with a server-centric architecture 100 illustrated in FIG. 1. Architecture 100 may be included in a push-to-talk (PTT) communications system. Architecture 100 includes a service specific server 102 that may be, for instance a PTT server, communicatively coupled in the signaling path of an endpoint 104 and a group 110 comprising endpoints 112, 114, and 116.
Using this paradigm, group communication is supported by PTT server 102, which is known to endpoints 104, 112, 114, and 116 as the target for all call control signaling. To setup a session, an initiating endpoint must target a session request to the PTT server 102 by using its Internet Protocol (IP) address. Specifically, while the call control signaling utilized by in the session request may identify the group in some manner, routing to the PTT server 102 is accomplished by performing a domain name system (DNS) lookup and using network layer IP protocols. This approach is limited in that it ties group communication to specific servers, thereby, limiting a system's ability to perform load balancing and failure recovery and placing an additional burden on an initiating endpoint by requiring it to know not only the group name but the IP address of the correct server.
In addition, existing group communications approaches have limited scalability and performance because a distinct SIP call leg must be used to join each group member to a session. Thus, as the number of group members increases, more and more three-way signaling exchanges must be performed over shared wire-line and wireless links before session setup can be completed. For large groups, the serialization delays can increase call setup times beyond what is acceptable for certain systems, especially public safety dispatch systems.
One example of a system that uses SIP signaling in the above described limiting fashion for group communications is the system disclosed in WO0167674 A2 (09/518776), entitled METHOD AND APPARATUS FOR PARTICIPATING IN GROUP COMMUNICATION SERVICES IN AN EXISTING COMMUNICATION SYSTEM. The specification describes a PTT server that can be added to a packet data system to provide Voice Over IP (VoIP) group communication. When a terminal desires to communicate with a net (a group of endpoints), the terminal determines the IP address of the appropriate top level server using DNS to resolve the SIP server addresses into Internet network addresses, and sends a SIP INVITE to this server requesting a session with the net. This server is further the target of call control signaling, talker arbitration signaling, and media. In addition, only point-to-point SIP signaling is used.
Thus, there exists a need for a call control architecture that takes advantage of the application layer routing control of SIP to enable a user to initiate a session based only the name and domain of the target regardless of which particular terminals they happen to be using, but that further includes features to enable greater scalability and faster call set-up for large groups of users.
BRIEF DESCRIPTION OF THE FIGURES
A preferred embodiment of the invention is now described, by way of example only, with reference to the accompanying figures in which:
FIG. 1 illustrates a simple block diagram of a prior art call model architecture; 5
FIG. 2 illustrates a block diagram of a call model architecture in accordance with the present invention;
FIG. 3 illustrates a layered view of the call model architecture in accordance with the present invention illustrated in FIG. 2; 10
FIG. 4 illustrates a layered view of the call model architecture in accordance with the present invention illustrated in FIG. 2;
FIG. 5 illustrates a method according to the present 15 invention for generating a set of common communications capabilities for a group;
FIG. 6 illustrates a method according to the present invention for affiliating an endpoint with a group;
FIG. 7 illustrates a method according to the present 20 invention for managing a pool of multicast addresses; and
FIG. 8 illustrates a method according to the present invention for enabling communications with an endpoint comprising a non-dispatch terminal.
DETAILED DESCRIPTION OF THE
It will be appreciated that for simplicity and clarity of 3Q illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to each other. Further, where considered appropriate, reference numerals have been repeated among the figures to indicate corre- 35 sponding elements.
FIG. 2 illustrates a call control architecture 200 comprising a number of entities and their communication paths for enabling communications between at least two endpoints in a communications system, in accordance with a preferred 40 embodiment of the present invention. Each endpoint typically comprises a logical entity, e.g., a user, and a physical counterpart, e.g., a terminal. Entities connected with solid black lines communicate using a transactional protocol or a broadcast protocol. The preferred transactional protocol is 45 SIP, and the preferred broadcast protocol is SAP. Other entities connected with dashed lines communicate using appropriate protocol known in the art. The architecture 200 is ideal for time critical communications systems such as public safety dispatch systems. 50
For enabling group communications between at least two endpoints (e.g., endpoints 240 and 242) architecture 200 comprises a session controller 206, a group database manager 208, and at least one group entity 210 that is named and addressable at the application layer. To further facilitate 55 application layer routing, architecture 200 preferably comprises a registration manager 202 and an application layer router 204 that is preferably a SIP proxy. Architecture 200 finally preferably includes a group entity manager 212, a parameter resolver 214, at least one individual proxy 216, an 60 individual proxy manager 218, a multicast address manager 220, a policy manager 224, a floor controller 230, a media manager 226, and a bandwidth manager 232. Architecture 200 is simplified for purposes of illustrating the present invention. However, those of ordinary skill in the art will 65 realize that architecture 200 may include a plurality of each illustrated entity as a function of the size of the system.
Architecture 200 is configured to be independent of an underlying network and air interface and relies on entities such as the bandwidth manager 232 for network specific functionality.
Architecture 200 can be viewed as being abstracted into three layers as shown in FIG. 3: a session signaling layer 304; a session services layer 306; and a Radio Access Network (RAN) layer 308. The session signaling layer 304 terminates session control signaling such as SIP, SAP, and SDP that may be used in combination to initiate, modify, and terminate sessions. The session signaling layer 304 further makes requests into and receives events, e.g., lack of bandwidth, from the session services layer 306. The session services layer 306 provides session services such as session interaction for prioritization and preemption and for features such as critical users. The session services layer 306 further enforces system policies such as allowing a user or a group to make a certain call type or to use a certain amount of bandwidth, and also provides in-session services such as floor control or media management services (e.g. transcoding) directly to an endpoint, e.g., endpoint 302. The RAN layer 308 is aware of an underlying wireline and wireless network implementations, e.g., a SAM (Scalable Adaptive Modulation) 310 and a Wireless Local Area Network (WLAN) 312, and provides network specific functionality to support the session services layer 306. This functionality includes bandwidth management for the various wired and wireless links and location management of the terminals in the system.
The layered view 300 is beneficial in that each of the layers can be modified independently of the other layers. For instance, the session signaling layer 304 could be changed without affecting the other layers, if use of a different call control protocol is desired. Moreover, such a layered approach enables architecture 200 to support various air interfaces and mobility schemes without affecting the session services or session signaling.
FIG. 4 illustrates a layered view 400 of architecture 200 as well as the allocation of the components of the architecture 200 to the various layers. The registration manager 202, group database manager 208, group entity 210, and individual proxy 216 are allocated to the session signaling layer 402. The session controller 206, media manager 226 and floor controller 230 are allocated to the session services layer 404, and the bandwidth manager 232 is allocated to the RAN layer 406. As will be explained in more detail below, the interfaces between the session controller 206 and the individual proxy 216, group entity 210, and bandwidth manager 232 provides flexibility to accommodate systems that use different RANs or different session signaling protocols. Moreover, this layered approach maintains the standard SIP transactional model from the point of view of the endpoints, thereby, simplifying inter-working with both dispatch and non-dispatch endpoints and enabling better leveraging of future SIP standards and products.
Architecture 200 preferably supports two types of session setup methods, confirmed and unconfirmed. In an unconfirmed session setup, session notifications to the endpoints are not acknowledged, which provides better scaling for large groups. All unconfirmed session setups are, thus, preferably automatically accepted by a target terminal without human intervention and without providing the target users an opportunity to decline the session or to indicate which terminal they would like to use. Unconfirmed session setup may be used, for instance, for mission critical group dispatch sessions since these sessions typically need to be
active within several hundred milliseconds, and session notifications could then broadcast out to the group.
Confirmed session setup is used when a response is expected or required from every target user or terminal. This type of session setup may be used, for instance, when a 5 session initiator wants to ensure: that the target endpoints are really in the session; that a session only goes to the terminals where a user is present; or that the target endpoints are ready to receive media. It should be noted that session setup could also be a combination of confirmed and unconfirmed, wherein a majority of session invitations are ideally unconfirmed, and only a few strategic or required users receive confirmed session invitations.
The preferred embodiment of each of the entities illus- 15 trated in FIG. 2 is described below, including its preferred functionality. Each entity preferably comprises a receiver for receiving information in the communications system, a transmitter for transmitting information in the communications network, and a processor for enabling the entity to 20 perform various functions.
Each endpoint in the system, e.g., endpoints 240, 242 and 246, comprise a unique user and terminal binding, wherein each terminal is preferably a dispatch terminal having the 25 minimum capabilities of PTT functionality to enable communication with the floor controller 230, being able to affiliate itself with a group, and being able to exchange media and control (SAP) via IP multicast. By contrast, non-dispatch terminals are unable to perform one or more of 3Q the above three functions. Thee endpoints preferably comprise both a SIP User Agent Client (UAC) and a SIP User Agent Server (UAS) to enable the endpoint to interact with the communications system to setup, modify, and take down either group directed or individual directed sessions, 35 wherein a group directed session is an invitation to a group, and an individual directed session in an invitation to at least one individual endpoint, e.g., point-to-point. In order to place or receive calls, an endpoint must first register with the system. Since SIP signaling is preferably utilized for all 4Q session control signaling, a SIP REGISTER method can be used, wherein all SIP REGISTER requests are preferably forwarded to the registration manager 202. If the endpoint desires to be member of a group, it must affiliate with that group using an AFFILIATE method, according to the 45 present invention, wherein all affiliation requests are preferably forwarded to the group database manager 208.
Endpoints are also preferably configured for receiving SAP announcements to inform the endpoint of the addition and removal of sessions within the context of a group, and 50 during a session, endpoints preferably interact directly with the floor controller 230 for the purpose of controlling the source for a particular session's media streams. The protocol used for floor control interaction is specified in the SDP as part of the SIP and SAP session signaling. 55
Turning to the session controller 206, it maintains the state for all sessions within its domain of control, e.g., there may be multiple session controllers in a multi-zone system, as a function of factors such as system resources, such as wireless and wireline bandwidth, endpoint resources, e.g., 60 whether an endpoint is currently participating in another session, and capabilities of target endpoints. The session controller 206 is responsible for determining whether or not a requested multimedia session can be established, and works with the bandwidth manager 232 to reserve band- 65 width and make the appropriate quality of service (QoS) reservations for a given session. The session controller 206
also works with the parameter resolver 214 to determine a corresponding set of session parameters usable during an accepted session.
The session controller 206 is preferably the one entity in the system with visibility into all sessions and the participants for all of the sessions. Therefore, it preferably uses information such as the critical users to determine whether they are available. Thus, if the critical users are not available, a session will be queued. In addition, session controller 206 may decide to pull a critical user out of a low priority session to place this user in another higher priority session. Furthermore, the session controller 206 preferably knows, either from the group database manager 208 or the registration manager 202, how many simultaneous sessions an endpoint can support and therefore whether it can join the session being setup.
Turning to the group entity 210, it is preferably a specialized SIP entity that combines a SIP UAC, a SIP UAS, and optionally a SAP session directory into a single entity. ITS SIP UAC and SIP UAS functionality enables a single point of control for group communications, and the SAP directory functionality enables increased scalability and performance.
Each group entity is also named and addressable at the application layer to enable endpoints to send SIP signaling to setup sessions with a group to the group's associated group entity. This feature distinguishes the present invention from the prior art server model discussed with respect to FIG. 1, wherein the server responsible for group communications is communicated with at the network layer.
Upon receiving a session request, the group entity 210 is preferably configured for determining the set of endpoints to pull into a session based on group affiliation information from the group database manager 208, and then for passing any requested session parameters and the capabilities for the group members to the session controller 206 with a request that a session be setup. If the session controller 206 grants the request, the group entity 210 signals the session setup to the affiliated endpoints either through a SIP INVITE message for confirmed session setup or via a session announcement protocol, such as multicast SAP announcements, for unconfirmed session setup.
Turning to the individual proxy 216, it is preferably a "stateful" SIP proxy that represents the signaling point of control through which the underlying session controller 206 can be accessed when an individual directed session (e.g. point-to-point) is setup between at least two endpoints. Each individual proxy 216 is instantiated by the individual proxy manager 218 on behalf of the requested session and has a life cycle equal to the session. The individual proxy 216 must insert itself into the SIP route set of an individual directed session to insure that all session control signaling passes through the individual proxy 216 for possible handling by the underlying session controller 206. To the rest of the system and, most importantly, to the endpoints, the SIP signaling looks like it is being sent end to end even though the individual proxy 216 may change the SDP or indicate that a session cannot proceed. This allows adherence to the SIP standard and possibly, better compatibility with standard SIP devices.
In operation, the individual proxy 216 intercepts a SIP INVITE message from an initiating endpoint's UAC and then preferably decides what endpoints to involve in the session based on the destination specified in the INVITE and system policy information. Different policies may specify that a user is called at all of their terminals, called at their mobile terminals, or called at only the terminal specified in