Content for TS 29.122 Word version: 19.0.0

1… 4.4… 4.4.3… 4.4.5… 4.4.7… 4.4.8… 4.4.12… 5… 5.6… 5.8… 5.10… 5.12… 6…

4.4.8 Procedures for Reporting of Network Status 4.4.8.1 General 4.4.8.2 Network Status Reporting Subscription 4.4.8.3 Network Status Reporting Notification 4.4.9 Procedures for Communication Pattern Parameters Provisioning 4.4.10 Procedures for PFD Management 4.4.11 Procedures for Enhanced Coverage Restriction Control
...

4.4.8 Procedures for Reporting of Network Status p. 46

4.4.8.1 General p. 46

These procedures are used by an SCS/AS to perform reporting of network status via the T8 interface in one time or continuous reporting cases. The SCEF uses the reporting procedures based on the network status information from one or more RCAF(s). These procedures can also be used by the SCS/AS to indicate the removal of a previously subscribed reporting request.

4.4.8.2 Network Status Reporting Subscription p. 46

In order to create a new subscription to request for notifications on network status, the SCS/AS shall send an HTTP POST request message to the SCEF on the "Network Status Reporting Subscriptions" resource. The body of the HTTP POST request shall include a Notification destination address and Location area information, and may include the time duration and threshold(s).

Upon receiving the HTTP POST request message from the SCS/AS, the SCEF shall check:

if the SCS/AS is authorized to perform the request. If not, the SCEF shall respond to the SCS/AS with an HTTP "401 Unauthorized" status code.
if the SCS/AS has exceeded its quota of submitting requests. If so the SCEF shall respond to the SCS/AS with an HTTP "403 Forbidden" status code and may indicate the failure reason "QUOTA_EXCEEDED" (i.e. the quota exceeded) within the "cause" attribute of the ProblemDetails data structure in the HTTP POST response.
if the SCS/AS has exceeded its rate of submitting requests. If so the SCEF shall respond to the SCS/AS with an HTTP "429 Too Many Requests" status code in the HTTP POST response.

After the SCEF authorized the HTTP request message, the SCEF shall create an "Individual Network Status Reporting Subscription" resource which represents the subscription, addressed by a URI that contains the SCS/AS identity and an SCEF-created subscription identifier, and shall respond to the SCS/AS with an HTTP "201 Created" status code, including a Location header field containing the URI for the created resource, to acknowledge to the SCS/AS the successful subscription creation. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this network status reporting subscription. Then, the SCEF shall trigger the network status reporting procedure with the RCAF over Ns interface as defined in TS 29.153.

In order to update an existing subscription of continuous network status reporting, the SCS/AS shall send an HTTP PUT request message to the SCEF on the "Individual Network Status Reporting Subscription" resource, using the URI received in the response to the request that has created the network status reporting subscription resource. After receiving the HTTP PUT request message, the SCEF shall send an HTTP PUT response to the SCS/AS with an HTTP "200 OK" status code including a representation of the updated "Individual Network Status Reporting Subscription" resource in the response body, or a "204 No Content" status code. Then, the SCEF shall apply the requested updatesand interact with the RCAF as defined in TS 29.153.

If the "PatchUpdate" feature defined in clause 5.9.4 is supported, in order to partially modify an existing subscription of continuous network status reporting, the SCS/AS shall send an HTTP PATCH request message to the SCEF on the "Individual Network Status Reporting Subscription" resource, using the URI received in the response to the request that has created the network status reporting subscription resource. The request body shall contain the NetStatusRepSubsPatch data structure including only the attributes that shall be updated. After receiving the HTTP PATCH request message, the SCEF shall send an HTTP response to the SCS/AS with an HTTP "200 OK" status code including a representation of the modified "Individual Network Status Reporting Subscription" resource in the response body, or a "204 No Content" status code. Then, the SCEF shall apply the requested changes and interact with the RCAF as defined in TS 29.153.

In order to remove an existing subscription of continuous network status reporting, the SCS/AS shall send an HTTP DELETE request message to the SCEF on the "Individual Network Status Reporting Subscription" resource, using the URI received in the response to the request that has created the network status reporting subscription resource. Upon reception of the HTTP DELETE request message, the SCEF shall send an HTTP DELETE response to the SCS/AS with an HTTP "204 No Content" status code. Then, the SCEF shall interact with the RCAF to terminate the continuous reporting of network status as defined in TS 29.153.

4.4.8.3 Network Status Reporting Notification p. 47

After receiving reports from all the involved RCAF(s) as defined in TS 29.153, the SCEF shall send an HTTP POST message to the SCS/AS using the identified destination URL, which is provided by the SCS/AS during the network status reporting subscription. The body of HTTP POST message shall include the NSI.

