Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.9…   AC.10…

 

5.20  Procedures for Assigning, Using, and Processing GRUUs |R7|p. 206

5.20.1  UEp. 206

5.20.1.1  Obtaining a GRUU during registrationp. 206

A UE shall indicate its support for the GRUU mechanism in the registration request and retain the GRUU set (P-GRUU and T-GRUU) in the registration response. The UE may retain some or all of the previous T-GRUUs obtained during the initial registration or previous re-registrations along with the new T-GRUU or the UE may replace some or all of the previous T-GRUUs with the new T-GRUU. The UE shall generate an instance identifier that is a unique identifier for that UE. The UE shall include an instance identifier in all registration requests. Instance identifiers shall conform to the mandatory requirements for instance identifiers specified in RFC 5627 and RFC 5626.
If the registered Public User Identity is part of an implicit registration set, the UE shall obtain and retain the GRUU sets for each implicitly registered SIP URI sent by the S-CSCF in accordance to RFC 5628.
Up

5.20.1.2  Using a GRUUp. 207

When sending SIP requests from an explicitly or implicitly registered Public User Identity for which a UE obtained P-GRUU and at least one T-GRUU, the UE should use the corresponding retained P-GRUU or a T-GRUU as a Contact address.
When responding to SIP requests where the identification of the called party is a registered Public User Identity for which a UE obtained a GRUU, the UE shall use the corresponding retained P-GRUU or T-GRUU as the Contact address when addressing that UE.
If the UE has obtained GRUUs for its Public User Identity being used in a request or response and the user does not require privacy the UE should use the P-GRUU as the Contact address.
A UE may learn a GRUU of another UE using mechanisms that are outside the scope of this specification, (e.g. a UE may learn a GRUU from the contact header of a request, from presence information, or by other mechanisms).
If a UE that receives a notification from the S-CSCF indicating that an implicit registration has occurred for a contact the UE has registered, then the UE shall retain the GRUUs included in the notification for future use.
Up

5.20.1.3  Using a GRUU while requesting Privacyp. 207

When a UE sends a request or response containing a GRUU, and it wishes to block the delivery of its Public User Identity to an untrusted destination, the UE shall use a T-GRUU as the Contact address.

5.20.2  Serving-CSCFp. 207

5.20.2.1  Allocating a GRUU during registrationp. 207

The S-CSCF, when receiving a registration request from a UE that includes an instance id, shall allocate a GRUU set. If the UE indicates support of GRUU in the REGISTER request, then the S-CSCF shall return the GRUU set in the registration response and associate that GRUU set with the registered contact information for that UE.
If there are implicitly registered Public User Identities, the S-CSCF shall generate a GRUU set for each implicitly registered Public User Identity and include the corresponding GRUU set with the notification of each implicitly registered Public User Identity
Up

5.20.2.2  Using a GRUUp. 207

The filter criteria in the service profile may check for the presence of a GRUU in the Request-URI or related parameters of a request.
For originations, the S-CSCF shall validate the GRUU conveyed in the contact header of the SIP request and pass the SIP request with the validated GRUU to Application Servers based on the filter criteria.
For terminations, the S-CSCF may validate the GRUU conveyed in the Request-URI header of the SIP request and pass the SIP request with the validated GRUU to Application Servers based on filter criteria.
Application servers may then apply services to the GRUU.
If the SIP message is destined to a GRUU, then the S-CSCF shall associate the request with the corresponding Public User Identity. The S-CSCF will not fork this request, but will direct the call to the identified instance.
S-CSCF shall provide an indication to UE that the SIP request was targeted to a GRUU.
Up

5.20.3  Interrogating-CSCFp. 208

When routing requests addressed to a GRUU to the terminating S-CSCF, the I-CSCF uses the contents of the Request-URI when querying the HSS. Requests routed to the terminating S-CSCF are addressed to the GRUU.

5.20.3a  HSSp. 208

