Tech-invite  3GPPspace  IETFspace
◀  ▶  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x
Top   in Index   Prev   Next

TS 28.540
Management and Orchestration –
5G Network Resource Model (NRM) – Stage 1

3GPP‑Page   ETSI‑search   CONTENT↓
V20.1.0 (Wzip)  2025/12  … p.
V19.3.0 (PDF)  2025/12  … p.
V18.2.1  2025/06  13 p.
V17.3.1  2025/06  13 p.
V16.2.1  2025/06  12 p.
V15.1.0  2018/12  11 p.
Rapporteur:
Miss Ping, Jing
Nokia Germany

Content for  TS 28.540  Word version:  20.0.0

Here   Top
0 Introduction  1 Scope  2 References  3 Definitions and abbreviations  4  Concepts and background  5  Requirements  $ Change history 

 

0  Introduction  p. 5

The present document is part of a TS-family covering the 3rd Generation Partnership Project Technical Specification Group Services and System Aspects Management and orchestration of networks, as identified below:
TS 28.540:
Management and orchestration of 5G networks; Network Resource Model (NRM); Stage 1.
TS 28.541:
Management and orchestration of 5G networks; Network Resource Model (NRM); Stage 2 and stage 3.

1  Scope  p. 6

The present document specifies the requirements for the Network Resource Model (NRM) definition of NR, NG-RAN, 5G Core Network (5GC) and network slice, to support the management for:
  • variety of 5G radio access network functions and features, covering management for NR connectivity options defined in TS 37.340 and NG-RAN architectural options defined in TS 38.401.
  • variety of 5GC network functions and features defined in TS 23.501.
  • network slice and network slice subnet.
Up

2  References  p. 6

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".
[3]
TS 38.300: "NR; Overall description; Stage-2".
[4]
TS 38.401: "NG-RAN; Architecture description".
[5]
TS 37.340: "NR; Multi-connectivity; Overall description; Stage 2".
[6]
TS 28.531: "Management and orchestration of 5G networks; Provisioning".
[7]
TS 23.502: "Procedures for the 5G System; Stage 2".
[8]
GSMA NG.116: "Generic Network Slice Template" v1.0 (2019-05-23).
[9]
TS 28.533: "Management and orchestration; Architecture framework".
[10]
TS 38.331: "NR; Radio Resource Control (RRC); Protocol specification".
[11]
TS 23.369: "Ambient power-enabled Internet of Things; Stage 2".
[12]
TS 23.304: "Proximity based Services (ProSe) in the 5G System (5GS)".
[13]
TS 28.314: "Management and orchestration; Plug and Connect; Concepts and requirements".
Up

3  Definitions and abbreviations  p. 7

3.1  Definitions  p. 7

For the purposes of the present document, the terms and definitions given in TR 21.905 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.
5G Core Network:
Defined in TS 23.501.
AMF Region:
Defined in TS 23.501.
AMF Set:
Defined in TS 23.501.
en-gNB:
Defined in TS 37.340.
gNB:
Defined in TS 38.300.
gNB Central Unit (gNB-CU):
Defined in TS 38.401.
gNB-CU-Control Plane (gNB-CU-CP):
Defined in TS 38.401.
gNB-CU-User Plane (gNB-CU-UP):
Defined in TS 38.401.
gNB Distributed Unit (gNB-DU):
Defined in TS 38.401.
ng-eNB:
Defined in TS 38.300.
NG-RAN:
Defined in TS 23.501.
RedCap UE:
defined in TS 38.331.
eRedCap UE:
defined in TS 38.331.
AIoT:
defined in TS 23.369.
AIOTF:
defined in TS 23.369.
ADM:
defined in TS 23.369.
IAB-node:
as defined in TS 38.401.
Up

3.2  Abbreviations  p. 7

For the purposes of the present document, the abbreviations given in TR 21.905 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.
5GC
5G Core network
5GS
5G System
ADM
AIoT Data Management
AIOTF
Ambient IoT Function
AMF
Access and Mobility Management Function
EN-DC
E-UTRA-NR Dual Connectivity
EPS
Evolved Packet System
IAB
Integrated Access and Backhaul
MR-DC
Multi-Radio Dual Connectivity
NG-RAN
NG Radio Access Network
NR
New Radio
PCF
Policy Control Function
UDM
Unified Data Management
UDR
Unified Data Repository
UDSF
Unstructured Data Storage Function
Up

