6.8 SBI Message Priority Mechanism

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

6.8.1 General

The primary usage of SBI Message Priority (SMP) is to provide guidance to 5GC NF acting as HTTP/2 clients or servers and HTTP/2 proxies when making throttling decisions related to overload control. The priority information may also be used for routing in proxies. Eventually a server may use the priority information to process higher-priority requests before lower-priority requests.

The SMP mechanism defined in this clause uses the "3gpp-Sbi-Message-Priority" custom HTTP header defined in clause 5.2.3.2.1 to set and carry the message priority between the client and the server.

NOTE 1: The custom HTTP header enforces the message priority end to end between the client and the server through one or more proxies.

The SMP mechanism should also use the stream priority mechanism specified in IETF RFC 7540 [7] clause 5.3.

NOTE 2: The stream priority enforces the message priority at the HTTP/2 connection level not end to end.

HTTP/2 clients, servers and proxies implementing SBIs shall support the custom HTTP header and should support the stream priority.

6.8.2 Message level priority

A client, proxy and server shall use the "3gpp-Sbi-Message-Priority" value (see clause 5.2.3.2.1) when setting or evaluating the priority of a message.

The client shall assign the request priority by adding the "3gpp-Sbi-Message-Priority" custom HTTP header (see clause 5.2.3.2.1) to the message and setting its value.

If the "3gpp-Sbi-Message-Priority" custom HTTP header is not present in a response message then the HTTP nodes shall use the priority indicated in the "3gpp-Sbi-Message-Priority" of the associated request message.

If the server wants to assign a different priority to the response message than the request one then the server shall assign the response priority by adding the "3gpp-Sbi-Message-Priority" custom HTTP header to the message and setting its value.

6.8.3 Stream priority

The purpose of HTTP/2 stream priority is to allow an endpoint to prioritize streams for transmitting frames when there is limited capacity for sending and to express how it would prefer its peer to allocate resources when managing concurrent streams. Setting the stream priority ensures a priority treatment to a message between the two endpoints of an HTTP/2 connection.

The stream priority applies to all frames in both directions. If it is not changed until the stream is closed then all frames of the request and response messages will have the same priority. A client assigns a priority for a request and the correspondent response by including dependency and Weight information in the HEADERS frame that opens the stream carrying the message.

The stream dependency shall be set to 0.

If the stream priority is used then the stream priority Weight is mapped from the custom HTTP header. The mapping algorithm shall respect the ordering of the priority. If message 1 has a priority of "x" and message 2 has a priority of "y" where "x" is lower than "y" then the Weight of the stream carrying the message 1 shall be higher than the Weight of the stream carrying the message 2.

If the server wants to change the priority of the response, it shall send a PRIORITY frame after the stream state became "half-closed (remote)" or shall send the priority information in the HEADERS frame.

6.8.4 Recommendations when defining SBI Message Priorities

The recommendations provided in this clause are compliant with clause 10 of IETF RFC 7944 [19]. The priority value range defined over SBIs spans from 0 to 31 (decimal), where 0 indicates the highest priority and 31 indicates the lowest priority. The recommendations have been adapted to 5G services and Service Based Architecture.

The priorities defined for all messages across all SBIs used in an HTTP/2 administrative domain must be defined in a consistent and coordinated fashion, taking the default priority (see below for default priority values) into account.

The following are some guidelines to be considered when defining the SMPs to be used in SBA networks that support HTTP/2 nodes handling multiple services.

– As with any prioritization scheme, it is possible for higher-priority messages to block lower-priority messages from ever being handled. In 5GC, this will often result in the messages being retried. This may result in more traffic than the network would have handled without use of the SMP mechanism.

One potential guideline to prevent unwanted starving of lower-priority messages is to have higher-priority messages represent a relatively small portion of messages handled by the 5GC under normal scenarios. The Multimedia Priority Service (see 3GPP TS 23.501 [5] clause 5.16.5) and the Mission Critical Service (see 3GPP TS 23.501 [5] clause 5.16.6) typically generate little traffic compared to the total traffic of a 5GC.

The Multimedia Priority Service (MPS) and the Mission Critical Service (MCX) require the blocking of lower-priority services.

– A network entity (e.g., the AMF) that has received an RRC Establishment Cause associated with priority service (e.g., mps-PriorityAccess, mcs-PriorityAccess, or highPriorityAccess) or has determined that the UE has a priority subscription (e.g., MPS, MCX) in the UDM/UDR, shall select an SMP value appropriate for the priority service (e.g., MPS, MCX) for use in requests and responses.

NOTE 1: Other situations (e.g., certain ARP, 5QI Priority Level or 5QI values) and/or other network elements (e.g., UDM, PCF, etc.) can also set the SMP to an appropriate level for a priority service.