4.4.9 Procedures for Communication Pattern Parameters Provisioning p. 47

One or more set of CP parameters may be provisioned by the SCS/AS for a single UE or a group of UEs.

In order to create resources for one or more CP parameter set(s), the SCS/AS shall send an HTTP POST message to the SCEF for the "CP Provisioning Subscriptions" resource, including one or more new provisioned CP parameter set(s). The body of HTTP POST message shall include External Identifier or MSISDN for a single UE or External Group ID for a group of UEs, SCS/AS Identifier and one or more set of CP information associated with CP parameter set Id(s).

After receiving the HTTP POST message, the SCEF shall check if the SCS/AS is authorised. The SCEF may also check if the number of CP parameter sets(s) reaches the limitation based on operator policy or configuration.

After validation, the SCEF shall for each received CP parameter set Id, assign an SCEF Reference ID which may be derived from the CP parameter set Id, and send Update CP Parameter Request message to the HSS for delivering the CP parameter set(s) as specified in TS 29.336.

After receiving result from the HSS, if the result is successful, the SCEF shall create a resource "Individual CP Provisioning Subscription" and the corresponding sub-resources "Individual CP Set Provisioning" each represents a successfully provisioned CP parameter set indicated by the HSS and respond to the SCS/AS with a "201 Created" including Location header field containing the URI for the created subscription resource "Individual CP Provisioning Subscription" and the sub-resource(s) "Individual CP Set Provisioning" corresponding to each successful CP parameter set within the "self" attribute in the "cpParameterSet" attribute; otherwise, the SCEF shall not create any resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6. If not all CP parameters sets are provisioned successfully (i.e. the HSS indicates failure for some or all CP parameter sets and/or the SCEF does not accept the CP parameter provisioning (e.g. one or more CP Set Identifiers in the request are already present in existing subscriptions)), the SCEF shall also include CP report(s) within attribute "cpReports" with a list of failed CP Set Identifier(s) and the corresponding failure code as specified in table 5.10.2.3.5-1 in the body of the HTTP response.

In order to add new CP parameter set(s), update and/or remove the existing CP parameter set(s) for one or more CP parameter set Id(s), the SCS/AS may send an HTTP PUT message to the SCEF for the "Individual CP Provisioning Subscription" resource requesting to add new CP parameter set(s) by creating new resource(s), change some created properties (e.g. Validity Time) of the existing resource(s), and/or remove some or entire properties of the existing resource(s). After receiving the HTTP PUT message, the SCEF shall send the CP parameter changes to the HSS as specified in TS 29.336. After receiving the response from the HSS with a successful code, if the HSS indicates all CP parameter sets or some CP parameter sets are provisioned successfully, the SCEF shall create or update the corresponding sub-resource(s) "Individual CP Set Provisioning" each represents a successfully provisioned CP parameter set indicated by the HSS and send an HTTP response to the SCS/AS with a "200 OK" status code and include a list of successful CP parameter set(s) in the body of the HTTP response, or a "204 No Content" status code. Otherwise, the SCEF shall not create or update the resource(s) and shall send an HTTP response to the SCS/AS with a corresponding failure code as described in clause 5.2.6. If not all CP parameters sets are provisioned successfully (i.e. the HSS indicates failure for some or all CP parameter sets and/or the SCEF does not accept the CP parameter provisioning (e.g. one or more CP Set Identifiers in the request are already present in existing subscriptions)), the SCEF shall also include CP report(s) within attribute "cpReports" with a list of failed CP Set Identifier(s) and the corresponding failure code as specified in table 5.10.2.3.5-1 in the body of the HTTP response.

The SCS/AS may send a HTTP PUT message to the SCEF for the "Individual CP Set Provisioning" resource requesting to replace an individual resource identified by the CP parameter set Id. The body of the HTTP PUT message shall include set of CP information. After receiving such request, the SCEF shall interact with the HSS as specified in TS 29.336. After receiving the response from the HSS with a successful code, the SCEF shall update the resource and send an HTTP response to the SCS/AS with a "200 OK" status code or a "204 No Content" status code; otherwise, the SCEF shall not update the resource and shall send an HTTP response to the SCS/AS with a corresponding failure code as described in clause 5.2.6. If the provisioning of the CP set fails (i.e. the HSS returns failure for the CP set or the SCEF does not accept the CP set provisioning), the SCEF shall reject the request with a corresponding status code, and include the attribute "cpReports" with the corresponding failure code as specified in table 5.10.2.3.5-1 and the CP Set Identifier for which the provisioning has failed.

The SCS/AS may send an HTTP DELETE message to the SCEF requesting to delete an individual CP set resource "Individual CP Set Provisioning". After receiving such request, the SCEF shall determine the SCEF Reference ID for Deletion associated with the CP parameter set Id, and interact with the HSS as specified in TS 29.336. After receiving the response from the HSS, the SCEF shall delete the addressed resource and send an HTTP response to the SCS/AS with a "204 No Content" status code.

The SCS/AS may send an HTTP DELETE message to the SCEF requesting to delete an individual subscription resource "Individual CP Provisioning Subscription". After receiving such request, the SCEF shall determine the SCEF Reference ID (s) for Deletion associated with the CP parameter set Id(s) and interact with the HSS as specified in TS 29.336. After receiving the response from the HSS, the SCEF shall delete the addressed resource and its sub-resources addressed by "Individual CP Set Provisioning" and send an HTTP response to the SCS/AS with a "204 No Content" status code.

4.4.10 Procedures for PFD Management p. 48

The PFDs associated with application identifier(s) may be created, updated or removed by the third party SCS/AS as defined in TS 23.682.

In order to create PFDs resources for one or more external Application Identifier(s), the SCS/AS shall send an HTTP POST message to the request URI of the resource "PFD Management Transactions" including one or more PFD(s) for external Application Identifier(s). The body of the HTTP POST message shall include external Application Identifier(s) and PFDs associated with its PFD Identifier(s), an Allowed Delay may be included for the external Application Identifier(s) as well.

After receiving the HTTP POST message, if the SCS/AS is authorized, the SCEF shall provision the PFDs to the PFDF as defined in TS 29.250. When receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code. If one or more external application identifiers are provisioned successfully, the SCEF shall create an "Individual PFD Management Transaction" resource for the request and he corresponding sub-resources "Individual Application PFD Management" each represents a successfully provisioned external application identifier. The SCEF shall respond to the SCS/AS with a 201 Created including Location header field containing the URI for the created transaction resource "Individual PFD Management Transaction" and the sub-resource(s) "Individual Application PFD Management" corresponding to each external application identifier within the "self" attribute in the "PfdData" data type, the SCEF shall also include PFD report(s) with a list of external Application Identifier(s) and result(s) in the body of the HTTP response if some application(s) are not provisioned successfully (i.e. the PFDF returns failure and/or the SCEF does not accept the PFD provisioning (e.g. one or more external Application Identifiers in the request are already present in existing transactions)).

In order to update the PFDs for an existing individual transaction, the SCS/AS shall send an HTTP PUT message to URI of the resource "Individual PFD Management Transaction" including one or more PFD(s) for external Application Identifier(s). After receiving the HTTP PUT message, the SCEF shall make the change and send the change to the PFDF (i.e. add/update/remove PFDs) as defined in TS 29.250. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code. The SCEF shall create or update the corresponding sub-resource(s) "Individual Application PFD Management" each represents a successfully provisioned external application identifier, and also include PFD report(s) with a list of external Application Identifier(s) and result(s) in the body of the HTTP response if some application(s) are not provisioned successfully (i.e. the PFDF returns failure and/or the SCEF does not accept the PFD provisioning (e.g. one or more external Application Identifiers in the request are already present in existing transactions)).

If the "PatchUpdate" feature defined in clause 5.11.4 is supported, in order to partially modify an existing PFD Management Transaction, the SCS/AS shall send an HTTP PATCH request message to the SCEF on the "Individual PFD Management Transaction" resource, using the URI received in the response to the request that has created the concerned PFD Management Transaction resource. The request body shall contain the PfdManagementPatch data structure including only the attributes that shall be updated. After receiving the HTTP PATCH request, the SCEF shall apply the requested modifications and interact with the concerned PFDF to add/update/remove PFD(s) as defined in TS 29.250. After receiving the response of the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code. The SCEF shall then create or update the corresponding "Individual Application PFD Management" sub-resource(s), with each represents a successfully provisioned external application identifier. If some application(s) are not provisioned successfully (i.e. the PFDF returns a failure and/or the SCEF does not accept the PFD provisioning (e.g. one or more external Application Identifiers in the request are already present in existing transactions)), the SCEF shall also include PFD report(s) containing a list of external Application Identifier(s) and result(s) in the body of the HTTP response.

In order to update the PFDs for an existing external Application Identifier, the SCS/AS shall send an HTTP PUT message to the resource "Individual Application PFD Management" to update the full set of PFD(s) of an existing resource. After receiving the HTTP PUT message, the SCEF shall make the change and send the change to the PFDF (i.e. add/update/remove PFDs) as defined in TS 29.250. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

