6 Group management procedures

24.5443GPPGroup Management - Service Enabler Architecture Layer for Verticals (SEAL)Protocol specificationRelease 17TS

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

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.1.2 Boot up procedure

Upon device boot up, the GMC in the UE shall subscribe to group announcement events as specified in clause 6.2.8.1.2 or clause 6.2.8.1.1, and also fetch the list of groups as specified in clause 6.2.10.1.

6.2.1.3 Authenticated identity in CoAP request

Upon receiving an CoAP request, the SGM-S shall authenticate the identity of the sender of the CoAP 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 CoAP request as an authenticated identity.

6.2.2 Group creation procedure

6.2.2.1 SGM client HTTP 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 SGM server HTTP 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 SGM client HTTP 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.2.4 SGM client CoAP procedure

Upon receiving a request from the VAL user to create a group document, the SGM-C shall send a CoAP POST request to the SGM-S. In the CoAP POST request, the SGM-C:

a) shall set the CoAP URI to the VAL Group Documents resource URI to according to the resource definition in clause C.2.1.2.2.2:

1) the "apiRoot" is set to the SGM-S URI;

b) shall include Content-Format option set to " application/vnd.3gpp.seal-group-doc+cbor ";

c) shall include " VALGroupDocument" object:

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

2) may include "groupName" attribute containing a human readable name of the VAL group;

3) may include "grpDesc" attribute containing a human readable description of the VAL group;

4) if the VAL user has requested to include a list of users who are to be members of the group, shall include "memberDetails" object, and for each member:

i) shall set "memberId" attribute to the VAL user ID or VAL UE ID;

ii) if the VAL user has requested this member to be an administrator of the group, shall set "membershipType" attribute to "ADMINISTRATOR";

iii) if the VAL user has requested this member to be required to give user consent to be a member of the group, shall set "membershipType" attribute to "EXPLICIT";

iv) if the VAL user has requested this member to not be required to give user consent to be a member of the group, shall set "membershipType" attribute to "IMPLICIT";

5) shall include "category" attribute indicating the category of the group;

6) may include one or more VAL service IDs in "valServiceIds" attribute indicating a list of supported VAL services by the group;

7) if the request is to configure VAL group request, shall include one or more geographical area identifiers in "geoIds" attribute, each identifier indicating the geographical area to be addressed by the group;

8) may include "priority" attribute set to the priority as specified by VAL user;

9) may include "extGrpId" attribute identifying the member UEs of the VAL group at the 3GPP core network;

10) may include "com5GLanType" attribute set to the 5GLAN communication type if requested by the VAL user;

11) may include "valGrpConf" attribute set to VAL specific configuration data if provided by the VAL user;

12) if the request is to form a temporary group, shall include a list of VAL group IDs of the constituent VAL groups in "inclValGroupIds" attribute; and

d) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

Upon receiving a CoAP 2.01 (Created) response, the SGM-C shall notify the VAL user about successful group creation. Based on VAL user’s request, the SGM-C shall create a subscription to changes of the newly created as specified in clause 6.2.8.1.3.2 for the Individual VAL Group Document resource.

6.2.2.5 SGM server CoAP procedure

Upon reception of an CoAP POST request where the CoAP URI of the request identifies the VAL Group Documents resource URI according to the resource definition in clause C.2.1.2.2.2, the SGM-S:

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

1) if the identity of the sender of the received CoAP POST request is not authorized to create the VAL group document, shall respond with a 4.03 (Forbidden) response to the CoAP POST request and skip rest of the steps;

b) shall support handling an CoAP POST request from a SGM-C according to procedures specified in IETF RFC 7252  [12]; and

c) shall create a new Individual VAL Group Document resource and for each VAL user in the list of members of the document shall create a new Individual Group Member resource and shall return the VAL group document and its resource URI in the CoAP 2.01 (Created) response as specified in clause C.2.1.2.2.3.1.

