6 Group management procedures

24.5443GPPGroup managementProtocol specificationRelease 17Service Enabler Architecture Layer (SEAL)TS

6.1 General

6.2 On-network procedures

6.2.1 General

6.2.1.1 Authenticated identity in HTTP request

Upon receiving an HTTP request, the SGM-S shall authenticate the identity of the sender of the HTTP request as specified in 3GPP TS 24.547 [5], and if authentication is successful, the SGM-S shall use the identity of the sender of the HTTP request as an authenticated identity.

6.2.2 Group creation procedure

6.2.2.1 Client procedure

Upon receiving a request from the VAL user to create a group document, the SGM-C shall create an XML document as specified in clause 7 and shall send the XML document to the SGM-S according to procedures specified in IETF RFC 4825 [3] "Create or Replace a Document". In the HTTP PUT request, the SGM-C:

a) shall set the Request URI to a XCAP URI identifying an XML document to be created. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SGM-S;

2) the "auid" is set to specific VAL service identity; and

3) the document selector is set to a document URI pointing to a group document addressed by a group ID;

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6];

c) shall include a Content-Type header field set to "application/vnd.3gpp.seal-group-doc+xml"; and

d) shall include an application/vnd.3gpp.seal-group-doc+xml MIME body and in the <seal-group-doc> root element:

1) shall set "uri" attribute to the VAL group identity to be created;

2) may include <display-name> element containing a human readable name of the VAL group;

3) if the VAL user has requested to include administrator users, shall include <administrators> element of a <list-service> element with list of administrator users.

4) if the list of users available who are required to give user consent to be member for the group, shall include such list of users into the <explicit-member-list> element of a <list-service> element;

5) if the list of users available who are members of the group, shall include such list of users into the <list> element of a <list-service> element;

6) shall include <common> element of a <list-service> element. The <common> element:

i) may include <seal-subject> element indicating the title or description for the group;

ii) shall include <category> element indicating the category of the group;

iii) shall include one or more <val-service-id> element(s) indicating list of supported services by the group; and

iv) if the request is to configure VAL group request, shall include one or more <geo-id> element(s), each element indicating list of geographical areas to be addressed by the group; and

7) shall include <val-specific-config> element of a <list-service>. The <val-specific-config> element:

i) may include <group-priority> element to the priority as specified by VAL user; and

ii) may include <external-group-id> element identifying the member UEs of the VAL group at the 3GPP core network.

Upon receiving an HTTP 200 (OK), the SGM-C shall notify the VAL user about successful group registration. Based on VAL user’s request, if group events subscription is not already created, then the SGM-C shall create the group events subscription as specified in clause 6.2.8.1.1 for the event SUBSCRIBE_GROUP_MODIFICATION (0x02) as defined in clause A.1.2. If group events subscription already exists then the SGM-C shall modify the subscription as specified in clause 6.2.8.1.2.

6.2.2.2 Server procedure

Upon reception of an HTTP PUT request where the Request-URI of the HTTP PUT request identifies an XML document as specified in clause 7, the SGM-S:

a) shall determine the identity of the sender of the received HTTP PUT request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP PUT request is not authorized to initiate group creation, shall respond with a HTTP 403 (Forbidden) response to the HTTP PUT request and skip rest of the steps;

b) if value of the group URI received in HTTP PUT request does not conform to local policy, shall respond with an HTTP 409 (Conflict) response to the HTTP PUT request. The <uniqueness-failure> error element shall identify the error condition. The SGM-S shall include at least one <alt-value> element in the <uniqueness-failure> error element, whereby each <alt-value> element contains a Group ID acceptable for the SGM-S. The SGM-S shall skip rest of the steps; and

c) shall support receiving an XML document according to procedures specified in IETF RFC 4825 [3] "PUT Handling" where the Request-URI of the HTTP PUT request identifies an XML document.

Upon successful creation of group, for each VAL user in <list> element of a <list-service> element of the group document, the SGM-S shall send Group Announcement notification as specified in clause 6.2.7.3.1 with following clarification:

a) shall set the "IsJoinReq" parameter to "false"; and