The HSS shall remove the P-GRUU as part of the canonicalization process of SIP URIs, to obtain the Public User Identity for identity look-up as it is defined in TS 29.228.

5.20.4  Elements other than UE acting as a UAp. 208

5.20.4.1  Using a GRUUp. 208

It shall be possible for other IMS elements other than UEs, that act as UAs (e.g. MGCF, Application Server) to use a GRUU referring to itself when inserting a contact address in a SIP message. The MGCF and MRF are not required to store GRUUs beyond a session. If the incoming contact address that is being replaced by the B2BUA functionality contains a GRUU, then the replacement URI in the outgoing SIP message should also contain a GRUU.
If an element so uses a GRUU, it shall handle requests received outside of the session in which the contact was provided.
Routing procedures amongst IMS elements other than UEs that act as UAs are unchanged when GRUUs are in use.
Up

5.20.4.2  Assigning a GRUUp. 208

The GRUUs shall either be provisioned by the operator or obtained by any other mechanism. The GRUU shall remain valid for the time period in which features addressed to this URI remains meaningful.

5.21  IMS Multimedia Priority Services Procedures |R10|p. 208

The IMS Multimedia Priority Service provides Service Users access to IMS services in a prioritised manner.
The P-CSCF shall control the priority of IMS based MPS sessions, using PCC procedures. The P-CSCF shall permit any authorised Service User to originate an IMS based MPS session. The detection of MPS sessions is handled by the P-CSCF at the originating network.
The P-CSCF may send an MPS for Messaging indication to the PCRF/PCF using PCC procedures to request the PCRF/PCF to modify the IMS signalling bearer/QoS Flow for MPS for Messaging, as described in TS 23.203 and TS 23.503.
PCC shall always be enabled in a network supporting IMS Multimedia Priority Services.
The HSS shall store the IMS Priority Indication, the Priority Level and the MPS for Messaging indication as part of the subscription information/user profile.
The P-CSCF at the originating end shall determine whether the INVITE message requires priority handling based on the user profile as stored during the registration procedures or as subsequently updated and/or the MPS code/identifier provided by the INVITE message. For MPS Session-based Messaging, the P-CSCF shall determine whether the INVITE message requires priority handling based on the MPS for Messaging indication. If the session is determined to require priority handling, then the P-CSCF inserts/replaces the MPS priority indication in the INVITE and, if the Service User's priority level is known, may include it and forwards the INVITE to the S-CSCF.
The P-CSCF uses the MPS priority indication and Service User's priority level, if available, to derive Resource-Priority information as further described in clause 4.11 of TS 24.229.
If the Service User's priority level is not known, the P-CSCF includes the priority indication without the Service User's priority level. The S-CSCF routes (using initial Filter Criteria set for the MPS code/identifier) the INVITE to the AS for authentication/authorization for MPS (if needed), and the AS adds the Service User's priority level if it is not in the INVITE already. The AS or the S-CSCF may assert the authorization for priority in the INVITE. The AS then forwards the INVITE (with MPS priority indication and the Service User's priority level) to the next entity in the network via the S-CSCF as part of the normal IMS routing. All subsequent SIP messages carry both MPS priority indication and the Service User's priority level.
When the P-CSCF at the originating end determines that priority handling is required, the P-CSCF shall derive session information and interact with the PCRF/PCF providing the session information. The derived session information shall indicate the priority of the MPS session, which depends on whether the Service User's priority level is known at this stage. The PCC interaction between the P-CSCF and the PCRF/PCF is described in TS 23.203 and TS 23.503.
The P-CSCF at the terminating end shall determine whether the INVITE message requires priority handling based on MPS priority indication and the originating Service User's priority level received from the originating network. If priority handling is required, P-CSCF shall derive the session information based on the Service User's priority level to indicate the priority of the MPS session and interact with the PCRF/PCF providing the session information.
For IMS Immediate Messaging, the P-CSCF at the originating end shall add Resource-Priority information to the MESSAGE request and shall handle this request with priority if the MPS for Messaging indication is set (enabled) in the originating UE subscription information.
The P-CSCF at the terminating end shall handle the MESSAGE request with priority whether or not it contains Resource-Priority information, if the MPS for Messaging indication is set (enabled) in the terminating UE subscription information.
The P-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized MPS priority indication.
When the terminating user is a Service User, while the session request is from a normal user, the IMS signalling bearer/QoS Flow may be given priority treatment when operator policy and MPS (IMS) priority subscription indicates so. For a Service User originating a non-priority session, the IMS signalling bearer/QoS Flow may be given priority treatment when operator policy and MPS (IMS) priority subscription indicates so. For IMS media, priority treatment is not required in these cases.
If so configured by the operator, a P-CSCF or an IBCF shall prohibit the negotiation of ECN during SDP offer/answer exchanges and shall not invoke ECN (as described in clause 4.22) for IMS based MPS sessions.
A conferencing AS, if enabled by local policy, shall permit an authorized host with an MPS (IMS) priority subscription (i.e. the Service User that established the conference) to request an upgrade of the host itself, specific participants, or all participants including the host in the conference, whether participants have an MPS subscription or not. Once the conference has been upgraded, the AS will upgrade new participants to MPS without explicit host invocation. For MPS conferencing sessions, upon request from a host to upgrade an existing conference, the AS shall first authenticate/authorize the host for MPS.
The session upgrade of UE conference participants is based on existing IMS routing procedures, including interaction between the P-CSCF and PCRF/PCF for that purpose.
For E-UTRAN access, priority support for an EPS bearer is described in TS 23.401.
For 5GS, support of Multimedia Priority Service is described in TS 23.501.
IMS Immediate Messaging and IMS Session-based Messaging delivered with MPS priority are further described in clause 5.16.
Up