4  Concepts and background  p. 8

4.1  NR and NG-RAN deployment scenarios  p. 8

According to NG-RAN architecture defined in TS 38.300, An NG-RAN node is either a gNB or an ng-eNB connected to 5GC.
A gNB may consist of a gNB-CU and one or more gNB-DU(s), and a gNB-CU may consist of a gNB-CU-CP and one or more gNB-CU-UP. From functional split point of view, there have following gNB deployment scenarios which are specified in TS 38.401:
  1. gNB which does not consist split function.
  2. gNB which consists of gNB-CU and gNB-DU(s).
  3. gNB which consists of gNB-CU-CP, gNB-CU-UP(s) and gNB-DU(s).
Abovementioned deployment scenarios apply to en-gNB also.
Part of gNB (e.g. gNB-CU) can be deployed as virtualized network function.
Up

4.2  MR-DC  p. 8

Besides single connectivity operation, E-UTRAN, NR and NG-RAN support Multi-RAT Dual Connectivity (MR-DC) operation defined in TS 37.340, which can be further divided into following two categories based on connected core network types.
  1. MR-DC with the EPC via EN-DC, the NR node in EN-DC is called en-gNB.
  2. MR-DC with the 5GC via either NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC) or NR-E-UTRA Dual Connectivity (NE-DC) or NR-NR Dual Connectivity (NR-DC).
There are different user plane connectivity options of the master node and secondary node involved in MR-DC (see detail in TS 37.340).
Up

4.3  5GC architecture  p. 8

The 5G architecture is defined as service-based and the interaction between network functions is represented in the following two ways:
  • Service-based representation
  • Reference point representation
The network functions composed 5GC is specified in TS 23.501, network functions within the 5GC control plane shall only use service-based interfaces for their interactions.

4.4  Data storage architecture  p. 8

5G system architecture allows UDM, PCF and NEF to store their data in the Unified Data Repository (UDR), and allows any NF to store and retrieve its unstructured data (e.g. UE context) into/from a UDSF.

4.5  AMF load balancing insides AMF Region/AMF Set  p. 9

When deploying AMF Region or AMF Set, AMF load balancing insides AMF Region/AMF Set is achieved by setting a weight factor for each AMF according to its relative capacity compared to other AMFs, see detail in clause 5.19.3 of TS 23.501.

4.6  5GC NFs supporting edge computing  p. 9

Edge computing enables operator and 3rd party services to be hosted close to the UE's access point of attachment, so as to achieve an efficient service delivery through the reduced end-to-end latency and load on the transport network, see details in clause 5.13 of TS 23.501.

4.7  General information for network slice instance and network slice subnet instance  p. 9

The general information used to describe network slice instance and network slice subnet instance are specified in TS 28.531.

4.8  Remote Interference Management  p. 9

A remote interference scenario may involve a number of victim and aggressor cells, where the gNBs execute Remote Interference Management (RIM) coordination on behalf of their respective cells. Aggressor and victim gNBs or cells can be grouped into semi-static sets, where each cell is assigned a set ID, and is configured with a RIM Reference Signal (RIM-RS) and the radio resources associated with the set ID. As defined in TS 38.300.

4.9  Void

4.10  Management of NTN  p. 9

4.10.1  Management of transparent mode feature  p. 9

Satellite Transparent Mode is a communication mode where a satellite functions as a simple relay or "bent-pipe" that merely forwards signals between the user equipment (UE) and the terrestrial network, without any signal processing or modification by the satellite. The 3GPP management system should provide the satellite ephemeris parameters to the gNB providing non-terrestrial access as outlined in TS 38.300 to support management of NTN function. Satellite assistance information (e.g. ephemeris information) can be used for the handling of coverage holes or discontinuous satellite coverage in a power efficient way.
For a UE using a Non-Terrestrial Network that provides discontinuous coverage, 3GPP management system needs to support UE location verification, NTN access restriction and NTN mobility management.
Up

4.10.2  Management of Backhaul feature  p. 9

The AMF report the satellite backhaul category and indicates the satellite backhaul category change to SMF as outlined in TS 23.501. And the AMF can determine the Satellite backhaul category based on the information within Global RAN Node IDs associated with satellite backhaul. The 3GPP management system should provide a capability to allow the MnS consumer to configure satellite backhaul information for NTN node.

