HK1161499B - Group management in a communication network - Google Patents

Description

Group management in a communication network

Technical Field

The present invention relates to the field of group management in communication networks.

Background

In a communication network, a group refers to a grouping of users or devices. Taking a group of users as an example, an individual user may not belong to any group, belong to one group, or belong to multiple groups. Groups are used to simplify providing access or services to individual members of a group. For example, assume a company has 20 employees and two directory structures in a shared network. 5 users are allowed to access both directories and the remaining 15 are only allowed to access one directory. Without a group, the administrator would have to configure permissions for each individual user. However, by grouping users and granting permission to each group, permission may be granted. This very simple example shows how grouping users is an efficient way to allow access to services and networks.

Many groups are static and are defined by individually selecting group members based on certain criteria. However, dynamic groups can also be used. For example, a dynamic group may include users that are logged into a particular network at a particular time. Logging into the network is a criterion for group membership and thus the group will vary significantly depending on which members of the group are logged into at any one time.

The open mobile alliance (www.openmobilealliance.org) is working to develop architectural solutions for dynamic group management. As part of the architecture, logical nodes are identified to perform Uniform Resource Identifier (URI) selection based on certain conditions or criteria. The UR identifies the group members. The selection function contemplates selection of group members according to criteria (matching conditions) and then providing the requesting node with a set of group members that satisfy the criteria.

The selection function can access various information sources to make selections. The information may include static information (information that does not change frequently) available in a database (e.g., XML document management, address book, and user profile). The information may also include dynamic information that changes more frequently. Examples of dynamic information include information from a Presence Server (Presence Server) or a location Server.

The selection of URIs based on criteria/conditions can be performed as a one-time operation (e.g. only once at session start-up) or as a continuous monitoring of user information (e.g. during an ongoing session).

The criteria/condition based URI selection function can be used by many services such as push to talk over cellular (PoC) or Instant Messaging (IM) services. Any session based group communication can use this functionality for group member management, such as selecting group members at session setup, adding or removing individuals to an active session (active session), sending messages to selected individuals, etc., all based on the selection result.

The standard/condition based URI selection function defined by OMA provides a list of URIs of group members that meet the standard/condition each time a selection is made. In many cases, this information is insufficient for the end user or service engine (service enabler) to decide on a populated group. For example, no information such as "why mary is in the list and john is not in the list" or suggestions of what actions to perform on those environments are provided.

Furthermore, when the source information changes (statically or dynamically), it is not sufficient to send a new URI list to the requesting node each time a change occurs. It is more useful to let the requesting node know which group members are added or removed, when these actions occur, why the actions occur, and what actions to take in response to the changes. Examples of the kinds of information that may change during a session include profile or preference changes, changes to a predefined list of group members, dynamic presence information changes, and so forth.

Disclosure of Invention

The inventors have recognized the limitations of the prior art group management notification mechanisms and devised new methods and devices.

According to a first aspect of the present invention, a method of performing group management in a communication network is provided. A network node receives a request from a requesting node to monitor a group comprising a plurality of group members. The request also contains at least one criterion to be monitored. The network node determines which group members meet the criteria and sends a notification message to the requesting node containing the identity of at least one group member meeting the criteria. The notification message also contains other criteria satisfaction information, the other criteria information containing the identity of the satisfied criteria.

As an option, the request is sent in a session initiation protocol SUBSCRIBE message and the notification message is sent in a session initiation protocol NOTIFY message.

The notification message optionally includes other criteria satisfaction information in an extended markup language element in the body of the session initiation protocol NOTIFY message.

The notification message is optionally sent before the session is established and contains the identities of all group members that meet the criteria. This provides the requesting node with a list of group members that meet the criteria at session start-up. Alternatively, the notification message is sent in case the state of the group members changes after the session has been established. The notification contains the identity of that group member. This allows changes to be reported dynamically to the requesting node without having to report the status of all group members.

Alternative examples of other criteria-satisfying information include information selected from any of the number of group members of the group that satisfy the criteria, location information for determining a change in group member status, presence information for determining a change in group member status, a reason for the change in group member status, a timestamp of when the change in group member status occurred, and whether the group member looked up using dynamic or static information.

