Content for  TS 24.229  Word version:  19.0.0

For the IM CN subsystem, the support of local service numbers is provided by an AS in the subscriber's home network as described in subclause 5.7.1.7.

In support of priority, the IM CN subsystem uses the mechanisms of RFC 4412. The request for prioritisation of a transaction / dialog may, for some deployments, be marked with the Resource-Priority header field by the UE. For other deployments, the request is not marked for priority by the UE, but the request is instead identified as a priority request and marked for priority (via a Resource-Priority header field) by a functional entity (e.g., P-CSCF) within the network. Subsequent to successful authorisation at an authorisation point (e.g. AS), request is considered to be authorised. The characteristics of any priority scheme is defined by the namespace that is used. This determines how priority is applied to the SIP signalling, to the bearer carrying the SIP signalling, and to the bearers carrying any media. Different priority levels exist within each namespace. Priority levels in one namespace have no relationship to the priority levels in any other namespace, i.e. priority level "1" in namespace "A" may have an entirely different level and characteristic of priority treatment to an identically labelled priority level "1" in namespace "B". A network can support multiple namespaces. It is up to the network operator (potentially based on regulatory or contractural obligations) to define the relationship between the priority mechanisms for each namespace, and indeed with calls that are not given any priority. It is normal that prioritised calls do not have access to 100% of any available resource and indeed are limited to a much lower figure. Priority is optional, and this document places no requirement on a conformant IM CN subsystem implementation to support priority, or indeed any namespace in a priority scheme. Regulators can however place their own requirements on an operator. Emergency transactions or dialogs (see subclause 4.7) can also have their own priority scheme. RFC 4412 specifies several resource priority namespaces. For example, certain national MPS implementations use resource priority namespaces of ETS (Emergency Telecommunications Service) and WPS (Wireless Priority Service). Several ways of using priority exist, depending on the authorisation mechanism adopted. These are identified as follows. In each of these authorisation means authorisation to use the service, the namespace, and the priority level within that namespace:

1. Authorisation based on subscription in the IM CN subsystem only, priority requested by the UE using the Resource Priority header field. Whether the user is allowed to use priority or not, and the appropriate namespace and priority levels, is stored as part of the user profile in the HSS. As part of the reg event package subscription, this information is given to the P-CSCF when the contact information for any public user identity changes, and based on this information, the P-CSCF acts as the authorisation point for priority on individual requests. At the P-CSCF, when a Resource-Priority header field is received from the UE, if the requested priority equates to a value (namespace and priority level) that the P-CSCF knows is allowed for that public user identity, the priority is authorised.
2. Authorisation based on a database deployed by an AS; priority requested by the UE using a special dialstring. In this case the user requires no priority subscription information in the HSS. Specific dialstrings are configured in the P-CSCF. When a request is received from the UE by the P-CSCF, if the request contains a specific dialstring that is recognised by the P-CSCF as being eligible for priority treatment, the request is marked for temporary priority, subject to subsequent authorisation by an authorisation point (i.e., AS). And all such requests are routed to an AS. Final authorisation is granted by the AS, based on a PIN or password exchange with the UE. Subsequent requests or responses after authorisation are only given priority by the P-CSCF and S-CSCF if some backwards indication is received for that specific dialog. The definition of this backwards indication is outside the scope of this document (because non-standardised mechanisms have already been implemented in association with this approach).
3. Authorisation based on subscription in the IM CN subsystem and on a database deployed by an AS; priority requested by the UE using a special dialstring. Specific dialstrings are configured in the P-CSCF. When a request is received from the UE by the P-CSCF, if the request contains a specific dialstring that is recognised by the P-CSCF as being eligible for priority treatment, the request is marked for temporary priority, subject to subsequent authorisation by an authorisation point (i.e., AS). Based on iFC functionality that exists at the S-CSCF (from the users subscription in the HSS), such requests are routed to an AS. Final authorisation is granted by the AS, based on a PIN or password exchange with the UE or based on user profile. Subsequent requests or responses after authorisation are only given priority by the P-CSCF and S-CSCF if some backwards indication is received for that specific dialog. The definition of this backwards indication is outside the scope of this document (because non-standardised mechanisms have already been implemented in association with this approach).