Upon successful creation of the group, for each group member the SGM-S shall send Group Announcement notification as specified in clause 6.2.7.5.1

6.2.2.6 Group member SGM client CoAP procedure

Upon receiving a group announcement notification, the SGM-C shall follow the procedure as specified in clause 6.2.7.4.1.

6.2.3 Group information query procedure

6.2.3.1 SGM client HTTP 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 SGM server HTTP 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.3.3 SGM client CoAP procedure

Upon receiving a request from the VAL user to retrieve a part of a group document, the SGM-C shall send a CoAP GET request to the SGM-S with the CoAP URI set to the Individual VAL Group resource identifying the VAL group document and with the content filtering query parameters set according to the VAL user request. The procedure is described in clause 6.2.5.2.3.

6.2.3.4 SGM server CoAP procedure

Upon reception of a CoAP GET request for a part of a group document from the SGM-C, the SGM-S shall handle it as described in clause 6.2.5.2.4.

6.2.4 Group membership procedure

6.2.4.1 SGM client HTTP 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 SGM server HTTP 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.4.3 SGM client CoAP procedure

Upon receiving a request from the VAL user to update group membership of a group document, the SGM-C shall send a CoAP PUT request to the SGM-S. In the CoAP PUT request, the SGM-C:

a) shall set the CoAP URI identifying the individual VAL group document to be updated according to the resource definition in clause C.2.1.2.3.2:

1) the "apiRoot" is set to the SGM-S URI; and

2) the "groupDocId" to point to the VAL group document;

b) shall include Content-Format option set to "application/vnd.3gpp.seal-group-doc+cbor";

c) shall include "VALGroupDocument" object with "members" and "memberDetails" lists including the member identities and member details according to the requested group membership; and

d) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

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

NOTE 2: If the VAL client is adding a new member to the group, it may include VAL service specific information in the "memberConfig" attribute of the "GroupMember" object.

6.2.4.4 SGM server CoAP procedure

Upon reception of an CoAP PUT request where the CoAP URI of the request identifies Individual VAL Group Document resource as described in clause C.2.1.2.3.2, the SGM-S:

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

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

b) shall support handling an CoAP PUT request from a SGM-C according to procedures specified in IETF RFC 7252  [12]; and

c) shall update the VAL group document pointed according to the "VALGroupDocument" received in the request, and:

1) for each new member in the group shall create a new individual group member resource; and

2) for each member removed from the group shall delete the corresponding individual group member resource.

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.3.2.

6.2.5 Group configuration management procedure

6.2.5.1 Update group configuration

6.2.5.1.1 SGM client HTTP 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 updated;

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.

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 SGM server HTTP 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".

6.2.5.1.3 SGM client CoAP procedure

Upon receiving a request from the VAL user to update a group document, the SGM-C shall send a CoAP PUT request to the SGM-S. In the CoAP PUT request, the SGM-C:

a) shall set the CoAP URI identifying the individual VAL group document to be updated according to the resource definition in annex C.2.1.2.3.2:

1) the "apiRoot" is set to the SGM-S URI; and

2) the "groupDocId" to point to the VAL group document;

b) shall include Content-Format option set to "application/vnd.3gpp.seal-group-doc+cbor";

c) shall include "VALGroupDocument" object in the payload:

1) shall set "valGroupId" attribute to the same VAL group identity as in the group document to be updated;

2) may include "groupName" attribute containing a human readable name of the VAL group;

3) may include "grpDesc" attribute containing a human readable description of the VAL group;

4) if the VAL user has requested to include a list of users who are to be members of the group, shall include "memberDetails" object, and for each member:

i) shall set "memberId" attribute to the VAL user ID or VAL UE ID;

ii) if the VAL user has requested this member to be an administrator of the group, shall set "membershipType" attribute to "ADMINISTRATOR";

iii) if the VAL user has requested this member to be required to give user consent to be a member of the group, shall set "membershipType" attribute to "EXPLICIT";