According to a second aspect of the present invention, there is provided a requesting node for use in a communication network. A processor is provided for generating a request message requesting monitoring of a group comprising a plurality of group members.

The request contains at least one criterion to be monitored. The transmitter is arranged to send a request message to the network node and the receiver is arranged to receive a notification message. The notification message contains the identity of at least one group member that satisfies the criteria and also includes other criteria satisfaction information, the other criteria information containing the identity of the satisfied criteria.

The processor is optionally arranged to generate a session initiation protocol SUBSCRIBE request message and the notification message is optionally received as a session initiation protocol NOTIFY message.

According to a third aspect, a network node for use in a communication network is provided. A receiver is provided for receiving a request from a requesting node to monitor a group comprising a plurality of group members, the request containing at least one criterion to be monitored. The processor is configured to determine which group members meet the criteria. The transmitter is arranged to send a notification message to the requesting node containing the identity of at least one group member meeting the criteria. The notification message contains other criteria satisfaction information.

The transmitter is optionally arranged to send a notification message before the session is established and contains the identities of all group members that meet the criteria. Alternatively, the processor is arranged to initiate the sending of a notification message in case of a change of the status of a group member, the notification comprising the identity of that group member. Other optional examples of criteria meeting criteria include information selected from any of the number of group members of the group meeting the criteria, the reason for the change in group member status, a timestamp of when the change in group member status occurred, and whether the group members looked up using dynamic or static information.

Drawings

FIG. 1 is a signaling diagram illustrating one embodiment of the present invention;

FIG. 2 schematically illustrates in a block diagram a service engine node according to one embodiment of the present invention; and

FIG. 3 schematically illustrates in a block diagram a dynamic group engine node according to one embodiment of the invention.

Detailed Description

When the requesting node requests an update to the group membership status, the criteria satisfaction related information is sent in a notification sent to the requesting party. When requested, the logical node performing the criteria/condition-based URI selection function can include, for example, the following elements:

-the total number of group members that meet the criteria/conditions;

group members found by using static information, such as: predefined members in the list, search results from the database (address book, profile), and the reason and time for any change to the static information.

The status of group members that meet the dynamic criteria/conditions, details about which condition(s) are met (several conditions may be met by the group members), and the reason and time for any change to the static information.

To provide a criteria satisfied update for a requesting node, the SIP event Package (SIP eventpackage) as described in RFC 4575 "a SIP event Package for Conference State" can be extended. The SIP event package can be used by, for example, a conference notification service. The SIP event package of the conference notification service is mainly used to notify the subscriber set about the status of the conference participants. Note that even in case the application of the present invention does not directly relate to a conferencing service, it is possible to use this event package to inform the subscriber about the status of another entity, depending on a set of defined criteria, e.g. geographical location, presence status or other user or entity related information. Thus, the meeting scenario is used as an example in the following description, but it will be understood that the invention is equally applicable to any scenario in which the status of an entity is evaluated. A criteria/condition-based selection function may be used prior to establishing a conference in order to obtain information about which users meet given criteria.

In one embodiment of the invention, the standard to be evaluated uses RFC 4745 "CommonPolicy: a Document Format for Expressing Privacy Preferences ". A common policy defines a set of rules consisting of a set of conditions, a set of actions, and a set of transformations in one option. The conditions specify to whom actions and/or transformations are to be applied. This rule set is sent in the body of the initial SIP SUBSCRIBE request message.

The URI selection function uses an extension of the SIP event package of the conference state to send updated notifications according to the evaluation criteria used. The update is sent in the body of the SIP NOTIFY request. The mapping and use of different XML elements and attributes is as follows:

- < conference-info >: containing different information about the requested evaluation service.

-entity: this attribute contains a group URI, a list URI or an ad-hoc unique URI. This is the SIP URI that the requesting entity must subscribe to in order to get information about the dynamic standard.

-state: indicating whether the notification contains information about all entities participating in the conference ("full"), only information that has changed since the last time the notification was sent ("partial"), or whether the subscription has stopped existing or the target group of entities has been deleted ("deleted").

- < conference-description >: information is given about service groups or resource lists (when such groups are predefined).

