Explore Cisco
How to Buy

Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco RAN Management System Administration Guide, Release 5.1

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco RAN Management System Administration Guide, Release 5.1

Chapter Title

Cisco RAN Management System Overview

Results

Updated:
July 6, 2017

Chapter: Cisco RAN Management System Overview

Cisco RAN Management System Overview

This chapter provides a functional overview of the Small Cell Solution (SCS), Cisco RAN Management System (RMS), and explains how to use it to manage your network.

Cisco RMS Solution Overview

The Cisco RAN Management System provides different workflows and services to support enhanced provisioning and managing capabilities for both, 3G and LTE Femtocells. These services include provisioning and management functions such as, device configuration, status monitoring, firmware upgrade, data retrieval, and troubleshooting.

The following are a few key functionalities of the Cisco RMS solution:

  • Device activation and configuration
  • Software upgrade and status monitoring of devices
  • Performance monitoring through Key Performance Indicator (KPI) data uploaded by devices
  • Enhanced access to the device alarm data
  • Troubleshooting of devices
  • Remote Authentication Dial In User Service (RADIUS) for device authorization on Home NodeB Gateway (HNB-GW) including per device whitelist support
  • Dynamic Host Configuration Protocol (DHCP) service for allocating IPSec addresses

The Small Cell RMS solution integrates with the Cisco Broadband Access Center (BAC) for Telecom and Wireless, as well as the Cisco ASR 5000 Gateway that plays the HNB-GW and Security Gateway (SeGW) roles.

Cisco RMS Solution Components

The Cisco RMS solution comprises of the following components that provide end-to-support in provisioning, managing, and maintaining the Femtocell access points (FAPs or APs, used interchangeably in this guide):

Provisioning Management Gateway

The Provisioning Management Gateway (PMG) provides a programmatic integration interface, Northbound interface (NBI) API, to the service provider Operating Support Systems (OSS) or Business Support Systems (BSS) for provisioning and managing access points (APs).

The PMG supports the following functions:

  • Integration of API with OSS / BSS to enable:
    • Subscriber portal to communicate with the PMG to perform a device registration, update the whitelist, and so on.
    • Mobile systems to compute and configure SAI, e911 location data on the FAP.
    • Care interface to access live data. For example, admin status, operator status, and so on.
  • Provision of XML/HTTP API for requests and notifications
  • Generation of KPIs (which PMG generates) in CSV (format) for PM files
  • Installation on Cisco UCS x86 hardware with RedHat Linux OS
  • Implementation of critical algorithm that automatically assigns:
    • AP
    • Regional SeGW, HNB-GW
    • Unique SAI
    • Unique Cell ID (so that Femtocell can be optimized or work efficiently)
    • RF and Management Groups
  • Facilitation of Whitelist management: it interfaces with the HNB GW like RADIUS interface apart from interacting with the BAC so that it can directly update the IMSI to the HNB GW.
  • Facilitation of Plan-Activate Flow; this enables the operator to register the AP separately, activate separately, or group the registration and activation.

PMG provides the following interfaces for provisioning and CSR requests, and notifications:

  • Provisioning Requests
    • Register
    • Activate / Deactivate
    • Update
    • Update IMSI
    • Block / Unblock
    • Shutdown
    • Delete and so on
  • CSR Requests
    • Get Stored Data
    • Get Live Data
    • Reboot
    • Reset to Defaults
  • Notifications (from PMG to the SP OSS or subscriber)
    • Assigned Data
    • Location Status
    • Service Operational
    • Service Error
    • IP Address Update
    • User Password Expiry Notification
    • Group Update
    • Group Delete
    • Group Create

The PMG workflow facilitates zero-touch activation flows by integrating with the Broadband Access Center (BAC). On Femtocell registration, PMG communicates with BAC to assign unique RF parameters. For example, PMG can assign a unique SAI for the Femtocell and PMG can set this data on the Femtocell via BAC as well as notify the SP OSS about the assignment.

PMG selects the appropriate provisioning, SeGW and HNB-GW/HeNB-GW nodes for the Femtocell and determine location-specific RF scan configuration for the Femtocell. This location-groups data is provided to the BAC, which instructs the Femtocell to perform a radio scan on specific bands and frequencies that are relevant in the area. After completing the radio scan and location check, BAC can notify PMG, which can, in turn, notify SP OSS.

The PMG is usually co-located with BAC on the same HW node.

Broadband Access Center

The Broadband Access Center (BAC) is a versatile TR-069 (support TR-169, v1 and v2) management system that provides all essential Femtocell management functions whether it is AP configuration, firmware, data retrieval (like get parameter value), troubleshooting (logs), and so on.

BAC supports the following functions:

  • Maintenance of AP inventory in the RDU
  • Implementation of policy-based configuration and firmware (FW) for APs— When the AP is contacting the BAC for the first time, BAC pushes a specific configuration. When the AP contacts the BAC subsequently, it pushes specific parameters, when the device is sending Network Listen (NWL) scan.
  • Implementation of TR-069 standards. BAC also implements download service.
  • Implementation of Femtocell activation logic, which is on the Device Provisioning Engine (DPE). PMG does not play any role on the Femtocell activation logic, although PMG provides the configuration values as part of the registration to the BAC. Therefore it is BAC that pushes all the information to the FAP as part of the provisioning flow.
  • Implementation of Oracle Berkeley database to store all the AP database information.
  • Installation on Cisco UCS x86 hardware with Red Hat Linux OS.