iv) if the VAL user has requested this member to not be required to give user consent to be a member of the group, shall set "membershipType" attribute to "IMPLICIT";

5) shall include "category" attribute indicating the category of the group

6) shall include one or more VAL service IDs in "valServiceIds" attribute indicating a list of VAL services supported by the group;

8) may include "priority" attribute set to the priority as specified by VAL user;

9) may include "extGrpId" attribute identifying the member UEs of the VAL group at the 3GPP core network;

10) may include "com5GLanType" attribute set to the 5GLAN communication type if requested by the VAL user;

11) may include "valGrpConf" attribute set to VAL specific configuration data if provided by the VAL user; and

d) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

6.2.5.1.4 SGM server CoAP procedure

Upon reception of an CoAP PUT request where the CoAP URI of the request identifies an Individual VAL Group Document resource as described in annex C.2.1.2.3.2, the SGM-S:

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

b) shall support handling an CoAP PUT request from a SGM-C according to procedures specified in IETF RFC 7252  [12]; and

c) shall update the VAL group document pointed according to the "VALGroupDocument" received in the request, and:

1) for each new member in the group shall create a new individual group member resource; and

2) for each member removed from the group shall delete the corresponding individual group member resource.

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.3.2.

6.2.5.2 Retrieve group document

6.2.5.2.1 SGM client HTTP 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 SGM server HTTP 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.5.2.3 SGM client CoAP procedure

Upon receiving a request from the VAL user to retrieve a group document, the SGM-C shall send a CoAP GET request to the SGM-S. In the CoAP GET request, the SGM-C:

a) shall set the CoAP URI identifying the group document to be retrieved according to resource API definition in clause C.2.1.2:

1) the "apiRoot" is set to the SGM-S URI;

2) if the SGM-C does not know the "groupDocId" of the group document at the SGM-S, the SGM-C:

i) shall use the VAL Group Documents resource GET and shall set "val-group-id" query parameter to the VAL group ID and may set any of the other query parameters as described in clause C.2.1.2.2.3.2; or

ii) shall use the Individual VAL Group Document GET and shall set "groupDocId" to point to the VAL group document and may set any of the content filtering query parameters as described in clause C.2.1.2.3.3.1; and

b) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

6.2.5.2.4 SGM server CoAP procedure

Upon reception of an CoAP GET request where the CoAP URI of the request identifies VAL Group Documents resource as described in clause C.2.1.2.2.3.2, the SGM-S:

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

1) if the sender is not authorized to fetch the requested VAL group document(s), shall respond with a 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SGM-C according to procedures specified in IETF RFC 7252 [12]; and

c) shall return a 2.05 (Content) response including all the VAL group documents matching all the given values of the query parameters.

Upon reception of an CoAP GET request where the CoAP URI of the request identifies Individual VAL Group Document resource as described in clause C.2.1.2.3.3.1, the SGM-S:

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

1) if the sender is not authorized to fetch the requested VAL group document, shall respond with a 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SGM-C according to procedures specified in IETF RFC 7252 [12]; and

c) shall check if the resource pointed at by the CoAP URI exists and:

1) if it exists, shall return the VAL document in a 2.05 (Content) response with the content of the document matching the content filtering query parameters; or

2) otherwise, shall return a 4.04 (Not found) response.

6.2.6 Location-based group creation procedure

6.2.6.1 SGM client HTTP 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; and

b) shall set the location of tracking area in the <geo-id> child element of <common> element of a <list-service> element.

6.2.6.2 SGM server HTTP 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:

a) shall obtain the list of users based on location as specified in clause 6.2.9 of 3GPP TS 24.545 [11] and include the list of users in the group document.

6.2.6.3 SGM client CoAP 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.4 with following clarifications. The SGM-C:

a) shall set "category" attribute to "LOCATION_BASED"; and

