Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  16.6.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.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.8…   5.11…   5.11.3…   5.11.4…   5.11.5…   5.11.6…   5.12…   5.16…   5.19   5.20…   A…   E…   E.2.2…   G…   G.5…   H…   J…   L…   N…   Q…   Q.2.5…   R…   S…   U…   U.2…   V…   Y…   Z…   AA…   AA.3…

 

5.20  Procedures for Assigning, Using, and Processing GRUUs |R7|

5.20.1  UE

5.20.1.1  Obtaining a GRUU during registration

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 GRUUWord‑p. 205
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 Privacy

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-CSCF

5.20.2.1  Allocating a GRUU during registration

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 GRUU

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-CSCFWord‑p. 206
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  HSS

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 UA

5.20.4.1  Using a GRUU

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 GRUU

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|

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 UE to originate an IMS based MPS session. The detection of MPS sessions is handled by the P-CSCF at the originating network.
PCC shall always be enabled in a network supporting IMS Multimedia Priority Services.
HSS shall store IMS Priority Indication and Priority Level as part of the subscription information.
The P-CSCF at the originating end shall determine whether the INVITE message requires priority handling based on user profile stored during the registration procedure and/or MPS code/identifier provided by the INVITE message. If the session is determined to require priority handling, then 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 forward the INVITE to the S-CSCF. 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 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 if 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,
When the terminating user is a Service User, while the session request is from a normal user, the IMS signalling bearer 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 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.
For E-UTRAN access, priority support for EPS bearer is described in TS 23.401.
For 5GS, support Multimedia Priority Service is described in TS 23.501.
Up

5.22  Support of Overload Control |R11|Word‑p. 207

5.22.1  Next-hop monitoring of overload

The following figure depicts an example information flow for the overload control mechanism based on feedback.
(not reproduced yet)
Figure 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 ControlWord‑p. 208
The following figure depicts an example information flow for the filter based overload control mechanism.
(not reproduced yet)
Figure 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: \begul
  • 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