Cisco RMS uses BAC as the TR-069 Auto Configuration Server (ACS), which contains the Regional Data Unit (RDU) and DPE. The RDU is a central database of registration and RF data. The DPE provides TLS secured TR-069 services and HTTPS download service for firmware and other files (e.g. AGPS). The TR-069 extensions in DPE perform small cell activation flows including location verification.

In a small deployment, RDU and DPE servers can be deployed on the same hardware node.

For more information about the DPE, see Device Provisioning Engine.

For more information about the RDU, see Regional Data Unit.

Device Provisioning Engine

The DPE is part of Cisco Broadband Access Center (BAC). It acts as a Auto Configuration Server (ACS). It provides essential functionality for remote management of APs, such as discovery, registration, activation, configuration, live operations (get live data, factory reset, etc), service shutdown, and HTTPs download support.

There are two kinds of DPEs: start-up DPE and home DPE. The ACS URL of the start-up DPEs is stored in the AP by the CloudBase. When it starts up for the first time, the AP contacts the start-up DPE. This DPE then redirects the AP to the home DPE based on geographical location of the AP. On subsequent reboot, the AP directly contacts the home DPE. The home DPE pushes new software/firmware, configuration, and performs location check.

Regional Data Unit

The RDU is also part of Cisco Broadband Access Center. It is the central part of the RMS and has a persistent database. It stores the information related to 3G/4G AP parameters such as: expected software/firmware image, expected location, network listen status, PLMN, LAC, SAC, Cell, CSG, RNC ID, SeGW, HNB-GW, and HeNB-GW IP address, and network listen information.

The RDU receives all this data from the DCC UI, Ops Tools, and IT portal via the PMG (Provisioning and Management Gateway). The RDU provides this data to the startup and home DPEs, on request. The DPE and RDU are distributed in the network.

Device Command and Control

The Device Command and Control (DCC) provides the following UI and CLI tools that can be used to manage Cisco RMS and devices for device activation, administration, and troubleshooting.

DCC UI

The DCC UI provides the framework within which all the user interface applications reside. The following application solutions are provided within the DCC UI:

  • Enhanced Groups & IDs Management—Provides the ability to manage, edit, import, and export group types and instances and ID pool types and instances.

  • Device Manager—Provides device management capabilities based on user permissions (Read only / Read & Write / Read & Write Advanced).

Ops Tools

The Ops Tools are a set of CLIs that enables the following functions:

  • Bulk Small Cell registration (example, connection requests, reboots)

  • Device searches (based on group, etc)

  • Device data retrieval

  • Device property setting

  • Re-balance of group and ID assignments

  • BFST

  • GPS Data Export

  • Factory restore

In addition, the Ops Tools can be used in a workflow to perform group operations such as upgrades or moving devices from default provisioning groups.

Prime Access Registrar

The Prime Access Registrar (PAR) is used for authentication, authorization, and accounting (AAA). It provides AP authentication on the HNB-GW and delivers AP whitelists to HNB-GW via RADIUS.

Prime Network Registrar

The Prime Network Registrar (PNR) is a DHCP server that is used to allocate IPSec addresses for SeGW via DHCP. The lease database can then be queried to discover the current IP address of an AP.

Upload Server

The Upload Server (ULS) provides a high scale service for receiving and processing file uploads from the Femtocells. All the logs from the FAP are uploaded to the Upload Server.

The Upload Server supports the following functionality:

  • Supports only HTTPS.

  • Uploads AP system logs, PM file uploads, and performance data.

  • Bundles files for distribution to the SP OSS.

  • Exposes the HTTP and SFTP interface towards the SP OSS.

  • Manages uploaded files by saving, archiving, and purging them based on the configured thresholds.

  • Provides detailed KPIs in the CSV PM files.

  • Runs on UCS x86 on the Red Hat Linux.

  • Accepts logs uploaded by APs and stores it on the disk.

  • Provides access to uploaded logs on the server via access-restricted HTTP.

  • Keeps the original uploaded log files in the upload partition.

  • Creates simultaneously a compressed version of the same log file and keeps it in the archived partition

  • Reports average and peak load (uploads/hour) for every hour in the daily and weekly PM log files.

  • Causes the watchdog process to automatically restart the Log Upload service if it goes down for any reason.

  • Configures Log Upload service to automatically start when the OS boot ups.

Upload Server Directory Maintenance

  • Writes files in raw and compressed format in /opt/CSCOuls/files/uploads and /opt/CSCOuls/files/archives directory respectively as they are uploaded.

  • For raw partition,

    • Periodically (default 1 hr.) purges files uploaded within the last interval.

      The periodicity and interval is defined by [UploadServer.server.filemanager.taskscheduler.raw.dirmaint.interval.minutes] property. For example, If the above property is set to 1 hr. the Upload Sever purges the files every one hour, uploaded within last the one hour interval , thereby keeping files uploaded within the running hour, intact.

  • For archives partition,

    • ULS checks periodically (defined by UploadServer.server.filemanager.taskscheduler.archive.dirmaint.interval.minutes property) the disk utilization against the threshold value (defined by UploadServer.files.upload.<file_type>.disk.alloc.upload.archives.thresh.pct property ).

    • If the disk utilization for a particular file type is above the threshold, the oldest files in the archive directory of size equal to percentage (defined by UploadServer.files.upload.<file_type>.pctoftotaldiskspacetofree property) plus the difference between the current percent disk utilization and threshold percentage are deleted.