Some administrations can require the use of multiple approaches in the same network. When the network is required to prioritise IMS registration requests from particular UEs, a designated DSCP value can be set by the P-GW (as per subclause 11.9 of TS 29.061) or SMF/UPF (as per subclause 8.3 of TS 29.561). Based on regional/national requirements and network operator policy, when the P-CSCF receives a SIP REGISTER request transported using the designated DSCP value from a P-GW or UPF within the PLMN of the P-CSCF, the P-CSCF inserts an appropriate Resource-Priority header field. For the cases of interworking with other networks, where the P-CSCF of the other network does not support priority, but it is intended or required to give users of that P-CSCF priority in the home network, provision is made for recognition of dialstrings by the IBCF and the S-CSCF. In such scenarios, when the IBCF or S-CSCF recognize that a request contains a dialstring as being eligible for priority treatment, the request is marked by the IBCF or S-CSCF for temporary priority, subject to subsequent authorisation by an authorisation point (i.e. AS). This mechanism does not have an impact on the network where the P-CSCF resides. Where the network has a requirement to prioritise emergency calls, it can either perform this function by the use of the "esnet" namespace in the Resource-Priority header field (as defined in RFC 7135), or by recognition of the presence of the service URN relating to an emergency. Where the Resource-Priority header field is used for this purpose, it is inserted by the entity identifying the emergency call, i.e. the P-CSCF or the IBCF. There is no usage of this namespace from the UE, and when this namespace is used, the trust domain implementation is set to remove it if it occurs from the UE. Where a network has requirements on attestation and signing of priority IMS sessions (e.g., MPS sessions) the Priority verification using assertion of priority information feature described in subclause 3.1 shall be supported and the Calling number verification using signature verification and attestation information feature described in subclause 3.1 may be supported. Where the network has requirements on attestation and signing of originating calling identification information for emergency and emergency callback IMS sessions, and on authentication of a Resource-Priority header field and a header field value "psap-callback" of a Priority header field, Calling number verification using signature verification and attestation information and Priority verification using assertion of priority information features described in subclause 3.1 shall be supported.

Usage of overload control is independent of the nature of any SIP using entity, i.e. there are no specific requirements for any particular IMS functional entity implementing SIP. The capability however is not extended to the UE except when performing the function of an externally attached network. Two mechanisms are defined as follows:

• a feedback based mechanism defined in RFC 7339, where the feedback is given in the Via header field of signalling messages supporting the traffic. RFC 7339 also defines the default algorithm for usage of the feedback based mechanism in the IM CN subsystem (i.e. loss-based algorithm). Additional algorithms are either already defined, e.g. the rate-based scheme defined in RFC 7415 or can also be defined in the future. As it is carried in the Via header fields the nature of the mechanism is hop by hop.
• an event package for distributing load filters defined in RFC 7200, which can be either used in a hop-by-hop manner between adjacent entities in a similar manner to the feedback based mechanism, or can be used on a wider basis across the network, subject to the restrictions given in Annex A. In this manner it can be used to address expected overload situations, e.g. for voting calls initiated by a specific television programme.

When the load filters based mechanism is used in the IMS, the default algorithm is loss-based (i.e. the filter specifies the relative percentage of incoming requests that can be accepted). The S-CSCF, application servers and entities that implement the additional routeing capability can use both mechanisms in parallel on the same interfaces. There are no specific reasons why one protocol mechanism should be specified over another, although some discussion is given in the documents specifying the mechanisms themselves. It is regarded as a deployment issue as to which mechanisms are supported, and which algorithms are supported within those mechanisms, beyond those that the mechanisms themselves identify as mandatory. An operator will need to take a network wide view to planning their overload control strategy, it cannot be performed on ad-hoc basis as nodes are deployed. For the distribution of load filters mechanism, typical deployments might include an S-CSCF subscribing to the load control event package at an AS, an AS subscribing to the load control event package at an AS, and an entity hosting additional routeing capabilities as specified in subclause I.3 subscribing to the load-control event package at the AS. Based on regional/national requirements and network operator policy, priority calls (e.g., multimedia priority service) are exempted from SIP overload controls up to the point where further exemption would cause network instability. Therefore, SIP messages related to priority calls have the highest priority, and are last to be dropped or rejected, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction. The interaction between SIP overload control and priority services is covered in RFC 7339 and RFC 7200. Based on regional/national requirements and network operator policy, IMS registration requests that are identified as priority requests according to subclause 4.11 are exempted from SIP overload controls up to the point where further exemption would cause network instability. Therefore, SIP REGISTER requests marked as priority requests have the highest priority, and are last to be dropped or rejected, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction. The interaction between SIP overload control and priority services is covered in RFC 7339 and RFC 7200. Based on regional/national requirements and network operator policy, emergency calls are exempted from SIP overload controls up to a configured threshold. Therefore, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction due to overload control, SIP messages related to emergency calls are not dropped while the configured threshold regarding the amount of the ongoing emergency calls is not reached. Mid-dialog SIP messages have higher priority with regard to initial SIP requests, and therefore are last to be dropped or rejected, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction due to overload control. Operation between two network operators is supported. If two network operators wish to implement overload control, it is a matter for bilateral agreement as to what is supported. Operation with enterprise networks is supported. The network operator and the enterprise operator will need to agree on the overload control options to be supported.

Resource sharing allows two or more sessions to use the same resources for one or more media streams in uplink, downlink or both uplink and downlink direction. A P-CSCF that supports resource sharing can determine that there is a potential for resource sharing based on local configuration or defer the determination of potential resource sharing to an AS in the home network. If the determination of potential resource sharing is deferred to an AS in the home network:

