Product Description
nanoBTS Product Description Software Specification
© ip.access Ltd Page 36
The BTS does not immediately use the new Primary OML or Secondary OML
Configuration if a connection has already been established. It shall use the configuration
for all new connections.
The BTS does not immediately action receipt of configuration of new IP Configuration
(either from the "IP Interface Config" or "IP Gateway Config"). A reboot is always required.
The BTS immediately actions receipt of configuration of new BTS Location.
The BTS does not immediately use new Unit Id configuration (BTSid and TRXid). A reboot
is always required. For single TRX configuration, the TrxId is always be 0.
The BTS supports setting of the "Name" field.
The BTS supports the extension to the "SetBTSAttribute" message for paging
configuration. Note that the defaults are hard coded and cannot be adjusted in NV
configuration.
The BTS supports the Set Alarm Thresholds with the behaviour as defined in the ip.access
Abis Over IP specification. Note that the behaviour depends on the NVConfig flag F8
("SetAlarmThresholds").
The BTS supports the "Perform test" message for starting NWL tests according to the
ip.access Abis Over IP specification.
The BTS supports the "Get Attribute" message as defined in the ip.access Abis Over IP
specification and not as per GSM 12.21 V5.0.0.
The BTS supports the "Reinitialise" message.
5.14.2 RSL Signalling Messages
The BTS uses the "Measurement Pre-processing Defaults" messages for configuration of
the Measurement Pre-processing algorithm (according to the ip.access Abis Over IP
specification). The BTS should accept this message at any time and apply new defaults for
new dedicated connections. The BTS or any sub-object does not need to be locked for this
to take effect.
5.14.3 User Traffic Messages
The BTS supports RTP Traffic format as defined in the ip.access Abis Over IP
specification.
The BTS does not support the Traffic Frame Synchronisation Procedure.
5.14.4 Channel Control Messages
The BTS supports the "Heartbeat" procedure according to the ip.access Abis Over IP
specification. The BTS requires the Identity Request Message over TCP or UDP. The
BTS shall respond to a UDP message to the well-known "second omlipport" number
(3006).
Upon heartbeat failure of OML, the BTS shall try to carry on if already operating, keep
trying to reopen the connection. Messages should be discarded as required to avoid
overflow (e.g. whenever connect returns a failure, discard any queue and immediately
retry, if too many things queue whilst awaiting connection, discard as required).
Upon heartbeat failure of RSL, the BTS shall disable the relevant TRX, dropping calls and
clearing up as required, (it should act as if locked and then immediately unlocked again).