Note
The above properties can be found in Upload Server in the /opt/CSCOuls/conf/UploadServer.properties file.
Upload Server Southbound Interface

The Upload Server Southbound interface (SBI) is used to upload the AP log files. It listens on port 443 (HTTPS).

Uploads received by the Upload Server are buffered in memory until written to the disk. When the rate of incoming data exceeds the rate that ULS can process, the server no longer accepts new uploads and responds to new upload requests with a standard HTTP response code 503, for service not available.

ULS sorts uploaded files based on filename patterns into stat and on-demand folders. The files that do not match any of the two patterns go into an unknown directory.

ULS creates the subdirectories based on the timestamp in the filename and keeps the archive files there. This is applicable only for archive files to avoid too many files in a single directory. The date regex pattern to extract date from filename is configurable in the properties file. If the timestamp in filename does not match with the configured pattern then it keeps the file in the parent directory and not in the date-wise subdirectories. For example, the upload file has the following URLs:

<IP>:8080/area1/A20140801.0442+0400-0442+0400_-110_001B67-357539019562681.xml

<IP>:8080/A20140801.0442+0400-0442+0400_-110_001B67-357539019562681.xml

Therefore it creates the following directory structure under the archive directory and places the file under the date-wise subdirectory: 

/stat
  |-area1
  |    |-20140801
  |
  |-20140801
Logs

  • The Upload Server provides information on the average and peak loads (uploads/hour) for every hour in the daily PM log files. The file-naming convention for these daily PM files is as follows: upload-perf-periodic-YYYY-MM-DD.csv

  • In addition, every seven days, a weekly PM file is rolled up and zipped up from the most recent, seven daily PM files in the /opt/CSCOuls/server-perf-archives directory

Upload Server Northbound Interface

The Upload Server Northbound interface (NBI) is used to extract the AP log files for analysis and report generation. Such applications can extract the PM/Stat or on-demand files over the Northbound interface. The default port used is 8082.

For security, digest authentication mechanism is used. The default username/passwords are as follows:

File Type

Username

Password

PM/stat files

statadmin

Value of RMS_App_Password

Property defined in OVA descriptor

(default Rmsuser@1)

PED/on-demand files

demandadmin

Value of RMS_App_Password

Property defined in OVA descriptor

(default Rmsuser@1)

Unknown files

unknownadmin

Value of RMS_App_Password

Property defined in OVA descriptor

(default Rmsuser@1)

Important configurations and their meanings in Upload Server:

Property Name

Type

Description

Change Affective

config.scantimems

Integer

Indicates time, in milliseconds, between checking if the configuration file has changed. If changed, the configuration is reloaded. Default is 50000 (50 seconds).

Configuration reload and next configuration lookup

UploadServer.config.bool

Boolean

Indicates the setting to enable checking the configuration file for changes periodically. Default is true.

Configuration reload and next configuration lookup

UploadServer.disk.alloc.global.maxgb

Integer

Sets a maximum for the total number of gigabytes to be used. If this value exceeds the total number of gigabytes available, the total number of gigabytes for the partition is used. The value to be set is the maximum of the number of gigabytes for the upload and archive partition. Default is 500.

Configuration reload and next configuration lookup

UploadServer.disk.alloc.global.threshold.info

Integer

Defines the percentage at which the watchdog process logs an informational message regarding the level at which the server disk space is full. Default is 70.

Configuration reload and next configuration lookup

UploadServer.disk.alloc.global.threshold.warning

Integer

Defines the percentage at which the watchdog process logs a warning message regarding the level at which the server disk space is full. Default is 80.

Configuration reload and next configuration lookup

UploadServer.disk.alloc.global.threshold.critical

Integer

Defines the percentage at which the watchdog process logs a critical message regarding the level at which the server disk space is full. Default is 90.

Configuration reload and next configuration lookup

UploadServer.files.homedir

String

Indicates the "Root" directory for all Upload Server files (absolute path). Default /opt/CSCOlog/files.

Restart

UploadServer.files.upload.stat.deviceid.pattern

String

Indicates the regular expression pattern used to extract the DeviceID from the filename for stat file type.

Default [0-9A-F]{6}-[0-9A-Z]{1,64}

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.deviceid.pattern

String

Indicates the regular expression pattern used to extract the DeviceID from the filename for demand file type.

Default [0-9A-F]{6}-[0-9A-Z]{1,64}

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.archive.delete.threshexceeded

Boolean

Indicates whether or not the archive files of the stat file should be deleted when the disk space threshold is exceeded (UploadServer.files.upload.<fileType>.disk.alloc.upload.archives.thresh.pct). Default is true.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.archive.delete.threshexceeded

Boolean

Indicates whether or not the archive files of the demand file type should be deleted when the disk space threshold is exceeded (UploadServer.files.upload.demand.disk.alloc.upload.archives.thresh.pct). Default is true.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.archive.delete.threshexceeded

Boolean

Indicates whether or not the archive files of the unknown file type should be deleted when the disk space threshold is exceeded (UploadServer.files.upload.unkown.disk.alloc.upload.archives.thresh.pct). Default is true.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.archive.path

