Single RAN Management Overview Guide
Single RAN Management Overview Guide
This document includes Nokia proprietary and confidential information, which may not be distributed or disclosed to any third parties without
the prior written consent of Nokia.
This document is intended for use by Nokia’s customers (“You”/”Your”) in connection with a product purchased or licensed from any company
within Nokia Group of Companies. Use this document as agreed. You agree to notify Nokia of any errors you may find in this document;
however, should you elect to use this document for any purpose(s) for which it is not intended, You understand and warrant that any
determinations You may make or actions You may take will be based upon Your independent judgment and analysis of the content of this
document.
Nokia reserves the right to make changes to this document without notice. At all times, the controlling version is the one available on Nokia’s
site.
This document is Nokia’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the
prior written consent of Nokia.
Copyright and trademark: Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be
trademarks of their respective owners.
© 2021 Nokia.
3 Object model.................................................................................................................................................. 21
4 Configuration management.......................................................................................................................... 27
4.1 Pre-validation and validation...................................................................................................................27
4.2 Provisioning and send to network.......................................................................................................... 28
4.3 Upload and events.................................................................................................................................. 28
4.4 BTS Conversion Service.........................................................................................................................29
5 Software management.................................................................................................................................. 30
6 Fault management......................................................................................................................................... 31
7 Performance management............................................................................................................................32
7.1 Single RAN common transport............................................................................................................... 32
7.2 Single RAN GSM.................................................................................................................................... 32
7.3 Single RAN WCDMA.............................................................................................................................. 32
7.4 Single RAN LTE...................................................................................................................................... 33
7.5 Single RAN 5G........................................................................................................................................33
7.6 Administration of Measurements.............................................................................................................34
9 State management.........................................................................................................................................37
10 License management.................................................................................................................................. 39
13 Troubleshooting........................................................................................................................................... 44
For more information on Single RAN documentation, see the documents in the Single RAN Operating
Documentation set.
Single RAN BTS (SBTS) can host multiple RATs simultaneously, or it can be configured for one sin-
gle RAT only. The SBTS maximum concurrent configuration consists of one instance for each RAT
(5G, LTE, WCDMA and GSM). GSM and WCDMA RATs are configured in the controllers as BCF and
WBTS in addition to the site configuration in the SBTS. LTE and 5G RAT (LNBTS and NRBTS) are
configured in the SBTS only.
5G21BCLA is the last 5G Classical release that has a dedicated software package. 5G Classical soft-
ware is now provided only as a part of the SBTS software. Note that 5G Cloud is a separate product
and not part of SRAN.
LTE19 is the last LTE macro release that has a dedicated software package. LTE macro software is
now provided only as a part of the SBTS software. Note that LTE micro (small cells) is a separate
product and not part of SRAN.
AirScale support for GSM and WCDMA is only provided with the SBTS software.
The SRAN network, including SBTS and the related controllers, should be managed by one NetAct
cluster, because of the close relationships between the elements.
SBTS is integrated to NetAct via the NE3SWS mediation. The interface enables the following BTS
management functionalities:
• Configuration management
• Software management
• Fault management
• Performance management
• Security management
• License management
• Hardware inventory management
BSC and RNC controllers are required for GSM and WCDMA radio management, however, the con-
troller role in the SBTS management is limited, as SBTS has the direct management interface. Ex-
isting controller management interfaces (Q3, NWI3) are used for the radio management in BSC and
RNC. Controllers produce own performance and alarm data related to SBTS, and in case of GSM,
BSC also mediates the SBTS generated performance and alarm data to NetAct. NetAct filters SBTS
generated alarms sent by BSC as these alarms are sent to NetAct also directly by SBTS via the NE3S
interface.
The following picture describes the management interfaces of the SRAN and legacy BTSs.
BSC RNC
5G, LTE, WCDMA, Transport and performance management data is collected in a single PM data file
from SBTS and transferred to NetAct via the NE3SWS mediation. SRAN GSM performance manage-
ment data is transferred to NetAct via the BSC and Q3 mediation.
5G, LTE, WCDMA, GSM, SBTS transport and fault management data is collected from SBTS and
transferred to NetAct via the NE3SWS mediation directly.
Configuration management data for SBTS transport, site configuration, and LTE and 5G radio network
is managed via the NE3SWS mediation. The GSM radio network configuration data in BSC is man-
aged via the Q3 mediation, and the WCDMA radio network configuration data in RNC via the NWI3
mediation.
Hardware inventory data for SBTS is collected from SBTS via the NE3S/WS mediation.
The following picture illustrates the O&M evolution path from SRAN17A onward. SRAN17A intro-
duced BTS Mediator to mediate BTS data between BTS and network management system (NetAct).
SRAN19A introduced direct integration between BTS and NetAct, and the role of BTS Mediator dimin-
ished to configuration data pre-validation in the new architecture. From SRAN20A onward only the di-
rect integration is supported, however, a limited mediated integration support is provided in SRAN20A
NetAct supports SBTS rollout and provides workflows for moving between the architectures within
SRAN and from legacy technologies to SRAN. The following table gives an overview of the function-
alities supported by NetAct and provides references to documents that describe the required prereq-
uisites and the use case in detail. Moving between the BTS products (legacy – SBTS), or between ar-
chitectures (OMS, mediated integration (BTSMED), direct integration) requires planning from the sys-
tem administrator to ensure full management functionalities for the operating personnel before and af-
ter the change.
Manual inte- N/A SRAN direct Network inte- Integrating Input data in
gration integration gration wizard SBTS to Net- Excel format.
Act
The Integrating
SBTS to Net-
Act document
is available
once respec-
tive NetAct fast
pass Service
Package is in-
stalled.
Plug and Play N/A SRAN direct Unified PnP - Configuring A workflow for
integration Direct integra- Radio Network PnP databuild
tion planning Elements with planning.
Plug and Play
Unified PnP - Autoconnec-
Maintenance tion and auto-
operations and configuration
troubleshooting support.
Licensed fea-
ture.
Recommis- SRAN (mediat- SRAN direct Plan BTS site Rebuilding Several sce-
sioning ed integration, integration rebuilding BTS Sites narios support-
BTSMED) ed.
Rebuild BTS
SRAN (direct site A generic
integration) workflow for
databuild plan-
WCDMA
ning.
A supportive
workflow for
NetAct data
updates during
BTS recom-
missioning.
Input data in
XML format.
Validation by
PDL validation
service (NetAct
19 SP2002 on-
ward) or by of-
fline BTSMED.
Licensed fea-
ture.
Manual inte- N/A SRAN mediat- Network inte- Integrating Input data in
gration ed integration gration wizard SBTS to Net- Excel format.
(BTSMED) Act
The Integrating
SBTS to Net-
Act document
is available
once respec-
tive NetAct fast
pass Service
Package is in-
stalled.
Plug and Play N/A SRAN mediat- Unified PnP - Configuring A workflow for
ed integration Mediated inte- Radio Network PnP databuild
(BTSMED) gration plan- Elements with planning.
ning Plug and Play
Autoconnec-
Unified PnP - tion and auto-
Maintenance configuration
operations and support.
troubleshooting
Input data in
RACCLI: XML/CSV for-
mat.
Unified_PnP_
SOAM_Site_ Validation by
Preparation BTSMED.
Note: Combined software upgrade and switchover, for example SBTS19A/SBTS19B (medi-
ated integration) to SBTS20A (direct integration) is not supported as a mass operation. How-
ever, rebuilding workflows support combined switchover and upgrade in the recommission-
ing.
Note: BTS Mediator support is removed in SRAN20A, and SRAN19B is the last supported
release.
BTS Mediator needs to be deployed before integrating the base stations when the release version is
lower than SBTS19A. BTS Mediator is deployed on a virtual machine in NetAct Data Center. One BTS
Mediator per one NetAct needs to be deployed.
The following picture describes the connectivity configuration between NetAct, BTS Mediator, and
BTS.
In the following tables you can find examples on the DNS and NASDA entries in NetAct:
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
MRBTS-10
EM hostname [Link]
MRBTS-11
EM hostname [Link]
BTS Mediator internal mapping (southboundIPAddress, for example [Link]) is used between
the btsId and tcp connection based on the BTS self-identification during a session establishment pro-
cedure.
BTS Mediator requests NetAct for a software update, for example for a plan validation.
When cleaning up BTSMED from NetAct, there are the following phases:
Note:
• In addition to the cleanup items above, some BTSMED related cleanup activities will be
handled in SR002818 BTSMED support SW removal.
• Perform these instructions before BTSMED VM removal.
[Link]
where <system_FQDN> is the fully qualified domain name of the NetAct cluster load balancer
for WebSphere. For more information, see Launching the NetAct Start Page.
b) Type the Username and Password of the integration user, and click Log In.
Note: If the terms and conditions appear, select the I have read and agree to
the above terms and conditions check box, and then click Log In. For more
information, see Modifying terms and conditions page.
Note:
Note: You must have both CM Editor and the Workflow Engine dialog open to drag-
and-drop or copy and paste the managed object.
d) From the Operation List drop-down list, select NE data deletion from Configurator.
Expected outcome
The selected operation shows in the Operation column, and the corresponding attributes of
the operation are shown on the right.
Expected outcome
The NE data deletion from Configurator: Finished dialog appears displaying the feedback.
Expected outcome
Note: If the un-registration of BTS Mediator fails, troubleshoot the problem by following
the instructions in Un-registration fails in Troubleshooting Southbound Mediations.
Expected outcome
On the Operations History area, it is shown that the operation is completed successfully.
8. Remove the IP address of the BTS Mediator from Brute force attack white-list. Check if the IP
address of the BTS Mediator is added to the allowed list by executing the current brute force
protection status command. If the IP address of the BTS Mediator is included in the allowed
list, remove the IP address from the white-list. If not, skip this step. For more information, see
Configuring brute force protection for web services in Administering NetAct System Security.
Note:
• Contact the BTSMED administrator to get the BTSMED northbound IP address and
BTSMED northbound virtual IP address. BTSMED northbound virtual IP address is
involved only when SR001756/LTE3875: BTS Mediator Resiliency (Active-Standby) is
enabled.
• For the SBTS hostnames which also point to the BTSMED northbound IP address
or BTSMED northbound virtual IP address, check that they are not used by the user
anymore before the removal.
• If an external DNS server is used, the corresponding BTSMED DNS entry needs to be
removed also.
If the Network Segregation feature is enabled, follow the instructions to disable BTSMED firewall rules
for Network Segregation environment. In Network Segregation environment, to check whether the Net-
Act firewall rules are enabled for BTSMED, see Viewing firewall rules and customization information in
Administering NetGuard Virtual Firewall and Windows Firewall. If NetAct firewall rules are not enabled
for BTSMED, skip this section. Network Segregation feature is supported only for NetAct and NetAct
Cloud (OpenStack) and is not supported for NetAct Cloud (VMware).
The default firewall rules for connecting BTS Mediator to NetAct are listed in the following tables:
Note:
• If the Network Segregation function is enabled, IP addresses of all the NetAct nodes
in the following table must be the NetGuard routable public IP addresses. For more
information on how to query the NetGuard routable public IP addresses in Network
Segregation environment, see Listing NetGuard routable endpoints for network
segregated environment in Administering Network Segregation in NetAct.
• To prevent security risks, Nokia recommends that you choose the secure protocol
HTTPS instead of HTTP.
BTSMED ephemeral LB JBI virtu- 30505 HTTP TCP tcp-30505 NE3S/WS SMI for SBTS FM/PM no-
al IP tification. Optional: This firewall rule
is not required if the respective se-
cure protocol is used (port 30510).
BTSMED ephemeral LB JBI virtu- 30508 HTTP TCP tcp-30508 Software Manager outgoing request.
al IP Optional: This firewall rule is not re-
quired if the respective secure proto-
col is used.
BTSMED ephemeral LB JBI virtu- 30509 HTTPS TCP tcp-30509 Software Manager outgoing request.
al IP Should be enabled when secure pro-
tocol is used.
BTSMED ephemeral LB JBI virtu- 30510 HTTPS TCP tcp-30510 NE3S/WS SMI for BTSMED FM/PM
al IP notification.
BTSMED ephemeral LB WAS vir- 80 HTTP TCP http NE3S/WS SMI for BTSMED CM noti-
tual IP fications. A port used by BTSMED to
transfer BTSMED software from Net-
Act Software Manager to BTSMED,
when IPSec not in use. Optional:
This firewall rule is not required if the
respective secure protocol is used.
BTSMED ephemeral LB WAS vir- 448 HTTPS TCP tcp-448 NE3S/WS SMI for BTSMED CM noti-
tual IP fications.
BTSMED ephemeral LB WAS vir- 10510 HTTP TCP tcp-10510 NE3S/WS SMI for BTSMED CM noti-
tual IP fications. Optional: This firewall rule
is not required if the respective se-
cure protocol is used This firewall
rule is required if default port 80 is
disabled.
SBI-Com- ephemeral BTSMED 8080 HTTP/ TCP NE3S/WS BTSMED integration with non-TLS
monMedia- SOAP mode Optional: This firewall rule is
tion not required if the respective secure
protocol is used. This port is also
used in SOAM BTS integration.
SBI-Com- ephemeral BTSMED 8443 HTTPS/ TCP NE3S/WS BTSMED integration with TLS mode.
monMedia- SOAP This port is also used in SOAM BTS
tion integration.
cmwas ephemeral BTSMED 8080 HTTP/ TCP tcp-8080 NE3S/WS communication from Con-
SOAP figurator to BTSMED/SOAMBTS.
Optional: This firewall rule is not re-
quired if the respective secure proto-
col is used.
cmwas ephemeral BTSMED 8443 HTTPS/ TCP tcp-8443 NE3S/WS communication from Con-
SOAP figurator to BTSMED/SOAMBTS.
fmwas ephemeral BTSMED 22 SSH TCP ssh For SCLI connections to BTSMED
Note:
1
• AL : Application Layer
2
• TL : Transport Layer
• If the port is ephemeral, select a port from the port pool of the IP stack.
For detailed descriptions of all the sources and destinations, see the following table:
Node Description
NetAct nodes
For more information on how to get the NetAct IP addresses for a virtual machine (VM) on which a
certain service is running, see Locating the right virtual machine for a service in Administering NetAct
Virtual Infrastructure.
CMP server is used to manage SBTS certificates with the operator Certificate Authority servers. SBTS
has the same functionality as in WCDMA and LTE.
SBTS implements an NTP client to retrieve the time information from the NTP server in NetAct. In the
configurations with more than one system module, the primary system module synchronizes the time
with the other system modules.
MRBTS object hierarchies contain the common site and transport configuration. SBTS can contain
multiple technologies. LTE and 5G radio network configurations are modeled directly under the SBTS
containment tree.
The association between the radio network configuration in RNC/WBTS and/or in BSC/BCF is based
on the SBTS ID that the commissioned SBTS informs towards the controller. Using the SBTS ID, Net-
Act builds a relationship between SRAN base station and the respective radio network configuration in
the controller. NetAct also updates RNC/WBTS and BSC/BCF topology information necessary for FM
and PM adaptations (version, adaptation, relationship) based on a special warning alarm provided by
the SBTS.
The radio-specific object model in RNC/WBTS and BSC/BCF is the same in Single RAT and Single
RAN base stations. SBTS has a similar LNBTS object model, but with a dedicated release version.
Single RAT 5G and SBTS use the same NRBTS object model.
The following high-level picture illustrates the relationships between SRAN base station and
the controllers. Solid line represents the parent-child relationship and dotted line represents the
relationship by the SBTSId attribute.
MRBTS-200
NRBTS-200
LNBTS-200
WBTS-200
BCF-200
RNC-1
MRBTS-200
BSC-1
MRBTS-200
Figure 4: SRAN high-level object model
Note that the picture does not include all object classes.
MRBTS-200
GNBTS-1
LNBTS-200
WNBTS-1
NRBTS-200
EQM-1
EQM_R-1
HW-1
MNL-1
TNLSV-1
Figure 5: SRAN object model
Here is more detailed information on the objects in the MRBTS object model figure:
Related adaptations:
• CM adaptation: [Link]
• FM adaptation: [Link]
• PM adaptation: nokmrn
• Local sectors
• Management plane towards BSC
Related adaptations:
• CM adaptation: [Link]
• FM adaptation: N/A
• PM adaptation: N/A
Related adaptations:
• CM adaptation: NOKLTE
• FM adaptation: NOKLTE
• PM adaptation: NOKLTE
Related adaptations:
• CM: [Link]
• FM: [Link]
• PM: [Link]
Related adaptations:
• CM adaptation: [Link]
• FM adaptation: N/A
• PM adaptation: N/A
Related adaptations:
• CM adaptation: [Link]
• FM adaptation: N/A
• PM adaptation: N/A
Related adaptations:
• CM adaptation: [Link]
• FM adaptation: [Link]
• PM adaptation: N/A
Related adaptations:
• CM adaptation: [Link]
• CM adaptation: [Link]
Related adaptations:
• CM adaptation: [Link]
• FM adaptation: [Link]
• PM adaptation: nokmrn
• Ethernet
• PPP
• IP interfaces
• IP routing
• Transport security
• Quality of service
Related adaptations:
• CM adaptation: [Link]
• FM adaptation: [Link]
• PM adaptation: nokmrn
Configuration management operations operate on the delta plan meaning that only the changed para-
meter content is provisioned to the BTS. This is optimal for the network service because the service
impact depends on the parameter content in the plan: BTS restart, RAT restart, object locking, or on-
line. For more information on the service impact in SBTS, see State management.
Site configuration file (SCF) is used for the SBTS commissioning. Site configuration file usually refers
to the entire content of the BTS configuration. It can also be used to refer to the BTS interpretation of
the NetAct XML/RAML plans. For more information on the NetAct support for the site configuration file,
see section Site configuration file in Configuration in Configuration Management Overview and Opera-
tions.
Configuration management operations from NetAct toward each SBTS are handled as independent
actions, and there are no dependencies between BTSs. The basic principle is that SBTS can perform
only one configuration management operation at a time. However, some level of concurrency is sup-
ported for upload and download, which can be run parallel with other types of configuration manage-
ment operations under certain conditions.
For more information on validation, see Validating plans in Configuration Management Overview and
Operations.
The BTS plan pre-validation and validation can be divided into the following layers:
Responsible compo-
Validation type Example Note
nent
Validation
Validation
NetAct provides two alternatives for mass provisioning of the SBTS plans (including download, vali-
date, and activate):
• Best effort - only the successfully validated SBTS configurations are activated.
• Best consistency ('all or nothing') - plan is activated only if all the accessible SBTSs are validated
successfully.
For choosing between these alternatives, you can use option Activate only after successful pre-ac-
tivation of all BTSs in the Provision dialog of CM Operations Manager.
In the Configurator user interface, the upload scope can be MRBTS, RNC, BSC, or OMS. When the
scope is RNC, BSC, or OMS, Configurator creates separate upload requests for SRAT base stations
and SBTSs.
BTS Conversion Service is a licensed feature and part of the BTS site rebuilding use case.
For more information, see Overview of integrating BTS Conversion Service in Integrating BTS Conver-
sion Service to NetAct.
SBTS software package includes the SBTS O&M software, common transport software, and the soft-
ware of all the radio access technologies: LTE, 5G, WCDMA, and GSM. New SBTS software package
can be activated with NetAct Software Manager and Web Element Manager on top of SBTS software
and with Rescue Console on top of factory delivery software (FDSW). BTS Site Manager can be used
to activate SBTS software on top of LTE (up to LTE18A) and WCDMA software. For limitations, refer to
SRAN upgrade rules in SRAN operating documentation.
For more information on software management, see About Software Manager in Software Manager
Help.
Common alarms, for example transmission and hardware fault related alarms are targeted to the com-
mon objects of the SBTS site configuration. A common alarm without RAT impact can be, for example
an EAC (external alarm connection) alarm, or an alarm about a configuration error of resources with-
out RAT allocations. If the fault impacts the RATs in SBTS, the alarm is reported to the relevant RNW
objects. If the fault impacts more than one RAT, the alarm is reported to all relevant RATs.
Since the common faults are reported for more than one object, NetAct provides an alarm correlation
function for filtering and modifying alarms with user-defined correlation rules. For example, you can
view only your important alarms, or several RAT alarms can be merged into one. For more information,
see Alarm correlation in Fault Management Overview and Operations.
If a fault affects the radio configuration, SBTS reports an alarm for the impacted radio, for exam-
ple RNC-1010/WBTS-100/WCEL-1, BSC-1234/BCF-100/BTS-101, MRBTS-123/LNBTS-100,
MRBTS-123/NRBTS-101. For an alarm affecting more than one RAT, SBTS includes a shared tag in
the alarm information. This can be used in the alarm correlation in NetAct later.
RNC and BSC generate their own alarms for the radio service objects. The alarm numbers in the
SBTS radio service and controller radio service alarms are different. Separate alarm uploads for each
element (SBTS, RNC, BSC) are needed to get all the alarms related to a single RAN base station.
For more information on fault management, see About SingleRAN Site View in SingleRAN Site View
Help for NetAct Monitor.
Technology Hierarchy
Technology Hierarchy
Technology Hierarchy
PLMN/WS_LNCEL
Table 11: LTE technology, hierarchy, and working sets in Performance Manager+
PLMN/WS_NRBTS
PLMN/WS_NRCEL
PLMN/WS_NRDU
• [Link] adaptation is used for administering SBTS common transport, WCDMA, LTE
and 5G measurements.
• NOKBSC adaptation is used for administering SBTS GSM measurements.
For more information on the GSM measurements supported by SRAN, see Searching Single RAN da-
ta in Object Information Browser .
For more information on the corresponding GSM release when selecting the NOKBSC adaptation, see:
• Configuring GSM, WCDMA and LTE radio access technologies in Integrating SBTS to NetAct
• Configuring GSM and WCDMA radio access technologies in Integrating SBTS to NetAct
• Configuring GSM and WCDMA radio access technologies in Integrating SBTS to NetAct
The Integrating SBTS to NetAct document is available once respective NetAct fast pass Service Pack-
age is installed.
Note: Administration of Measurements for GSM is performed on the BSC level, that is to
say, you administrate all the BCFs under a BSC, and not only the BCF that is related to the
SBTS.
HW object in the hardware inventory model represents the base station. Hardware inventory data in-
cludes both auto-detected units and passive units, which are manually defined in the site configuration
file.
Hardware inventory can be viewed in the NetAct Configurator user interface, and exported to up-
per-layer management systems via northbound interfaces.
The following table lists the CM adaptations for SRAN hardware inventory data:
SBTS inherits the RAT-specific states from 5G, LTE, WCDMA, and GSM, so the same principles and
functionalities are used.
RAT and cell operational states can be displayed with the following tools:
• LNBTS and LNCEL operational states are available in NetAct Monitor, NetAct Configurator and
Web Element Manager.
• NRBTS and NRCELL operational states are available in NetAct Monitor, NetAct Configurator and
Web Element Manager.
• WBTS operational state is SBTS internal information. WCEL operational state is available in RNC
MMLs and NetAct Configurator.
• BCF, BTS, TRX, and timeslot operational states are available only in BSC MMLs.
RAT and cell administrative states can be displayed and managed with the following tools:
• LNCEL administrative state is managed in NetAct Monitor, NetAct Configurator and Web Element
Manager.
• NRCELL administrative state is managed in NetAct Monitor, NetAct Configurator and Web Ele-
ment Manager.
• WCEL administrative state is managed in NetAct Monitor, NetAct Configurator, RNC MML, and
OMS Element Manager.
• BCF, BTS, and TRX administrative state is managed in NetAct Monitor, NetAct Configurator, and
BSC MML.
If a parameter modification requires object locking, an automatic lock/unlock is triggered if the respec-
tive technology supports it.
SBTS supports the restart of the whole base station and the restart of one technology only.
• SBTS restart can be triggered with Web Element Manager and NetAct Configurator.
• LTE RAT (LNBTS) and LNCEL restart can be triggered from NetAct Monitor, NetAct Configurator,
and Web Element Manager.
• WCDMA RAT (WBTS) restart can be triggered from NetAct Monitor, RNC MML, OMS Element
Manager, and Web Element Manager.
• GSM RAT (BCF) restart can be triggered from NetAct Configurator, BSC MMLs, and Web Element
Manager.
• 5G RAT (NRBTS) and NRCELL restart can be triggered from NetAct Monitor, NetAct Configurator,
and Web Element Manager.
The modification of the BTS restart needed parameters in SBTS triggers an automatic restart in
the base station. Depending on the SBTS parameter, the restart can be limited to the impacted RAT
(LTE, 5G, WCDMA, GSM), or the whole base station is restarted (common site configuration, transport
Alarm status and Unknown status are determined by NetAct internally based on alarm information.
• SBTS, LNBTS, and LNCEL, NRBTS, NRCELL Unknown status is based on the NetAct connectivi-
ty to SBTS.
• WBTS and WCEL Unknown status is based on the NetAct connectivity to RNC.
• BCF and BTS Unknown status is based on the NetAct connectivity to BSC.
Blocking state is only managed via Web Element Manager. It is possible to block and unblock SBTS,
RAT (NRBTS, LNBTS, WNBTS, GNBTS), and a cell.
The existing license management concepts for 5G, LTE, RNC, and BSC are still valid for controlling
the feature and capacity usage in SBTS. RNC and BSC licenses need to be activated with License
Manager. BSC also controls GSM capacity and base station optional features as before. LTE and 5G
uses measurement-based monitoring by Software Asset Monitoring.
The new SBTS license mechanism protects cross-technology SBTSs and premium and hardware acti-
vation features (for example a feature configured for more cells than allowed). The file-based WCDMA
BTS license management is replaced with the SBTS license concept.
In the new license mechanism, the license files are not downloaded to the base station, but stored in
NetAct Centralized License Server. When new optional functionality or licensed capacity is configured
in SBTS, NetAct Software Entitlement Manager (SWEM) reports the feature usage and reserves the
capacity from the license pool in CLS.
For more information on monitoring-based license management and Single RAN licenses, see Moni-
toring based license management in Software Asset Monitoring.
From NetAct 22 release onwards, NetAct Radio SRAN Standard SW license (feature code: 17753) is
discontinued. SBTS integration requires license based on SBTS RAT configuration.
The following table lists the required NetAct Radio Standard SW license for each RAT configuration:
To find RAT-specific performance management objects and measurements you can also use the Note
field for advanced search (5G objects, measurements counters and GSM counters are not supported),
WCDMA and LTE counters are supported. By entering a Single RAN release in the Note field, for ex-
ample SBTS17A, you get the RAT-specific data of the selected adaptation which is also relevant for
SRAN17A. You can use the same method when searching Object Information Browser Excels in Sup-
port portal in [Link] Accessing the documentation and software in the portal re-
quires authentication.
The table below shows how to search for Single RAN related data in Object Information Browser.
SBTS
Objects PM: Nokia Single RAN base PM and CM: • PM: PM: Nokia
station MRBTS (com. Nokia LTE Nokia Base Sta-
Nokia AirS-
[Link]) Base Station Radio tion Controller
cale BTS 5G
(NOKLTE). Network (NOKBSC)
([Link]. • Nokia LTE/SRAN
Note: the re- Con-
nrbts). BTS management CM:
lease should troller
layer ([Link].
Note: the re- start with Nokia Base
[Link]) (NOKRNC)
lease should "SBTS". Station Con-
• Nokia LTE/SRAN • Nokia
start with troller (NOK-
BTS equipment mcRNC
"SBTS" BSC)
([Link]. (com.
CM: nsn. AirScale BSC
eqm)
mcrnc) ([Link].
Nokia New • Nokia LTE/SRAN
asbsc)
Radio Base BTS runtime equip- CM:
Station (com. ment ([Link]. CM adapta-
Nokia Ra-
[Link]. [Link]) tion for Nokia
dio Network
nrbts) • Nokia SRAN BTS SRAN BTS
Controller
transport layer (com. GSM config-
(NOKRNC)
[Link]) uration (com.
SBTS
Nokia [Link].
ncRNC gsm)
([Link].
mcrnc)
AirScale
RNC (com.
[Link])
CM adapta-
tion for Nokia
SRAN BTS
WCDMA
configuration
([Link].
[Link])
Measure- Nokia AirS- Nokia Single RAN base Nokia LTE Nokia Ra- Nokia Base
ments and cale BTS 5G station MRBTS (nokmrn) Base Sta- dio Network Station Con-
counters (nokgnb) tion (noklte). Controller troller (nokb-
Note: the re- (nokrww) sc)
Note: the re-
lease should
lease should
start with
start with
"SBTS".
"SBTS"
Alarms Nokia AirS- Nokia Single RAN base Nokia LTE Nokia Sin- Nokia Single
cale BTS 5G station MRBTS (com. Base Station gle RAN RAN Base
([Link]. [Link]) (NOKLTE). Base Sta- Station (NOK-
nrbts) Note: the re- tion (NOK- BCF). Note:
lease should WBTS) Note: the release
Note: the re-
start with the release should start
lease should
"SBTS". should start with "SBTS".
start with
with "SBTS".
"SBTS"
SBTS
• CM adaptation for
Nokia Single RAN
BTS inventory unit
data ([Link].
[Link])
• CM adaptation for
Nokia Single RAN
base station 3GPP
hardware invento-
ry ([Link].
hw)
Besides a standard compatible web browser application, Web Element Manager does not require any
additional software installation for the used terminal (for example laptop). SBTS software provides the
web server functionalities for the element manager. When connected to the web server in SBTS, the
browser uploads all the necessary data for the element manager.
Web Element Manager also provides offline functionality: an HTML file can be saved during an active
session to a BTS, and then opened in offline mode in a web browser. The local management terminal
needs to be physically connected to an Ethernet connector in the SBTS system module. Also a remote
connection through the O&M DCN is possible. NetAct integrates Web Element Manager into NetAct’s
own management views and task flows for remote use.
While the existing BTS Site Manager is no longer used for SBTS, it still has a role in the manual com-
missioning of the SBTS. This is because the FSMF factory delivery software is based on the BTS soft-
ware architecture, and it does not have the web server for the SRAN element managers.
The snapshot collection is triggered from Configurator. When the snapshot collection is completed at
the SBTS, the snapshot is automatically uploaded, and saved to the NetAct file system.
In Trace Viewer it is possible to use the LTE user tracing functionality (subscriber, equipment, and cell)
for SBTS.
LDAP is pivotal in the authentication and authorization processes for SBTS, as it manages the remote user authentication, ensuring the NE3S operation's integrity. Its implementation parallels that of WCDMA and LTE, providing a unified security framework across technologies, ensuring seamless user management and access control .
Fault management in SBTS impacts network operation significantly; alarms are categorized based on their effect on common objects or radio access technologies. This categorization helps network operators focus on critical failures. Alarm correlation further enhances management by grouping related alarms, improving response efficiency, and reducing false positives, ensuring smooth network operation .
NetAct supports two strategies for mass provisioning of SBTS plans: 'Best effort', where only successfully validated configurations are activated, and 'Best consistency', where activation happens only if all configurations are successfully validated. The 'Best consistency' method ensures full network synchronization, reducing discrepancies, while 'Best effort' permits partial activations that can quickly address urgent needs but may lead to inconsistencies .
Alarm status and unknown statuses for SBTS and network elements like LNBTS, NRBTS, and WBTS are determined by NetAct’s connectivity to these elements. Unknown status indicates a loss of connectivity or data reception, signaling potential underlying issues that warrant immediate attention. This mechanism helps maintain high levels of operational reliability and quickly identifies dysfunctions .
The NE3S interface is critical for centralized management of SBTS, providing M-plane interface which supports configuration, software, fault, performance, and license management. It ensures remote user and operation authentication and authorization, maintaining the operational integrity of SBTS configurations .
The Network Segregation feature, when enabled, dictates specific firewall rules for BTSMED operations. It necessitates ensuring that only vetted public IPs interact with NetAct nodes, thus tightening security. This feature is particularly relevant for maintaining strict operational boundaries, enhancing overall system security, and preventing unauthorized access .
The BTS Conversion Service can be integrated into NetAct to facilitate the migration of existing BTS configuration data to SBTS plans efficiently. It utilizes existing configurations to help form new SBTS release plans, ensuring consistency and reducing configuration errors, particularly useful in rebuilding scenarios .
The process of removing the BTS Mediator involves several key steps: first, the removal of BTSMED software packages from the Software Manager; next, the deletion of configuration management data and managed objects; then, the removal of the IP address from a white-list if applicable; followed by removing DNS entries and firewall rules related to BTSMED. Each step requires careful execution to ensure no element is in use before removal .
SBTS software packages are managed through NetAct Software Manager, Web Element Manager, and Rescue Console. The process allows for activation on top of WCDMA and LTE software via OMS/RNC for migration purposes, ensuring compatibility across different radio access technologies. The comprehensive management approach supports software for LTE, 5G, WCDMA, and GSM, enabling seamless network operation across various technologies .
BTS Mediator primarily supports software updates of BTSs by acting as an intermediary that requests updates from the NetAct Software Manager, even in the pre-commissioned state. It also manages security by mediating certification and user management operations between NetAct and SBTSs .