LTE3296/SR001527 functional description

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature alters the object model of both LTE and SRAN products to align them in one topology. There are some conceptual changes introduced to make the object model scalable and more useful to the operator, as well as simple relocations. The major changes can be summarized as follows:

• Configured hardware is separated from hardware detected at runtime. A new top-level MOC named EQM holds the configuration of hardware specified by the operator, and a similar MOC named EQM_R holds the configuration of hardware detected by the eNB at runtime. The Distinguished Name (DN) of the object configuring that hardware in the EQM tree is mapped to the detected hardware in EQM_R.

• Hardware topology is now defined by a new set of objects in the EQM/EQM_R trees.

Configured topology is now in the HWTOP tree, split into physical and logical links in CABLINK and LOGLINK objects, and similarly the detected hardware topology is stored in CABLINK_R and LOGLINK_R objects under HWTOP_R in EQM_R.

• Common management parameters are located in the MNL object tree on the top level. Actions such as SW reset or calibration and testing are located in this tree. The management subtree also holds the new CELLMAPPING tree to configure mapping between cells and physical resources, replacing the BTSSCL/LCELL object.

• FDD and TDD parameters are aligned into one common model, with technology-specific parameters being split into new MOCs with the suffix _TDD or _FDD as appropriate.

• For SRAN, the RAT-specific parameters will have their own top-level subtrees LNBTS, WNBTS and GNBTS for LTE, WCDMA and GSM respectively.

New MOC tree overview

Figure 15 Top level objects in the hierarchy

Changes to hardware configuration and detection

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature introduces a new way of presenting configured and detected hardware to the

administrator. Configured hardware is maintained separately in the object hierarachy under the EQM object, and detected hardware is presented under the read-only EQM_R hierarchy. Detected hardware that matches configured hardware is linked via an ID in the relevant object under EQM_R.

Figure 16 The EQM and EQM_R object trees

For each MOC under the EQM subtree, there is a corresponding MOC with the suffix of _R in the EQM_R subtree. The two MOCs are related to each other by their names and also via the parameter configDN in the _R object. configDN contains the

Distinguished Name (DN) of the MOC in EQM. For the DN format, please refer to the RAML2.1 Specification, section 2.1. It is possible that there are discrepancies between the two subtrees. Even in the normal case, the EQM_R tree contains more objects than the configured list because the BTS is able to provide more information to the operator without manual configurations. There are two cases where the discrepancies are reflected in the configDN and state attributes:

1. Hardware is installed but there is no configured EQM object. In this case, the _R object will be present with configDN set to NULL. This _R object will not be enabled until the corresponding EQM object is configured.

2. An object in EQM is configured but the hardware is not installed. In this case, the _R object will be present with configDN set to the configured object. The states of the _R object will reflect that it is not installed.

There are significant changes in the hardware topology area. New objects have been introduced: CABLINK and LOGLINK. CABLINK represents the physical cable, LOGLINK represents a connection between two points, without explicitly defining the environment between them. Topology between System Modules and RF modules are defined as CABLINKs specified only by the Distinguished Names of the endpoints. For an antenna path specification, a full topology is required.

These are the configurable objects and their usage for a macro BTS:

• EQM – The top object of the EQM tree. It must always be present.

• APEQM – Access point equipment subtree. This subtree consists of equipment that makes up an access point. For macro, there is only 1 instance of it.

• CABINET – At least one is needed to house the system and baseband modules.

• SMOD – System Module. The controller of the BTS containing the management interface towards NetAct. Depending on the hardware release, it may or may not contain baseband processing. There may also be multiple SMODs but only one will be the main controller. Additional SMODs are for expansion purposes.

• EAC_IN, EAC_OUT – these are optional environmental control for alarm inputs (EAC_IN) or relay control (EAC_OUT). They can also be present under an RMOD.

• BBMOD – Baseband Module. Baseband processing module. Additional modules can be added to a System module to expand the processing capacity.