b) shall set the location of tracking area as an item in the list in the "geoIds" attribute.

6.2.6.4 SGM server CoAP procedure

Upon receiving a group creation request for a group with the "category" attribute value of "LOCATION_BASED", the SGM-S shall follow the procedure as defined in clause 6.2.2.5 with following clarifications. The SGM-S:

a) shall obtain the list of users based on the location provided in the "geoIds" attribute as specified in clause 6.2.9 of 3GPP TS 24.545 [11] and include the list of users in the group document; and

b) for each new member in the group shall create a new individual group member resource.

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 HTTP procedure specified in clause 6.2.7.3 to notify group announcement to group members and to handle group registration request from SGM-C. If CoAP is used the respective procedures are specified in clause 6.2.7.5.

The SGM-C shall follow the HTTP procedure specified in clause 6.2.7.2 to handle received group announcement notification and to request group registration. If CoAP is used the respective procedures are specified in clause 6.2.7.4.

6.2.7.2 SGM client HTTP 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.2.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 SGM server HTTP 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.7.4 SGM client CoAP procedure

6.2.7.4.1 Subscribing to and receiving group announcement notification

In order to subscribe to group announcements, the SGM-C shall send an extended CoAP GET request with the CoAP URI set to the URI of the observable VAL Group Documents resource and with the "memberId" query parameter set to the VAL user ID or VAL UE ID and with the Observe option set to 0 (Register) as specified in IETF RFC 7641 [14].

Upon receiving a CoAP 2.05 (Content) response that matches the extended CoAP GET request which initiated the subscription, and which contains the Observe option, the SGM-C:

a) shall handle the response according to IETF RFC 7641 [14];

b) shall compare the received list of the VAL group documents with the local list of VAL group documents to determine the new group(s) in which the VAL user is a member, and for each such new group:

1) shall notify the VAL user about announcement of group with "valGroupId", "groupName" and "grpDesc"; and

2) if VAL user’s "membershipType" value is "EXPLICIT", the SGM-C shall ask VAL user to join the group; and

c) shall update the local list of VAL group documents, and may also decide to store the group announcement based on user’s request.

6.2.7.4.2 Sending group registration request

Upon receiving request from VAL user to join the group, the SGM-C shall send a CoAP PUT request to the SGM-S. In the CoAP PUT request, the SGM-C:

a) shall set the CoAP URI to the "resUri" of the group member corresponding to the VAL user, so that the CoAP URI of the request identifies the Individual Group Member resource to be updated according to the resource definition in clause C.2.1.2.4.3.2:

1) the "apiRoot" is set to the SGM-S URI;

2) the "groupDocId" is set to point to the VAL group document; and

3) the "memberId" is set to VAL user ID or VAL UE ID;

b) shall include Content-Format option set to "application/vnd.3gpp.seal-group-member-info+cbor";

c) shall include "GroupMember" object which:

1) shall contain "membershipState" with the "registered" attribute set to "true";

2) may contain "messageFilter" attribute; and

3) shall contain all the other attributes unchanged; and

d) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

Upon receiving a CoAP 2.04 (Changed), the SGM-C shall notify the VAL user about successful group registration. Based on VAL user’s request, if subscription to modifications of this group is not already created, then the SGM-C shall create such a subscription as specified in clause 6.2.8.1.3.2.

6.2.7.4.3 Subscribing to and receiving group identity list notification

In order to subscribe to changes in the group’s identity list, the SGM-C shall send an extended CoAP GET request with the CoAP URI set to the URI of the observable Individual VAL Group Document resource and with the "group-members" query parameter set to "true" and with the Observe option set to 0 (Register) as specified in IETF RFC 7641 [14].

Upon receiving a CoAP 2.05 (Content) response that matches the extended CoAP GET request which initiated the subscription, and which contains the Observe option, the SGM-C:

a) shall handle the response according to IETF RFC 7641 [14]; and