4.10.3  Management of regenerative mode feature  p. 9

Figure 4.10.3-1 illustrates an NTN system with regenerative mode, where the gNB is located onboard the satellite. In this case, the ground segment Core Network (CN) will serve the same beams all the time, while the space segment gNB on different satellites (satellite 1, 2 and 3) will serve the beam in different time periods as the satellites are approaching and leaving the coverage of the beam over time.
Copy of original 3GPP image for 3GPP TS 28.540, Fig. 4.10.3-1: Non-geosynchronous satellites in NTN with regenerative gNB processed satellite payload
Figure 4.10.3-1: Non-geosynchronous satellites in NTN with regenerative gNB processed satellite payload
(⇒ copy of original 3GPP image)
Up
As defined in TS 38.300, with Non-Geosynchronous orbit (NGSO) satellites, the gNB can provide either quasi-Earth-fixed cell coverage or Earth-moving cell coverage.
One consequence of non-geosynchronous satellites is that the associations between the entities on ground segment and entities in space segment are changing frequently, typically with a period of one to several minutes.
Another issue is the topology between space segment Managed Element (MnS producer) and the ground based Management System (MnS consumer): With long distances in between, disturbances (e.g. bad weather conditions), and partial reachability issues (when satellites fly over oceans with no gateway coverage), the latency, availability and reliability of the interface between them (feeder link + Inter-satellite link) are impacted.
Summary:
For the deployment scenario of RAN nodes on-board satellites, this would result in the following scenario: a LEO or MEO satellite with an onboard RAN node leaves the coverage area of a CN and then returns to the coverage area of that CN after cycling around the earth one or several times seen from the operator's perspective, it is necessary to investigate how to efficiently manage 1) The cell configuration of satellite gNBs when quasi-Earth-fixed cell coverage is applied, as the moving satellite gNB is serving different coverage areas over time. 2) The connections between RAN nodes and CN to avoid errors in CN due to stale connections, e.g. AMF sending paging requests or AMF configuration updates to an unavailable RAN node. For example, 3GPP management system configures AMF and/or gNB to add necessary information to support their awareness of when connectivity between a RAN node and a CN NF is available or unavailable.
Up

4.11  Management of RedCap feature  p. 10

RedCap is a lightweight network access solution aiming at scenarios with relatively low cost, low energy consumption, and low data rate requirement, mainly applying to scenarios such as industrial sensors, video surveillance, wearable scenarios, smart grid, etc.
In some scenarios, operator may want to prohibit RedCap UEs to access specific NR cells for a specified time to improve the network performance for non-RedCap UEs. After the specified time, operator will allow RedCap UEs to access specific NR cells again. So, the 3GPP management system should have the capability to allow operators to configure the NR cell to allow or prohibit RedCap UEs to access.
An initial BWP can be configured for RedCap UEs' initial access instead of initial BWP that may exceed the (e)RedCap UE maximum bandwidth. So, the 3GPP management system should have the capability to configure initial BWP separately for RedCap UEs.
Up

4.12  Management of WAB-gNB  p. 10

WAB provides an NR access link to UEs in proximity and connects to the 5GC serving the UE through an IP connectivity provided by a Backhaul PDU session(s). A WAB-node consists of a WAB-gNB and a WAB-UE. The WAB-gNB is based on the gNB functionality specified in TS 38.300 and serves UEs by means of a terrestrial NR Uu radio link. The 3GPP management system should provide the configuration parameters to the WAB-gNB to support management of WAB-gNB. The 3GPP management system should provision configuration parameters based on the current location of the WAB-node. In that case, the continuity of OAM connectivity needs to be ensured as the WAB-node moves.
The OAM provides configuration parameters for WAB-gNB including the configuraton for activating/deactivating the WAB-gNB operation, and to assist the WAB-gNB providing information used by WAB-UE for the BH PDU Session(s) management via URSP processing.
Note that the name of WAB-gNB and MWAB-gNB are used exchangably.
Up

4.13  Management of Ambient IoT  p. 11