- < display-text >: the display text of the service group or resource list,

- < subject >, < free-text >, < keywords > can fill in the information described in RFC 4575 when it can be extracted from a service group or a resource list.

- < conf-uris >: containing a set of URIs identifying the evaluated session,

- < service-uri >: contains a set of URIs that can be used for contact evaluation services, i.e., SIP URIs for which special evaluation services can be issued,

- < maximum-user-count >: the maximum number of users that the service can handle per session is defined. In the event that this number is exceeded, the service will apply local policies to determine to which users the service applies.

- < available-media >: this is not used.

- < host-info >: used in the same manner as in RFC 4575

- < conference-state >: state of the evaluation session is described:

- < user-count >: the number of users for evaluation is considered when receiving the subscription request, regardless of whether the users meet any criteria.

- < active >: indicating whether the evaluation session is active.

- < users >/< user >: a user that is part of the target group is described. The user is monitored to determine if the user meets any of the criteria.

-entity: this attribute contains the URI of the user in the evaluation session. This URI must be unique among all other participants in the target group.

-state: this attribute indicates whether the element contains full user information ("full"), contains only information that has changed since the previous notification ("partial"), or whether the user is no longer considered for evaluation.

- < display-text >: this element contains user-friendly text that is displayed to the end user. It can be extracted from the service group or from the resource list.

- < associated-individuals >: this element may contain an additional URI associated with the user, i.e., a TEL URI or an email address.

- < user >/< endpoint >: this element defines one of the devices used by the user. Typically, a user element will contain only one endpoint element.

-entity: this is the URI associated with this endpoint and must be unique in the user context. In SIP terminology, it will be a contact URI.

-state: this attribute indicates whether the element contains full endpoint information ("full"), contains only information that has changed since the previous notification ("partial"), or whether this endpoint is no longer considered for evaluation.

- < display-text >: this element contains the display text of the endpoint.

- < status >: as in RFC 4575, but if the user meets at least one of the given criteria, only 'connected', 'disconnected' and 'pending' will be used.

The elements < referred >, < joined-method >, < joined-info >, < disconnection-method >, < disconnection-info > and < media > are unused,

- < call-info > is used in the same way as described in RFC 4575

- < sidebar-by-ref > and < sidebar-by-val > were not used.

In addition, a new element is defined under the < endpoint > element:

- < rule-info >: containing information about which criteria the user met when the notification was sent out.

By way of example, to illustrate the present invention, fig. 1 is a signaling diagram illustrating one embodiment of the present invention. Fig. 1 shows a service engine 1, which is a requesting node that requests information about the status of conference participants. Dynamic group engine 2 (shown in fig. 1 as the Dyn-G engine) performs the function of evaluating the criteria and notifying service engine 1 as to which users meet the requested criteria and the changes of those users that meet the requested criteria. There is also a presence engine 3 to which Dyn-G engine 2 subscribes. The shared XDMS server 4 is used to provide a resource list to the Dyn-G engine 2, and the search proxy node 5 is used to perform XDM searches. The search proxy node 5 forwards the XDM search query to a specific XDM server in the network, which may contain the requested information, and combines all received responses. The Dyn-G engine 2 can then obtain the URI from the resource list obtained from the shared XDM server 4 and the URI from the result of the XDM search as targets of the evaluation criteria. The following numbering corresponds to that shown in figure 1:

s1.sip SUBSCRIBE request is sent from the service engine 1 to the dynamic group engine 2. This SUBSCRIBE message is to SUBSCRIBE to the OMA dynamic group. Com, with an entry for sip, aliceexample. This XDM search resolves to sip, bobexample. An example of a SUBSCRIBE message is as follows:

s2, the dynamic group engine 2 sends SIP200 OK response to the service engine 1. An example SIP200 OK message is as follows:

s3, analyzing the resource list: the dynamic group engine 2 gets a resource list from the shared XDMS server 4.

S4. when the dynamic group engine parses the < list-service >/< list > element, it finds the < drl: xsearch > entry. That indicates that an XDM search is required. The dynamic group engine performs the search using proxy search 5, where the query is provided in < drl: xsearch > entry. The search resolves to a single URI: com. sip. bobexample

