Inter-domain group-communications

The present invention relates to a group communication service, that is, a communication service involving two or more users (or service participants). The present invention relates to a method of delivering multicast data of a multicast service to different domains and a method of delivering multicast data to service participants in the domain. The present invention further relates to control nodes and systems that perform their respective methods.

IP Multimedia Subsystem (IMS) IMS is defined by 3GPP as a new subsystem, a new mobile network infrastructure that brings together data, voice, and mobile network technologies on top of IP-based infrastructure.

IMS was designed to bridge the gap between existing traditional telecommunications technology and Internet technology, which cannot be achieved by simply increasing bandwidth. This allows operators to provide new and innovative services that shareholders and end users expect.

IMS is specifically designed to enable and improve real-time multimedia mobile services such as rich voice services, video calling, messaging, conferencing, and push services. IMS is designed to enable user-to-user communication services through several key mechanisms, including session negotiation and management, quality of service (QoS), and mobility management. However, IMS enables more than real-time user-to-user services.

The mobile industry is in the process of transitioning from traditional voice and short message services-centric businesses to a wide range of new and exciting multimedia services and applications. Phones and messages can be complemented by next-generation person-to-person applications, which enable easier sharing of two-way wireless sessions (push-to-talk), view sharing, files, shared whiteboards, and multiplayer gaming experiences. Allows sharing. It also provides the ability to combine existing services in an exciting way, such as when adding multiplayer games during a push-to-talk session.

