How do I troubleshoot T-BTS management?

T-BTS components in Object Troubleshooting

You can perform troubleshooting of T-BTS using Object Troubleshooting by selecting Radio Plane as the Target Type. See Viewing a radio plane in Object Troubleshooting. See the NSP Network and Service Assurance Guide for more information about using Object Troubleshooting.

T-BTS alarm mapping

The names of some T-BTS alarms in NSP differ from their versions in NetAct/MantaRay NM, MRBTS, and NIDD.

Specific problem ID

MRBTS alarm name

NSP alarmName

7658

BASE STATION LICENSE LIMITATION

BaseStationLicenseLimitation2

61029

LOS on $UNIT, $INTERFACE

LossOfSignal

61050

Missing SFP module on $UNIT, $INTERFACE

MissingOrNonCompliantSfpModule

61410

CCM fault level $LEVEL, prio $PRIORITY, cause $CAUSE

CcmFault

61607

Auto-negotiation mismatch on $UNIT, $INTERFACE

AutoNegotiationMismatch

61632

Dup Addr detected-$DUPLICATEIPV6ADDRESS

DupIpV6AddrDetected

61641

IP Traffic Capturing ongoing $UNIT, $INTERFACE, $MACADDRESS

IpTrafficCapturingOngoing

Backend logging

SRT backend logs are viewable using NSP LogViewer. Logging levels can be configured by Nokia support using the kubectl -n nsp-psa-restricted edit cm srt-ran-services-app-logback command.

Simplified RAN Transport in Grafana

The Grafana logging application features dedicated SRT metrics that can be found by searching for “Simplified RAN Transport”. See the NSP System Administrator Guide for more information about using the Grafana dashboard.

How do I force SRT to recompute binding states?

For SMR topologies that do not have real-time binding state computation, you can force SRT to recompute all BTS radio plane binding states using one of the following methods:

Note: This operation can take several minutes (up to 15 minutes for 5000 BTS) depending on the amount of managed MRBTS. While the operation is running, radio plane binding states are not displayed accurately.

Parsing error case 1: missing T-BTS parameter

In this error case, the T-BTS is missing a mandatory parameter. The following occurs:

Note that the MO id parameter is mandatory only in T-BTS Yang model v1.

The logs for a resync failure can be viewed in MdmServer.log. The following is an example:

<2021.06.30 12:43:13 811 +0000><mdm><E><mdm-server-0><ResyncPollerTaskExecutor[3]><com.nokia.nsp.mdm.core.sbi.resync.imp.ResyncConsumer.failed> Full resync failed for node=10.0.3.238, detailStatus=null
java.lang.RuntimeException: com.fasterxml.jackson.databind.JsonMappingException: N/A
 at [Source: (ByteArrayInputStream); line: 1, column: 6618] (through reference chain: com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.read.DescendantMoLitesResponse["moLites"]->java.util.HashMap["PLMN-PLMN/MRBTS-1000"]->java.util.ArrayList[46]->com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.common.MoLite["moId"])
        at io.reactivex.internal.util.ExceptionHelper.wrapOrThrow(ExceptionHelper.java:45)
<2021.06.30 12:43:13 778 +0000><mdm><I><mdm-server-0><ResyncPollerTaskExecutor[13]><com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.read.ReadHelper.queryAllObjectsFDNAsString> queryAll: Perform Rest Request POST /persistency/v1/descendantMOLites
<2021.06.30 12:43:13 768 +0000><mdm><E><mdm-server-0><pool-15-thread-2><com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.read.ReadHelper.getObjectsFDN> Could not read descendantMoLites
Parsing error case 2: T-BTS parameter type not compliant with NSP Yang model

In this case, a parameter has been set as a string when an integer is required. The following occurs:

The logs for a resync failure can be viewed in MdmServer.log. The following is an example:

2021.06.29 07:29:59 041 +0000><mdm><E><mdm-server-0><ResyncPollerTaskExecutor[13]><com.nokia.nsp.mdm.core.sbi.resync.imp.ResyncConsumer.failed> Full resync failed for node=10.0.3.243, detailStatus=null
java.lang.NumberFormatException: For input string: "Test"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65
REST error case 1: NetAct/MantaRay NM is unreachable on T-BTS configuration resynchronization

NetAct/MantaRay NM is unreachable and the error is logged in MdmServer.log. The following is an example:

<mdm><E><mdm-server-0><ResyncPollerTaskExecutor[37]><com.nokia.nsp.mdm.core.sbi.resync.imp.ResyncConsumer.failed> Partial resync failed for node=10.0.3.243, detailStatus=null, class="nokia-tbts-v1-model":/MRBTS/TNLSVC/TNL/ETHAPP/LLDP
java.lang.RuntimeException: org.apache.http.conn.HttpHostConnectException: Connect to 10.11.210.158:8001 [/10.11.210.158] failed: Connection refused (Connection refused)
    at io.reactivex.internal.util.ExceptionHelper.wrapOrThrow(ExceptionHelper.java:45)
    at io.reactivex.internal.observers.BlockingMultiObserver.blockingGet(BlockingMultiObserver.java:91)
    at io.reactivex.Single.blockingGet(Single.java:2157)
REST error case 2: Body is not compliant with REST format