As defined in TS 23.369, Ambient IoT is a service that can be provided by the 5G system to support Ambient power-enabled IoT devices that are powered by energy harvesting, being either battery-less or with limited energy storage capability (e.g. using a capacitor) and the energy is provided through the harvesting of radio waves, light, motion, heat, or any other suitable power source. The 5GS System architecture for AIoT includes core network functions, AIoT Readers and AIoT Devices, where AIoT Reader can be supported by NG-RAN. However, to enable AIoT services such as inventory service and command service, as defined in the TS 23.369, it is required to correctly identify the appropriate AIOTF and RAN node instance with A-IoT capability to ensure accurate identification of AIoT devices for correctly triggering various AIoT related operations. This requires an effective mapping between the expected external target area (provided by the Application Function) and the internal target area served by the 5G Core (5GC) and RAN nodes and readers.
The AIoT service operations can work flawlessly with the help of configurations provided by Operations, Administration, and Management (OAM). The NEF can obtain internal area mapping corresponding to the external target area from OAM and use it for further processes like identifying of correct AIOTF with the help of NRF. This ensures that the NEF can accurately identify and interact with the correct internal network segments, leading to targeted service delivery. Management of Ambient IoT includes the configuration for core network functions and NG-RAN with A-IoT capability to support Ambient IoT.
Up

4.14  Management of IAB-node  p. 11

IAB architecture is specified in TS 38.401. The management of IAB-node includes the IAB-node connectivity to management system as specified in TS 28.314 and IAB-node configuration as specified in TS 28.531.

4.15  Management of XRM Service  p. 11

XR/Media Service refers to emerging mobile media services, e.g. cloud AR/VR and cloud gaming, which are expected to contribute more and more traffics to 5G network. Such XR/media traffics have some common characteristics including high throughput, low latency, high reliability requirement, and periodicity. 5GC can utilize such information for transmission control and efficiency. The 3GPP management system should provision configuration parameters to support policy control and packets handling of XRM Service in 5GC.
Up

4.16  Management of NR Femto  p. 11

NR Femto enables use cases such as providing NR access at home or at enterprise premises. An NR Femto node hosts the same functions as a gNB as described in clause 4.1 of TS 38.300.
As specified in clause 5.50.2 of TS 23.501, an NR Femto node connects to 5GC directly or via an NR Femto Gateway (GW).
As specified in clause 5.50.2 of TS 23.501, the NR Femto GW appears to the AMF as a gNB, while to the NR Femto node(s) it appears as an AMF. The N2 and N3 interface between the NR Femto node(s) and the 5GC is the same, regardless of whether or not the NR Femto node(s) is(are) connected to the 5GC via an NR Femto GW.
The OAM provides configuration parameters for NR Femto nodes as well as configuration parameters for NR Femto GW, including the configuration for activating/deactivating NR Femto node and NR Femto GW as well as mobility related parameters such as PLMN id and TAC.
Up

5  Requirements  p. 12

5.1  Requirements for management of NG-RAN  p. 12

The following specific requirements apply to NG-RAN:
REQ-NGRAN_NRM-CON-001:
The NRM definitions shall support management of NG-RAN, containing gNB or/and ng-eNB.
REQ-NGRAN_NRM-CON-002:
The NRM definitions shall support management of either gNB without split function or gNB with split functions defined in TS 38.401.
REQ-NGRAN_NRM-CON-003:
The NRM definitions shall support management of virtualized network functions that are part of gNB, e.g. virtualized gNB-CU.
REQ-NGRAN_NRM-CON-004:
The NRM definitions shall support management of intra-NG-RAN handover between any combinations of gNB and ng-eNB.
REQ-NGRAN_NRM-CON-005:
The NRM definitions shall support management of inter-system handover between 5GS and EPS.
REQ-NGRAN_NRM-CON-006:
The NRM definitions shall support management of network slicing feature in NG-RAN.
REQ-NGRAN_NRM-CON-007:
The NRM definitions shall have a read-only representation of NR beam properties in NG-RAN.
REQ-NGRAN_NRM-CON-008:
The NRM definitions shall support configuration of sector carrier coverage properties in NG-RAN.
REQ-NGRAN_NRM-CON-009:
The NRM definitions shall support management of radio access network sharing feature in NG-RAN.
REQ-NGRAN_NRM-CON-010:
The NRM definitions shall support management of self optimization network feature in NG-RAN.
Up

5.2  Requirements for management of MR-DC  p. 12

