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 Provisioning Management Gateway

Results

Updated:
July 6, 2017

Chapter: 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

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.

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 an XML message from the OSS or Poster to the PMG:

http://<host name/IP address>:8083/pmg

Where,

  • <host name> is the host name of the Central Node.
  • <IP address> is the eth1 of the Central Node.
  • 8083 is the port number.
  • /pmg is the path.

Digest authentication is supported in PMG.


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. OSS establishes an HTTP connection with the PMG service url.
  2. OSS sends a message to PMG with the digest authentication credentials.
  3. PMG receives the message and validates the content-type as application/xml or text/xml.
  4. PMG validates that the message is valid XML.
  5. PMG validates that the message complies with PMG XML Schema Definition (XSD).
  6. PMG determines the message type by examining the root node name.
  7. PMG determines if the message type is part of the configured profile.
  8. PMG makes business orchestration by invoking PMG API.
  9. 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:

  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, CustomValueChange, 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>
  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 Reachability Alarm and AP location Verification Alarm.

AP Reachability Alarm

RMS has introduced a new alarm AP Reachablity Alarm with the severity "Major". The alarm raises whenever the AP is abruptly down or Issue in the network connection between FAP and RMS. The scenarios are as follows:

  • RMS raises AP Reachability alarm if the current request for connection request has failed and previous one is passed.

  • RMS clears the AP Reachability alarm if the current request for connection request has passed and previous one is failed.

  • RMS forwards AP Reachability alarm to Prime Central for further processing.

  • RMS treats this alarm in a 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 generation of this alarm.

  • RMS schedules massCR.sh to run every 10 minutes by default.

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=
#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.

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	Block	          ead1eb47-...-472bb	00223A-0000393086	220	215	319
2011-12-09T01:01:49.319	Unblock	        ead1eb47-...-472bb	00223A-0000393086	220	215	320
2011-12-09T01:01:49.329	Update	         ead1eb47-...-472bb	00223A-0000393086	222	216	321
2011-12-09T01:01:49.339	GetStoredData	  ead1eb47-...-472bb	00223A-0000393086	220	225	319
2011-12-09T01:01:49.349	Block	          ead1eb47-...-472bb	00223A-0000393086	221	215	320
2011-12-09T01:01:49.359	UnBlock	        ead1eb47-...-472bb	00223A-0000393086	220	215	319
2011-12-09T01:01:49.359	Unknown	        Unknown	           Unknown	            2	  0	  3
2011-12-09T01:01:49.359	Unknown Content	Unknown	           Unknown	            2	  1	  3
2011-12-09T01:01:49.359	XML Parse error	Unknown	           Unknown	            2	  0	  3

Following are the headings of the fields in the log file and their descriptions:

  • 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.


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".
  • 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

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:

    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.

    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.

    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>

    Was this Document Helpful?

    FeedbackFeedback

    Contact Cisco