The IP Multimedia Subsystem (IMS) not only includes developments in cellular / wireless networks (see Non-Patent Document 1 available from http://www.3gpp.org), but also between mobile and solid-state devices. Enable new services with. Examples of such services include content sharing and messaging services between mobile terminals and PCs.

Push to Talk Over Cellular (PoC) One of the services that utilize the IMS infrastructure is a push-to-talk application such as Push-to-Talk Overcellular, which was developed and standardized by the Open Mobile Alliance (OMA).

Push-to-talk over cellular provides one-to-one and one-to-many voice communication services directly on the cell network. The idea is simple. PoC's "always-on" allows users to call individuals or groups at the push of a button. The availability of other users can be checked before making a call due to existing features. The phone is connected almost instantly and the receiver does not need to answer. Users of the Push-to-Talk service may be doing activities other than telephone, and can also communicate by listening to group traffic while they are busy. Users may be contacted by name or often want to speak to a group. PoCs are based on half-duplex voice-over IP (VoIP) technology using IP-enabled networks, which means that one participant can speak while another participant is receiving voice data.

Push-to-talk is not a substitute for any existing cellular service. It is a complementary service that allows operators to develop and distinguish their respective voice portfolios without modifying existing services.

OMA's PoC standard network architecture is based on a PoC application server (PoC AS) connected to the IP Multimedia Subsystem (IMS), as illustrated in Figure 10. IMS handles common features such as session initialization protocol (SIP) -based user authentication, call routing, and general charging.

In the following, refer to the OMA website http://www.openmobilealliance.org, and in particular, Non-Patent Document 2 and Non-Patent Document 3 (available from http://www.openmobilealliance.org).

The PoC application server handles application-specific tasks such as floor control (reserving talks to individual speakers). Provides an interface to operator provisioning and network management systems to create application-specific Charging Detail Records (CDRs). The push-to-talk user database contains the provided users and their service profiles. Users and talk groups can be placed in databases in organization-specific closed user groups to support the security and management capabilities required by business applications. Push-to-talk solutions can be extended to millions of user networks with several networked PoC application servers.

As shown in Figure 10, various cellular access networks are used to deliver PoC media data to PoC users. The cellular access network is called the PoC enabler. Examples of PoC enablers include 3GPP networks, GSM networks, or 3GPP networks. The architectural requirements for a 3GPP network as a PoC enabler will be clear from 3GPPTR23.979 (Non-Patent Document 4 available from http://www.3gpp.org).

Push-to-talk is based on multi-unicasting. Each sender client sends packet data traffic to a dedicated push-to-talk server, and in the case of a group call, the server replicates the traffic to all receivers. No multicasting is performed in the access or core network, and mobility management is performed by the wireless network. As a result, push-to-talk solutions run unnoticed by users on cellular and fixed networks. PoC call control and other signaling are based on IETF-defined SIP, and voice traffic is routed through an RTP / RTCP-based streaming bearer. Mobility is handled via (E) GPRS with support wide range roaming over GSM / WCDMA.

The PoC solution protocol stack is shown in Figure 11. At the application level, PoC applications are provided. For session-related signaling, SIP is typically used to establish, modify, or destroy a session. Transmission RTP / RTCP is commonly used for media. Protocols related to signaling and transmission SIP and RTP / RTCP are transmitted by UDP (TCP is also possible) and IP protocols. The IP packet is ultimately provided to service participants in different access networks using access network specific channels such as the 3GPP mobile channel.

Potential problem PoC services are based on a conference-centric, or central element, that controls communication, called a PoC application server (PoC AS). All participants are connected to the node, resulting in the star topology underlying the PoC service. As one of the main functions, PoC AS performs floor control, that is, controls the permission to speak. Participants who take the floor send audio data to the PoC AS, which delivers it to all other participants.

PoC AS typically runs as an IP Multimedia Subsystem (IMS) application server. Participants in the PoC service may be connected to the PoC AS through any IP connection access network (IP-CAN) that provides access to the IMS network. It also includes GPRS access, including GERAN and / or UTRAN radio access identified by the 3rd Generation Mobile Communication Standards Project (3GPP).

By using the PoC application server as the conference center, the service is easily (centralized) controlled. Group communication is realized using a large number of point-to-point connections. However, to increase the size of the group, this point-to-point connection property results in inefficient delivery of service data. The same data must be individually copied and transmitted to each participant. This is especially relevant for wireless participants who utilize less wireless resources to access services.

As described above, efficient distribution of group communication is required, especially when the size of the group is large and the wireless resources are small. It will be clear to utilize point-to-point transmission or multicasting whenever possible to avoid the inefficiencies of multiple point-to-point transmissions.

For GPRS-based IP-CAN to IMS networks, this functionality is provided by the Multimedia Broadcast / Multicast Service (MBMS). Establish a multicast distribution tree in the GPRS core network and use wireless broadcasts to efficiently send data to large groups of users. MBMS is supported on UTRAN and GERAN radio access networks.

The use of MBMS for IMS services, especially PoC, has recently been discussed in the 3GPP standardization group. This matter is addressed in the 3GPP work item, and each service requirement is defined in 3GPP TS22.228 (see Non-Patent Document 5 available from http://www.3gpp.org). Further technical proposals have been made on how to realize the use of MBMS in IMS services. However, recent discussions have focused on the use of MBMS within a network of local domains, eg, a single operator, representing only limited service scenarios.

In order to better understand the differences from the present invention and the prior art, it is necessary to understand the complete service scenario. In general, IMS services can span different domains with different operator networks, for example. This is also possible with PoC services. To support this interdomain scenario, PoC AS plays various logical and functional roles in PoC calls. The PoC AS either performs a control PoC function or a participating PoC function, or performs each function at the same time. The controlling PoC AS acts as a conference center that performs call control, and the participating PoC AS acts as a proxy that sends signaling and data between PoC users in the local domain and controlling PoC ASs in another domain. There is always one single controlling PoC AS, but there are many participating PoC ASs in PoC calls, such as in different operator domains. Normally, the PoC AS as the user initiating the PoC call acts as the controlling PoC AS.

Current standardization activities in this area are underway and not yet completed, but it is expected that the MBMS transmission function will be available for PoC services. The control element of MBMS is the Broadcast Multicast Service Center (BM-SC). The use of MBMS in PoC services is realized in various ways. A new interface may be established between the PoC AS and the BM-SC to allow dialogue between both (separate) elements. Another option is to integrate both functional modules into a single element. However, in terms of functionality, each option is the same.

As mentioned above, MBMS functionality is available within GPRS-based IP-CAN. Generally, it is under the control of a particular network operator. For the interdomain scenarios described above, PoC calls span a large number of operator domains, so support for MBMS transmission functionality results in the local characteristics of a particular PoC AS. Therefore, it must be considered that MBMS is not available in all PoC ASs involved in the call.

MBMS support in the network is one of the points to consider when using it in PoC services. Another point is that MBMS reception depends on the capabilities of the terminal. Some terminals, like PoC, may not be able to receive MBMS in parallel with the IMS service. Other terminals may not be able to receive MBMS at all. Therefore, it must also be assumed that MBMS cannot be supported by all PoC users.

The main problem that arises in the complete service scenario described above is due to the different functional roles of each PoC AS associated with the PoC call. Since support for MBMS transmission is a local characteristic of PoC AS, the controlling PoC AS does not know whether the participating PoC AS will take advantage of MBMS transmission functionality and presumes to be a point-to-point connected user.

Therefore (as already mentioned), the controlling PoC AS establishes an individual connection to each participant to the participating PoC AS and delivers individual copies of the incoming audio data. If the MBMS transmission functionality is used in the local domain, the participating PoC AS sends all audio data received on all connections to the BM-SC. Therefore, all individual copies of the same audio data are transmitted on the MBMS bearer. Since all participants in the local domain receive the MBMS bearer, each participant will receive all copies of the same audio data, not just once.

On the other hand, of course, unnecessary transmission of this copy of voice data is a waste of resources, especially on wireless interfaces. On the other hand, the reception of a large number of duplicate voice data on the terminal is not noticeable to the PoC user, which causes some problems in receiving the application.

Figure 12 illustrates the scenario and its potential problems.

As a result, unnecessary transmission of a copy of the audio data (1) Between control and participating PoC AS (2) Downlink MBMS bearer for PoC call Occurs in.

Another issue that arises in full service scenarios is related to deciding whether to utilize MBMS transmission functionality for PoC calls. PoC services enable group communication and MBMS efficiently distributes data to groups of users, but it may not be wise to use the available MBMS transmission functionality in all cases. Due to its characteristics, especially on the wireless interface, there is a trade-off between efficient data transmission and MBMS resource consumption.

Therefore, it makes sense to utilize MBMS transmission for large or dense groups of users. In this regard, it is important that accurate group information is available as the basis for MBMS decisions in PoC AS. This is the case for a controlling PoC AS that receives complete group information at the request of the starting PoC user. However, it is not seen in participating PoC ASs. Here, the group information must be derived from separate signaling messages, which can complicate the decision to use MBMS in PoC calls.<nplcit num="1"><text>3GPP TR 23.228 "IP Multimedia Subsystem (IMS); Stage 2", V. 7.2.0</text></nplcit><nplcit num="2"><text>OMA draft "Push to talk over Cellular (PoC) --Architecture", Candidate Version 1.0, 27 Jan. 2006</text></nplcit><nplcit num="3"><text>OMA draft "Push to talk over Cellular (PoC) --Architecture", Draft Version 2.0, 14 Mar. 2006</text></nplcit><nplcit num="4"><text>3GPP TR 23.979 "3GPP enablers for Open Mobile Alliance (OMA); Push-to-talk over Cellular (PoC) services; Stage 2", V. 6.2.0</text></nplcit><nplcit num="5"><text>3GPP TS 22.228, "Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1", V. 7.3.0</text></nplcit><nplcit num="6"><text>RFC 3261, "SIP: Session Initiation Protocol" by the IETF (Internet Engineering Task Force) from June 2002</text></nplcit><nplcit num="7"><text>RFC 3320, "Signaling Compression (SigComp)" of the IETF from January 2003</text></nplcit>

It is an object of the present invention to provide service participants with improved resource utilization in providing multicast services, especially PoC services.

This object is solved by the technical content of the independent claims. An advantageous embodiment of the present invention is the technical content of the dependent claims.

One main aspect of the present invention avoids unnecessarily increasing the multicast data in the distribution tree of the multicast service to service participants in different domains. For this purpose, the control node that starts the multicast service at the time of a request determined to which domain the multicast data should be provided sends the multicast data for each domain.

In another aspect of the invention, multicast data is prevented from being unnecessarily replicated within individual domains. According to this aspect, the control node of a domain obtains information about service participants receiving services within that domain, and the control node is within the domain or to provide multicast data to service participants within the domain. Whether to use the point-to-point link or the point-to-multicast link for each wireless access subsystem is determined for each domain or each wireless access subsystem. This behavior is advantageous because it allows for optimized resource utilization within the domain.

According to one embodiment of the present invention, there is provided a method of delivering multicast data of a multicast service to different domains. The control node of the first domain in a different domain receives a service start request that identifies the service participants participating in the multicast service. Based on the identification of the service participant, the domain to which the service participant belongs and is not controlled by the control node of the first domain is identified, and the multicast data is distributed to the control node of the domain identified for each domain.

In another embodiment of the invention, the control node sends a service start request to the identified control node. The service start request sent to the control node includes service participants belonging to each domain controlled by the control node. Notifying the control node of the identified domain about the service participant in each domain informs the most suitable transmission decision to be used in the domain to provide multicast data to the service participant in each domain. Is advantageous because it can be facilitated.

According to another embodiment, the control node of the first domain establishes a point-to-point link to each control node of the identified domain to which multicast data should be sent to each control node.

According to another embodiment of the invention, when delivering multicast data to the control nodes of each identified domain, a single copy of each of the multicast data is delivered to the control nodes of each domain via a point-to-point link. And further delivered to service participants in each domain. As described above, distributing multicast data on a domain-by-domain basis is advantageous in avoiding unnecessary duplication of multicast data on interfaces between control nodes in different domains. A single copy of each multicast data is delivered to the control nodes in each domain, even if there are multiple service participants in each domain.

According to a further embodiment of the invention, the control node (in the first domain) receives a negative response in response to a service start request from one of the identified domains. In response to a negative response, it sends an individual service start request to each service participant in the domain controlled by the control node in response to the negative response. This behavior is advantageous in that it provides compatibility with standard control nodes that have not been improved as described in the present application.

Another embodiment of the present invention relates to a method of delivering multicast data of a multicast service to service participants in a domain. A domain control node first receives a service start request from another domain control node. The service start request contains information about service participants participating in the multicast service located in the domain controlled by the control node. Based on the information about the service participants, the domain control node decides whether to use point-to-point links or point-to-multipoint links to deliver multicast data within the domain. Depending on this determination, the control node establishes point-to-point for each service participant in the domain or point-to-multipoint for service participant in the domain as a transmission medium for multicast data, and through the established transmission medium. Deliver multicast data to service participants in the domain.

When there are multiple wireless network subsystems within a domain, it is advantageous to determine which transmission medium to use for each wireless network subsystem instead of for each domain in order to further optimize resource utilization. is there. Therefore, in another embodiment of the invention, the control node determines at least one wireless network subsystem serving service participants. Decisions regarding the use of point-to-point links or point-to-multipoint links are made for each determined wireless network subsystem, and point-to-point links or point-to-multipoints for each service participant are each determined wireless network sub. Established for each system.

Another advantageous embodiment describes a change in the number of service participants in a domain or in a wireless network subsystem, for example, a new user joins or leaves the service due to user mobility. According to a typical embodiment, the transmission medium is switched from point-to-point link to point-to-multipoint link and vice versa, depending on the number of service participants currently participating in the multicast service in the domain. .. Alternatively, switching from a point-to-point link to a point-to-multipoint link may be made on a per-wireless network subsystem basis.

When using a point-to-multipoint link to deliver multicast data, another embodiment of the invention uses a domain-wide multicast service, such as MBMS, that is used to deliver multicast data in a domain. Predict. Typically, multicast services are provided by functional entities within a domain called a multicast service center. According to this embodiment, the domain control node sends multicast data to a multicast service center within the domain to utilize the multicast services available in the domain at the domain level or the wireless network subsystem level.

In another embodiment of the invention, the domain control node approves the service start request, i.e. provides affirmative or negative feedback in the form of an approval or error message.

Positive feedback replies establish point-to-point links with control nodes in other domains. In addition, the multicast service identifier is assigned to the link so that the data of the multicast service can be identified on the point-to-point link.

In a variant of this embodiment, the multicast service identifier is associated with the multicast service identifier used by the multicast service center in the domain to identify the multicast service data when delivered to service participants in the domain. This behavior is advantageous when different identifiers are used for multicast data when distributed between and within domains.

According to another embodiment of the invention, a domain control node generates a service start request for each service participant identified in a service start request received from a control node in another domain to service the domain. Send at least one generated service start request to the participant. This operation of the control node allows, among other things, to generate a service start request for a multicast service within an individual domain rather than the control node that receives the first service start request, for interdomain signaling between control nodes. Reduce the load.

In a typical variant of this embodiment, each service participant's service start request comprises a multicast service identifier that should be used by a multicast service center within the domain to identify the multicast service data. This is via a point-to-multicast link where the multicast data uses a special multicast service transmission mechanism within the domain (for example, MBMS that utilizes a unique service identifier (for example, a specific multicast address in the case of MBM)). This is especially advantageous when multicast data should be sent to service participants.

Another embodiment of the present invention relates to the efficient use of multicast services to provide multicast data within a domain. To support fast service activation of multicast services that provide multicast data to service participants, it is advantageous for the domain control node to apply for domain service participants to a multicast service center within the domain. For example, when using MBMS to provide multicast data to service participants, the control node applies for participants in the BM-SC of the domain.

A further embodiment of the present invention provides a control node for a first domain that distributes multicast data for multicast services to different domains. This control node is based on the receiver that receives the service start request that identifies the service participant participating in the multicast service and the control node of the first domain to which the service participant belongs based on the identification of the service participant. It comprises a processor that identifies uncontrolled domains. Further, the control node includes a transmitter that distributes multicast data to the control node of the domain identified for each domain.

Another embodiment of the present invention, circles multicast service to service participants in a domain related to the control node for distributing a multicasting data. This control node receives a service start request from a control node in another domain that contains information about service participants participating in the multicast service located in the domain controlled by the control node, and multicast data within the domain. Decide whether to use point-to-point links or point-to-multicast links to deliver data, based on information about service participants, and depending on the decision, point-to to each service participant in the domain. It comprises a processor that establishes point-to-multipoint for service participants in a point or domain as a medium for transmitting multicast data. In addition, the control node comprises a transmitter that delivers multicast data to service participants in the domain via an established transmission medium.

In another embodiment, the control node distributes the multicast data of the multicast service to different domains according to any of the above embodiments, or distributes the multicast data of the multicast service to service participants in the domain. Further provided means adapted to perform the steps of the method.

Another embodiment of the invention provides a system comprising at least one control node according to one typical embodiment of the invention.

Further, according to another embodiment, the present invention, when executed by the processor of the control node of the first domain of a different domain, stores a computer read in which the control node stores an instruction to distribute the multicast data of the multicast service to different domains. Provide a possible medium. The control node receives a service start request that identifies a service participant participating in the multicast service, and based on the service participant's identification, the domain to which the service participant belongs and is not controlled by the control node of the first domain. Multicast data is delivered by identifying and delivering multicast data to the control node of the domain identified for each domain.

According to a further embodiment of the present invention, when executed by a control node of a domain, the control node is provided with a computer-readable medium that stores instructions for delivering multicast data for multicast services to service participants in the domain. A control node receives a service start request from a control node in another domain that contains information about service participants participating in a multicast service located in a domain controlled by the control node, and distributes multicast data within the domain. Decide whether to use point-to-point links or point-to-multicast links based on information about service participants, and depending on the decision, each service participant in the domain is point-to-point or in the domain. Multicast data for multicast services by establishing point-to-multipoint to service participants as a transmission medium for multicast data and delivering multicast data to service participants in the domain via the established transmission medium. To deliver.

Another embodiment, when executed by the control node of the first domain, is a method of delivering multicast data for a multicast service to different domains, or service participants within a domain, according to any of the above embodiments. The present invention relates to a computer-readable medium that further stores an instruction to cause a control node to execute a step of a method of distributing multicast data of a multicast service.

Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings. In the figure, similar or corresponding details are given the same reference numerals.

Hereinafter, various embodiments of the present invention that are partially related to PoC multicast services within the IMS network infrastructure via MBMS-enabled 3GPP wireless networks will be described. It should be understood that typical and specific embodiments are not intended to limit the underlying ideas of the invention to these specific embodiments. More detailed information in the background art is intended to illustrate possible network architectures and scenarios to which the principles of the invention apply.

The idea of the present invention is particularly applicable to multicast services that use a centralized approach in which a central element controls service communications. One of the main ideas of the present invention is to use a distributed approach instead of a centralized approach, in particular the features of multicast service control and distribution of multi-service data. Some functions typically performed by central control elements are distributed at the domain level, that is, functions that are handled more efficiently at the domain level are at the control nodes of each domain where service participants receiving multicast services are located. Be distributed. Another aspect of the idea involves the exchange of information necessary for a control node to perform a new function.

Distributing functionality at the domain level reduces signaling overhead and optimizes resource utilization between and within domain control nodes, as will be more apparent from the typical embodiments described below. be able to.

It will be appreciated that the solutions according to the various embodiments of the invention described herein are used in favor of, for example, IMS services such as PoCs in which service participants belong to different management domains. A domain in the sense of the present application is a group of computers and devices on a network that are managed as units according to common rules and procedures. Normally, all equipment on the network is owned and maintained by a particular network operator.

Two major drawbacks of traditional PoC services are identified in this application. First, the controlling PoC AS has no knowledge of the transmission capabilities available within other domains in which PoC service data should be distributed. This leads to increased signaling load and service data load on the interface between the controlling PoC AS and the participating PoC AS.

Second, participating PoC ASs participate because they have no knowledge of service participants in their domain (or, at best, unreliable but derive that information from the SIP signaling sent). It is difficult (if not impossible) for PoC AS to select the optimal transmission mechanism within each domain in order to distribute PoC service data in each domain. Point-to-point links that consume "expensive" resources to distribute service data in participating PoC AS controlled domains are used because they are not aware of service participants in the domain, or of the same service data. Several copies are provided to service participants via the multicast service.

These drawbacks are generalized to multicast services that use a centralized approach similar to the PoC services described above.

To address the first drawback, in one embodiment of the invention, the control node that receives the service start request in the first domain determines the domain in which the service participant is located and distributes the multicast data of the service domain by domain. Propose to deliver to the control nodes of other determined domains (rather than per participant).

This idea will be described in more detail below with reference to FIGS. 1 and 4. FIG. 1 is a diagram showing a typical overlay network that provides service participants with data for an interdomain multicast service according to an embodiment of the present invention. FIG. 4 is a diagram showing signaling and data transfer between control nodes in different domains according to a typical embodiment of the present invention.

For illustrative purposes, assume that the multicast service configuration was requested by client 100. Client 100 sends a service start request to its control node, that is, control node 110 of domain # 1 in this example. The service start request identifies potential service participants who participate in the service.

The identification of service participants is realized by a unique ID that identifies each service participant. Alternatively, a group or list may be pre-configured that contains the appropriate identification of users belonging to the group or list. Each group or list may be individually assigned an ID that can be used by Client 100 to identify potential service participants.

For example, when SIP is used as the signaling protocol in the service configuration, the service start request may be, among other things, a SIP INVITE message identifying a service participant participating in the multicast service. Typically, SIP URIs can be used to identify participants. Details regarding the SIP protocol and message format are described in Non-Patent Document 6 available from http://www.ietf.org, which is incorporated herein by reference. Further, in order to reduce the size of the SIP message, the signaling compression described in Non-Patent Document 7, which is incorporated as a reference in the present application, may be used.

The control node 110 receives the service start request (step 401) and determines the domain to which the various service participants indicated in the request belong (step 402). Note that in general, a request from Client 100 indicates one or more service participants, that is, it is sufficient for at least two users to participate in the service.

In the example shown in Figure 1, it is assumed that the service start request identifies clients (service participants) 101 through 106. Therefore, control node 110 determines that participant 101 belongs to its own domain # 1, participants 102 and 103, and participants 104, 105, and 106 belong to domains # 2 and domain # 3, respectively. (402).

For example, when using a SIR URI as a service participant identifier, a different domain is determined from the host portion of the SIP URI that contains either the non-abbreviated domain name or the numeric IPv4 or IPv6 address. The domain of the SIP URI "joe@example.com" is determined to be "example.com".

The control node 110 then identifies the control nodes (here, control nodes 111 and 112) that serve to the identified domains, which are domains # 2 and domain # 3 in this example (403).

Identification of control nodes in different domains is achieved in a variety of ways. For example, control node 110 may use a preconfigured list of control nodes in other domains. Alternatively, the control node 110 may derive the information from previous (signaling) communication with other domains. Another option is to use some well-known name for the control node that can be used by service participants to start the service, such as "ConferenceFactory@example.com".

After identifying control nodes 111 and 112 in domains # 2 and # 3, control node 110 may optionally send a service start request message to control nodes 111 and 112, respectively. Each service start request message sent to control nodes 111 and 112 identifies a service participant in the domain controlled by each control node, that is, the service participant 102 in the request message sent to control node 112. And 103, service participants 104, 105, and 106 are identified in the request message sent to control node 111. As described in more detail below, the control node's service start request message may be sent to individual indicated service participants in the domain to establish a multicast service.

In principle, control node 110 only needs to identify different domains in which potential service participants are located to deliver multicast data at the domain-by-domain level. Upon receiving multicast data to be delivered to a service participant (eg, client 100) (406), control node 110 controls other domains to generate individual copies of the data and provide them to the service participant. Service data may be delivered to control nodes 111 and 112 of the "identified" domain instead of being provided to the nodes on a per-participant basis (407, 408).

As a result, only one copy of the multicast data is sent to each identified domain, so identifying the different domains to which the multicast data should be provided reduces the load (by signaling) of the multicast data delivery.

It is also advantageous to provide the control nodes of each domain with the identification of service participants within a domain, as described above and with reference to FIG. 5 (steps 404, 405 of FIG. 4). Strictly speaking, no identification is required for domains where participants do not have to be invited to the session and / or are not informed of the service's system resources. Nevertheless, in various embodiments of the invention, the identification of service participants is included in the service start request (steps 404, 405).

FIG. 5 is a diagram showing typical operation of a control node in a domain that enables an interdomain multicast service according to a typical embodiment of the present invention. For illustrative purposes, it is assumed that the control node of FIG. 5 corresponds to the control node of FIG. 4 and the control node 111 of FIG.

Upon receiving the service start request (404), the control node may generate an individual service start request for each service participant indicated in the service start request previously received by control node 111. At least one generated service start message is sent to service participants 104, 105, and 106 in domain # 2 (501).

For example, if SIP is used as the signaling protocol when configuring the service, the start request message may be a SIP INVITE message. Participants respond with an approval message in response to the service start message. If a service is locally established within domain # 2 between control node 111 and individual participants, control node 111 handles the response to that service start request. Otherwise, if a service session is established between control node 110 in domain # 1 and service participants in domain # 2, control node 111 will have service participants 104, 105, and in that domain. Send the response from 106 to control node 110 in domain # 1.

In addition, control node 111 in domain # 2 determines the delivery method used within the domain to deliver multicast service data to service participants 104, 105, and 106 (502). Since the service start request contains information about the service participants in the domain, the control node 111 may derive the number of service participants in the domain from the information.

In general, control node 111 determines if point-to-point links (eg, individual transmission channels or connections) are being used to provide service data to service participants 104, 105, and 106. Alternatively, a point-to-multipoint link (eg, a shared or common transmission channel) may be used for that purpose. Which of these two transmission methods is selected depends on the current load of the wired and / or air interface within the domain, the number of service participants receiving the multicast service in the domain or wireless network subsystem, and the like. Radio resource information may be available to control node 111 (or when using a domain-specific multicast service transmission mechanism for the multicast service center 301) to obtain appropriate criteria. For example, if the number of service users exceeds a given or defined threshold, control node 111 determines to use point-to-point links, otherwise it uses individual point-to-point links.

If the number of service participants fluctuates during service delivery, the delivery method may be triggered by an event (eg, when a participant joins / leaves, a participant hands over to another wireless network subsystem or network, etc.) or periodically. Is re-evaluated. If this evaluation shows that it is more efficient to use a different transmission mechanism, control node 111 will move the transmission mechanism from point-to-point link to point-to-multipoint link, or vice versa, if necessary. Switch.

After deciding which transmission mechanism to use, suitable resources are established in domain # 2. For example, when point-to-point links are used, control node 111 may initiate the establishment of individual channels or connections to individual service participants 104, 105, and 106. When point-to-multipoint links are used, common or shared channels may be established to serve participants 104, 105, and 106.

Another way to establish a point-to-multipoint link is to take advantage of the multicast service transmission mechanism already in place in the domain. For this purpose, a multicast service center 301 may be provided. The Multicast Service Center 301 is a functional or physical entity in a domain that is responsible for providing multicast services to users in a domain that utilize point-to-multipoint link connections. If the multicast service center is a functional entity, it may be located in the same network element as control node 111. An example of a multicast service mechanism is the MBMS of a 3GPP network, in which case the Multicast Service Center 301 corresponds to the BM-SC.

Figure 3 shows a typical structural overview of the domain that provides the multicast service transmission mechanism. Figure 3 corresponds to Figure 1 outside of domain # 2 and includes the Multicast Service Center 301.

Upon receiving the multicast data for the service at control node 111 (407), control node 111 distributes the multicast data to service participants 104, 105, and 106 within the domain (504). Note that control node 111 only needs to make a copy of the multicast data for distribution if point-to-point links are used.

Returning to FIGS. 1 and 3, the behavior of control node 112 in domain # 3 is similar to that of control node 111 in domain # 2. Further note that control nodes 111 and 112 in domains # 2 and # 3 can perform the actions of control node 110 in domain # 1 when they receive the first service start request from the client. Similarly, control node 110 of domain # 1 may perform the function of control node 111 of domain # 2 in the latter case.

In one embodiment of the present invention outlined in FIG. 5, which transmission mechanism is used is determined by the control node 111 for the entire domain # 2. However, as described below, this determination and switching between transmission mechanisms may be made for each wireless network subsystem as follows.

FIG. 2 is a typical overview of the network architecture of one of the different domains of FIG. 1 according to an embodiment of the present invention. In Figure 2, it is assumed that domain # 2 is a UMTS with a 3GPP network, eg, a core network consisting of GGSN201 and at least one SGSN202 (GGSN = gateway GPRS support node; SGSN = serving GPRS support node). The radio access network is connected to the core network via an interface between the SGSN202 and the RNC210, 211 (radio network controller) of the radio access network, respectively. Each RNC is typically connected to one or more nodes B215, 216, and 217 that send and receive data to and from mobile terminals 104, 105, 106.

In the current UMTS system, the RNC210 and 211 also take on the functions of establishing and controlling air interface resources because they terminate radio resource control. In this regard, RNC210, 211 also establish point-to-point links and / or point-to-multipoint links for service participants 104, 105, and 106. When MBMS services are available in the UMTS network (indicated by the BM-SC200 in the architecture), the RNC establishes a point-to-multipoint link at the terminal for each radio cell controlled by each node B.

Therefore, in this architecture, it is advantageous to determine the transmission mechanism used for distribution of multicast service data for each radio cell. In this embodiment of the invention, the wireless network subsystem corresponds to a wireless cell controlled by node B. Therefore, the system resources for the distribution of multicast data may be switched depending on the number of users who are currently receiving the multicast service in each cell.

In an alternative embodiment of the invention, the determination of the transmission mechanism may be made on a radio network subsystem basis, where the radio network subsystem is the RNC and the node B under its control (eg, RNC210). Defined as nodes B215 and 216). Similarly, switching of the transmission mechanism to be used during service provision may be performed at the wireless network subsystem level.

FIG. 6 shows a more typical behavior of control node 111 within domain # 2, which enables interdomain multicast services according to a typical embodiment of the present invention. In the embodiment typically illustrated in FIG. 6, which transmission mechanism is used for distribution of multicast service data within domain # 2 is determined for each wireless network subsystem.

As shown in FIG. 5, control node 111 first receives a service start request indicating a service participant located in domain # 2 (404) and sends it to service participants 104, 105, and 106 (501). ) Can generate individual service start requests.

Based on the service participant identification, control node 111 in domain # 2 determines which radio network subsystem the indicated participant belongs to (601).

For example, a wireless network subsystem may be defined at the wireless cell level, where control node 111 is served by node B216 with service participant 104 and service participants 105 and 106 with node B215. Judge that there is.

Based on this result, the control node 111 determines which transmission mechanism to use for each of the determined wireless network subsystems (602). For example, this determination is based on the number of service participants in each of the determined wireless network subsystems, as described above. Based on this determination, control node 111 further establishes suitable resources in the domain (603).

For example, if participants 105 and 106 are determined to be served over a point-to-point link, control node 111 thus provides a shared or common channel to the radio cell controlled by node B215. It may be established. When using the domain-specific multicast service transmission mechanism, the control node 111 starts providing the downlink multicast service via the multicast service center 301 and delivers it to the participants 105 and 106 via the point-to-multipoint link. Multicast data may be transferred to the multicast service center 301.

When the MBMS service function is used as the multicast service transmission mechanism, the control node 111 corresponding to the IMS application server or PoC application server in this example starts MBMS for participants 105 and 106. In this procedure, control node 111 registers participants 105 and 106 with the BM-SC200 to obtain the MBMS service multicast identifier (eg, IP multicast address) established by the BM-SC200. The multicast identifier may be included in the service start request sent to participants 105 and 106 to identify the resource that provides the multicast data to the participants.

For participant 104, control node 111 determines that it will use a point-to-point link for the multicast service. Therefore, an individual channel is established for participants 104.

Upon receiving the multicast data (407), control node 111 uses the established link to send a multicast service to participants in the domain.

Further details on how the network with the control node 111 and the multicast service center 301 operates (including the method of determining the transmission mechanism and its conditional switching) can be found in EP06001019.6, co-pending pending by the applicant of the present invention. Described in EFFICIENT MULTICAST SERVICE DATA PROVISION IN A MOBILE COMMUNICATION SYSTEM "(incorporated as a reference in this application) and EP06004868.3" EFFICIENT PROVISION OF A MULTICAST SERVICE BY SWITCHING BETWEEN MULTICAST SERVICES IN A MOBILE COMMUNICATION SYSTEM "(incorporated as a reference in this application). Ru. In these references, the control node corresponds to the IMS application server / PoC AS and the multicast service center corresponds to the BM-SC.

Hereinafter, a more detailed embodiment of the present invention will be schematically described using the PoC service as an exemplary embodiment of the multicast service. FIG. 8 shows a typical application of the principles of the invention to the realization of interdomain PoC services in an MBMS-enabled mobile communication system according to a typical embodiment of the invention.

As mentioned above, one aspect of the invention is to distribute functionality between nodes in different domains. In a PoC call to which this idea applies, certain functionality typically performed by a controlling PoC, such as call setup or session establishment, is delivered to the PoC AS in a different domain that accompanies the PoC call. means.

To facilitate the delivery of functionality, the controlling PoC AS may establish signaling dialogs with all participating PoC ASs in the required target domain. Within this dialog, the controlling PoC AS delivers each user group information to the participating PoC ASs and establishes a single individual connection between the elements in different domains (INVITE PoC-B [user list @ Domain B]). ..

Each participating PoC AS locally determines the PoC call data transmission strategy, including the use of MBMS transmission functionality (eg, whether or not the BM-SC transfers a talk burst via the MBMS service as shown in Figure 8). , Responsible for processing call configuration requests (INVITE UE-B1, ..., INVITE UE-Bn).

The control PoC AS may then transmit voice data that arrives only once via a single individual connection to each target domain (talk bursts transmitted from PoC-A to PoC-B). The local participation PoC AS is responsible for delivering data to each participant. When the MBMS transmission functionality is utilized, the participating PoC AS sends a single copy of the audio data (talk burst) to the BM-SC.

As a result, unnecessary transmission of a large number of copies of audio data is avoided. A further advantage is that reliable user group information is immediately available in participating PoC ASs, which can improve the decision to use MBMS for PoC calls.

In a variant of the method described in connection with FIG. 8, the initiating PoC user (UE-A) identifies the desired participant for the call in its SIP INVITE request. Upon receiving the message, the controlling PoC AS reviews the list and groups the requested users according to the domain, such as grouping into sublists for each domain. Instead of signaling each user individually, the controlling PoC AS sends a single SIP INVITE request containing the generated sublist to the PoC AS in each domain. The control PoC AS may use a well-known identity or previously acquired information to directly address the PoC AS in the target domain.

Upon receiving the message on a participating PoC AS in the target domain, the participating PoC AS does not perform the controlling PoC function instead of the standard participating PoC function because the request was received from another PoC AS in another domain. Judge that it should not be. The participating PoC AS uses the acquired group information to signal the requested PoC user and generate an appropriate SIP INVITE message. In addition, the participating PoC AS may use the group information in determining whether to use the MBMS transmission functionality for the requested PoC call.

The participating PoC AS sends an appropriate SIP response back to the controlling PoC AS in the other domain. This is done immediately after receiving each SIP INVITE request for the controlling PoC AS, or after receiving all responses from the signaled PoC user in the local domain. This behavior may also be due to the specific execution of the participating PoC AS. In either case, successful completion of the SIP dialog with the controlling PoC AS results in a single individual connection being established for media transmission between PoC ASs in different domains.

This procedure is performed for any target domain in the user group information of the start request received in the control PoC AS. As a result, there may be some individual connections between the controlling PoC AS and the participating PoC ASs in different domains. When the controlling PoC AS receives audio data from the PoC user, the controlling PoC AS utilizes a separate connection to deliver the data to the associated participating PoC AS exactly once. Given the use of MBMS in the target domain, the participating PoC AS sends a copy of the audio data to the BM-SC, which sends it to the PoC user in the local domain via the MBMS bearer. Therefore, all PoC users receive the audio data only once, avoiding unnecessary transmission of many copies of the same data.

FIG. 7 shows a signal diagram for establishing a PoC service in an MBMS-enabled mobile communication system according to a typical embodiment of the present invention. For exemplification purposes, services across two domains are assumed (this principle is applicable to services across several domains). In the first domain A, the PoC user (UE-A) initiates service to at least one participant in domain B (UE-B).

It typically shows the signaling flow, a single PoC user (UE-B) in the target domain. However, in the general case, there may be a number of different target domains hosting any number of requested participants. Furthermore, regarding the signaling flow, PoC users utilize GPRS-based IP-CAN to access their local IMS networks, and the target domain supports MBMS transmission functionality. For access to the IMS network, the initiating user does not need to use GPRS and any IP-CAN can be used as long as it provides access to the respective IMS network.

A suitable PDP context for IMS-related signaling if the user (UE-A) has not yet been assigned any IP address, and if necessary, an additional general purpose PDP with the same APN (access point name) and IP address. It ensures that the context is established as a PDP context for IMS-related signaling.

The terminal (UE-A) registers itself with the first IMS network (step 1). This registration is a prerequisite for access to all IMS services. If the user (UE-A) prefers to initiate a PoC call, then the user (UE-A) uses UE-B as the destination address in this example (alternatively, the destination address is for a PoC group session). PoC communication by sending an INVITE request to the IMS core (A) sent to the control PoC AS of PSI (Public Service Identity) hosted by the PoC server. Create a SIP session for it.

The INVITE request includes a PoC service display whose SDP media parameters indicate that the IP address obtained when the PDP context was established and that UE-A is ready to send and receive media (in this example, at the time of IMS registration). Suppose UE-A establishes a non-real-time PDP context for talk burst control and media). For ad hoc groups, the INVITE request also contains a list of requested users for the call. Routed to PoC AS (PoC-A) over the IMS network (A) (steps 3 and 4).

Upon receiving the SIP INVITE message, the PoC AS performs the controlling PoC function and, according to the present embodiment of the present invention, groups the received user list by target domain (step 5).

In the next step, the controlling PoC AS (PoC-A) generates a SIP INVITE message for the PoC AS in the target domain (PoC-B), including a list of requested users for the corresponding domain. This message is sent to the local IMS network and then routed to the desired PoC AS over the IMS network in the target domain (steps 6-8). In traditional systems, the PoC AS that receives the INVITE message performs the participating PoC function. However, because the message recognizes that an INVITE message was sent from another PoC AS in another domain, it recognizes that the PoC AS in domain B should perform control PoC functions regarding call setup and session establishment. To do.

Therefore, the participating PoC AS (PoC-B) generates a SIP INVITE message for each user listed in the message received from the controlling PoC AS (PoC-A). Since the domain supports MBMS transmission functionality, the participating PoC AS uses reliable group information to determine whether to use it for PoC calls (step 9).

For the illustrated signaling flow, the participating PoC AS (PoC-B) utilizes the existing MBMS transmission functionality for illustrative purposes. Therefore, the generated SIP INVITE message includes the configuration parameters of the MBMS bearer included in the MBMS user service description and the like. A PoC user in domain B receiving a message from a participating PoC AS (PoC-B) returns an appropriate response and activates the corresponding MBMS bearer in the GPRS network. If the terminal cannot support receiving MBMS bearers, it sends an error message to the participating PoC AS (PoC-B), which sets up a point-to-point link for the PoC user. This procedure (steps 10-14) is performed for each required participant in the local domain of the participating PoC AS (PoC-B).

The participating PoC AS (PoC-B) returns an appropriate response to the SIP INVITE request received from the controlling PoC AS (PoC-A) (steps 15-17). Depending on the execution of the participating PoC AS (PoC-B), it may be done after all the responses have been received from the PoC user, or already for the first response. In either case, an acknowledgment from the participating PoC AS (PoC-B) to the controlling PoC AS (PoC-A) establishes a single individual connection between the two elements. This connection is then used to exchange a single copy of voice data and for in-band signaling between PoC ASs in different domains (steps 24 and 34). Finally, the participating PoC AS (PoC-B) sends the audio data received from the controlling PoC AS to the associated BM-SC, which sends it to the PoC user in the local domain via an established MBMS bearer ( Steps 35 and 36).

The methods and systems according to the various embodiments of the invention described above assume that control nodes in different domains associated with a multicast session support improved applications and improvements in ideas and functionality, as described herein. ing.

As already mentioned, the multicast service may span different domains under the control of different operators. Therefore, it is assumed that all operators have performed the improved functionality described in the present application in their respective local domains.

For example, a single operator may not support the control PoC functionality delivered in that PoC AS. Moreover, for various reasons, it cannot be assumed that MBMS transmission functionality is available in all domains. No BM-SC may be placed or associated with the PoC AS, and the existing BM-SC may not provide the required resources for the PoC call.

Therefore, it is desirable to support traditional control nodes or domains without having specific multicast service transmission functionality.

FIG. 9 is typical of configuring interdomain PoC services according to a typical embodiment of the invention, while maintaining backwards compatibility with control nodes that are not operating according to a typical embodiment of the invention. It shows the signaling procedure. The participating PoC AS (PoC-B) in domain B is assumed to be a state-of-the-art PoC AS. Further, for illustrative purposes, it is assumed that no MBM transmission functionality is available in domain B. Note that the following steps do not change even if MBMS transmission functionality is available in Domain B.

The control PoC AS sends a single SIP INVITE message directed to the PoC AS in the target domain, including user group information in each domain, as described above.

If an existing PoC AS that does not support improved call control functionality is placed in target domain B, the PoC AS (PoC-B) rejects the SIP INVITE request received with the appropriate error message. According to the present embodiment of the present invention, when an error message is received from the PoC AS of the target domain, the control PoC AS is directed to a separate SIP INVITE for each requested PoC user according to standard PoC behavior. Send a message (INVITE B1, ..., INVITE Bn).

When an improved PoC AS without support for MBMS transmission functionality is deployed in the target domain, there are various ways to handle the request. The PoC AS may perform a controlling PoC function and then deliver the voice data received via individual point-to-point links to PoC users in the domain without notifying the controlling PoC AS. The PoC AS informs the controlling PoC AS about its local capabilities, and the controlling PoC AS can decide whether to establish individual or individual connections to the participating PoC ASs. Alternatively, the PoC AS rejects the request received as described above.

In either case, if the target domain supports improved call control functionality or MBMS transmission functionality, the first required PoC call is established.

As described in different embodiments of the present application, the delivered control node functionality is improved by using an innovative scheme, i.e., the control node first sends a single service start request message to the target domain. Attempt to use the type call control functionality. However, additional signaling occurs if it is not supported by the target domain.

Another possibility is to use a reaction scheme. In this variant according to another embodiment of the invention, the control node in the first domain sends a separate service start request directed to each requested service participant in another domain. This establishes a separate connection between the control nodes in the domain. If the control node in the target domain in which the service participant is located supports the use of a particular multicast transmission functionality (eg, MBMS transmission functionality), then in the response message sent in response to the received service start request message, the particular The control node of the requesting source domain may be notified that it supports multicast transmission functionality.

Based on this information, the control node in the source domain can generate a list of a set of users in the target domain. When receiving voice data from a service participant, only a single copy is delivered to the control node of the target domain for further delivery to the service participant in the target domain. For transmission, the control node of the source domain may choose one of the established connections mentioned above. The control node of the target domain transfers the received voice data to the multicast service center of the target domain for transmission to the local service participant via the point-to-multipoint bearer.

Typical behavior according to embodiments of the present invention may be used for PoC services. Only the control PoC functionality delivered when supported by the target domain is utilized without any prior knowledge of the domain.

However, establishing individual (unused) connections between the controlling PoC AS in the initiating source domain and the participating PoC AS in the target domain is considered a drawback in the embodiments of the present invention. In addition, participating PoC ASs will only get delayed and unreliable user group information. This complicates the decision to use MBMS for PoC calls in participating PoC ASs.

Another embodiment of the invention relates to performing the various embodiments described above using hardware and software. It is recognized that various embodiments of the present invention may be performed or implemented using a computer device (processor). The arithmetic unit or processor may be a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable array (FPGA) or other programmable logic unit. Various embodiments of the present invention may be implemented or embodied by a combination of these devices.

Further, various embodiments of the present invention may be performed using software modules that are executed directly by a processor or by hardware. A combination of software modules and hardware execution is also possible. Software modules can be stored in all types of computer-readable storage media such as RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROMs, DVDs and the like.

<figref num="1">The figure which shows the typical overlay network which provides the data of the inter-domain multicast service to the service participant by embodiment of this invention.</figref><figref num="2">A typical schematic of a network architecture in one of the different domains of FIG. 1 according to an embodiment of the present invention.</figref><figref num="3">A diagram illustrating another typical overlay network that provides data for an interdomain multicast service to service participants according to another embodiment of the invention.</figref><figref num="4">Diagram showing signaling and data transfer between control nodes in different domains according to a typical embodiment of the invention.</figref><figref num="5">The figure which shows the typical operation of the control node in a domain which enables the inter-domain multicast service by the typical embodiment of this invention.</figref><figref num="6">The figure which shows the typical operation of the control node in a domain which enables the inter-domain multicast service by the typical embodiment of this invention.</figref><figref num="7">A signal diagram for establishing a PoC service in an MBMS-compatible mobile communication system according to a typical embodiment of the present invention.</figref><figref num="8">The figure which shows the typical application of the principle of this invention to the realization of the inter-domain PoC service in the MBMS-enabled mobile communication system by the typical embodiment of this invention.</figref><figref num="9">A typical signaling procedure for configuring interdomain PoC services according to a typical embodiment of the invention, while maintaining backwards compatibility with a control node that is not operating according to a typical embodiment of the invention. Figure shown</figref><figref num="10">Diagram showing a typical network architecture that enables IMS services</figref><figref num="11">Diagram showing a typical protocol stack that enables PoC IMS services</figref><figref num="12">Diagram showing typical signaling procedures that enable interdomain PoC services</figref>