String

Indicates the directory that contains the archived files of the stat file type (relative path from UploadServer.files.homedir). Default is archives/stat.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.archive.path

String

Indicates the directory that contains the archived files of the file type (relative path from UploadServer.files.homedir). Default is archives/on-demand.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.archive.path

String

Indicates the directory that contains the archived files of the unknown file type (relative path from UploadServer.files.homedir). Default is archives/unknown.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.archiving.compression.enabled

Boolean

Indicates whether or not the stat archived TARballs should be compressed. Default is false.

Note   

This property is deprecated and must not be set to true.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.archiving.compression.enabled

Boolean

Indicates whether or not the demand archived TARballs should be compressed. Default is false.

Note   

This property is deprecated and must not be set to true.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.archiving.compression.enabled

Boolean

Indicates whether or not the unknown archived TARballs should be compressed. Default is false.

Note   

This property is deprecated and must not be set to true.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.archiving.filename.prefix

String

Indicates the beginning of the filename that is used to verify the correct file type. Default is stat.

Note   

This property is deprecated.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.archiving.filename.prefix

String

Indicates the beginning of the filename that is used to verify the correct file type. Default is on-demand.

Note   

This property is deprecated.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.archiving.filename.prefix

String

Indicates the beginning of the filename that is used to verify the correct file type. Default is unknown.

Note   

This property is deprecated.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.archiving.filename.suffix.dateformat

String

Indicates the remainder of the filename (excluding the prefix) that can be disregarded as the prefix that is used to verify the file type. Default is yyyy-MM-dd-HH-mm-ss.

Note   

This property is deprecated.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.archiving.filename.suffix.dateformat

String

Indicates the remainder of the filename (excluding the prefix) that can be disregarded as the prefix is used to verify the file type. Default is yyyy-MM-dd-HH-mm-ss.

Note   

This property is deprecated.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.archiving.filename.suffix.dateformat

String

Indicates the remainder of the filename (excluding the prefix) that can be disregarded as the prefix is used to verify the file type. Default is yyyy-MM-dd-HH-mm-ss.

Note   

This property is deprecated.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.archiverawfiles.interval.minutes

Integer

Indicates the frequency at which the raw/uploaded files of the stat file type should be archived into zip files (in minutes). Default is 1440.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.archiverawfiles.interval.minutes

Integer

Indicates the frequency at which the raw / uploaded files of the demand file type should be archived into zip files (in minutes). Default is 1440.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.archiverawfiles.interval.minutes

Integer

Indicates the frequency at which the raw / uploaded files of the lowmem file type should be archived into zip files (in minutes). Default is 1440.

Configuration reload and next configuration lookup

Integer

Indicates the frequency at which the raw / uploaded files of the lowmem file type should be archived into zip files (in minutes). Default is 1440.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.disk.alloc.upload.archives.thresh.pct

Integer

Defines the percentage of the entire disk space allocated for archives of stat file type. Default is 60.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.disk.alloc.upload.archives.thresh.pct

Integer

Defines the percentage of the entire disk space allocated for archives of demand file type. Default is 10.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.disk.alloc.upload.archives.thresh.pct

Integer

Defines the percentage of the entire disk space allocated for archives of this file type. Default is 1.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.pctoftotaldiskspacetofree

Integer

Defines the file type-specific percentage (in addition to the difference between current utilization and threshold percentage) of the disk space to remove after the UploadServer.files.upload.stat.disk.alloc.upload.raw.thresh.pct is reached. Default is 15.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.pctoftotaldiskspacetofree

Integer

Defines the file type-specific percentage (in addition to the difference between current utilization and threshold percentage) of the disk space to remove after the UploadServer.files.upload.demand.disk.alloc.upload.raw.thresh.pct is reached. Default is 5.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.pctoftotaldiskspacetofree

Integer

Defines the file type-specific percentage (in addition to the difference between current utilization and threshold percentage) of the disk space to remove after the UploadServer.files.upload.unkown.disk.alloc.upload.raw.thresh.pct is reached. Default is 100.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.raw.delete.afterarchived

Boolean

Defines whether or not the files used to create the archives should be removed after they are zipped. Default is false.

Note   

It is recommended that this property should not be modified.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.raw.delete.afterarchived

Boolean

Defines whether or not the files used to create the archives should be removed after they are archived into TARballs. Default is false.

Note   

It is recommended that this property should not be modified.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.raw.delete.afterarchived

Boolean

Defines whether or not the files used to create the archives should be removed after they are archived into TARballs. Default is true.

Note   

It is recommended that this property should not be modified.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.raw.delete.threshexceeded

Boolean

Defines whether or not raw / uploaded files for this file type should be deleted when the threshold is exceeded (UploadServer.files.upload.stat.disk.alloc.upload.raw.thresh.pct). Default is true

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.raw.delete.threshexceeded

Boolean

Defines whether or not raw / uploaded files for this file type should be deleted when the threshold is exceeded (UploadServer.files.upload.demand.disk.alloc.upload.raw.thresh.pct). Default is true.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.raw.delete.threshexceeded

Boolean

Defines whether or not raw / uploaded files for this file type should be deleted when the threshold is exceeded (UploadServer.files.upload.unknown.disk.alloc.upload.raw.thresh.pct). Default is true.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.archiving.enabled

Boolean