b) shall notify the VAL user about group members.

6.2.7.5 SGM server CoAP procedure

6.2.7.5.1 Receiving group announcement subscription

Upon reception of an extended CoAP GET request with the CoAP URI set to the URI of the observable VAL Group Documents resource with the "memberId" query parameter and with the Observe option set to 0 (Register), the SGM-S:

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

1) if the sender is not authorized to fetch the requested VAL group document(s), shall respond with a 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SGM-C according to procedures specified in IETF RFC 7252 [12];

c) shall register the SGM-C as an observer of this resource with the given value of the "memberId", as per IETF RFC 7641 [14]; and

d) shall send a CoAP 2.05 (Content) response with the Observer option set to the initial sequence number of the notification and with the payload including all the VAL group documents in which the given value of the "memberId" matches any of the group members’ "memberId" attribute.

6.2.7.5.2 Sending group announcement notification

Upon successful creation of a group, for each group member in the group document which has "EXPLICIT" membership type, the SGM-S:

a) shall check whether a valid group announcement subscription exists with a matching value of "memberId" as defined in clause 6.2.7.5.1 or not; if it does not exists then skip rest of the steps;

b) shall send a CoAP 2.05 (Content) response with the Observer option set to incremented sequence number of the notification and with the payload including all the VAL group documents in which the subscription’s value of the "memberId" query parameter matches any of the group members’ "memberId" attribute. Each included VAL group document shall also have the list of group members included in "memberDetails" attribute.

6.2.7.5.3 Receiving subscription request and sending group identity list notification

Upon reception of an extended CoAP GET request with the CoAP URI set to the URI of the observable Individual VAL Group Document resource with the "group-members" query parameter set to "true" and with the Observe option set to 0 (Register), the SGM-S:

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

1) if the sender is not authorized to fetch the requested VAL group document, shall respond with a 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SGM-C according to procedures specified in IETF RFC 7252 [12]; and

c) shall check if the resource pointed at by the CoAP URI exists and:

1) if it does not exist, shall return a 4.04 (Not found) response and skip rest of the steps;

2) shall register the SGM-C as an observer of this resource as per IETF RFC 7641 [14]; and

3) shall send a CoAP 2.05 (Content) response with the Observe option set to the initial sequence number of the notification and with the payload including the VAL group document with the content of the document matching the content filtering query parameters, i.e., including the member list in the "members" attribute.

Upon a change in the list of group members of the VAL group document, for each group identity list subscription, the SGM-S:

a) shall send a CoAP 2.05 (Content) response with the Observe option set to incremented sequence number of the notification and with the payload including the VAL group document with the content of the document matching the content filtering query parameters, i.e., including the member list in the "members" attribute.

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.1.3 CoAP based procedures

6.2.8.1.3.1 General

CoAP based procedures shall use the mechanisms to observe a resource as specified in IETF RFC 7641 [14].

NOTE: CoAP "observe" mechanism uses the principle of eventual consistency where an intermediate state change can be lost when UDP is used. If it is critical for the client to receive every change in the resource state (and not just the latest state), TCP can be used to avoid missing notifications.

6.2.8.1.3.2 Create a subscription

The CoAP resource representation defines in clause C.2.1.2 the following observable resources:

a) VAL Group Documents resource which represents a collection resource of VAL group documents, and which may be observed by the SGM-C with the purpose to be notified when the VAL user is defined as a group member;

b) Individual VAL Group Document which represents a single VAL group document, and which may be observed by the SGM-C with the purpose to be notified when the VAL group document is modified. By means of the content filters the SGM-C may choose the part of the VAL group document to be included in the notification.

In order to subscribe to changes of an observable resource the SGM-C shall send an extended CoAP GET request with the CoAP URI set to the URI of the observable resource and with the Observe option set to 0 (Register) as specified in IETF RFC 7641 [14].

