full Contents for TS 23.501 Word version: 16.4.0
A Relationship between Service-Based Interfaces and Reference Points Word-p. 389
Service-Based Interfaces and Reference Points are two different ways to model interactions between architectural entities. A Reference Point is a conceptual point at the conjunction of two non-overlapping functional groups (see TR 21.905
). In Figure A-1
the functional groups are equivalent to Network Functions.
A reference point can be replaced by one or more service-based interfaces which provide equivalent functionality.
Reference points exist between two specific Network Functions. Even if the functionality is equal on two reference points between different Network Functions there has to be a different reference point name. Using the service-based interface representation it is immediately visible that it is the same service-based interface and that the functionality is equal on each interface.
A NF may expose one or more services through Service based interfaces.
B (Normative) Mapping between temporary identities Word-p. 391
When interworking procedures with N26 are used and the UE performs idle mode mobility from 5GC to EPC the following mapping from 5G GUTI to EPS GUTI applies:
5G <MCC> maps to EPS <MCC>
5G <MNC> maps to EPS <MNC>
5G <AMF Region ID> and 5G <AMF Set ID> maps to EPS <MMEGI> and part of EPS <MMEC>
5G <AMF Pointer> map to part of EPS <MMEC>
5G <5G-TMSI> maps to EPS <M-TMSI>
The mapping described above does not necessarily imply the same size for the 5G GUTI and EPS GUTI fields that are mapped. The size of 5G GUTI fields and other mapping details will be defined in TS 23.003
To support interworking with the legacy EPC core network entity (i.e. when MME is not updated to support interworking with 5GS), it is assumed that the 5G <AMF Region ID> and EPS <MMEGI> is partitioned to avoid overlapping values in order to enable discovery of source node (i.e. MME or AMF) without ambiguity. Once the EPS in the PLMN has been updated to support interworking with 5GS, the full address space of the AMF Region ID can be used for 5GS.
C Guidelines and Principles for Compute-Storage Separation Word-p. 392
5G System Architecture allows any NF/NF Service to store and retrieve its unstructured data (e.g. UE contexts) into/from a Storage entity (e.g. UDSF) as stated in clause 4.2.5
in this release of the specification. This clause highlights some assumptions, principles regarding NF/NF services that use this Storage entity for storing unstructured data:
It is up to the Network Function implementation to determine whether the Storage entity is used as a Primary Storage (in which case the corresponding context stored within the NF/NF Service is deleted after storage in the Storage entity) or the Storage entity is used as a Secondary Storage (in which case the corresponding context within the NF/NF Service is stored).
It is up to the NF/NF Service implementation to determine the trigger (e.g. at the end of Registration procedure, Service Request procedure etc) for storing unstructured data (e.g. UE contexts) in the Storage entity but it is a good practice for NF/NF service to store stable state in the Storage entity.
Multiple NF/NF service instances may require to access the same stored data in the Storage entity (e.g. UE context), around the same time, then the resolution the race condition is implementation specific.
In the case of AMF, all AMFs within the same AMF Set are assumed to have access to the same unstructured data stored within the Storage entity.
AMF planned removal with UDSF (clause 126.96.36.199.1) and AMF auto-recovery (with UDSF option in clause 188.8.131.52) assume that a storage entity/UDSF is used either as a primary storage or secondary storage by the AMF for storing UE contexts.