b) shall include the "Members-list" parameter as specified in clause B.2.

6.2.2.3 Group member client procedure

Upon receiving an HTTP POST request over a call back URI which was given to SGM-S at time of group events subscription, the SGM-C shall follow the procedure as specified in clause 6.2.7.2.1.

6.2.3 Group information query procedure

6.2.3.1 Client procedure

Upon receiving a request from the VAL user to retrieve an element of a group document, the SGM-C shall send an HTTP GET request to the SGM-S according to procedures specified in IETF RFC 4825 [3] "Fetch an Element". In HTTP GET request, the SGM-C:

a) shall set the Request-URI to a XCAP URI identifying an element within an XML document to be queried. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SGM-S;

2) the "auid" is set to specific VAL service identity;

3) the document selector is set to a document URI pointing to a group document addressed by a group ID which contains the element to be queried; and

4) the node selector is set to a node URI identifying the element to be queried; and

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6].

6.2.3.2 Server procedure

Upon reception of an HTTP GET request where the Request-URI of the HTTP GET request identifies an element of a XML document as specified in clause 7, the SGM-S:

a) shall determine the identity of the sender of the received HTTP GET request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP GET request is not authorized to query group information, shall respond with a HTTP 403 (Forbidden) response to the HTTP GET request and skip rest of the steps;

b) shall support handling an HTTP GET request from a SGM-C according to procedures specified in IETF RFC 4825 [3] "GET Handling".

6.2.4 Group membership procedure

6.2.4.1 Client procedure

Upon receiving a request from the VAL user to update group membership element of a group document, a SGM-C shall send an HTTP PUT request to the SGM-S according to procedures specified in IETF RFC 4825 [3] "Create or Replace an Element". In HTTP PUT request, the SGM-C:

a) shall set the Request-URI to a XCAP URI identifying an element within an XML document to be updated. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SGM-S;

2) the "auid" is set to specific VAL service identity;

3) the document selector is set to a document URI pointing to a group document addressed by a group ID which contains the element to be updated; and

4) the node selector is set to a node URI identifying the element to be updated; and

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6].

NOTE1: The VAL client can use the procedure specified in this clause to update all possible elements which can be updated.

NOTE 2: If the VAL client is adding new member to the group, it may include VAL service specific information as an attribute of the new element or as an child element of the new element.

6.2.4.2 Server procedure

Upon reception of an HTTP PUT request where the Request-URI of the HTTP PUT request identifies an element of a XML document as specified in clause 7, the SGM-S:

a) shall determine the identity of the sender of the received HTTP PUT request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP PUT request is not authorized to update group information, shall respond with a HTTP 403 (Forbidden) response to the HTTP PUT request and skip rest of the steps;

b) shall support handling an HTTP PUT request from a SGM-C according to procedures specified in IETF RFC 4825 [3] "PUT Handling".

Upon successful modification of the group, the SGM-S shall notify all group members about the group modification by following the procedure specified in clause 6.2.8.2.2.2. In the group modify notification, the SGM-S shall set the "modificationType" parameter to the value GROUP_MEMBER_ADDED (0x01) as specified in clause B.3.

6.2.5 Group configuration management procedure

6.2.5.1 Update group configuration

6.2.5.1.1 Client procedure

Upon receiving a request from the VAL user to update a group document, the SGM-C shall create an XML document as specified in clause 7 and shall send the XML document to the SGM-S according to procedures specified in IETF RFC 4825 [3] "Create or Replace a Document". In the HTTP PUT request, the SGM-C:

a) shall set the Request URI to a XCAP URI identifying an XML document to be updated. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SGM-S;

2) the "auid" is set to specific VAL service identity; and

3) the document selector is set to a document URI pointing to a group document addressed by a group ID;

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6];

c) shall include a Content-Type header field set to "application/vnd.3gpp.seal-group-doc+xml"; and

d) shall include an application/vnd.3gpp.seal-group-doc+xml MIME body and in the <seal-group-doc> root element:

1) shall set "uri" attribute to the VAL group identity to be created;

2) may include <display-name> element containing a human readable name of the VAL group;

