Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 29.502  Word version:  18.6.0

Top   Top   Up   Prev   Next

 

5.2.3  General proceduresp. 94

5.2.3.1  Transfer of NAS SM information between UE and H-SMF for Home Routed PDU sessionsp. 94

5.2.3.1.1  Generalp. 94
As specified in clause 4.3.1 of TS 23.502, for Home Routed PDU sessions, there is NAS SM information that the V-SMF and H-SMF need to interpret, and NAS SM information that the V-SMF only needs to transfer between the UE and H-SMF but which it does not need to interpret.
NAS SM information that only needs to be transferred between the UE and H-SMF by the V-SMF can be extended in later versions or releases of the NAS specification, e.g. defining new fields or values within existing IEs, and the extensions should not impact the V-SMF.
Besides, in HR roaming scenarios, the V-SMF and H-SMF can comply to different versions or releases of the NAS specification. It should be possible to support new SM features only requiring support from the H-SMF without impacting the V-SMF, when the H-SMF complies with a more recent release than the V-SMF, e.g. defining new NAS SM IEs in signalling from the UE to the H-SMF and/or signalling from the H-SMF to the UE.
Up
5.2.3.1.2  V-SMF Behaviourp. 94
The V-SMF shall transfer NAS SM information that it only needs to transfer to the H-SMF (i.e. known IEs, and IEs that have an unknown value not set to "reserved" according to the release to which the V-SMF complies, that only need to be forwarded by the V-SMF) in n1SmInfoFromUe binary data within the HTTP content. This carries N1 SM IE(s), encoded as specified in TS 24.501, including the Type field and, for TLV or TLV-E IEs, the Length field.
The V-SMF shall transfer NAS SM information that it does not comprehend (i.e. unknown IEs, or known IEs to be interpreted by the V-SMF that have an unknown value not set to "reserved" according to the release to which the V-SMF complies) in unknownN1SmInfo binary data within the HTTP content. This carries N1 SM IE(s), encoded as specified in TS 24.501, including the Type field and, for TLV or TLV-E IEs, the Length field.
When receiving n1SmInfoToUe binary data in the HTTP contentfrom the H-SMF, the V-SMF shall parse all the N1 SM IEs received in the binary data and construct the NAS SM message to the UE according to TS 24.501. The V-SMF shall append unknown NAS SM IEs received in the binary data at the end of the NAS SM message it sends to the UE.
The V-SMF shall comprehend and be able to encode at their right place in a given NAS message, all the IEs of the version of the NAS specification it implements that do not need to be interpreted by the V-SMF and which precede the last interpreted IE that the V-SMF implements in a NAS message.
Up
5.2.3.1.3  H-SMF Behaviourp. 95
When receiving unknownN1SmInfo binary data in the HTTP content from the V-SMF, the H-SMF shall process any N1 SM IE received in this binary data that do not require to be interpreted by the V-SMF. Other N1 SM IEs shall be dropped, e.g. IEs that the H-SMF comprehends but which require to be interpreted by the V-SMF.
The H-SMF shall transfer NAS SM information which the V-SMF does not need to interpret (i.e. that it only needs to transfer to the UE) in n1SmInfoToUe binary data within the HTTP content. This carries N1 SM IE(s), encoded as specified in TS 24.501, including the Type field and, for TLV or TLV-E IEs, the Length field.
The NAS SM IEs in n1SmInfoToUe binary data shall be encoded in the same order as specified in TS 24.501.
N1 SM information which does not require to be interpreted by the V-SMF is information that is not defined as specific IEs over N16.
Up

5.2.3.2  Transfer of NAS SM information between UE and SMF for PDU sessions with an I-SMF |R16|p. 95

5.2.3.2.1  Generalp. 95
The requirements specified in clause 5.2.3.1 shall also apply for the transfer of NAS SM information between the UE and the SMF for PDU sessions with an I-SMF, whereby the I-SMF and SMF shall take the role of the V-SMF and H-SMF respectively.

5.2.3.3  Detection and handling of late arriving requests |R16|p. 95

5.2.3.3.1  Handling of requests which collide with an existing SM context or PDU session contextp. 95
5.2.3.3.1.1  Generalp. 95
This procedure enables an SMF, which receives a request colliding with an existing SM context or PDU session context, to know the time at which the new request and the existing PDU session were originated, and to accept the new request only if it is more recent than the existing PDU session.
The originating entities within the PLMN (i.e. AMFs) shall be NTP synchronized.
5.2.3.3.1.2  Principlesp. 95
The following principles shall apply if this procedure is supported and enabled by operator policy.
An AMF originating a Create SM Context request shall include in the message the Origination Time Stamp indicating the absolute time at which the request is initiated.
The V-SMF or I-SMF shall forward this header to the H-SMF or SMF, if it is received from the AMF.
Upon receipt of a Create SM Context request or a Create request which collides with an existing SM context or PDU session context, the SMF shall accept the new PDU session establishment request only if it contains a more recent time stamp than the time stamp stored for the existing PDU session. An incoming PDU session establishment request shall be considered as more recent than an existing PDU session and be accepted if no Origination Time Stamp information was provided for at least one of the two PDU sessions. The SMF shall reject an incoming request whose time stamp is less recent than the time stamp of the existing PDU session with the HTTP status code "403 Forbidden" and the application error "LATE_OVERLAPPING_REQUEST".
3GPP TS 29.512 further specify:
  • the SMF requirements regarding the forwarding of the Origination Time Stamp towards the PCF, when received from the AMF;
  • the handling of the Origination Time Stamp parameter by the PCF for an incoming request colliding with an existing Individual SM Policy Association.
Up
5.2.3.3.2  Detection and handling of requests which have timed out at the HTTP clientp. 96
5.2.3.3.2.1  Generalp. 96
The procedure specified in clause 6.11.2 of TS 29.500 shall apply with the following additions.
An HTTP request may include the 3gpp-Sbi-Origination-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, with or without the 3gpp-Sbi-Sender-Timestamp header.
The 3gpp-Sbi-Max-Rsp-Time header shall indicate the duration expressed in milliseconds since the absolute time indicated in the 3gpp-Sbi-Sender-Timestamp header, if this header is present, or indicated in the 3gpp-Sbi-Origination-Timestamp header otherwise.
Up

5.2.3.4  UE Location Information |R16|p. 96

When attributes with the UserLocation data type (as defined in clause 5.4.4.7 of TS 29.571) are included in the messages (as specified in clause 6) to report the UE location information to the SMF, the following information shall be included in these attributes:
  • the TAI and NCGI for NR user location; or
  • the TAI and ECGI for E-UTRA user location; or
  • the TAI, UE local IP address, Port if NAT is detected, and optionally n3Iwid if available, for untrusted non-3GPP access; or
  • the TAI and TNAP Id/TWAP Id for trusted non-3GPP access; or
  • the TAI and GLI and optionally LineType if available, or the TAI and hfcNodeId, or the TAI and GCI, for wireline network access.
Up

Up   Top   ToC