Indicates whether or not archiving for stat file type is enabled. Default is true.

Note   

This property is deprecated and must not be set to true.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.archiving.enabled

Boolean

Indicates whether or not archiving for demand file type is enabled. The default is true.

Note   

This property is deprecated and must not be set to true.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.archiving.enabled

Boolean

Indicates whether or not archiving for unknown file type is enabled. Default is true.

Note   

This property is deprecated and must not be set to true.

Configuration reload and next configuration lookup

UploadServer.files.upload.stat.raw.path

String

Refers to the directory that contains the uploaded files (relative path from UploadServer.files.homedir) of the stat file type. Default is uploads/stat.

Configuration reload and next configuration lookup

UploadServer.files.upload.demand.raw.path

String

Refers to the directory that contains the uploaded files (relative path from UploadServer.files.homedir) of the demand file type. Default is uploads/on-demand.

Configuration reload and next configuration lookup

UploadServer.files.upload.unknown.raw.path

String

Refers to the directory that contains the uploaded files (relative path from UploadServer.files.homedir) of the unkown file type. Default is uploads/unknown.

Configuration reload and next configuration lookup

UploadServer.sb.interface

String

Refers to the network interface that bind on for South-bound connections. Default is 0.0.0.0.

Restart

UploadServer.sb.port

Integer

Refers to the port number that the Southbound interface is bound to. Default is 8080.

Restart

perf.summary.intervalMS

Integer

Indicates interval, in milliseconds, between summary statistics (that are for the last interval) are logged. Default is 3600000 (1 hour).

Restart

UploadServer.sb.uri.regex

String

Refers to the regex for filtering the request URI; currently it accepts everything but could be updated to exclude patterns or characters if desired in the future. Default (.*).

Restart

UploadServer.server.archive.filecount.max

Integer

Refers to the safety feature that considers the ulimit for the ciscorms user, which specifies the maximum number of open files at any given time. Default is 200000.

Note   

This property is deprecated and no longer used.

Configuration reload and next configuration lookup

UploadServer.server.filemanager.taskscheduler.archive.dirmaint.initialdelay.minutes

Integer

Defines the initial delay in the server maintaining the archive directory structure (in minutes). Default is 10.

Restart

UploadServer.server.filemanager.taskscheduler.archive.dirmaint.interval.minutes

Integer

Defines the frequency at which the server maintains the archive directory structure (in minutes). Default is 10.

Restart

UploadServer.server.filemanager.taskscheduler.raw.dirmaint.initialdelay.minutes

Integer

Defines the initial delay in the server maintaining the raw directory structure (in minutes). Default is 60.

Restart

UploadServer.server.filemanager.taskscheduler.raw.dirmaint.interval.minutes

Integer

Defines the frequency at which the server maintains the raw directory structure (in minutes). Default is 60.

Restart

UploadServer.server.filemanager.taskscheduler.poolsize

Integer

Specifies the number of threads to use for the scheduled DirectoryMonitor process. Default is 1.

Restart

UploadServer.nb.channel.maxidlems

Integer

Indicates the maximum idle time for Northbound channel in milliseconds. Default is 300000.

Restart

UploadServer.nb.interface

String

Refers to the network interface that bind on for Northbound connections. Default is 0.0.0.0.

Restart

UploadServer.nb.port

Integer

Refers to the port number that the Northbound interface is bound to. Default is 8082.

Restart

UploadServer.nb.auth.enabled

Boolean

Confirms if HTTP digest authentication (RFC 2617) is enabled (true) or not (false). If enabled, the values for UploadServer.files.upload.<FileType>.nb.auth.username and UploadServer.files.upload.<FileType>.nb.auth.password.statadmin must be specified. Only the first request for a connection is required for authentication. Default is true.

UploadServer.nb.auth.maxattempts

Integer

Configures the maximum number of failed authentication attempts on a connection before it is closed. Default is 5.

Active on next connection after configuration reload. Existing connections are not affected.

UploadServer.files.upload.demand.nb.auth.username

String

Configures the default username for HTTP digest authentication for the NBA client. Default is rmsapp.

Active on next connection after configuration reload. Existing connections are not affected.

UploadServer.files.upload.unknown.nb.auth.username

String

Configures the default username for HTTP digest authentication for the NBA client. Default is rmsapp.

Active on next connection after configuration reload. Existing connections are not affected.

UploadServer.files.upload.unknown.nb.auth.username

String

Configures the default username for HTTP digest authentication for the NBA client. Default is rmsapp.

Active on next connection after configuration reload. Existing connections are not affected.

UploadServer.files.upload.stat.nb.auth.password.username

String

Configures the valid password for HTTP digest authentication for the user identified by username. Encrypted. For example, for the user statadmin, the property would be UploadServer.files.upload.stat.nb.auth.password.statadmin. Default for user rmsapp is Onk7AeUn7vQSaiyB2GreKw== (rmsapp).

Active on next connection after configuration reload. Existing connections are not affected.

UploadServer.nb.channel.digest.realm

String

Configures the realm field as specified by RFC 2617. Default is UploadServer.

Active on next connection after configuration reload. Existing connections are not affected.

UploadServer.nb.auth.domain

String

Configures the domain field as specified by RFC 2617. Because all paths require authentication, a default of / is used. Default is /.

Active on next connection after configuration reload. Existing connections are not affected.

