Content for TS 29.122 Word version: 19.0.0
4.4.12 Procedures for Network Parameter Configuration
4.4.12.1 General
4.4.12.2 Configuration Request for an individual UE
4.4.12.3 Configuration Request for a group of UEs
4.4.12.4 Notification of applied parameter configuration
4.4.13 Procedures for setting up an AS session with required QoS
4.4.14 Procedures for MSISDN-less Mobile Originated SMS
4.4.14.1 General
4.4.14.2 Delivery of MSISDN-less MO SMS
4.4.15 Procedures for RACS Parameter Provisioning
...
...
4.4.12 Procedures for Network Parameter Configuration p. 51
4.4.12.1 General p. 51
The procedures are used by an SCS/AS to request that the network consider setting the suggested network parameter values which can influence certain aspects of UE/network behaviour. The procedures are applicable for an individual UE or a group of UEs.
In order to create a new network parameter configuration to configure suggested network parameters, the SCS/AS shall send an HTTP POST request message to the SCEF to the resource "NP Configurations". The body of the HTTP request message shall include External Identifier or MSISDN or External Group Identifier, SCS/AS Identifier, and may include Maximum Latency, Maximum Response Time and Suggested Number of Downlink Packets and Group Reporting Guard Time, wherein, the External Identifier or MSISDN indicates the configuration for an individual UE and the External Group Identifier indicates for a group of UEs. If the External Group Identifier is included, the SCS/AS shall provide the Notification Destination Address in the request.
In order to update an existing Network Parameter Configuration, the SCS/AS may send an HTTP PUT message to the resource "Individual NP Configuration" requesting the SCEF to replace all properties in the existing resource.
The SCS/AS may also use an HTTP PATCH message to request to change some properties in the existing resource.
Upon receipt of the HTTP POST, PUT or PATCH message, if the SCS/AS is authorized to perform the request, the SCEF shall check whether the Maximum Latency, Maximum Response Time and/or Suggested Number of Downlink Packets in the HTTP request body are within the range defined by operator policies, if one or more of these parameters are not within the range, the SCEF shall:
- either reject the request message by sending an HTTP response to the SCS/AS with a status code set to "403 Forbidden" , in which it may indicate the "PARAMETER_OUT_OF_RANGE" application error in the "cause" attribute of the "ProblemDetails" data structure and it may also indicate which parameters are out of the range in the "invalidParams" attribute of the "ProblemDetails" structure in the response body; or
- modify the parameters which are not within the range by selecting different values which are in the range.
4.4.12.2 Configuration Request for an individual UE p. 51
If the configuration request from the SCS/AS is for an individual UE, the SCEF shall send the Configuration Information Request command to the HSS via S6t as defined in TS 29.336.
Upon receipt of the response from the HSS, the SCEF shall,
- for the HTTP POST message, create a new resource "Individual NP Configuration" addressed by a URI that contains the SCS/AS identifier and an SCEF-created configuration identifier, and send an HTTP POST response to the SCS/AS with "201 Created" status code, the final suggested configuration parameter(s) (if modified), the indication(s) for the discarded parameter(s) (if discarded), and a location header field containing the URI for the created resource.
- for the HTTP PUT or PATCH message, update the active resource "Individual NP Configuration", and send an HTTP response to the SCS/AS with "200 OK" status code, the final suggested network parameter(s) (if modified), the indication(s) for the discarded parameter(s) (if discarded), or a "204 No Content" status code.
4.4.12.3 Configuration Request for a group of UEs p. 52
If the configuration request from the SCS/AS is for a group of UEs, the SCS/AS shall provide the Notification Destination Address, the SCEF shall send the Configuration Information Request command to the HSS via S6t as defined in TS 29.336.
Upon receipt of the successful response indicating that group processing is in progress from the HSS before beginning the processing of individual UEs, the SCEF shall,
- for the HTTP POST message, create a resource "Individual NP Configuration" addressed by a URI that contains the SCS/AS identity and an SCEF-created configuration identifier. The SCEF shall send an HTTP POST response to the SCS/AS including a location header field containing the URI for the created resource and a "201 Created" status code to acknowledge the SCS/AS of the successful group processing request.
- for the HTTP PUT or PATCH message, update the resource "Individual NP Configuration" addressed by the requested URL, and shall send "200 OK" status code or a "204 No Content" status code to acknowledge the SCS/AS of the successful group processing request in the HTTP response message.
4.4.12.4 Notification of applied parameter configuration |R16| p. 52
If the Enhanced_param_config feature is supported and the SCEF receives currently applied parameter configuration from the HSS, the SCEF shall notify the SCS/AS by the HTTP POST message including the parameter changes in the "appliedParam" attribute.
4.4.13 Procedures for setting up an AS session with required QoS p. 52
This procedure is used to set up an AS session with required QoS for the service as defined in TS 23.682.
For initial AS session creation, the SCS/AS shall send an HTTP POST message to the SCEF for the "AS Session with Required QoS Subscriptions" resource. The body of HTTP POST message shall include SCS/AS Identifier, UE IP address, IP Flow description, QoS reference and notification destination address. And it may also include time period and/or traffic volume for sponsored data connectivity purpose. If the feature AppId is supported, either the Flow description or an external Application Identifier shall be included.
After receiving the HTTP POST message, the SCEF shall authorize the request and may check if the total number of requested QoS reference has exceeded the limit for the SCS/AS. If the authorization is successful, the SCEF shall map the SCS/AS Identifier to AF Application Identifier if the external Application Identifier is not provided and only one AF Application Identifier is mapped, and if required, map the SCS/AS Identifier to ASP Identity and Sponsor Identity.
If the authorization performed by the SCEF is successful, then the SCEF shall act as an AF to interact with the PCRF via the Rx interface as defined in TS 29.214 or TS 29.201 and trigger a PCRF initiated IP-CAN Session Modification. Based on local configuration, the SCEF may also request to be notified about the transmission resource status, i.e. INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION, INDICATION_OF_RELEASE_OF_BEARER, INDICATION_OF_FAILED_RESOURCES_ALLOCATION, and optionally INDICATION_OF_LOSS_OF_BEARER and INDICATION_OF_RECOVERY_OF_BEARER. If the time period and/or traffic volume are received from the AF, the SCEF should subscribe to the PCRF on the USAGE_REPORT event.
If the "enNB" feature is supported, the SCEF may explicitly receive a list of user plane event(s) that the SCS/AS requests to subscribe to. The SCEF shall subscribe to the corresponding PCRF event(s) (e.g. INDICATION_OF_SUCCESSFUL_RESOURCE_ALLOCATION) for the received event(s) (e.g. SUCCESSFUL_RESOURCES_ALLOCATION), except for the SESSION_TERMINATION event.
The SCEF, after receiving the AAA message or HTTP 201 Created message over the Rx interface from the PCRF with successful result code, shall create a resource "Individual AS Session with Required QoS Subscription" which represents AS session, addressed by a URI that contains the SCS/AS identity and an SCEF-created AS session identifier, and shall respond to the SCS/AS with a 201 Created message, including the result in the body of the HTTP response and a Location header field containing the URI for the created resource. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this AS session. Otherwise, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code and include the result in the body of the HTTP response. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not create the resource and respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.
In order to update the established AS session, the SCS/AS may send an HTTP PUT message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource requesting to replace all properties (e.g. new usage threshold, Flow Description or external Application Identifier) in the existing resource, addressed by the URI received in the response to the request that has created the resource. The UE IP or MAC address shall remain unchanged from previously provided values. After receiving such message, the SCEF shall make the change (e.g. if the usage threshold within the "usageThreshold" attribute is included in the HTTP PUT request and the accumulated usage report for the previously provided usage threshold is not received yet, the SCEF shall completely replace the previously provided one), and interact with the PCRF to modify the Rx session (as defined in TS 29.214 or TS 29.201). After receiving the response with successful result code from the PCRF, the SCEF shall replace all properties of the existing resource, send an HTTP response to the SCS/AS with a "200 OK"status code, and include the result in the body of the HTTP response or a "204 No Content" status code. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not update the resource and respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.
The SCS/AS may also send an HTTP PATCH message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource requesting to change some created properties (e.g. new usage threshold, Flow Description or external Application Identifier, updated list of user plane event(s) if the "enNB" feature is supported). After receiving the HTTP PATCH message, the SCEF shall make the change (e.g. if the usage threshold within the "usageThreshold" attribute is included in the HTTP PATCH request and the accumulated usage report for the previously provided usage threshold is not received yet, the SCEF shall completely replace the previously provided one), and interact with the PCRF to modify the Rx session (as defined in TS 29.214 or TS 29.201). After receiving the response from the PCRF, the SCEF shall send an HTTP response to the SCS/AS with a "200 OK"status code and include the result in the body of the HTTP response, or a "204 No Content" status code.
If the SCEF receives a traffic plane notification (e.g. the usage threshold is reached or transmission resource lost), or if the SCEF gets informed that the Rx session is terminated (e.g. due to a release of PDN connection), the SCEF shall send an HTTP POST message including the notified event (e.g. session terminated) and the accumulated usage (if received from the PCRF) to the callback URI "notificationUri" provided by the SCS/AS during the creation of individual AS Session with Required QoS Subscription. The SCS/AS shall respond with an HTTP response to confirm the received notification.
In order to remove the established AS session, the SCS/AS shall send an HTTP DELETE message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource. After receiving the HTTP DELETE message, the SCEF shall remove all properties and interact with the PCRF to terminate the Rx session (as defined in TS 29.214 or TS 29.201). After receiving the response from the PCRF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code and include the accumulated usage (if received from the PCRF).
4.4.14 Procedures for MSISDN-less Mobile Originated SMS p. 54
4.4.14.1 General p. 54
The procedures are used by the SCEF to send the MSISDN-less MO-SMS to the SCS/AS via T8 interface.
4.4.14.2 Delivery of MSISDN-less MO SMS p. 54
If the SCEF receives an MSISDN-less MO-SMS via T4 including an destination SME address (long/short code of the SCS/AS), the SCEF will use the IMSI of the UE and application port ID received over T4 to query the HSS/HLR for an external ID, and the SCEF shall then determine the notification destination URL of an SCS/AS based on configured information on the mapping of SME addresses to destination URLs. The SCEF shall send to the determined destination URL an HTTP POST request that shall include an MsisdnLessMoSmsNotification data type with:
- the short message transfer protocol data unit as received on the T4 interface.
- the Application Port as received on the T4 interface, and
- the external identifier of the UE that send the SMS, as received from the HSS/HLR.
4.4.15 Procedures for RACS Parameter Provisioning |R16| p. 54
The procedures are used by an SCS/AS to request that the network to provision manufacturer specific UE radio capability information.
In order to create a new parameter provisioning, the SCS/AS shall send an HTTP POST request message to the SCEF to the resource "RACS Parameter Provisionings". The body of the HTTP POST request message shall include a list of RACS IDs, and for each provided RACS ID, its radio capability parameters and the related UE model(s) IMEI-TAC value(s).
In order to fully replace an existing RACS Parameter Provisioning, the SCS/AS may send an HTTP PUT message to the resource "Individual RACS Parameter Provisioning" requesting the SCEF to change all properties in the existing resource. The body of the HTTP PUT request message shall include a list of RACS IDs, and for each provided RACS ID, its radio capability parameters and the related UE model(s) IMEI-TAC value(s).
In order to partial update an existing RACS Parameter Provisioning, the SCS/AS may send an HTTP PATCH message to the resource "Individual RACS Parameter Provisioning" requesting the SCEF to change some properties in the existing resource.
Upon receipt of the HTTP POST, PUT or PATCH message, if the SCS/AS is authorized to perform the request, the SCEF shall interact with the UCMF as described in TS 29.675. After receiving the response from the UCMF, if at least one RACS ID is succesfully provisioned, the SCEF shall create or update the resource "Individual RACS Parameter Provisioning" and respond with 201 Created or 200 OK to the SCS/AS respectively with the successfully provisioned RACS information or 204 No Content if the updates or replacement is successful with no content in the PATCH or PUT response message body, the SCEF may include RACS report(s) within attribute "racsReports" with a list of RACS ID(s) and the corresponding failure code for which the provisioning has failed as specified in table 5.16.2.2.3-1 in the body of the HTTP response. Otherwise, the SCEF shall send an HTTP response to the SCS/AS with a corresponding failure code as described in clause 5.16.5. If all the RACS IDs failed to be provisioned succeessfully, the SCEF may send a "500 Internal Server Error" HTTP response and may include in the response body failure reports as specified in clause 5.16.3.
In order to delete an existing RACS Parameter Provisioning at the SCEF, the SCS/AS shall send an HTTP DELETE message to the corresponding resource "Individual RACS Parameter Provisioning" at the SCEF. Upon receipt of the DELETE request message, the SCEF shall interact with the UCMF as described in TS 29.675. After receiving the response from the UCMF, the SCEF shall remove the resource and respond with 204 No Content to the SCS/AS.
