The present document describes the Representational State Transfer (REST) protocol-based St reference point, which is used to provision the traffic steering control information to the TSSF from the PCRF.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
The network infrastructure connected to the 3GPP network over the SGi or Gi reference point that provides various IP-based services.
(S)Gi-LAN service function:
A function located in the (S)Gi-LAN that provides value-added IP-based services e.g. NAT, anti-malware, parental control, DDoS protection.
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
The TSSF is a function that receives traffic steering control information from the PCRF and ensures that the related traffic steering policy is enforced in the (S)Gi-LAN.
A traffic steering policy is locally configured in TSSF and can be used for uplink, downlink or for both directions. To ensure that the traffic steering policy is enforced, the TSSF performs deployment specific actions as configured for that traffic steering policy.
The PCRF functionality defined in TS 23.203 is applicable. In addition, the PCRF shall be able to make a decision of traffic steering policies used to control the steering of the subscriber's traffic to appropriate (S)Gi-LAN service functions.
When the PCRF determines the traffic steering control information needed for the IP-CAN session; the PCRF shall send an HTTP POST message to the TSSF to create a new session resource. The PCRF shall provide the representation of the session resource within the body of the HTTP POST. Within the body of the HTTP POST, the PCRF shall provide the St Session ID, the PDN information if required by the operator policies, the UE IPv4 address and/or UE IPv6 prefix and one or more sets of traffic steering control information to the TSSF.
The PCRF may modify or remove traffic steering control information at any time (e.g. due to subscription change or network status change) by sending either an HTTP PUT or HTTP PATCH message to the TSSF including the St session ID within the request URL. When using an HTTP PUT to modify the session resource, the PCRF shall provide the entire state of the session resource within the body of the HTTP PUT. In this case, the TSSF shall replace the existing session information associated with this resource with the information provided in the body of the HTTP PUT. When using an HTTP PATCH to modify the session resource, the PCRF shall provide the modifications within the body of the HTTP PATCH as defined in subclause 220.127.116.11. In this case, the TSSF shall update the existing session resource based on the content of the body of the HTTP PATCH.
In order to remove all of the traffic steering control information associated with an IP-CAN session when the IP-CAN session is terminated, the PCRF shall send to the TSSF an HTTP DELETE message including the St Session ID within the request URL.
Once the PCRF has requested the creation of a session resource, the PCRF may request the state of the session at any time by sending an HTTP GET request to the TSSF including the Session ID within the request URL. Upon receipt of an HTTP GET from the PCRF, the TSSF shall provide the session representation within the body of the response. Based on the received information, the PCRF may decide whether re-installation, modification, removal of the traffic steering control information or any other action applies.
When a combination of PCEF/TDF with traffic steering control feature and TSSF is deployed, the TSSF shall behave as specified in subclause 6.1.17 of TS 23.203. In this case, the PCRF shall provide the traffic detection information as part of the service data flow information included in the tos-traffic-class within the flow-information field or within the tdf-application-identifier field. If traffic detection is performed using the flow-information field, the PCRF shall ensure that the relevant value of the tos-traffic-class field included within the flow-information field used for traffic detection is the same as the value provided in the traffic steering policy identifier(s) provided over Gx or Sd reference point. If traffic detection is performed using the tdf-application-identifier field, the PCRF shall ensure that the identifier included within the tdf-application-identifier refers to the configured value(s) in the TSSF that correspond to the value provided in the traffic steering policy identifier(s) over Gx or Sd reference point. See TS 29.212.
If the installation/activation of one or more traffic steering rules fails, the TSSF shall inform the PCRF of the failed traffic steering rules in the corresponding JSON body of the HTTP response, by including a ts-rule-reports field, and by setting the error-tag to TS_RULE_EVENT. The ts-rule-reports field is an array of rule failure reports. Within each rule failure report, the TSSF shall identify the failed traffic steering rule(s) by including the resource-paths field containing a list of JSON pointer(s) to the relevant traffic steering rule resource(s), shall specify the failed reason code by including a rule-failure-code field and a rule-status as described below:
If the installation/activation of one or more new traffic steering rules (i.e., rules which were not previously successfully installed) fails, the TSSF shall set the rule-status field to INACTIVE.
If the modification of a currently active traffic steering rule fails, the TSSF shall retain the existing traffic steering rule as active without modification unless the reason for the failure also has an impact on the existing traffic steering rule.
Depending on the value of the rule-failure-code field, the PCRF may decide whether retaining of the old traffic steering rule, re-installation, modification, removal of the traffic steering rule or any other action applies.
If a traffic steering rule was successfully installed/activated, but can no longer be enforced by the TSSF, and if the notification supported feature is supported by the TSSF and PCRF, the TSSF shall notify the PCRF of the rule enforcement failure by sending an HTTP POST request to the notification URL provided by the PCRF as defined in subclause 18.104.22.168. The JSON body of this HTTP POST shall include a notification-info field containing a ts-rule-reports field and a notification-tag field set to a value of TS_RULE_EVENT filled. Each item of the ts-rule-reports shall include the corresponding rule-failure-code field and rule-status field to INACTIVE.
Note that the PCRF may poll the session state from the TSSF at any time via the HTTP GET method as described in subclause 4.4.2; and take further decisions based on the status of the traffic steering rules reported in the session state.
When the PCRF is notified by the PCEF that either a UE_IP_ADDRESS_ALLOCATE or a UE_IP_ADDRESS_RELEASE event of the IP-CAN session occured in the PCEF, the PCRF shall send an HTTP PATCH or PUT meesage to the TSSF including the St session ID within the request URL.
If the PCRF uses HTTP PUT to update the St session, the PCRF shall provide the entire state of the session resource including the new IPv4 in case a new IPv4 was allocated or omitting the IPv4 in case the IPv4 was released. If the PCRF uses the HTTP PATCH method to update the St session, and if the IPv4 was allocated, the PCRF shall use the "add" operation within the body of the HTTP PATCH to include the new IPv4 as specified in subclause 22.214.171.124; otherwise if the IPv4 was released, the PCRF shall use the "remove" operation within the body of the HTTP PATCH to remove the IPv4 as specified in subclause 126.96.36.199. If the PCRF provides the new UE Ipv4 address to the TSSF, the TSSF shall additionally apply the traffic steering rules to the user plane traffic with the IP address matching the new UE Ipv4 addres. If the PCRF notifies to the TSSF that the UE Ipv4 address has been released, the TSSF shall stop applying the traffic steering rule to the user plane traffic with the IP address matching the released UE Ipv4 address.