S5. for each target URI provided by an entry in the < list-service >/< list > element, a SIP SUBSCRIBE request is sent from the dynamic group engine 2 to the presence engine 3. In this example, sip is statically specified to aliceexample. com, and sip is the result of an XDM search query to bobexample. com. An example SUBSCRIBE request is as follows:

s6.sip 200 OK response is sent from the presence engine 3 to the dynamic group engine 2. An example SIP200 OK is as follows:

s7.sip NOTIFY message is sent from the presence engine 3 to the dynamic group engine 2. The NOTIFY message confirms that the user status has been subscribed to and includes an initial list of group members that meet the criteria. An example SIP NOTIFY request is as follows:

s8.sip 200 OK response is sent from the dynamic group engine 2 to the presence engine. The example SIP200 OK response in this example is as follows:

s9.sip NOTIFY request is sent from the dynamic group engine 2 to the service engine 1. An example SIP notify request is as follows:

the SIP200 OK response is sent from the service engine 1 to the dynamic group engine 2. An example SIP200 OK response is as follows:

s11. the presence status of the target group member changes (in this case, the target group member is currently < sip: anexample. com >).

S12. the change of state triggers the sending of a SIP NOTIFY request from the presence engine 3 to the dynamic group engine 2. An example SIP NOTIFY request is as follows:

s13. sip200 OK response is sent from the dynamic group engine 2 to the presence engine 3. An example SIP200 OK response is as follows:

s14.sip NOTIFY request is sent from the dynamic group engine 3 to the service engine 1 to inform the service engine about the change of the target group member status. An example SIP NOTIFY request is as follows:

s15. sip200 OK response is sent from the service engine 1 to the dynamic group engine 2 as follows:

referring now to fig. 2, the service engine node 1 is provided with a processor 6 for generating a SIP SUBSCRIBE message as described at step S1, a transmitter 7 for sending the SIP SUBSCRIBE message to the dynamic group engine 2, and a receiver 8 for receiving the SIP notify message as described at S9 or S14 above.

Referring now to fig. 3, the dynamic group engine 2 is provided with a receiver 9 for receiving the SIP subscribe message described at step S1, a processor 10 for determining which group members satisfy the criteria, and a transmitter 11 for sending the SIP NOTIFY message described at steps S9 and S14 to the service engine 1.

The present invention makes the determination more flexible for requestors of the URI selection function based on the condition. If the requesting party is an end user (human), the information produced is richer and more suitable for flexible decisions. If the requestor is a service engine (automaton), different decision models can be used, depending on the nature of the service in combination with the additional < rule-info > element. The present invention makes the processing at the requestor more efficient because part of the notification mechanism informs the requestor what aspect of the target group member state has changed. The rich information provided in the notification can be used for different purposes than session management. One example may be the generation of a statistical report.

OMA list group extension：

The following is an example extension of the OMA shared group scheme to provide an extended resource list with dynamic entries such as XDM search and SIMPLE presence search.

Common policy extension

An example extension to the common policy scheme to provide dynamic conditions for presence and for additional SIP event encapsulation based on information of the geo-priv location is described below. The < dynamic-condition > element defines a set of criteria and may include:

- < xpath-condition >: the description is based on the condition of Xpath expression to be applied to the body receiving a NOTIFY request for a subscription issued to a given event package. This condition is satisfied if the Xpath expression does not return a null sequence.

- < location-condition >: a geographic shape is described. This condition is satisfied when the geographic shape derived from the location node overlaps with the geographic shape provided by this condition.

Conference encapsulation extensions：

An example extension of the conference package (conference package) is provided below. The extension provides a new element < rule-info > that contains information about which dynamic rule has been matched for each particular user.

The following abbreviations have been used:

IM instant messaging

PAG Presence and availability workgroup

PoC push-to-talk over cellular

URI uniform resource identifier

Dyn-G dynamic group

geo-priv Geographic Location/Privacy (Geographic Location/Privacy)

XPath XML path language

SIMPLE SIP for Instant messaging and Presence Leveraging Extensions (Instant messaging and Presence Leveraging Extensions)