5.22  Support of Overload Control |R11|p. 210

5.22.1  Next-hop monitoring of overloadp. 210

The following Figure depicts an example information flow for the overload control mechanism based on feedback.
Reproduction of 3GPP TS 23.228, Fig. 5.22.1-1: Information flow for Overload Control with next-hop monitoring
Up
Step 1.
During a past INVITE, the SIP IMS entity 1 obtained a percentage by which the load forwarded to SIP IMS entity 2 should be reduced.
Step 2.
During a past INVITE, the SIP IMS entity 1 obtained a percentage by which the load forwarded to SIP IMS entity 3 should be reduced.
Step 3.
Incoming INVITE from Originating side (network or UE). The SIP IMS entity 1 determines that the INVITE has to be forwarded via SIP IMS entity 2.
Step 4.
With the information obtained in step 1, the SIP IMS entity 1 either:
Step 5a.
refuses the INVITE request because of overload situation, or
Step 5b.
forwards the INVITE to SIP IMS entity 2 (5b1). The Reply to the INVITE (5b2) can contain updated overload control information.
Up

5.22.2  Filter based Overload Controlp. 210

The following Figure depicts an example information flow for the filter based overload control mechanism.
Reproduction of 3GPP TS 23.228, Fig. 5.22.2-1: Information flow for AS Overload Control using a filter based mechanism
Up
Step 1.
Upon initialization or restart, AS/S-CSCF subscribes to overload event notification of AS-1 and receives overload control filters (1c).
Step 2.
Upon initialization or restart AS/S-CSCF subscribes to overload event notification of AS-2 and receives overload control filters (2c)
Step 3.
An INVITE comes to AS/S-CSCF.
Step 4-5.
The AS/S-CSCF determines where to forward the message (AS-1 in this example), then evaluates whether the contents of the INVITE matches the filters received from AS-1:
  • If the request does not match any filter, the AS/S-CSCF forwards it to AS-1 (5b1);
  • Otherwise, depending on the throttling algorithm, the AS/S-CSCF either:
  • refuses the INVITE request because of the overload situation (5a), or
  • forwards the INVITE to AS-1 (5b1).
Up

Up   Top   ToC