PacketLogic Subscriber

Manager Product Guide
Release 14.0

PacketLogic Subscriber
Manager Product Guide

Portions of the documents can be copied and pasted to your electronic mail or word-processing applications for
your personal use only, but cannot be distributed to third parties. In no event may you copy or use this information
for any commercial purposes except the operation of products from Procera Networks, Inc. and you may not
transmit this information to third parties without the consent of Procera Networks, Inc.

IT IS ILLEGAL TO COPY (FOR OTHER THAN BACK-UP PURPOSES) THE CONTENTS OF THIS
DOCUMENTATION OR TO POST THE CONTENTS ON THE INTERNET WITHOUT THE EXPRESS
PRIOR WRITTEN CONSENT FROM AN AUTHORIZED OFFICER OF PROCERA NETWORKS, INC. OR
NETINTACT AB.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL
ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND
RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED
WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL
RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

and
signals the PacketLogic systems to ensure the policies applicable to a subscriber are applied to the IP address that
subscriber currently uses.
5. and hold current
access information including IP address. and policies are applied. The OSS nodes are the entry point to the network for the subscriber.
3.
Figure 1.
Based on the data received.
The policies to apply are configured on the PacketLogic.
1
. since that is where traffic management is performed and
statistics are collected. The PSM can query the BSS systems for policy information.1. monitoring. typically has accounting and policy information based on the subscriber.1.
The BSS nodes hold policy information which can be used to define how policies are applied to subscribers. but a subscriber can change IP addresses frequently. however. Introduction
Chapter 1.
An operator. The PSM can
then populate the NetObjects correctly based on subscriber information. The internet traffic of the subscriber passes through a PacketLogic system. and troubleshooting.
2. Introduction
This document provides a description of the PacketLogic Subscriber Manager (PSM). Overview of PSM tasks
1. OSS systems propagate authentication information to the PSM (see Section 4. Overview
The PSM is a solution for integrating PacketLogic solutions with existing network support systems. The core
function of the PSM is to provide a mapping between an operator identifier of a subscriber and an IP address. Subscribers authenticate through the OSS systems in the network. the PSM provides the PRE with a NetObject tree containing IP addresses.3. the rules use conditions based on NetObjects. and
the deployed PacketLogic. “Sources”). but any information available in the authentication handshake
can potentially be used to make decisions in the PSM. and guidelines for
configuring.
The OSS nodes can provide the PSM with the information needed to map the subscriber to an IP address.
The PSM interfaces with Operational Support System (OSS) nodes.
4. additional information may also be available which
can be used for policy or statistics application. Examples include mobile terminal or location (deduced from IMEI
and cell information in a mobile RADIUS packet).
1. operating. The PSM signals the PacketLogic systems deployed so that the policies for the subscriber are applied to the
IP address currently in use by the subscriber.1. When integrated with a PSM. Business Support System (BSS) nodes.
Depending on the protocol used to authenticate subscribers. This
is necessary since the PacketLogic operates on IP addresses.

1. or using APIs. and
include:
2
.2.2.
and how to make use of that information. “Sources”. An input source in the PSM is a protocol for associating a subscriber
with an IP address.3.3. Introduction
Figure 1. The
NetObjects grouping subscribers by their IMSI and MSISDN (obtained from RADIUS provided to the RADIUS
source) are kept up to date by the provisioner in the PSM.1. and the input source support in the PSM consists of a parser for that protocol and a set of
data items to extract from the authentication handshake of the protocol. A source can also be used for setting up
traffic counters. Provisioner operations (example)
Figure 1. see the PacketLogic Product Guide.
For more information on the rules and their application. with different roles and configuration.1.2. “Provisioner operations (example)” shows an example from a mobile operator environment. The sources specify what to look for in the received source packets. Overview of PSM components
1.
Figure 1. PSM Components
The PSM is built up by several components.
The current set of supported input sources can be configured in the web interface (Section 4. Sources
The PSM supports a range of input sources. Using these NetObjects as conditions to relevant rules
for traffic management (such as shaping and filtering) and statistics is done on the PacketLogic.2.

sessions.
The available configuration options are shown in the web interface (Section 4.2. Introduction
• RADIUS
• DHCP
• DHCPv6
• JSON Bulk (TCP and UDP)
• JSON RPC
• SOAP
• REST
The sources are customized to define what data is extracted from the source protocol and how that data is mapped
to the subscriber and session information in the PSM. The
model contains schemas for subscribers. Model
The model is the core of the PSM.2. “NetObject Tree”).2.
The configuration of PacketLogic systems to provision is done in the Provisioner section of the web interface. Using groups a service plan can be created.2.1.2.3. “Sources”). This customization is done in the Sources configuration in
the web interface (see Section 4. a session is created for the
subscriber.2.3.
1.
In addition to being mapped to sessions. keeping state of subscribers and their sessions based on the information from
the sources. Other tables can be configured as well in the model. and instructing the provisioners to perform updates to the PacketLogic that the PSM provisions. NetObject Tree Syntax.
1. that provides an overall quota shared
by all devices with separate identities (subscribers) owned by one customer. A subscriber can hold several sessions.1.1. that share
for example policies and quotas. When authenticated. grouped together under a single customer ID. a subscriber in PSM can also hold information that relates to the subscriber
rather than the sessions. Sessions
A session is created when a subscriber connects to the network through the mechanism that provides an input to
one of the sources in PSM (typically an access system such as a DHCP or RADIUS server). This is subject to customization. This provides the mapping from
subscriber to IP address.
3
. Subscribers
A subscriber is defined by a network-unique subscriber identity.
1.2. mapping the subscriber to the IP address provided in that session. The definition of
the language used in the adapter is shown in Appendix B.3.2.2. and groups.
1. based on the state
of the model.4. but examples include policy information provided by
other BSSs.2. Groups
A group is an entity that refers to one or more subscribers. “Model”).1. Provisioner
The provisioner is the component that applies updates to the provisioned PacketLogic systems. mapping to several IP addresses.
The provisioner can be customized in terms of the NetObject tree it maintains in the PacketLogic systems.2.
1. This
is done in the NetObject tree section of the web interface (see Section 4.

Introduction
.

1. See Section 4. Previously counter data was automatically applied internally.4.1
This section lists prominent changes in PSM 14. DHCPv6 and JSON-BULK
sources.4. See Section 4. PRE Provisioning
The provisioning by the PSM to the PRE has a new implementation which results in perfomance improvements.
• The accounting plugin has been replaced with two new field types: Limit set and state.
2.0. Using this. The new configuration options allow a more
customised handling of input data.3. The new features include:
• A new counter source has been added.
especially when running the PSM against a 14. “Counters Source” and Section A.3.
Source-Address and Source-Port are now available as variables when doing input transformations. Instead a new object
set type can be configured to work as the previous counters type if needed. DHCP.1. New Since Release 13.
• The counter-reset implementation has been replaced with the schedulement of object mutations mentioned in
Automatic Actions below. not just the
counter values. compared to 13.
5
. a number of attributes can be set/reset at the same time. “Access Logging”.3. “Setting
up Counters”. see Section 4.1.11.3.1.6. the following are new
features (see Section 4.2.8.1. Access Logging
Configurable request/access logging has been implemented for the RADIUS. “DHCPv6 Source”. DHCPv6 Source
A new DHCPv6 source has been added. In addition. However. “Sources”. Random CSV/JSON data can now be posted to /rest/input/<X> and
then be transformed in the same way as for other sources.3. but also for older versions of the PRE.0 PRE.1.1.2.
2. along with the counters attribute on the objects.
2. Counters
Counter handling has been completely reworked. “REST Source”.4.
• The counter plugins have been removed.2.1
Chapter 2. See Section 4. See Section 4. New Since Release 13. This implementation
also avoids a large memory build-up when synchronizing with the PRE:s.
2.1.5.1. The limits can optionally
be placed in a table and be looked up based on a service attribute (for example).3. Now it can
be transformed just like all other input data.
2. REST Source
A new REST input source has been added.0 PRE:s
2. the new recommendation
is to apply counter values directly to a normal integer attribute. “Provisioners”):
• Enabling and disabling is now configurable per PRE instead of per proxy group
• Provisioning filters are now configurable per PRE instead of per proxy group
• Dynamic provisioning of IPv4 subnets to 14. Sources Transformations
The configuration of input transformations for all sources is new.

• A new REST URL is added.7.8. Credit Control
A Diameter Credit Control function is added.
It is now possible to log to multiple remote syslog servers at the same time. which means that the port 8443 does not have to be specified
when accessing the user interface.1.3. Automatic Actions
A new more generic schedulement of object mutations has been added.14. The children of an object can be viewed using for example /rest/model/
objects/subscribers/aid/<id>/children. The object type does not have to be specified.3. as well as the counter-reset implementation.
2.1. The grouping of the configuration options
in the user interface has also been updated. meaning easier logging configuration and
shorter log lines.1. Configuration of the PSM.13.9. and all related
objects are displayed in the result.
2.proceranetworks" prefix has been removed everywhere. scheduled in a one-time or periodic fashion. see Section 4.3. This can be used to configure automatic
updates and/or deletes per object.1. which makes configuration of CDR generation easier.3. New Since Release 13.
2. See Section 4. Updates in User Interface
The web interface has been reduced in size to fit better on small screens.
• The PSM now binds to the standard SSL port. “CDR”. CDR Generation
Many of the required fields for CDR generation are added automatically in the schema when enabling the CDR
plugins. Additional Changes
• The "com.3.2.2. See Section 4.
2. This functionality replaces the
expiryTime attribute. “Diameter Access Logging”. There is also the vmstat.12.log
that logs system activity.
6
. “Logging”. System Diagnostics Zones Support
The PacketLogic client can now be used to monitor and and present graphs of interesting values.log.
2.9. Object Query Updates
The object query user interface has been improved. and are logged to the psmgc.1. “Query Objects”.1
Diameter access logging is implemented. “Automatic Actions”.
2.
• Average lifetime values for all object types are now exposed via system diagnostics and the REST interface (/
rest/system/psm/model/objects). Garbage Collection Logs Enabled
Garbage collection logs are now enabled by default.
2. See Section 4.11. see Section 4.13. See Section 4. “Credit Control”.
2.8.10.1. See Chapter 4.
The user interface will now automatically reload when the PSM is restarted.8.

making for example counter updates less resource consuming.
• The configuration format now includes the exact PSM version that generated the configuration.
• It is now possible to use the same type for subscriber and group ID:s (for example strings) without risk of ID
collisions. as well as the
creation time.
• The RADIUS source can now be configured to use different secret keys for different source addresses/networks. contact Procera Networks support.1
• Additional model optimisations have been made. New Since Release 13. and >=. For instructions on converting.
7
. meaning that it is now more difficult to commit a broken
configuration. <. Configuration Migration
Configuration migration from 13. !=. any provided fields will
immediately be visible in the schema.
• New condition operations have been added to the JSON API: ==. <=.
• The configuration validation has been improved.
• When a plugin is enabled in the user interface (for example the CDR plugin). >.1 must be done manually by first exporting the configuration and then converting
it.15.
2.

New Since Release 13.1
.

From the main menu.
5. and gateway. Configuring the NetObject tree is described in Section 4. and scripts can be added (Section 4.
9
.
4. Download the license. select Updates > Update firmware
from the main menu (this step is not required)
The main configuration of the PSM consists of defining the database schema. mask.1.2. 1 stop bit. Configuration of the PSM).
• Ethernet . Change the IP address. username pladmin.9.
Note
If the PSM web password is changed when the PRE is configured with drop-if-psm-fail or close-
channels-if-psm-fail.7. select License > Download license. To update the firmware before connecting the PacketLogic into the network.1. Verify connectivity by pinging a remote IP address. it is necessary to also reconfigure the password that is set on all PREs in the CLI
under System Administration > High Availability > Shutdown channels on PSM fail.2. Connect to the Admin port with an ethernet
cable or to the console port with a serial cable.168. password pldemo00. Either can be used to edit the configuration in the menu-based
command-line interface (CLI). “Model”.
Additionally.2. see the hardware guide for the system.
2. enable password
pldemo00.
4. IP 192.1.
1. “Sources”. “NetObject Tree”.
3. From the main menu.
select Network Configuration > Ping IP address.25. Consult the documentation of the authentication
server. “Provisioners”.use SSH.3. logging can be configured (Section 4.1. To locate the Admin and console ports. From the main menu. Initial Installation and
Configuration
1. Configuring the provisioner is described in Section 4.6. 8 bits.4. port 42002.
2.
If the PSM is to be part of a redundancy cluster.9600 baud. Configuring sources is described in Section 4.
3. Initial Installation
and Configuration
Chapter 3. This configuration is available in the web
interface (Chapter 4.4.1. no flow control. select Network Configuration > IP
Configuration > Admin interface. see Section 5. “Scheduler”). configuring the adapter to insert subscriber data correctly in the PacketLogic
system NetObject trees. Configuring authentication servers is not part of this document. configuring the provisioner to update the associated PacketLogic systems. Configuring the schema is described in Section 4.
“Scripting”) and scheduled (Section 4.1.
• Console . and configuring
the authentication servers to send information to the PSM source.1. “Configuring Redundancy and High Availability”. setting up the correct sources to
receive subscriber information. password pldemo00.1. “Logging”). Power up the PSM system before cabling it into the network. no parity.

Initial Installation
and Configuration
.

Importing takes such a file and applies the
configuration in the file to the PSM. The sections are opened by clicking them in the left-
hand navigation pane. Configuration of the PSM
Chapter 4.
4.1.
Figure 4. change. Configuration of the PSM
The web interface of the PSM is accessed with the URL:
https://<IP of PSM>
The PSM web interface has three main sections.1. The PSM web interface
4. In each section there are items
which are displayed in the main window when selected.
There are two buttons available at the top of the configuration pane:
• Commit saves the changes made to the configuration database. and Status.
• Revert reverts (undoes) the changes made since the last commit.1. Configuration. Manage
This contains options to export and import a configuration.1. Tables.
11
. and import the PSM configuration. Exporting to file creates a file containing
the current configuration with JSON content and downloads it. export. Configuration
This section has options to view.
The PSM configuration can be exported to or imported from a file.

1.
Figure 4.
The tables contained in the PSM schema is shown in the schema view.2. Depending on the type. This shows the schema of the database in the PSM. Note that attributes of string type that do not contain
unique values should have the Cache values checkbox selected to increase performance.
12
.2. Configuration of the PSM
4. additional configurations
are available when expanding the arrow next to the attribute. Model
The database schema is configured in the Model pane. attributes can be added by
filling in an attribute name and selecting the type of the attribute.
• View holds actions to expand or collapse the schema view. The schema editor
The top bar holds the following buttons:
• Schema holds an action to add a table to the schema. For each table.

3. Expanding the schema attributes
4.
Boolean This type validates and holds a boolean value.
13
. for example
"00:11:22:33:44:FF". Schema attributes and types
Attribute types
The following data types are always available for use when defining attributes:
String This type validates and holds a string value. for example "true".
Set of Strings This type validates and holds a set of string values.
Integer This type validates and holds an integer value between -2^63+1 and +2^63-1.2. Configuration of the PSM
Figure 4.1.1.
MAC Address This type validates and holds a MAC-48 address.

which will be evaluated to
the current time when the operation is executed.
3GPP IMEI SV This type validates and holds data as defined in the 3GPP standard for the
attribute 3GPP-IMEI-SV. If a number is supplied it
will be interpreted as the number of seconds since 1970-01-01 (also known
as Unix time). The data type
is commonly used when the number of counters is unknown and cannot be
specified in advance. The counters can then be held in an object set.0/24"
Example of IPv6 address: "2001:0db8:85a3:0042:1000:8a2e:0370:7334"
Example of IPv6 network address: "2001:db8::/32"
3GPP User Location Info This type validates and holds data as defined in the 3GPP standard for the
attribute 3GPP-User-Location-Info. It is only used together with
the state attribute.000Z".
Limit set This type validates and holds an array of limits. “Scheduled Reset of Byte
Counters”). for example "1117770012345600".
Object set This type validates and holds a set of objects. Values are assigned
using a CRON string (read more in Section A.
Example:
14
. Configuration of the PSM
IP Network This type validates and holds an IP network address of one of the following
types: IPv4 address. IPv6 address or IPv6 network
address. IPv4 network address. and IPv4 and
IPv6 network addresses are written in CIDR notation.
3GPP MCC MNC This type validates and holds data as defined in the 3GPP standard for the
attribute 3GPP-MCC-MNC. an IPv6 address
in eight groups of four hexadecimal digits separated by colons. Values are assigned
and represented using a string in the following format: yyyy-MM-
dd'T'HH:mm:ss.
Timestamp This type validates and holds a timestamp.168. the string "0 0 0 ? * 1" is interpreted as
"run once a week at midnight on Sunday".
Schedule This type validates and holds a data type for scheduling.
Example of IPv4 address: "192. For example.0. The limits in the limit set contain an integer (the lower limit
for traffic) and a string (the name of the state). The object set must have a
unique key and can have a number of additional attributes.10"
Example of IPv4 network address: "192. for example "2010-05-20T15:00:01.0.168. The automatic actions under Model
> Automatic actions use the schedule attribute to run jobs periodically at
specified times or dates. The
special string "now" can also be used for input.2.SSSZZ. for example "70101". for example "0132f40204a451cd".7. An IPv4 address is written in a dotted-quad notation.

All the specified attributes must have the
same data type and are looked up in the order they are listed in the attribute
configuration. the result null is returned.
State (String) This type validates and holds a state.. The
type operates on a string.
Example: A subscriber has a 'Base' and a 'Bonus' service. LENGTH: 50".
In the attribute definition.port. The current service
is set to the first defined value of the 'Bonus' and the 'Base' service. from which values are parsed and extracted. The attribute uses a limit set attribute
and an integer key to look up and return the value of the state attribute in the
limit set as a string. The regular expression capture is "^PORT:
([0-9]*).*$".
15
.
Example: An attribute called 'modemInfo' has a capture group named
'port' with the type integer.
Regular Expression Capture This type validates and holds a value derived from a regular expression. The data type returns the
first attribute value that is not null. It adds the values of the
specified attributes. and returns an integer. Configuration of the PSM
Total (Integer) This type validates and holds a sum of values.
Example:
First Defined Value This type depends on the specified sub-attributes. If there
is no match in the indata string. optionally weighted. This would return the integer value '800' given the indata string
"PORT: 800.modemInfo. It would then be possible to reference 'port' as
subscriber. one or more capture groups can be defined with
name and data type. A string attribute will always be created automatically
for the indata string.

Given a key attribute. The
attribute 'serviceInfo' references a table called 'Services' with the columns
'service' (string) and 'limits (integer). If this attribute is null the object will never be
deleted by the system in this manner. Some
attributes provided by plugins may or may not result in this value getting updated
when changed. optionally
with added hashing salt.
creationTime This is a read-only timestamp that is set when an object is created and never changes
after that. a row in the referenced table is returned. It is a lookup reference to a
specified table.
Attributes
In addition to any custom attributes.
or points to an object of the wrong type.
16
. Defaults
The Defaults view shows the options and default values that are applied to the model. The default value for this attribute can be
configured separately for each object type. then the sessions will be automatically be deleted when their
owning subscriber is deleted.
When creating a new object via the API:s. It
would then be possible to reference the limit as subscriber.g. limit: 100}.
updateTime This is a read-only timestamp that is set when any normal attribute is updated. {"service": "Gold". See the details for each plugin for more information.1.
Example: A subscriber has the attribute service with value 'Gold' and
another attribute of the type table reference called 'serviceInfo'. e.
persistent This is a boolean value that determines if an object should be automatically deleted
if it does not have any references (false) or not (true). if the default value is set to
false for sessions.
Hash This type validates and holds a hash value.limit. the value of this attribute will be set to
true by default if not any other value is specified.
oid This is a read-only integer value that specifies the object ID of the current object. but will
never be done before the set time. The result of 'serviceInfo' will be the
table row where the service = 'Gold'.
4.
The actual deletion may be delayed some time for performance reasons.
parentOid This is an integer value that specifies the object ID of the parent object. will result in an error. is hashed using the selected function.
expiryTime This is a timestamp that determines if/when an object will be automatically deleted. For example. These are
described below.2.serviceInfo.2. If a parent object
is deleted then this attribute will automatically be set to null for any remaining
children. there are some attributes with special meaning that always exist. An object is referenced
if it has a parent or at least one child. The value of an attribute. or null if
no such object exist. Trying to set this attribute to an invalid ID that does not exist. Configuration of the PSM
Table Reference This type validates and holds a table reference.

may also be
configured here. “Scheduled Reset of Byte Counters” for an example of how to use automatic
actions. The
default values should normally be set under each attribute in the schema configuration. can
be configured in the Automatic actions view.4. Configuration of the PSM
Figure 4.2.
Figure 4. Storage
The Storage view shows the configurable options for type of storage and amount of memory.
17
.3.2. Other updates that can be performed automatically.7.1. These parameters
are typically left unaltered.
• Storage type is the type of storage used.5. Defaults view
• Max sessions per subscriber defines the number of sessions a subscriber is allowed to have.1.2. Automatic Actions
Automatic updates to the schema.
• Group/Subscriber/Session defaults allow the default values of attributes to be changed during run-time. See Section A. such as deletion of expired sessions or periodic resets of volume counters. Automatic actions view
4.4.
4.

6.1. Sources
Figure 4.
and how to make use of that information. Sources configuration example
This section configures the data sources that are available to the PSM.3. Configuration of the PSM
• Mapped memory is the amount of memory mapped by the storage component.
4.
The Sources view has a Source button in the top bar. with the following actions. All of the actions create a new
source of the selected type:
• New RADIUS Source
• New DHCP Source
• New DHCPv6 Source
• New JSON Bulk Source (TCP)
• New JSON Bulk Source (UDP)
• New JSON RPC Source
18
. Sources are also used for setting up traffic
counters and using APIs. The sources are configured to determine what to look for in the received source packets. Sources are used to receive and interpret
data to maintain the correct mapping between subscribers and sessions.

10.0. This will typically be localhost or 0. See
Section 4. “Declarations”.1.
• Declarations specifies the variables to be used as conditions in rules. “RADIUS with Attributes”.
• Listen port is the port used by the DHCP feed. “Access Logging”.3.
• Listen port is the port used by the RADIUS feed.
• Cache DHCP requests if enabled. The default port is 1813. see
Section A.3.
• Access Logging specifies what attributes in the RADIUS feed should be sent to the access log. and attribute ID. caches DHCP requests to ensure that all required fields are available by
combining fields from request and reply packets. and has the configurable actions
described below.2.1.
4.
• Tags sets a value that all RADIUS operations will be tagged with.0 if
the PSM receives the RADIUS feed.3. RADIUS Source
For a RADIUS source. DHCP Source
For a DHCP source.1. the following parameters can be configured:
• Listen host is the host where the RADIUS feed can be picked up. See Section A. See Section 4. Any attribute in the feed can
be added to the list. Configuration of the PSM
• New SOAP Source
• New REST Source
4.9.
• Rules defines the rules to apply to messages received by the source.
• Declarations specifies the variables to be used as conditions in rules.0.
• Tags sets a value that all DHCP operations will be tagged with. See Section 4.3.3.10.1.1.3. The default port is 5470.2. “Declarations”.
19
.0.0 if the
PSM receives the DHCP feed.1.
For an example of a simple configuration for a RADIUS integration provisioning two PacketLogic systems.1.3.1.1. “Rules”.
• Request cache size is the number of DHCP packets kept in the cache.1.0.
• Attributes determines what attributes should be fetched from the RADIUS feed.1.3.9. the following parameters can be configured:
• Listen host is the host where the DHCP feed can be picked up.3. See Section 4.
• Secret is the network and the secret used in the RADIUS handshake. vendor ID. Counters Source
The Counters source is always available in the top view of the Sources pane. This will typically be localhost or 0.
• Send responses determines wether the PSM shall acknowledge the RADIUS commands it receives.
4.11. “Configuration of the PSM” for an example of how to use the Counters source. See Section 4. “Rules”.
• Tags sets a string that all counter operations will be tagged with. by specifying the attribute name.
• Rules defines the rules to apply to messages received by the source.

1. See
Section 4.3. See Section 4.1. “Rules”.0.3. “Access Logging”. This will typically be localhost or 0. ID. See Section 4. This will typically be localhost or 0.
• Listen port is the port used by the DHCPv6 feed.
• Listen port is the port used by the JSON Bulk messages.1.1. JSON RPC Source
A JSON RPC source has the following parameters:
20
. the following parameters can be configured:
• Listen host is the host where the DHCPv6 feed can be picked up.0.
• Tags sets a value that the message operations will be tagged with. and type of the option. The default port is 3996.
• Variables is used to define what data to fetch from the JSON Bulk source.6. See Section 4. See Section 4.10.
• Declarations specifies the variables to be used as conditions in rules.3.3.
• Declarations specifies the variables to be used as conditions in rules.9.3.11. See Section 4.3.5.1. by specifying name and type of
the data. “Declarations”.1.1.
4.1.3.1. Configuration of the PSM
• Options is used to define what data to fetch from the DHCP feed.
• Rules is used to define the rules to apply to messages received by the source.
4.11.10.
• Request cache size is the number of DHCPv6 packets kept in the cache. JSON Bulk (TCP/UDP) Source
A JSON Bulk (TCP/UDP) source has the following parameters:
• Listen host is the host where the JSON Bulk feed is received. “Rules”.0 if
the PSM receives the DHCPv6 feed. Any option in the feed may be added to the
list by specifying the name.3.
• Rules is used to define the rules to apply to messages received by the source.
• Access Logging specifies what attributes in the JSON Bulk message should be sent to the access log. and type of
the option. caches DHCPv6 requests to ensure that all required fields are available by
combining fields from request and reply packets. “Access Logging”.
• Tags sets a value that all DHCPv6 operations will be tagged with.1. “Declarations”.
• Options is used to define what data to fetch from the DHCPv6 feed.11.9.3. ID.0.
“Access Logging”.0. by specifying the name.
• Access Logging specifies what attributes in the DHCPv6 feed should be sent to the access log.10.
• Rules is used to define the rules to apply to messages received by the source.3. DHCPv6 Source
For a DHCPv6 source.9.
• Declarations specifies the variables to be used as conditions in rules. See
Section 4.1. “Declarations”.4.1.
• Cache DHCPv6 requests if enabled.3. “Rules”. The default port is 5460.
4. See Section 4.3. See Section 4.0 if the
PSM receives the messages.
• Access Logging specifies what attributes in the DHCP feed should be sent to the access log.

21
. IP networks. date. “Declarations”.
• Variables is used to define what data to fetch from the REST source. The SOAP
source configuration consists of the following parameters:
• Listen host is the host where the SOAP messages are received. or integer values.9. The default port is 3994.1.1. see Appendix C.
• Listen port is the port used by the SOAP messages.9. The default port is 7627.3.
• Listen port is the port used by the messages. REST Source
A REST source makes it possible to provide the PSM with information using the REST interface.10.
• User name is the user name for the SOAP connection. Configuration of the PSM
• Listen host is the host where the messages are received.3. integers. The
operators used to define declarations can result in boolean values.1.
• Password is the password for the JSON RPC connection. Declarations
Declarations are used to define variables that can be used as conditions in rules.
• Password is the password for the SOAP connection. by specifying name and type of the data.0. or extract for example time.0 if the
PSM receives the messages.3.
4.7.0. This will typically be localhost or 0. PSM-JSON-RPC protocol. hex strings.3. SOAP Source
A SOAP source makes it possible to provide the PSM with information using the PSM SOAP API.
and strings. This will typically be localhost or 0.
• Authentication type is either none or HTTP basic.
• Tags sets a value that the REST operations will be tagged with.
4.0.1.0.8.1.
4.0 if the PSM
receives the messages. The REST
source configuration consists of the following parameters:
• Name is the name of the REST source. The variables can use information
from the source feed to create boolean declarations.
• Declarations specifies the variables to be used as conditions in rules.3.
• User is the user for the JSON RPC connection. See Section 4. See Section 4.
For details on the JSON RPC protocol.
• Rules is used to define the rules to apply to messages received by the source. “Rules”. time stamps.
Below is an example of how to use declarations in a RADIUS source.

1.3.7. which objects should be
created. as well as performing the
action.
22
. The rules are used to determine when the PSM should take action. Configuration of the PSM
Figure 4. and group. updated. or delete) that
is selected in the rule. The
subscriberId variable converts the Calling-Station-Id attribute to an integer to be used as a subscriber ID. Declarations in sources
This configuration creates the boolean variables isStart. The rule
isStartOrUpdate creates a subscriber and a session object for a connection. Clicking the Add Rule button shows a view
where a condition for the rule is set (by selecting a variable specified in the Declarations pane). Add Rule and Remove Selected. and isUpdate by evaluating the RADIUS attribute
Acct-Status-Type.
Below is an example of how to create rules in a RADIUS source. and delete objects of
the types subscriber. Rules use the declarations to set conditions for the rules. and a sub operation
specifying the actions to be performed is defined.
The Sub op view has different parameters depending on the type of operation (create. and performing the action.
4. isStop. update. The variable isStartOrUpdate is then declared using the isStart and isUpdate variables. session. update. set. The Add button creates the sub operation. using the declarations described above. set.
The Rules pane contains two buttons. Rules
Rules are used to determine what actions to take depending on the source information. or deleted. The sub operation can create.10. and also for further filtering the items that the rules
should be applied on.

23
. and if the IP address is already mapped to a
session in the PSM. Available options are OFF.
• The Log severity option sets a priority of the log message.9. by making it possible to check that the system receives data
properly. the
attributes available for logging are the ones specified under Attributes in the RADIUS source. Access Logging
Access Logging can be used for troubleshooting. since they are evaluated from the top down.12. see Section 4. from
which it can extract subscriber and session information. The following two sub operations create the subscriber and session objects for the connection. “Sources”). The RADIUS snooper requires a JSON Bulk source to
be set up in the Sources section (Section 4. The MSG
field is a comma-separated list of the values that are specified in the Fields configuration. the values will be separated by a semicolon. Snoopers
The top bar of the snoopers pane has a Snoopers button. the next sub operation will be evaluated. Configuration of the PSM
Figure 4. for
example "access.1.1. TRACE. In cases where access monitoring is available in multiple systems. which holds the following actions:
• Create RADIUS Snooper
• Create Packet Snooper
4. INFO. Access logs are logged with names starting with "access. The TIMESTAMP field contains the time of the log event.1.
4. The No match action
parameter is set to Continue with next operation in the first sub operation.3. For a RADIUS source. RADIUS Snooper
The RADIUS snooper is a passive listener.11.radius. DEBUG. The order and contents
of the resulting columns are user defined. the access logging can be aggregated
and correlated to get a full view of system health.
4.1.
• Listen interface is the interface where the RADIUS feed can be picked up.
The RADIUS snooper has the following parameters:
• Dictionary file is the file path to the RADIUS dictionary to use on the PSM file system. an empty column is emitted.
WARN. “Logging”. which means that if the conditions of
the Delete Session sub operation do not match the connection. The destination host of the access log is configured in the
Logging pane.3.1.request. the attributes specified under Options can be used.12. Rules in sources
The first sub operation deletes a session if isStartOrUpdate is true.8. If an attribute is missing in the message. and ERROR.
The order of the sub operations is important.
Each syslog message consists of several fields.1813".3.
• The Fields option specifies which attributes should be included in the access log. A JSON Bulk source uses the attributes
specified under Variables.". and relies on seeing a complete RADIUS feed on an interface. For the DHCP and
DHCPv6 sources.3. If
a column contains more than one value.1.

3. The syntax
of the packet filter is that of tcpdump/pcap-filter. Packet Snooper
The generic packet snooper requires a corresponding UDP source (a RADIUS source or a DHCP source) to be
configured (see Section 4.
Figure 4. Creating a new Diameter Daemon
24
. Configuration of the PSM
• Packet filter determines how to select packets from the RADIUS feed that the snooper shall process.
• Destination port is the port to which the packets picked up by the snooper shall be sent.
4. Diameter
Clicking the Diameter Daemons button in the top bar of the Diameter pane and selecting the Create Diameter
Daemon option displays a text editor where a Diameter configuration is entered.3.12.1.
The generic packet snooper has the following parameters:
• Listen interface is the interface where the packet feed can be picked up.9. “Sources”).1.13.
• Packet filter determines how to select packets from the RADIUS feed that the snooper shall process.2.3.
• Destination host is the host to which the packets picked up by the snooper shall be sent.
4.1. The syntax
of the packet filter is that of tcpdump/pcap-filter.
Below is an example Diameter configuration.

2. Diameter Attributes
The Diameter attributes are mapped to the schema using the format $ATTR-<NAME> <schema-field>.
ATTR-IPV4.13.3. “Diameter Access Logging”)
• ACCESS-LOG-CMD-CCR (default is 1)
• ACCESS-LOG-CMD-CCA (default is 1)
• ACCESS-LOG-CMD-RAR (default is 1)
• ACCESS-LOG-CMD-RAA (default is 1)
• ACCESS-LOG-CMD-ASR (default is 1)
• ACCESS-LOG-CMD-ASA (default is 1)
• ACCESS-LOG-CMD-DWR (default is 0)
• ACCESS-LOG-CMD-DWA (default is 0)
• ACCESS-LOG-CMD-CER (default is 1)
• ACCESS-LOG-CMD-CEA (default is 1)
• ACCESS-LOG-CMD-DPR (default is 1)
• ACCESS-LOG-CMD-DPA (default is 1)
4. and also in
CCR-U messages if the attribute has been updated. the attribute will be included
in all CCR messages.
The suffixes _DISABLE and _STATIC can be added to all ATTR keywords. The _STATIC suffix specifies that
the attribute is not a schema attribute and that it can not be changed.
Attributes available for schema mapping are:
• ATTR-APN
26
.
it should not be followed by any parameters. as in $ATTR-MSISDN callingStation 1. Configuration of the PSM
• EVENT-RAT-TOGGLE (default is -1)
• EVENT-IP-CAN-TOGGLE (default is -1)
• EVENT-SGSN-TOGGLE (default is -1)
• EVENT-USER-LOCATION-CHANGE-TOGGLE (default is -1)
• EVENT-USAGE-REPORT-TOGGLE (default is -1)
• ACCESS-LOG (default is 0)
• ACCESS-LOG-STR-LENGTH (default is 300)
• ACCESS-LOG-PORT (default is 1814)
• ACCESS-LOG-FORMAT (see Section 4. If the parameter is set to 0 the attribute will be included in CCR-I messages.1. and ATTR-MSISDN which have 1 as default value. Adding the _DISABLE suffix to
a keyword will disable the attribute. which means that the contents of the ATTR-RULE will be mapped
to the ruleName schema field. Most attributes have 0 as default value.1.3. The value of a _STATIC attribute is stated
directly in the configuration.
There is also an optional parameter used to specify in which CCR messages the attribute should be included. If an attribute is disabled as described above. for example ATTR-IP-CAN_DISABLE. except ATTR-IMSI. An
example of this is $ATTR-RULE ruleName.13. for example ATTR-RAT_STATIC 1000. If
the value of the parameter is 1.3.

The
logging priority is also set in the command line interface. Diameter Access Logging
To enable Diameter access logging. where a UDP host and a facility for the log is added.13. Configuration of the PSM
• ATTR-BEARER-USAGE
• ATTR-CALLED-STATION-ID
• ATTR-CC-REQUEST-COUNTER (this attribute is mandatory and must have a corresponding attribute in the
schema)
• ATTR-FLAGS (this attribute is mandatory and must have a corresponding attribute in the schema)
• ATTR-IMEISV
• ATTR-IMSI
• ATTR-IP-CAN
• ATTR-IPV4
• ATTR-IPV6
• ATTR-MCC-MNC-IP
• ATTR-MSISDN
• ATTR-NAI
• ATTR-NAS-IP
• ATTR-OFFLINE
• ATTR-ONLINE
• ATTR-PRIVATE
• ATTR-RAT
• ATTR-RESULT (this attribute is mandatory and must have a corresponding attribute in the schema)
• ATTR-RULE
• ATTR-RULE-BASE
• ATTR-SESSION-ID (this attribute is mandatory and must have a corresponding attribute in the schema)
• ATTR-SESSION-OID
• ATTR-SESSION-PARENT-OID
• ATTR-SGSN-IP
• ATTR-SIP-URI
• ATTR-SUBSCRIBER-OID
• ATTR-USER-LOCATION-INFO
• ATTR-3GPP-SGSN
• ATTR-3GPP-SGSN-IPV6
• ATTR-3GPP-RAT
4.3.
27
.3. a remote syslog host should be added in the command line interface. This
is done in System Administration -> Logs -> Syslog.1.

which is followed by a string containing numbers
28
. The log
format is specified using the ACCESS-LOG-FORMAT attribute. CLI access logging
In the Diameter Daemon editor. Configuration of the PSM
Figure 4. access logging is enabled by setting the ACCESS-LOG attribute to 1.10.

Configuration of the PSM
that indicate what is included in the log. an empty column is emitted.
Each line in the resulting log will contain a comma separated list of the values specified with the ACCESS-LOG-
FORMAT string. If a column
contains more than one value. the following numbers can also be used. The number 5 in the format string indicates that the number that follows
is the ID of an Attribute-Value Pair (AVP).
1 Source type (Gx)
2 Syslog port
29
.
Below is an example of how to use access logging in the Diameter Daemon. the values will be separated by a semicolon.
$ACCESS-LOG 1
$ACCESS-LOG-FORMAT 145 144 3 5 443 5 263 0 5 416 5 415 5 268 5 4 5 6 5 8
5 30 5 264 5 293 5 1006 5 1032 5 1001 5 1002
145 Priority (which is set in the command line interface)
144 Facility (which is set in the command line interface)
3 The IP address of the PSM
5 443 Subscription-Id
5 263 Session-Id
0 CCR command
5 416 CC-Request-Type
5 415 CC-Request-Number
5 268 Result-Code
54 NAS-IP-Address
56 3GPP-SGSN-Address
58 Framed-IP-Address
5 30 Called-Station-ID
5 264 Origin-Host
5 293 Destination-Host
5 1006 Event-Trigger
5 1032 RAT-Type
5 1001 Charging-Rule-Install
5 1002 Charging-Rule-Remove
In addition to the ID numbers above. If an attribute is missing in the Diameter message. and an explanation of the mapping.

The NetObject tree in
the Static Ruleset corresponds to the NetObjects that can be viewed and used in the Objects and Rules editor in
the PacketLogic client. Configuration of the PSM
4 PCRF port
4. which specifies the NetObject path to where all
dynamic and static NetObjects will be provisioned. and group information to the target NetObject tree structure
the PSM NetObject tree syntax is used (see Appendix B.2. A session will generate
dynamic items in a provisioner only if the attribute specified in the By: Attribute field contains the name of the
provisioner. and not(). and session data to the NetObject Tree. and groups).
The Provisioning filter checkbox is used to distribute sessions among provisioners.
To perform the mapping from the subscriber. subscriber. session. and can thereby adapt to a complex NetObject tree structure.
The Dynamic ruleset maps the internal group. The NetObject
Tree in the Dynamic Ruleset corresponds to what can be seen using LiveView in the PacketLogic client. NetObject Tree
The NetObject Tree configuration contains the structure of NetObjects to be provisioned to the PacketLogic. sessions. The syntax supports functions
such as all(). NetObject Tree Syntax.1. NetObject tree configuration
The NetObject Tree configuration contains the NetObject root.
The Static ruleset is used for initial population of the NetObject Tree on the PacketLogic.4.
Figure 4. if(). any().11.1.4. and
instructs the provisioner (see Section 4. “Provisioners”) where in the NetObject tree on the PacketLogic to
put the dynamic items (subscribers.
30
.

The following
is specified:
• Add new address is the field that specifies the IP address to the PacketLogic system holding the static ruleset.
• Password is the password for the account used to log in to the static ruleset system. that is whether the provisioning shall start when
the PSM starts (Online).4.1.5.
• Password is the password for the account used to log in to the dynamic ruleset system.1.1. “Redundancy”.4. Redundancy
This section configures the data replication part of the redundancy functionality.
• Realtime timeout (ms) is the delay allowed for a realtime system to respond before trying to reconnect.
• Username is the account to use to log in to the static ruleset system.
31
.
• Filtering group specifies the name of a filtering group. to minimize the consequences of system failures. but can be performed per filtering group according to the configuration
in the NetObject tree. Provisioners
The Provisioners configuration defines the PacketLogic systems that the PSM shall provision.2. Example configuration
4. that is whether the provisioning shall start when
the PSM starts (Online).
• Online or Standby determines the startup state of the PSM.
• Batch limit (items)
• Static rulesets specifies the PacketLogic system that shall be provisioned with the static ruleset. or if it shall be manually started (Standby). and is used with the filtering attribute checkbox and
attribute in the NetObject tree to perform selective provisioning.
4. Configuration of the PSM
4.1. This means that provisioning must not be the
same for all PREs in a proxy group.
For an overview of redundancy. Redundancy allows configuring
standby PSM systems to take over in case of a system failure.
• Static ruleset is the address to the PacketLogic system that holds the static ruleset.1. or if it shall be manually started (Standby).
• Username is the account to use to log in to the dynamic ruleset system.
• Dynamic rulesets
• Add new address specifies the IP address to the PacketLogic system holding the dynamic ruleset. see Section 5.
• Online or Standby determines the startup state of the PSM. The provisioners
have the following available options:
• Ruleset timeout (ms) is the delay allowed for a ruleset system to respond before trying to reconnect.

subscribers. and the script code.
4. “Scheduler”).
• Reconnect delay (ms) is how long the data replication client will wait before attempting to reconnect to a server.1. consisting of a name. Redundancy configuration
Note: The redundancy will ensure that groups. Client Settings
• Max server inactivity time (ms) specifies how long the data replication client will allow a server to be inactive
before attempting to reconnect. which has the folloing actions:
• New Script allows entering a new script.1.
Redundancy configuration has the following options:
4. Server Settings
• Max client reply time (ms) specifies how long the data replication server will wait for a client to respond before
attempting to reconnect. The scripts can then be run by the scheduler (see
Section 4. The top bar has a Scripting button.1.
• Listen host is the IP address where the server listens for client messages.1.3.
4.12. sessions. Scripting
The PSM allows adding scripts.2. and tables are synchronized among all PSM
nodes in the cluster.7. This can be Offline.
4. Configuration is local to each system and not synchronized.
• Remote Servers is a list of servers to which this PSM will connect to replicate data. Configuration of the PSM
Figure 4.5.5.1. Controller Settings
Startup state is the redundancy state to start in.
• Listen port is the port where the server listens for client messages.6.5. mappers. a type (Python or JavaScript).
32
. or Master. Slave. and triggers.1.

• Format is the type of data located at the given URL.13. Table Import
A Table Import is a scheduled task to fetch data and insert it into one of the database tables in the PSM. A scheduled task can be added by clicking
the Tasks button in the top bar of the main pane. The Trigger
has the following options:
• Trigger name sets the name of the trigger. a point in time during the interval to execute the table import
can be defined. directory cleanup.1. weekly. After selecting the type of interval. like
table and subscriber import.7. daily. Configuration of the PSM
• New Mapper specifies the name and the code.
• Filter attribute
• Template
4. Scheduler
The Scheduler in PSM can be configured to run certain tasks at defined intervals.1.7. Table Import
A scheduled table import takes the following options:
• Interval indicates the interval at which the table import should be executed. or script execution.
Figure 4. subscriber import.
33
. The mapper is used
to map information from one table to another.
4. This can be hourly.
• New Trigger specifies the name and the code of a trigger used to perform tasks on certain events.1. of a mapping function.
or monthly. Once something is entered in the URL field. The mapper can be used by for example scheduled tasks.
• URL is the location from which to retrieve the data. The scheduler can perform a
table import. the other fields
become visible. written in JavaScript.
• Trigger on event specifies the kind of action that the event will trigger.
• Target table is the table in which to insert the data. This can be JSON or CSV.

Subscriber Import
A Subscriber Import is a scheduled task to fetch data and use it to add subscribers in the PSM.14.
weekly.
4. This can be hourly. Directory Cleanup
A Directory Cleanup is a scheduled task to remove files from the PSM file system to prevent the disk from running
full.1. See Section 4. Subscriber Import
A scheduled subscriber import takes the following options:
• Interval indicates the interval at which the subscriber import should be executed.6.1. “Scripting” for
information on mappers.7. If
the box is checked. or monthly.
• Mapping function is an optional function to apply to each line of the data before inserting it into the table.3.1. daily.
4. See Section 4.
34
.
Figure 4. “Scripting” for
information on mappers. a mapper defined in the Scripting pane can be selected. If
the box is checked.1. the point in time during the interval to execute the
subscriber import can be defined. Configuration of the PSM
• Mapping function is an optional function to apply to each line of the data before inserting it into the table.
• URL is the location from which to retrieve the data in CSV format. a mapper defined in the Scripting pane can be selected.2.6.7. After selecting a type of interval.

the point in time during the interval to execute the
scheduled cleanup can be defined. or monthly. Directory Cleanup
A scheduled cleanup takes the following options:
• Interval indicates the interval at which the scheduled cleanup should be executed.
weekly. After selecting a type of interval.1. daily. This can be hourly.
• Path is the file system path to the directory where files are to be removed. Configuration of the PSM
Figure 4. Files newer than this at
the time the task is run are not removed.
35
.
• Number of days to keep files defines how old files must be to be removed by the task.7.4. Script Execution
A Script Execution is a scheduled task to execute a script defined in the Scripting pane.15.
• Free space limit before cleanup (MB)
4.

1.8. CDR
This shows configuration options for Charging Data Record (CDR) generation.1.1.
• Script selects which script to run (defined in Section 4. Available plugins are CDR. For an overview of how to
configure CDR generation.3.6. To use CDR generation.
4. Configuration of the PSM
Figure 4. Script Execution
A scheduled script execution takes the following options:
• Interval indicates the interval at which the script should be executed. The CDR configuration consists
of several subcomponents. “Scripting”. the point in time during the interval to execute the script can be
defined.1. Each data item can be assigned an attribute defined in the schema by using the drop-down list. weekly. see Section A. Attributes
Attributes contain a mapping of which schema attributes correspond to the set of data items that are required for
CDR writing. daily.8. “Generating Charging Data Records (CDRs)”.16. The
CDR attributes pane has the following parameters:
36
.1.1. or
monthly. This can be hourly. Plugins
This shows available plugins and has options for enabling and disabling them.
4. After selecting a type of interval.1.
4.8. the CDR plugins must be enabled. CDR:
Simple Service Mapping and Credit Control.

or if no domain list can be found for the SGSN.
• The Roaming condition is evaluated based on the tables referenced by the apnInfo and sgsnInfo session fields
in the following way:
• The APN domain for the session is looked up using the apnInfo table reference in the session schema.
the session is considered roaming.2.
• The domains managed by the SGSN of the session are looked up using the sgsnInfo table reference in the
session schema. Attributes
4.
• If the APN domain is in the domains managed by the SGSN.1. according to the following mapping:
0100 Hot billing
0200 Flatrate
0400 Prepaid
0800 Normal
• The APN of the profile is compared to the session field pointed out by the APN attribute in the CDR Attributes.8. Configuration of the PSM
Figure 4. the session is not considered roaming. and wether a session is considered roaming or not. If the
APN domain is not in the domains managed by the SGSN.17.
• The charging characteristic of the profile used for the CDR of a session is determined by the session field pointed
out by the Charging characteristics attribute in the CDR Attributes editor. The
table referenced has a domain column.
37
. APNs.1. Profiles
Profiles are used to configure how CDRs are written. The table referenced has a domains column. Profiles are matched to sessions based on three criteria:
charging characteristics.

Connections.4.
4.8.3. Credit Control
The credit control function allows the PSM to query an OCS (Online Charging System) for quotas to use for
subscribers. The quotas are linked to services. Writer
The Writer configuration defines how CDRs are written to file on the PSM disk.
• CDR file extensions is the file ending (suffix) of the CDR files written to disk. where ShapingObject is the
name of the ShapingObject counting for a specific service. or RAW CDRs which does not include the file header in TS 32. The Node Id should be unique for each node creating CDR files. When the limit is reached
the CDR is closed.297 CDRs.8. The following settings are available:
• Prepaid policy IDs contains a list of the policy IDs that are prepaid policies.279.1.2.1.3. Unless explicitly
needed.
• Max file open time (ms) is the maximum time a CDR file is allowed to be open. If this limit is reached. “CDR Extension Format”). Configuration of the PSM
• Time limit (ms) specifies the maximum time a CDR is allowed to be open.
• Max CDR file size (bytes) specifies a size limit for the CDR files. this field can be left empty. “Creating CDRs
for Services”).
38
. When the limit is reached the CDR
is closed.1.2.
• Volume limit (bytes) is the maximum amount of bytes a CDR is allowed to have. if enabled.8.8. and consists of the following
settings:
• Node ID is the name representing the PSM in the CDR files. the file is closed and
a new file is opened for writing.
• CDR writing enabled will. and
AVP Mappings. in order to discern it from CDR files gathered at
other nodes. if enabled. The services are mapped to a ShapingObject on the PRE in the Credit Control configuration. The Credit Control configuration has four menu options.
4. and ID is the identifier given to the counters for this
service in the CDR custom extension (see Section A.
The Credit Control plugin is enabled in the Plugins pane.
4. close a CDR when the time limit is reached even if the CDR counters are at 0.
even if no CDRs have been generated during that time.8. Services. This automatically adds credit control attributes in the
subscriber schema.
• Allow empty CDR batches will.297 CDRs but only the CDRs
themselves. the file
is closed and a new file is opened for writing. and act as limits to the traffic volume credit a subscriber is allowed
to use for the service.3.
• Max # CDRs in a file specifies a limit for the number of CDRs allowed in a file. the file
is closed and a new file is opened for writing. write a CDR file when the Max file open time (ms) limit is reached.
• Map of services contains a comma-separated list of ShapingObject:ID pairs.1. This can be TS32. SSM
The SSM (Simple Service Mapper) is used for customizing CDR generation (see Section A. If this limit is reached. This is used if the schema contains a
custom attribute named policyId (typically derived from a vendor-specific RADIUS attribute).
• Format is the format of the CDR files written. which is a format described in
3GPP TS 32.
• Allow empty CDRs will.
A service can be used to specify a certain type of application (for example Voice over IP) or type of traffic (for
example roaming traffic). If this limit is reached. if enabled. allow CDRs to be written to file on the PSM disk.1. Settings.

• Origin realm is the domain realm of the PSM. Settings
The basic configuration is edited under the Settings menu option.
39
.8.2.
• Destination realm is the realm of the OCS server that the PSM should connect to.1.
The configurable settings are:
• Origin host is the FQDN (Fully Qualified Domain Name) of the PSM.
• Vendor ID is the ID of Procera Networks.
• Product name is a string that identifies the name of the PSM product.
• Peer reconnect delay (ms) sets the time in milliseconds that the PSM waits until it tries to reconnect to an OCS
that has disconnected.
• Firmware revision is the revision number of the PSM.1. Configuration of the PSM
4.
• Watchdog timer (ms) sets the time interval in milliseconds for when the PSM sends heartbeat messages to the
OCS server.

8.
• Sync CC sessions (requires OCS support) enables or disables mirroring of the credit control session data to a
slave PSM.
• Peer send queue size (commands) sets the amount of commands the peer send queue can hold. continue as
if the transaction succeeded. Configuration of the PSM
• Peer inbox size (bytes) sets the size in bytes of the incoming message buffer.2. If enabled. Connections
The IP addresses and ports of the OCS are added under the Connections menu. the
transaction is terminated as if the it failed.
• Supported vendor IDs is a list of vendor IDs for all vendor-specific AVPs that the PSM supports.
40
.
4. This can be used to reduce the
amount of traffic to the OCS if subscribers create
many short-lived sessions.
Terminate If a transaction times out while waiting for a reply.
• Peer outbox size (bytes) sets the size in bytes of the outgoing message buffer.1.
• Failure handling has three available options:
Continue If a transaction times out while waiting for a reply.
When last session expires The credit control session for a subscriber is
terminated when the last service request for that
subscriber expires.
• Terminate condition has two available options:
When last session is closed Terminates the credit control session for a
subscriber when the subscriber is no longer online. the new PSM can connect to the OCS and resume the sessions in case of a failover. the
transaction is repeated with another OCS. If that times out as
well the transaction is terminated.
Retry and Terminate If a transaction times out while waiting for a reply.2. This
requires support from the OCS.

The following options can
be configured for a new service:
• Name is the name of the service. Always.
By attribute A boolean attribute in the subscriber schema is used to control if the subscriber
has a quota for the service.
When the threshold is reached. and By attribute. unless a quota is received from the OCS. unless the OCS provides a validity time.8.
• Open condition specifies when the PSM should ask the OCS server for the quota of a service. the quota is returned to the OCS. The Remove Selected button is used to delete services from the list.
Always The quota is requested as soon as the subscriber is online.3. Services
The services that the credit control should be applied to are added under the Services menu.
• Default validity time is a default time that the quota is valid. by clicking the New
Service button.
• Default volume quota is a default quota to use for the service. When the
time limit is reached. The options are
First use.
41
.
First use The PSM will ask for the quota when the service is used for the first time.
• Rating group is the service identifier defined in the OCS.
• Default volume quota threshold is a limit that is set lower than the volume quota received from the OCS server. and should correspond to the name of a ShapingObject on the PRE. or a new quota request must be sent to the OCS. This can be used to prevent
gaps where the subscriber has no access to the service during a quota request.1. Configuration of the PSM
4. and then the quota request is sent.2. the PSM sends a new quota request to the OCS.

• Attribute is used to select an attribute from the subscriber schema.1.
For the constant value option the following parameters can be configured:
• AVP is used to select an AVP to use for the mapping.2.8.5. Configuration of the PSM
4.4. AVP Mappings
The AVP Mappings menu is used to specify the attribute mappings between the subscriber attributes in the PSM
and the AVPs (Attribute Value Pairs) in the CCR messages. and is added automatically to the schema when the credit control plugin is enabled.2. Credit Control Counter Source
The credit control needs a counter source where the traffic counters are configured. The attribute ccsServices that is modified with this configuration is an object set
containing services.
4. Below are configuration
examples of a counter source.
42
.8. Attribute Mapping and Constant Value.1.
• Value is used to set a constant value to map to the AVP. Each
service in cssServices has byte counters for incoming and outgoing traffic that will be updated with the counter
information that the PRE provides to the PSM. The following options can be configured for a new attribute mapping:
• AVP is used to select an AVP to use for the mapping. There are two menu options when clicking the New
button. The Remove Selected button is used to delete mappings from the
list.

Configuration of the PSM
43
.

accepted values are:
44
. Configuration of the PSM
Each credit control service stored in ccsServices has the following attributes and types:
• name (string)
• validityTime (timestamp)
• limitReached (boolean)
• state (integer).

9. Several remote syslogs can be
specified.
or to the console on the platform. Logging Configuration
The PSM provides logs for analysis and troubleshooting. Configuration of the PSM
4. Logging
Figure 4.1.18. The logging function can log to syslog (local or remote). The log threshold to use is also configurable.
46
.

4. INFO. AUTHPRIV. The other options are: OFF. DEBUG. and ERROR. and LOCAL0 . see PatternLayout in Apache Logging.
Exporting tables is done by clicking the Export button at the top of the left-hand navigation pane when viewing
tables. The default is psm:%p %c %m%n.
• Format defines the format of the messages sent to the remote syslog host.2. WARN.
47
. with different log levels and different targets. Status
The Status view shows if the model is writable or standby. Configuration of the PSM
• Default log threshold specifies the default log level to use for the remote syslog messages.
• Address is the IP address of the syslog host. AUTH. if selected.
4. subscribers. This is useful in case a specific component logs excessively
at the log threshold defined at the top level. DAEMON.1. as well as the number of updates to the model along
with a set of values. The log format can be defined with
formatting strings. Status
4. which includes priority (%p).
In addition to generic PSM logging. where the log threshold to be used when sending messages to
the remote syslog host can be selected.
The remote syslog targets have the following options:
• Add new name is used to enter the name of the host to which syslog messages shall be sent. Tables
The Tables section contains options to import and export table data. message
(%m). individual loggers for different system components can be added using Custom
log levels.LOCAL7. The
options are: USER.
• LOCAL7 is one of the options in a drop-down list where the facility to use for the message can be selected. and sessions.3. It also shows real-time graphs for groups. the default logging that is done locally and that matches the Default log threshold
to the specified remote syslog. and a line break (%n). category (%c).
• TRACE is one of the options in a drop-down list. This will create and download a text file with all table contents as a python dict.
• Log defaults sends.3. Importing is done by
clicking the Import button and locating a file with the same format. For details on other formatting elements.

Configuration of the PSM
Figure 4.19.20.3.2.
4.
48
. Process information
This view shows the PSM related processes running on the PSM. Top
The Top view shows the list of processes run on the PSM. Status
4. The view of
the object will show the IDs and the attributes connected to that object. using the assigned ID of that object.3.3.
Figure 4. Clicking a column header will sort the list
based on that column. Query Objects
The Query Objects view can be used to inspect a PSM object. The information displayed corresponds to that in the top command available in most Unix
variants.

21. Configuration of the PSM
Figure 4. Query objects
49
.

Configuration of the PSM
.

Figure 5.
To monitor the operational status of the nodes.1. Additionally. Configuration is local to each node and not
synchronized.
Another option is to use a virtual IP address that the current master is responding on. “Redundancy”). the master (PSM 1 in the figure) receives the source input (for example RADIUS messages. to reduce the consequences of system or network failures.
Another is where all nodes monitor the operational status of the other nodes to ensure the actual systems are up
and connected. and tables) will always be identical on all PSM nodes in a cluster (other
PacketLogic nodes acting as electors do not synchronize any data). but due to the amount of data required. The slave takes no active role.
The parameters of the data replication is configured in the web interface (see Section 4.
however.
When a system is found to be faulty by not responding to heartbeat messages. This IP can then be used for all communication towards the PSM cluster (except configuration
and any read operations that should go to a slave).
denoted 1 in the figure). Hence.
The data (subscribers.
meaning that the information about subscribers and sessions along with any additional tables are always identical
on both PSM systems. Operation
5. sessions. Operation
Chapter 5. Write operations. only on the master. Figure 5.
The redundancy function will ensure that the master is the only one reading messages from the source. the state of the PSM can be polled using
SNMP. These heartbeat messages exist in two forms: One is where each node in the cluster
monitors the operational status of the services running on that node (PSM is an example of such a service). a slave is immediately promoted to master and starts processing
source messages (denoted 5) and provisioning the PacketLogic systems (6). the master and slave continuously synchronize data using a data replication connection (denoted 3). Redundancy
PacketLogic systems can be set up redundantly.1.
51
.
In normal operation. Note that the data replication connection need not necessarily be a separate physical
connection.
The system-level high availability is configured in the CLI of the PSM system (see Section 5. which is taken over by a new
master on failover.
However. a separate physical connection is recommended. it is marked as such by the other
nodes.
5. For passive sources.2. read operations can be performed on the
slaves. Redundant PSM systems
Two or more PacketLogic systems can be set up in a redundancy cluster. are not possible on any slave node.2. all nodes run a heartbeat daemon exchanging heartbeat messages
(denoted 4 in the figure).5. For active sources (such
as active RADIUS).1. any PacketLogic system can be included as a decision maker or elector
in the redundancy cluster. “Configuring
Redundancy and High Availability”). This can be useful if there are read operations that risk loading the master node heavily. this can be accommodated by letting the authentication server try all available PSM systems
in sequence when the current one stops responding. and provisions the PacketLogic systems (denoted 2).1. but it is
necessary to ensure that the authentication server sends the messages to the correct node. “Redundant PSM systems”
shows two PSM systems. Configuring Redundancy and High
Availability
This section describes how to set up a redundancy cluster. If the failing node is the current master.

1.1. other settings can be left at default. “Provisioners”) is added. connect with
a secure shell (SSH) to port 42002 on the IP address of the PacketLogic.
5.
52
.
1. This is due to the fact that the high availability mechanism will
not change the state of the provisioner. ensure that all provisioners on all
PSM systems are set with Startup State as Online.2.
Any other configuration that can be added before PSM starts can also be added at this point. Select System Administration.4.
5.2.
Node runs services This defines if there are services running on the
systems that shall be managed by the high availability
mechanism.
2. Prepare Provisioners
If the Provisioner configuration (see Section 4. this can cause problems. Once this is
completed. If a PSM is already
started (Startup State set to Master) at that point.
6. Enter Y to enable high availability. Ensure this is set identically on all PSM systems in the cluster (not
on other PacketLogic systems acting as electors in the cluster). Set up High Availability
This section describes configuring system level high availability functions on a PacketLogic system. Select Enable to access the CLI and enter the Enable password. This will not start any provisioning until a master is elected. Select Configure Node. Add all PSM systems as Remote Servers. Redundancy configuration
Note: The redundancy will ensure that subscribers. This will allow the high availability mechanism. Ensure that all nodes are initially set
with Startup State as Slave.3.
3.2.
7.
Unless there are specific requirements.5. To access the CLI. If a virtual IP (VIP) shall be used to connect to the Master.
deciding which PacketLogic system to use as Master. since the PSM is still a Slave
in the Redundancy configuration. Select High Availability.2. when configured. set up the PSM redundancy (see Section 4. Configuration is local to each system and not synchronized. select Virtual IPs. Enter settings as appropriate.
4. This will elect a master and start PSM on
the elected master. “Redundancy”).
Figure 5. a master will be elected and the PSM service on that master will start. to promote a
master which will then start processing inputs and provisioning other PacketLogic systems. and tables are synchronized among all PSM nodes
in the cluster.2.1. so to get provisioning started when a PSM is elected master. Operation
5.2. Enter A to add a virtual IP that
will be used only when the node is Master. the provisioner
must already be online.
The settings in the Configure Node menu are the following:
Cluster name A name for the cluster
Node is elector This defines if the system shall act as an elector. Configure PSM Redundancy
First. described below.
5. Enter R to reload the configuration for the changes to take effect. sessions.
The high availability configuration is done in the CLI of the PacketLogic system.

auto_recover_time This is the time the cluster wait before trying to restart
failed services (default 10s).
Cluster quorum This is the voting policy applied when electing a
Master. five seconds is entered as '5s'.
Loglevel This sets the logging level for the high availability
function.
Cluster network This is the IP network of the cluster. see Section 5.
Cluster ID This is the ID of the cluster. 'm' for minutes.
Reuse address This option enables the socket option to reuse the
address.
53
.
For details on the redundancy and high availability mechanisms. This can be used if a malfunction
in the high availability function causes it to lock the
port used by default. and 'h' for hours).
Cluster shared secret This is the secret used to communicate between the
nodes in a cluster.
Incremental port This option enables incrementing the port used for
cluster messages. Also. suffixes can be used ('ms'
for milliseconds. Ensure it is set identically on all
systems in a cluster. select S to save the changed
list and restart the cluster so the changes take effect. This can be used if a malfunction in the high
availability function causes it to lock the port used. Selecting a service means the
high availability mechanism will manage that service. if there
are multiple clusters on the same network.
After changing the list. Operation
Port This option sets the network port used for the clsuter
messages. If this is zero (0).
Advanced service options This option displays a list of values that can be
configured for the high availability mechanism (see
Advanced service options below). If the
network does not allow multicast traffic. no policy is applied and any
node considering itself to be an elector can make a
decision. the number
set is the number of voting electors that must agree
on a decision. If the network
allows multicast traffic. “Redundancy”. 's' for seconds. this can be set to the same
multicast address on all systems in the cluster.
auto_recover This is the number of times the cluster tries to restart
failed services (default 120). this can be
a comma-separated list of the IP addresses of all the
nodes in cluster. If it is set to a non-zero value.
Select services This option displays a list of the services available to
manage in the cluster. ensure that
the clusters to not have the same ID. For time variables.
Advanced service options
These are the advanced options available to set for high availability.1. Ensure that it is set
identically on all systems in a cluster. For example.

elector_startup_tolerance This is a grace period before determining the leader
elector (default 5s). Operation
cluster_update_interval This is the interval with which nodes in the cluster
update their state (default 1s).
54
.
failcount_reset This is the time after which a failed node will
reattempt to recover failed services after being
marked as failed (default 30m).
demote_timeout This is the time the cluster will wait after running a
demote operation before considering a node demoted
without a response (default 30s). if it is master.
quorum_demote_time This is a grace period when the number of electors
in cluster is less than the quorum setting (meaning
elections are impossible) before demoting the master
node running services (default 10s).
runner_tick_interval This is the interval with which nodes running services
evaluate the state of the services run. and provide the
elector with that state (default 1s).
elector_lost_time This is the time that a running services waits for a new
elector to be elected / announce itself before printing
a warning to the log (default 3s).
failure_promotion_timeout This is a grace period for how soon a failed node with
services can be promoted after having failed (default
60s).
demoting itself (default 8m).
promote_timeout This is the limit for how long the cluster waits
for a response from a promote operation before
considering it failed and electing another master
(default 30s).
elector_tick_interval This is the interval with which the elector evaluates
the cluster state (default 1s).
initial_promotion_delay This is an initial grace period when a new elector
selects a master before the node is promoted to master
(default 5s)
mainloop_sleep_time Sleep time in main loop of the cluster functionality
(default 333ms).
elector_gone_time This is the time that a running services waits for a new
elector to be elected / announce itself. before deciding
that the cluster is without elector and.
master_dead_time This is the time the elector will allow between
messages from the master node running services
before considering the node failed (default 5s).
start_timeout This is the limit for how long the cluster waits for a
response from a start operation on a service before
considering the service to be down (default 360s).

unless they were updated before that.
stop_timeout This is the limit for how long the cluster waits for a
response from a stop operation before considering the
service to be down (default 360s).3.2.
The Model > Defaults section has the advantages that defaults can be set for all attributes.
5. Deletion of session when the subscriber is deleted
The PSM can be configured to delete sessions automatically when the owning subscriber is deleted. On the Model configuration pane.
3.
5. Deleting sessions
Sessions can be deleted automatically in the PSM when the owning subscriber is deleted or after a certain time
has passed. select persistent in the Attribute combobox. Click Commit. Expand the Model menu and the Model > Defaults configuration pane. open the Session table. and that the defaults can be changed at run-time without restarting the system. Expiry of sessions
Sessions can be automatically deleted when a certain period of time has passed after the session was created.
Procedure 5.
Note
It is possible to configure default values both in the Model section and in the Model > Defaults section. The most common case for expiry of sessions is when DHCP is used as
a source for session information.
Procedure 5. In the Session defaults section.
status_timeout This is the limit for how long the cluster waits for a
response from a status check before considering the
service to be down (default 120s). Configuring the model schema
1.
status_interval This is the interval with which the status check will
be run for services to determine that they are running
correctly (default 10s). Open the Model > Automatic actions configuration pane.
5.3. Configuring automatic deletion of sessions
1.
2. The following example shows how to set up automatic expiry of sessions with
a DHCP source.
2. Add a new attribute called expiryTime and set the type to Timestamp.3.
3.
55
. including built-
in attributes. Type false in the text box next to the attribute.2.1.1. Operation
state_update_interval This is the interval with which the nodes running
services evaluate the state of the services (default
333ms).
4.

since the
defaults may not be correct for the current schema. PSM Counters. add a new DHCP source.
5.3. Click Commit. Expand the rule isLease and then select the suboperation Set Session. find the DHCP source to modify. Click Commit.
7. Counter data is generated by a PacketLogic system
which manages channel traffic (typically referred to as a PRE).
4. CDRs. Click Add Action. are correct. set the operation to Offset current time with.
6. add the attribute expiryTime defined above.
3. Create a new action with Operation set to Delete object and Object type set to Session. Operation
4. Expand the Rules section for the DHCP source. On the Sources configuration pane.
6. and Quotas
The PSM can receive counters from PacketLogic systems. Configuring the DHCP source
1.
Procedure 5.
Alternatively.
2. Make sure that the subscriber ID mappings etc. it is generated by ShapingObjects
56
. More specifically.4.
5.
7. Under Setters. Set the Time attribute to expiryTime.
5. Select the variable IP-Lease-Time in the last combobox. Below the Attribute field.

3. a subscriber.
5. Counters
Counters can be used for Charging Data Record (CDR) generation (see Section A. These NetObjects can then be used as conditions in rules on the PRE to apply
policies specific to that state.3.4. When a message to implement or change a policy is received from the
PCRF on the Gx interface. “Setting up Counters”.1.
Figure 5.13. In a 3GPP network. Gx/Gy
This section describes the functionality and configuration of the PSM implementation of the Gx and Gy interfaces. Operation
which have the option Byte counter enabled.5.212 (Gx) and
3GPP TS 32.
Quota management in PSM is implemented by PSM associating counter limits with an object (where an object
in the PSM model can be a session. The PSM must have a counter source configured to receive counters
from the PRE. Gx carries Diameter messages providing policy information between the PCRF and PCEF.1. PSM can
apply a new state to the object. the Diameter daemon updates the attributes for the corresponding subscriber. When a new session is seen in the PSM.
For details on the specification of Gx and Gy Policy and Charging Control (PCC). allowing
the model in PSM to update the PacketLogic systems where the policies are enforced with updated subscriber
information.5. The PSM uses the
information received on the Gx and Gy interfaces. With that in place.
For a description of how to configure Gx in the PSM. the Diameter daemon notifies the
PCRF and requests policy information.
Gx and Gy are Diameter interfaces specified by 3GPP for mobile network functions. “Diameter”. See Section A. The state can then be used in the NetObject tree to provision subscribers into
NetObjects specific to their state. When a limit is passed. see Section 4. making the PacketLogic impose the associated policies on the subscriber traffic.
5. “Using States” for an example configuration.2.3. Example configurations of the PSM and the PRE can be found in
Section A.299 (Gy). The schema and the NetObject Tree must also be modified. and inserts subscribers at the correct locations in the NetObject
tree in the PacketLogic. PSM will receive
counter updates from the PacketLogic system.
57
.2. Gx
Gx is used for communication between a Policy and Charging Rules Function (PCRF) and a PCEF in a 3GPP
network.
The Gx interface is implemented by a Diameter daemon on the PSM which communicates with the PCRF and with
the model in the PSM. “Generating Charging Data
Records (CDRs)”). or a group of subscribers). The Diameter daemon listens for event updates from the model in PSM and for messages
from the PCRF on the Gx interface. the PSM
and the PacketLogic combined act as a Policy and Charging Enforcement Function (PCEF). see 3GPP TS 29.

the logic can determine when. any problems with a table import will only be visible in log files on the PSM. For legacy purposes it is also possible to have the PSM periodically fetch table data through
HTTP or FTP. The HTTP POST method is the recommended update model for a number of reasons.
5. there is logic on the side providing table data. see Section 4. For scripting table updates from hosts outside the PSM the HTTP POST method
is recommended.
To import an IMEISV-table in CSV format:
58
.
5. Operation
5.2. This can be done by importing tables to PSM. “Credit Control”. The quotas act as limits to the traffic volume credit a subscriber is allowed to use. It will merely provide a file that the
PSM requests. if. For manual updates.
With the push model using HTTP POST.6. Using HTTP POST
When using HTTP POST the URL determines what table will be updated.6. Gy
Gy is used for communication between an Online Charging System (OCS) and a PCEF in a 3GPP network. the URL to the imeisv_table is:
http://psm. This logic receives
acknowledgements for successful operations. With the polling model
of fetching data. The path to a table is specified as:
/rest/model/tables/<table name>
For a PSM running at psm.
For a description of how to configure Gy in the PSM.6. Importing Tables
The integration scheme runs autonomously once configured. and can act when operations (table imports) are unsuccessful.com for example.1. the PacketLogic
systems where the credit control is enforced can be updated with the current subscriber information.8. Examples
These examples use the CURL tool. no decisions can be made on the side providing data. The credit control function allows the PSM to query the OCS for quotas to use
for subscribers.1.com:8080/rest/model/tables/imeisv_table
The type of the source file is specified by the HTTP header Content-Type.
There are a number of ways to make table data available to the PSM. the state of the file
at that time.
The Gy interface is implemented in the Credit Control configuration which communicates with the OCS and
with the model in the PSM. the web interface can be
used (see Section 4.
Furthermore.1.
The HTTP POST method uses a push model for updating the data in the tables. However. and searching log files in the PSM. Gy
carries Diameter messages providing service information between the OCS and the PCEF. By mapping
Attribute Value Pairs (AVPs) received on the Gy interface with subscriber attributes on the PSM.
5.2.2. “Tables”). and how often data should be pushed.5. there may be additional information to
provide for the PSM to take other data into account.1. Consequently. where the scheduled fetch method
uses a polling model. At the moment only the values
application/json and text/csv are supported. and
correlating them to a specific fault means finding out the time at which the file was retrieved.

It is recommended that this field is the first column. CSV
The CSV data format supported by PSM is a simple comma-separated file format. Import Formats
5.2."iPhone 4G"
To import an IMEISV-table in JSON format:
$ curl -X POST -H Content-Type:application/json --data-binary \
> @imeisv_table.0.
59
."iPhone 4G".3
Host: 127. digits (0-9). The file must begin with a
header line naming the columns in the file.make.
5.model
01234.8l zlib/1.6. Operation
$ curl -X POST -H Content-Type:text/csv --data-binary @imeisv_table. Spaces before and after each item will be included in the item. and that the Accept
header is used to determine the output format (defaults to JSON.Nokia. an arbitrary number of lines
of data may follow. When used as data for a table.7
OpenSSL/0. and underscores.0) libcurl/7.json http://psm:8080/rest/model/tables/imeisv_table
Successfully imported data into table imeisv_table
$
It is also possible to extract the currently used table data:
$ curl -X GET -H Accept:text/csv http://psm:8080/rest/model/tables/
imeisv_table
"tac".2.7 (universal-apple-darwin10.1. it is required that at least the key field (in the PSM table) is
among the fields (for every line of data)."Nokia"
$
Note that the columns are not necessarily extracted in the same order as they are imported.1
User-Agent: curl/7.0.19.csv \
> http://psm:8080/rest/model/tables/imeisv_table
Successfully imported data into table imeisv_table
$
The resulting HTTP request looks like this:
POST /rest/model/tables/imeisv_table HTTP/1.2."make"
"01234".1:8080
Accept: */*
Content-Type:text/csv
Content-Length: 39
tac."model". supports the types application/json and text/csv).
The name in a header field must start with an ASCII letter (a-z.9.6. no stripping of trailing
whitespace is performed. A-Z) which may be followed by any number of
ASCII letters. Note that the column names are case-sensitive.19. All values must be
unique in the key column. Immediately following the header line.

Operation

More formally, the following special tokens are defined (note that the non-quote and non-special character classes
include most whitespace characters):

Table 5.1. Special tokens in PSM table import CSV
<quote> the double-quote character (")
<non-quote> any UTF-8 character which is not the double-quote
character (")
<non-special> any UTF-8 character which is not the double-quote
character, the comma character (,) or a new-line/line-
feed character
<letter> any ASCII letter (a-z, A-Z)
<digit> any digit (0-9)
<new-line> a new-line or a line-feed followed by a new-line

During parsing of the imported file there are a number of things that can go wrong. The file can be malformed,
the columns can contain invalid values, mapping can fail, or there can be too many columns in the file (that is
more value columns than there are header columns).

Malformed files are files that do not follow the syntax described above. Mapping failures can only occur if a user-
defined mapping function is used. The ways mapping can fail depends on how the function is defined. Invalid
values are values that do not correspond to the attribute type and type options as set out in the schema in the PSM.

There is one notable difference between updating a table and updating subscribers. Table updates always happen
as one single atomic update. Subscriber imports happen in batches to avoid (too much) interference with other
tasks updating subscribers (such as RADIUS or SOAP updates), and to avoid the provisioning latencies that occur
when huge batches of subscribers are updated at once. This means that RADIUS and other "real-time" interfaces
are not unduly disturbed by batch operations.

5.6.2.1.3. Examples

The following CSV snippet is illegal since the header fields "Country Code" and "Network Code" do not follow
the required naming convention:

MCC-MNC,Country Code,Network Code
234-343,UK,H3G

60

Operation

The following is a legal file containing the same data:

mcc_mnc,country_code,network_code
234-343,UK,H3G

The four lines in this example do not evaluate to the same values since leading and trailing spaces are not stripped:

28347-45671,Red
28347-45671,Red
28347-45671, Red
28347-45671 , Red

In a quote-enclosed field, any whitespace outside the quotes is ignored. The four lines in this example do evaluate
to the same values:

In order to use quotes as part of a field, the field itself needs to be quoted, and the quote in question is escaped
with another quote:

"28347-45671","My ""quoted"" value"

61

Operation

Session. additional
configurations are available when expanding an attribute.1. The Subscriber.1. Setting up a source for the RADIUS messages (Section A. For the simple configuration case. Configuring the database schema to hold the data needed for the integration of the RADIUS information
(Section A. attributes for SGSN and GGSN
information are added to the session schema. Configuring the RADIUS server to provide the PSM with RADIUS messages (not described in this document).1. Depending on the type.1. More fields can be added to these tables
by adding attributes. that can provide more detail to the integration.6. Configuration of the Schema
The schema specifies the fields for the data that will be available in the PSM database. Attributes for the IMEI and APN of the session are also added.
4. In this example.
6. RADIUS with Attributes
This section describes how to configure the PSM to provision a PacketLogic system managing traffic.
This configuration consists of:
1. “Configuration of the NetObject Tree”).
2.3. Expanding the configuration by adding attributes for location information (Section A.1.
Defining the schema is depending on what fields shall be extracted from the authentication messages (RADIUS
in this case).
Access the PSM web interface by opening the URL:
https://<IP of PSM>
in a web browser.
63
.1.2.1.
and Group tables are available from start. but it is
also possible to add new tables to the schema. “Configuration of
Provisioners”).
A. “Expanding: Adding
Location Information”). containing pre-defined fields. and log in. Configuration Examples
A.1.
All schema tables consist of attribute names and corresponding data types. the subscriber and session tables must be defined. Configuration Examples
Appendix A.
3. “Configuration of the Source”). “Configuration of the Schema”). using
RADIUS information that the PSM receives from a RADIUS authentication server. Setting up the NetObject tree configuration to populate the NetObject tree in the PacketLogic systems with
subscriber information (Section A.4.1. Adding the PacketLogic systems to the provisioning configuration (Section A. and if other information sources are available.
5.

Configuration Examples

Figure A.1. Schema

In the schema configuration, names and appropriate datatypes of the attributes are entered in the session table. For
more information on the schema configuration, see Section 4.1.2, “Model” .

The following attributes and types are added in Figure A.1, “Schema”.

• The sgsnIp with the type IP Network will hold the IP address of the SGSN (Serving GPRS Support Node) of
the session. This will be represented by the 3GPP-SGSN-Address value in the RADIUS message.

• The ggsnIp with the type IP Network will hold the IP address of the GGSN (Gateway GPRS Support Node) of
the session. It will be represented by the NAS-IP-Address value in the RADIUS message.

• The apn is of String type and will hold the name of the APN (Access Point Name) of the session. This will be
represented by the Called-Station-Id value in the RADIUS message.

• The imei is set to the 3GPP IMEI SV type and will hold the IMEI (International Mobile Station Equipment
Identity) that uses the session. This will be represented by the 3GPP-IMEISV value in the RADIUS message.

• The ggsnName is of String type and will hold the name of the GGSN of the session. This will be represented
by the NAS-Identifier value in the RADIUS message.

64

Configuration Examples

A.1.2. Configuration of the Source
The RADIUS source is added in the Sources section by clicking the Source button and selecting New RADIUS
Source. The following settings are made in this configuration:

• The Listen host is set to 0.0.0.0 and the Listen port to 1813, meaning that the source will look for the RADIUS
messages on port 1813 locally.

• The Tags field sets a value that the RADIUS operations will be tagged with, in this case "radius".

• The Secret fields can be set to a network specific secret used to authenticate messages towards the RADIUS
server.

• Send responses is checked, which means that the PSM will acknowledge received messages to the RADIUS
server.

A.1.2.1. Attributes

All RADIUS attributes in Figure A.2, “Attributes” are predefined in the RADIUS source configuration, except the
NAS-Identifier attribute. In this configuration the NAS-Identifier is specified by adding the name of the attribute
(NAS-Identifier), the vendor ID (0), the attribute ID (32), and the type of the attribute (String) in a new line in
the RADIUS attributes configuration.

65

Configuration Examples

Figure A.2. Attributes

A.1.2.2. Declarations

The declarations are used to define variables that can be used as conditions in rules. The boolean variable
isStartOrUpdate that will be used in the rule described below (Section A.1.2.3, “Rules”) is predefined in the
RADIUS source, along with the boolean variables isStart, isStop, and isUpdate (Figure A.3, “Declarations”).
These are declared by evaluating the RADIUS attribute Acct-Status-Type. If the value is equal to 1, it marks the
beginning of the user service. If the value is equal to 2, it marks the end of the user service, and 3 marks an update.
The isStartOrUpdate variable is then declared using the isStart and isUpdate variables.

66

both
containing suboperations to create or delete subscriber and session objects. the rules isStartOrUpdate and isStop are predefined.3.
Figure A.3. Rules
Rules are used to determine what actions to take depending on the source information.2. and if the IP address is already mapped to a
session in the PSM (see Figure A. In the RADIUS source.4. Configuration Examples
Figure A. as well as performing the
action and updating the schema.1. “Suboperation”). Suboperation
The first suboperation deletes a session if isStartOrUpdate is true.4. The following suboperation creates the subscriber object for
67
. Declarations
A.

Configuration Examples
the session. the
next suboperation will be evaluated. see Section 4. the Framed-IP-Address is used as assigned ID for the session. The order of the suboperations is important.
Figure A. 3GPP-SGSN-Address. in the following way:
• The 3GPP-SGSN-Address is mapped to the sgsnIp column.
• The Called-Station-Id is mapped to the apn column. the session object is deleted if the Calling-Station-Id matches the assigned ID in the parent
subscriber.5. Called-Station-Id. which means that if the conditions of the Delete Session suboperation do not match the session. When a new session is detected (Acct-Status-Type start or update).
In the isStop rule. by adding attributes under Setters in the Set Session suboperation. The RADIUS attributes are mapped to
the corresponding attributes that were previously added to the session schema. which means that the values in
those attributes will be copied from the RADIUS message to the session table. Both these suboperations are predefined. Adding attributes in rules
The Set Session suboperation in the isStartOrUpdate rule tells the PSM when session objects should be created
and what information should be added to the session table (see Figure A. the values of the attributes Calling-
Station-Id. The No match action parameter is set to Continue with next operation in the first
suboperation.
and NAS-Identifier are copied to the session table from the RADIUS message. When the session ends (Acct-
Status-Type stop) the information is removed. “Sources”. since they are
evaluated from the top down.
• The 3GPP-IMEISV is mapped to the imei column. The Calling-Station-
ID is used as parent assigned ID.
The RADIUS source configured in this example will receive and acknowledge RADIUS messages received on
port 1813. “Adding attributes in rules”). Framed-IP-Address.1.
For this configuration example. 3GPP-GGSN-Address. 3GPP-IMEISV.
For more information on the sources configuration.5.
68
. When
a session object is created.3.
• The 3GPP-GGSN-Address is mapped to the ggsnIp column.
• The NAS-Identifier (that was previously added to the RADIUS attributes) is mapped to the ggsnName column. additional information from the RADIUS message should be added to the session
table.

subscriberId
/BySGSN/<session. The NetObjects in the static
ruleset can be viewed and used in the Objects and Rules editor in the PacketLogic client.subscriberId The subscribers will be added in the Subscribers
Netobject.
/Subscribers ! subscriber.3.
/Sessions ! session.oid
/Subscribers ! subscriber.ggsnName> !
This configuration will add a dynamic item in four places in the NetObject tree on the PRE every time a session
is added.sgsnIp> !
/ByNAS/<session. NetObject Tree Syntax for more information on how to use the NetObject tree syntax.sgsnIp> ! Each SGSN IP address will have a separate NetObject
in the BySGSN NetObject with the sessions from that
SGSN in the NetObject. Configuration of the NetObject Tree
The PSM NetObject tree configuration defines where subscriber data is added to the NetObject tree on the
PacketLogic systems. the
following is added:
/Sessions ! session. using the assigned ID subscriberId value
from the subscriber table as the name. all subscribers coming from other SGSNs (essentially meaning
that those subscribers are roaming) can be shaped to control the amount of data from roaming subscribers.1.
/BySGSN/<session.
/ByNAS/<session. the following is added in the static ruleset:
/Sessions
/Subscribers
/BySGSN
/ByNAS
The static ruleset is used for initial population of the NetObject tree in the PacketLogic. “NetObject Tree”. For example.ggsnName> ! Each GGSN will have a separate NetObject in the
ByNAS NetObject with the sessions from that GGSN
in the NetObject. In the dynamic ruleset in the NetObject tree configuration under /NetObjects/PSM.
Note that defining the rules to apply to the traffic is done in the PacketLogic systems.
For information on the NetObject tree configuration.4. using the oid value from the
session table as the name. The role of the PSM is to
ensure that the objects in the NetObject tree are kept up to date with subscriber information.
In addition. see Section 4.oid All sessions will be added as named dynamic items in
the Sessions NetObject. if the SGSNs on
the home network of a mobile operator are known. which means that the
NetObjects will be created even if nothing is matching them from the beginning.
These NetObjects can then be used as conditions in rules in the PacketLogic systems.
See Appendix B. Configuration Examples
A.1.
69
.

Provisioners
The provisioner shown in Figure A.
• Dynamic ruleset contains the IP address.
A. Committing Changes
To store the configuration changes made. and password of the PRE that holds the dynamic ruleset.
For information on the provisioner configuration.1.1.5. see Section 4. Configuration Examples
A. “Provisioners” has the following configuration:
• Ruleset Timeout (ms): is 60001. username. open the Provisioners configuration under NetObject Tree.4.6. In the Schema.
• Realtime Timeout (ms): is 60000. add a mapping for the location information in the Set
Session sub operation in the isStartOrUpdate rule.2. Expanding: Adding Location Information
This section describes adding location information from the RADIUS messages.
2.6. which is predefined in the RADIUS attributes. Configuration of Provisioners
The provisioners configuration defines the PacketLogic systems where the PSM shall update the NetObject trees
with subscriber information. click the Commit button in the left-hand Configuration pane. meaning it will wait for responses from the realtime systems for 60 seconds
before reconnecting.
70
.
• Batch limit (items) is 10000.
In the Configuration section.
The IP address of the static ruleset and a filtering group (if applicable) is also set.1. Under Rules in the RADIUS source configuration.
A.
1. username.4. and password of the PRE that holds the static ruleset.
Figure A. add an attribute named "location". with type "3gpp user location info" in the session table. meaning it will wait for responses from the ruleset system for 60 seconds and
1 millisecond before reconnecting.
• Static rulesest contains the IP address.1. The location field is mapped to the 3GPP-User-Location-
Info attribute. “Provisioners”.6.

This way.
The counters can be applied on sessions. To use it in.location". In the same way. session. Configuration Examples
3. subscribers.
71
. the counter
values in the following example will be mapped to a subscriber.1.
but counters may also be applied on sessions or groups. Setting up Counters
The PSM and the PRE can be configured to provide traffic byte counters to the PSM. which are then sent to the PSM. This section describes how to configure the PSM and the PRE to set
up counters. and group is represented by a number in the PSM. Set up the NetObject tree in the PSM web interface. The PSM uses the subscriber OID to keep track of which sessions a subscriber
is using. counters will be set up to keep track of the volume of every subscriber.2.2. outgoing. provided the RADIUS message contains
the field 3GPP-User-Location-Info.
and is assigned by the PSM internally.
3. Configuration of the PSM
The model schema is configured by going to the Model menu in the PSM.
A.
Every subscriber. to be
able to count the bytes correctly. for example.
The location field will now be available for all subsequent sessions. regardless of how many sessions the subscriber is
using. or groups that will
have counters. Configure the counter source in the PSM web interface. and editing the Subscriber table. it can be referenced as
"session.
4. by assigning the subscriber OID as a parent OID in the session information. In this
example. Create a ShapingObject and a shaping rule in the PRE to collect the sessions. The PSM uses the OID when mapping the counters to the objects. Configure the model schema in the PSM web interface. As of version 14.
the counters can be transformed by the PSM and applied to any user defined attribute.7. the attributes incoming. the group
OID is used as a parent OID in the subscriber information of every member of the group. making them more flexible. In the example configuration below. Commit to activate the changes. subscribers. ShapingObjects in the PRE are used to store the
counters.0 of PSM.
The following steps are needed to configure the PSM and the PRE to use counters:
1. or groups.
2. and total are added to keep track of traffic volume. This OID (object identifier) is unique. see Figure A.
A. the NetObject tree.

Add the incoming and outgoing attributes to the Total(Integer) configuration.
72
. The checkboxes Visible to
update time and Visible to NetObject Tree are both unchecked for all counter attributes to increase performance.7. The attributes incoming and outgoing are integers with 0 as default value. Schema configuration
The counter source is configured in the Sources configuration pane. The attribute
total is set to be calculated from the incoming and outgoing bytes by selecting the type Total(Integer) in the
drop-down list.
Figure A. In this example
configuration the default values (1) are kept for the divider and the multiplicators. Configuration Examples
“Schema configuration”. the variable isSubscriber
is defined to ensure that only the subscribers are receiving the counter data from the PRE.
Commit the changes of the PSM by clicking the Commit button. Under Declarations.

the configurations below are entered. NetObject Tree Syntax. the NetObject tree is set up to provision subscribers to the relevant NetObject. Configuration Examples
Figure A. The image below shows
the NetObject tree that will be used in this example configuration. The Setters configuration decides which attributes will be updated with a new
value. see Appendix B. In this case the incoming and outgoing attributes will be updated by adding the change in value. It defines a new NetObject under the PSM
NetObject in the PRE.
73
. Rules configuration
Next. This configuration specifies that the type of object to
be updated is a subscriber object. The SubscriberCounterOids NetObject will use the subscriber OIDs to name the objects. Source configuration
In the Rules pane.8.
For more information on the NetObject tree syntax.
Figure A.9.

NetObject tree configuration
This will create the NetObject SubscriberCounterOids under the PSM NetObject in the PRE.
This configuration lets every subscriber have their own copy of the ShapingObject. Figure A. Configuration of the PRE
Next. LiveView
A.
in this case the subscribers. which will be used in this example. and thereby there will be
volume counters for every subscriber.11.
Figure A. the counters will be mapped to the correct subscriber OID when they are sent back to
the PSM. a ShapingObject is created in the Objects and Rules Editor in the PRE. Since
they are named by OID. The Byte counter check box
under Advanced Options needs to be selected for the ShapingObject to count bytes. and the Subscriber NetObject configuration is set to the
SubscriberCounterOids NetObject that was just created.11. where the subscribers
can be viewed using PacketLogic LiveView.2. The ShapingObject in
this example is configured to be Split by Subscriber.
The Subscriber NetObject configuration needs to be set to the NetObject that holds the items that uses the counters.2. This will create a list of the subscribers that will have counters applied to them. Configuration Examples
Figure A.
74
.10. The image below shows the configuration of the SubscriberVolumeCounter
ShapingObject. “LiveView” shows the SubscriberCounterOids
NetObject in the PRE.

Shaping rule configuration
Figure A. and the association of the ShapingObject to the rule. Configuration Examples
Figure A.
75
.
Figure A. ShapingObject configuration
A shaping rule that associates the relevant traffic with the ShapingObject is created. and send the counter information back to the PSM.14. Shaping rule and object association
With this configuration. The images below show the
configuration of the SubscriberVolumeCounter shaping rule.
in this case the SubscriberCounterOids NetObject. The relevant local NetObject. is assigned as a condition in the rule.13. the PRE will start counting the traffic volume for the subscribers that are provisioned to
the SubscriberCounterOids NetObject by PSM.12.

3.2. Counters REST view
Using the command sessions results in the view below. The following commands and flags can be used:
/subscribers Command for requesting and posting subscriber information
/sessions Command for requesting and posting session information
/groups Command for requesting and posting group information
/tables Command for requesting and posting tables
/system Command for requesting system information
?pretty Flag for formatting the output in a human readable way
?download Flag used for downloading configuration files
Below is an example view of what information the PSM database holds.
Figure A.
76
.15. Configuration Examples
A. can be viewed using the REST (Representational State Transfer)
Interface. Note that the complete path to the database is https://
<ip_of_PSM>:8443/rest/model/objects/subscribers. which is a way of accessing the system using standard HTTP requests. The output is JSON formatted by
default. The REST interface is accessible
using https://<ip_of_PSM>:8443/rest/model in a web browser. Using the REST Interface
The information that the PSM currently holds. displayed by using the command
subscribers in the REST interface.

the PSM can provision the object to different NetObjects
depending on the current state of the object. Using States
When counters have been configured on the PSM they may be used to move objects (subscribers.
2. Add limits and states to the subscriber schema in the PSM web interface.4. The NetObjects may then be used as conditions in rules on the PRE.1.
A.
to apply state specific policies on the traffic. sessions. PSM applies a new state
on that object. When the limit is
reached. This can be useful when policies should be applied to subscribers
depending on for example how much incoming traffic they generate. When a limit for an object is reached. The following steps are needed to configure states for this example. Configuration of the PSM
Limits and states are added to the subscriber tables by adding attributes in the Model Schema. Configuration Examples
Figure A.
3. Configure the NetObject tree to provision the PRE with NetObjects reflecting the states. In this case.16. the
attributes limits and state are added to the Subscriber table. Counters REST view of sessions
A. The table allStates is added to the Model Schema to
keep track of the states. or
groups) between different states.
In the following example. The configuration below will apply the limits to the incoming traffic.4.2.
77
. The counters are used to define
limits for when an object should change states. a subscriber is allowed to use up to 200 MB of incoming traffic. given that counters are
already configured:
1.2. Create ShapingObjects and associate them with shaping rules in the PRE to apply the state specific policies. the subscriber will be provisioned to a NetObject used in a shaping rule to limit the incoming traffic
speed to 1 Mbps. depending on what policy should be applied. By using the state in the NetObject tree.

For the dynamic ruleset. reflecting the states of the subscribers. The NetObjects will be named using the id of every state as name of the NetObject.
Add the following to the static ruleset:
/ByState/<allStates.17.state> !
This will create the NetObject ByState. static NetObjects for all the states available in the allStates
table. and under that. Configuration Examples
Figure A. add:
/ByState/<subscriber.
78
. States configuration
Add the following lines in the NetObject tree configuration.state> !
This configuration will create dynamic objects under the ByState NetObject.

PSM-JSON-RPC protocol.2.
"state":"Over200MB"}]}]}
Below is an example of a REST interface view of the subscribers table after limits have been added. For more information on how to use the JSON RPC API.
{"limits":[{"limit":0. The subscribers are provisioned to NetObjects based on the states they are in. "state":"Under200MB"}. REST view of states
A. and the other
represents the state when traffic has exceeded 200 MB.
79
.
see Appendix C. "params":["subscriber".
Figure A. "method":"object. The JSON RPC source is added in the Sources
menu.18. {"limit":200000000. Configuration Examples
Limits can be set for the subscribers using the JSON RPC API. In this example two limits are
added.4. Configuration of the PRE
The image below shows a view of the PSM/ByState NetObjects in the PRE LiveView with the PSM configured
the way described above. The following command will apply limits and states to a subscriber
with OID 1:
{"id":1. One limit is representing the state where the incoming traffic has not yet reached 200 MB.2. Limits can be applied to any counter that has been added in the schema. 1.update".

80
.
Figure A.21. States shaping rule
Now the items in the Over200MB NetObject are not allowed to use more than 1 Mbps of the incoming bandwidth. Configuration Examples
Figure A.
Figure A.20. Shaping based on states
A shaping rule that associates the items in the Over200MB NetObject with the new ShapingObject is created as
shown below. a ShapingObject to limit the incoming traffic is created.
which can be controlled using LiveView in the PRE. The ShapingObject IncomingTrafficShaping below
is set to be split by subscriber. which means that every subscriber in the PSM/ByState/Over200MB NetObject will
be placed in a ShapingObject where the incoming bandwidth rate is limited to 1 Mbps per subscriber. States in LiveView
Next.19.

limits and
the Integer Key to Total. Optional: If there are limits and states attributes in the table already. Add a new attribute called state and set the type to State (String).
3.
A new table is added at the bottom of the configuration pane. the Table Name to
serviceLimits.
10.2. On the Model configuration pane.
4. where they have been defined for each service.
6. they can be based on a service.
7. Add a new attribute called serviceLimits and set the type to Table Reference. “Configuration of the
PSM”. In the primary key field. Set the Table name to serviceLimits.
81
. When a subscriber is assigned a service. enter service and set the type to String.
8.
Figure A. States after shaping
A. Creating a new table
1. Clear the Visible to update time option.1. Add a new attribute called service and set the type to String. New table for service limits
5.1. as described in Section A.2.
9. Setting states and limits based on service
Instead of adding states and limits directly to a subscriber. remove them by clearing the name fields.22. “Configuration of
the PSM”.
Procedure A. Configuration Examples
Figure A. Open the Subscriber table. the Limit Set to serviceLimits.
To set up a service. A service can then assigned to a subscriber.
2. and the Key to service.2. a table for services with states and limits is needed. Click Commit.1. the state and the limit are looked
up in a table.5. Add a new attribute called limits and set the type to Limit set. as in Section A. click Schema > New Table.23.

3. one limit represents the normal state
where the total traffic has not yet reached 1000 MB. and the other represents the above state when traffic has
exceeded 1000 MB.
1. The data can be viewed in the REST interface. Importing data to serviceLimits table
In this example. In the Tables section of the navigation pane. "state":"above"}]}]
2. "state":"normal"}.
{"limit":1000. Click Import and then Close.
{"service":"gold". Select Table serviceLimits and Format JSON.2. Configuration Examples
11. For the gold service. Browse and select the textfile. "state":"above"}]}. Subscriber attributes
Procedure A. the traffic can reach 9000 MB before passing the upper limit. "limits":[{"limit":0.
82
.25.24. click Import. see Figure A. "state":"normal"}.
4.
Figure A. Click Commit. "limits":[{"limit":0. For the basic service. “Service limits data”.
{"limit":9000. two limits are added for each service.
5. Save the following in a textfile:
[{"service":"basic".

"params":["subscriber". “Subscriber with service string”. The two approaches
83
.26. See instructions in Section A.2.2.6. The counters are set up within an object set. “Configuration of the PSM”. Service limits data
Verifying the configuration
The JSON RPC API can be used to test and verify the configuration.25. Subscriber with service string
Configuring the NetObject tree and the PRE
The next thing to do is to configure the NetObject tree in PSM and the PRE. the state will be set to above.set".2.
Figure A.
Since the service in this example is basic and the total traffic is 1100 MB. see Appendix C. PSM-JSON-RPC protocol. Configuration Examples
Figure A. "outgoing": 100}]}
The service string contents can be verified in the REST interface.
The following command will apply the basic service to the subscriber with assigned id 1:
{"id":1. “Configuration of the PRE”. For more information on how to use the
JSON RPC API.1.26. "method":"object.
{"service":"basic". see Figure A. Configuring volume counters for multiple services
A subscriber can have multiple volume counters for different services. "incoming": 1000.
as compared to the counter top-level attributes in Section A.
A.2.1.2. 1.
“Configuration of the PSM” and Section A.

Procedure A.
3. Expand the view and select the update subscriber sub-operation.
5.
3.g. Counters object set
Procedure A. select the counters attribute and click Add. Under Object set modifiers. e. enter name in the primary key field
and set the type to String.3. with total traffic volume as a top-level attribute and service-specific traffic
volumes within the object set.
Note
If Update object is selected instead.27.
84
. Configuring the counter source
1.4. Add a new sub-attribute called total and set the type to Total (Integer). On the Model configuration pane. For both attributes.
Click Add. Add the incoming and outgoing attributes to the total attribute.
4. On the Sources configuration pane. Adding a counters object set to the subscriber
1. Click Commit. Set the condition for the first rule to isSubscriber. set
the type to Integer and the default value to 0. counter objects will not be automatically created when counter
data is received.
5. open the Subscriber table.
2.
Figure A.
4. This will match all incoming counter data.
A new pane is opened.
2. select Set object. Keep the default value 1 for the divider and
multiplicator. Add two new sub-attributes inside the object set called incoming and outgoing. Configuration Examples
can be used in combination. Clear Visible to update time and Visible to NetObject tree to
get the best performance. Add a new attribute called counters and set the type to Object set. expand the Rules pane for the Counters source.
6. In the sub-modifier combobox.

29. "MYCOUNTER". PSM-JSON-RPC protocol. outgoing 100 and total 300.
The following command will simulate a counter update with incoming traffic 200 MB and outgoing traffic 100
MB for the subscriber with object ID 10:
{"id":2.
In addition to the top-level counter attributes being updated. Under Setters. set the operation to Offset current value with. there is a new object called MYCOUNTER. 200. For outgoing. see Figure A. Click Commit.28.
8.
100]}
The counter values can be verified in the REST interface.update command with a new counter name will add another counter object to the object set. Rules for counters source
Verifying the configuration
The JSON RPC API can be used to test and verify the configuration.
7.
9. add the attributes incoming and outgoing.update". see Appendix C. The
incoming attribute should be 200.
6.
Figure A. For more information on how to use the
JSON RPC API. select the variable Outgoing-Delta in the last combobox. Select the variable Counter-Name for the Object-ID setting.
10.
11. Re-
running the counters. For incoming. "params":["10". select the variable Incoming-Delta in the last combobox. “Multiple counters updated”. Configuration Examples
A new pane is opened.
85
. For both attributes. "method":"counters.

The model schema is
updated by adding two subscriber attributes as shown below.
For this example configuration the counters will be reset at the beginning of every minute. Configuration Examples
Figure A. While it
is possible to reset the counters for all subscribers at the same time.7.
86
.2. at for example the beginning of every week or month.29. For large installations it is recommended that the resets are spread out in time to
prevent this. Multiple counters updated
A. Scheduled Reset of Byte Counters
The counters may need to be reset periodically. this can result in a heavy load on the system
with latency spikes as a result.

a subscriber object update is added in the Automatic actions configuration pane. the two attributes incoming
and outgoing are added to select the counters that will be reset to the value 0. Counter reset attributes
Next.
Figure A.31. Configuration Examples
Figure A. This
will keep track of when. and how often the counters should be reset. Counter reset automatic actions
The Schedule type is set to Periodic execution. The Schedule attribute value is set to the resetPeriod attribute. Under Setters.
87
.30. and
the Last time attribute value is set to the lastResetTime attribute that was just added in the subscriber table.

"method":"object. and can contain the character "*" to match all values of the field. the counter will
be reset every minute.
{"id":5. until the counters have again reached 200 MB. In this example.32. Configuration Examples
Figure A. "params":["subscriber". The "?" character can
be used in the "day of month" and "day of week" fields. and the string "0 0 0 1 * ?" is
interpreted as "run at midnight first day of every month".update". the subscribers with the resetPeriod attribute in the Over200MB NetObject in
the example change state to Under200MB.
88
. The string "0
0 0 ? * 1" is interpreted as "run once a week at midnight on Sunday". Counter reset configuration
The reset period or interval may be added to the counters using the JSON-RPC API (see Appendix C. and is used to specify "no specific value". The fields represent in order:
Field Name Allowed Values
Seconds 0-59
Minutes 0-59
Hours 0-23
Day of Month 1-31
Month 1-12
Day of Week 1-7
All fields are mandatory. The PSM provisions these subscribers to the Under200MB NetObject
and the shaping is no longer performed on their traffic. The counter reset plugin attribute resetPeriod holds a CRON string for when the byte counter
value should be reset. PSM-JSON-
RPC protocol). 9.
{"resetPeriod":"0 * * * * ?"}]}
After the counters have been reset.
The following command will add a reset period for a subscriber with the OID 9.
The REST interface views of a subscriber before and after a counter reset are shown below. The CRON string contains six fields separated by white space.

33. Configuration Examples
Figure A. Counters before reset
89
.

The second alternative is to have separate resets for each service
object.5. start with the configuration in Section A.2.34. The two alternatives can be used in combination. On the Model > Automatic Actions configuration pane. “Scheduled Reset of
Byte Counters” and then perform the following steps:
1. Scheduling reset of counters per service
There are two alternatives ways of setting up scheduled resets of per-service counters.
90
. Configuration Examples
Figure A. select the Update: Subscriber action.2. The first is to reset the
counters for all (or some) service objects at once. Counters after reset
A. Configuring the model schema for reset of all per-service counters
To configure reset of counters for all services.8.7.
Procedure A.

5. In the last text-box for each attribute.
A. select the counters attribute and click Add.
{"id":1.
2. “Scheduled Reset of Byte
Counters” and then perform the following steps:
1.3. add the attributes incoming and outgoing. Generating Charging Data Records (CDRs)
91
. "method":"object.
A new pane is opened. For more information on how to use the JSON RPC API. Notice how the per-service counters are also reset.2. PSM-JSON-RPC
protocol.
A new pane is opened. "params":["subscriber". and the Last time attribute
to lastResetTime. Set the operation to Assign value. add the attributes incoming and outgoing. Configuration Examples
2. Click Commit. enter 0.
6. Wait until the next time for reset has passed
and verify that the counter values for the service are reset.
4.
Procedure A. see Appendix C. On the Model configuration pane. expand the settings for the subscriber attribute counters.
6. Set the Sub modifier to Update all objects and click Add.
5. Set the
Object type to Subscriber and Object set to the counters attribute. {"counters":
{"op":"add". select the Update object in object-set action. 10. On the Model > Automatic actions configuration pane. In the last text-box for each attribute. Set the operation to Assign value.
4. Under Setters. "resetPeriod":"0/10 * * *
* ?"}]}}]}
The contents of the subscriber can be verified in the REST interface. Set the Schedule type to Periodic execution. Then click Add. the Schedule attribute to resetPeriod. start with the configuration in Section A.
Verifying the configuration
Test and verify the configuration using the JSON RPC API the same way as in Section A.6.
7.7. “Scheduled Reset
of Byte Counters”. enter 0.
Verifying the configuration
The JSON RPC API can be used to test and verify the configuration. Configuring the model schema for separate reset of per-service counters
To configure separate resets of counters. Add a new sub-attribute called lastResetTime and set the type to Timestamp.
8.
A new pane is opened. Click Commit. "value":[{"name":"MYCOUNTER". Under Setters. see Appendix C.set". PSM-JSON-RPC protocol.7.
3. For more information on how to use the
JSON RPC API. the counter will
be reset every minute. In this example.
3. Under Object set modifiers.
The following command will add a reset period for the counter MYCOUNTER . Add a new sub-attribute called resetPeriod and set the type to Schedule.2.

If the PSM stops functioning (e. see the PSM log file. “Counters Source”). disable the plugins and commit to
ensure PSM is up and running and correct the schema errors before re-enabling them. indicated by
status changing to Readonly in the Status pane.1. This ensures
that the attributes storing CDR counters are available in the sessions schema. Requirements
The following criteria must be met for PSM to be able to generate CDRs:
• The PSM shall have an FTP account set up for CDRs. Overview
The PSM can generate Charging Data Records (CDRs) for sessions based on traffic generated by those sessions. Configuration Examples
A.
• The CDR and CDR: Simple Service Mapper plugins must be enabled (see Section 4.
The rule should also contain a sub operation that updates the cdrCounters:
92
. Below is a counter source configuration with a rule that updates the attributes cdrIncomingBytes and
cdrOutgoingBytes in the sessions schema.1. To see where the schema
validation fails. This is configured in the CLI.3.1.8.3.3. the
PSM cannot start correctly since the schema validation will fail.
A.
and write them to file for retrieval. “Status”).
• A counter source must be configured in the Sources pane (see Section 4. These attributes are automatically added when enabling the CDR
plugins. and how they are updated in
the PSM. This
specifies what counter values the PSM requests from the PacketLogic system. see Section 4. The files written
are available to retrieve using FTP.3.
Note: If the schema is not complete and correct according to the requirements for CDRs (described below).g. The fields to include and the limits for records and files are all configurable. “Plugins”). in the System
Administration -> Change Passwords -> Change ftpaccess password menu option.2. The PSM attaches attributes to sessions for keeping CDR-related counters and
generates records.1.

The APN table reference then
uses the APN name of the session as key when performing table lookups. “Model”) needs the following:
• The sessions schema needs to be updated with attributes that are used in the CDR generation. The following attributes should be added in
the sessions schema:
• The apnInfo and sgsnInfo attributes in the sessions schema are table refrence fields used for lookup of APN
and SGSN information.1. The SGSN table reference uses the
SGSN IP address of the session as key for lookups.2. In the sgsnInfo table. Configuration Examples
• The schema (see Section 4. These fields
must be provisioned by an input source (typically RADIUS). the SGSN IP address is used as key.
93
. The key field is the APN name in
the apnInfo table. These tables should be created in the schema.

If the sessions schema has been modified as described above.
the Attributes configuration should look like this:
94
. Configuration Examples
• The CDR Attributes configuration should be set up to specify which fields in the schema are mapped to the
CDR attributes used when generating the CDRs.

4. CDR closure can be triggered by a time limit. Setting Profiles
Profiles are used to configure how CDRs are written.
A.oid in a flat list directly
in that NetObject (see Section 4. Flatrate.2. see the PacketLogic Product Guide. and Pre-paid).
A. For details on how to configure the PacketLogic. it is highly recommended to review the system configuration value
SHAPING_COUNTERS_GRANULARITY_SHIFT on the PRE.1.8. Configuration Examples
• The NetObject Tree should be configured to provision a NetObject on the PacketLogic system with all the
sessions that are to generate CDRs. CDR file
95
.
The time and volume limits are used to specify when a CDR is closed (see Section A.3.3. just that a session
must accumulate a certain amount before it is accounted.
“Profiles”). Set the value as high as possible given the requirements on
precision and granularity.8.2.1.
• The PacketLogic system from which counters are to be received must have Byte counter enabled on the relevant
ShapingObjects (specified in Section A. “Profiles”. which significantly reduces the
load on PSM. or the CDR counter reaching a volume limit.1.
• While not strictly necessary. CDR and CDR File Closure Conditions
The metrics that define when a CDR is closed are specified in the Profiles configuration (Section 4.3. “CDR and CDR File
Closure Conditions”). Do note that a high setting does not mean that any traffic is missed in CDRs. The charging characteristic of the profile used for the CDR of a session is determined by the
session field pointed out by the Charging characteristics attribute in the CDR Attributes configuration.4. APNs. and the ShapingObject must be set
to be split by subscriber. and wether a session is considered
roaming or not. The NetObject must be provisioned with session.3.1. see
Section 4.2. “Configuration of the PRE”). Hot Billing. Profiles are matched to sessions based on three criteria:
charging characteristics (Normal.2. A higher value means fewer updates are sent to PSM. This value determines how much an
individual counter value must change to be sent to clients that have requested counter updates (the PSM is
such a client when a Counter source is configured).4.1. “NetObject Tree”).

time.3. by adding ServiceObjects to the conditions of the rule. Retrieving CDRs
To retrieve the generated CDRs.
addresses.2. the first limit that is reached causes closure in both cases.8. it is recommended to set up a scheduled
directory cleanup (see Section 4.1. ports.
This means that CDRs can be based on any criteria available in the rule set of the PRE (services/applications.3.1. To ensure that the disk is not filled with CDR files.2. For example certain services (like VoIP) can be excluded. The CDR files are in a directory named cdrs and can be retrieved to a remote
host for handling.
For details. Configuration Examples
closure is specified in the Writer configuration (Section 4.6. This allows selecting what to account with the full feature set of
the PacketLogic rule set on the PRE. and many more. What traffic that enters a ShapingObject is determined by the
conditions used in the associated shaping rule.
When multiple limits are set.
“SSM”).8. “Writer”).
• The Updates crossing granularity boundary received are the updates that are sent to the PSM.4.1. This verifies that the PSM has started correctly after configuration changes. Verifying Functionality
With configuration complete.3.5.1.3. and the counters for Active counters and
Updates received shall be increasing according to the traffic seen (the numbers seen will depend entirely on
the subscriber and traffic volume). see the PacketLogic Product Guide).3.6. These are the
updates that will cause CDRs to be generated. the file size. Active clients shall be at least 1 (one).5.15397. for example by checking the Status pane in the web interface (see
Section 4. or a time limit. connect to the PSM with an FTP client with the user ftpaccess and the
password set for this user (in the CLI).7.
• The following counter available over SNMP on the PSM provides information on the received counters for
CDRs:
PACKETLOGIC-PSM-MIB::cdrGeneratedRecords The total number of CDRs generated since startup
(.1. or CDR
accounting can be done exclusively for selected services. PSM can create per-service counters in the CDR (Section 4.6.1. “Scheduler”). Creating CDRs for Services
Using the Simple Service Mapper (SSM).0)
A.
96
. and can be triggered by number of
CDRs in the file. the following diagnostics can be used to verify that CDRs are being generated as
intended:
• Check that the model on the PSM is writable. Selecting Traffic for CDR Accounting
The traffic that is accounted in CDRs is the traffic that enters the ShapingObjects configured as counters for CDRs
(see Section A.3.3. “Status”). PSM is not involved in this decision-making as it only receives the counters
from the ShapingObjects without any knowledge about the rules.3.2. “Configuration of the PRE”).
A.7.
A.
Do note that the ShapingObject needs to emit counters named after session OIDs for it to update CDR counters in
PSM correctly.
A.3.
• Check that the PacketLogic system where the traffic is accounted (the PRE) has values in the Shaping Counter
zone of System Diagnostics.1.1.4.8. This is most reliably and easily accomplished by having the CDR accounting ShapingObject split
by subscriber and including the NetObject where sessions are provisioned in a flat list with OIDs as a condition
in the rule for that ShapingObject.

3. there will be separate CDR
counters named 1 and 2 respectively in the custom CDR extension in the CDR file. if the Map of services is entered as Skype-CDR:1.100)).
A. see Section A.8. CDR Extension Format
The format for the CDR extension (in ASN. in this example they are called Skype-CDR and Spotify-CDR.. The conditions for these
rules shall be a ServiceObject containing the relevant services.
A.
and provide the records to the CGF using FTP as per 3GPP TS 32.3. A custom extension is added to the CDR files including the counters of the specified
ShapingObjects identified by the associated identifiers.oid
The PRE ruleset is set up with two Shaping Rules: One for Skype and one for Spotify. A
NetObject named SessionOIDs is provisioned with sessions by oid using the following configuration in the
NetObject Tree in PSM:
/NetObjects/PSM
/SessionOIDs ! session. and the SessionOIDs NetObject. “CDR Extension Format”.8. for example. The ShapingObjects are configured
as split by subscriber with SessionOIDs as the Subscriber NetObject and with Byte counter enabled.2.
uplinkVolume[1] INTEGER.1.
downlinkVolume[2] INTEGER
}
A.1 notation) is as follows:
PsmCdrExtension ::= SET
{
serviceVolumes[0] SEQUENCE OF ServiceVolume
}
ServiceVolume ::= SEQUENCE
{
identifier[0] IA5String (SIZE(1.
In the SSM configuration on PSM the field Prepaid Policy Ids can be left empty.3.8. Configuration Examples
The SSM allows mapping services (identified by the names of ShapingObjects) to identifiers (which can be
arbitrarily chosen). ShapingObjects
are also created. For definitions of the extension
format.297 and 3GPP TS 32.295.2. The Map of services field has
a comma-separated list of the ShapingObjects and the identifiers they shall receive in the CDR extension. In this
example.298. a policy where counters shall be maintained for the services Skype and Spotify. Example Application
Consider.Spotify-CDR:2.
The attributes written in each record are the following:
• Record Opening Time
• Session duration
97
.3.9. This does not affect the generic CDR counter. Format Specification
CDRs generated by PSM use the format specified for S-GW records in 3GPP TS 32.

2.1. and iterating.
99
. Creating a NetObject structure
The /Foo in the syntax describes the NetObject structure. using conditionals. The ! marks the NetObject where a dynamic or static
item should be generated. subscribers and groups. NetObjects are created from both the dynamic ruleset and
the static ruleset. Dynamic and static rulesets
The configuration pane for the NetObjet tree is opened by clicking NetObject Tree in the Navigation pane. the
PSM will attempt to derive one from the dynamic ruleset. the PSM NetObject
tree syntax is used. when and where these objects should be generated.2. The
configuration pane is divided into a Dynamic ruleset and a Static ruleset.
B. as well as
which attribute values they should have.
The dynamic ruleset handles sessions. NetObject Tree Syntax
Appendix B.model> !
This will evaluate the session attributes 'manufacturer' and 'model' and create a NetObject path in which the
dynamic item will be added.manufacturer>/<session.
B. so that the
PacketLogic ruleset does not have to be recompiled during live operations.
B.4.2. NetObject Tree Syntax
To ease the mapping from session and subscriber information to the target NetObject structure. The
static ruleset handles tables and generates static items. Syntax
The NetObject tree syntax can be used for generating static and dynamic items.
The purpose of the static ruleset is to populate the PacketLogic ruleset with all NetObjects up front. If the static ruleset is undefined. “NetObject Tree”.
Example B.1. assigning
attribute values to the objects.1. The main functionality is to create a NetObject structure and generate dynamic items and static
items in the PRE. The syntax also defines how.1. Creating a dynamic NetObject
The most simplistic construction is to always emit a session on a path:
/Hello World !
This will add a dynamic item with the subscriber ID as the default subscriber name under the 'Hello World'
NetObject.
Example B. See also Section 4. Creating dynamic NetObject paths
The NetObject path can be constructed with the help of session or subscriber attributes:
/Device Type/<session. referencing. and this is where dynamic items are generated.

Creating static NetObjects
Similar to the dynamic NetObject structure you can add static NetObjects:
/Device Type
/MSISDN
Example B. The syntax is a ? followed by a boolean value.5.2. Using conditionals
Conditionals can only be used for dynamic items.
all(. and evaluation of any children NetObject
paths is aborted... there is no further evaluation. 'Group-B'. counter-name. it will automatically expand to multiple NetObjects:
/Group/<subscriber. Gets the attribute of a counter. NetObject Tree Syntax
Example B.name> for each row in the 'groups' table.2.2.) Evaluates to true if any of the parameters evaluate to
true.2.3. depends
on the conditions. Using tables to create NetObjects
The table 'groups' with the column 'name' is used to create NetObjects:
/Groups/<groups..groups> !
Setting subscriber.) Evaluates to true if all its parameters evaluate to true. Where in the NetObject structure the item is placed.2.2.
getCounterAttr(object.4. Functions
A number of functions are provided to allow conditional NetObject structure population..name>
This will create a /NetObjects/PSM/By Group/<groups. Creating dynamic NetObject paths from collections of strings
When an attribute is defined as a Set of Strings.2.
B.counters.1. attribute.
name)
100
.
B.
any(.
B. 'Group-C'] would be equivalent to the following tree:
/Group/Group-A !
/Group/Group-B !
/Group/Group-C !
Example B. Boolean Evaluation
A variable will be evaluated as false if any of the following conditions hold:
• Is an unset session or subscriber attribute
• Is an empty list
• Is an empty dictionary
• Is an empty string
• Is a False boolean
If the boolean value evaluates to false.groups to ['Group-A'.

found = in(subscriber. needles .
outLinkspeed.
Static item Values can be set in the static ruleset for the attribute name. outLinkspeed
and isSubscriber.tariffProfiles.manufacturer>/<session. the boolean conditional 'found' evaluates to true if the string "whatImLookingFor" exists
in the set of strings 'subscriber. inLinkspeed. isSubscriber and cgn.the list of strings must be first.
list(1..manufacturer)
not_so_awesome = not(is_awesome_phone)
/Phone Stuff ? session.1.model> ! ?
not_so_awesome
Conditionals can control if a whole branch is to be evaluated or not.
is_awesome_phone = in("Apple"..
is_awesome_phone = in("Apple". true-branch. regex) The result is a list derived from a with all items
matching the regular expression regex present. .
B. Below. session.tariffProfiles'.
match(a. n) Constructs a list of the given arguments. "whatImLookingFor")
Example B. They are then used to determine which dynamic items to generate.3.2.manufacturer>/<session.2. NetObject Tree Syntax
if(test. Conditionals
The following example starts with a declaration of the two boolean conditionals 'is_awesome_phone' and
'not_so_awesome'. 2. Conditional with string matching
In the following example.
Example B. false-branch) If the test evaluates to true return the second
argument. This way.model> ! ?
is_awesome_phone
/Boring Phones/<session. Setting attribute values
It is possible to change the default values of the following object attributes:
NetObject Values can be set in the static ruleset for the attributes inLinkspeed.7.
not(arg) Evaluates to true if the argument evaluates to false. different dynamic
items can be assigned shaping rules without the need of creating new NetObjects. the whole 'Phone Stuff' branch will
be dropped if the 'tac' attribute of the session evaluates to False. Note the order of the parameters ..manufacturer)
not_so_awesome = not(is_awesome_phone)
/Awesome Phones/<session...
inLinkspeed The in-bound linkspeed attribute of the NetObject. session. otherwise the third.) Returns true if all of the needles exist in the haystack.
Dynamic item Values can be set in the dynamic ruleset for the attributes name.
101
.tac
/Awesome Phones ! ? is_awesome_phone
/Boring Phones ! ? not_so_awesome
B.6.
in(haystack.3. NetObject attributes
Attributes can be used to set up rules on the PRE for inLinkspeed and outLinkspeed.

This marks a NetObject where a dynamic or static
item should be emitted.
Example B.
cgn Available for dynamic items.0. 'subscriber. Referencing
References can be used in both the dynamic ruleset and static ruleset using the same syntax.
isSubscriber An indication of if the subscriber name of the dynamic item identifies a subscriber
or not.
isSubscriber An indication of if the subscriber name of the NetObject identifies a subscriber or
not.0.service' or 'sgsnTable. Dynamic item and static item attributes
The syntax is a ! followed by key1=value1. Using NetObject attributes
/Something { inLinkspeed=42.
'subscriber.g. since name is the default attribute if nothing else is stated.
Example B. An
alternative would be to use the session attribute imei as a subscriber name for the dynamic item:
/IMEI ! session.2.3.1. Alternative DynItem Subscriber Name
In the case of a session attribute being almost completely unique.2.
102
. outLinkspeed=24 } ! table.network') and lookup references (e. field references (e.imei
Note how it is not necessary to write 'name=session..
outLinkspeed The out-bound linkspeed attribute of the dynamic item. keyN=valueN.9.8. It determines if the object should be considered a subscriber in statistics..10.
name For dynamic items.
B. NetObject Tree Syntax
outLinkspeed The out-bound linkspeed attribute of the NetObject. It can be followed by optional attributes.network
/Address From String ! localhost
/IPv4 Network From String ! homenetwork
/IPv6 Network From String ! modernnetwork
B. the subscriber name of the dynamic item is implicitly used if no
key is specified. of which all are available to dynamic items but
only name is available for static items.imei'.counters[name]').168.1")
homenetwork=ipv4network("192. .
inLinkspeed The in-bound linkspeed attribute of the dynamic item. There are two
types of references.0/24")
modernnetwork=ipv6network("fe80::76f0:6dff:fea2:2f3/64")
/Network From Table { inLinkspeed=42. when adding the item to the PacketLogic. It determines if the object should be considered a subscriber in statistics.g. isSubscriber=true }
Example B. Using NetObject attributes and static items
localhost=ipv4("127. this would result in a lot of NetObjects.4. outLinkspeed=24.2.

counters[name]. NetObject Tree Syntax
Example B. Iterations can be nested.2.se':
apn="tre.state> !
The reference here is in the static ruleset to a row in the table 'apnTable' where the value in the key-column 'apn"
is 'tre.
103
.
The iterator identifier should be a simple name using only the letters a-z and numbers.service> !
A field reference of a table row in the static ruleset:
/Network/<sgsntTable. Iterating
Iterators can be used in both the dynamic ruleset and the static ruleset with the same syntax.network>
Example B. The variable is then referenced. a subscriber attribute in the dynamic ruleset:
name="allData"
/AllDataState/<subscriber.11.network>
B.se"
/DefaultNetwork/<apnTable[apn].5.12.
The reference is here to the counter named 'allData'. Lookup references
Lookup references always have a declaration of a variable at the top. Field references
A field reference of subscriber attributes in the dynamic ruleset:
/Service/<subscriber.

as in this example.model>
Or.
/Device Type
/<imeisv. 'Apple.15. table iterators can be used. a different way of writing the same thing:
/Device Type/<i.network
Example B.state> ! [c:subscriber.manufacturer>/<i. To avoid this.14. Here i is the
iterator identifier:
/Device Type/<i.manufacturer' and 'i.manufacturer>
/<imeisv. This will generate the expected tree:
/Device Type/Apple/iPhone 3G
/Device Type/Apple/iPhone 4G
/Device Type/HTC/Desire
Example B. iPhone 3G'. where a static item is generated from the data in the table:
/SGSN [s : sgsn_info]
/<s. Using table iterators
If the columns of a table are to be populated in multiple depths. iPhone 4G' and 'HTC.model' will only reference one row per iteration. the 'imeisv' table contains the three rows 'Apple.model> [i : imeisv]
Now 'i.13.counters]
104
.
Desire'. each column will expand all rows of the whole table. Using static items with table iterators
An iteration through a table. A dynamic item will be generated under each state
NetObject for the counter in question:
/States/<c. it would produce:
/Device Type/Apple/iPhone 3G
/Device Type/Apple/iPhone 4G
/Device Type/Apple/Desire
/Device Type/HTC/iPhone 3G
/Device Type/HTC/iPhone 4G
/Device Type/HTC/Desire
Each table reference would expand all its available rows.manufacturer> [i : imeisv]
/<i. Iterating over dynamic items
Below is an iteration through all the counters for a subscriber.name> ! s. NetObject Tree Syntax
Example B.model>
If.

2.
105
.
C.2. It has the following properties:
• id .the value returned by the executed method.this property must be omitted or null. Protocol
The protocol is built on top of TCP.
• result . The error
object has the following properties:
• code . This property is omitted in case of errors. except:
• id . This is sent back in the response to the request. This implies
that the JSON encoding cannot contain newline characters.
• tags .
• error .
C. It has the same properties as a request. PSM-JSON-RPC protocol
Appendix C. Error object
If a request fails.
C.
• params . The simplicity of the protocol makes it very easy to
implement in any language.an array or dictionary with parameters to the method.2.2.
C. It is a text based protocol on top of TCP.
where requests can continously be streamed without delays. The protocol is line-based where each line must
be a valid JSON encoded object.1. which would otherwise be valid as whitespace. This property is omitted if no error occurred. Request
A remote method is invoked by sending a request to the server.the id of the corresponding request.an optional array of strings.
C. The request is a single JSON object on its own
line with the following properties:
• method .2. Lines are separated by a single newline character ('' or ASCII 10).
• id . using port 3994 by default. Overview
The PSM-JSON-RPC protocol is a simple low-latency protocol for PSM. PSM-JSON-RPC protocol
C.a string with the name of the method to invoke. Response
The result of a request is sent back in a response object.0 standard as much as possible.2.an integer indicating what error occured.1. in the error property of the response. Tags are attached to each change resulting from the request and can be used
for auditing purposes by external event monitors.2.
Since no reply is sent to notifications no guarantees can be given regarding the successful completion of them. details of the failure is returned in an error object.1. Optional parameters are set to null or left
out entirely.1.a request id of any type.
A reply can still be sent in case of request errors (see below).1. The
protocol tries to be compatible with the JSON-RPC 2. Notification
A notification is a request for which no response is expected.an error description object (see below).

a string with a short description of the error. The correct way for a client to determine
if a response or an event has been received.getByAid".get". "result":{"id":"460000002".
C.
C. An event is a notification that is sent from the
server to the client.getByAid". All
events in a group originate from the same transaction in PSM. or is invalid. Request errors
If an request is sent that cannot be parsed. "result":null}
An example with parameters and a return value:
--> {"id":2.ping"}
<-. and therefore should be considered to have been
applied at the same time.2.
"460000002"]}
<-.
C. The id property will be set to null if it could not be parsed.data sent to client
A simple request:
--> {"id":1. "group":"foo"}}
An example of an error response:
--> {"id":4. Event
Some methods are used to subscribe for events of different types. "method":"object. If events are enabled. Examples
In these examples the following syntax is used:
--> data sent to server
<-.
Event notifications are always sent in groups/arrays.5. is to check for the existence of the method property. "method":"system. "result":{"id":"460000002". there is therefore no need for explicit batching.{"id":1.2. "group":"foo"}}
An example with named parameters:
--> {"id":3.3. "method":"object. Batches/multiple calls
The PSM-JSON-RPC protocol is a streaming protocol.
C. "params":["subscriber". possibly with more details. 101001]}
106
. while events will always contain the method
property.2. "method":"object.2. a single response will be sent with the error code set to
either PARSE_ERROR or INVALID_REQUEST. and the same is true for the replies. In case of parse errors.
Responses will in this case also be sent to notifications.4.{"id":2. "params":["subscriber". meaning multiple events can be seen on the same line. PSM-JSON-RPC protocol
• message . meaning multiple requests can be sent continously without
waiting for replies. these can be sent at any time.2. the parsing will continue at the
next line.{"id":3.
"assignedId": "460000002"}}
<-.2. No events will ever be sent unless explicitly enabled via some method call. Each request is sent on a
separate line. Responses will
always contain exactly one of the result and error properties. Performance wise. "params":{"type":"subscriber".

update". ["created". The most common example is IP:s that are used during
the lifetime of a session. for as long as it is running. "error":{"code":-20020.3.delete". either by deleting and re-creating the subscriber. The assigned ID is the ID chosen by the
user of the system. Assigned ID:s VS generated objects ID:s
PSM has two different ID:s for each object: assigned ID:s and object ID:s.
{"class_of_service":"fast"}]}
An example with multiple requests:
--> {"id":5.{"id":5. }}]
<-. "params":["subscriber".[{"method":"object. or if the subscriber is renamed and another
takes it's place. }}]
C. 3636.
System methods:
107
. The object ID:s make it
possible to reliably determine if a subscriber/session is the same as before.. "result":null}
An example with events:
--> {"id":8. Assigned ID:s can be re-used.
C. "params":["subscriber". For sessions it is always the
IP address of the session. "result":null}
<-.3. "params":["subscriber". "params":
["subscriber". 3636]}
<-. 104331. "user:sven"]}
<-. "updated"]]}
<-.delete".2. 14555].
"tags":["my client progam". For subscribers this can typically be a MSISDN or a MAC address. "method":"object. "result":null}
An example with tags:
--> {"id":7. "result":null}
<-.1.3. PSM provides
methods for operating on both assigned ID:s as well as object ID:s. API description
C. or if it has been deleted. Subscriber ID:s
can also be re-used.{"id":6. "method":"events.update".{"id":4..created" "params":{ . for whichever is the most convenient for the
user of the system. Parameters in brackets are optional..
Object ID:s on the other hand are automatically generated by the system and cannot be chosen by the user.. and then re-used again at a later time. These
ID:s are guaranteed to be unique on the current host/cluster.{"id":8.{"id":7. "method":"object. "message":"Unknown object:
101001"}}
An example of a notification:
--> {"method":"object.
{"foo":"bar"}]}
--> {"id":6. PSM-JSON-RPC protocol
<-.setObjectTypeFilter". "params":["subscriber".updated" "params":{ . Method overview
Below are all available methods listed with their names and parameters. possibly for a different subscriber. "method":"object.[{"method":"object.

If no authentication is required then this method always returns null.created: type object tags
object.
Example:
{"id":1.4. In addition to any
explicitly specified error codes. "method":"system. unless otherwise stated. PSM-JSON-RPC protocol
counters.
This document version applies to API version "2.apiVersion"}
Returns: a version string.2.3.
C. The minor version is increased when new
additions are made that are backwards compatible. system. "params":["admin". The returned value is a dot-separated tuple like 2. all methods return null if no error occurs.login
This method authenticates a user and returns null if successful.login".apiVersion
This method returns the API version.deleted: type object tags
object.
Object events:
object.0. If unsuccessful it returns the error code
ACCESS_DENIED. all methods can also return any of the general error codes described in the error
codes section.the password to use.update
C. That section also contains the actual error code numbers that are returned.
• password .ping
This method does not do anything and always returns null. Detailed method description
In the following sections. It can be used to check the responsiveness of the
system. "secret"]}
C.the username to use.4. system.4.3. The first part is an
integer specifying a major version. as well as to check that the connection is still alive.updated: type oldObject newObject tags
C.3. The major version is only increased when a non-backwards compatible change
is made. "method":"system.3.3.5". system.
Parameters:
• username .3. Clients should use this information to determine if they are
compatible with the current PSM version.
Example:
109
.4.
Example:
{"id":1. The second part is an integer specifying a minor version. Event overview
Below are all available events listed with their names and parameters.1.3.2 since the version parts are integers.10 is considered to be a newer version than 2.
Note: 2.
C.

9. "method":"system.
C.smd
This method returns a description of all available methods and their parameters.5.3. where each string is the name of a method. system.
Example:
{"id":1. system.7.disconnect"}
C.smd"}
Returns: an object formated according to the Service Mapping Description (SMD) 2.4.4.
C.3.3.hostname"}
Returns: a string with the hostname for the machine. "method":"system. "method":"system. "method":"system.version"}
Returns: a version string.
C. system. "method":"system. system.8.ping"}
C. Unspecified
attributes are left unchanged.
Example:
{"id":1.hostname
This method returns the configured hostname for the machine.4.disconnect
This method disconnects the current connection after any previous requests have been processed and replied to.listMethods"}
Returns: an array of strings. It
is not necessary to use this method.4.
Example:
{"id":1. regular TCP connection termination is also supported (and encouraged). system.3.listMethods
This method returns a string list with all the available method names.4.4.set
This method updates the attributes of an object.4.
110
.
Example:
{"id":1.version
This method returns the current version of the PSM software. If the object does not already exist it is created.6.3. PSM-JSON-RPC protocol
{"id":1. "method":"system.
Example:
{"id":1. object.
C.0 proposal.3.

Returns: An integer with the object ID of the updated/created object.the type of object to create.
Parameters:
• type . subscriber. Must be one following strings: session.
{"class_of_service":"fast"}]}
Example with named parameters:
{"id":1. "method":"object. object.if any specified attribute condition did not hold.
• assignedId .a conditions structure with attribute conditions that should be checked (optional).
• oid .
• conditions . subscriber. group.an attributes structure with attributes that should be set for the object (optional).
C.
Parameters:
• type .4.if the object already exists.assigned ID of the object to create/update.the type of object to update/create. subscriber.update
This method updates the attributes of an object. PSM-JSON-RPC protocol
Parameters:
• type . "sub001".
"assignedId":"sub001".4.create
This method creates an object and sets its attributes.set".
• attributes .
• attributes . object.assigned ID of the object to create.
111
.
Returns: An integer with the object ID of the created object.object ID of the object to update. Unspecified attributes
are left unchanged.the type of object to update. The method fails if the object already exist. "attributes":{"class_of_service":"fast"}}}
Error codes:
• UNEXPECTED_VALUE . group. "params":{"type":"subscriber".
Example:
{"id":1.
• conditions .
Error codes:
• OBJECT_EXIST . "method":"object.an attributes structure with attributes that should be set for the object (optional).11.
C. The method fails if the object does not exist. Must be one of the following strings: session.
• assignedId .
group.3. Unspecified
attributes get their default values.3.10. Must be one following strings: session.an attributes structure with attributes that should be set for the object (optional).
• attributes .a conditions structure with attribute conditions that should be checked (optional).set". "params":["subscriber".

updateByAid
This method updates the attributes of an object. object.
Example:
{"id":1. Must be one following strings: session. group.a conditions structure with attribute conditions that should be checked (optional).a conditions structure with attribute conditions that should be checked (optional).assigned ID of the object to update.if the object does not exist.an attributes structure with attributes that should be set for the object (optional).
• conditions .if the object does not exist.4.
• conditions . "method":"object.delete". group.
• attributes .
C. Unspecified attributes
are left unchanged.the type of object to update. object. if the supplied conditions match.the type of object to update.if the object does not exist.3. "params":["subscriber". PSM-JSON-RPC protocol
Error codes:
• UNKNOWN_OBJECT . Must be one following strings: session. object.4.
Returns: an integer indicating the number of objects that were updated/matched the conditions.
Error codes:
• UNKNOWN_OBJECT .if any specified attribute condition did not hold.
• conditions .delete
This method deletes an object.the type of object to delete. The method fails if the object does not exist.
• attributes .
Error codes:
• UNKNOWN_OBJECT .
Parameters:
• type . subscriber.3.a conditions structure with attribute conditions that should be checked (optional).the object ID of the object to delete.
C. subscriber.4.3.
• UNEXPECTED_VALUE .an attributes structure with attributes that should be set for the object (optional). subscriber.
Parameters:
• type . 10234]}
112
.
• UNEXPECTED_VALUE . Must be one following strings: session.
• assignedId .updateAll
This method updates the attributes of all objects of the specified type.
• UNEXPECTED_VALUE .
Parameters:
• type .if any specified attribute condition did not hold.14.
C.
• oid .12. group. The method fails if the object does not exist.13.if any specified attribute condition did not hold.

group.the assigned ID of the object to delete.
• conditions . "params":["session". object. subscriber. 123123]}
C.a conditions structure with attribute conditions that should be checked (optional).deleteAll
This method deletes all objects of the specified type. PSM-JSON-RPC protocol
C.
Example:
{"id":1. Must be one following strings: session.16.the type of object to delete.deleteByAid
This method deletes an object.4.0.
• oid .
113
.3. group. "method":"object. Must be one following strings: session.
• UNEXPECTED_VALUE .
Parameters:
• type .get
This method returns information about an object.the object ID of the object to get information about.
Parameters:
• type . object.a conditions structure with attribute conditions that should be checked (optional). Zero means unlimited. object.50"]}
C.3.
• assignedId . object. group.
C.
Error codes:
• UNKNOWN_OBJECT . "params":["session".
• conditions .the type of object to update.
Parameters:
• type .get".
"127.4.
Returns: An object structure.0.3.
Returns: an integer indicating the number of objects that were deleted.17.getByAid
This method returns information about an object.
• maxDeletesPerSecond . subscriber.if the object does not exist. if the supplied conditions match. Must be one following strings: session.4.deleteByAid".an integer value with the maximum number of deletes to perform per second
(optional). The method fails if the object does not exist.
Error codes:
• UNKNOWN_OBJECT .if any specified attribute condition did not hold.
Example:
{"id":1. "method":"object. The method fails if the object does not exist.3.4. subscriber.18. The method fails if the object does not exist.if the object does not exist.the type of object to get.15.

4. so this method cannot be used to incrementally list all objects!
Parameters:
• type .
Parameters:
• type . The method fails if the object does not exist. Must be one following strings: session. Defaults to all objects.
114
.4.
Error codes:
• UNKNOWN_OBJECT .
Error codes:
• UNKNOWN_OBJECT .the object ID of the object to get the children for. subscriber.list
This method returns information about all objects of a specific type in the system. object.the assigned ID of the object to get information about. PSM-JSON-RPC protocol
Parameters:
• type .the type of object to access. group. subscriber.21.
"127. group.the type of object to get.
• count .
Returns: An array of object structures.getByAid".3.
• assignedId .3.
WARNING: This method can produce a lot of return data and may impact the operation of the system.0.20. subscriber.
NOTE: The internal element ordering is NOT stable. group. object.getChildrenByAid
This method returns information about the children of an object.if the object does not exist.
C.4.50"]}
C.
Example:
{"id":1. object.
Returns: An object structure.19.
Returns: An array of object structures.getChildren
This method returns information about the children of an object.if the object does not exist.the maximum number of items to return.
Parameters:
• type .0.
C.
• assignedId . Must be one following strings: session. group.the type of object to return. Must be one following strings: session. The method fails if the object does not exist.if the object does not exist. "method":"object.the assigned ID of the object to get the children for.
• oid .3.the type of object to access. Must be one following strings: session. or a subset thereof. subscriber.
Error codes:
• UNKNOWN_OBJECT . "params":["session".

then an event will be let through if any of the supplied tags match any
of the tags attached to the event.
• events . otherwise not.
• deleted .send object.setTagFilter".3. If the filter is including.
Parameters:
• type .
If it is called again for the same object type. so this method can be called multiple times in order to set up multiple filters. Defaults to zero. "deleted"]]}
C.setObjectUpdateFilter
This method enables further filtering of object.
["radius".
Example:
{"id":1. Must be one following strings: session. Possible values are:
• created . The default value is an empty array.deleted events for the specified type. then an event will be let through if any of the supplied attributes have
changed.send object.24.22.
group.
Parameters:
• action . The default value is exclude. The events that are sent depend on the events parameter. subscriber. events.setObjectEventFilter".
["created". The filter can either be of including or
excluding type.4.
NOTE: Since quite a lot of events can be enabled with this method it can result in a negative performance impact
on the system.send object.a string specifying the filtering action (optional).setObjectEventFilter
This method enables sending of object events. then an event will be filtered (that is.the number of items to skip from the beginning.updated events. "updated". it defaults to an empty
array. based on which tags they have. meaning all events will be let through this filter. By default no filter is installed. Must be either include for an including filter. If the filter is including.4. The filter can either be of including
or excluding type.
There is one filter for each object type. "method":"events.
115
.
or exclude for an excluding filter. it will not be sent)
if any of the supplied tags match any of the tags attached to the event.23. "custom"]]}
C. events.
• tags .
Example:
{"id":1.created events for the specified type.3.
• updated .4. meaning
all events will be let through this filter. then an event will be let through if any other attribute than those
specified (also) have changed. If the filter is excluding.updated events for the specified type.the type of object to apply the filter to. "params":["session".
Returns: An array of object structures. If the filter is excluding. By default no tag filter is installed. events.a string array of tags to act upon (optional). PSM-JSON-RPC protocol
• offset . If this parameter is null or left out.a string array of event flags (optional).setTagFilter
This method applies a filter to all sent events. "params":["include".3. then the previous specified filter for that type will be overwritten.
C. "method":"events.

it defaults to an empty
array. Each string must match an attribute name exactly.send table. "params":["session". Must be one following strings: session. ["counters/Roaming EU/totalState"]]}
C.a string array of attribute specifiers.
• attributes .updated events. or a name can
be supplied for a specific counter.
• replacedNotice .4.a string array of event flags (optional).3.
116
.
Parameters:
• events . so this method can be called multiple times in order to set up
multiple filters. Must be either include for an including filter.replacedNotice events.setObjectUpdateFilter".
NOTE: In order to receive object. "sgsnIp"]]}
Example:
Exclude all updates that only modifies the counter values (creation/deletion of counters will still be sent):
NOTE: This example depends on optional counter plugins being enabled!
{"id":1.
or exclude for an excluding filter.setObjectEventFilter method.setObjectUpdateFilter". "exclude". PSM-JSON-RPC protocol
There is one update filter for each object type. The
slash ('/') character can be used to specify sub-attributes for those types that support it.a string specifying the filtering action (optional)."counters/*/totalBytes"]]}
Example:
Only send an update event if the totalState attribute has changed for the "Roaming EU" counter:
NOTE: This example depends on optional counter plugins being enabled!
{"id":1.
Example:
Exclude events that only touch a few specified attributes:
{"id":1. See the examples below.
Parameters:
• type . subscriber.the type of object to apply the filter to. "include". If it is called again for the same object type. "counters/*/
outgoingBytes". "params":
["subscriber". The events that are sent depend on the events parameter. Possible values are:
• replaced .
• action . ["counters/*/incomingBytes". If this is not done. then no update events will be sent regardless
of what is setup using this method. events.send table. ["apn". For the counter set type. the corresponding event must be enabled using the
events.
"exclude". If this parameter is null or left out. "params":
["subscriber".setTableEventfilter
This method enables sending of certain table events. "method":"events.25. the start ('*') character can be used to specify all counters. The default value is exclude. "method":"events.
group. then the previous specified filter for that type will
be overwritten.setObjectUpdateFilter". "method":"events.replaced events.
provided by the counter values plugin.

C.
• replacedNotice .snapshot event. "method":"model.3.
It is not necessary or even possible to set an event filter for the resulting model. "method":"events. "method":"events.4.snapshot event.
C.a string array of event flags (optional).setModelEventFilter".4.send model.
Parameters:
• events .replaced events.send model. PSM-JSON-RPC protocol
Example:
{"id":1.replacedNotice events. "params":
[["readOnlyChanged"]]}
C.
Example:
{"id":1. "method":"model.send model. it defaults to an empty
array. model.
Example:
{"id":1.
Example:
{"id":1. If this parameter is null or left out. All other connections will
be unaffected. model. model.3.4. The events that are sent depend on the events parameter.27. with a snapshot of the current model. so that updates received before the snapshot
can be safely ignored and updates received after the snapshot applies cleanly to the snapshot.
• replaced .isReadOnly"}
Returns: a boolean value indicating if the model is read only (true) or not (false).isReadOnly
This method return the current read only status of the model.4.26. The snapshot
event will be correcly ordered with respect to other update events.setTableEventFilter".29.28.3. events.getSnapshot
This method returns a snapshot of the current model.
Example:
117
. "params":
[["replaced"]]}
C.setModelEventFilter
This method enables sending of certain model events.readOnlyChanged events.sendSnapshot
This method triggers and sends a model. Possible values are:
• readOnlyChanged . If this method
is invoked then it is assumed that the corresponding connection will accept said event.getSnapshot"}
Returns: A model snapshot structure.3.

get".
Parameters:
• key .
• incomingDelta .A positive integer with the change in the amount of outcoming bytes since last update. model.update".A string value representing the shaping object split key. "method":"table.A positive integer with the change in the amount of incoming bytes since last update.3. This can be useful to determine how
each object attribute should be interpreted. PSM-JSON-RPC protocol
{"id":1.getSchema"}
Returns: A model schema structure.31.
C. However.
Example:
{"method":"counters.created
This event is sent when a object has been created.3.update
This method does the same as what happens when a counter update is received from a PRE.A string value with the name of the table to get.
Example:
{"id":1. "method":"model.32.
C. Detailed event description
Regarding event ordering.getSchema
This method returns a description of the current model object configurations.
Parameters:
• name . table. For example.A string value with the name of the counter (shaping object) that was updated.
C. 9500]}
C.3.4.1. See above.
• counterName .
118
. although it also triggers an event.4. 11000. "params":[123.5. "method":"model.get
This method returns the content of a specified table. the ordering of
events related to a single request is not specified.5. This must be a valid OID value in order to get
any update in PSM.4.
Example:
{"id":1.
C. events are guaranteed to be sent in the order they occured.sendSnapshot"}
Returns: This method returns null.3.30. if a subscriber and its sessions are deleted in the
same transaction. counters.
• outgoingDelta .3. "params":["sgsnInfo"]}
Returns: An array of object structures. "ALLDATA". object. the subscriber deletion event can be sent before the session deletion events.

• tags .updated
This event is sent when an object has been updated.
• newObject .4. "params":{"type":"subscriber".3.
C. "object":
{"oid":1001.an object structure describing the object before the update.
• object .5.
Example:
{"method":"object. "msisdn":12.
• tags .5. PSM-JSON-RPC protocol
Parameters:
• type . except that the table parameter with the table contents is left out.the type of object that was deleted.5.
Parameters:
• type .
Parameters:
119
.3.an array of all the new table entries in the specified table.a string value with the name of the table that was updated. then this event will be
followed by one or more object.
• tags . If the table change affected any objects.3.created".
Parameters:
• type .an object structure describing the created object. "group":"fast"}.the type of object that was updated.3.an array of strings with all tags from the request that triggered this event. This event is
therefore more efficient from a performance viewpoint. table.an object structure describing the object after the update.updated events from the same transaction.2.
C.5. This event is very similar to
the table. object.
C.
Parameters:
• name .the type of object that was created.
• object . If the table change affected any objects.deleted
This event is sent when an object has been deleted.updated events from the same transaction.an object structure describing the deleted object.
• table .An array of strings with all tags from the request that triggered this event. table. "tags":[]}}
C. object.replaced
This event is sent when a table has been replaced.5.An array of strings with all tags from the request that triggered this event.3.
• tags . then this event will
be followed by one or more object.an array of strings with all tags from the request that triggered this event.
• oldObject .replacedNotice
This event is sent when a table has been replaced. and can be useful if one only is interested in the actual
notification and not the data.replaced event.

PSM-JSON-RPC protocol

• name - a string value with the name of the table that was updated.

• tags - An array of strings with all tags from the request that triggered this event.

C.3.5.6. model.readOnlyChanged

This event is sent when the read only state of the model changes.

Parameters:

• isReadOnly - a boolean value indicating if the model is currently read only or not.

C.3.5.7. model.replaced

This event is sent when the model has been completely replaced. This can for example happen when a slave node
connects to a master node and receives a new snapshot.

Parameters:

• snapshot - a snapshot structure representing the current model.

• tags - An array of strings with all tags from the request that triggered this event.

C.3.5.8. model.replacedNotice

This event is sent when the model has been completely replaced. This event is very similar to the
model.replaced event, except that the snapshot parameter with the model contents is left out. This event
is therefore more efficient from a performance viewpoint, and can be useful if one only is interested in the actual
notification and not the data.

C.3.5.9. model.snapshot

This event is sent as a response to the model.sendSnapshot method call.

Parameters:

• snapshot - a snapshot structure representing the current model.

• tags - An array of strings with all tags from the request that triggered this event.

C.3.6. Data structures
C.3.6.1. Attributes

This data structure is used to specify object attributes that should be updated. In the simplest form, this is just a
dictionary where each key corresponds to the name of the attribute that should be updated, and each value is the
new value the attribute should get. This works for all simple types as well as lists/arrays.

If the value is a dictionary it should have the following properties:

• value - an input value. How this is applied depends on the selected operation.

• op - an operation name that determines how the attribute value should be updated. Available operations are:

• set - assign the value as is.

• offset - increment the current value with the supplied one. This only works for some types like numbers
and timestamps.

• nowOffset - add the current time to the value before assignment. This only works for timestamps.

120

PSM-JSON-RPC protocol

• add - add the supplied value to the current collection. This only works for collection types.

• remove - remove the supplied value from the current collection. This only works for collection types.

This data structure is used to specify conditions on object attributes that should be evaluated. This is currently just
a dictionary where each key corresponds to the name of the attribute that should be checked, and each value is the
value it should be compared against. This works for all simple types as well as lists/arrays.

If the value is a dictionary it should have the following properties:

• value - an input value. How this is applied depends on the selected operation.

• op - an operation name that determines how the attribute value should be updated. Available operations are:

• equals - condition true if the values are equal.

• notEquals - condition true if the values are not equal.

• in - condition true if the provided string is in the set of strings.

• notIn - condition true if the provided string is not in the set of strings.

This data structure describes an object. It is just a normal JSON object containing all the attributes for the object.

Example:

{"oid":34019, "mac":"00:01:02:03:04:05", "group":"foo"}

Schema:

{"id":"psm:object",
"type":"object"}

C.3.7. Attribute type value representation
The following data types are available when defining attributes:

String This type validates and holds a string value. Values are assigned and
represented using the native string type.

Example: "hello Internet"

Set of Strings This type validates and holds a set of string values. Values are assigned and
represented using the native string array type, if available. If just a string is
specified, then the string set will be constructed by splitting the string on both
commas (,) and semicolons (;).

Example: ["one", "two", "three"]

Example: "one,two;three"

Integer This type validates and holds an integer value between -2^63+1 and +2^63-1.
Values are assigned and represented using the native integer type, if available,
or as a base-10 string equivalent.

Example: 350

Boolean This type validates and holds a boolean value. Values are assigned and
represented using the native boolean type, if available, or as one of the strings
true and false.

122

IPv6 address or IPv6 network
address. which will be evaluated to the current time when the operation is
executed. or a dictionary where each sub-
field is directly accessible.
Example: "70101"
Depending on retrieval method. optionally
separated by hyphens or colons.
3GPP MCC MNC This type validates and holds data as defined in the 3GPP standard for the
attribute 3GPP-MCC-MNC.SSSZZ.10"
IPv4 network address: "192. or a dictionary where each sub-field is directly
accessible. in eight groups of four hexadecimal digits
separated by colons for IPv6 addresses. the value is either represented using the same
type of hexadecimal string as used for input.
123
. If a number is supplied it will be interpreted as the number of
seconds since 1970-01-01 (also known as Unix time). Values are assigned using a string
containing 16 hexadecimal digits. the value is either represented using the same
type string as used for input.0.168. The special string "now" can also be used for
input.
Example: "1117770012345600"
Depending on retrieval method. for example:
IPv4 address: "192. the value is either represented using the same
type string as used for input.
Example: "00:11:22:33:44:FF"
IP Network This type validates and holds an IP network address of one of the following
types: IPv4 address. Values are assigned and represented using a string in dotted-quad
notation for IPv4 addresses. Values are assigned and
represented using a string with six groups of hexadecimal digits.
Example: "0132f40204a451cd"
Depending on retrieval method.0/24"
IPv6 address: "2001:0db8:85a3:0042:1000:8a2e:0370:7334"
IPv6 network address: "2001:db8::/32"
3GPP User Location Info This type validates and holds data as defined in the 3GPP standard for
the attribute 3GPP-User-Location-Info. Values are assigned
and represented using a string in the following format: yyyy-MM-
dd'T'HH:mm:ss.
Timestamp This type validates and holds a timestamp. Values are assigned using a string containing
exactly 16 digits. Values are assigned using a string containing five
or six digits.0.168. and in CIDR notation for IPv4 and
IPv6 network addresses.
3GPP IMEI SV This type validates and holds data as defined in the 3GPP standard for
the attribute 3GPP-IMEI-SV. IPv4 network address. PSM-JSON-RPC protocol
Example: true
MAC Address This type validates and holds a MAC-48 address. or a dictionary where each sub-field is directly
accessible.

2.000Z"
Example: "2010-05-20T17:00:01.
-32600 INVALID_REQUEST The request could be parsed but
is missing/has invalid elements in it.
-32602 INVALID_PARAMS The method parameters do not
match the method signature. -----------------------.
-32603 INTERNAL_ERROR An unexpected and serious error
occured.
124
.
-32601 METHOD_NOT_FOUND The specified method could not be
found. or the configured attributes.
Example: [{"name":"ALLDATA". Values are assigned
using a CRON string (read more in Section A.
-20023 UNEXPECTED_VALUE An attribute value did not match
a specified condition.
-20004 READ_ONLY_MODEL This node is a slave/in read only
mode. -----------------------.
-20021 OBJECT_EXIST The specified object already
exists.
"state":"TWO"}]
Object set This type validates and holds a set of objects.7. The limits in the limit set contain an integer (the lower limit
for traffic) and a string (the name of the state). -----------
-32700 PARSE_ERROR The request could not be parsed
(is not valid JSON).
Code Friendly name Description
-----.000+0200"
Schedule This type validates and holds a data type for scheduling.
-20005 OBJECT_LIMIT_REACHED The absolute maximum number of
objects has been reached!
Special error codes: These are only returned by methods that explicitly state so. “Scheduled Reset of Byte
Counters”).
Example: The string "0 0 0 ? * 1" is interpreted as "run once a week
at midnight on Sunday".
Example: [{"limit":100. -----------
-20020 UNKNOWN_OBJECT The specified object does not
exist. "incoming":200}]
C. It is only used together with
the state attribute. "state":"ONE"}. Error codes
General error codes: These can be return by any method. The object set must have a
unique key and can have a number of additional attributes.
Code Friendly name Description
-----.3.
-20001 ACCESS_DENIED Access denied for the specified
method. Send change requests to the master node instead.
Limit set This type validates and holds an array of limits.8. PSM-JSON-RPC protocol
Example: "2010-05-20T15:00:01. {"limit":1000.

5. it is much more efficient to use a persistent TCP connection instead
of closing and creating new ones.
• New methods can be added.
• For a proper close of the connection. This also
means that responses can be received in a different order than the corresponding request objects.apiVersion to determine if the client is compatible with the current PSM version.4. contact Procera technical
support for clarifications. PSM-JSON-RPC protocol
C. be strict in what you send and
liberal in what you accept.
• Do not rely on any method or behavior not explicitly documented here. if they are dependent on each other. Implementation notes
• Requests are processed in the order they are received.listMethods and system. or not processed at all.
EOF
125
.
• If large amount of requests are being sent. and new optional parameters can be added to existing methods. client implementations should take the following
precautions:
• Use system. The system. any
pending requests are normally either processed and responded to.smd stays
exactly the same.
• Ignore unknown fields in responses if they don't matter to the client. or shutdown of PSM as a whole. shutdown of the source component. When in doubt. No guarantees are
made regarding ordering of requests that are independent. or received from different connections. This implies that
an implementation should not assume that the output from system.
C.ping method can be used to verify the connection status if
no requests have been sent in a while. Compatibility notes
In order to remain compatible with future PSM versions. In general.

PSM-JSON-RPC protocol
.

In general the JSON-RPC
API is the recommended mode of interaction with the PSM due to its higher performance and added functionality. In practice PSM calls can be performed in four ways.v3_1 -faultSerialVersionUID
FQCN -asyncMethods -bareMethods -exceptionSuper
com.1 Introduction
The following sections describes PSM client development for the PSM SOAP v3. PSM SOAP 3. each having some impact on performance
or code complexity. when generating a Java client.
The PSM SOAP API basically consists of a number of calls to manipulate subscriber and session entities within
PSM as well as a call to dispatch and execute several operations in one call. While the use of this parameter is optional.v3_1.source.wsdl
This will generate the PSM API bindings into the gen folder. It also assumes the following
directory structure:
/psmclient
/gen
/src/com/proceranetworks/psm/source/soap/v3_1
PsmException.2. PSM SOAP API
D.2.
D. Also. PSM SOAP 3.
This example assumes that the separately distributed WSDL and XSD files are used.soap.
For information on how to configure this and similar aspects of SOAP and PSM.Exception
class.1 Client writers guide
D.psm.2.1.1 API.
D.lang. All versions of the PSM API can have
Basic HTTP authentication enabled. PSM SOAP API
Appendix D. use the separately
distributed WSDL and XSD files as they contain several useful hints to the generator that yields a more usable API. Java Client API generation
For generating the client Apache CXF is recommended. call the wsdl2java command distributed in CXF while standing in the psmclient folder:
$ wsdl2java -fe jaxws21 -d gen -validate -p
com. See the discussion in API usage for details.
The -exceptionSuper parameter is optional and makes use of a pre-existing exception class as parent to the
SOAP fault classes. Introduction
The following sections contains the basic information needed to create a PSM SOAP client as well as some notes
on good practices.1.soap.proceranetworks.PsmException wsdl/psm-
service.java
/wsdl
psm-service.psm. The exception super-class can be any class that inherits from the base java. A simple implementation could look like this:
127
.xsd
To generate the client.wsdl
messages. this is controlled in the Web UI.source. please consult the users guide. the use of the generated API becomes much simpler
with it enabled.2.proceranetworks.

The synchronous variants are often easier to use.
A synchronous batch call to create one session and one subscriber would look like this:
package soap.
public PsmException() {
super().psm.
}
public PsmException(Throwable cause) {
super(cause). the easiest way of adding this authentication to the client is to interact
with the static methods of the java. one call is being transferred and one call is being executed on the server.3. API usage
There are basically four ways of using the API:
• Synchronous single item
• Synchronous batched
• Asynchronous single item
• Asynchronous batched
For the highest throughput for large amounts of data. the asynchronous single item API is easiest to use and has
quite good performance.setDefault(new Authenticator() {
@Override
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(username.Authenticator class:
Authenticator. PSM SOAP API
package com.toCharArray()). Throwable cause) {
super(message. password.
}
public PsmException(String message) {
super(message).soap.v3_1. The synchronous batch call is a good mix of performance and usability whereas the synchronous
simple call is very easy to use for smaller tasks requiring few calls or tasks where performance is less of an issue. but might not always offer the required
performance. Barring that. For streaming data. use the asynchronous batch API such that one call is always
being prepared by the client.
128
.proceranetworks.2.net.source.
}
public PsmException(String message.
}
}
D.
}
}). cause).
public class PsmException extends Exception {
private static final long serialVersionUID = 8259908506948318705L.
If HTTP Basic authentication is enabled.
it is better to have a request in the inbound queue on the PSM side rather than PSM not having a new call available
when the previous call is finished.

import com.
final Batch batch = F.Session.1.setSubscriberId("11:22:33:44:55:66").proceranetworks.source.
import com.getItems().util.OnError.proceranetworks. Psm service
D.
import com.Response object. There are two asynchronous variants of each method.source.Objects.concurrent.psm.psm.soap.ws.proceranetworks. PSM SOAP 3.source. The
Psm service exposes one port called Objects.v3_1. It contains one service.
sub.createSessionSet(session)).Future interface.Subscriber.
import com.soap.xml. with a few calls
dispatched but not yet executed to keep from starving PSM.
public class SimpleBatch {
private static final ObjectFactory F = new ObjectFactory().1")).
which is an extension of the java.setAssignedId("11:22:33:44:55:66").
import com.source. Objects port
port Objects {
129
.CONTINUE). probably in the range of a few hundred.soap.JAXBElement.setAssignedId("127.List.createSubscriber().0.Batch.
session.
import com.batch(batch).3.createSubscriberSet(sub)).add(F.bind.
D.
public static void main(String[] args) throws Exception {
private final Objects objects = new Psm(new URL("http://psm:7627/
soap/3.
The asynchronous variant of the batch call works in a similar fashion except that the batchAsync method is
used.psm.
session.
// TODO: Check result
}
}
Normally the batches would be larger than two items.psm.1.
calls. called Psm.proceranetworks.soap.
final List<JAXBElement<?>> calls = batch.
final Session session = F.soap.0.1 SOAP API is a SOAP 1.getObjects().2 API exposed over HTTP.xml.ObjectFactory. one returning a javax.
final List<JAXBElement<?>> result = objects.source.1.1 Reference
The PSM 3.
D.setOnError(OnError.3.v3_1.soap.util.psm. PSM SOAP API
import java.v3_1.source.
calls.v3_1.proceranetworks.
batch.psm. This port exposes methods to manipulate and inspect session and
subscriber entities.
final Subscriber sub = F.createSubscriber().getItems().add(F.1").v3_1.proceranetworks. the other which takes an extra
parameter containing a callback object.
import javax.createBatch().v3_1.3.

0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://www.
138
.
Note that the subscriber referred to by subscriberId needs to exist before this call can succeed.
GeneralError If an internal error occurred. The method returns a sessionCreateResponse element if successful.org/2003/05/soap-envelope"
xmlns="http://psm. The method returns a
sessionSetResponse element if successful.1/message">
<S:Header/>
<S:Body>
<sessionCreate>
<assignedId>72.proceranetworks.
UnknownSubscriber If the subscriber does not exist.org/2003/05/soap-envelope"
xmlns="http://psm.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://www. IllegalArgument or GeneralError if unsuccessful.proceranetworks. or updates an existing session if one does.com/soap/3.24. or one of UnknownSubscriber.112</assignedId>
<subscriberId>00:12:c9:dc:d3:70</subscriberId>
</sessionCreate>
</S:Body>
</S:Envelope>
Response
<?xml version="1.8.1. PSM SOAP API
Output sessionCreateResponse None
Faults SessionExist If a session with the given id already exists.w3.
Example D. sessionSet
Creates a new or updates an existing session
Input sessionSet Session
Output sessionSetResponse None
Faults UnknownSubscriber If the subscriber does not exist. or one of
SessionExist.com/soap/3.182.
GeneralError If an internal error occurred. Creating a session
Request
<?xml version="1.
Creates a new session if one does not exist.3.1/message">
<S:Body>
<void/>
</S:Body>
</S:Envelope>
D. UnknownSubscriber.
Creates a new session. IllegalArgument or
GeneralError if unsuccessful.w3.
IllegalArgument If the attribute mapping failed. No subscriber
is created implicitly.
IllegalArgument If the attribute mapping failed.1.9.

such as MAC addresses.1. represent the value in the dotted quad
notation with prefix (10.3. SubscriberExist
fault SubscriberExist {
string id . second fraction and time-zone indicator. hour.
Timestamp creationTime . There are
cases where the value types are always represented as strings. minute.4.1. day. use the colon separated octet notation
(01:23:45:67:89:AB). Examples
All examples in this section assumes the following schema:
schema Subscriber {
MAC Address subscriberId .1 and above) Use string type. second fraction
and time-zone indicator.3.0/24)
IPv6 Network(PSM 13.0.2. A value
element like <value><string>203</string></value> for example.
minute. timestamps.2. Formats
Value type to Schema type mappings
Timestamp Use string type.0.
D. and using the appropriate
value type for each schema type is strongly recommended to avoid unintentional misconfiguration. represent the value in ISO-6801
format including year.
D.1. would be coerced into being an
integer if that is what the receiving attribute requires.
IPv4 Address Use string type.6.
and others.1. day.0. Care must be taken when constructing these string types so that they adhere to the correct format. hour.
147
.
}
A subscriber with the referred id already exists.
D. PSM SOAP API
string id .3.1.1)
IPv4 Network Use string type. month. month.0.3.
Timestamp updateTime .
(2011-11-16T17:57:02.3.
}
A session with the referred id already exists. for example. represent the value in the RFC
2373 "Text Representation of Address Prefixes" form
(12ab:0:0:cd30::/64)
MAC Address Use string type. Case insensitive.3.
D. This is not the recommended way. IP addresses.
Timestamps. Value mapping
PSM attempts to map provided values into values matching the schema types on a best-effort basis.536Z) or the string
now. represent the value in the dotted quad
notation (10. must be an ISO-6801 value including year.

PSM SOAP API

boolean persistent ;

string cmtsName ;

}

schema Session {

IPv4 Address sessionId ;

Timestamp creationTime ;

Timestamp updateTime ;

Timestamp expiryTime ;

}

D.3.1.4.1. Use Case: Provision new subscriber

If the subscriber does not exist in the system already, use the subscriberCreate call. This call will fail if the
subscriber is already in the system, and will thus highlight any inconsistencies in the setup.

If this is not guaranteed, use subscriberSet since that will instead update the existing subscriber if one happens
to exist.

For this example the stricter case is assumed and subscriberCreate is used.

If it is certain that the subscriber already exists in the system, use the subscriberUpdate call. This call will fail if
the subscriber isn't already in the system, and will thus highlight any inconsistencies in the setup.

148

PSM SOAP API

If this is not guaranteed, use subscriberSet since that will instead create a new subscriber if none existed previously.

For this example the stricter case is assumed and subscriberUpdate is used.

If the session is known to not be present in the system, use the sessionCreate call. This call will fail if the session
is already in the system, and will thus highlight any inconsistencies in the setup.

If this is not guaranteed (including the case where the session belongs to another subscriber), use sessionSet
since that will instead create a new session if none existed previously, or move the existing session to the correct
subscriber, if it was not already associated with it.

Note that PSM does not automatically create subscribers for sessions provisioned through the SOAP API. This
means that if the subscriber does not already exist, it needs to be created beforehand. In order to avoid tracking
whether or not the subscriber has already been created for a session, a call to subscriberSet can be issued before the
session creating command. Another alternative would be to use subscriberGet to query the state of the subscriber
before any add call. This is not recommended, however, as it causes extra calls in the case where a subscriber is not
already present, and the impact of a no-op (i.e. update with the same attributes that are already set) subscriberSet
call on an existing subscriber is negligible.

In order to keep the number of subscribers in PSM down, it is important to remove them once they are no longer
customers, or if they have permanently moved to another area and are thus permanently handled by another PSM.

Removing a subscriber can be done by issuing a call to subscriberDelete. A call to this method will remove the
subscriber and all sessions currently associated with it.

1.15397.9.2.4.1.2.4.1.4.1
A entry containing information about a table
• modelTableName
.3.6.1.2
The number of entries in the table
• modelTableLastChanged
154 .3.3.3.3.3.15397.6.1.3.1.9.2.1.2.15397.4.3.2.4
OBSOLETE! Maximum number of sessions allowed by current environment configuration
• modelSubscriberUpdates
.3
.2.2.3.15397.3.6.3.6.3.2.4.2.4.1.2.1.1.15397.1.2.1.1.1.3.1.9
A list of all available tables
• modelTablesEntry
.3.6.2.6.2.1.1.4.3.3.6.2.2.2.1.7
OBSOLETE! Maximum number of sessions allowed by current environment configuration
• modelSessionUpdates
.1.1.6
OBSOLETE! Total number of sessions
• modelSessionsMax
.6.15397.6.1.1.15397.2.1.2.3.2.3.1.2.4.2.1.1.4.2.1.1.1.5
OBSOLETE! Total number of subscriber updates
• modelSessions
.15397.6.1.1. PSM SNMP MIB
.15397.9.15397.3
OBSOLETE! Total number of subscribers
• modelSubscribersMax
.1.1.3.4.1.3.4.3.1.15397.3.1
The name of the table
• modelTableSize
.1.8
Total number of session updates
• modelTablesTable
.9.6.

11.1.6.3.3.1.2. PSM SNMP MIB
Date and time when the table was last modified
• modelServer
.6.2.10.1.6.3.6.1.3.4.2.2.11.1.4.4.15397.1
The total number of model snapshots generated and sent
• modelServerActiveSnapshots
.4.3.1.15397.3.2.4.2.15397.3.6.15397.1.3.4.2.4.1.2.14
Maximum number of objects allowed by current environment configuration
• modelObjectCount
.2.6.15397.1.2.1.6.2.6.10.4.1
Current model sync client state
• modelClientStateLastChanged
.6.1.3.1.2.11
• modelClientState
.1.1.1.2.1.2.2.3.2.3.3.4.1.1.3.2.6.1.3.3.3.15397.1.15 155
.1.10
• modelServerTotalSnapshots
.1.3
The number of requests waiting to be applied after synchronization completes
• modelTransactions
.1.15397.4.1.3.3.2.15397.3.1.3.2.3.4.2
The number of model snapshots currently being processed
• modelClient
.1.1.15397.1.1.1.15397.12
Total number of model transactions performed
• modelObjectUpdates
.1.13
Total number of model object updates
• modelMaxObjects
.2.2.1.11.1.2.3.2
Date and time when the last model sync client state change occured
• modelClientQueueSize
.6.15397.

1.15397.3.1.3.1.2.1.15397.6.3.1.3
The number of established connections to the source
156 • tcpSourceRequests
.1
A entry containing information about a model object type
• modelObjectTypeName
.6.4.1.2.15397.4.1.1.3.4.1.3.3.4.4.3.1.16.2.3.15397.2
The number of instances of the object type
• source
.
• modelObjectTypeTable
.6.3.1.1.3.1.2.1.1.3.3.6.1.15397.3.3.6.4.1.3.15397.1.1
The name of the object type
• modelObjectTypeCount
.1
The port number this source is listening to
• tcpSourceProtocol
.3.4.1.1.4.2.3. PSM SNMP MIB
Current total number of objects that exist in the system.1
A list of TCP sources that have been configured
• tcpSourceEntry
.16
A list of all available object types
• modelObjectTypeEntry
.3.2
The protocol used by this source
• tcpSourceConnections
.1.1.3.1.15397.1.2.2.1.2.4.3.2.1.1.1.6.2.6.3.3.3.15397.1.1.1.1.1.6.3
• tcpSourceTable
.2.1.2.16.15397.15397.2.1
A entry containing information about a TCP source
• tcpSourcePort
.4.6.3.1.1.1.2.1.16.3.1.6.

5
The number of requests that were malformed and rejected
• tcpSourceFailures
.4 157
. PSM SNMP MIB
.1.2.1.1.15397.3.3.3.4
The total number of received requests
• tcpSourceRejects
.4.1.1.3.3.1.3.3.15397.4.3.1.1.1.1.3.1.2.2
A list of UDP sources that have been configured
• udpSourceEntry
.1.6.1.4.1.3.1.1.6.1
A entry containing information about a UDP source
• udpSourcePort
.1.4.2.4.15397.3.6.1.15397.3.6.1.1.4.15397.15397.3.3.1.3.2.7
The number of requests that was accepted but no action was actually performed
• tcpSourceTotalConnections
.4.2.1.6.15397.2.4.1.6.15397.1.1.1.1.6.2.3
The total number of received requests
• udpSourceRejects
.1.3.1.1.3.1.1.3.2.3.3.3.1.4.3.1
The port number this source is listening to
• udpSourceProtocol
.3.2.15397.2
The protocol used by this source
• udpSourceRequests
.3.1.6.6
The number of requests that was accepted but failed during execution
• tcpSourceDrops
.8
The total number of connections made to the source over its lifetime
• udpSourceTable
.2.3.1.6.3.1.1.2.2.3.3.6.1.4.1.1.2.1.2.15397.4.3.3.3.2.1.3.1.6.3.1.1.1.15397.2.1.

15397.1.2.1.15397.4.1.3
The number of dynitem changes waiting to be applied to the PacketLogic realtimes
• plGroupChangeQueueLag
.2
PacketLogic group enabled by administrator (true/false)
• plGroupChangeQueueSize
.5
The number of requests that was accepted but failed during execution
• udpSourceDrops
.3.4.6.1.1.1.1.3.15397.1.2.1.1.4.1.1.1.4
• plGroupTable
.3.15397.4.4
The number of milliseconds passed since the last change was enqueued.6.2.1.1.6. PSM SNMP MIB
The number of requests that were malformed and rejected
• udpSourceFailures
.1.4.1.1
A entry containing information about a PacketLogic group
• plGroupName
.3.3.1.1.3.1.3.1.2.2.3.1.
• rulesetTable
.1.4.4.1.15397.1.4.4.3.1.3.3.3.1.6.1
Name of the PacketLogic proxy group
• plGroupEnabled
.2.3.6.2.1.3.4.1.2.4.1.3.1
A list of PacketLogic groups (plGroupEntry) that we have configured
• plGroupEntry
.2.15397.15397.1.2.1.3.3.3.6.4.4.1.3.2.2.4.6.6.15397.3.1.2
A list of PacketLogics rulesets (rulesetEntry) that we have configured
158 • rulesetEntry
.1.6.1.1.4.1.3.1.6.1.15397.1.3.4.6
The number of requests that was accepted but no action was actually performed
• packetlogic
.15397.4.

2.6.3.1.1.2.3.4.1.15397.5
Date and time when the last ruleset state change occured
• rulesetReconnects
.4.3.9
Number of commits performed on this ruleset
• rulesetLastCommit
.3.1.4.1.12 159
.1.1.3.2.3.1.1.15397.3.1.3.4.3.1.2.1.15397.1.2.1.4.3.2.15397.1.6.1.15397.2.2.6.1.1.4.6.2.4.6.2.4.2.4.1.1.4.1.1.4.1.15397.1.3.3.1.1.1.3.15397.2
IP address of the PacketLogic ruleset
• rulesetGroupName
.1.10
Date and time when the last commit occured
• rulesetRollbacks
.4.11
Number of rollbacks performed on this ruleset
• rulesetLastRollback
.1.1.15397.3.6.2.3.1
Type of IP address of the PacketLogic ruleset
• rulesetAddress
.6.15397.1.1.4.4.1.2.2.3.3
Name of the group to which the ruleset belong
• rulesetState
.1.3.4.2.4
Current ruleset state
• rulesetStateLastChanged
.1
A entry containing information about a specific PacketLogic
• rulesetAddressType
.2.6.6
Number of reconnects performed on this ruleset
• rulesetCommits
.4.3. PSM SNMP MIB
.3.4.1.3.1.2.2.1.6.15397.1.3.4.4.1.1.1.6.1.15397.2.2.3.4.1.4.2.6.2.4.

1.4.6.1.4.15397.4.6.3.1.15397.1.4.1.3.6.6.4.1.1.1.6.8
Total number of removed netobjects (lifespan)
• rulesetNetObjItemsAdded
.13
Total number of added netobject items (lifespan)
• rulesetNetObjItemsRemoved
.1.1.1.3.1.1.15397.1.3.3
A list of PacketLogics realtimes (realtimeEntry) that we have configured
• realtimeEntry
.1
Type of IP address of the PacketLogic realtime
• realtimeAddress
.6.2.4.4.3.2.1.1.2.15397.3.15397.16
Total number of removed netobject attributes (lifespan)
• realtimeTable
.4.2.1.4.15397.3.1.1.15397.6.2.1.3.4.1.1.6.1
A entry containing information about a specific PacketLogic
• realtimeAddressType
.14
Total number of removed netobject items (lifespan)
• rulesetNetObjAttrsAdded
.3.4. PSM SNMP MIB
Date and time when the last rollback occured
• rulesetNetObjsAdded
.4.3.1.6.1.2.1.1.3.3.15397.7
Total number of added netobjects (lifespan)
• rulesetNetObjsRemoved
.2.4.1.3.3.4.15397.3.2.3.3.3.2.2.1.2.1.2.15397.4.4.1.2
160 IP address of the PacketLogic realtime
.2.2.2.3.3.4.1.4.4.1.1.1.4.3.1.1.3.3.1.1.6.2.15
Total number of added netobject attributes (lifespan)
• rulesetNetObjAttrsRemoved
.

15397.5
Date and time when the last realtime state change occured
• realtimeReconnects
.1.1.1.2.4.3.1.15397.3.1.1.2.7
Total number of added netobjects (lifespan)
• realtimeDynItemsRemoved
.2.4
A list of PacketLogic groups (plProxyGroupEntry) that we have configured
161
.4.3.
wrong splitkey.4.4.3.1.3.1.1.4.1.1.4.1.3.3.1.3.2.1.15397.1.3.2.15397.9
Total number of dynamicnetobject set calls (lifespan)
• realtimeCounterUpdates
.3.1.2.1.6.1.1.4.4.1.3.3.3.6.3.3.4. PSM SNMP MIB
• realtimeGroupName
.1.6.1.1.11
Total number of counter corrupt updates with reasons such as.3.15397.15397.15397.8
Total number of removed netobjects (lifespan)
• realtimeDynSets
.3.3.3.2.4.1.3.6.4.6. out of bounds (lifespan)
• plProxyGroupTable
.10
Total number of counter updates (lifespan)
• realtimeCounterRejects
.6.2.1.4.1. unknown shaping object.1.4
Current realtime state
• realtimeStateLastChanged
.4.6.3
Name of the group to which the realtime belong
• realtimeState
.3. including but not limited to.1.3.1.15397.1.4.3.3.4.1.3.4.15397.4.1.1.4.1.1.2.6
Number of reconnects performed on this realtime
• realtimeDynItemsAdded
.4.6.1.1.4.3.3.3.3.15397.1.6.2.6.1.

3.2
Total number of dispatched RADIUS packets
• radiusSnooperDropped
162 .
• misc
.4. PSM SNMP MIB
• plProxyGroupEntry
.1.6.4.4.1.15397.2.3.1
A entry containing information about a PacketLogic group
• plProxyGroupAddressType
.3
.2.4.4.3.4.1.6.1.3.2.4
The number of unprocessed events in this PacketLogic group.1
A list of RADIUS snoopers that have been configured
• radiusSnooperEntry
.1.2.5.1.4.2
IP address of the PacketLogic ruleset
• plGroupEventCount
.1.3.2.3.3.1.1.1.1.4.3
The number of events processed by this PacketLogic group.4.4.3.4.1.1.6.1.15397.15397.1.3.3.1.3.1.3.3.1.6.5.5.6.1.1.5
• radiusSnooperTable
.15397.15397.1.5.3.2.1.1.1.1
Type of IP address of the PacketLogic ruleset
• plProxyGroupAddress
.15397.15397.3.6.1.4.15397.1.1.
• plGroupEventQueueSize
.4.1.6.1.15397.3.3.2.15397.1.1.6.1.1.1.1.6.4.5.6.1.1.2.2.3.4.15397.1.4.4.2.3.1.2.1
A entry containing information about a RADIUS snooper
• radiusSnooperInterface
.4.6.1.3.4.1.4.4.1.3.3.1
The name of the interface this snooper is listening to
• radiusSnooperDispatched
.1.1.

1.6.1.6.1.2
A list of generic packet snoopers that have been configured
• packetSnooperEntry
.15397.5.5.2.2.1.4.1.5.1.4.3
Total number of dropped packet packets
• packetSnooperDuplicates
.4.1.1.1.3.1.1.5.3.6.15397.6.3.15397.4.3.2.1.1.2.2.3.3.1.3.3.1.1.1.6.3.1.3.15397.1.1.1.5.5
The number of times the RADIUS snooper has been restarted
• radiusSnooperRunning
.1.3.1.1.6.2.1.1.6.1.1.15397.2
Total number of dispatched packet packets
• packetSnooperDropped
.1.4.15397.2.3.1.1
The name of the interface this snooper is listening to
• packetSnooperDispatched
.4.4.3.6.2.15397.2.5.1.1.15397.5.1.2.1.5.15397. PSM SNMP MIB
Total number of dropped RADIUS packets
• radiusSnooperDuplicates
.4.2.3.3.1.5.1
A entry containing information about a packet snooper
• packetSnooperInterface
.6
The current running state of the RADIUS snooper
• packetSnooperTable
.4.3.1.2.6.2.3.5.6.1.1.4.1.2.4
Total number of duplicate RADIUS packets received
• radiusSnooperLaunches
.3.2.4
Total number of duplicate packet packets received
• packetSnooperLaunches
.5
The number of times the packet snooper has been restarted 163
.3.1.2.3.15397.1.

3.3
• cdrAccountedTraffic
.6.4
OBSOLETE! The total number of sessions currently being tracked for traffic
• cdrOpenRecords
.2.3.3.3.3.1.3.3.2.5. that has been accounted to sessions
• cdrIgnoredTraffic
.6.3.1
OBSOLETE! The total amount of traffic. in bytes.4.4.4.5.4.15397.4.3.1.2.2.4.1.1.1.1.1. in bytes.5
OBSOLETE! The total number of currently open CDR:s (excluding sessions for which CDR
writes are disabled due to configuration).1.4.1.1.2.5.
• cdrGeneratedRecords
.1.15397.15397.1.3
OBSOLETE! The total amount of traffic.6.3.3.1.5.1.6.3.1.3.1.2
OBSOLETE! The total amount of traffic.1.3.6.3.1.6.2.3.6.15397.3.6
The current running state of the packet snooper
• cdr
.5.6.3.15397.3.15397.2.8
The total amount of traffic. in bytes.2.6
The total number of generated CDRs since startup
• cdrLostRecords
.1.1.4. that has been seen but could not be accounted
to any session
• cdrActiveSessions
. that could have been accounted to a session.2.5.3. in bytes.1.
but was not due to configuration
• cdrUnaccountedTraffic
.6.5.3.7
The total number of lost CDRs due to encoding or disk write failures
• cdrLostTraffic
.15397.1.1.1.3.15397.2.3.6.3.5.4.15397.15397.3.1.1. lost due to encoding or disk write failures
164
.2.5.3.4.3.1.1.1. PSM SNMP MIB
• packetSnooperRunning
.3.5.1.1.

3.
• counterReset
.2
Total number of counters resetted when last reset occurred.1
"Date and time when the last counter reset occurred
• counterResetLastCount
.1.1.6
• controller
.15397.3.15397.1.6.6.2.6.3.6.4.
• redundancy
.2.4.2
Total number of bytes lost due to missing target object.1.1.15397.6.1.5.15397.6.2.5.
• counterBytesReceived
.4.1.4.3.15397.1.1.4.4.1.1.3.15397.15397.4.2.2 165
.1.1.2.3.1.3.15397.3.1.6.1.15397.5.1.4.15397.6.3.3. PSM SNMP MIB
• counters
.4.6.3.5.4.3.4
Total number of bytes received (but not necessarily applied).1.1.1.3.3.1.3.6.1
Current redundancy controller state
• controllerStateLastChanged
.3.5.1.4.1.2.3.3.1.1.4.5.3.1.1.6.3.
• counterUpdatesReceived
.4.3.15397.
• counterBytesLost
.4
• counterUpdatesLost
.1.1
• controllerState
.6.15397.1.5.1.6.3
Total number of counters updates received (but not necessarily applied).5.1.4.6.6.2.1.3.5.1.5
• counterResetLastTime
.1.2.2.4.2.3.2.1.3.4.1
Total number of counters updates lost due to missing target object.1.1.2.5.1.

if any
• syncClientRemotePort
.3.1.3.1.3.1.1.15397.1
Current sync client state
• syncClientStateLastChanged
.1.1
The number of established connections to the sync server
• syncClient
.3.3.3.1.3.1.4.4.1.4.1.4. if any
• syncClientRemoteAddress
.3.1.1
166 PSM trap
.1.15397.1.1.1.5
IP address to the currently connected master.1.3.1.15397.6.4.3.6
Port to the currently connected master.4.3.3
• syncClientState
.4.2.3.3.2.3.1.4.6.6.1.6.3.1.3.3.1.1.3.2.3.6.2.6.3.2.3.6.3.6.1.6.1. PSM SNMP MIB
Date and time when the last controller state change occured
• syncServer
.6.15397.3.1.3
Number of reconnects performed by the sync client
• syncClientRemoteAddressType
.15397.1.15397.6.6.1000
• trapGeneric
.3.1. if any
• notifications
.6.15397.6.3.1.1.6.1.2.1.2.2.2.2.15397.4
Address type of currently connected master.4.6.4.2
Date and time when the last sync client state change occured
• syncClientReconnects
.6.6.6.1.1.1000.6.3.2
• syncServerConnections
.3.2.2.1.4.3.15397.15397.15397.