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