It will be appreciated by a person skilled in the art that various modifications may be made to the embodiments described above without departing from the scope of the present invention as defined in the appended claims.

Claims (20)

1. A method of performing group management in a communication network, the method comprising:

receiving, at a network node, a request from a requesting node to monitor a group comprising a plurality of group members, the request containing at least one criterion to be monitored;

determining which group members meet the criteria;

sending a notification message to the requesting node containing an identity of at least one group member that satisfies the criteria, the notification message containing other criteria satisfaction information, the other criteria satisfaction information containing an identity of the satisfied criteria.

2. The method of claim 1, wherein the request from the requesting node is sent in a session initiation protocol SUBSCRIBE message and the notification message is sent in a session initiation protocol NOTIFY message.

3. A method as claimed in claim 1 or 2, wherein the notification message includes further criteria-fulfilment information in an extensible markup language element in the body of the session initiation protocol NOTIFY message.

4. A method according to claim 1 or 2, wherein the notification message is sent before the session is established and contains the identities of all group members that meet the criteria.

5. A method according to claim 3, wherein the notification message is sent before the session is established and contains the identities of all group members that meet the criteria.

6. A method according to claim 1 or 2, wherein the notification message is sent in the event of a change in the status of a group member, the notification containing the identity of that group member.

7. A method according to claim 3, wherein the notification message is sent in the event of a change in the status of a group member, the notification containing the identity of that group member.

8. A method as claimed in claim 1 or 2, wherein the other criteria-satisfying information comprises information selected from any one of:

location information for determining a change in group member status;

presence information for determining a change in group member status;

a number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.

9. A method as claimed in claim 3, wherein the other criteria-satisfying information comprises information selected from any one of:

location information for determining a change in group member status;

presence information for determining a change in group member status;

a number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.

10. The method of claim 4, wherein the other criteria-satisfying information comprises information selected from any one of:

location information for determining a change in group member status;

presence information for determining a change in group member status;

a number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.

11. The method of claim 5, wherein the other criteria-satisfying information comprises information selected from any one of:

location information for determining a change in group member status;

presence information for determining a change in group member status;

a number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.

12. The method of claim 6, wherein the other criteria-satisfying information comprises information selected from any one of:

location information for determining a change in group member status;

presence information for determining a change in group member status;

a number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.

13. The method of claim 7, wherein the other criteria-satisfying information comprises information selected from any one of:

location information for determining a change in group member status;

presence information for determining a change in group member status;

a number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.

14. A requesting node for use in a communication network, the requesting node comprising:

a processor configured to generate a request message requesting monitoring of a group comprising a plurality of group members, the request including at least one criterion to be monitored;

a transmitter for transmitting the request message to a network node;

a receiver for receiving a notification message comprising an identity of at least one group member meeting the criteria, the notification message comprising further criteria meeting information comprising the identity of the met criteria.

15. The requesting node of claim 14, wherein the processor is arranged to generate a session initiation protocol SUBSCRIBE request message and the notification message is received as a session initiation protocol NOTIFY message.

16. A network node for use in a communication network, the network node comprising:

a receiver for receiving a request from a requesting node to monitor a group comprising a plurality of group members, the request containing at least one criterion to be monitored;

a processor for determining which group members meet the criteria;

a transmitter for sending a notification message to the requesting node containing an identity of at least one group member that satisfies the criteria, the notification message containing other criteria satisfaction information.

17. A network node as claimed in claim 16, wherein the transmitter is arranged to send the notification message before a session is established, and the notification message contains the identities of all group members that meet the criteria.

18. A network node as claimed in claim 16 or 17, wherein the processor is arranged to initiate the sending of the notification message in the event of a change in the status of a group member, the notification comprising the identity of that group member.

19. A network node as claimed in claim 16 or 17, wherein the further criterion-satisfaction information comprises information selected from any one of:

the number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.

20. The network node of claim 18, wherein the other criteria-satisfying information comprises information selected from any one of:

the number of group members in the group that meet the criteria;

the reason for the change in group member status;

a timestamp of when the change to the group member status occurred; and

whether dynamic or static information is used to find the group members.