Configuration Push Guide

Pushing configuration changes to Nokia AirScale base stations via RAN Monitor

Overview

RAN Monitor can push configuration changes to Nokia AirScale base stations using the NE3S Bulk Operations protocol. Configuration is expressed as an SCF (Site Configuration File) in RAML 2.1 XML format. The push follows a three-step process on the BTS: download (stage the plan), validate (check for errors), and activate (apply changes). RAN Monitor handles all three steps automatically.

A configuration push can be a full SCF containing every managed object on the BTS, or a partial update targeting only the specific parameters you want to change. Partial updates are the recommended approach for operational changes because they are faster, lower risk, and avoid triggering unnecessary BTS reboots.

SCF XML Format

All configuration files use the RAML 2.1 XML schema. The basic structure is:

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>

<!-- Managed objects go here -->

</cmData>
</raml>

Each managed object is represented as a <managedObject> element:

<managedObject class="NOKLTE:LNBTS" distName="MRBTS-256/LNBTS-256" operation="update">
<p name="enbName">MY-SITE-NAME</p>
</managedObject>

Key Attributes

Attribute	Description
`class`	Nokia object class identifier (e.g. `NOKLTE:LNCEL`, `com.nokia.srbts.tnl:IPIF`)
`distName`	Distinguished name — the object's path in the managed object tree
`operation`	`create` for full SCF push, `update` for partial changes

Distinguished Name Format

The distName follows a hierarchical path:

MRBTS-{bts_id}                                    # BTS root
MRBTS-{bts_id}/LNBTS-{bts_id}                     # LTE eNodeB
MRBTS-{bts_id}/LNBTS-{bts_id}/LNCEL-{cell_id}     # LTE Cell
MRBTS-{bts_id}/GNBTS-{gsm_id}                     # GSM BTS
MRBTS-{bts_id}/GNBTS-{gsm_id}/GNCEL-{cell_id}     # GSM Cell
MRBTS-{bts_id}/MNL-1/MNLENT-1/PMCADM-1            # PM Administration
MRBTS-{bts_id}/EQM-1/APEQM-1                      # Equipment Management

Full SCF Push vs Partial Update

Full SCF Push

A full SCF contains every managed object on the BTS (typically 100-200 objects). It uses operation="create" on each object. This replaces the entire configuration.

When to use: Initial provisioning, disaster recovery, or restoring a known-good configuration from backup.

Risk: High. A full SCF typically contains transport/IP objects that will trigger a BTS reboot, taking the site offline for 3-5 minutes.

Partial Update

A partial SCF contains only the objects and parameters you want to change. It uses operation="update" and only includes the specific <p> elements being modified.

When to use: Operational parameter changes, cell tuning, feature activation, PM configuration.

Risk: Low to none, provided you avoid reboot-triggering object classes.

Key Differences

	Full SCF	Partial Update
Operation attribute	`operation="create"`	`operation="update"`
Objects included	All managed objects	Only objects being changed
Parameters included	All parameters per object	Only parameters being changed
Reboot risk	Almost certain	Depends on object classes
Typical use case	Initial provisioning	Day-to-day changes

Reboot Impact by Object Class

Objects That Trigger a BTS Reboot

Changing any of these object classes will cause the BTS to restart. The site will be offline for 3-5 minutes during the reboot.

Category	Object Classes
Transport / IP	`TNL`, `ETHIF`, `ETHLK`, `IPIF`, `IPADDRESSV4`, `IPRT`, `IPRTV6`, `VLANIF`, `L2SWI`, `BRGPRT`, `IBRGPRT`, `IPNO`, `ETHSVC`, `TNLSVC`, `IPSECC`, `FIREWALL`
System / Hardware	`MRBTS`, `SMOD`, `BBMOD`
Management Plane	`MPLANENW`, `CLOCK`, `SYNC`, `NTP`
Security / Certificates	`SECADM`, `CERTH`, `CERTHENT`, `CMP`, `CMPECDSA`, `CMPFH`

Objects Safe to Change Without Reboot

These object classes can be updated without triggering a restart. Some radio parameter changes will cause a brief cell outage (seconds) as the cell reconfigures.

