8 Affiliation

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1 General

Clause 8.2 contains the procedures for explicit affiliation at the MCData client.

Clause 8.3 contains the procedures for explicit affiliation at the MCData server serving the MCData user and the MCData server owning the MCData group.

Clause 8.3 contains the procedures for implicit affiliation at the MCData server serving the MCData user and the MCData server owning the MCData group.

Clause 8.4 describes the coding used for explicit affiliation.

The procedures for implicit affiliation in this clause are triggered at the MCData server serving the MCData user in the following circumstances:

– on receipt of a SIP MESSAGE request from an MCData client when initiating an MCData emergency alert targeted to an MCData group and the MCData client is not already affiliated to the MCData group; and

– on receipt of a SIP REGISTER request for service authorisation (as described in clause 7.3.2) or SIP PUBLISH request for service authorisation and service settings (as described in clause 7.3.3), as determined by configuration in the MCData user profile document as specified in 3GPP TS 24.484 [12].

The procedures for implicit affiliation in this clause are triggered at the MCData server owning the MCData group in the following circumstances:

– on receipt of a SIP MESSAGE request from the MCData server serving the MCData user when the MCData user initiates an MCData emergency alert targeted to an MCData group and the MCData client is not already affiliated to the MCData group.

8.2 MCData client procedures

8.2.1 General

The MCData client procedures consist of:

– an affiliation status change procedure;

– an affiliation status determination procedure;

– a procedure for sending affiliation status change request in negotiated mode to target MCData user;

– a procedure for receiving affiliation status change request in negotiated mode from authorized MCData user; and

– a rules based affiliation status change procedure.

In order to obtain information about success or rejection of changes triggered by the affiliation status change procedure for an MCData user, the MCData client needs to initiate the affiliation status determination procedure for the MCData user before starting the affiliation status change procedure for the MCData user.

8.2.2 Affiliation status change procedure

In order:

– to indicate that an MCData user is interested in one or more MCData group(s) at an MCData client;

– to indicate that the MCData user is no longer interested in one or more MCData group(s) at the MCData client;

– to refresh indication of an MCData user interest in one or more MCData group(s) at an MCData client due to near expiration of the expiration time of an MCData group with the affiliation status set to the "affiliated" state received in a SIP NOTIFY request in clause 8.2.3;

– to send an affiliation status change request in mandatory mode to another MCData user;

– to indicate that an MCData user is interested in one or more MCData group(s) at an MCData client triggered by a location or functional alias activation criteria;

– to indicate that the MCData user is no longer interested in one or more MCData group(s) at the MCData client client triggered by location or functional alias deactivation criteria; or

– any combination of the above;

the MCData client shall generate a SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34], and IETF RFC 3856 [39].

When the MCData user indicates that he is no longer interested in one or more MCData group(s) at the MCData client, the MCData client shall first check value of the <manual-deaffiliation-not-allowed-if-affiliation-rules-are-met> element if present within the MCData user profile document (see the MCData user profile document specified in 3GPP TS 24.484 [12]). If the affiliation to the group has been activated due to a rule being fulfilled and the <manual-deaffiliation-not-allowed-if-affiliation-rules-are-met> element is present and is set to a value of "true", the MCData client shall suppress the MCData user’s request.

NOTE 0: If the request is suppressed, a notification message can be displayed to the user.

In the SIP PUBLISH request, the MCData client:

1) shall set the Request-URI to the public service identity identifying the originating participating MCData function serving the MCData user;

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData client shall include the <mcdata-request-uri> element set to the MCData ID of the MCData user;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

4) if the targeted MCData user is interested in at least one MCData group at the targeted MCData client, shall set the Expires header field according to IETF RFC 3903 [34], to 4294967295;

NOTE 1: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if the targeted MCData user is no longer interested in any MCData group at the targeted MCData client, shall set the Expires header field according to IETF RFC 3903 [34], to zero; and

6) shall include an application/pidf+xml MIME body indicating per-user affiliation information according to clause 8.4.1. In the MIME body, the MCData client:

a) shall include all MCData groups where the targeted MCData user indicates its interest at the targeted MCData client;

b) shall include the MCData client ID of the targeted MCData client;

c) shall not include the "status" attribute and the "expires" attribute in the <affiliation> element; and

d) shall set the <p-id> child element of the <presence> root element to a globally unique value.

The MCData client shall send the SIP PUBLISH request according to 3GPP TS 24.229 [5].

8.2.3 Affiliation status determination procedure

NOTE 1: The MCData UE also uses this procedure to determine which MCData groups the MCData user successfully affiliated to.

In order to discover MCData groups:

1) which the MCData user at an MCData client is affiliated to; or

2) which another MCData user is affiliated to;

the MCData client shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36].

In the SIP SUBSCRIBE request, the MCData client:

1) shall set the Request-URI to the public service identity identifying the originating participating MCData function serving the MCData user;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

4) if the MCData client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 2: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if the MCData client wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [36], to zero; and

6) shall include an Accept header field containing the application/pidf+xml MIME type; and

7) if requesting MCData groups where the MCData user is affiliated to at the MCData client, shall include an application/simple-filter+xml MIME body indicating per-client restrictions of presence event package notification information according to clause 8.4.2, indicating the MCData client ID of the MCData client.

In order to re-subscribe or de-subscribe, the MCData client shall generate an in-dialog SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36]. In the SIP SUBSCRIBE request, the MCData client:

1) if the MCData client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 3: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

2) if the MCData client wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [36], to zero; and

3) shall include an Accept header field containing the application/pidf+xml MIME type.

Upon receiving a SIP NOTIFY request according to 3GPP TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36], if SIP NOTIFY request contains an application/pidf+xml MIME body indicating per-user affiliation information constructed according to clause 8.4.1, then the MCData client shall determine affiliation status of the MCData user for each MCData group at the MCData client(s) in the MIME body. If the <p-id> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request is included, the <p-id> element value indicates the SIP PUBLISH request which triggered sending of the SIP NOTIFY request.

8.2.4 Procedure for sending affiliation status change request in negotiated mode to target MCData user

NOTE: Procedure for sending affiliation status change request in negotiated mode to several target MCData users is not supported in this version of the specification.

Upon receiving a request from the MCData user to send an affiliation status change request in negotiated mode to a target MCData user, the MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6]. In the SIP MESSAGE request, the MCData client:

1) shall set the Request-URI to the public service identity identifying the originating participating MCData function serving the MCData user;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7] in the SIP MESSAGE request;

4) shall include an application/vnd.3gpp.mcdata-affiliation-command+xml MIME body as specified in Annex D.3; and

5) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [5].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCData client shall indicate to the user that the request has been delivered to an MCData client of the target MCData user.

8.2.5 Procedure for receiving affiliation status change request in negotiated mode from authorized MCData user

Upon receiving a SIP MESSAGE request containing:

1) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7]; and

2) an application/vnd.3gpp.mcdata-affiliation-command+xml MIME body with a list of MCData groups for affiliation under the <affiliate> element and a list of MCData groups for de-affiliation under the <de-affiliate> element;

then the MCData client:

1) shall send a 200 (OK) response to the SIP MESSAGE request;

2) shall seek confirmation of the list of MCData groups for affiliation and the list of MCData groups for de-affiliation, resulting in an accepted list of MCData groups for affiliation and an accepted list of MCData groups for de-affiliation; and

3) if the user accepts the request:

a) shall perform affiliation for each entry in the accepted list of MCData groups for affiliation for which the MCData client is not affiliated, as specified in clause 8.2.2; and

b) shall perform de-affiliation for each entry in the accepted list of MCData groups for de-affiliation for which the MCData client is affiliated, as specified in clause 8.2.2.

8.2.6 Rules based affiliation status change procedure

8.2.6.1 General

The MCData client can based on configuration decide to affiliate or de-affiliate to a group.

8.2.6.2 User profile defined rules

User profile based affiliation rules are controlled by the elements <RulesForAffiliation> or <RulesForDeaffiliation> of the MCData user profile document identified by the MCData ID of the MCData user (see the MCData user profile document specified in 3GPP TS 24.484 [12]). The rules can be composed of location criteria (including heading and speed) or functional alias based criteria. A rule is fulfilled if any of the location criteria and any of the functional alias based criteria are met. These rules are evaluated whenever a change of location occurs and whenever a functional alias is activated or deactivated. If any defined rule is fulfilled, the MCData client shall initiate the affiliation status change procedure as specified in clause 8.2.2.

NOTE: Hysteresis can be applied to location changes to avoid too frequent affiliation changes. In addition, the definition of area entry and exit criteria can be specified to provide a buffer space to minimize ping-ponging into and out of an area.

8.2.6.3 Group configuration defined rules

If the <permitted-geographic-area> element of the <list-service> element of an MCS group document is present and the MCData client is within the area specified in the <permitted-geographic-area> element, the MCData client is allowed to affiliate to the group.

If the <mandatory-geographic-area> element of the <list-service> element of an MCS group document is present and the MCData client is not within the area specified in the <mandatory-geographic-area> element the MCData client shall de-affiliate from the group.

8.3 MCData server procedures

8.3.1 General

The MCData server procedures consist of:

– procedures of MCData server serving the MCData user; and

– procedures of MCData server owning the MCData group.

8.3.2 Procedures of MCData server serving the MCData user

8.3.2.1 General

The procedures of MCData server serving the MCData user consist of:

– a receiving affiliation status change from MCData client procedure;

– a receiving subscription to affiliation status procedure;

– a sending notification of change of affiliation status procedure;

– a sending affiliation status change towards MCData server owning MCData group procedure;

– an affiliation status determination from MCData server owning MCData group procedure;

– a procedure for authorizing affiliation status change request in negotiated mode sent to served MCData user;

– a forwarding affiliation status change towards another MCData user procedure;

– a forwarding subscription to affiliation status towards another MCData user procedure

– an affiliation status determination procedure;

– an affiliation status change by implicit affiliation procedure;

– an implicit affiliation status change completion procedure;

– an implicit affiliation status change cancellation procedure; and

– an implicit affiliation to configured groups procedure.

8.3.2.2 Stored information

The MCData server shall maintain a list of MCData user information entries. The list of the MCData user information entries contains one MCData user information entry for each served MCData ID.

In each MCData user information entry, the MCData server shall maintain:

1) an MCData ID. This field uniquely identifies the MCData user information entry in the list of the MCData user information entries; and

2) a list of MCData client information entries.

In each MCData client information entry, the MCData server shall maintain:

1) an MCData client ID. This field uniquely identifies the MCData client information entry in the list of the MCData client information entries; and

2) a list of MCData group information entries.

In each MCData group information, the MCData server shall maintain:

1) an MCData group ID. This field uniquely identifies the MCData group information entry in the list of the MCData group information entries;

2) an affiliation status;

3) an expiration time;

4) an affiliating p-id; and

5) a next publishing time.

8.3.2.3 Receiving affiliation status change from MCData client procedure

Upon receiving a SIP PUBLISH request such that:

1) Request-URI of the SIP PUBLISH request contains either the public service identity identifying the originating participating MCData function serving the MCData user, or the public service identity identifying the terminating participating MCData function serving the MCData user;

2) the SIP PUBLISH request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the<mcdata-request-uri> element which identifies an MCData ID served by the MCData server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) the Event header field of the SIP PUBLISH request contains the "presence" event type; and

5) SIP PUBLISH request contains an application/pidf+xml MIME body indicating per-user affiliation information according to clause 8.4.1;

then the MCData server:

1) shall identify the served MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

2) if the Request-URI of the SIP PUBLISH request contains the public service identity identifying the originating participating MCData function serving the MCData user, shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP PUBLISH request;

3) if the Request-URI of the SIP PUBLISH request contains the public service identity identifying the terminating participating MCData function serving the MCData user, shall identify the originating MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

4) if the originating MCData ID is different than the served MCData ID and the originating MCData ID is not authorized to modify affiliation status of the served MCData ID, shall send a 403 (Forbidden) response and shall not continue with the rest of the steps;

5) if the Expires header field of the SIP PUBLISH request is not included or has nonzero value lower than 4294967295, shall send a SIP 423 (Interval Too Brief) response to the SIP PUBLISH request, where the SIP 423 (Interval Too Brief) response contains a Min-Expires header field set to 4294967295, and shall not continue with the rest of the steps;

6) if the Expires header field of the SIP PUBLISH request has nonzero value, shall determine the candidate expiration interval to according to IETF RFC 3903 [34];

7) if the Expires header field of the SIP PUBLISH request has zero value, shall set the candidate expiration interval to zero;

8) shall respond with SIP 200 (OK) response to the SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34]. In the SIP 200 (OK) response, the MCData server:

a) shall set the Expires header field according to IETF RFC 3903 [34], to the candidate expiration time;

9) if the "entity" attribute of the <presence> element of the application/pidf+xml MIME body of the SIP PUBLISH request is different than the served MCData ID, shall not continue with the rest of the steps;

10) shall identify the served MCData client ID in the "id" attribute of the <tuple> element of the <presence> element of the application/pidf+xml MIME body of the SIP PUBLISH request;

11) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

12) shall consider an MCData client information entry such that:

a) the MCData client information entry is in the list of MCData client information entries of the served MCData user information entry; and

b) the MCData client ID of the MCData client information entry is equal to the served MCData client ID;

as the served MCData client information entry;

13) shall consider a copy of the list of the MCData group information entries of the served MCData client information entry as the served list of the MCData group information entries;

14) if the candidate expiration interval is nonzero:

a) shall construct the candidate list of the MCData group information entries as follows:

i) for each MCData group ID which has an MCData group information entry in the served list of the MCData group information entries, such that the expiration time of the MCData group information entry has not expired yet, and which is indicated in a "group" attribute of an <affiliation> element of the <status> element of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request:

A) shall copy the MCData group information entry into a new MCData group information entry of the candidate list of the MCData group information entries;

B) if the affiliation status of the MCData group information entry is "deaffiliating" or "deaffiliated", shall set the affiliation status of the new MCData group information entry to the "affiliating" state and shall set the affiliating p-id of the new MCData group information entry to the value of the <p-id> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request; and

C) shall set the expiration time of the new MCData group information entry to the current time increased with the candidate expiration interval;

ii) for each MCData group ID which has an MCData group information entry in the served list of the MCData group information entries, such that the expiration time of the MCData group information entry has not expired yet, and which is not indicated in any "group" attribute of the <affiliation> element of the <status> element of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request:

A) shall copy the MCData group information entry into a new MCData group information entry of the candidate list of the MCData group information entries; and

B) if the affiliation status of the MCData group information entry is "affiliated" or "affiliating":

– shall set the affiliation status of the new MCData group information entry to the "de-affiliating" state; and