The following specific requirements apply to MR-DC management, including management of NR in EN-DC and other MR-DC operations.
REQ-MRDC_NRM-CON-001:
The NRM definitions shall support management of NR node in EN-DC operation (en-gNB).
REQ-MRDC_NRM-CON-002:
The NRM definitions shall support management of en-gNB with different user plane connectivity options defined in TS 37.340.
REQ-MRDC_NRM-CON-003:
The NRM definitions shall support management of NG-RAN nodes in NGEN-DC operation.
REQ-MRDC_NRM-CON-004:
The NRM definitions shall support management of different user plane connectivity options in NGEN-DC operation defined in TS 37.340.
REQ-MRDC_NRM-CON-005:
The NRM definitions shall support management of NG-RAN nodes in NE-DC operation.
REQ-MRDC_NRM-CON-006:
The NRM definitions shall support management of different user plane connectivity options in NE-DC operation defined in TS 37.340.
REQ-MRDC_NRM-CON-007:
The NRM definitions shall support management of NG-RAN nodes in NR-DC operation.
REQ-MRDC_NRM-CON-008:
The NRM definitions shall support management of different user plane connectivity options in NR-DC operation defined in TS 37.340.
Up

5.3  Requirements for management of 5GC NFs  p. 13

The following specific requirements apply to management of 5GC NFs:
REQ-5GC_NRM-CON-001:
The NRM definitions shall support management of 5GC containing variety of network functions defined in TS 23.501.
REQ-5GC_NRM-CON-002:
The NRM definitions should support management of all the relationships between network functions and corresponding data storage functions where the network functions store/retrieve their data.
REQ-5GC_NRM-CON-003:
The NRM definitions shall support management of interworking between 5GC and EPC.
REQ-5GC_NRM-CON-004:
The NRM definitions shall support management of network slicing feature in 5GC.
REQ-5GC_NRM-CON-005:
The NRM definitions shall support management of 5GC network function services independently to align with requirements of TS 23.501.
REQ-5GC_NRM-CON-006:
The NRM definitions shall support NF service instance registration, deregistration, update, etc., with NRF during NF service instance lifecycle to align with requirements of TS 23.501 and TS 23.502.
REQ-5GC_NRM-CON-007:
The NRM definitions shall support configuration of NF profile for NF Service registration and discovery to align with requirements of TS 23.501 and TS 23.502.
REQ-5GC_NRM-CON-008:
The NRM definitions should support 5G ProSe Direct Discovery and Communication to align with requirements of TS 23.304.
Up

5.4  Requirements for management of AMF Set  p. 13

REQ-AMFSET_NRM-CON-001:
The NRM definitions shall support management of AMF Region and AMF Set, including AMF load balancing management.

5.5  Requirements for management of edge computing  p. 13

REQ-ECM_NRM-CON-001:
The NRM definitions shall support management of 5GC NFs supporting edge computing.

5.6  Requirements for management of network slice and network slice subnet  p. 13

The following requirements apply to network slice and network slice subnet:
REQ-NS_NRM-CON-001:
The NRM definitions shall support management of network slice.
REQ-NS_NRM-CON-002:
The NRM definitions shall support management of network slice subnet.
REQ-NS_NRM-CON-003:
The NRM definitions shall support the attributes of the Generic network Slice Template (GST) defined by GSMA [8].

5.7  Requirements Remote Interference Management  p. 14

REQ-RIM-CON-001:
The NRM definitions should support Remote Interference Management.

5.8  Void

5.9  Requirements for management of NTN  p. 14

5.9.1  Management of transparent mode feature  p. 14

5.9.1.1  Management of transparent mode feature for NG-RAN  p. 14

REQ-NTN_TRANS_NRNRM-001:
The 3GPP management system should support management of NTN NG-RAN node.
REQ-NTN_TRANS_NRNRM-002:
The 3GPP management system should support NTN mobility management.

5.9.1.2  Management of transparent mode feature for 5GC  p. 14

REQ-NTN_TRANS_5GCNRM-001:
The 3GPP management system should support NTN UE location verification.
REQ-NTN_TRANS_5GCNRM-002:
The 3GPP management system should support NTN access restriction.
REQ-NTN_TRANS_5GCNRM-003:
The 3GPP management system should support NTN mobility management.