Upon reception of such an extended CoAP request from SGM-C where the CoAP URI of the request points at an observable resource and with the Observe option set to 0 (Register), the SGM-S:

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

1) if the sender is not authorized to fetch the requested resource, shall respond with a 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SGM-C according to procedures specified in IETF RFC 7252 [12];

c) shall register the SGM-C as an observer as per IETF RFC 7641 [14]; and

d) shall send a CoAP 2.05 (Content) response including the current content of the resource and the Observe option with the initial sequence number of the notification.

6.2.8.1.3.3 Delete a subscription

In order to unsubscribe from changes of an observable resource the SGM-C shall send a CoAP GET request matching the CoAP GET request used to create the subscription but with the Observe option set to 1 (Deregister) as specified in IETF RFC 7641 [14].

Upon reception of a CoAP GET that matches an active subscription but with the Observe option set to 1 (Deregister), the SGM-S:

a) shall perform the steps as for a normal CoAP GET request for the observable resource;

b) shall deregister the SGM-C as an observer as per IETF RFC 7641 [14]; and

c) shall send a CoAP 2.05 (Content) response including the current content of the resource and shall not include the Observe option.

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.8.2.3 CoAP based procedures

6.2.8.2.3.1 Client procedure

Upon receiving a CoAP 2.05 (Content) response that matches the extended CoAP GET request which initiated the subscription, and which contains the Observe option, the SGM-C:

a) shall handle the response according to IETF RFC 7641 [14]; and

b) shall handle the modification according to the observable resource.

6.2.8.2.3.2 Server procedure

In order to send a notification when the resource which is being observed is modified, the SGM-S shall send a CoAP 2.05 (Content) response to SGM-C containing the modified resource and the Observe option according to IETF RFC 7641 [14]. The Content-Format specified in a 2.xx notification shall be the same as the one used in the initial response to the GET request received for the subscription.

6.2.9 Group member leave

6.2.9.1 SGM client HTTP 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 SGM server HTTP 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.

6.2.9.3 SGM client CoAP procedure

Upon receiving request from VAL user to leave the group, the SGM-C shall send a CoAP DELETE request to the SGM-S. In the CoAP DELETE request, the SGM-C:

a) shall set the CoAP URI to the "resUri" of the group member corresponding to the VAL user, so that the CoAP URI of the request identifies the Individual Group Member resource to be deleted according to the resource definition in clause C.2.1.2.4.3.3:

1) the "apiRoot" is set to the SGM-S URI;

2) the "groupDocId" is set to point to the VAL group document; and

3) the "memberId" is set to VAL user ID or VAL UE ID; and

b) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

Upon receiving a CoAP 2.02 (Deleted) response, the SGM-C shall notify the VAL user about successful group deregistration. Based on VAL user’s request, if subscription to modifications of this group is already created, then the SGM-C shall delete that subscription as specified in clause 6.2.8.1.3.3.

6.2.9.4 SGM server CoAP procedure

Upon reception of an CoAP DELETE request where the CoAP URI of the request identifies Individual Group Member resource as described in clause C.2.1.2.4.3.3, the SGM-S:

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

1) if the identity of the sender of the received CoAP DELETE request is not authorized to delete the requested group member resource, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP DELETE request and skip rest of the steps;

b) shall support handling an CoAP DELETE request from a SGM-C according to procedures specified in IETF RFC 7252  [12]; and

c) shall delete the individual group member resource pointed at by the CoAP URI and shall update the "members" and "memberDetails" lists in the VAL group document.

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.3.2. In the notification, the SGM-S shall send the modified VAL group document.

6.2.10 Group list fetch procedure

6.2.10.1 SGM client HTTP procedure

Upon receiving request from VAL user to fetch the list of groups in which the VAL user is a member, 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 SGM server HTTP 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.2.10.3 SGM client CoAP procedure

