WIRELESS-INNOVATIONS-PRODUCTS-MIB: View SNMP OID List / Download MIB

MIB for Wireless Innovations distributed management system.

Objects valid for common objects.

Basic information.

This is the software version of the agent and is determined according to the software version control rules of the particular device.

This object denotes the current MIB's version. This value is built by the first line of the DESCRIPTION value of the most recent REVISION statement of the current MIB's MODULE IDENTITY object. Please note, that this comment makes only sense if it is included and read in the component specific MIB.

The version of the WIRELESS-INNOVATIONS-PRODUCTS-MIB, which is included in this (component specific) MIB. This value is the same as the first line of the DESCRIPTION value of the most recent REVISION statement of the WIRELESS-INNOVATIONS-PRODUCTS-MIB's MODULE IDENTITY object (wirelessInnovations).

Current time in Coordinated Universal Time (UTC) format.

Note! This object is obsolete and no longer supported. New object is 'connManOrigAgentIPAddressCS'. This is the IP address of the DCM used in dial-in access. Since the DCM does not use a port number for the agent, setting the port has no affect. Setting this address to 0.0.0.0 causes the DCM to revert back to the default IP address.

This OID is used in the changedIPAddressEvent only.

Geographic location identification of the Agent, either GPS coordinates or the serving cell identification of the Agent's wireless modem (Location Area). If the Agent has a GPS receiver the GPS coordinates should be responded, otherwise the LA. If neither the GPS coordinates nor the LA is known to the Agent, an empty string should be responded. This location id is always a comma separated string. Syntax for GPS coordinates: 'GPS,,' : numeric value (decimal), positive value for north, negative for south, including a decimal point. Allowed characters '-','0'..'9','.' : numeric value (decimal), positive value for east, negative for west, including a decimal point. Allowed characters '-','0'..'9','.' E.g. 'GPS,42.4088172912598,-71.1735153198242', 'GPS,-1.2,12.34' Syntax for LA: 'LA,,,,' : mobile country code, allowed characters '0'..'9' : mobile network code, allowed characters '0'..'9' : location area code (decimal), allowed characters '0'..'9' : cell identity (decimal), allowed characters '0'..'9' If any value is unknown, it has to be left empty but the corresponding comma has to be provided. E.g. 'LA,123,12,67890,1234', 'LA,321,21,456,'

Alias name of the geographic location area (zone name) where the Agent is currently in. If the Agent does not support geographic location identification, an empty string should be responded.

Indicates whether the Agent is currently out of operation. This may be caused e.g. by geographical location change (moving out of active areas / active zones) or by entering any other inactive operating mode (standby). This object has also to be sent within the changedParameterEvent notification, so the manager is able to track the operational state (availability status) of the Agent. The Manager has to consider that if this object is true, the Agent may not send any further notifications/alarms and may not accessible via remote connection until the Agent comes back to operation. If the Agent does not support geographic location identification and any other inactive operation modes, always false should be responded.

This OID is used in the changedParameterEvent only. Indicates the condition why the changedParameterEvent was fired. 0 = user maintenance via another user interface caused parameter changes. 1 = location (zone) change caused immediate parameter changes. 2 = location (zone) change caused parameter changes after latency expired (V1.6.0.0 extension). If the Agent does not support conditional configuration changes or the changedParameterEvent was fired because of user changes, 0 has to be used. Enumeration: 'userMaintenance': 0, 'locationLatency': 2, 'locationChange': 1.

GPS data and related Objects. If the Agent doesn't support GPS data at all, always 'no such object' has to be returned to any request within this section.

Timestamp of GPS data set reported by GPS device.

Zone name related to GPS position (gpsLatitude/gpsLongitude) or empty string in case the position is not within a zone. Note! In case the actual position reflects the crossing of a common border of two zones (one zone left, other zone entered), the zone name of the entered zone is used here.

Position latitude. Numeric value (decimal), positive value for north, negative for south, including a decimal point. Allowed characters '-','0'..'9','.'

Position longitude. Numeric value (decimal), positive value for east, negative for west, including a decimal point. Allowed characters '-','0'..'9','.'

Speed in km/h. Numeric value (decimal) including a decimal point. Allowed characters '0'..'9','.'

Direction in relation to north in degree. Numeric value (decimal) including a decimal point. Allowed characters '0'..'9','.'

Position altitude or empty string in case altitude is not available. Numeric value (decimal) including a decimal point. Allowed characters '0'..'9','.'

Number of used satellites (decimal).

Additional GPS event data.

GPS event type. 1 = Agent has detected start moving 2 = Agent has detected stop moving 3 = Agent has entered a GPS zone 4 = Agent has left a GPS zone 5 = GPS event heartbeat Note! In case the actual position reflects the crossing of a common border of two zones (one zone left, other zone entered), only the entering of the new zone is indicated. Enumeration: 'gpsZoneLeaving': 4, 'gpsHeartbeat': 5, 'stopMovingDetected': 2, 'gpsZoneEntering': 3, 'startMovingDetected': 1.

GPS event generation time in Coordinated Universal Time (UTC) format.

Notification sent by the agent to indicate the occurrence of any type of GPS event (see gpsEventType).

Additional GPS event configuration data.

Object that shows resp. controls whether the GPS event notification is enabled or not.

Object that shows resp. controls whether the GPS event notification destination is the standard notification destination (true: destination is alarmRecipient) or not (false: destination is gpsEventDestination).

Object that shows resp. controls the destination of the GPS event notification. Setting the IP address to 0.0.0.0 will also have the effect of disabling the notification forwarding (like setting gpsEventEnabled to false). Note! In case gpsEventDestinationIsAlarmRecipient is true, this object is just read-only and reflects the alarmRecipient object setting. Then a SET request on this object will fail with an appropriate error.

Object that shows resp. controls the GPS event heartbeat interval (in minutes). Set this object to 0 in order to disable the GPS event of type heartbeat. Set this object to any value but 0 in order to enable the GPS event heartbeat notification. Default value is 0. Allowed range is 0 to 6000 minutes (or 0 to 100 hours).

Alarm objects.

The recipient of all notifications. This IP address can be changed in order to switch the recipient to another (auxiliary) recipient. It can be useful if the OMC must be switched off for maintenance or other purpose. NOTE: Setting the IP address to 0.0.0.0 will have the effect of disabling notification forwarding.

Set this value to true(1) in order to enable alarm forwarding. Note, that the alarm recipients IP address has to be set to alarmRecipient prior to enable alarm forwarding. Set this value to false(2) in order to disable alarm forwarding.

