Content for TS 29.155 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 4.1 Overview 4.2 Reference model 4.3 Functional elements 4.4 Procedures over St reference point
...

1 Scope p. 6

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.

2 References p. 6

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.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 23.203: "Policy and charging control architecture".

[3]

RFC 793: "Transmission Control Protocol".

[4] Void.

[5]

TS 29.201: "Representational State Transfer (REST) reference point between Application Function (AF) and Protocol Converter (PC)".

[6]

RFC 1786: "Uniform Resource Locators (URL)".

[7]

TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security".

[8]

RFC 1983: "Internet Users' Glossary".

[9] Void.

[10]

RFC 7159: "The JavaScript Object Notation (JSON) Data Interchange Format".

[11] Void.

[12]

RFC 5789: "PATCH Method for HTTP".

[13]

RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".

[14]

RFC 6902: "JavaScript Object Notation (JSON) Patch".

[15]

RFC 6901: "JavaScript Object Notation (JSON) Pointer".

[16]

draft-newton-json-content-rules-09: "A Language for Rules Describing JSON Content".

[17]

TS 29.212: "Policy and Charging Control (PCC); Reference points".

[18]

TS 29.213: "Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping".

[19]

RFC 2818: "HTTP Over TLS".

[20]

TS 23.003: "Numbering, addressing and identification".

[21]

RFC 6733: "Diameter Base Protocol".

[22]

RFC 7230: "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".

[23]

RFC 7231: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".

[24]

RFC 7232: "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests".

[25]

RFC 7233: "Hypertext Transfer Protocol (HTTP/1.1): Range Requests".

[26]

RFC 7234: "Hypertext Transfer Protocol (HTTP/1.1): Caching".

[27]

RFC 7235: "Hypertext Transfer Protocol (HTTP/1.1): Authentication".

3 Definitions and abbreviations p. 7

3.1 Definitions p. 7

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.

(S)Gi-LAN:

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.

JSON Content Rules:

JSON Content Rules (JCR), as defined in IETF draft-newton-json-content-rules [16] is a language specifying the interchange of data in JSON as defined in RFC 7159.

3.2 Abbreviations p. 7

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.

JCR

JSON Content Rules

JSON

JavaScript Object Notation

PCRF

Policy and Charging Rules Function

TSSF

Traffic Steering Support Function

4 St reference point p. 7

4.1 Overview p. 7

The St reference point resides between the PCRF and TSSF. St reference point is used to provision the traffic steering control information from the PCRF to the TSSF.

4.2 Reference model p. 7

The St reference point resides between the PCRF and TSSFas depicted in Figure 4.2-1. The overall PCC architecture is depicted in subclause 3a of TS 29.213.

Reproduction of 3GPP TS 29.155, Fig. 4.2-1: St reference model

Figure 4.2-1: St reference model

4.3 Functional elements p. 8

4.3.1 TSSF p. 8

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.

4.3.2 PCRF p. 8

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.

4.4 Procedures over St reference point p. 8

4.4.1 General p. 8

The procedures which can be operated at the St interface are described in the following subclauses.

4.4.2 Traffic Steering Policy Provisioning over St p. 8

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

4.4.3 Traffic Steering Rule Error Handling p. 9

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

4.4.4 UE IPv4 address provisioning p. 9

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 5.3.3.4; 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 5.3.3.4. 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.