Section: 6.2.19 SCP
Content: The Service Communication Proxy (SCP) includes one or more of the following functionalities. Some or all of the SCP functionalities may be supported in a single instance of an SCP: - Indirect Communication (see clause 7.1.1 for details). - Delegated Discovery (see clauses 7.1.1 and 6.3.1 for details). - Message forwarding and routing to destination NF/NF service. - Message forwarding and routing to a next hop SCP. - Communication security (e.g. authorization of the NF Service Consumer to access the NF Service Producer API), load balancing, monitoring, overload control, etc. - Optionally interact with UDR, to resolve the UDM Group ID/UDR Group ID/AUSF Group ID/PCF Group ID/CHF Group ID/HSS Group ID based on UE identity, e.g. SUPI or IMPI/IMPU (see clause 6.3.1 for details). NOTE 1: Communication security, e.g. authorization of the NF Service Consumer to access the NF Service Producer's API is specified in TS 33.501[ Security architecture and procedures for 5G System ]  [29]. NOTE 2: Load balancing, monitoring, overload control functionality provided by the SCP is left up to implementation. The SCP may be deployed in a distributed manner. NOTE 3: More than one SCP can be present in the communication path between NF Services. SCPs can be deployed at PLMN level, shared-slice level and slice-specific level. It is left to operator deployment to ensure that SCPs can communicate with relevant NRFs. In order to enable SCPs to route messages through several SCPs (i.e. next SCP hop discovery, see clause 6.3.16), an SCP may register its profile in the NRF. Alternatively, local configuration may be used.