Cisco Provisioning Management Gateway

Cisco Provisioning Management Gateway
Cisco Provisioning Management Gateway
The Cisco Provisioning Management Gateway (PMG) is a generic provisioning and management application
that provides the necessary workflow component between the Service Provider (SP) IT or Operations Support
Systems (OSS) applications and the Cisco provisioning Broadband Access Center (BAC). These OSS
applications include service management and custom care systems.
This guide describes the PMG operations, components and concepts, and services in detail. While PMG is
designed to be a generic product, this document describes the concepts specific to this release.
This chapter describes PMG components and concepts as used in the current release.
• PMG Overview, page 1
• PMG Event Subscription, page 3
• PMG Logging, page 6
• PMG Profiles, page 12
PMG Overview
The PMG is a generic application suitable for any TR-069 deployment with the BAC. The application provides
an Extensible Markup Language (XML) interface over Hypertext Transfer Protocol (HTTP) based Application
Programming Interface (API) to the OSS that hides the complexity of the BAC API. The PMG provides the
ability to customize a deployment by using a profile that defines the elements of the API (such as messages,
parameters, and so on) that are applicable.
The PMG provides the following functionality:
• Interfaces to the OSS system for device provisioning and management.
• XML messages for provisioning and management.
• Interacts with the BAC and HNB-GW.
• Interfaces with the HNB-GW via RADIUS for dynamic whitelist.
• Reports events to the subscriber/OSS.
• Reports SNMP alarms for PMG service related events.
• Interfaces with the HNB-GW via RADIUS for dynamic whitelist.
Cisco RAN Management System Administration Guide, Release 5.1
July 6, 2015
1
Cisco Provisioning Management Gateway
PMG Overview
For requests from the OSS, the PMG accepts TCP connections, receives an HTTP request with XML payload
and provides response in HTTP response with XML payload. The connection can remain persistent for
subsequent requests unless it is closed by the client or times out.
For notifications, the PMG establishes a TCP connection to an IT / OSS / BSS, sends an HTTP request with
XML payload and gets confirmation in HTTP response. The connection can remain persistent for subsequent
notifications unless closed by target or times out.
The PMG API is defined by a profile, which is an XML document that describes the inbound messages that
the PMG supports. The XML schema provides a means for defining the structure, content, and semantics of
the XML document. The XML schema for the profile specifies the inbound requests, the required elements,
excluded elements, ignored elements, and the applicable parameters. These parameter elements include name,
type, readable, writable, deletable, and source type along with optional validation and source key.
Note
PMG is installed as part of the OVA installation.
This table lists a few standard HTTP status codes used in validating the PMG messages:
Table 1: PMG HTTP Status Codes
HTTP Status Codes
Description
200 OK
Occurs for any response containing a valid PMG message response
(which in turn may contain an application layer error).
400 Bad Request
Occurs when the request received does not contain a valid PMG
message (for example, wrong encoding).
503 Service Unavailable
Used when the service is unavailable, typically due to high load.
Note
The client must resend the service
request.
Following is the send.url for posting XML message for httpclientsh:
http://localhost:8083/pmg
Following is the URL for defining the HTTP POST messages to PMG:
/pmg
Where,
• <host name>, is the host name of the Central Node, or IP address.
• <IP address>, is the eth1 of the Central Node.
• 8083, is the port number.
• /pmg, is the path.
Digest authentication is supported in PMG.
Cisco RAN Management System Administration Guide, Release 5.1
2
July 6, 2015
Cisco Provisioning Management Gateway
PMG Message Flow
Note
To add any new pmguser or pmgadmin user, log in to DCC UI as a pmgadmin and create new users.
PMG Message Flow
The following is the flow of PMG messages:
1
2
3
4
5
6
7
8
9
OSS establishes an HTTP connection with the PMG service url.
OSS sends a message to PMG with the digest authentication credentials.
PMG receives the message and validates the content-type as application/xml or text/xml.
PMG validates that the message is valid XML.
PMG validates that the message complies with PMG XML Schema Definition (XSD).
PMG determines the message type by examining the root node name.
PMG determines if the message type is part of the configured profile.
PMG makes business orchestration by invoking PMG API.
Construct the response message and sent with HTTP 200 OK response message.
LUS Organized Directory Structure for AP PM Files
Currently all the APs upload PM files to LUS server under the same directory (base path). Therefore, if the
number of APs are more, then the directory is unmanageable. This feature is added to categorize the APs
based on AP's associated group, and upload all these APs PM files to LUS into a same sub directory under
base path. (sub directory name will be the associated group name.) New property "ap.upload.url.suffix.group
" is added in PMGServer.properties file to enable this feature. By default value of this is "NO_GROUP",
means feature is disabled and the current behavior will continue. Possible values of this property are
Area/FemtoGateway/Enterprise/Site (Possible FRM group types).
For example: If ap.upload.url.suffix.group = Area,
A P-1,2,3 are associated to Area-1,
AP-4,5,6 are associated to Area-2,
then the uploaded PM files will be structured as below:
/opt/CSCOuls/files/uploads/Area-1/
AP1-stats_1.xml
AP1-stats_2.xml
AP2-stats.xml
AP3-stats.xml
/opt/CSCOuls/files/uploads/Area-2/
AP4-stats.xml
AP5-stats.xml
AP6-stats.xml
When this feature is enabled, PMG will set "FC-LOG-PERIODIC-UPLOAD-URL" custom property at device
level for all newly registered APs. The same can be added to existing APs with ReAssign API.
PMG Event Subscription
The subscriber should follow these steps for subscribing to the PMG events:
Cisco RAN Management System Administration Guide, Release 5.1
July 6, 2015
3
Cisco Provisioning Management Gateway
PMG Event Subscription
1 Send the getAllEventTypes message (subscribe.xml) to PMG for receiving all the supported events.
Note
Each subscriber can subscribe to all the events or selected events, and can have multiple (maximum 3 and
minimum 1) notification url for one subscriber. PMG picks up one url and delivers the event. If that URL1
is not reachable, then PMG picks up the next url for event delivery.
PMG event subscription supports these events: AssignedData, FirmwareUpgraded, GroupCreated,
GroupUpdated, GroupDeleted, LocationStatus, Online, ServiceError, ServiceOperational,Tampered,
UserPasswordExpiryNotification, and IpAddressUpdate. . PMG accepts three number of subscribers by
default.
Following is the sample xml request for event subscriptions:
<Subscribe subscriber-name=”OSS-1”>
<URL>http:server1/notifyme </URL>
<URL>http:server2/notifyme </URL>
<URL>http:server3/notifyme </URL>
<Event name=”AssignedData”>
<Parameter name=”eCGI”>
</Event>
<Event name=”Groups” isEnabled=false>
</subscribe>
Following is an example xml:
<Subscribe xmlns="http://www.cisco.com/ca/sse/PMGMessages-v3_0_0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.cisco.com/ca/sse/PMGMessages-v3_0_0
pmg-messages-v3_0_0.xsd"
subscriber-name='TESTLAB-OSS-1'>
<TxnID>subs-trans-1234567890</TxnID>
<URL>http://10.105.233.87:8083/pmg</URL>
<Events>
<Event name='AssignedData' isEnabled='true'>
</Event>
<Event name='GroupCreated' isEnabled='true'>
</Event>
<Event name='GroupUpdated' isEnabled='true'>
</Event>
<Event name='GroupDeleted' isEnabled='true'>
</Event>
<Event name='FirmwareUpgraded' isEnabled='true'>
</Event>
<Event name='LocationStatus' isEnabled='true'>
</Event>
<Event name='Online' isEnabled='true'>
</Event>
<Event name='ServiceError' isEnabled='true'>
</Event>
<Event name='ServiceOperational' isEnabled='true'>
</Event>
<Event name='Tampered' isEnabled='true'>
</Event>
<Event name='IpAddressUpdate' isEnabled='true'>
</Event>
<Event name='UserPasswordExpiryNotification' isEnabled='true'>
</Event>
</Events>
</Subscribe>
2 The subscriber can send this subscribe message from any host by specifying the subscriber name and the
list of notification URL. Subscribed events are specified in the <Event> element, and events are enabled
by default. Changing the Enabled state of particular event to false, to disable the event. Following is an
example:
<Event name='LocationStatus' isEnabled='false'>
</Event>
Cisco RAN Management System Administration Guide, Release 5.1
4
July 6, 2015
Cisco Provisioning Management Gateway
RMS Alarm Handler
3 The subscriber can customize the events by specifying the parameter names that the notification server
prefers to receive. If the parameters are not specified, then the notification will contain all the parameters
of an particular event.
Note
If the events are not specified, it indicates that the subscriber has subscribed to all the events.
4 The subscriber can update event subscription by sending subscribe message with the updated set of
additional events and removing previously subscribed events.
For example, the subscriber can subscribe to events by posting the subscribe.xml message using the url
http://<eth1 address of central node>:8083/pmg to receive the notifications.
RMS Alarm Handler
RMS alarm handler raises the AP location Verification Alarm.
AP Location Verification Alarm
RMS raises a Location Verification Alarm with the severity Major if the location verification passes or fails
based on these scenarios:
• RMS raises Location Verification alarm if the current location verification has failed and the previous
location verification was passed.
• RMS clears Location Verification alarm if the current location verification has passed and previous
location verification was failed.
• RMS forwards Location Verification alarm to Prime Central for further processing.
• RMS treats this alarm in similar way as it treats any other FAP alarm. For example, adding FAP ID, DN
Prefix, and so on while sending this alarm to Prime Central.
• RMS defines a property using which operator can turn on/off for generation of this alarm.
The PMG Server Properties file, (/rms/app/pmg/conf/PMGServer.properties) must be configured
as shown below for enabling the Alarm Handler Feature.
#Alarms
#Following parameter is used to enable/disable the EPM alarm feature.
#1:Enable , 0:Disable
pmg.alarms.snmp.epm.alarmhandler=1(Enable by default)
pmg.alarms.snmp.epm.alarmhandler.port=4678 (Port)
pmg.alarms.snmp.epm.nummanagers=1
#<Prime central IP>
pmg.alarms.snmp.epm.manager.address.1=
pmg.alarms.snmp.epm.manager.port.1=162
pmg.alarms.snmp.epm.manager.community.1=public
#1:Enable AP reachability alarm, 0:Disable
pmg.alarms.snmp.epm.apreachability=1
#Connection Request Timer, By Default this is 10 min. Can be increased to interval of 60
min
pmg.alarms.snmp.epm.apreachability.interval=10
#Rate at which Connection Request is Triggered. By Default this Should be 10
pmg.alarms.snmp.epm.apreachability.rate=10
pmg.alarms.snmp.epm.apreachability.devices.max=5000
#idfile: A absolute path to a file with a list of devices or group IDs (one per line).
# Provide the Complete Path with ciscorms permissions
pmg.alarms.snmp.epm.apreachability.idfile=
Cisco RAN Management System Administration Guide, Release 5.1
July 6, 2015
5
Cisco Provisioning Management Gateway
PMG Logging
#type: Specifies the content of the list file as either devices or a configured group type
(Available types are : all, devices, provgroup, cos, Area, CELL-POOL, Enterprise,
FRM-Group-Type-Meta-Data, FemtoGateway, Management, Pool-Type-Meta-Data, SAI-POOL, Site,
system)
pmg.alarms.snmp.epm.apreachability.type=all
#1:Enable AP location check , 0:Disable
pmg.alarms.snmp.epm.aplocation=1
#Serving Node Eth_0 Ip Address
pmg.alarms.snmp.epm.serving.address=
For the first time usage of the alarm handler, the below changes should be made in the PMGServer.properties
file under the path /rms/app/pmg/conf.
1 Add the PrimeCentral IP/SNMP Address:
#<Prime central IP>
For example, pmg.alarms.snmp.epm.manager.address.1= 10.142.52.41
2 Provide the Eth_0 Serving Node IP Address
#Serving Node Eth_0 Ip Address
For example, pmg.alarms.snmp.epm.serving.address=10.5.1.20
3 Provide the path of the file location
# Provide the Complete Path with ciscorms permissions
For example, pmg.alarms.snmp.epm.apreachability.idfile=/rms/app/pmg/conf/idfile.txt
4 Modify the below Parameter value as required.
For example, if the alarm handler needs to be triggered for all devices, then provide all as mentioned
below.
pmg.alarms.snmp.epm.apreachability.type=all
User Guidelines
1 RMS issues Connection Request (CR) every 10 min (by default) as configured in the PMG Server Properties
file.
2 CR is issued based on the configuration in the PMG Server properties file. For example:
pmg.alarms.snmp.epm.apreachability.idfile= /rms/app/pmg/conf/ idfile.txt
#type: This specifies the contents of the list file as either devices or a configured group type. The available
types are: all, devices, provgroup, cos, Area, CELL-POOL, Enterprise, FRM-Group-Type-Meta-Data,
FemtoGateway, Management, Pool-Type-Meta-Data, SAI-POOL, Site, system.
pmg.alarms.snmp.epm.apreachability.type=all (This should be changed based on the configuration.)
This file should have ciscorms permissions, for example:
chown ciscorms:ciscorms idfile.txt
chmod 744 idfile.txt
3 The Alarm handler logs in to the path (/rms/log/AlarmHandler/AlarmHandler.console.log)
.
PMG Logging
The PMG is capable of logging all requests and responses to and from the OSS, and to and from the BAC.
The PMG logging automatically rolls its log files on a daily and file size basis. The path for pmglogs is
/rms/log/pmg.
This table lists the different types of PMG logs. By default a maximum of five days of compressed log files
are maintained for various PMG log files.
Cisco RAN Management System Administration Guide, Release 5.1
6
July 6, 2015
Cisco Provisioning Management Gateway
PMG Performance Logs
Table 2: Different Types of PMG Logs
PMG Logs
Description
Performance Logs
The Performance log determines the performance statistics and consists of two
files, one for individual message performance and the other periodic roll-up
performance metrics.
Audit Logs
The Audit log logs all interactions with the individual provisioning system
components and changes, to the device configuration.
Message Logs
The OSS HTTP Message logs are used for testing and message tracking
purposes.
Syslog
PMG server status will be logged when PMG is started/stopped/restarted. Syslog
contains the Alarm messages of PMG server.
Thus, PMG logging is useful in determining device performance and ensuring proper processing with the
BAC. Alarm information is logged in the syslog. The syslog messages can be found in /var/log/local0.log.
In addition to the logs mentioned above, the server start/stop will also be logged in syslog.
Note
The server, pmgServer, must be started with the user specified as ciscorms.
All PMG logs are stored in the directory defined in the /rms/log/pmg/ environmental variable with a
"/pmg" added.
PMG Performance Logs
The Performance logging consists of two files; one for individual message performance and the other hourly
roll-up performance metrics.
Individual Performance Log File
The performance log for individual messages is output to the file "pmg-msg-perf.csv" and is stored in the
directory /rms/log/pmg. The Performance log file is in the CSV format and begins with a header row followed
by the individual message performance data. An example of the individual performance logs is shown here:
2011-12-09T01:01:49.309
2011-12-09T01:01:49.319
2011-12-09T01:01:49.329
2011-12-09T01:01:49.339
2011-12-09T01:01:49.349
2011-12-09T01:01:49.359
2011-12-09T01:01:49.359
2011-12-09T01:01:49.359
2011-12-09T01:01:49.359
Block
Unblock
Update
GetStoredData
Block
UnBlock
Unknown
Unknown Content
XML Parse error
ead1eb47-...-472bb
ead1eb47-...-472bb
ead1eb47-...-472bb
ead1eb47-...-472bb
ead1eb47-...-472bb
ead1eb47-...-472bb
Unknown
Unknown
Unknown
00223A-0000393086
00223A-0000393086
00223A-0000393086
00223A-0000393086
00223A-0000393086
00223A-0000393086
Unknown
Unknown
Unknown
220
220
222
220
221
220
2
2
2
215
215
216
225
215
215
0
1
0
319
320
321
319
320
319
3
3
3
Following are the headings of the fields in the log file and their descriptions:
Cisco RAN Management System Administration Guide, Release 5.1
July 6, 2015
7
Cisco Provisioning Management Gateway
PMG Performance Logs
• timestamp is the date and time of the received message. The timestamp is represented in the ISO 8601
format "YYYY-MM-DDThh:mm:ss.fffZ", where:
◦YYYY-represents the four-digit year
◦MM-represents the two-digit month
◦DD-represents the two-digit day of the month
◦T-is the time delimiter
◦hh-represents the time in hours
◦mm-represents the time in minutes
◦ss-represents the time in seconds
◦fff-represents the time in milliseconds
◦Z-represents the zone designator for the zero (Co-ordinated Universal Time) UTC off set, if the
time is in UTC
• msg name-the message name as found in the XML root element
• trans id-the transaction ID in the message
• eidthe device ID for the record. If the message is called with a Secondary ID, the EID must be looked
up and used
• msg process time ms-the message processing time of the message processor in milliseconds, with the
BAC processing time removed
• BAC process time ms-the BAC processing time in milliseconds
• total msg process time ms-the total message processing time in milliseconds that includes time in
un-marshaling the message, message processing time, BAC processing time, and the response time in
message marshaling.
To track the performance of unknown messages, messages with XML parser errors and messages that are not
of XML content are also logged in the individual performance log file.
Following are some of the logging details for unknown messages:
• All unknown messages have the message name, transID, and EID as "Unknown".
• All message XMLs that fail to parse, have the message name as "XML Parse error" with transID and
EID as "Unknown".
• All messages that are not of content type application/xml or text/xml have the message name as "Unknown
Content", with transID and EID as "Unknown".
The audit logging is output to the file "pmg-audit.log" and is stored in the directory /rms/log/pmg. The audit
logs are used to identify the workflow from the receipt of a PMG message to the response back to the OSS.
The audit logs will be rotated after 12 am when the first log entry comes in each day or if larger than 50 MB
in size.
Cisco RAN Management System Administration Guide, Release 5.1
8
July 6, 2015
Cisco Provisioning Management Gateway
PMG Performance Logs
Note
Some of the archived log files are maintained until the files consume configured disk space threshold. For
details, see Cleaning Up PMG, Upload Server, and DCC UI Logs. For log files that are not configured
for disk space thresholds, the individual archived logs are maintained for five days on the Central node
after which they are removed from the Central node.
Periodic Performance Log File
The periodic performance log file is a summary of each message performance from the start of PMG or for
the last period defined. The period is specified by the pmg.perf.periodic.log.interval.milli.seconds property
in the dcc.properties file. The period is specified in milliseconds. If this property is not set in the dcc.properties
file, the default value of 3600000 (1 hour) is used.
For example, if the period is set to 900000, which corresponds to 15 minutes, and the PMG starts at 2:03, the
first log is printed at 2:18 and then at 2:33 and so on. The periodic performance log files are output to the file
"pmg-perf-periodic.csv", and are stored in the directory /rms/log/pmg. The periodic performance log file
is in csv format and begins with a header row followed by a performance summary for each message.
An example of the messages in the file for the period performance logs is shown below for 15 minute intervals:
2014-09-24T16:41:49.735Z,899,GetAllFRMPools,96,96,96,1,0,245,524,0,0
2014-09-24T16:41:49.736Z,899,GetAllFRMPoolTypes,113,118,108,2,0,424,1486,0,0
2014-09-24T16:41:49.737Z,899,GetAllFRMGroupTypes,447,767,272,3,0,642,8694,0,2
2014-09-24T16:41:49.737Z,899,GetAllFRMGroups,157,157,157,1,0,241,6914,0,2
2014-09-24T16:56:49.735Z,899,GetLiveData,145,145,145,1,0,606,283,0,0
2014-09-24T16:56:49.736Z,899,GetAllFRMPools,69,70,68,2,0,487,1047,0,0
2014-09-24T16:56:49.737Z,899,GetAllFRMPoolTypes,99,108,91,2,0,424,1486,0,0
2014-09-24T16:56:49.737Z,899,GetAllFRMGroupTypes,204,211,200,3,0,642,8694,0,2
2014-09-24T16:56:49.738Z,899,GetStoredData,259,271,248,2,0,448,35272,0,10
The headers for the fields in the periodic performance summary file are described here:
• period end-the summary period end timestamp in the ISO 8601 format. The timestamp is in the format
"YYYY-MM-DDThh:mm:ss.fffZ", where time is represented in milliseconds
• summary period sec-the time interval in milliseconds, for receiving the messages during the summary
period
• msg name-the message name received during the summary period
• avg response time ms-the average response time in milliseconds
• max response time ms-the maximum response time in milliseconds
• min response time ms-the minimum response time in milliseconds
• num msgs-the total number of messages received during the summary period
• num errors-the number of errors occurred during the summary period
To track the performance of unknown messages, messages with XML parser errors and messages that are not
of XML content are also rolled up in the periodic performance summary file.
Following are some of the logging details for unknown messages:
• All unknown messages have the message name as "Unknown".
• All message XMLs that fail to parse have the message name as "XML Parse error".
Cisco RAN Management System Administration Guide, Release 5.1
July 6, 2015
9
Cisco Provisioning Management Gateway
PMG Alarm Logs
• All messages that are not of content type application/xml or text/xml have the message name as "Unknown
Content".
Note
The periodic performance logs are maintained for five days on the Central node after which they are
removed from the Central node. Each periodic performance log file is rotated after 12 am when the first
log entry comes in or if the file size exceeds 10 MB.
PMG Alarm Logs
The PMG alarms are sent to Prime Central or any alarm monitoring entity via the Fault Management server.
Table 3: PMG Alarm Log Messages
Alarm Condition
Alarm Level
Alarm Text
Connection with the RDU lost
Critical
Alarm raised: Type=RDU Connection
Connection with RDU established
Clear
Alarm resolved: Type=RDU Connection
Radius connection lost
Minor
Alarm raised: Type=Radius Connection
Radius connection restored
Clear
Alarm rersolved: Type=Radius Connection
PMG connection limit exceeded
Warning
Alarm raised: Type=PMG Connection
PMG connection limit exceeded
Major
Alarm raised: Type=PMG Connection
PMG Server start
Warning
Alarm resplved Type= PMG Status
PMG Server stop
Major
Alarm raised Type= PMG Status
PMG Syslogs
The alarms logged in pmg-alarms.log are logged in the syslog (/var/log/local0.log). In addition to the
above mentioned logs, the server start/stop are also logged in the syslog.
For the statements to appear in the syslogs, the udp port has to be uncommented in
/etc/rsyslog.conf.
These parameters, (if commented) need to be uncommented in rsyslog.conf.
• #$ModLoad
imudp.so
• #$UDPServerRun
514
The rsyslog needs to be restarted: /etc/init.d/rsyslog
restart
Cisco RAN Management System Administration Guide, Release 5.1
10
July 6, 2015
Cisco Provisioning Management Gateway
PMG Message Logs
PMG Message Logs
The PMG includes inbound message logs for inbound message tracking. This logging is output to the file
"pmg-inbound-msg.log", and is stored in the directory /rms/log/pmg. The PMG also includes outbound
message logs for outbound message tracking. This logging is output to the file "pmg-outbound-msg.log", and
is stored in the directory /rms/log/pmg. Inbound message logs and outbound message logs are rotated after
12 am when the first log entry comes in or if the file size exceeds 50 MB.
Note: The individual logs are maintained for five days on the Central node after which they are removed from
the Central node.
PMG Status Monitoring
Use these commands to monitor the status of the PMG server and start or stop the server.
Procedure
Step 1
god status PMGServer
Verifies the status of the PMG server. The server states can be up (running), unmonitored (stopped), init
(intermediate).
Example:
This example shows sample output when the server is up:
[rms-aio-central] /home/admin1 # god status PMGServer
PMGServer: up
This example shows sample output when the server is stopped:
[rms-aio-central] /home/admin1 # god status PMGServer
PMGServer: unmonitored
Step 2
god start PMGServer
Starts the PMG server.
Example:
This example shows sample output when the server is started.
[rms-aio-central] /home/admin1 # god start PMGServer
Sending 'start' command
The following watches were affected:
PMGServer
Step 3
god stop PMGServer
Stops the PMG server.
Note
Check the status of the PMG server before starting or stopping the server. Wait for some time after
executing the command as it can take 10 to 12 seconds.
Example:
Cisco RAN Management System Administration Guide, Release 5.1
July 6, 2015
11
Cisco Provisioning Management Gateway
PMG Profiles
This example shows sample output when the server is stopped:
[rms-aio-central] /home/admin1 # god stop PMGServer
Sending 'stop' command
The following watches were affected:
PMGServer
PMG Profiles
A PMG profile defines the messages used for the configuration and activation processes. The profile specifies
the inbound requests that are used along with the required, ignored, and excluded elements. The PMG profile
also contains a number of exclusions, but does not add element requirements. The PMG profile is referred to
as pmg-profile.xml in the server.
Using the pmg-profile.xml, the operator can add/remove/exclude/ignore for any message.
For all PMG messages, either an EID or SecondaryID is specified as the device ID. The device search is
performed using the SecondaryID which is the device's Fully Qualified Domain Name (FQDN) in BAC or
with the EID which is the device's DeviceID property in the BAC.
Profiles are used to specify the subset of messages, elements, and parameters to be used in a given deployment.
A Profile is a way to configure the generic PMG to deployment-specific requirements.
The PMG profile contains the Parameter Definition section, which defines the names and types of the supported
parameters.
Note
When pmg-profile is customized for the first time, the PMG server must be restarted. Place the customized
pmg-profile.xml in the /rms/app/rms/conf/ directory.
The path for the default pmg-profile.xml is /rms/app/rms/doc/pmg/pmg-profile.xml.
Parameter Definitions
Some PMG messages support the parameter structure to add, update, delete, or retrieve parameters. The PMG
profile contains the Parameter Definition section, which defines the names and types of the supported
parameters.
This table lists some of the parameter elements that are defined in the parameter definition.
Table 4: Parameter Elements and Description
Parameter Elements
Description
Name
The parameter name or the alias used in the message.
Cisco RAN Management System Administration Guide, Release 5.1
12
July 6, 2015
Cisco Provisioning Management Gateway
Parameter Definitions
Parameter Elements
Description
Type
The type of the parameter that can be:
• String
• Integer (BAC custom property which is an integer)
• Unsigned integer (BAC custom property which is of the type Long)
• Decimal
• Boolean
• Date/Time
Source Type
The type of the source that includes:
• DeviceParameters
An example of BAC API constant: DeviceDetailsKeys.DEVICE_ID.
• DeviceProperty (BAC property or custom property)
Writable
Indicates if the parameter is writable (can be added or updated).
Readable
Indicates if the parameter is returned by a get.
Deletable
Indicates if the parameter can be deleted.
Cisco RAN Management System Administration Guide, Release 5.1
July 6, 2015
13
Cisco Provisioning Management Gateway
Parameter Definitions
Parameter Elements
Description
Validation
Defines the validation to use on a Writable parameter value and is defined
by the following:
• Type - defines the type of validation that can be:
◦A range, used to validate numbers. The expression element is of
the format [low:high], where "low" is the lowest number in the
range, or empty if there is none, and "high" is the highest number
in the range or empty if there is none.
◦A Regular expression. The expression element contains a regular
expression that is used to match the value.
• Expression - Expression as defined by the type, either a range or regex
expression.
Following is an example for validation:
<ParameterDefinition>
<Name>MAX-TRANS-PWR</Name>
<Type>int</Type>
<SourceType>DeviceProperty</SourceType>
<Writable>true</Writable>
<Readable>true</Readable>
<Deletable>true</Deletable>
<Validation>
<Type>range</Type>
<Expression>[-100:10]</Expression>
</Validation>
</ParameterDefinition>
Cisco RAN Management System Administration Guide, Release 5.1
14
July 6, 2015
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising