School of Specs 23.501v20.2.0

3GPP 23.501 v20.2.0 — the document's own text

5.17.5.1 General

Taught in 19. Living next to 4G (The 5G system architecture, in depth), 7. Roaming, other accesses, the edge and the outside (The 5G system architecture, overview).

Clause 4.3.5 shows the Service Exposure Network Architecture in scenarios where for EPC-5GC Interworking is required.

In scenarios where interworking between 5GS and EPC is possible, the network configuration is expected to associate UEs with SCEF+NEF node(s) for Service Capability Exposure. The SCEF+NEF hides the underlying 3GPP network topology from the AF (e.g. SCS/AS) and hides whether the UE is served by 5GC or EPC.

If the service exposure function that is associated with a given service for a UE is configured in the UE's subscription information, then an SCEF+NEF identity shall be used to identify the exposure function. For example, if a UE is capable of switching between EPC and 5GC, then the SCEF ID that is associated with any of the UE's APN configurations should point to an SCEF+NEF node.

For external exposure of services related to specific UE(s), the SCEF+NEF resides in the HPLMN. Depending on operator agreements, the SCEF+NEF in the HPLMN may have interface(s) with NF(s) in the VPLMN.

The SCEF+NEF exposes over N33 the same API as the SCEF supports over T8. If CAPIF is not supported, the AF is locally configured with the API termination points for each service. If CAPIF is supported, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS 23.222 [64].

The common state information shall be maintained by the combined SCEF+NEF node in order to meet the external interface requirements of the combined node. The common state information includes at least the following data that needs to be common for the SCEF and NEF roles of SCEF+NEF:

  • SCEF+NEF ID (must be the same towards the AF).
  • SCEF+NEF common IP address and port number.
  • Monitoring state for any ongoing monitoring request.
  • Configured set of APIs supported by SCEF+ NEF.
  • PDN Connection/PDU Session State and NIDD Configuration Information, including Reliable Data Service state information.
  • Network Parameter Configuration Information (e.g. Maximum Response Time and Maximum Latency).

The SCEF+NEF need not perform the same procedures for the configuration of monitoring events towards the HSS+UDM twice. For example, if the HSS+UDM is deployed as a combined node, a monitoring event only need to be configured by the SCEF+NEF just once.

The SCEF+NEF may configure monitoring events applicable to both EPC and 5GC using only 5GC procedures towards UDM. In this case, the SCEF+NEF shall indicate that the monitoring event is also applicable to EPC (i.e. the event must be reported both by 5GC and EPC) and may include a SCEF address (i.e. if the event needs to be configured in a serving node in the EPC and the corresponding notification needs to be sent directly to the SCEF). If the HSS and UDM are deployed as separate network entities, UDM shall use HSS services to configure the monitoring event in EPC as defined in TS 23.632 [102]. The UDM shall return an indication to SCEF+NEF of whether the configuration of the monitoring event in EPC was successful. In the case that the UDM reports that the configuration of a monitoring event was not possible in EPC, then the SCEF+NEF may configure the monitoring event using EPC procedures via the HSS as defined in TS 23.682 [36].

NOTE 1: The SCEF+NEF uses only 5GC procedures to configure monitoring events in EPC and 5GC.

NOTE 2: In terms of the CAPIF, the SCEF+NEF is considered a single node.