alarms.snmp.mhsmib.prefix

String

Configures the top level OID prefix to use. Default is 1.3.6.1.4.9.9.9999.

Configuration reload on next alarm or clear.

alarms.sb.snmp.nummanagers

Integer

Configures the number of destination SNMP managers that are configured. Default is 0.

Configuration reload on next alarm or clear.

alarms.snmp.manager.address.1

String

Refers to the prefix on which an index is added that is used to configure the IP address of a destination SNMP manager. The index must be 1 or greater and less than or equal to the number of managers. For example, alarms.snmp.manager.address.1=127.0.0.1. Default is empty.

Configuration reload on next alarm or clear.

alarms.snmp.manager.port.1

Integer

Refers to the prefix on which an index is added that is used to configure the port of a destination SNMP manager. The index must be 1 or greater and less than or equal to the number of managers. For example: alarms.snmp.manager.port.1=162. Default is 162.

Configuration reload on next alarm or clear.

alarms.snmp.manager.community.1

String

Refers to the prefix on which an index is added that is used to configure the community string of a destination SNMP manager. The index must be 1 or greater and less than or equal to the number of managers. For example: alarms.snmp.manager.community.1=public. Default is public.

Configuration reload on next alarm or clear.

alarms.snmp.manager.version.1

String

Indicates the SNMP version to use. Default is v1.

Configuration reload on next alarm or clear.

alarms.diskutilization.warning.enabled

String

Indicates whether alarm should be raised when the information disk utilization is reached. Info level depends on UploadServer.disk.alloc.global.threshold.info. Default is true.

Configuration reload and next configuration lookup.

alarms.diskutilization.info.enabled

String

Indicates whether alarm should be raised when info disk utilization is reached. Info level depends on UploadServer.disk.alloc.global.threshold.info. Default is true.

Configuration reload and next configuration lookup.

UploadServer.filetypes

String

A comma delimited string of values defining each file type supported by the server.

Restart

UploadServer.sb.limit.enabled

Boolean

Refers to the true false flag to indicate if the server should use load limiting.

Configuration reload and next configuration lookup.

UploadServer.sb.connection.limit.max

Integer

Indicates the limit on maximum number of southbound connections.

Configuration reload and next configuration lookup.

UploadServer.sb.connection.warn.threshold

Integer

Refers to the limit at which a warning is raised when the number of SB connections reach this value.

Configuration reload and next configuration lookup.

UploadServer.sb.limit.maxConcurrentUploads

Integer

Indicates the maximum number of uploaded files that can be buffered in raw format by the server. Any uploads breeching this threshold triggers a 503 response.

Configuration reload and next configuration lookup.

UploadServer.sb.limit.maxConcurrentArchiveUploads

Integer

Indicates the maximum number of uploaded files which can be buffered in the compressed format by the server. Any uploads breeching this threshold triggers a 503 response.

Configuration reload and next configuration lookup.

UploadServer.server.filemanager.taskscheduler.alarmthreshold.initialdelay.minutes

Integer

Indicates the initial delay in minutes for the alarm scheduler to wait before running.

Restart

UploadServer.server.filemanager.taskscheduler.alarmthreshold.interval.minutes

Integer

Indicates the number of minutes between each alarm threshold test.

Restart

UploadServer.server.filemanager.taskscheduler.duplicatedeviceidcleanup.initialdelay.minutes

Integer

Indicates the initial delay in minutes for the duplicate device ID cleanup process to wait before running.

Restart

UploadServer.server.filemanager.taskscheduler.duplicatedeviceidcleanup.interval.minutes

Integer

Indicates the number of minutes between each duplicate device ID cleanup process.

Restart

UploadServer.fw.coresize

Integer

Indicates the initial number of threads to use for the raw FileWriter thread pool.

Restart

UploadServer.fw.maxpool

Integer

Indicates the number of seconds to keep the raw FileWriter threads alive when idle.

Indicates the maximum number of threads the raw FileWriter thread pool uses.

Restart

UploadServer.fw.keepalive.seconds

Integer

Indicates the number of seconds to keep the raw FileWriter threads alive when idle.

Restart

UploadServer.fw.debug.sleep.milliseconds

Integer

Strictly used for debugging purposes. This value should always be zero unless there is a need to introduce a delay for each FileWriter task. Value is in milliseconds.

Restart

UploadServer.archive.fw.coresize

Integer

Indicates the initial number of threads to use for the archive FileWriter thread pool.

Restart

UploadServer.archive.fw.maxpool

Integer

Indicates the maximum number of threads the archive FileWriter thread pool uses.

Restart

UploadServer.archive.fw.keepalive.seconds

Integer

Indicates the number of seconds to keep the archive FileWriter threads alive when idle.

Restart

UploadServer.files.upload.*.filename.pattern

String

Indicates the filename pattern for each filetype. This regex is used to match a filename to a given filetype known by the server.

Restart

UploadServer.files.upload.*.postprocessor

String

Indicates the postprocessor for each filetype. Defines the name of the PostProcessor implementation to use for this filetype.

Restart

UploadServer.files.upload.*.duplicatedeviceidcleanup.enabled

Boolean

Indicates the duplicate device ID cleanup for each filetype. Defines if duplicate device ID cleanup process should be used for this filetype.

Restart

UploadServer.files.upload.unknown.enableUpload

Boolean