Upon receiving request from VAL user to fetch the list of groups in which the VAL user is a member, the SGM-C shall send a CoAP GET request with the CoAP URI set to the URI of the VAL Group Documents resource with the "memberId" query parameter set to the VAL user ID or VAL UE ID and optionally with the "time-period" query parameter when the group was created.

Upon receiving request from VAL user to fetch the list of groups in which the VAL user is a member, the SGM-C shall send a CoAP GET request to the SGM-S. In the CoAP GET request, the SGM-C:

a) shall set the CoAP URI to the URI of the VAL Group Documents resource:

1) the "apiRoot" is set to the SGM-S URI; and

2) shall set "memberId" query parameter to the VAL user ID or VAL UE ID and may set "time-period" query parameter to the time period when the group was created as described in clause C.2.1.2.2.3.2; and

b) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

Upon receiving a CoAP 2.05 (Content) response the SGM-C shall notify the VAL user about the list of the groups where the VAL UE is a member.

6.2.10.4 SGM server CoAP procedure

Upon reception of an CoAP GET request where the CoAP URI of the request identifies VAL Group Documents resource as described in clause C.2.1.2.2.3.2, the SGM-S:

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

1) if the sender is not authorized to fetch the requested VAL group document(s), shall respond with a 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SGM-C according to procedures specified in IETF RFC 7252 [12]; and

c) shall return a 2.05 (Content) response including all the VAL group documents matching all the given values of the query parameters.

6.2.11 Temporary groups procedure

6.2.11.1 SGM client HTTP procedure

In order to form a temporary group, the SGM-C shall generate an HTTP POST request. In the HTTP POST request:

a) shall set the Request-URI to the URI of the SGM-S appended with the value "/temporary-groups";

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];

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

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

Upon receiving an HTTP POST request from SGM-S contains parameters of VAL Group Ids and VAL Group Id, the SGM-C shall respond with an HTTP 200 (OK) message including a parameter VAL Group Id set to the VAL group ID of the temporary group.

6.2.11.2 SGM server HTTP procedure

Upon receiving an HTTP POST request from SGM-S where the Request-URI of the HTTP POST request contains "/temporary-groups", 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; and

b) shall check whether any of the received VAL group IDs is a temporary group, and:

1) if any of the received VAL group IDs is a temporary group, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps; and

2) else shall create and store the received parameters in the HTTP POST request message;

c) shall notify the VAL server regarding the temporary group creation with the received parameters; and

d) shall generate an HTTP POST request message. In the HTTP POST request:

1) shall set the request URI to the URI of the SGM-C received at the time of creating groups;

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

3) shall send the HTTP POST request to every SGM-C of the constituent VAL groups.

Upon receiving an HTTP 200 (OK) message contains only one parameter of VAL Group Id, the SGM-S shall send an HTTP 200 (OK) response to SGM-C. In the response, the SGM-S shall include the parameters specified in clause A.4.2 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [10];

6.2.11.3 SGM client CoAP procedure

In order to form a temporary group, the SGM-C shall follow the procedure to create a group as defined in clause 6.2.2.4 with the following clarifications. The SGM-C:

a) shall set "category" attribute to "TEMPORARY";

b) shall include the list of VAL group IDs of the constituent VAL groups in the "inclValGroupIds" attribute.

Upon receiving a CoAP 2.01 (Created) response, the SGM-C shall notify the VAL user about successful formation of the temporary group.

6.2.11.4 SGM server CoAP procedure

Upon receiving a group creation request for a group with the "category" attribute value of "TEMPORARY", the SGM-S shall follow the procedure as defined in clause 6.2.2.5 with the following clarifications. The SGM-S:

a) before creating the group, shall check whether any of the received VAL group IDs is a temporary group, and:

1) if any of the received VAL group IDs is a temporary group, shall not create the group and respond with a CoAP 4.03 (Forbidden) response to the CoAP POST request;

b) upon successful group creation, shall notify the VAL server regarding the temporary group creation.

6.3 Off-network procedures

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