• PASSDEV – a generic MOC for the operator to document equipment that cannot be detected by the BTS. It can be used for modeling passive ALD devices or simply a way for the operator to record inventory data of other passive devices (e.g. power supply, fan) for the purpose of keeping track of HW inventory.

• RMOD – Radio module. This can be an RF module that is part of the system module (as in small cell), locally connected to the System Module or remotely connected as a Remote RF Head (RRH).

• SMOD_EXT – a virtual object to represent a system module from a peer BTS. In RF sharing, the SMOD_EXT represents another BTS that shares resources of one or more radio modules.

• HWTOP – Hardware Topology top object. It must always be present.

• CABLINK, LOGLINK – Hardware Topology objects defining physical and logical connections between modules.

Common Management subtree MNL The MNL tree contains three objects:

• CMD - Commands, such as hardware reset or RET unit calibration, are activated here.

• NOTES - Contains NOTE objects that may be freely filled by the operator for any purpose.

• MNLENT - System module specific objects are placed under MNLENT. The MNLENT (Management Layer Entity) object contains system module specific parameters and is placed under MNL with one instance for each entity. The related objects under MNLENT are as follows:

• BBADM - Baseband Administration. Contains BBPOOL objects.

• CAPADM - Capacity Administration. Capacity configuration and limitations are defined here.

• CELLMAPPING - Cell Mapping. This replaces the cell mapping list that was previously part of LNCEL.

• FMCADM - Fault Management Common Administration. Parameters related to fault management are moved here.

• FEATCADM - Feature Common Administration. Parameters to activate and administer specific features appear here.

• PMCADM - Performance and Monitoring Common Administration.

• SECADM - Security Common Administration. Security related parameters are found here, and additional security information detected by the BTS is available in the SECADM_R sub-object.

• SYNC - Synchronization. Time source and synchronization configuration is made here.

• TEST - Tests. Testing is activated here and the results returned as objects under the TEST object.

• TRBLCADM - Troubleshooting Common Administration. Contains troubleshooting parameters.

Figure 17 The MNL tree

Figure 18 The MNLENT subtree

The CELLMAPPING subtree contains the new scheme for mapping cells to antennas that replaces the previous one in BTSSCL/LCELL. The CELLMAPPING object contains a number of LCELL objects equivalent to the old LCELL object, but each new LCELL object contains a number of CHANNELGROUP objects that contain CHANNEL objects.

The CHANNELGROUP and CHANNEL objects replace the legacy resourceList parameter in the old LCELL.

Each CHANNEL object is linked to an ANTL object in the EQM tree using the antlDN parameter, and it also contains a direction parameter to specify whether the channel is RX or TX. A TXRX antenna line is configured with two CHANNEL objects, one for each direction. As the ANTL is a child object of an RMOD, there is no need to specify the old rmodId or antId parameters.

Unification of LNCEL for FDD and TDD technologies

The LTE3296/SR001527: Harmonized Object Model for SRAN and LTE feature unifies the previously different hierarchies of the LNBTS/LNCEL tree into one form.

The LNCEL object has a new parameter cellTechnology that may be set as FDD or TDD. TDD- and FDD-specific parameters in LNCEL are moved to technology-specific objects LNCEL_TDD and LNCEL_FDD respectively, which contain technology-specific objects for MPUCCH and APUCCH with the _TDD and _FDD suffix. LNCEL child objects belonging to one specific technology are configured only if that technology is specified by the cellTechnology parameter in the LNCEL parent, and objects common to both technologies are consistency-checked according to that same parameter.

The LNBTS object has a similar controlling parameter named

supportedCellTechnology that applies to the whole eNB, and again TDD- and FDD-specific parameters are moved to child objects named LNBTS_TDD and

LNBTS_FDD respectively. Common child classes are aligned and consistency-checked according to that parameter, with the exception of MBSFNSYNCAREA and MBSFNSYNC which are split into technology-specific classes with the _TDD and _FDD suffix.

Figure 19 The LNBTS tree

Figure 20 The LNCEL tree