Content for TR 23.726 Word version: 16.0.0

3.1 Definitions 3.2 Abbreviations 4.1 Architectural requirements 4.2 Architectural assumptions and Principles
...

1 Scope p. 8

The objective of this Technical Report is to study enhancements of 5GS architecture that has been defined in Rel-15 about the topology of SMF and UPF, and:

investigate mechanisms to enable the 3GPP system to support deployments where a SMF is not able / allowed to control UPF(s) throughout the same PLMN.
Study whether it is needed to enhance the capability of 5GS architecture for a UPF to be controlled by multiple SMF's (and many UPF's to be controlled by many SMFs) and, if yes, define such enhancements.
For these objectives, use cases will be defined.

2 References p. 8

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 23.501: "System Architecture for the 5G System; Stage 2".

[3]

TS 23.502: "Procedures for the 5G system, Stage 2".

[4]

TS 23.503: "Policy and Charging Control Framework for the 5G System; Stage 2".

[5]

TS 29.244: "Interface between the Control Plane and the User Plane nodes".

[6]

TS 29.510: "5G System; Network function repository services; Stage 3".

[7]

RFC 4861: "Neighbor Discovery for IP version 6 (IPv6)".

[8]

TR 23.716: "Study on the Wireless and Wireline Convergence for the 5G system architecture".

3 Definitions, symbols and abbreviations p. 8

3.1 Definitions p. 8

For the purposes of the present document, the terms and definitions given in TR 21.905, TS 23.501 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

AMF Service Area:

An area within which a UE can be served by the same AMF. It contains one or more TA(s).

Anchor SMF (A-SMF):

the SMF serving the PDU Session when a single SMF is used as defined for non-roaming and LBO scenarios in Rel-15. A PDU Session always involves an A-SMF. An A-SMF is never changed for a PDU Session.

Intermediate SMF (I-SMF):

the SMF that controls UPF(s) that the A-SMF cannot control. An I-SMF is inserted, changed or removed as needed. An I-SMF is used only in specific deployments.

SMF Service Area:

The collection of the UPF Service Areas (as defined in TS 23.501) of all UPFs which can be controlled by one SMF. It contains one or more TA(s).

3.2 Abbreviations p. 9

For the purposes of the present document, the abbreviations given in TR 21.905, TS 23.501 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

A-SMF

Anchor SMF

Key Issue

L-SMF

Local SMF

L-UPF

Local UPF

I-SMF

Intermediate SMF

I-UPF

Intermediate UPF

4 Architecture Requirements, Assumptions and principles p. 9

4.1 Architectural requirements p. 9

Void.

4.2 Architectural assumptions and Principles p. 9

The SMF Service areas and the AMF Service Areas are not required to be identical, i.e. contain the same TA list. However, it shall be possible that the SMF service area partially overlaps with the AMF Service Area.
Allocation and release of CN Tunnel Info is performed when a new PDU Session is established or released. This functionality is supported either by SMF or UPF, if it supports this functionality. It shall be possible that each NF can support the CN Tunnel Info allocation and release function same as Rel-15.
If an A-UPF which is managed by the A-SMF and if it has a N3 interface used by the PDU session, then there is no need to have an I-SMF for the PDU Session. 3GPP specifications assume that the SMF instance can act as I-SMF or A-SMF depending on its role for a PDU Session.