3) if the VAL user has requested to include administrator users, shall include <administrators> element of a <list-service> element with list of administrator users.

4) if the list of users available who are required to give user consent to be member for the group, shall include such list of users into the <explicit-member-list> element of a <list-service> element;

5) if the list of users available who are members of the group, shall include such list of users into the <list> element of a <list-service> element;

6) shall include <common> element of a <list-service> element. The <common> element:

i) may include <seal-subject> element indicating the title or description for the group;

ii) shall include <category> element indicating the category of the group; and

iii) shall include <val-services> element indicating list of supported services by the group; and

7) shall include <val-specific-config> element of a <list-service>. The <val-specific-config> element:

i) may include <group-priority> element to the priority as specified by VAL user

6.2.5.1.2 Server procedure

Upon reception of an HTTP PUT request where the Request-URI of the HTTP PUT request identifies an XML document as specified in clause 7, the SGM-S:

a) shall determine the identity of the sender of the received HTTP PUT request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP PUT request is not authorized to update the group document, shall respond with a HTTP 403 (Forbidden) response to the HTTP PUT request and skip rest of the steps;

b) shall support receiving an XML document as specified in application usage of the specific vertical application according to procedures specified in IETF RFC 4825 [3] "PUT Handling".

Upon successful modification of the group, the SGM-S shall notify all group members about the group modification by following the procedure specified in clause 6.2.8.2.2.2. In the group modify notification, the SGM-S shall set the "modificationType" parameter to the value GROUP_CONFIG_UPDATE (0x03) as specified in clause B.3.

6.2.5.2 Retrieve group document

6.2.5.2.1 Client procedure

Upon receiving a request from the VAL user to retrieve a group document, the SGM-C shall send an HTTP GET request to the SGM-S according to procedures specified in IETF RFC 4825 [3] "Fetch a Document". In HTTP GET request, the SGM-C:

a) shall set the Request-URI to a XCAP URI identifying an XML document to be retrieved. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SGM-S;

2) the "auid" is set to specific VAL service identity; and

3) the document selector is set to a document URI pointing to a group document addressed by a group ID; and

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6].

6.2.5.2.2 Server procedure

Upon reception of an HTTP GET request where the Request-URI of the HTTP GET request identifies an XML document as specified in clause 7, the SGM-S:

a) shall determine the identity of the sender of the received HTTP GET request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP GET request is not authorized to retrieve the group document, shall respond with a HTTP 403 (Forbidden) response to the HTTP GET request and skip rest of the steps;

b) shall support receiving an XML document as specified in application usage of the specific vertical application according to procedures specified in IETF RFC 4825 [3] "GET Handling".

6.2.6 Location-based group creation procedure

6.2.6.1 Client procedure

Upon receiving a request from the VAL user to create a location based group, the SGM-C shall follow the procedure as defined in clause 6.2.2.1 with following clarifications.

The SGM-C:

a) shall set <category> child element of <common> element of a <list-service> element to the value "location-based" as defined in clause 7;

b) shall set the location of tracking area in the <geographical-area> child element of <common> element of a <list-service> element;

6.2.6.2 Server procedure

Upon receiving HTTP PUT request with <category> child element of <common> element of a <list-service> element set to the value "location-based", the SGM-S shall follow the procedure as defined in clause 6.2.2.2 with following clarifications. The SGM-S:

1) shall obtain the list of users based on location as specified in clause 6.2.x of 3GPP TS 24.545 [11] and update the list of users in group document.

6.2.7 Group announcement and join procedure

6.2.7.1 General

Upon successful creation of the group as specified in clause 6.2.2, the SGM-S follow the procedure specified in clause 6.2.7.3 to notify group announcement to group members and to handle group registration request from SGM-C. The SGM-C shall follow the procedure specified in clause 6.2.7.2 to handle received group announcement notification and to request group registration.

6.2.7.2 Client procedure

6.2.7.2.1 Receiving group announcement notification

Upon receiving an HTTP POST request over a call back URI which was given to SGM-S at time of group events subscription, the SGM-C:

a) shall match subscription identity received in the "Identity" parameter of the HTTP POST request with the locally stored identity of the subscription. If subscription identity is not valid, then