5.9.2  Management of Backhaul feature  p. 14

REQ-NTN_BACKHAUL-001:
The 3GPP management system should support a capability to allow the MnS consumer to configure satellite backhaul information for NTN node.

5.9.3  Management of UE-Satellite-UE communication feature  p. 14

REQ-NTN_USU_5GCNRM-001:
The 3GPP management system should support NTN UE-Satellite-UE communication feature.

5.9.4  Management of regenerative mode feature  p. 14

REQ-NTN_REGEN-001:
The 3GPP management system shall have the capability to allow the MnS consumer to configure NTN neighbour cells considering the satellite movement.
REQ-NTN_REGEN-002:
The 3GPP Management System should have the capability to allow the configuration of the connections between RAN nodes on-board satellite and 5GC considering that the availability of the management interface to the RAN nodes may be intermittent.
REQ-NTN_REGEN-003:
The 3GPP Management System should have the capability to allow the configuration of the (quasi-Earth-fixed) cell configurations of RAN nodes where, due to satellite movement, the configuration requires continuous update while considering that the availability of the management interface to the RAN nodes may be intermittent.
REQ-NTN_REGEN-004:
The 3GPP Management Systemshall have the capability to allow the MnS consumer to configure TACs for NTN cell, while considering the satellite movement.
Up

5.10  Requirements for management of RedCap feature  p. 15

REQ-RedCap_NRNRM-1:
The 3GPP management system should support a capability to allow MnS consumer to configure Multi-Initial BWPs to support RedCap and Non-RedCap UEs co-existence scenario.
REQ-RedCap_NRNRM-2:
The 3GPP management system should support a capability to allow MnS consumer to configure the NR cell to allow or prohibit RedCap UEs to access.
REQ-RedCap_NRNRM-3:
The 3GPP management system should support a capability to allow MnS consumer to configure initial BWP separately for RedCap UEs.

5.11  Requirements for management of WAB-gNB  p. 15

REQ-VMR-CON-001:
The 3GPP management system may support IP address configuraton for WAB-gNB management.
REQ-VMR-CON-002:
The 3GPP management system should support TAC/RANAC (re)configuraton for WAB-gNB management.
REQ-VMR-CON-003:
The 3GPP management system should support activating/deactivating the WAB-gNB operation.

5.12  Requirements for management of Ambient IoT  p. 15

5.12.1  Management of Ambient IoT for NG-RAN  p. 15

REQ-AIOT_NRNRM-1:
The 3GPP management system should support the capability to configure NG-RAN to support AIoT.
REQ-AIOT_NRNRM-2:
The 3GPP management system should support the capability to configure gNB reader served A-IoT areas for management of Ambient IoT.
REQ-AIOT_NRNRM-3:
The 3GPP management system should support the capability to configure reader location for management of Ambient IoT.

5.12.2  Management of Ambient IoT for 5GC  p. 15

REQ-AIOT_5GCNRM-1:
The 3GPP management system should support the capability to configure 5GC Network Functions to support AIoT.
REQ-AIOT_5GCNRM-2:
The 3GPP management system should support the capability to configure A-IoT areas, reader location and index for A-IoT capable gNB/reader selection.
REQ-AIOT_5GCNRM-3:
The 3GPP management system should support the capability to configure NEF with mapping information between external target area and internal target area for correct identification of AIOTF.

5.13  Requirements for management of IAB-node  p. 15

REQ_IAB_NRM_1:
The NR NRM definitions should support location information of IAB-node.
REQ_IAB_NRM_2:
The NR NRM definitions should support IP configuration for IAB-node OAM connectivity.

5.14  Requirements for management of XRM Service  p. 15

REQ-XRM_OAM-1:
The 3GPP management system should support the capability to configure 5GC Network Functions to support policy control of XRM Service.
REQ-XRM_OAM-2:
The 3GPP management system should support the capability to configure 5GC Network Functions to support packets handling of XRM Service.

5.15  Requirements for management of NR Femto  p. 16

REQ-FEMTO_CON-001:
The NR NRM definitions shall support management of NR Femto node.
REQ-FEMTO_CON-002:
The NR NRM definitions shall support management of NR Femto GW.
REQ-FEMTO_CON-003:
The 5GC NRM definitions shall support management of NR Femto GW.

$  Change history  p. 17

Up   Top