There is a syntax error in the REST body. For example, there is a missing “}” and the structure is invalid. The error is logged in MdmServer.log. The following is an example:

<mdm><E><mdm-server-0><ResyncPollerTaskExecutor[38]><com.nokia.nsp.mdm.core.sbi.imp.AsynResync.doResync> Partial aInCurrent=com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.read.ReadAdaptation@535e9f6e,aInMetaDevicePojo=MetaDevicePojo{classId='nokia-tbts-v1-model:/MRBTS/TNLSVC/TNL/ETHAPP/LLDP', sbiProtocol=rest, priority=21, alwaysReadFromNetwork=false, resyncType=getQuery, isGenericPojo=true, iDevicePojoBuilder=null, FilterNode=null}
java.lang.RuntimeException: com.fasterxml.jackson.core.JsonParseException: Unexpected close marker '}': expected ']' (for root starting at [Source: (ByteArrayInputStream); line: 1, column: 0])
at [Source: (ByteArrayInputStream); line: 1, column: 2]
at io.reactivex.internal.util.ExceptionHelper.wrapOrThrow(ExceptionHelper.java:45)
at io.reactivex.internal.observers.BlockingMultiObserver.blockingGet(BlockingMultiObserver.java:91)
at io.reactivex.Single.blockingGet(Single.java:2157)
at com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.read.ReadHelper.readLLDP(ReadHelper.java:254)
at com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.read.ReadHelper.read(ReadHelper.java:178)
at com.nokia.nsp.mdm.device.mrbts.model.impl.rest.adaptation.read.ReadAdaptation.read(ReadAdaptation.java:71)
Modifications of T-BTS L2 backhaul services do not appear in Service Management

Workaround: Run a RESTCONF POST request using the stitchservices command to perform a service stitching operation for the affected T-BTS sites:

POST /restconf/data/nsp-service-intent:stitchservices

The following input is required:

Note: Manual service stitching cannot be performed when automatic service stitching is enabled.

Updated BTS transport configuration does not appear in Radio Plane Bindings

Workaround: Verify that NetAct/MantaRay NM reachability = Reachable in Device Management, if not then see NetAct/MantaRay NM and BTS reachability is Partially reachable or Unreachable, ReachabilityProblem alarm on NetAct/MantaRay NM. Upload MRBTS configuration in NetAct/MantaRay NM then launch a resynchronization of the BTS from Device Management. See the NSP Device Management Guide for more information.

Updated BTS alarms do not appear in NSP

MRBTS alarms may not be properly updated in NSP (alarm views, Radio Plane Bindings table).

Workaround: Verify that NetAct/MantaRay NM reachability = Reachable in Device Management, if not then see NetAct/MantaRay NM and BTS reachability is Partially reachable or Unreachable, ReachabilityProblem alarm on NetAct/MantaRay NM. Launch a resync of the NetAct/MantaRay NM server acting as NE controller for this BTS from Device Management.

MRBTS is unreachable

NSP is not aware when MRBTS are unreachable from NetAct/MantaRay NM. In this case, BTS resynchronizations launched from Device Management will show as successful, but any radio plane bindings will fail.

NetAct/MantaRay NM ResyncStatus = failed or PollerProblem alarm on NetAct/MantaRay NM

When NSP is unable to successfully complete a BTS alarm resynchronization, NSP will:

Workaround: If the problem is not automatically resolved by NSP (2 failed retries), you must resolve the issue by manually launching a resynchronization of the NetAct/MantaRay NM server acting as NEcontroller using Device Management.

NetAct/MantaRay NM and BTS reachability is Partially reachable or Unreachable, ReachabilityProblem alarm on NetAct/MantaRay NM

When NSP detects a loss of communication with NetAct/MantaRay NM on SNMP reachability policy:

When NSP detects a loss of communication with NetAct/MantaRay NM on ping (=REST) reachability policy:

When NSP detects a loss of communication with NetAct/MantaRay NM on SNMP and ping (=REST) reachability policies:

Workaround: Resolve SNMP and/or REST communication issues with NetAct/MantaRay NM. See the NSP Nokia TBTS Adaptor Guide for information about configuring the SNMP interface, integrating NSP and NetAct/MantaRay NM, and discovering NetAct/MantaRay NM and the T-BTS.

When NSP detects that communication is restored with NetAct/MantaRay NM on SNMP and ping (=REST) reachability policies:

Updated BTS software version or chassis type does not appear in Device Management

The MRBTS productVariant parameter value is displayed as chassis type in Device Management. Updating the software version or the productVariant in the BTS configuration is not reflected in Device Management, even after performing a resync of the BTS.

Workaround: Unmanage and rediscover the BTS from Device Management, or check updated values in equipment inventory.

Modifications of T-BTS L2 backhaul endpoints do not appear in Service Management or Network Map

Workaround: Run the following RESTCONF command to trigger a resync:

POST /restconf/operations/nsp-admin-resync:trigger-resync

{"nsp-admin-resync:input":{
    "plugin-id":"mdm",
    "network-element": [{
        "ne-id":" bts-ip ",
        "sbi-classes":[{
            "class-id":"nsd-service-l2backhaul:/l2backhaul-sites/site"
        }]
    }]
}
}

where bts-ip is the T-BTS site ID.