• the P-CSCF on the originating side indicates that resource sharing is supported in the initial REGISTER request in the Resource-Share header field defined in subclause 7.2.13. The Resource-Share header field is included in the third-party REGISTER request towards the AS; and
• if the "message/sip" MIME body in the third-party REGISTER request included the Resource-Share header field with the value "supported", the AS in the home network includes the Resource-Share header field containing the rules for resource sharing in responses and requests towards the P-CSCF.

If the rules for resource sharing are updated, the updated rule will be sent to P-CSCF in one of the sessions that share resources. The updated resource sharing rules will then be applied for all sessions that are sharing resources.

Priority sharing allows two or more sessions with different priority to share the same bearer. The determination of the use of priority sharing is deferred to an AS in the home network:

1. if P-CSCF supports priority sharing and if according to local policy, the P-CSCF indicate that priority sharing is supported by including the g.3gpp.priority-share feature-capability indicator defined in subclause 7.9A.10 in a Feature-Caps header field in the REGISTER request;
2. if the "message/sip" MIME body in the third-party REGISTER request included the g.3gpp.priority-share feature-capability indicator and:
   1. if the AS determined to enable priority sharing, the AS includes the Priority-Share header field with a value "allowed" in a request or response sent towards the P-CSCF; or
   2. if the AS determined to disable priority sharing, the AS includes the Priority-Share header field with a value "not-allowed" in a request or response sent towards the P-CSCF.

The UE and the network can support the 3GPP PS data off. When 3GPP PS data off is supported and active, IP packets that are associated with services that are not a 3GPP PS data off exempt service are prevented from transport over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN as specified in TS 23.228. The UE may be configured by the HPLMN, the EHPLMN or the subscribed SNPN with up to two indications whether a 3GPP IMS service is a 3GPP PS Data Off exempt service, one indication is valid when the UE is in the HPLMN, the EHPLMN, or a subscribed SNPN and the other indication is valid when the UE is in the VPLMN or, if the UE supports access to an SNPN using credentials from a CH, a non-subscribed SNPN. When the UE is only configured with the indication valid for the UE camping in HPLMN the EHPLMN or a subscribed SNPN, the UE shall use this indication also when the UE is in the VPLMN or the non-subscribed SNPN. When 3GPP PS data off is supported and active and the UE is configured, either as specified in TS 24.167 or in TS 31.102, with services that are 3GPP PS data off exempt, then the UE will not send uplink IP packets related to any services that are not 3GPP PS data off exempt over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN. The UE informs the network about its 3GPP PS data off status by including a g.3gpp.ps-data-off media feature tag specified in subclauce 7.9.8 in all REGISTER requests sent over GPRS IP-CAN, EPS IP-CAN or 5GS IP-CAN. The UE reregisters over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN every time the 3GPP PS data off status is changed or the UE is provided by the network with a new list of 3GPP PS data off exempt services while the 3GPP PS data off status is "active". An AS handling a service is configured with information whether the service is a 3GPP PS data off exempt service. If the 3GPP PS data off status is active and the service is not a 3GPP PS data off exempt service, the AS prevents downlink IP packets of the service from reaching the UE over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN. The AS shall be configured with up to two indications whether a 3GPP IMS service is a 3GPP PS Data Off exempt service, one indication is valid for non-roaming users, and the other indication is valid for users roaming in the various VPLMNs with whom roaming agreements exist or users accessing non-subscribed SNPNs. When the AS is only configured with the indication valid for the UE camping in the HPLMN, the EHPLMN or the subscribed SNPN, the AS shall use this indication also when the UE is in the VPLMN or non-subscribed SNPN.

Dynamic Service Interaction allows that different ASs involved in the same IMS session (within an operator network or across networks) exchange information about executed services to avoid conflicting interactions between these services. Dynamic Service Interaction information is included in a SIP header field Service-Interact-Info defined in subclause 7.2.14. If an AS which supports dynamic service interaction:

• provides one or more services:
  1. the AS inserts in a SIP message the Service-Interact-Info header field with the identities of the services which have been performed; and
  2. if the AS identified services which should be further avoided the AS adds the identities of those services in the Service-Interact-Info header field; and
• receives a SIP message containing the Service-Interact-Info header field, the AS takes the received Service-Interact-Info header field information into account as described in subclause 7.2.14.3.

The UE and the network can support Restricted Local Operator Services (RLOS). RLOS services are operator defined services that are offered to UEs when using an EPS IP-CAN as specified in Annex L in the following scenarios:

• UE is successfully registered using IMS AKA or GPRS-IMS bundled authentication; or
• UE has attempted to register and the registration is rejected from the network with a 403 (Forbidden) response.

RLOS services are offered only for the UE-originating case. RLOS services can be offered to an operator's own subscribers and roaming subscribers.

The UE and the network can support the IMS data channel procedures as specified in TS 23.228 and TS 24.186. IMS data channels are always associated with MMTEL sessions.