For the POST message to the resource "PFD Management Transactions" or the PUT message to the resource "Individual PFD Management Transaction", if the provisioning of all application(s) fails (i.e. the PFDF returns failure and/or the SCEF does not accept the PFD provisioning), the SCEF shall respond with 500 Internal Server Error status code, and include the attribute "pfdReports" with the corresponding failure reason as specified in table 5.11.2.2.3-1 and the external Application Identifier(s) for which the provisioning has failed.

In order to update the PFDs for an existing external Application Identifier, the SCS/AS shall send an HTTP PUT message to the resource "Individual Application PFD Management" to update the full set of PFDs of an existing resource. After receiving the HTTP PUT message, the SCEF shall make the change and send the change to the PFDF (i.e. add/update/remove PFDs) as defined in TS 29.250. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

In order to update the PFDs for an existing external Application Identifier, the SCS/AS may also send an HTTP PATCH message to URI of the resource "Individual Application PFD Management" to partially update PFDs. After receiving the HTTP PATCH message, the SCEF shall make the change and send the change to the PFDF (i.e. add/update/remove PFDs) as defined in TS 29.250. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

In order to remove the PFDs for an existing individual application, the SCS/AS shall send an HTTP DELETE message to the resource "Individual Application PFD Management". After receiving such request, the SCEF shall delete the resource and interact with the PFDF as defined in TS 29.250. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

For the PUT/PATCH message to the resource "Individual Application PFD Management", if the provisioning of the application fails (i.e. the PFDF returns failure or the SCEF does not accept the PFD provisioning), the SCEF shall reject the request with a corresponding status code, and include the attribute "pfdReports" with the corresponding failure code as specified in table 5.11.2.2.3-1 and the external Application Identifier for which the provisioning has failed.

If the SCEF receives PFD management notification including the PFD failure report from the PFDF (as defined in TS 29.250) and if the feature PfdMgmtNotification is supported, the SCEF shall notify the SCS/AS with an HTTP POST message, identified by the notification destination URI received during the PFD provisioning, to notify the failure result for the PFD management by including the PfdReport data type in the body of the message. Within the PfdReport data type, the SCEF shall include the impacted application id(s) within the "externalAppIds" attribute, the "failureCode" attribute set to "PARTIAL_FAILURE". In addition, if the SCEF receives the location area(s) of PCEF/TDF(s) which are unable to enforce the PFD(s) from the PFDF, the SCEF shall include the location area(s) within the "locationArea" attribute of the PFD report(s). After receiving the HTTP POST message, the SCS/AS shall send a HTTP response with "204 No Content" status code.

4.4.11 Procedures for Enhanced Coverage Restriction Control p. 50

The procedures are used by an SCS/AS to query the status of, or to configure the enhanced coverage restriction for a UE via the T8 interface as defined in TS 23.682.

In order to query the current status of enhanced coverage restriction, the SCS/AS shall send an HTTP POST message to the SCEF using the query custom operation as defined in clause 5.12.3.2. The body of the HTTP POST message shall include External Identifier or MSISDN.

In order to configure the enhanced coverage restriction, the SCS/AS shall send an HTTP POST message to the SCEF using the configure custom operation as defined in clause 5.12.3.3. The body of the HTTP POST message shall include External Identifier or MSISDN and the Enhanced Coverage Restriction setting (i.e. allowed-PLMN-List or restricted-PLMN-List).

Upon receiving the HTTP POST message from the SCS/AS, the SCEF shall check:

if the SCS/AS is authorized to perform the request. If not the SCEF shall respond to the SCS/AS with a status code set to 401 Unauthorized.
if the request is malformed. If it is malformed, the SCEF shall respond to the SCS/AS with a status code set to 400 Bad Request.
if the SCS/AS has exceeded its quota of submitting requests. If so the SCEF shall respond to the SCS/AS with a status code set to 403 Forbidden and may indicate the failure reason "QUOTA_EXCEEDED" (i.e. the quota exceeded) within the "cause" attribute of the "ProblemDetails" structure in the HTTP POST response.
if the SCS/AS has exceeded its rate of submitting requests. If so the SCEF shall respond to the SCS/AS with a status code set to 429 Too Many Requests in the HTTP POST response.

The SCEF shall send a Configuration Information Request to the HSS to query or configure the setting of Enhanced Coverage Restriction as defined in TS 29.336.

Upon receipt of the response from the HSS, the SCEF shall send an HTTP response to the SCS/AS with a 200 OK message for query or configure custom operation and include the Enhanced Coverage Restriction Data from HSS into the HTTP response.

If the SCEF receives a response with an error code from the HSS, the SCEF shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.