1) send an HTTP 406 (Not Acceptable) response and skip rest of the steps;

b) shall send an HTTP 200 (OK); and

c) if "Event" parameter is set to SUBSCRIBE_GROUP_ANNOUNCEMENT (0x01) as specified in clause B.2, shall notify the VAL user about announcement of group with group-ID and subject. If the notification contains "IsJoinReq" parameter with value set to "true", the SGM-C shall ask VAL user to join the group. The SGM-C may also decide to store the group announcement based on user’s request.

6.2.7.2.2 Sending group registration request

Upon receiving request from VAL user to join the group, the SGM-C:

a) shall generate an HTTP POST request. In the HTTP POST request:

1) shall set the Request URI to the value "/group-registration";

2) shall include the Host header with public user identity of SGM-S;

3) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6];

4) shall include in the HTTP request entity-body the "group-ID" parameter set to the group URI received in group announcement notification; and

5) may include the parameters specified in clause A.Y.1 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [10]; and

b) shall send an HTTP POST request to SGM-S.

Upon receiving an HTTP 200 (OK), the SGM-C shall notify the VAL user about successful group registration. Based on VAL user’s request, if group events subscription is not already created, then the SGM-C shall create the group events subscription as specified in clause 6.2.8.1.1 for the event SUBSCRIBE_GROUP_MODIFICATION (0x02) and SUBSCRIBE_GROUP_IDENTITY_LIST (0x04) as defined in clause A.1.2. If group events subscription already exists then the SGM-C shall modify the subscription as specified in the clause 6.2.8.1.2.

6.2.7.2.3 Receiving group identity list notification

Upon receiving an HTTP POST request over a call back URI which was given to SGM-S at time of group events subscription, the SGM-C:

a) shall match subscription identity received in the "Identity" parameter of the HTTP POST request with the locally stored identity of the subscription. If subscription identity is not valid, then

1) send an HTTP 406 (Not Acceptable) response and skip rest of the steps;

b) shall send an HTTP 200 (OK); and

c) if "Event" parameter is set to SUBSCRIBE_GROUP_IDENTITY_LIST (0x04) as specified in clause B.4, shall notify the VAL user about group list members.

6.2.7.3 Server procedure

6.2.7.3.1 Sending group announcement notification

Upon successful creation of group, for each VAL user in <explicit-member-list> element of a <list-service> element of the group document, the SGM-S:

a) shall check whether valid group events subscription exists for event SUBSCRIBE_GROUP_ANNOUNCEMENT (0x01) as defined in clause A.1.2 or not; if valid subscription does not exists then skip rest of the steps;

b) shall generate an HTTP POST message to notify group announcement. In the HTTP POST message:

1) shall set request URI to call back URI received at the time of creating subscription;

2) shall set Content-Type header to "application/json";

3) shall include an HTTP request entity-body serialized into a JavaScript Object Notation (JSON) structure; In the entity-body:

i) shall set the "Identity" parameter to the identity of the subscription;

ii) shall set the "Event" parameter to the value SUBSCRIBE_GROUP_ANNOUNCEMENT (ox01) as specified in clause B.2;

iii) shall set the "GroupID" parameter to the identity of the VAL Group;

iv) may set the "Subject" parameter to the value of <seal-subject> child element of a <common> element of a <list-service> element from the group document;

v) shall set the "IsJoinReq" parameter to "true";

vi) may include the "Val-services" parameter as specified in clause B.2;

vii) if there are no privacy concerns with sharing the identity list, may include the "Members-list" parameter as specified in clause B.2; and

viii) if the group is created for 5G LAN-Type communication, may include the "5GVN Group Info" parameter providing 5GVN group information; and

c) shall send the HTTP POST request towards SGM-C.

6.2.7.3.2 Receiving group registration request

Upon reception of an HTTP POST request where the Request-URI of the HTTP POST request is set to "/group-registration", the SGM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP POST request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps;

b) shall update the members information in group document; and

c) shall send an HTTP 200 (OK) response to SGM-C.

6.2.7.3.3 Sending group identity list notification