– shall set the expiration time of the new MCData group information entry to the current time increased with twice the value of timer F; and

iii) for each MCData group ID:

A) which does not have an MCData group information entry in the served list of the MCData group information entries; or

B) which has an MCData group information entry in the served list of the MCData group information entries, such that the expiration time of the MCData group information entry has already expired;

and which is indicated in a "group" element of the <affiliation> element of the <status> element of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request:

A) shall add a new MCData group information entry in the candidate list of the MCData group information list for the MCData group ID;

B) shall set the affiliation status of the new MCData group information entry to the "affiliating" state;

C) shall set the expiration time of the new MCData group information entry to the current time increased with the candidate expiration interval; and

D) shall set the affiliating p-id of the new MCData group information entry to the value of the <p-id> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request;

b) determine the candidate number of MCData group IDs as number of different MCData group IDs which have an MCData group information entry:

i) in the candidate list of the MCData group information entries; or

ii) in the list of the MCData group information entries of an MCData client information entry such that:

A) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry; and

B) the MCData client ID of the MCData client information entry is not equal to the served MCData client ID;

with the affiliation status set to the "affiliating" state or the "affiliated" state and with the expiration time which has not expired yet; and

c) if the candidate number of MCData group IDs is bigger than N2 value of the served MCData ID, shall based on MCData service provider policy reduce the candidate MCData group IDs to that equal to N2;

NOTE: The MCData service provider policy can determine to remove an MCData group ID based on the order it appeared in the PUBLISH request or based on the importance or priority of the MCData group or some other policy to determine which MCData groups are preferred.

15) if the candidate expiration interval is zero, constructs the candidate list of the MCData group information entries as follows:

a) for each MCData group ID which has an entry in the served list of the MCData group information entries:

i) shall copy the MCData group entry of the served list of the MCData group information into a new MCData group information entry of the candidate list of the MCData group information entries;

ii) shall set the affiliation status of the new MCData group information entry to the "de-affiliating" state; and

iii) shall set the expiration time of the new MCData group information entry to the current time increased with twice the value of timer F;

16) shall replace the list of the MCData group information entries stored in the served MCData client information entry with the candidate list of the MCData group information entries;

17) shall perform the procedures specified in clause 8.3.2.6 for the served MCData ID and each MCData group ID:

a) which does not have an MCData group information entry in the served list of the MCData group information entries and which has an MCData group information entry in the candidate list of the MCData group information entries with the affiliation status set to the "affiliating" state;

b) which has an MCData group information entry in the served list of the MCData group information entries with the expiration time already expired, and which has an MCData group information entry in the candidate list of the MCData group information entries with the affiliation status set to the "affiliating" state;

c) which has an MCData group information entry in the served list of the MCData group information entries with the affiliation status set to the "deaffiliating" state or the "deaffiliated" state and with the expiration time not expired yet, and which has an MCData group information entry in the candidate list of the MCData group information entries with the affiliation status set to the "affiliating" state; or

d) which has an MCData group information entry in the served list of the MCData group information entries with the affiliation status set to the "affiliated" state and with the expiration time not expired yet, and which has an MCData group information entry in the candidate list of the MCData group information entries with the affiliation status set to the "de-affiliating" state;

18) shall identify the handled p-id in the <p-id> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request; and

19) shall perform the procedures specified in clause 8.3.2.5 for the served MCData ID.

8.3.2.4 Receiving subscription to affiliation status procedure

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains either the public service identity identifying the originating participating MCData function serving the MCData user, or the public service identity identifying the terminating participating MCData function serving the MCData user;

2) the SIP SUBSCRIBE request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the<mcdata-request-uri> element which identifies an MCData ID served by the MCData server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7]; and

4) the Event header field of the SIP SUBSCRIBE request contains the "presence" event type;

the MCData server:

1) shall identify the served MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

2) if the Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the originating participating MCData function serving the MCData user, shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP SUBSCRIBE request;

3) if the Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the terminating participating MCData function serving the MCData user, shall identify the originating MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

5) shall generate a 200 (OK) response to the SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36].

For the duration of the subscription, the MCData server shall notify the subscriber about changes of the information of the served MCData ID, as described in clause 8.3.2.5.

8.3.2.5 Sending notification of change of affiliation status procedure

In order to notify the subscriber about changes of the served MCData ID, the MCData server:

1) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

2) shall consider the list of the MCData client information entries of the served MCData user information entry as the served list of the MCData client information entries;

3) shall generate an application/pidf+xml MIME body indicating per-user affiliation information according to clause 8.4.1 and the served list of the MCData client information entries with the following clarifications:

a) the MCData server shall not include information from an MCData group information entry with the expiration time already expired;

b) the MCData server shall not include information from an MCData group information entry with the affiliation status set to the "deaffiliated" state;

c) if the SIP SUBSCRIBE request creating the subscription of this notification contains an application/simple-filter+xml MIME body indicating per-client restrictions of presence event package notification information according to clause 8.4.2, the MCData server shall restrict the application/pidf+xml MIME body according to the application/simple-filter+xml MIME body; and

d) if this procedures is invoked by procedure in clause 8.3.2.3 where the handled p-id value was identified, the MCData server shall set the <p-id> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request to the handled p-id value; and

4) send a SIP NOTIFY request according to 3GPP TS 24.229 [5], and IETF RFC 6665 [36] for the subscription created in clause 8.3.2.4. In the SIP NOTIFY request, the MCData server shall include the generated application/pidf+xml MIME body indicating per-user affiliation information.

8.3.2.6 Sending affiliation status change towards MCData server owning MCData group procedure

NOTE 1: Usage of one SIP PUBLISH request to carry information about change of affiliation state of several MCData users served by the same MCData server is not supported in this version of the specification.

In order:

– to send an affiliation request of a served MCData ID to a handled MCData group ID;

– to send an de-affiliation request of a served MCData ID from a handled MCData group ID; or

– to send an affiliation request of a served MCData ID to a handled MCData group ID due to near expiration of the previously published information;

the MCData server shall generate a SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39]. In the SIP PUBLISH request, the MCData server:

1) shall set the Request-URI to the public service identity of the controlling MCData function associated with the handled MCData group ID;

NOTE 2: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.

NOTE 3: If the controlling MCData function is in an interconnected MCData system in a different trust domain, then the public service identity can identify the MCData gateway server that acts as an entry point in the interconnected MCData system from the local MCData system.

NOTE 4: If the controlling MCData function is in an interconnected MCData system in a different trust domain, then the local MCData system can route the SIP request through an MCData gateway server that acts as an exit point from the local MCData system to the interconnected MCData system.

NOTE 5: How the MCData server determines the public service identity of the controlling MCData function serving the target MCData ID or of the MCData gateway server in the interconnected MCData system is out of the scope of the present document.

NOTE 6: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData server:

a) shall include the <mcdata-request-uri> element set to the handled MCData group ID; and

b) shall include the <mcdata-calling-user-id> element set to the served MCData ID;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) if sending an affiliation request, shall set the Expires header field according to IETF RFC 3903 [34], to 4294967295;

NOTE 7: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if sending an de-affiliation request, shall set the Expires header field according to IETF RFC 3903 [34], to zero;

6) shall include an P-Asserted-Identity header field set to the public service identity of the MCData server according to 3GPP TS 24.229 [5];

7) shall set the current p-id to a globally unique value;

8) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

9) for each MCData group information entry such that:

a) the MCData group information entry has the "affiliating" affiliation status, the MCData group ID set to the handled MCData group ID, the expiration time has not expired yet and the affiliating p-id is not set;