– When setting priorities for Multimedia Priority Services, Mission Critical Services or Emergency calls, it is important to use the same priority values across all APIs and services exposed by the 5GC. For instance, if the MPS priority levels of [1; n] are assigned the values of [k; k+n-1], then the same values shall be defined in the same order on all SBIs for the same service.

– Messages related to MPS, MCX and Emergency calls may be ranked according to their priority (e.g., based on ARP priority level, 5QI priority level, MPS Priority) based on regional/national regulatory and operator policies when it is known by the application sending the message. Otherwise MPS and MCX should have higher priorities than Emergency calls. Emergency call related messages should have higher priority than the rest of the messages. The ranking can be used to select SMP values.

NOTE 2: In some situations (e.g. REGISTRATION or SERVICE REQUEST procedure); it is possible to identify that the message belongs to a procedure of a high priority user without knowing the identity of the priority service. In such a case, all the messages sent over an SBI of these high priority procedures should be given the same SBI message priority.

The following are general requirements:

– Requests without the "3gpp-Sbi-Message-Priority" header shall be assigned the default priority value of "24".

– Streams without priority shall be assigned a Stream Dependency of 0x0 and the default Weight of 16.

– When defining priorities of the messages of a service, the same rules apply independently of the application, the SBI and the service:

– When there is a series of request/response required to complete a procedure, it is appropriate to mark request/responses that occur later in the series at a higher priority than those that occur early in the series.

– The requests that establish new sessions should have a lower priority than the requests that update or end a session.

– The requests that will result in deregistering users if they failed (e.g., due to authentication vector retrieval, or update location) shall have a higher priority than the requests of a non-registered user.

– Request/responses of optional procedures and of delay tolerant services should have lower priority than those of mandatory procedures.

6.8.5 HTTP/2 client behaviour

The client sending a request shall determine its required priority according to 6.8.4. It shall include a "3gpp-Sbi-Message-Priority" header (see clause 5.2.3.2.1) indicating the required priority level in the request and shall prioritise the requests according to the required priority level. If the client also uses the stream priority at the HTTP/2 connection level then it shall map the header value into a Weight and include it in the HEADERS of the request message.

When the client receives a response with the "3gpp-Sbi-Message-Priority" header, it shall prioritise the received response according to the priority level received, otherwise according to the priority level of the corresponding request. This includes determining the order in which responses are handled and resources that are applied to the handling of the responses. The client may use the stream priority to determine how to prioritize the response at the HTTP/2 connection level.

6.8.6 HTTP/2 server behaviour

The server should use the "3gpp-Sbi-Message-Priority" header (see clause 5.2.3.2.1) and may use the stream priority information to determine how to handle the request. This includes determining the order in which requests are handled and resources that are applied to the handling of the request.

Servers should use "3gpp-Sbi-Message-Priority" value when making overload throttling decisions.

Servers should use stream priority information when making overload throttling decisions at the connection level.

When the priority of the response message needs to have a different value than the request, a server shall include a "3gpp-Sbi-Message-Priority" header in the response message which value is set to the response required priority level.

If a server has included "3gpp-Sbi-Message-Priority" header in the response message it may also set the stream priority as described in IETF RFC 7540 [7], via priority information in the HEADERS frame or in a PRIORITY frame. In both cases the priority Weight value shall be mapped from the 3gpp-Sbi-Message-Priority" header value. When sending the priority information with a PRIORITY frame the server shall send it before sending the HEADERS frame of the response message. A server shall not send a PRIORITY frame after the HEADER one.

6.8.7 HTTP/2 proxy behaviour

A proxy should forward request and response without removing the "3gpp-Sbi-Message-Priority" header or changing its value.

While done only in exceptional circumstances, a proxy may modify priority information when relaying request and response by changing the "3gpp-Sbi-Message-Priority" value. For example, a SEPP may modify the priority set by a roaming partner.

Proxies should use the request priority information (respectively response priority information) according to the "3gpp-Sbi-Message-Priority" value and may use the stream priority Weight value when making overload throttling decisions to a request (respectively a response).

Proxies may use the priority information according to the "3gpp-Sbi-Message-Priority" value and may use the stream priority Weight value when relaying a request or a response messages. This includes the selection of routes (only for the requests) and the ordering of messages relayed.

6.8.8 DSCP marking of messages

A client, proxy or server may prioritize traffic at IP level by placing messages into different traffic classes and marking them with an appropriate Differentiated Services Code Point (DSCP).

Multiple HTTP/2 connections between two HTTP/2 end points are necessary: one per DSCP value. All messages sent over a connection are assigned the same traffic class and receive the same DSCP marking. The "3gpp-Sbi-Message-Priority" value shall be considered in the selection of the appropriate connection to send the message.