Restricts unknown file type uploads. Default value is true, that is, it allows unknown file uploading to the server.

Configuration reload and next configuration lookup.

Femtocell Access Point Process Flow

The following describes the life cycle of a small cell access point (AP) from procurement to service commissioning:

Procedure
    Step 1   When an AP is manufactured, there are two processes that occur:
    • The AP manufacturing information is fed into the production system (server). This includes serial number of AP, basic certificate, and so on.
    • The AP is dispatched to the Central Warehouse (factory) along with the AP manufacturing information that was fed into the production server.
    Step 2   The information from the production system is fed into the Cloudbase Activation Server (CAS), which is specific to the Ubiquisys AP. The information would include the serial number of the AP, basic certificate, service provider information, and so on.
    Step 3   Now a subscriber requests for the AP service through a retailer, customer care, or via a web interface. The subscriber provides all the information like, location, authorized user list, and other subscription details.
    Step 4   The subscription details are fed into the OSS system. OSS internally calls the Cisco RMS component to basically register the device.
    Step 5   On completion of the subscription details, a small cell (AP) is delivered to the subscriber from the Central Warehouse.
    Step 6   After the AP gets delivered, the subscriber connects the device and powers it up.
    Step 7   When the AP powers up for the first time, it goes to the CAS and downloads the appropriate image (when the information is fed into the CAS, the service provider mapping, which is the serial number meant for a specific service provider to identify the appropriate firmware to be downloaded).

    The AP activation occurs after the particular FW gets pushed to the AP.

    Step 8   RMS provisioning follows next. This is final automated, zero-touch plug and play activation that occurs. (from step 7 to 10)
    Step 9   All auto-configurations, like different parameters for RAN, RF parameter, and so on, get configured.
    Step 10   After the auto-configuration is complete, that is administration, radio access network, and operations services are up, the service is provided to the subscriber.

    Cisco RMS High-Level Provisioning Flow

    A high-level workflow of the Cisco RMS and the various components is described as follows:

    Procedure
      Step 1   To register an AP, the SP OSS calls the register message from the PMG for the parameters like, EID (entity ID or serial number of the device). The operator can provide the whitelist (if it is a closed mode support) and location information (for example, some service providers provide latitude and longitude, while other service providers may not provide the location) or associate the device with the area group based on which area it belongs to.
      Step 2   When the register message comes to the PMG, the PMG goes to the BAC and adds that device entry and updates the whitelist.
      Step 3   When the FAP is powered on for the first time, it establishes a HTTPS connection with the BAC and sends a BOOTSTRAP inform. On successfully authenticating the FAP, the BAC sends an Inform Response to the FAP.
      Step 4   After the Inform Response is done, BAC pushes the baseline configuration to the FAP. Part of the baseline configuration is the baseline parameters like NWL scan, HNB GW IP add, and scan on boot=true.
      Step 5   The FAP performs the NWL scan, and it sends that information by indicating whether the scan is completed or not.
      Step 6   When the NWL scan is completed, BAC gets the NWL data from the FAP. The NWL data is the TR-069 data model attribute that the BAC fetches from the FAP.
      Step 7   After receiving the NWL data, the BAC performs a location verification; after location verification is completed, the BAC sends the location verification status to the PMG and the SP OSS. If the OSS operator wants to activate the FAP, the operator will activate the device.

      Cisco RMS provides the following activation support:

      • At the registration stage, the operator can set the AP to activate at the end of the registration
      • Activation can be performed explicitly. That is, whenever the activation happens, the operator can perform an Admin Up to the FAP, then the FAP starts IPSec tunnel establishment with the HNB GW, authentication takes place, FAP gets the IPSec address from the CNR, then it goes basically for the HNB GW registration request; in the HNB GW Registration request, the RADIUS Access Request comes to the CAR, the CAR verifies whether i is a valid FAP or not. The CAR checks if it has the EID of the FAP, whether the proper IP address is configured, and validates it. After all checks are complete and authenticated, the FAP comes to the operational state.

      Cisco RMS Interfaces

      The following figure illustrates the various Cisco RMS interfaces and interactions.

      Figure 1. RMS Interfaces and Interactions



      Cisco RMS interacts with the various interfaces as follows:

      Service Provider OSS

      Cisco RMS exposes programmatic APIs, which use XML over HTTP, to interact with the SP OSS. Cisco RMS exposes XML schema(XSD) that the OSS uses to communicate to RMS.

      There are several APIs that are used for signatures, AP registration, and activation that the SP OSS uses to communicate with the Cisco RMS.

      Provisioning Management Gateway

      PMG is a generic provisioning and management application that provides the necessary workflow component between the Service Provider (SP) IT/OSS applications (for example, service management and customer care) and the Cisco provisioning system, Broadband Access Center (BAC). It exposes the NBI API, which is XML over HTTP, to enable the SP OSS to communicate with the PMG. The PMG in turn sends a set of notifications to the SP OSS. For example, PMG assigns the LAC and Cell ID for a particular registered device. This information is passed back to the SP OSS.

      Provisioning and Management Gateway DB

      Provisioning and Management Gateway (PMG) DB provides a geo-spatial lookup service for PMG (read-only). It takes a location, defined by latitude and longitude, and returns the name of a group (for example, polygon). PMG then uses this group for automatic assignments. PMG DB operates on Oracle and is shipped as installation scripts, schema files, and stored procedures. It is expected that the operator provides the Oracle license and maintenance.

      Broadband Access Center

      Cisco RMS and FAP-related alarms are logged on the BAC. All component-related alarms, for example, alarms that PMG raises and so on, are sent directly to the Prime Suite, which is the Network Management System (NMS) interface.

      Cisco RMS has three categories of alarms:

      • Device or AP Alarms—A set of alarms that is received from the AP. For example, unable to connect to the HNB GW, or some sector has gone down, or radio status is not up. All these alarms come to the BAC and from BAC, it goes to the Prime Suite (Network Management System [NMS]). Therefore the alarm is converted from TR-069 to SNMP and sent to the Prime Suite.
      • Component-specific Alarm—All component specific alarms are sent to the BAC. For example, PMG is not able to get some resource, does not have enough memory. Those specific alarms raised by the component are sent directly to the NMS or Element Management System (EMS).
      • System-specific Resource Alarm—Cisco RMS does not participate in resource-specific alarms like CPU, I/O, disk, memory, and so on. The Prime Suite and VMware vCenter that are running on the Cisco UCS hardware, monitor and track the utilization and convert the alarms and sends them back to the Prime Suite.

      Access Point

      The Ubiquisys FAP supports a Cloudbase Activation Server (CAS).

      When a registered AP is powered on for the first time, it contacts the CAS. The CAS has information about what firmware to push to the AP, Cisco RMS IP address, and SeGW IP address. This information comes from the CAS and the AP gets booted with that particular image which it has got from the CAS. Now the AP knows the Cisco RMS IP address or the fully qualified domain names (FQDNs) and the SeGW FQDN so the AP starts communicating with the RAN server.

      Therefore, when the AP comes up, it contacts the Cisco RMS, which in turn configures a set of parameters back to the AP. Then the AP contacts the SeGW and HNB GW via the luCS and luPS on the RAN server and then proceeds to contact the Cisco RMS for AAA. When the authentication is complete, the AP goes to the SP MSC or SP GGSN, etc.

      Cisco Radio Access Network

      The Cisco Radio Access Network (RAN) interacts and interfaces with the Cisco RMS. Though RAN is not a Cisco RMS component, the Prime Access Registrar component of the Cisco RMS interacts with the RAN for authentication whenever an AP contacts the Cisco RMS.

      The Cisco RMS interacts with the RAN to configure the AAA/RADIUS whitelist on the HNB GW to get the system up and running.

      The Prime Network Registrar, which is the DHCP server interacts with the RAN because it is responsible for assigning the IP address to a given AP.

      Cisco RMS Software Architecture

      The following figure illustrates the Cisco RMS software architecture.



      Cisco RMS architecture is divided into three logical components:

      Central RMS Node

      In the Central RMS node, the DCC UI, PMG, and BAC RDU components of the Cisco RMS are installed.

      The Central node can be paired with any number of serving nodes.

      Figure 2. Central RMS Node



      In any of the Cisco RMS deployments, it is mandatory to have at least one Central node.

      To deploy the Central node, it is mandatory to procure and install VMware with one VMware vCenter per deployment. For more information, see the Cisco RAN Management Systems Installation Guide.

      Serving RMS Node

      In the Serving RMS node, the BAC DPE, PNR, and PAR components of the Cisco RMS are installed.

      The Serving node must be configured with the Central node. To add additional Serving nodes, the properties of the additional Serving nodes must be configured on the Central node.

      Figure 3. Serving RMS Node



      The Serving node can be scaled horizontally, which means that there can be multiple Serving nodes with one Central node depending on how many APs need to be supported.

      The AP (HNB) always interacts with the Serving node. APs use the Serving node IP address to reach the Cisco RMS. The IP address or FQDN of the Cisco RMS that is configured on the AP is part of the Serving node and not the Central node, which is hidden from the AP.

      For example, if a customer has around 1 million devices up and running, and they have 16 different Serving nodes, each of the devices will be configured to interact with a specific Serving node. That is how a Serving node can be scaled horizontally.

      Upload RMS Node

      In the Upload RMS node, the Upload Sever is provided on a separate node.

      The Upload RMS node must be combined with the Serving node.

      Figure 4. Upload RMS Node



      For more information about the Upload Server, see Upload Server.

      Cisco RMS Physical and Virtual Architecture

      This section lists the physical and virtual architecture of the Cisco RMS.

      The Cisco RMS can be deployed in one of these modes:

      All-in-One RMS Node

      In the All-in-One RMS node, all the components of the Cisco RMS solution is provided on a single host.

      The physical hardware has one virtual machine running a central node and one serving node.

      Figure 5. All-in-One RMS Node



      In an All-In-One RMS node, the Serving Node comprises of the Upload Sever VM and the VM combining the BAC DPE, PNR, and PAR components; the Central Node comprises of the VM combining the DCC UI, PMG, and BAC RDU VM components.

      To deploy the All-in-One node, it is mandatory to procure and install VMware with one VMware vCenter per deployment. For more information, see the Cisco RAN Management Systems Installation Guide.

      Distributed RMS Node

      In a Distributed RMS deployment mode, the following nodes are deployed:

      In a Distributed deployment mode, up to 250,000 APs are supported.

      Was this Document Helpful?

      FeedbackFeedback

      Contact Cisco