b) the MCData group information entry is in the list of the MCData group information entries of an MCData client information entry; and

c) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry;

shall set the affiliating p-id of the MCData group information entry to the current p-id; and

10) shall include an application/pidf+xml MIME body indicating per-group affiliation information constructed according to clause 8.4.1. The MCData server shall indicate all served MCData client IDs, such that:

a) the affiliation status is set to "affiliating" or "affiliated", and the expiration time has not expired yet in an MCData group information entry with the MCData group ID set to the handled MCData group;

b) the MCData group information entry is in the list of the MCData group information entries of an MCData client information entry;

c) the MCData client information entry has the MCData client ID set to the served MCData client ID; and

d) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry.

The MCData server shall set the <p-id> child element of the <presence> root element to the current p-id.

The MCData server shall not include the "expires" attribute in the <affiliation> element.

The MCData server shall send the SIP PUBLISH request according to 3GPP TS 24.229 [5].

If timer F expires for the SIP PUBLISH request sent for a (de)affiliation request of served MCData ID to the MCData group ID or upon receiving a SIP 3xx, 4xx, 5xx or 6xx response to the SIP PUBLISH request, the MCData server:

1) shall remove each MCData group ID entry such that:

a) the MCData group information entry has the MCData group ID set to the handled MCData group ID;

b) the MCData group information entry is in the list of the MCData group information entries of an MCData client information entry; and

c) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry.

8.3.2.7 Affiliation status determination from MCData server owning MCData group procedure

NOTE 1: Usage of one SIP SUBSCRIBE request to subscribe for notification about change of affiliation state of several MCData users served by the same MCData server is not supported in this version of the specification.

In order to discover whether a served MCData user was successfully affiliated to a handled MCData group in the MCData server owning the handled MCData group, the MCData server shall generate an initial SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36].

In the SIP SUBSCRIBE request, the MCData server:

1) shall set the Request-URI to the public service identity of the controlling MCData function associated with the handled MCData group ID;

NOTE 2: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.

NOTE 6: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData server:

a) shall include the <mcdata-request-uri> element set to the handled MCData group ID; and

b) shall include the <mcdata-calling-user-id> element set to the served MCData ID;

3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) if the MCData server wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 7: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

5) if the MCData server wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [36], to zero;

6) shall include an Accept header field containing the application/pidf+xml MIME type; and

7) shall include an application/simple-filter+xml MIME body indicating per-user restrictions of presence event package notification information according to clause 8.4.2, indicating the served MCData ID.

In order to re-subscribe or de-subscribe, the MCData server shall generate an in-dialog SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 3856 [39], and IETF RFC 6665 [36]. In the SIP SUBSCRIBE request, the MCData server:

1) if the MCData server wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [36], to 4294967295;

NOTE 8: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [4].

2) if the MCData server wants to de-subscribe, shall set the Expires header field according to IETF RFC 6665 [36], to zero; and

3) shall include an Accept header field containing the application/pidf+xml MIME type.

1) for each served MCData ID and served MCData client ID such that the application/pidf+xml MIME body of SIP NOTIFY request contains:

a) a <tuple> element of the root <presence> element;

b) the "id" attribute of the <tuple> element indicating the served MCData ID;

c) an <affiliation> child element of the <status> element of the <tuple> element;

d) the "client" attribute of the <affiliation> element indicating the served MCData client ID; and

d) the "expires" attribute of the <affiliation> element indicating expiration of affiliation;

perform the following:

a) if an MCData group information entry exists such that:

i) the MCData group information entry has the "affiliating" affiliation status, the MCData group ID set to the handled MCData group ID, and the expiration time has not expired yet;

ii) the MCData group information entry is in the list of the MCData group information entries of an MCData client information entry with the MCData client ID set to the served MCData client ID;

iii) the MCData client information entry is in the list of the MCData client information entries of a served MCData user information entry with the MCData ID set to the served MCData ID; and

iv) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

shall set the affiliation status of the MCData group information entry to "affiliated"; and

shall set the next publishing time of the MCData group information entry to the current time and half of the time between the current time and the expiration of affiliation; and

2) for each MCData group information entry such that:

a) the MCData group information entry has the "affiliated" affiliation status or the "deaffiliating" affiliation status, the MCData group ID set to the handled MCData group ID, and the expiration time has not expired yet;

b) the MCData group information entry is in the list of the MCData group information entries of an MCData client information entry with the MCData client ID set to a served MCData client ID;

c) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry with the MCData ID set to a served MCData ID; and

d) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

for which the application/pidf+xml MIME body of SIP NOTIFY request does not contain:

a) a <tuple> element of the root <presence> element;

b) the "id" attribute of the <tuple> element indicating the served MCData ID;

c) an <affiliation> child element of the <status> child element of the <tuple> element; and

d) the "client" attribute of the <affiliation> element indicating the served MCData client ID.

perform the following:

a) shall set the affiliation status of the MCData group information entry to "deaffiliated"; and

b) shall set the expiration time of the MCData group information entry to the current time; and

3) if a <p-id> element is included in the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request, then for each MCData group information entry such that:

b) the MCData group information entry is in the list of the MCData group information entries of an MCData client information entry with the MCData client ID set to a served MCData client ID;

c) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry with the MCData ID set to a served MCData ID; and

d) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

for which the application/pidf+xml MIME body of SIP NOTIFY request does not contain:

a) a <tuple> element of the root <presence> element;

b) the "id" attribute of the <tuple> element indicating the served MCData ID;

c) an <affiliation> child element of the <status> child element of the <tuple> element; and

d) the "client" attribute of the <affiliation> element indicating the served MCData client ID;

perform the following:

a) shall set the affiliation status of the MCData group information entry to "deaffiliated"; and

b) shall set the expiration time of the MCData group information entry to the current time.

8.3.2.8 Procedure for authorizing affiliation status change request in negotiated mode sent to served MCData user

Upon receiving a SIP MESSAGE request such that:

1) Request-URI of the SIP MESSAGE request contains the public service identity identifying the terminating participating MCData function serving the MCData user;

2) the SIP MESSAGE request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the<mcdata-request-uri> element and the <mcdata-calling-user-id> element;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7]; and

4) the SIP MESSAGE request contains an application/vnd.3gpp.mcdata-affiliation-command+xml MIME body;

then the MCData server:

1) shall identify the served MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request;

2) shall identify the originating MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request;

3) if the originating MCData ID is not authorized to send an affiliation status change request in negotiated mode to the served MCData ID, shall send a 403 (Forbidden) response and shall not continue with the rest of the steps;

4) shall set the Request-URI of the SIP MESSAGE request to the public user identity bound to the served MCData ID in the MCData server; and

5) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

before forwarding the SIP MESSAGE request further.

8.3.2.9 Forwarding affiliation status change towards another MCData user procedure

Upon receiving a SIP PUBLISH request such that:

1) Request-URI of the SIP PUBLISH request contains the public service identity identifying the originating participating MCData function serving the MCData user;

2) the SIP PUBLISH request contains an application/vnd.3gpp.mcdata-info MIME body containing the<mcdata-request-uri> element which identifies an MCData ID not served by the MCData server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) the Event header field of the SIP PUBLISH request contains the "presence" event type; and

5) SIP PUBLISH request contains an application/pidf+xml MIME body indicating per-user affiliation information according to clause 8.4.1;

then the MCData server:

1) shall identify the target MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info MIME body of the SIP PUBLISH request;

2) shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP PUBLISH request;

3) shall generate a SIP PUBLISH request from the received SIP PUBLISH request. In the generated SIP PUBLISH request, the MCData server:

a) shall set the Request-URI to the public service identity identifying the terminating participating MCData function serving the target MCData ID;

NOTE 1: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.

NOTE 2: If the terminating participating MCData function is in an interconnected MCData system in a different trust domain, then the public service identity can identify the MCData gateway server that acts as an entry point in the interconnected MCData system from the local MCData system.

NOTE 3: If the terminating participating MCData function is in an interconnected MCData system in a different trust domain, then the local MCData system can route the SIP request through an MCData gateway server that acts as an exit point from the local MCData system to the interconnected MCData system.

NOTE 4: How the MCData server determines the public service identity of the terminating participating MCData function serving the target MCData ID or of the MCData gateway server in the interconnected MCData system is out of the scope of the present document.

NOTE 5: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

b) shall include a P-Asserted-Identity header field containing the public service identity identifying the originating participating MCData function serving the MCData user;

c) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData server:

A) shall include the <mcdata-request-uri> element set to the target MCData ID; and

B) shall include the <mcdata-calling-user-id> element set to the originating MCData ID; and

d) shall include other signalling elements from the received SIP PUBLISH request; and

4) shall send the generated SIP PUBLISH request according to 3GPP TS 24.229 [5].

The MCData server shall forward received SIP responses to the SIP PUBLISH request.

8.3.2.10 Forwarding subscription to affiliation status towards another MCData user procedure

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains the public service identity identifying the originating participating MCData function serving the MCData user;

2) the SIP SUBCRIBE request contains an application/vnd.3gpp.mcdata-info MIME body containing the<mcdata-request-uri> element which identifies an MCData ID not served by MCData server;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7]; and

4) the Event header field of the SIP SUBSCRIBE request contains the "presence" event type;

then the MCData server:

1) shall identify the target MCData ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info MIME body of the SIP SUBSCRIBE request;

2) shall identify the originating MCData ID from public user identity in the P-Asserted-Identity header field of the SIP SUBSCRIBE request;

3) shall generate a SIP SUBSCRIBE request from the received SIP SUBSCRIBE request. In the generated SIP SUBSCRIBE request, the MCData server:

a) shall set the Request-URI to the public service identity identifying the terminating participating MCData function serving the target MCData ID;

NOTE 1: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.

NOTE 5: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

b) shall include a P-Asserted-Identity header field containing the public service identity identifying the originating participating MCData function serving the MCData user;

c) shall include an application/vnd.3gpp.mcdata-info+xml MIME body. In the application/vnd.3gpp.mcdata-info+xml MIME body, the MCData server:

A) shall include the <mcdata-request-uri> element set to the target MCData ID; and

B) shall include the <mcdata-calling-user-id> element set to the originating MCData ID; and

d) shall include other signalling elements from the received SIP SUBSCRIBE request; and

4) shall send the generated SIP SUBSCRIBE request according to 3GPP TS 24.229 [5].

The MCData server shall forward any received SIP responses to the SIP SUBSCRIBE request, any received SIP NOTIFY request and any received SIP responses to the SIP NOTIFY request.

8.3.2.11 Affiliation status determination

This clause is referenced from other procedures.

If the participating MCData function needs to determine the affiliation status of an MCData user to an MCData group, the participating function:

1) shall find the user information entry in the list of MCData user information entries described in clause 8.3.2.2 such that the MCData ID of the MCData user information entry is equal to the MCData ID of the originator of the received SIP request;

a) if the applicable MCData group information entry cannot be found, then the participating MCData function shall determine that the MCData user is not affiliated to the MCData group at the MCData client and the skip the rest of the steps;

2) shall find the MCData client information entry in the list of MCData client information entries of MCData user information entry found in step 1) in which the MCData client id matches the value of the <mcdata-client-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body in the received SIP request;

a) if the applicable MCData client information entry cannot be found, then the participating MCData function shall determine that the MCData user is not affiliated to the MCData group at the MCData client and the skip the rest of the steps;

3) shall find the MCData group information entry in the list of MCData group information entries of MCData client information entry found in step 2 such that the MCData group identity matches the value of the identity of the targeted MCData group;

a) if the applicable MCData group information entry was found in step 3) and the affiliation status of the MCData group information entry is "affiliating" or "affiliated", shall determine that the MCData user at the MCData client to be affiliated to the targeted MCData group and skip the rest of the steps;

b) if the applicable MCData group information entry was found in step 3) and the affiliation status of the MCData group information entry is "deaffiliating" or "deaffiliated", shall determine that the MCData user at the MCData client to not be affiliated to the targeted MCData group and skip the rest of the steps; or

c) if the applicable MCData group information entry was not found in step 3), shall determine that the MCData user at the MCData client is not affiliated to the targeted MCData group.

8.3.2.12 Affiliation status change by implicit affiliation

This clause is referenced from other procedures.

Upon receiving a SIP request that requires implicit affiliation of the sending MCData client to an MCData group, the participating MCData function:

1) shall determine the served MCData client ID from the <mcdata-client-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the received SIP request;

2) shall determine the MCData group ID from the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the received SIP request;

3) shall determine the served MCData ID by using the public user identity in the P-Asserted-Identity header field of the SIP request;

NOTE 1: The MCData ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.

4) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

5) shall consider an MCData client information entry such that:

a) the MCData client information entry is in the list of MCData client information entries of the served MCData user information entry; and

b) the MCData client ID of the MCData client information entry is equal to the served MCData client ID;

as the served MCData client information entry;

6) shall consider a copy of the list of the MCData group information entries of the served MCData client information entry as the served list of the MCData group information entries;

7) shall construct the candidate list of the MCData group information entries as follows:

a) for each MCData group ID which has an MCData group information entry in the served list of the MCData group information entries shall copy the MCData group information entry into a new MCData group information entry of the candidate list of the MCData group information entries; and

b) if the determined MCData group ID does not have an MCData group information entry in the served list of the MCData group information entries or has an MCData group information entry in the served list of the MCData group information entries, such that the expiration time of the MCData group information entry has already expired:

i) shall add a new MCData group information entry in the candidate list of the MCData group information list for the determined MCData group ID;

ii) shall set the affiliation status of the new MCData group information entry to the "affiliating" state; and

iii) shall set the expiration time of the new MCData group information entry to the current time increased with the candidate expiration interval;

8) determine the candidate number of MCData group IDs as the number of different MCData group IDs which have an MCData group information entry:

a) in the candidate list of the MCData group information entries; or

b) in the list of the MCData group information entries of an MCData client information entry such that:

i) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry; and

ii) the MCData client ID of the MCData client information entry is not equal to the served MCData client ID;

with the affiliation status set to the "affiliating" state or the "affiliated" state and with the expiration time which has not expired yet; and

9) if the candidate number of MCData group IDs is bigger than the N2 value of the served MCData ID, shall based on MCData service provider policy reduce the candidate MCData group IDs to that equal to N2;

10) if the determined MCData group ID cannot be added to the the candidate list of the MCData group information entries due to exceeding the MCData user’s N2 limit, shall discard the candidate list of the MCData group information entries and skip the remaining steps of the current procedure; and

11) shall replace the list of the MCData group information entries stored in the served MCData client information entry with the candidate list of the MCData group information entries.

8.3.2.13 Implicit affiliation status change completion