Category	Object Classes	Notes
LTE Radio	`LNCEL`, `LNCEL_FDD`, `LNBTS`, `LNBTS_FDD`	Some parameters cause brief cell reconfiguration
GSM Radio	`GNBTS`, `GNCEL`, `GNBCF`
Performance Monitoring	`PMCADM`, `PMMNL`, `PMCCP`, `PMPLM`, `PMRNL`, `PMTNLINT`
Features	`FEATCADM`, `FEATGADM`, `FEATLADM`
ANR / Neighbour Relations	`ANR`, `ANRPRL`
RRC / DRX	`DRX`, `SDRX`, `SIB`
S1 / Transport	`SCTP`, `TRSNW`, `LNMME`
Other	`ALARMSUPP`, `REDRT`, `CAGENB`, `CADPR`, `QOS`

Runtime Objects (Read-Only)

Object classes ending in _R are runtime objects generated automatically by the BTS. They cannot be pushed and are stripped automatically by RAN Monitor before upload. Examples: EQM_R, APEQM_R, LNCEL_R, TNL_R, ETHIF_R.

Partial Update Examples

Changing the eNB Name

No reboot. Takes effect immediately.

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>
<managedObject class="NOKLTE:LNBTS" distName="MRBTS-256/LNBTS-256" operation="update">
<p name="enbName">NICK-LAB-AIRSCALE</p>
</managedObject>
</cmData>
</raml>

Changing the Cell Name

No reboot. Takes effect immediately.

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>
<managedObject class="NOKLTE:LNCEL" distName="MRBTS-256/LNBTS-256/LNCEL-256" operation="update">
<p name="cellName">TRI-B5-1</p>
</managedObject>
</cmData>
</raml>

Changing the Physical Cell ID

No reboot. The cell will briefly reconfigure.

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>
<managedObject class="NOKLTE:LNCEL_FDD" distName="MRBTS-256/LNBTS-256/LNCEL-256/LNCEL_FDD-256" operation="update">
<p name="physCellId">120</p>
</managedObject>
</cmData>
</raml>

Changing EARFCN and Bandwidth

No reboot, but the cell will be briefly unavailable (seconds) as it reconfigures to the new frequency.

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>
<managedObject class="NOKLTE:LNCEL_FDD" distName="MRBTS-256/LNBTS-256/LNCEL-256/LNCEL_FDD-256" operation="update">
<p name="earfcnDL">1400</p>
<p name="dlChBw">10 MHz</p>
</managedObject>
</cmData>
</raml>

Changing PM Collection Interval

No reboot. Takes effect on the next collection cycle.

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>
<managedObject class="com.nokia.srbts.mnl:PMCADM" distName="MRBTS-256/MNL-1/MNLENT-1/PMCADM-1" operation="update">
<p name="rTPmCollInterval">60s</p>
</managedObject>
</cmData>
</raml>

Changing Multiple Parameters Across Objects

Multiple objects can be included in a single SCF. This example changes the eNB name and a cell parameter in one push:

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>
<managedObject class="NOKLTE:LNBTS" distName="MRBTS-256/LNBTS-256" operation="update">
<p name="enbName">NICK-LAB-AIRSCALE</p>
</managedObject>
<managedObject class="NOKLTE:LNCEL" distName="MRBTS-256/LNBTS-256/LNCEL-256" operation="update">
<p name="cellName">TRI-B5-1</p>
<p name="pMax">331</p>
</managedObject>
</cmData>
</raml>

Changing an IP Address (Triggers Reboot)

Changing transport/IP objects will reboot the BTS. The site will be offline for 3-5 minutes.

<?xml version="1.0" encoding="UTF-8"?>
<raml xmlns="raml21.xsd" version="2.1">
<cmData type="actual" scope="all" domain="ALL">
<header>
<log dateTime="2026-03-21T00:00:00+00:00" action="created"></log>
</header>
<managedObject class="com.nokia.srbts.tnl:IPADDRESSV4" distName="MRBTS-256/TNL-1/IPNO-1/IPIF-1/IPADDRESSV4-1" operation="update">
<p name="localIpAddr">10.7.15.66</p>
</managedObject>
</cmData>
</raml>

Pushing Configuration via the Web UI

Navigate to BTS Status in the control panel
Click Config Ops on the target device
Select your partial SCF XML file (drag and drop or browse)
Click Push Configuration to Device
RAN Monitor automatically strips runtime objects, then performs download, validate, and activate
Monitor the result message for success or errors