Upon successful creation of group, for each VAL user in <explicit-member-list> element of a <list-service> element of the group document, the SGM-S:

a) shall check whether valid group events subscription exists for event SUBSCRIBE_GROUP_IDENTITY_LIST (0x04) as defined in clause A.1.2 or not; if valid subscription does not exists then skip rest of the steps;

b) shall generate an HTTP POST message to notify group announcement. In the HTTP POST message:

1) shall set request URI to call back URI received at the time of creating subscription;

2) shall set Content-Type header to "application/json"; and

3) shall include an HTTP request entity-body serialized into a JavaScript Object Notation (JSON) structure; In the entity-body,

i) shall set the "Identity" parameter to the identity of the subscription;

ii) shall set the "Event" parameter to the value SUBSCRIBE_GROUP_IDENTITY_LIST (0x04) as specified in clause B.4;

iii) shall set the "GroupID" parameter to the identity of the VAL Group;

iv) shall include the "Members-list" parameter as specified in clause B.4

c) shall send the HTTP POST request towards SGM-C.

6.2.8 Group subscription and notification procedure

6.2.8.1 Management of group events subscription

6.2.8.1.1 SIP based procedures

6.2.8.1.1.1 General

The VAL service will use the same identity which has been authenticated by VAL service with SIP core using SIP based REGISTER message. If VAL service do not support SIP protocol, then HTTP based method needs to be used.

The SGM-C shall use mechanism provided by VAL service to add access-token in SIP messages. The SGM-S shall identify the originating VAL user ID from the access-token received from SGM-C using the mechanism defined in VAL service specification.

6.2.8.1.1.2 Create subscription

In order to subscribe to notification of changes of one or more group documents of VAL groups identified by VAL group IDs, a SGM-C shall send an initial SIP SUBSCRIBE request to the network according to the UE originating procedures specified in 3GPP TS 24.229 [11] and IETF RFC 5875 [12]. In the initial SIP SUBSCRIBE request, the SGM-C:

a) shall set the Request-URI to the configured public service identity for performing subscription proxy function of the SGM-S;

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

c) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.seal" in the Contact header field;

d) shall include an application/resource-lists+xml MIME body. In the application/resource-lists+xml MIME body, the SGM-C shall include one <entry> element for each group document to be subscribed to, such that the "uri" attribute of the <entry> element contains a relative path reference to XCAP URI identifying an XML document to be subscribed to;

e) if the VAL server wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [14], to zero. Otherwise, shall set the Expires header field to the duration for which VAL user has requested for subscription;

Upon reception of an initial SIP SUBSCRIBE request:

a) with the Event header field set to xcap-diff;

b) with the Request-URI set to own public service identity for performing subscription proxy function of the SGM-S;

c) with an application/resource-lists+xml MIME body; and

d) with the ICSI value "urn:urn-7:3gpp-service.ims.icsi.seal" (coded as specified in 3GPP TS 24 229 [11]), in a P-Asserted-Service header field according to IETF RFC 6050 [13];

the SGM-S:

d) shall identify the originating VAL user ID and shall use the originating VAL user ID as an authenticated identity when performing the authorization;

b) if the authenticated identity is not authorized to subscribe to notification of changes of any resource in the application/resource-lists+xml MIME body, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps;

e) act as a notifier according to IETF RFC 5875 [12].

6.2.8.1.1.3 Modify subscription

In order to modify or refresh subscription, the SGM-C shall send SIP re-SUBSCRIBE request on the same dialog as the existing subscription, and with the same "Event" header. The SGM-C shall follow the steps specified in clause 6.2.8.1.1.2.1 to create SIP SUBSCRIBE request.

Upon reception of a SIP re-SUBSCRIBE request:

a) with the Event header field set to xcap-diff; and

b) with an application/resource-lists+xml MIME body;

the SGM-S:

a) act as a notifier according to IETF RFC 5875 [12].

6.2.8.1.1.4 Delete subscription

In order to delete the subscription, the SGM-C shall send SIP re-SUBSCRIBE request on the same dialog as the existing subscription, and with the same "Event" header. The SGM-C shall follow the steps specified in clause 6.2.8.1.1.2.1 to create SIP SUBSCRIBE request with following clarification:

a) shall set the Expires header field to zero.

Upon reception of a SIP re-SUBSCRIBE request:

a) with the Event header field set to xcap-diff; and

b) with Expires header field set to zero;

the SGM-S:

a) act as a notifier according to IETF RFC 5875 [12].

6.2.8.1.2 HTTP based procedures

6.2.8.1.2.1 Creating subscription

Upon successful service authorization of the VAL service, the SGM-C shall create a subscription for group events by sending an HTTP POST request to the SGM-S. In the HTTP POST request, the SGM-C:

a) shall set the Request URI to the URI of the SGM-S appended with VAL service identity and the value "/groupEventsSubscription";

b) shall include the Host header with public user identity of SGM-S;

c) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

c) include the parameters specified in clause A.1.2 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [10].

Upon reception of an HTTP POST request from SGM-C where the Request-URI of the HTTP POST request contains "/groupEventsSubscription" without subscription identity, the SGM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP POST request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps;

b) shall generate unique subscription identity and store the subscription details for the authorized user; and

c) shall send an HTTP 200 (OK) response including parameters specified in clause A.1.3.

6.2.8.1.2.2 Modify a subscription

Upon receiving a request from VAL user to modify existing subscription identified with unique subscription identity, the SGM-C:

a) shall generate an HTTP PUT request. In the HTTP PUT request:

1) shall set the Request URI to the same Request URI used while creating subscription in clause 6.2.8.1.2.1.1 appended with subscription identity;

2) shall include the Host header with public user identity of SGM-S;

3) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

4) include the parameters specified in clause A.1.2 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [10].

b) shall send the HTTP PUT request to the SGM-S.

Upon reception of an HTTP PUT request from SGM-C where the Request-URI of the HTTP PUT request is set to "/groupEventsSubscription" appended with subscription identity, the SGM-S:

a) shall determine the identity of the sender of the received HTTP PUT request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP PUT request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP PUT request and skip rest of the steps;

b) shall determine whether subscription for group events exists or not based on received subscription identity in request URI; and

1) if subscription does not exist, shall respond with an HTTP 406 (Not Acceptable) response to the HTTP PUT request and skip rest of the steps;

c) shall update the subscription details based on received parameters from the HTTP PUT request; and

d) shall send an HTTP 200 (OK) response including parameters specified in clause A.1.3.

6.2.8.1.2.3 Delete a subscription

Upon receiving a request from VAL user to delete existing subscription identified with unique subscription identity, the SGM-C:

a) shall generate an HTTP DELETE request. In the HTTP DELETE request:

1) shall set the Request URI to the value "/groupEventsSubscription" appended with subscription identity;

2) shall include the Host header with public user identity of SGM-S; and

3) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

b) shall send the HTTP DELETE request to the SGM-S.

Upon reception of an HTTP DELETE request from SGM-C where the Request-URI of the HTTP DELETE request contains "/groupEventsSubscription" appended with subscription identity, the SGM-S:

a) shall determine the identity of the sender of the received HTTP DELETE request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP DELETE request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP DELETE request and skip rest of the steps;

b) shall determine whether subscription for group events exists or not based on received subscription identity in request URI; and

1) if subscription does not exist, shall respond with an HTTP 406 (Not Acceptable) response to the HTTP DELETE request and skip rest of the steps;

c) shall delete the subscription details based on received parameters from the HTTP DELETE request; and

d) shall send an HTTP 200 (OK) response to the SGM-C.

6.2.8.2 Notifications

6.2.8.2.1 SIP based procedures
6.2.8.2.1.1 Client procedure

Upon receiving a SIP NOTIFY request associated with a subscription created as result of the sent initial SIP SUBSCRIBE request, the SGM-S:

a) shall handle the SIP NOTIFY request according to IETF RFC 5875 [12].

6.2.8.2.1.2 Server procedure

In order to send notification of group document update event, the SGM-S shall send SIP NOTIFY to SGM-C according to IETF RFC 5875 [12].

6.2.8.2.2 HTTP based procedures

6.2.8.2.2.1 Receiving group modify notification

Upon receiving an HTTP POST request over a call back URI which was given to the SGM-S at time of group events subscription, the SGM-C:

a) shall match subscription identity received in the "Identity" parameter of the HTTP POST request with the locally stored identity of the subscription. If subscription identity is not valid, then

1) send an HTTP 406 (Not Acceptable) response and skip rest of the steps;

b) shall send an HTTP 200 (OK); and

c) if "Event" parameter is set to SUBSCRIBE_GROUP_MODIFICATION (0x02) as specified in clause B.3, shall notify the VAL user about modification of group with group-ID.

Based on VAL user’s request, the SGM-C may also retrieve the group document identified by group ID received in group modify notification as specified in clause 6.2.5.2.

6.2.8.2.2.2 Sending group modify notification

To send the group modification notification to the SGM-C, the SGM-S:

a) shall check whether valid group events subscription exists for event SUBSCRIBE_GROUP_MODIFICATION (0x02) as defined in clause A.1.2 or not; if valid subscription does not exists then skip rest of the steps;

b) shall generate an HTTP POST message to notify group announcement. In the HTTP POST message:

1) shall set request URI to the call back URI received at the time of creating subscription;

2) shall set Content-Type header to "application/json"; and

3) shall include an HTTP request entity-body with the parameters specified in clause B.3 serialized into a JavaScript Object Notation (JSON) structure; and

c) shall sent the HTTP POST request towards SGM-C.

6.2.9 Group member leave

6.2.9.1 Client procedure

Upon receiving request from VAL user to leave the group, the SGM-C:

a) shall generate an HTTP POST request. In the HTTP POST request:

1) shall set the Request URI to the URI of the SGM-S appended with VAL service identity and the value "/group-deregistration";

2) shall include the Host header with public user identity of SGM-S;

3) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

4) shall include in the HTTP request entity-body the "group-ID" parameter set to the group URI of the group which VAL user has requested to leave; and

b) shall send the HTTP POST request to SGM-S.

Upon receiving an HTTP 200 (OK), the SGM-C shall notify the VAL user about successful group registration.

6.2.9.2 Server procedure

Upon reception of an HTTP POST request where the Request-URI of the HTTP POST request is set to "/group-deregistration", the SGM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP POST request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps;

b) shall update the members information in group document; and

c) shall send an HTTP 200 (OK) response to SGM-C.

Upon successful modification of the group, the SGM-S shall notify all group members about the group modification by following the procedure specified in clause 6.2.8.2.2.2. In the group modify notification, the SGM-S shall set the "modificationType" parameter to the value GROUP_MEMBER_REMOVED (0x02) as specified in clause B.3.

6.2.10 Group list fetch procedure

6.2.10.1 Client procedure

Upon receiving request from VAL user to join the group, the SGM-C:

a) shall generate an HTTP POST request. In the HTTP POST request:

1) shall set the Request URI to the URI of the SGM-S appended with VAL service identity and the value "/group-list-fetch";

2) shall include the Host header with public user identity of SGM-S;

3) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

4) shall include the parameters specified in clause A.3.1 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [10]; and;

b) shall send an HTTP POST request to SGM-S.

Upon receiving an HTTP 200 (OK), the SGM-C shall notify the VAL user about the list of the groups where the VAL UE is a member.

Based on VAL user’s request, if group events subscription is not already created, then the SGM-C shall create the group events subscription as specified in clause 6.2.8.1.1 for the event SUBSCRIBE_GROUP_MODIFICATION (0x02) as defined in clause A.1.2. If group events subscription already exists then the SGM-C shall modify the subscription as specified in clause 6.2.8.1.2.

6.2.10.2 Server procedure

Upon reception of an HTTP POST request where the Request-URI of the HTTP POST request is set to "/group-list-fetch", the SGM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP POST request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps;

b) shall send an HTTP 200 (OK) response to SGM-C. In the response, the SGM-S shall include the parameters specified in clause A.3.2 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [10];

6.3 Off-network procedures

The off-network procedures are out of scope of the present document in this release of the specification.