This clause is referenced from other procedures.

If the participating MCData function has received a SIP 2xx response from the controlling MCData function to a SIP request that had triggered performing the procedures of clause 8.3.2.12, the participating MCData function:

1) shall set the affiliation status of the MCData group information entry added to the candidate list of the MCData group information entries by the procedures of clause 8.3.2.12 to "affiliated"; and

2) shall perform the procedures specified in clause 8.3.2.5 for the served MCData ID.

8.3.2.14 Implicit affiliation status change cancellation

This clause is referenced from other procedures.

If the participating MCData function determines that a received SIP request that had triggered performing the procedures of clause 8.3.2.12 needs to be rejected or if the participating MCData function receives a SIP 4xx, 5xx or 6xx response from the controlling MCData function for the received SIP request, the participating MCData function:

1) shall remove the MCData group ID entry added by the procedures of clause 8.3.2.12 such that:

a) the MCData group information entry has the MCData group ID set to the MCData group ID of the MCData group targeted by the received SIP request;

b) the MCData group information entry is in the list of the MCData group information entries of an MCData client information entry containing the MCData client ID included in the received SIP request; and

c) the MCData client information entry is in the list of the MCData client information entries of the MCData user information entry containing the MCData ID of the sender of the received SIP request.

8.3.2.15 Implicit affiliation to configured groups procedure

This clause is referenced from other procedures.

If the participating MCData function has successfully performed service authorization for the MCData ID identified in the service authorisation procedure as described in 3GPP TS 33.180 [26], the participating MCData function:

1) shall identify the MCData ID included in the SIP request received for service authorisation procedure as the served MCData ID;

2) shall identify the MCData client ID from the <mcdata-client-id> element contained in the application/vnd.3gpp.mcdata-info+xml MIME body included in the SIP request received for service authorisation as the served MCData client ID;

3) shall download the MCData user profile from the MCData user database as defined in 3GPP TS 29.283 [37] if not already stored at the participating MCData function;

4) if no <ImplicitAffiliations> element is contained in the <OnNetwork> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) for the served MCData ID or the <ImplicitAffiliations> element contains no <entry> elements containing an MCData group ID, shall skip the remaining steps;

5) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of MCData user information entries described in clause 8.3.2.2; and

b) the MCData ID of the MCData user information entry is equal to the served MCData ID;

as the served MCData user information entry;

6) shall consider an MCData client information entry such that:

a) the MCData client information entry is in the list of MCData client information entries of the served MCData user information entry; and

b) the MCData client ID of the MCData client information entry is equal to the served MCData client ID;

as the served MCData client information entry;

7) shall consider a copy of the list of the MCData group information entries of the served MCData client information entry as the served list of the MCData group information entries;

8) shall construct the candidate list of the MCData group information entries as follows:

b) for each MCData group ID contained in an <entry> element of the <ImplicitAffiliations> element in the <OnNetwork> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) for the served MCData ID that does not have an MCData group information entry in the served list of the MCData group information entries or has an MCData group information entry in the served list of the MCData group information entries such that the expiration time of the MCData group information entry has already expired:

i) shall add a new MCData group information entry in the candidate list of the MCData group information list for the MCData group ID;

ii) shall set the affiliation status of the new MCData group information entry to the "affiliating" state; and

iii) shall set the expiration time of the new MCData group information entry to the current time increased with the candidate expiration interval;

c) if in step b) above, no new MCData group information entries were added to the candidate list of the MCData group information list for the MCData group ID:

i) shall discard the candidate list; and

ii) shall skip the remaining steps;

9) determine the candidate number of MCData group IDs as the number of different MCData group IDs which have an MCData group information entry:

a) in the candidate list of the MCData group information entries; or

b) in the list of the MCData group information entries of an MCData client information entry such that:

i) the MCData client information entry is in the list of the MCData client information entries of the served MCData user information entry; and

ii) the MCData client ID of the MCData client information entry is not equal to the served MCData client ID;

with the affiliation status set to the "affiliating" state or the "affiliated" state and with the expiration time which has not expired yet; and

c) if the candidate number of MCData group IDs is bigger than the N2 value of the served MCData ID, shall based on MCData service provider policy reduce the candidate MCData group IDs to that equal to N2;

10) shall replace the list of the MCData group information entries stored in the served MCData client information entry with the candidate list of the MCData group information entries; and

11) for each MCData group ID contained in an <entry> element of the <ImplicitAffiliations> element in the <OnNetwork> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) for the served MCData ID and which has an MCData group information entry in the candidate list of the MCData group information entries with an affiliation status of "affiliating", shall perform the procedures specified in clause 8.3.2.6 for the served MCData ID and each MCData group ID.

NOTE 2: To learn of the MCData groups successfully affiliated to, the MCData client can subscribe to that information by the procedures specified in clause 8.2.3.

8.3.3 Procedures of MCData server owning the MCData group

8.3.3.1 General

The procedures of MCData server owning the MCData group consist of:

– receiving group affiliation status change procedure;

– receiving subscription to affiliation status procedure;

– sending notification of change of affiliation status procedure;

– implicit affiliation eligibilty check procedure; and

– affiliation status change by implicit affiliation procedure.

NOTE: Usage of CSC-3 part of MCData group affiliation procedure and of CSC-3 part of MCData group de-affiliation procedure is not specified in this version of the specification.

8.3.3.2 Stored information

The MCData server shall maintain a list of MCData group information entries.

In each MCData group information entry, the MCData server shall maintain:

1) an MCData group ID. This field uniquely identifies the MCData group information entry in the list of the MCData group information entries; and

2) a list of MCData user information entries.

In each MCData user information entry, the MCData server shall maintain:

1) an MCData ID. This field uniquely identifies the MCData user information entry in the list of the MCData user information entries;

2) a list of MCData client information entries; and

3) an expiration time.

In each MCData client information entry, the MCData server shall maintain:

1) an MCData client ID. This field uniquely identifies the MCData client information entry in the list of the MCData client information entries.

8.3.3.3 Receiving group affiliation status change procedure

Upon receiving a SIP PUBLISH request such that:

1) Request-URI of the SIP PUBLISH request contains the public service identity of the controlling MCData function associated with the served MCData group;

2) the SIP PUBLISH request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the <mcdata-request-uri> element and the <mcdata-calling-user-id> element;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) the Event header field of the SIP PUBLISH request contains the "presence" event type; and

5) SIP PUBLISH request contains an application/pidf+xml MIME body indicating per-group affiliation information constructed according to clause 8.4.1;

then the MCData server:

1) shall identify the served MCData group ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

2) shall identify the handled MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP PUBLISH request;

3) if the Expires header field of the SIP PUBLISH request is not included or has nonzero value lower than 4294967295, shall send a SIP 423 (Interval Too Brief) response to the SIP PUBLISH request, where the SIP 423 (Interval Too Brief) response contains a Min-Expires header field set to 4294967295, and shall not continue with the rest of the steps;

4) if an MCData group for the served MCData group ID does not exist in the group management server according to 3GPP TS 24.481 [11], shall reject the SIP PUBLISH request with SIP 403 (Forbidden) response to the SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

5) if the handled MCData ID is not a member of the MCData group identified by the served MCData group ID, shall reject the SIP PUBLISH request with SIP 403 (Forbidden) response to the SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

6) shall respond with SIP 200 (OK) response to the SIP PUBLISH request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34]. In the SIP 200 (OK) response, the MCData server:

a) shall set the Expires header field according to IETF RFC 3903 [34], to the selected expiration time;

7) if the "entity" attribute of the <presence> element of the application/pidf+xml MIME body of the SIP PUBLISH request is different than the served MCData group ID, shall not continue with the rest of the steps;

8) if the handled MCData ID is different from the MCData ID in the "id" attribute of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request, shall not continue with the rest of the steps;

9) shall consider an MCData group information entry such that:

a) the MCData group information entry is in the list of MCData group information entries described in clause 8.3.3.2; and

b) the MCData group ID of the MCData group information entry is equal to the served MCData group ID;

as the served MCData group information entry;

10) if the selected expiration time is zero:

a) shall remove the MCData user information entry such that:

i) the MCData user information entry is in the list of the MCData user information entries of the served MCData group information entry; and

ii) the MCData user information entry has the MCData ID set to the served MCData ID;

11) if the selected expiration time is not zero:

a) shall consider an MCData user information entry such that:

i) the MCData user information entry is in the list of the MCData user information entries of the served MCData group information entry; and

ii) the MCData ID of the MCData user information entry is equal to the handled MCData ID;

as the served MCData user information entry;

b) if the MCData user information entry does not exist:

i) shall insert an MCData user information entry with the MCData ID set to the handled MCData ID into the list of the MCData user information entries of the served MCData group information entry; and

ii) shall consider the inserted MCData user information entry as the served MCData user information entry; and

c) shall set the following information in the served MCData user information entry:

i) set the MCData client ID list according to the "client" attributes of the <affiliation> elements of the <status> element of the <tuple> element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request; and

ii) set the expiration time according to the selected expiration time;

12) shall identify the handled p-id in the <p-id> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP PUBLISH request; and

13) shall perform the procedures specified in clause 8.3.3.5 for the served MCData group ID.

8.3.3.4 Receiving subscription to affiliation status procedure

NOTE: Usage of one SIP SUBSCRIBE request to subscribe for notification about change of affiliation state of several MCData users served by the same MCData server is not supported in this version of the specification.

Upon receiving a SIP SUBSCRIBE request such that:

1) Request-URI of the SIP SUBSCRIBE request contains the public service identity of the controlling MCData function associated with the served MCData group;

2) the SIP SUBSCRIBE request contains an application/vnd.3gpp.mcdata-info+xml MIME body containing the<mcdata-request-uri> element and the <mcdata-calling-user-id> element;

3) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [7];

4) the Event header field of the SIP SUBSCRIBE request contains the "presence" event type; and

5) the SIP SUBSCRIBE request contains an application/simple-filter+xml MIME body indicating per-user restrictions of presence event package notification information according to clause 8.4.2 indicating the same MCData ID as in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

then the MCData server:

1) shall identify the served MCData group ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

2) shall identify the handled MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP SUBSCRIBE request;

3) if the Expires header field of the SIP SUBSCRIBE request is not included or has nonzero value lower than 4294967295, shall send a SIP 423 (Interval Too Brief) response to the SIP SUBSCRIBE request, where the SIP 423 (Interval Too Brief) response contains a Min-Expires header field set to 4294967295, and shall not continue with the rest of the steps;

4) if an MCData group for the served MCData group ID does not exist in the group management server according to 3GPP TS 24.481 [11], shall reject the SIP SUBSCRIBE request with SIP 403 (Forbidden) response to the SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps;

5) if the handled MCData ID is not a member of the MCData group identified by the served MCData group ID, shall reject the SIP SUBSCRIBE request with SIP 403 (Forbidden) response to the SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 3903 [34] and IETF RFC 3856 [39] and skip the rest of the steps; and

6) shall generate a SIP 200 (OK) response to the SIP SUBSCRIBE request according to 3GPP TS 24.229 [5], IETF RFC 6665 [36].

For the duration of the subscription, the MCData server shall notify subscriber about changes of the information of the served MCData ID, as described in clause 8.3.3.5.

8.3.3.5 Sending notification of change of affiliation status procedure

In order to notify the subscriber identified by the handled MCData ID about changes of the affiliation status of the served MCData group ID, the MCData server:

1) shall consider an MCData group information entry such that:

a) the MCData group information entry is in the list of MCData group information entries described in clause 8.3.3.2; and

b) the MCData group ID of the MCData group information entry is equal to the served MCData group ID;

2) shall consider an MCData user information entry such:

a) the MCData user information entry is in the list of the MCData user information entries of the served MCData group information entry; and

b) the MCData ID of the MCData user information entry is equal to the handled MCData ID;

as the served MCData user information entry;

3) shall generate an application/pidf+xml MIME body indicating per-group affiliation information according to clause 8.4.1 and the served list of the served MCData user information entry of the MCData group information entry with following clarifications:

a) the MCData server shall include the "expires" attribute in the <affiliation> element; and

b) if this procedures is invoked by procedure in clause 8.3.3.3 where the handled p-id was identified, the MCData server shall set the <p-id> child element of the <presence> root element of the application/pidf+xml MIME body of the SIP NOTIFY request to the handled p-id value; and

4) send a SIP NOTIFY request according to 3GPP TS 24.229 [5], and IETF RFC 6665 [36] for the subscription created in clause 8.3.3.4. In the SIP NOTIFY request, the MCData server shall include the generated application/pidf+xml MIME body indicating per-group affiliation information.

8.3.3.6 Implicit affiliation eligibilty check procedure

This clause is referenced from other procedures.

Upon receiving a SIP request for an MCData group that the MCData user is not currently affiliated to and that requires the controlling MCData function to check on the eligibility of the MCData user to be implicitly affiliated to the MCData group, the controlling MCData function:

1) shall identify the served MCData group ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP request;

2) shall identify the handled MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP request;

3) if an MCData group for the served MCData group ID does not exist in the group management server according to 3GPP TS 24.481 [11], shall consider the MCData user to be ineligible for implicit affiliation and skip the rest of the steps;

4) if the handled MCData ID is not a member of the MCData group identified by the served MCData group ID, shall consider the MCData user to be ineligible for implicit affiliation and skip the rest of the steps;

5) if there is no MCData group information entry in the list of MCData group information entries described in clause 8.3.3.2 with an MCData group identity matching the served MCData group ID, then shall consider the MCData user to be ineligible for implicit affiliation and skip the rest of the steps; or

6) shall consider the MCData user to be eligible for implicit affiliation.

8.3.3.7 Affiliation status change by implicit affiliation procedure

This clause is referenced from other procedures.

Upon receiving a SIP request for an MCData group that the MCData user is not currently affiliated to and that requires the controlling MCData function to perform an implicit affiliation to, the controlling MCData function:

1) shall identify the served MCData group ID in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP request;

2) shall identify the handled MCData ID in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP request;

3) shall consider an MCData group information entry such that:

a) the MCData group information entry is in the list of MCData group information entries described in clause 8.3.3.2; and

b) the MCData group ID of the MCData group information entry is equal to the served MCData group ID;

as the served MCData group information entry;

4) shall consider an MCData user information entry such that:

a) the MCData user information entry is in the list of the MCData user information entries of the served MCData group information entry; and

b) the MCData ID of the MCData user information entry is equal to the handled MCData ID;

as the served MCData user information entry;

c) if the MCData user information entry does not exist:

i) shall insert an MCData user information entry with the MCData ID set to the handled MCData ID into the list of the MCData user information entries of the served MCData group information entry; and

ii) shall consider the inserted MCData user information entry as the served MCData user information entry; and