For more control, expand the Advanced: Manual download/validate/activate steps section to stage a plan without activating it, then validate and activate separately.

Pushing Configuration via the API

PUT /api/ne3s/function/provision
Content-Type: application/json

{
  "airscale_name": "ons-Lab-Airscale",
  "config_file": "/path/to/partial-config.xml"
}

The config_file path must exist on the RAN Monitor server. Copy the file to the server first if necessary.

Response on success:

{
  "status": "success",
  "operation": "provision",
  "plan_id": "plan_1774041772721652742",
  "data": "<activateResponse>...</activateResponse>"
}

Response on failure:

{
  "status": "error",
  "code": "PROVISION_FAILED",
  "message": "validate failed: Validation error details..."
}

API Parameters

Parameter	Type	Required	Default	Description
`airscale_name`	String	Yes	-	Registered device name in RAN Monitor
`config_file`	String	Yes	-	Absolute path to SCF XML file on the RAN Monitor server

Best Practices

Always download a backup first. Use the Web UI "Download Config" button or the API to save the current configuration before making changes.
Use partial updates for operational changes. Only include the objects and parameters you need to change. This minimises risk and avoids reboots.
Use operation="update" for partial changes. The operation="create" attribute is for full SCF replacements and will overwrite all parameters on the object.
Check the object class before pushing. If your SCF includes any transport, system, management, or security objects, the BTS will reboot. Plan a maintenance window accordingly.
Verify the distName matches your target BTS. The MRBTS ID, LNBTS ID, and cell IDs must match the target device. Push the wrong distName and the BTS will reject the config with a validation error.
One change at a time for critical parameters. When changing radio parameters that affect service (EARFCN, bandwidth, PCI), make one change per push so you can isolate any issues.

Troubleshooting

Validation Failed: Duplicated Object

Symptoms: Push fails with Duplicated object MRBTS-256/EQM_R-1

Cause: The SCF contains runtime (_R) objects. These are auto-generated by the BTS and cannot be pushed.

Resolution: RAN Monitor strips _R objects automatically. If you see this error, verify you are pushing through RAN Monitor and not directly to the BTS.

Activation Failed: Operation Conflict

Symptoms: Push fails with Operation could not execute because of operation conflict, RequestOperationType = {activate}, OngoingOperationType = {validate}

Cause: The activate was sent before validation completed. The BTS processes each step asynchronously.

Resolution: RAN Monitor waits for async completion between steps automatically. If this occurs, retry the push. If it persists, check that no other management system (NetAct, WebLM) is simultaneously pushing configuration to the same BTS.

BTS Rebooted Unexpectedly

Symptoms: BTS goes offline after config push, ping fails for 3-5 minutes.

Cause: The pushed configuration included transport/IP, system, or security objects that trigger a reboot.

Resolution: The BTS will come back on its own after 3-5 minutes. To avoid this in future, use a partial update that only includes the specific parameters you want to change, avoiding the reboot-triggering object classes listed above.

Plan File Not Found

Symptoms: Activate fails with Processing of attachment detail property file failed in agent

Cause: Internal BTS error reading the staged plan file. Can occur when multiple config operations overlap.

Resolution: Wait 30 seconds and retry the push. If the error persists, restart the NE3S session by using the "Force Reconnect" button in the Web UI before retrying.

Overview​

SCF XML Format​

Key Attributes​

Distinguished Name Format​

Full SCF Push vs Partial Update​

Full SCF Push​

Partial Update​

Key Differences​

Reboot Impact by Object Class​

Objects That Trigger a BTS Reboot​

Objects Safe to Change Without Reboot​

Runtime Objects (Read-Only)​

Partial Update Examples​

Changing the eNB Name​

Changing the Cell Name​

Changing the Physical Cell ID​

Changing EARFCN and Bandwidth​

Changing PM Collection Interval​

Changing Multiple Parameters Across Objects​

Changing an IP Address (Triggers Reboot)​

Pushing Configuration via the Web UI​

Pushing Configuration via the API​

API Parameters​

Best Practices​

Troubleshooting​

Validation Failed: Duplicated Object​

Activation Failed: Operation Conflict​

BTS Rebooted Unexpectedly​

Plan File Not Found​