The heartbeat mechanism is an alternative to OMC polling. A heartbeatEvent notification is sent by the agent to indicate that the device and the connection are still active. Set this object to 0 in order to disable the heartbeat. Set this object to any value but 0 in order to enable the heartbeatEvent notification. The value set determines the interval of the heartbeatEvents in minutes. Default value is 0. Allowed range is 0 to 6000 minutes (or 0 to 100 hours).

This object must be set to true(1) in order to force the agent to resend all active alarms to the current manager. Setting this object to false(2) has no effect. On GET requests always false(2) is returned.

This is the counter indicating how many total notifications have been sent from the device since last bootup (or reboot). The counter is included in every private/enterprise notification. The counter starts at 0 on system bootup (or reboot). Upon wrapping, the counter starts at 1, not 0. Since the standard notifications ColdStart and WarmStart will be implemented, any boot (or reboot) sequence will trigger the following notification sequence: 1. ColdStart/WarmStart notification. 1a changedIPAddressEvent with counter = 0 if IP address has been changed during agent downtime. 1b swActivationProgress with counter + 1 resp. counter = 0 (depending on 1a was fired or not) if agent startup has triggert the activation of a new software package. Note: This is an optional notification, it depends on the agent implementation whether he is able to detect that the startup was triggert by the activation of a new software package or not. 2. agentUpAndRunningEvent with counter + 1 resp. counter = 0 (depending on 1a/1b was fired or not) if agent is finally up and running. 2a HeartBeat notification with counter + 1 if HeartBeat enabled. 3. alarm/other notifications with counter + 1 according to alarm/other conditions detected once the agent starts operating.

The alarm table lists all the alarms currently active into the equipment. An entry is added to the table anytime an alarm condition raises. An entry is removed from the table according to the following conditions: 1. the alarm condition ceases (e.g. door open-->door closed). Any Manager GET/GETbulk shall leave the table unaffected 2. the alarm condition is a lacthed-type (e.g. configuration error) and no clear events is possible, therefore the only way to remove the entry from the list is to clear automatically after a GET/GETbulk from the manager. This kind of alarms will always be assigned a severity level 'information (6)'

Alarm table entry.

Table index to identify the instance.

This is the most generic identifier of the problem.

X733 compliance: specific problem unique code,according to a common alarm list. This unique list will be maintained at a central location.

According to X733 and common alarm list: 0=indeterminate 1=critical 2=major 3=minor 4=warning 5=cleared 6=information

X733 compatibility: time stamp for alarm condition change changes can occur on severity level (including set and clear)

According to X733 and common alarm list:The Event Type categorises the alarm.

According to X733 and common alarm list:The Probable Cause defines further qualification of an alarm.

According to X733 and common alarm list: The Additional Text allows a free form text description to be reported. It contains a formatted description of the alarm. If additional information regarding the alarm is unknown, a zero-length string may be used. Otherwise, no string over 128 bytes may be sent.

Must be a Common Topology Address (CTA) This represents the topological address of the equipment below the Agent and references the alarm source. It may also contain optional parameters, details see textual convention CTA.

This objects carries the value of entPhysicalIndex of the affected component.

The purpose of this object is to provide a pointer (OID) into the component specific MIB that relates most directly to this particular alarm. If this alarm is best described by multiple objects in the component specific MIB, the object should be closest common OID. An example would be a MMR remote unit instance that is coded in a table of MMR instances.

This OID is used in the changedParameterEvent only. It is a pointer to a component-specific object, whose parameter was changed. It points to the highest part of the tree where changes where made. That is, the manager is required to perform a WALK on this OID in order to get the current settings.

Bitcoded value indication the supported alarm severity levels within a SET via the alarmConfigTable: Bit0=indeterminate (0x01) Bit1=critical (0x02) Bit2=major (0x04) Bit3=minor (0x08) Bit4=warning (0x10) Bit5=disable (0x20) Bit6=information (0x40) Bit7 not used, always not set E.g: 00111110 (0x3E, 62): critical, major, minor, warning and disable supported. 0: setting/changing alarm severity levels not supported at all.

Agent alarm configuration table. This table lists all alarms supported by the agent. It is used to read resp. change default alarm parameter settings. This settings apply system-wide, even in distributed systems for every CTA.

Alarm configuration table entry.

Referenced alarm ID: This is the most generic identifier of the alarm.

Reading this object indicates the current level the alarm is set at. Setting this object changes the current level accordingly. Note! Severity 5=cleared in this context indicates that the alarm is disabled/to be disabled. Setting this object to any other level than supported (indicated by alarmSeveritiesSupported4Set) is not valid and results in a return of wrongValue.

Agent alarm user text configuration table. This table lists all alarms that support user defined text. It is used to read resp. change default alarm user text settings. This settings specific for every CTA within a distributed system.

Alarm user text configuration table entry.

Referenced Common Topology Address. It may also contain optional parameters, details see textual convention CTA.

Referenced alarm ID: This is the most generic identifier of the alarm.

User defined text for referenced alarmID at referenced CTA.

With this section alarm thresholds are handled. If the agent doesn't support alarm threshold management at all, always 'no such object' has to be returned to any request within this section.

This table provides threshold information for each alarm that has user-defined thresholds. Thresholds can be thought of as single or ranged. A single threshold is one in which an alarm is generated if a measurement falls below or rises above the threshold. For example, if we have a temperature threshold of 50 C, any temperature above this threshold will generate an alarm. A range in this case is not needed. However, common sense dictates that a value which cannot be represented by the hardware should not be used in a SET, so an upper range (or lower as the case may be) is still implied. The settings in this table are specific for every CTA within a distributed system. They are also specific to a particular alarm type, represented by the alarm ID. Since there may be as many as two thresholds for an alarm (minimum and maximum), this must be accounted for also. Therefore, this table is indexed by the following: - alarmThreshold4CTA - alarmThresholdalarmID - alarmThresholdIdx If not applicable to a particular agent implementation, 'no such object' must be returned to any request within this table. All alarms with a single threshold or simple linear ranged threshold can be completely described by the few basic objects in this table and the network manager can easily set up these thresholds properly. In this case, alarmThresholdPointerToValueLookupTableMainIndex is set to 0. For example, NodeX DL and UL RSSI alarms fall into this category. For alarms with more complex threshold ranges or whose set values cannot describe them, the object, alarmThresholdPointerToValueLookupTableMainIndex points into alarmThresholdValueLookupTable where each allowed value is defined and described. These alarms include NodeX VSWR ratios, external alarm polarity, etc.

Alarm threshold configuration table entry.

1st table index. Referenced Common Topology Address. In distributed systems the threshold for the same alarm may be configured different depending on the topology address of the alarm source. It may also contain optional parameters, details see textual convention CTA.

2nd table index. Referenced alarm ID: This is the most generic identifier of the alarm.

Some alarms have just a single threshold, others have a minimum and a maximum threshold. This index identifies whether this is a single, minimum, or maximum threshold. Possible values: 1 - single or minimum threshold 2 - maximum threshold

Textual description of the referenced threshold entry.

Unit of the referenced threshold entry. E.g. dB, dBm, Hz, ... or empty string.

This is the scale factor for the referenced threshold entry and only applies to simple thresholds. The value should be 0 in the case of a complex threshold. Otherwise, this number is a base 10 exponent value. It applies to the following values: - alarmThresholdStepValue - alarmThresholdMinValueAllowed - alarmThresholdMaxValueAllowed - alarmThresholdActValue All these values are multiplied with alarmThresholdScale power of 10. E.g.alarmThresholdActValue is 125 and alarmThresholdScale is -1 ==> real actual value is 12.5

This object only applies to simple thresholds. It is used to identify the discrete intermediate values of the complete threshold range from alarmThresholdMinValueAllowed to alarmThresholdMaxValueAllowed. In the case of complex thresholds, the value should be 0.

Possible values: Simple thresholds with defined ranges: This is the allowed minimum value of the threshold range. Single minimum thresholds: This is the value the entity should not fall below. Single maximum thresholds and complex thresholds: This value should be 0.

Possible values: Simple thresholds with defined ranges: This is the allowed maximum value of the threshold range. Single maximum thresholds: This is the value the entity should not rise above. Single minimum thresholds and complex thresholds: This value should be 0.

This is the actual value of the referenced threshold entry. For simple threshold ranges, please refer to alarmThresholdMinValueAllowed and alarmThresholdMaxValueAllowed for the allowed range. Complex ranges are defined by corresponding entries in alarmThresholdValueLookupTable.

For complex alarm thresholds, this is the pointer into the alarmThresholdValueLookupTable. This object does not apply to simple thresholds and should be 0 in those cases.

This table contains the threshold values of those alarms with ranges that are: 1. not linear or 2. cannot be described in by the few basic parameters in alarmThresholdTable. Alarm thresholds with these characteristics are referred to as complex thresholds and include NodeX VSWR ratios and external alarm polarity. Alarms whose thresholds fall into this class must still be set in a fairly simple manner and the allowed values must be clearly communicated to the network manager. Therefore an integer value must be mapped to an ASCII string describing the particular setting. This table must be presented such that alarmThresholdLookupValue objects are in ascending order based on their values.

Alarm threshold value lookup table entry.

Main table index referenced by alarmThresholdPointerToValueLookupTableMainIndex.

2nd table index. References the possible threshold values.

This object indicates a value that may be used to set alarmThresholdActValue for the corresponding alarm. Instances of this object must be ordered such that their values are ascending.

This is the ascii string indicating the 'real' set value, including the units if applicable. For example if setting an external alarm polarity, this object may be 'active high'.

System summary alarm status. Can be used for a simple system summary alarm polling. This object gets also delivered with the heartbeatEvent notification.

Agent alarm configuration table. This table lists all alarms supported by the agent. It is used to read resp. change default alarm parameter settings. This settings apply system-wide, even in distributed systems for every CTA.

Alarm configuration table entry.

Referenced Common Topology Address. It may also contain optional parameters, details see textual convention CTA.

Referenced alarm ID: This is the most generic identifier of the alarm.

Reading this object indicates the current level the alarm is set at. Setting this object changes the current level accordingly. Note! Severity 5=cleared in this context indicates that the alarm is disabled/to be disabled. Setting this object to any other level than supported (indicated by alarmSeveritiesSupported4Set) is not valid and results in a return of wrongValue.

Alarm raise latency in seconds. Note: This object may not given for all alarms.

Agent alarm user text configuration table. This table lists all alarms that support user defined text. It is used to read resp. change default alarm user text settings. This settings specific for every CTA within a distributed system.

Alarm user text configuration table entry.

Referenced Common Topology Address. It may also contain optional parameters, details see textual convention CTA.

Referenced alarm ID: This is the most generic identifier of the alarm.

User defined text for referenced alarmID at referenced CTA.

Notification objects.

Trap workflow: - this notification is sent any time an alarm raises or gets cleared - no acknowledge is required if sent as trap (not valid if sent as inform) - the alarm trap is sent once, without any repetitions if sent as trap (not valid if sent as inform) - the trap counter starts from 0 after reboot - each notification following notification increases the trap counter by 1 in order to provide an unique trap counter. - the trap counter wraps back to 1 after it reaches its maximum value (if this case should ever arise) in order to provide easy detect reboot capability V1.5.0.0 extension: - basicAgentLocationIdentification. For backward compatibility the manager has to use an empty string if this object is not provided with the notification.

A notification sent by the agent to indicate that the device and the connection are still active. The send interval is decided by means of alarmHeartbeatInterval. Heartbeat mechanism is an alternative to OMC daily polling.

If manual user changes via other interfaces than SNMP, automatic changes based on geographic location change or any operating mode change happened, this notification is send to the OMC determined by the value of alarmRecipient (in case of manual user changes after logout). V1.5.0.0 extensions: This notification has also to be send if automatic configuration changes were made based on geographic location changes, or any other operating mode change happened. - basicAgentLocationIdentification contains the geographic location identification of the Agent. For backward compatibility the manager has to use an empty string if this object is not provided with the notification. - basicAgentLocationAlias contains the geographic location area (zone) name. For backward compatibility the manager has to use an empty string if this object is not provided with the notification. - basicAgentOutOfOperationArea indicates whether the Agent is out of operation (true) or not (false). For backward compatibility the manager has to use false if this object is not provided with the notification. Depending on this object the Manager has to suspend (basicAgentOutOfOperationArea==true) resp. resume (basicAgentOutOfOperationArea==false) the heartbeat supervision of the corresponding system (if activated). - basicAgentConditionChangedConfig indicates whether this notification was fired because of user maintenance (0) or other conditions (details see description of the object itself). For backward compatibility the manager has to use 0 if this object is not provided with the notification. - connAgentUID2. Enables the manager to detect system replacement at agent side (connAgentUID changed while connAgentUID2 keeps equal or vice versa). Added also to this notification because the system may have been replaced while it was out of operation so that the agentUpAndRunningEvent may not has been sent out. For backward compatibility the manager has to use an empty string if this object is not provided with the notification. V1.5.1.0 extension: - basicCurrentTime contains the date/timestamp when the event occurred.

Used to notify a new agent IP address to the manager determined by the value of alarmRecipient resp. connVpnManagerVirtualIP. This is NOT used if the agent is connected 'On Demand' to a circuit switched network. As the standard SNMP notification is 'fire and forget' and may get lost during distribution, this notification has to be send periodically with a suitable period (see also latest revision of specification Q0359R0 OAM Communication). Possible scenarios for sending this notification: LAN: IP address was changed during runtime by administrator or DHCP. CSAO: Initial connection to the network or reconnection after unexpected disconnect. PSAO: Initial connection to the packet data network access server or reconnection after unexpected disconnect. PSOD: Connection to the packet data network access server was invoked by an incoming SMS. In this case connAttachPSODrequesterSMS is set to the SMS sender number, in all other scenarios connAttachPSODrequesterSMS is set to an empty string. Note! This notification MUST NOT be sent: - if the IP address change was explicitely invoked by the manager with a SET on connAgentIPAddressLAN or connManOrigAgentIPAddressCS. - if the agent is connected 'On Demand' to a packet switched network and the connection to the network is initiated by the agent itself in order to send out any other notification (entConfigChange, alarmTrap, heartbeatEvent, changedParameterEvent, ...). - if the agent is connected 'On Demand' to a circuit switched network. V1.3.0.0 extensions: - connAgntOrigIfNetworkType identifies the network type for that the new IP address is valid. For backward compatibility the manager has to use PS if this object is not provided with the notification. - connVpnEnabled identifies whether VPN is enabled or not. For backward compatibility the manager has to use false if this object is not provided with the notification. - connVpnAgentIPIsVirtual identifies whether the reported IP address is a virtual VPN address or not. For backward compatibility the manager has to use false if this object is not provided with the notification. If VPN is enabled, additionally the virtual agent VPN IP address has to be reported as soon as the VPN tunnel is established. In that case the manager has to wait for the virtual VPN IP address before starting communication. V1.5.0.0 extension: - connAgentUID2. Enables the manager to detect system replacement at agent side (connAgentUID changed while connAgentUID2 keeps equal or vice versa). Added also to this notification because it may be fired before agentUpAndRunningEvent (see description alarmTrapCounter). For backward compatibility the manager has to use an empty string if this object is not provided with the notification.

This notification is sent if any configuration change by the manager requires an agent reboot.

This notification is sent to indicate any agent startup. V1.5.0.0 extension: - basicAgentOutOfOperationArea indicates whether the Agent is out of its operational area (true) or not (false). For backward compatibility the manager has to use false if this object is not provided with the notification. - connAgentUID2. Enables the manager to detect system replacement at agent side (connAgentUID changed while connAgentUID2 keeps equal or vice versa). For backward compatibility the manager has to use an empty string if this object is not provided with the notification. - swActivePackageVersion. For backward compatibility the manager has to use an empty string if this object is not provided with the notification. - swActivePackagePatchLevel. For backward compatibility the manager has to use zero if this object is not provided with the notification. - On reception of this notification and if the Agent is not out of its operational area (basicAgentOutOfOperationArea==false), the Manager has to resume the heartbeat supervision of the corresponding system (if activated).

This notification is sent by the Agent during shutdown to indicate that the system will be 'out of service'. On reception of this notification the Manager has to suspend the heartbeat supervision of the corresponding system (if activated).

This notification is sent by the Agent in case of a location (zone) change that caused no other parameter changes. In case of a location (zone) change that caused immediate or latency delayed parameter changes, the changedParameterEvent is used instead.

Conformance objects.

A collection of objects providing basic device status and control.

A collection of alarm information common to all devices.

A collection of notifications common to all devices.

Compliance objects.

The compliance statement for all devices in this system.

A collection of objects providing for connectivity control.

A collection of device control objects.

A collection of optional notifications.

A collection of optional objects.

This group contains all objects whose status has been changed to obsolete.

Connectivity objects.

This is the agent unique identifier. The manager uses this UID to distinguish the agents integrated in the managers database. It has to be included in every private/enterprise trap. Besides the sysName, which is for free customer use and gets displayed at any agent or manager GUI, this is the internal unique communication identifier between manager and agent at communication protocol level. This is a read only factory setting, it can be e.g. a MAC address, a Windows GUID or similar unique identifier. If this setting is not available at the agent, always an empty string has to be returned. For backward compatibility: If the manager receives an empty connAgentUID it has to use the sysName for system identification, as already implemented with mib versions prior to version 1.1.0.0

Note! This object is obsolete and no longer supported. New objects are 'connAgentMainConnectivity' and corresponding 'connAgntOrigIfConnectionType'. Agent main connectivity type. This identifies resp. sets the preferred method and interface the agent connects to the network. It depends on the agent implementation whether all connectivity types are supported.

This is the IP address of the agent, if the agent is connected to a LAN network. The port number is that one the agent listens for SNMP GET/SET requests. It depends on the agent implementation whether a SET request is supported at all or maybe only setting the port gets rejected. Maybe setting the LAN IP address is only allowed to the LAN administrator outside the agent application (e.g. by DHCP or manually). Nevertheless a GET request has to reflect the actual setting, return 0.0.0.0:0 if LAN connection is not supported. Setting a new value should get active immediately (but this may depend on the operating system running at the agent).

Agent main connectivity. This identifies resp. sets the preferred interface the agent connects to the network. It depends on the agent implementation whether all interfaces/network types are supported.

Notification type the agent uses for any event defined within commonDeviceNotification and any component specific event. See TC NotificationType.

This is an alternative unique identifier of the Agent. This UID can be used by the Manager to detect system replacement at Agent side (connAgentUID changed while connAgentUID2 keeps equal or vice versa). It is also included in the private/enterprise agentUpAndRunningEvent, changedParameterEvent and changedIPAddressEvent notification. This is a read only factory setting, it can be e.g. the IMSI identification of the Agent's wireless modem SIM card, a concatenation of the HW-ID and serial number out of the HW HID the Agent is running on or a similar unique identifier. If this ID is not available at the Agent, always an empty string has to be returned.

This object indicates / controls which web communication protocol is active at the Agent. This setting applies to any HTTP based communication: Agent standard WEB interface and SNMP triggered file transfer (commonDeviceFileTransfer). 1 = HTTP 2 = HTTPS 3 = HTTP and HTTPS (in this case it is up to the Manager / web client to use HTTP or HTTPS) A change of this setting may require a restart of the WEB server at the Agent. In this case the WEB server restart is triggered by the Agent immediately with the successful SET request. If this object is not supported by the Agent, the Manager has to use HTTP. Enumeration: 'http': 1, 'https': 2, 'httpAndHttps': 3.

This object shows/controls the timeout (in seconds) used by the Agent waiting for inform responses before resending. Valid values are: 10s, 20s, 30s, 40s, 50s, 1min, 2min, 3min, 4min, 5min, 6min, 7min, 8min, 9min, 10min. Enumeration: 'm4': 240, 's10': 10, 's30': 30, 'm8': 480, 'm5': 300, 'm10': 600, 'm7': 420, 'm6': 360, 'm1': 60, 'm3': 180, 'm2': 120, 's50': 50, 'm9': 540, 's20': 20, 's40': 40.

This object shows/controls the number of retries used by the Agent in case inform resending. Allowed range is 1 to 20 times or -1. The value of -1 indicates retries forever until the inform resonse gets received.

Connectivity objects for connections initiated by the manager.

This is the IP address of the agent, if the agent gets accessed by an incoming circuit switched call (address of the agent dial-in server). The port number is that one the agent listens for SNMP GET/SET requests. It depends on the agent implementation whether a SET request is supported at all or maybe only setting the port gets rejected. Nevertheless a GET request has to reflect the actual setting, return 0.0.0.0:0 if circuit switched connection is not supported. Setting a new value should not affect the current connection, only future dial-in connections (but this may depend on the operating system running at the agent).

This is the username for PPP authentication, if the agent gets accessed by an incoming circuit switched call. It depends on the agent implementation whether a SET request is supported. Setting a new value should not affect the current connection, only future dial-in connections (but this may depend on the operating system running at the agent).

This is the password for PPP authentication, if the agent gets accessed by an incoming circuit switched call. For security reasons it is highly recommended that reading this object returns 14 asterisk character '**************'. Setting a new value should not affect the current connection, only future dial-in connections (but this may depend on the operating system running at the agent).

Communication idle timeout in minutes for agent incoming circuit switched connections. When expires the agent should drop the incoming circuit switched connection. A value of 0 denotes an infinite time (incoming connection never dropped by the agent). The default value is 0.

Connectivity objects for connections initiated by the agent.

Agent connectivity interface table. This table lists all possible interfaces that can be used for network connections at agent side.

Interface table entry. It depends on the agent implementation and connectivity type whether all the table entry objects are used at all resp. how it is interpreted. If an object is not applicable, a GET should return an empty value and a SET should return the notWritable error status.

Table index. Also used to indicate the priority for interfaces of the same network type. Lower indexes indicate higher priority.

Note! This object is obsolete and no longer supported. New objects are 'connAgntOrigIfNetworkType' and 'connAgntOrigIfConnectionType'. Connectivity type of this interface.

This object shows/controls whether this interface is enabled or disabled. It also shows whether or not such control is applicable. A GET may return: notApplicable(0) enabled(1) disabled(2) The value, notApplicable(0) is used to identify those interfaces that cannot be enabled or disabled by this object. Setting this object to notApplicable(0) is not valid and results in a return of wrongValue. Setting this object to enabled(1) enables this interface. Setting this object to disabled(2) disables this interface. In the case of an interface that does not support this control object, it is only legal to GET the value. A GET must always return notApplicable(0). Any SET must return notWritable. Enumeration: 'disabled': 2, 'notApplicable': 0, 'enabled': 1.

Depending on network type, used for: - CS, PS: modem / network initialization string. - SMS: SMS prefix. - DC, LAN: not used.

Depending on network type, e.g. used for: - circuit switched dial-out PPP connections: Telephone number of the recipient for all notifications. - packet switched network connection: Access code for the packet data network access server. - SMS: destination SMS number.

Username. Depending on network type, e.g. used for: - circuit switched dial-out PPP connections: This string is used to authenticate the user's access to the OMC remote access server. - packet switched network connection: This string is used to authenticate the user's access to the packet data network access server.

Password, for security reasons it is highly recommended that reading this object returns 14 asterisk character '**************'. Depending on network type, e.g. used for: - circuit switched dial-out PPP connections: This string is used to authenticate the user's access to the OMC remote access server. - packet switched network connection: This string is used to authenticate the user's access to the packet data network access server.

Network type of this interface. See TC NetworkType.

Connection type of this interface. See TC ConnectionType. This object shows/controls the connection type of this interface. It also shows whether or not such control is applicable. A GET may return: notApplicable(0) onDemand(1) alwaysOn(2) The value notApplicable(0) is used to identify those interfaces that do not distinguish the connection type. Setting this object to notApplicable(0) is not valid and results in a return of wrongValue. In the case of an interface that does not support this control object, it is only legal to GET the value. A GET must always return notApplicable(0). Any SET must return notWritable.

Communication idle timeout in minutes for agent side 'On Demand' packet switched network connection. Note! This applies ONLY when the connect request was issued by SMS. When expires the agent should drop this connection. The default value is 5.

This OID is used in the changedIPAddressEvent only. If the agent is connected PSOD and the connection to the packet data network access server was invoked by an incoming SMS, this object is set to the SMS sender number, in all other scenarios connAttachPSODrequesterSMS is set to an empty string.

Shows/sets whether SMS initiated packet switched network connection in the 'On demand' mode is enabled or disabled.

SMS service center number.

With this object the manager is able to force a disconnect of an active agent originated network connection. A GET always returns notApplicable(0). A SET to notApplicable(0) has no affect and triggers no further agent activity. A SET to disconnect(1) will cause the agent to disconnect from the network and behave according the actual connectivity settings. Note: The response has to be sent before disconnecting from network. If disconnect is not applicable to the current connection network type (e.g. LAN, SMS), error inconsistentValue has to be returned. Enumeration: 'notApplicable': 0, 'disconnect': 1.

VPN communication objects. If the agent doesn't support VPN at all, always 'no such object' has to be returned to any request within this section.

This object shows/controls whether VPN communication is enabled or disabled.

Physical IP address and port of actually connected VPN server. In case VPN is actually not connected, '0.0.0.0' will be responded.

Virtual VPN IP address and port of the recipient of all notifications in case VPN is enabled. Otherwise alarmRecipient (physical IP address) is used. Note! In case the Agent does not distinguish the notification destination for VPN and standard connection, this object reflects the setting of alarmRecipient and a SET request on this object will fail with an appropriate error.

This OID is used in the changedIPAddressEvent only, see also description there. Indicates whether the reported IP address is a virtual VPN address or not.

Andrew VPN objects.

Encryption type for transferred data except keep alive packet. Enumeration: 'cryptNone': 0, 'cryptAES128': 1, 'cryptBlowfish32': 3, 'cryptBlowfish64': 2.

VPN authentication user name. This string is used to authenticate the access to the VPN server.

VPN authentication password. This string is used to authenticate the access to the VPN server. For security reasons it is highly recommended that reading this object returns always asterisk characters '**************'.

Keep alive interval in seconds. Cyclic I am alive communication between VPN client and server.

Open VPN objects.

Protocol for communicating with OpenVPN server - UDP or TCP. Enumeration: 'udp': 1, 'tcp': 2.

Actual virtual IP address of the Agent (VPN client). In case VPN is currently not connected, 0.0.0.0 has to be responded.

Object that shows resp. controls in case of VPN connection whether the destination for all notifications is the standard notification destination (true: destination is alarmRecipient) or not (false: destination is connVpnManagerVirtualIP). Note! In case the Agent does not distinguish the notification destination for VPN and standard connection, a SET request on this object will fail with an appropriate error.

Object that shows whether the current VPN mode is secure (vpnConnected) or in unsecure fallback mode (vpnFailed). unknownOrNotApplicable is used in case VPN is disabled. Enumeration: 'unknownOrNotApplicable': 1, 'vpnFailed': 2, 'vpnConnected': 3.

Objects handling VPN server groups. Due to server scalability and failover aspects more than one server may be used. The server groups identify the different server instances.

Object that shows whether the Agent/VPN client is assigned to a VPN server group. unknownOrNotApplicable is used in case VPN is disabled. Enumeration: 'assigned': 3, 'unknownOrNotApplicable': 1, 'unassigned': 2.

Object that shows the actual assigned VPN server group number (>0) or 0 in case VPN server is not assigned.

Object that shows whether the Agent/VPN client is actually connected to resp. currently trying to connect the main or backup VPN server. unknownOrNotApplicable is used in case VPN is disabled. Enumeration: 'unknownOrNotApplicable': 1, 'main': 2, 'backup': 3.

Table that holds VPN server groups. Due to scalability aspects more than one entry may be used. This table identifies the different server group instances of the different server types (main/backup). During client side server scan procedure the servers decide to accept a connection request from a particular client or not so the client can find its assigned server instance.

Description.

Table index to identify the instance. Corresponds with VPN server group number.

Main VPN server physical IP address and port.

Backup VPN server physical IP address and port.

With this object the manager is able to force an immediate VPN disconnect. A GET always returns notApplicable(0). A SET to notApplicable(0) has no affect and triggers no further agent activity. A SET to disconnect(1) will cause the agent to disconnect VPN and behave afterwards according the actual connectivity settings. Note: The response has to be sent before disconnecting VPN. If disconnect is not applicable (VPN not connected), error inconsistentValue has to be returned. Enumeration: 'notApplicable': 0, 'disconnect': 1.

Communication idle timeout (related to application oriented incoming data requests) in minutes for agent outgoing always on connections. When expired the agent should drop and reconnect the outgoing always on connection. A value of 0 denotes an infinite time (outgoing always on connection never dropped by the agent, except main connectivity was changed and new connection type is no longer always on). The default value is 0. Allowed range is 30 to 1440 minutes (24 hours).

Agent SMS whitelist table. This table lists all accepted SMS numbers for incoming SMS requests.

Description.

Table index to identify the instance.

Authorized SMS phone number for incoming SMS requests.

This object shows/controls whether all location area change based notifications are enabled or not. Location area change based notifications are: - changedParameterEvent[basicAgentConditionChangedConfig=locationChange] (->immediate RF configuration change) - changedParameterEvent[basicAgentConditionChangedConfig=locationLatency] (->RF configuration change after latency expired) - changedLocationAreaEvent (->no RF configuration change)

Device and agent application control objects. Objects in this group provide for resetting of remote devices. In the future, other control such as software download and disaster recovery will be provided.

This object allows the agent application to be reset and if needed, the operating system as well. A GET must return running(0). A SET to reboot(1) causes a complete reboot of the operating system and agent application. A SET to restart(2) causes an agent application restart. A SET to running(0) is not valid and results in a return of wrongValue. Note: before starting the reboot/restart the agent has to send back the SET response. Enumeration: 'running': 0, 'reboot': 1, 'restart': 2.

With this section software features of the agent are handled. If the agent doesn't support software feature keys at all, always 'no such object' has to be returned to any request within this section.

This table lists all possible SW features supported by the agent.

Description.

Table index.

Textual description of the feature.

This object shows whether the feature is enabled or not.

With this object a new SW feature can be enabled by writing a valid feature key. A GET always returns an empty string. A SET with an invalid feature key results in an error being returned.

Objects for file transfer control. The actual file transfer is done via HTTP. In this section the following naming definition applies: - file upload: file transfer from Manager to Agent. - file download: file transfer from Agent to Manager.

Objects for file upload control. The actual file transfer is done via HTTP POST. If the Agent doesn't support file upload at all, always 'no such object' has to be returned to any request within this section. General: - Any state transition not shown in the state diagram (except state transcision to idle - see idle description) is not allowed and should respond an SNMP error code. Before responding the error code, fulResultOk and fulResultString should be prepared accordingly. Preconditions for file upload are: - fulState = idle (default at Agent startup) - fulResultOk = false (default at Agent startup) - fulDestFolder (V1.5.0.0 extension), fulFilename, fulMD5, fulUploadURL and fulResultString are empty (defaults at Agent startup) Workflow file upload: - Manager sets fulState = preparation - Manager gets fulSegmentationSupported If segmentation is supported, the Manager performs all neccessary internal actions to prepare file segmentation. This step is optional. If more than one file should be uploaded, the Manager typically checks fulSegmentationSupported only once. - Manager sets fulDestFolder (V1.5.0.0 extension) This step is optional. If not set it is up to the Agent where to store the file. - Manager sets fulFilename Upon this, the Agent prepares the upload URL in fulUploadURL (before responding the set fulFilename request) - Manager gets fulUploadURL - Manager sets fulMD5 This step is optional. The Manager may want to upload a file without MD5 checksum test (e.g. MD5 checksum unknown). - Manager sets fulState = inProgress Manager performs the actual HTTP file transfer of the file resp. all segments of the file _n_of_m. using fulUploadURL together with the HTTP POST command. If fulFilename is part of fulUploadURL and file segmentation is used, the Manager has to insert the segment numbering (_n_of_m) into fulUploadURL accordingly. In case of segmented file upload the Agent shall autonomously reassemble the segments to the entire file after last segment was received. - Manager sets fulState = md5check Agent performs the MD5 check (optional, if fulMD5 is not empty), sets fulResultOk and fulResultString accordingly and finally Agent sets fulState = md5checkDone - Manager gets fulState in a loop until fulState = md5checkDone - Manager gets fulResultOk and fulResultString Manager gives corresponding user feedback. - Manager sets fulState = idle Upon this, the Agent resets fulResultOk to false and fulFilename, fulMD5, fulUploadURL and fulResultString to empty string.

File upload state. idle: State idle indicates that no file upload is active. Initial and final state. State transition back to idle is always initiated by the SNMP Manager and has to be possible out of any state (including idle). Upon this, the Agent resets fulResultOk to false and all the other objects to the default values listed in the file upload preconditions above. preparation: File upload preparation state, the SNMP Manager provides name and MD5 hash of the file to be uploaded. The SNMP Agent provides the upload URL. State transition to preparation is always initiated by the SNMP Manager. inProgress: State where the actual HTTP file upload takes place. State transition to inProgress is always initiated by the SNMP Manager. md5check: State after the actual HTTP file upload is finished, where the SNMP Agent verifies the upload result by a MD5 checksum test. State transition to md5check is always initiated by the SNMP Manager. md5checkDone: Upload verification is finished, SNMP Agent provides the result to the SNMP Manager (fulResultOk and fulResultString prepared accordingly by the SNMP Agent). State transition to md5checkDone is always initiated by the SNMP Agent. Enumeration: 'preparation': 2, 'md5checkDone': 5, 'idle': 1, 'md5check': 4, 'inProgress': 3.

Indicates whether the Agent supports segmented file upload or not.

Name of file to upload. Set only allowed if fulState = preparation.

128 bit MD5 hash of file to upload represented as a sequence of 32 hexadecimal lowercase characters. Set only allowed if fulState = preparation.

URL for file upload to be used by the Manager together with the HTTP POST command.

File upload result, indicates whether file upload was successful or not. Value only valid if fulState = md5checkDone or any state transition responded an error code.

Detailed description of file upload result. Syntax: 'E'(rror)|'W'(arning)|'I'(nfo)+': ' or empty string. Possible result strings (examples): - 'I: File upload successfully finished' - 'W: File upload successfully finished but MD5 checksum not tested' possible if fulMD5 is empty (optional step in workflow) when fulState = md5check - 'E: File not found' - 'E: MD5 checksum error' Value only valid if fulState = md5checkDone or any state transition responded an error code.

V1.5.0.0 extension: Destination folder of file to upload. If the folder does not yet exist, the Agent has to create it during the SET request. Path separator character is the slash '/'. This may be an absolute (leading slash) or relative path (no leading slash) to the HTTP server file transfer root folder at Agent side. It has to be considered that there may be or may not be a trailing slash during GET or SET requests. Set only allowed if fulState = preparation.

Objects to control Agent software update, activation or removal. If the Agent doesn't support software update/activation/removal at all, always 'no such object' has to be returned to any request within this section. General: - Any state transition not shown in the state diagram (except state transcision to idle - see idle description) is not allowed and should respond an SNMP error code. Before responding the error code, fulStateResultOk and fulStateResultString should be prepared accordingly. - swActivePackageVersion and swActivePackagePatchLevel show the version and patch level of the actual active SW package at the Agent. - swPackagesTable lists always all SW packages that are available at the Agent. Note: Depending on the Agent implementation swPackagesTable may list one (NodeA), two (NodeAM) or several (ION) available packages. Preconditions for SW update (all workflows) are: - swState = idle (default at Agent startup) - swStateResultOk and swActivationForced = false (default at Agent startup) - swPackageVersion, swStateResultString and swNeededFilesTable are empty (defaults at Agent startup) - swPackagePatchLevel = 0 (default at Agent startup) Workflow SW update - file transfer: - Manager sets swPackageVersion - Manager sets swPackagePatchLevel - Manager sets swState = versionReq Manager performs file upload of the SW package TOC file - Manager sets swState = prepareVersionRsp Agent analyzes the TOC file, updates swNeededFilesTable accordingly, sets swStateResultOk and swStateResultString accordingly and finally Agent sets swState = versionRsp - Manager gets swState in a loop until swState = versionRsp - Manager gets swStateResultOk and swStateResultString Manager gives corresponding user feedback. - Manager sets swState = fileTransfer Manager sends all necessary files to the Agent using File Upload (commonDeviceFileTransfer.fUpload) - If all files are uploaded, Manager sets swState = fileTransferDone Agent updates swPackagesTable with the actual transferred package swPackageVersion / swPackagePatchLevel before sending the SNMP SET response. - Manager can go on with package activation or cancel (back to idle) Workflow SW update - package activation: - Manager sets swPackageVersion - Manager sets swPackagePatchLevel - Manager sets swActivationForced accordingly (default should be 'false') - Manager sets swState = versionActivation Agent performs the neccessary actions to activate the SW package (package uncompression, database migration if not up to date, distribute SW to sub components,...), provides regular SW activation notifications (swActivationProgress, swState = versionActivation and progress info in swStateResultString), sets swStateResultOk and swStateResultString accordingly and finally Agent sets swState = versionActivationOrRemovalDone and sends final SW activation notification (swState = versionActivationOrRemovalDone) - Manager processes received SW activation notifications and gives corresponding user feedback - Manager waits for final SW activation notification and (optional, only with AlwaysOn connection) may get the swState in a loop until swState = versionActivationOrRemovalDone In case of timeout waiting for the final SW activation notification (which may get lost if not send as inform) the Manager finally gets swState, swStateResultOk and swStateResultString - Manager gives corresponding final user feedback. - Note: Depending on the Agent implementation package activation may force an Agent restart / reboot. Nevertheless the Agent should provide the final SW activation notification during startup. If the Agent is not able to do this (see also alarmTrapCounter description), the agentUpAndRunningEvent indicates the end of the package activation. If in this case within the agentUpAndRunningEvent the reported swActivePackageVersion is equal to the requested swPackageVersion and the reported swActivePackagePatchLevel is equal to the requested swPackagePatchLevel the package activation was successful, otherwise not. The Manager has to consider this issue. Workflow SW update - package removal: - Manager sets swPackageVersion - Manager sets swPackagePatchLevel - Manager sets swState = versionRemoval Agent performs the neccessary actions to remove the SW package, removes corresponding swPackageVersion / swPackagePatchLevel entry from swPackagesTable, sets swStateResultOk and swStateResultString accordingly and finally Agent sets swState = versionActivationOrRemovalDone - Manager gets swState in a loop until swState = versionActivationOrRemovalDone - Manager gets swStateResultOk and swStateResultString Manager gives corresponding user feedback. - Note: Depending on the Agent implementation package removal may not be supported. In this case the Agent should respond an appropriate error like during an invalid state transicion (see General above). Workflow cancel SW update: - Manager sets swState = idle Upon this, the Agent resets swStateResultOk to false and all the other objects to the default values listed in the SW update preconditions above. V1.5.3.0 workflow extensions - immediate file activation after upload: Manager detects swNeededFilesImmediateActivationRequired=true during fileTransfer after successful upload of a file. In this case: - Manager stops continuing fileTransfer of the remaining files by setting swState = fileTransferDone and continues with SW package activation immediately. - Manager waits for file activation synchronization notification identified by swNeededFilesImmediateActivationSync. - Agent performs corresponding file activation actions on SW package activation request and sends corresponding file activation synchronization notification when finished (reboot may take place). - Manager immediately starts SW update file transfer newly for the remaining files to upload. In this case the Agent might not request previously uploaded and already activated files again, otherwise there will be an endless upload/activation loop. If there are no remaining files to upload: - Manager verifies the overall SW package activation result. Note: Relevant for the overall SW package activation result is just the SW package version / result information sent with the file activation finished synchronization notification for the last file within swNeededFilesTable. For all other intermediate file activations the SW package version information may be not available or empty resp. the result may be false. In case the last file within swNeededFilesTable does not need immediate activation, swFinalActivationNotification is relevant for the overall SW package activation result. If the swFinalActivationNotification object is not available, the Manager has to assume the agentUpAndRunningEvent.

Version of the actual active SW package at the Agent. Typically this version is equal to basicAgentVersion but e.g. in distributed systems it may differ.

Patch level of the actual active SW package at the Agent.

This table lists all SW packages that are available at the Agent.

Description.

Table index.

Version of available SW package.

Patch level of available SW package.

SW update / activation / removal state. idle: State idle indicates that no SW update / activation / removal is active. Initial state. State transition back to idle is always initiated by the SNMP Manager and has to be possible out of any state (including idle). Upon this, the Agent resets swStateResultOk to false and all the other objects to the default values listed in the SW update preconditions above. versionReq: SW update version request state, the SNMP Manager provides details of new SW package (file upload of TOC file) to the SNMP Agent. State transition to versionReq is always initiated by the SNMP Manager. prepareVersionRsp: During prepareVersionRsp state the Agent analyzes the TOC file. The Agent prepares the information which files are needed to be uploaded for the new SW package and which SW packages are already available at the Agent. State transition to prepareVersionRsp is always initiated by the SNMP Manager. versionRsp: In state versionRsp the Agent provides the data prepared during prepareVersionRsp and the data is ready to be read by the Manager. State transition to versionRsp is always initiated by the SNMP Agent. fileTransfer: State where the actual HTTP file upload of all the needed files of the new SW package takes place. State transition to fileTransfer is always initiated by the SNMP Manager. fileTransferDone: File transter is finished, new SW package is available at the Agent and is ready for activation. State transition to fileTransterDone is always initiated by the SNMP Manager. versionActivation: During versionActivation the Agent performs all necessary activities to activate the new SW package version. If during version activation the Agent has to reboot, the state has to be preserved. State transition to versionActivation is always initiated by the SNMP Manager. versionActivationOrRemovalDone: SW package activation or removal is finished. Final state. State transition to versionActivationOrRemovalDone is always initiated by the SNMP Agent. versionRemoval: State to initiate the removal of a SW package. The SNMP Manager provides SW package version to the SNMP Agent. State transition to versionRemoval is always initiated by the SNMP Manager. Enumeration: 'versionReq': 2, 'fileTransfer': 5, 'idle': 1, 'versionRsp': 4, 'versionRemoval': 9, 'versionActivationOrRemovalDone': 8, 'fileTransferDone': 6, 'prepareVersionRsp': 3, 'versionActivation': 7.

Version of new SW package to be updated / activated / removed.

Patch level of new SW package to be updated / activated / removed.

SW package activation 'force' option.

Actual state result, indicates whether transition to actual state was successful or not. Value only valid if swState = versionRsp or versionActivationOrRemovalDone or any state transition responded an error code.

Detailed description of actual state result. Syntax: 'E'(rror)|'W'(arning)|'I'(nfo)+': ' or empty string. Possible result strings (examples): - 'I: SW package successfully uploaded' - 'I: SW package successfully activated' - 'E: Timeout during file upload' - 'E: SW package activation error' - 'E: SW package not available for activation' Value only valid if swState = versionRsp or versionActivationOrRemovalDone or any state transition responded an error code.

This table lists all files of the new SW package that are not yet available at the Agent. V1.5.3.0 extension: - immediate file activation after upload introduced. - in case the Agent requires a specific file upload sequence during swState fileTransfer, this table has to be filled accordingly by the Agent and the Manager has to upload the files accordingly: Sequence order ascending according table index.

Description.

Table index.

Name of a needed file which is part of the new SW package.

Corresponding folder for swNeededFilesFilename. Path separator character is the slash '/'. This is a relative path (no leading slash) within the new SW package. The Manager has to consider that there may be or may not be a trailing slash.

This object identifies whether the file needs immediate activation after upload or not. If this object is not available, the Manager has to assume false.

In case swNeededFilesImmediateActivationRequired is true, this object identifies the file activation finished synchronization notification, sent out by the Agent when all steps of the file activation process are done (Agent reboot may be necessary). Possible values are null or object not available (in case swNeededFilesImmediateActivationRequired is false or not available) resp. either the agentUpAndRunningEvent or swActivationProgress (swState=versionActivationOrRemovalDone) notification, because just this two notifications contain corresponding SW package version information the Manager can use to verify the activation result. Note: Relevant for the overall SW package activation result is just the SW package version / result information sent with the file activation finished synchronization notification for the last file within swNeededFilesTable. For all other intermediate file activations the SW package version information may be not available or empty resp. the result may be false. In case the last file within swNeededFilesTable does not need immediate activation, swFinalActivationNotification is relevant for the overall SW package activation result.

This object identifies the final SW package activation finished notification, sent out by the Agent at the end of a SW package activation when all steps of the activation process are done. Possible values are either the agentUpAndRunningEvent or swActivationProgress (swState=versionActivationOrRemovalDone) notification, because just this two notifications contain corresponding SW package version information the Manager can use to verify the activation result. If this object is not available, the Manager has to assume the agentUpAndRunningEvent.

This notification is sent to provide SW package activation progress information to the Manager. Progress information strings during activation come with swState = versionActivation and final notification when activation is finished comes with swState = versionActivationOrRemovalDone. swStateResultOk and swStateResultString indicate the final result.

Placeholder for all Node products.

Placeholder for all Brite-Cell products.

Placeholder for all AMR products.

Placeholder for all miniRepeater products

Placeholder for all ION products.

ION-M section.

ION-B section.

ION-U section.