d) shall make the following modifications in the served MCData user information entry:

i) add the MCData client ID derived from the received SIP request to the MCData client ID list if not already present; and

ii) set the expiration time as determined by local policy;

5) shall perform the procedures specified in clause 8.3.3.5 for the served MCData group ID.

8.4 Coding

8.4.1 Extension of application/pidf+xml MIME type

8.4.1.1 Introduction

The clauses of the parent clause describe an extension of the application/pidf+xml MIME body specified in IETF RFC 3863 [40]. The extension is used to indicate:

– per-user affiliation information; and

– per-group affiliation information.

8.4.1.2 Syntax

The application/pidf+xml MIME body indicating per-user affiliation information is constructed according to IETF RFC 3863 [40] and:

1) contains a <presence> root element according to IETF RFC 3863 [40];

2) contains an "entity" attribute of the <presence> element set to the MCData ID of the MCData user;

3) contains one <tuple> child element according to IETF RFC 3863 [40] per each MCData client of the <presence> element;

4) can contain a <p-id> child element defined in the XML schema defined in table 8.4.1.2-1, of the <presence> element set to an identifier of a SIP PUBLISH request;

5) contains an "id" attribute of the <tuple> element set to the MCData client ID;

6) contains one <status> child element of each <tuple> element;

7) contains one <affiliation> child element defined in the XML schema defined in table 8.4.1.2-1, of the <status> element, for each MCData group in which the MCData user is interested at the MCData client;

8) contains a "group" attribute of each <affiliation> element set to the MCData group ID of the MCData group in which the MCData user is interested at the MCData client;

9) can contain a "status" attribute of each <affiliation> element indicating the affiliation status of the MCData user to MCData group at the MCData client; and

10) can contain an "expires" attribute of each <affiliation> element indicating expiration of affiliation of the MCData user to MCData group at the MCData client.

The application/pidf+xml MIME body indicating per-group affiliation information is constructed according to IETF RFC 3856 [39] and:

1) contains the <presence> root element according to IETF RFC 3863 [40];

2) contains an "entity" attribute of the <presence> element set to the MCData group ID of the MCData group;

3) contains one <tuple> child element according to IETF RFC 3863 [40] of the <presence> element;

4) can contain a <p-id> child element defined in the XML schema defined in table 8.4.1.2-1, of the <presence> element set to an identifier of a SIP PUBLISH request;

5) contains an "id" attribute of the <tuple> element set to the MCData ID of the MCData user;

6) contains one <status> child element of each <tuple> element;

7) contains one <affiliation> child element defined in the XML schema defined in table 8.4.1.2-1, of the <status> element, for each MCData client at which the MCData user is interested in the MCData group;

8) contains one "client" attribute defined in the XML schema defined in table 8.4.1.2-2, of the <affiliation> element set to the MCData client ID;

9) can contain an "expires" attribute defined in the XML schema defined in table 8.4.1.2-2, of the <affiliation> element indicating expiration of affiliation of the MCData user to MCData group at the MCData client. and

10) can contain one <functionalAlias> child element defined in the XML schema defined in table 8.4.1.2-1, of the <status> element, for each functional alias that the group member identified by the "id" attribute of the <tuple> element has activated with the "functionalAliasID" attribute set to the corresponding functional alias ID.

Table 8.4.1.2-1: XML schema with elements and attributes extending the application/pidf+xml MIME body

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

targetNamespace="urn:3gpp:ns:mcdataPresInfo:1.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:mcdataPI10="urn:3gpp:ns:mcdataPresInfo:1.0"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<!– MCData specific child elements of tuple element –>

<xs:element name="affiliation" type="mcdataPI10:affiliationType"/>

<xs:complexType name="affiliationType">

<xs:sequence>

<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="group" type="xs:anyURI" use="optional"/>

<xs:attribute name="client" type="xs:anyURI" use="optional"/>

<xs:attribute name="status" type="mcdataPI10:statusType" use="optional"/>

<xs:attribute name="expires" type="xs:dateTime" use="optional"/>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

<xs:simpleType name="statusType">

<xs:restriction base="xs:string">

<xs:enumeration value="affiliating"/>

<xs:enumeration value="affiliated"/>

<xs:enumeration value="deaffiliating"/>

</xs:restriction>

</xs:simpleType>

<xs:element name="p-id" type="xs:string"/>

<!– MCData specific child elements of status element –>

<xs:element name="functionalAlias" type="mcdataPI10:functionalAliasType"/>

<xs:complexType name="functionalAliasType">

<xs:sequence>

<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="functionalAliasID" type="xs:anyURI" use="optional"/>

<xs:attribute name="expires" type="xs:dateTime" use="optional"/>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:schema>

The application/pidf+xml MIME body refers to namespaces using prefixes specified in table 8.4.1.2-2.

Table 8.4.1.2-2: Assignment of prefixes to namespace names in the application/pidf+xml MIME body

Prefix	Namespace
mcdataPI10	urn:3gpp:ns:mcdataPresInfo:1.0
NOTE: The "urn:ietf:params:xml:ns:pidf" namespace is the default namespace so no prefix is used for it in the application/pidf+xml MIME body.

8.4.2 Extension of application/simple-filter+xml MIME type

8.4.2.1 Introduction

The clauses of the parent clause describe an extension of the application/simple-filter+xml MIME body specified in IETF RFC 4661 [41].

The extension is used to indicate per-client restrictions of presence event package notification information and per-user restrictions of presence event package notification information.

8.4.2.2 Syntax

The application/simple-filter+xml MIME body indicating per-client restrictions of presence event package notification information is constructed according to IETF RFC 4661 [41] and:

1) contains a <filter-set> root element according to IETF RFC 4661 [41];

2) contains a <ns-bindings> child element according to IETF RFC 4661 [41], of the <filter-set> element;

3) contains a <ns-binding> child element according to IETF RFC 4661 [41], of the <ns-bindings> element where the <ns-binding> element:

A) contains a "prefix" attribute according to IETF RFC 4661 [41] set to "pidf"; and

B) contains a "urn" attribute set to the "urn:ietf:params:xml:ns:pidf" value;

4) contains a <ns-binding> child element according to IETF RFC 4661 [41], of the <ns-bindings> element where the <ns-binding> element:

A) contains a "prefix" attribute according to IETF RFC 4661 [41], set to "mcdataPI10"; and

B) contains an "urn" attribute according to IETF RFC 4661 [41], set to the "urn:3gpp:ns:mcdataPresInfo:1.0" value;

5) contains a <filter> child element according to IETF RFC 4661 [41], of the <filter-set> element where the <filter> element;

A) contains an "id" attribute set to a value constructed according to IETF RFC 4661 [41];

B) does not contain an "uri" attribute of the <filter> child element according to IETF RFC 4661 [41]; and

C) does not contain an "domain" attribute according to IETF RFC 4661 [41];

6) contains a <what> child element according to IETF RFC 4661 [41], of the <filter> element; and

7) contains an <include> child element according to IETF RFC 4661 [41], of the <what> element where the <include> element;

A) does not contain a "type" attribute according to IETF RFC 4661 [41]; and

B) contains the value, according to IETF RFC 4661 [41], set to concatenation of the ‘//pidf:presence/pidf:tuple[@id="’ string, the MCData client ID, and the ‘"]’ string.

The application/simple-filter+xml MIME body indicating per-user restrictions of presence event package notification information is constructed according to IETF RFC 4661 [41] and: