system compatibility test plan for aisg standard no. …/file/... · · 2011-02-11system...

Antenna Interface Standards Group System Compatibility Test Plan 27 February 2004

University of Sheffield Issue 1, February 2004 of 61

System Compatibility Test Plan for AISG Standard No. AISG1: Issue 1.0

Revision History

DATE ISSUE NOTES 2003.12.10 COMP-1 Document First release, based upon AISG1

1.0, released on 29 October 2003

2004.02.27 COMP-2 Corrected X test procedures,

Added Y test procedures

© Copyright University of Sheffield 2004



TABLE OF CONTENTS

1. FOREWORD 4

2. SCOPE 5

3. REFERENCES 6

4. ABBREVIATIONS 7

5. TERMINOLOGY AND DEFINITIONS 8

6. LAYER 1 COMPLIANCE TESTS 10

6.1 General objective 10

6.2 Default Data Rate and Data Format 10 6.2.1 Primary station compliance test 10 6.2.2 Secondary station compliance test 11

6.3 Resumption of operation after interruption of supply 11 6.3.1 RET Type 1 Power loss/restore during nominal communication 11 6.3.2 RET Type 1 Power loss/restore during tilt change operation 12 6.3.3 RET Type 1 Power loss/restore during calibration operation 13 6.3.4 RET Type 3 Power loss/restore during nominal communication 13 6.3.5 RET Type 3 Power loss/restore during tilt change operation 14 6.3.6 RET Type 3 Power loss/restore during calibration operation 15 6.3.7 TMA Type 2 Power loss/restore during nominal communication 15 6.3.8 TMA Type 2 Power loss/restore during Gain or Mode change operation 15



7.2 Address Assignment 15 7.2.1 Primary station compliance test 15 7.2.2 Secondary station compliance test 15 7.2.3 Address reset to 0x00: Device logical removal from network. 15

7.3 Address Assignment with errors over the transmission 15 7.3.1 Primary station: Incorrect frame type response received 15 7.3.2 Primary station: Incorrect FCS in response frame 15 7.3.3 Primary station: No response received 15 7.3.4 Primary station: Partial response received 15 7.3.5 Secondary station: Unmatched Device Unique ID 15 7.3.6 Secondary station: Incorrect FCS in command frame. 15 7.3.7 Secondary station: No end flag received for the address assignment. 15

7.4 Device Scan 15 7.4.1 Secondary station Device Scan response format 15 7.4.2 Secondary station Device Scan with unmatched information 15 7.4.3 Secondary station Device Scan with incorrect FCS 15 7.4.4 Secondary station Device Scan without end flag 15 7.4.5 Primary Station: Correct Device scan response received from unknown device 15 7.4.6 Primary Station: Incorrect Device scan response received from unknown device 15 7.4.7 Primary Station: Device scan response from a known device with updated information 15 7.4.8 Primary Station: Device scan response from two devices with the same logical address 15 7.4.9 System test: Device Scan with multiple devices on the bus. 15



7.5 Layer 2 Parameter setting. 15 7.5.1 Compatible settings sent through command 15 7.5.2 Incompatible settings sent through command 15 7.5.3 System behaviour: Secondary does not support parameter setting command. 15

7.6 Logical connection management. 15 7.6.1 Connection Establishment 15 7.6.2 Disconnected mode behaviour 15 7.6.3 Disconnect command 15 7.6.4 Polling mechanism interrupted 15 7.6.5 Primary station: RNR frame reception. 15 7.6.6 System test: I-frame sequence number error. 15

7.7 Frame error rate. 15



8.2 Global Mandatory Commands 15 8.2.1 Get Device type: Known device type 15 8.2.2 Get Device type: Unknown device type 15 8.2.3 Get Device type: command failure 15 8.2.4 Device Reset: No other command is currently executed. 15 8.2.5 Device Reset: During command execution. 15 8.2.6 Get Error Status: Normal and Abnormal response. 15 8.2.7 Get Hardware & Software information: Normal and abnormal response. 15 8.2.8 Clear Alarms: Normal and abnormal response. 15 8.2.9 Enable/Disable command: Normal and abnormal response. 15 8.2.10 Self-Test: Normal and Abnormal response. 15 8.2.11 Device Read Memory: Normal and Abnormal response. 15 8.2.12 Device Write Memory: Normal and Abnormal response. 15 8.2.13 Get Supported Bit Rates: Normal and abnormal response. 15 8.2.14 Set Device Data: Normal and abnormal responses. 15 8.2.15 Get Device Data: Normal and abnormal responses. 15 8.2.16 Alarm reporting mechanism. 15

8.3 Global Optional Commands 15 8.3.1 Software download: Download start command. 15 8.3.2 Software download: Store Data Start and Store Data Block Segment. 15 8.3.3 Software download: Download ending procedure. 15 8.3.4 Bit rate change procedure. 15

8.4 RET Device specific commands 15 8.4.1 RET Set Optional Data: Max/Min tilt. 15 8.4.2 RET Calibration: Normal and abnormal responses. 15 8.4.3 RET Send Configuration Data: Normal and abnormal responses. 15 8.4.4 RET Set Tilt: Normal and abnormal responses. 15 8.4.5 RET Get Tilt: Normal and abnormal responses. 15 8.4.6 RET Actuator tilt modified physically. 15

8.5 TMA Device specific commands 15 8.5.1 TMA Set Optional Data: Max/Min gain. 15 8.5.2 TMA set mode: normal and abnormal response. 15 8.5.3 TMA Set Gain: Normal and abnormal responses. 15 8.5.4 TMA Get Gain: Normal and abnormal responses. 15



1. FOREWORD

The AISG1 standard has been produced by the Antenna Interface Standards Group to facilitate the introduction of antenna line products with remote control and monitoring facilities.

The purpose of the standard is to ensure basic interoperability of antennas and control infrastructure.

At the date of publication of this document, the following companies were members of the Antenna Interface Standards Group: Ace Technology Corp Jaybeam Ltd ADC, Inc Kathrein KG Alan Dick & Co Ltd K&L Microwave Inc Andrew Corporation KMW Ltd Argus Technologies (Australia) Pty Ltd LGP Allgon AB Avitec AB Lucent Technologies Böke & Walterfang Ltd MAT Equipement SA Celletra, Inc Mitec Inc Cellmax Technologies O2 (UK) Ltd CSA Ltd PowerWave Technologies, Inc. DAPA Systèmes SA Proximus Decibel Products Inc Quintel Ltd Elektrobit Ltd. Racal Antennas Ltd EMS Technologies, Inc REMEC Inc ETSA (Européenne de Télécommunications) RFS Inc Eyecom Technologies RYMSA SA Eyecom NZ Ltd. Siemens AG Filtronic Ltd Sigma Wireless Technologies Ltd Forem spa T-Mobile International Fractus SA TIM Gamma Nu Inc University of Sheffield (UK) Hitachi Cable Co Ltd VIAG Interkom GmbH Huber + Suhner Ltd Vodafone Group Huber + Suhner AG Voxaura Technologies Inc Jacquelot Technologies SA Xi’an Haitian Antenna Technologies Co.

Ltd .



2. SCOPE

This document defines a test plan that provides means to verify compatibility of equipment to the AISG1 standard. It focuses on compatibility on Layer 2 and Layer 7 of the model defined by the standard. Compliance at Layer 1 is considered in this test plan only in the terms it affects functionality of upper layers. Factors such as connector types, power supply, current consumption and over-current protection are beyond the scope of this test plan. Issues concerning physical problems over the transmission line are considered in terms of their impact to the logical channel and the interaction between devices in the communication system. The electrical characteristics of the transmission line are considered compatible to the standard and therefore the physical layer will be treated in this document as a black-box providing functionality. The compatibility testing can be divided into three main subcategories: • Normal behaviour tests – To verify compliance within the normal operating conditions

of the system. • Limit behaviour tests – To verify compliance to the standard under specified but not

ordinary circumstances. • Robustness behaviour tests – To verify an acceptable behaviour of the system under

conditions beyond the normal operating conditions of the system. Tests in this plan are applicable to all devices that claim compatibility to the AISG1 standard. As of release 1.0 of the standard, tests are provided for only 4 types of devices: types 1 and 3 (Remote Electrical Tilt units), type 2 (Tower Mounted Amplifiers) and type 4 (Tower Mounted Boosters). The approach taken to verify the compliance will be mainly black-box testing, where the device (secondary station or primary station) is considered only in terms of its functional behaviour specified in the AISG1 standard, not in terms of its individual technical specification/implementation.



3. REFERENCES

This testing plan is based upon the two documents that define the behaviour of the communication system.

1. AISG1 (Issue 1.0, October 2003): Antenna Interface Standards Group – Control Interface for antenna line devices.

2. ISO/IEC 13239 (2nd Edition, March 2000): Information Technology – Telecommunications and information exchange between systems – High-level data link control (HDLC) procedures.



4. ABBREVIATIONS

Where abbreviations or acronyms are used in this document they have the following meanings: ADR Address ALAP Antenna line application protocol ALD Antenna line device CRC Cyclic redundancy check DISC Disconnect (Frame type) DM Disconnected mode FCS Frame checking sequence FRMR Frame reject (Frame type) HDLC High-level data link control I Information (Frame type) INFO Information (Field name) NRM Normal response mode NRZ-L Non-return-to-zero level OSI Open Systems Interconnection RET Remote electrical tilt unit (Antenna drive unit) RNR Receive not ready (Frame type) RR Receive ready (Frame type) SNRM Set normal response mode (Frame type) TMA Tower-mounted amplifier TMB Tower-mounted booster TTE Tower-top equipment TWA Two-way alternate (Half-duplex) UA Unnumbered acknowledgement (Frame type) UI Unnumbered Information (Frame type) UNC Unbalanced operation normal response mode class XID Exchange ID (Frame type)



5. TERMINOLOGY AND DEFINITIONS

Where the following terms are used in this document, they have the meanings listed below.

Antenna line A group of logical devices associated with one or more antenna

systems, which may include antenna drives, amplifiers and other equipment.

Antenna Line Application Protocol

The application (Level-7) protocol defined in this AISG Specification.

Antenna line device A generic term for an addressable physical device such as an antenna drive or amplifier

ASCII character A character forming part of the International Reference Version of the 7-bit character set defined in ISO/IEC 646:1991

Black box testing Test design approach that focuses on the functional requirements of the system. Also known as behavioural testing.

Bus address The HDLC address of each device connected to an RS485 bus Calibrate Exercise the antenna drive unit over its entire range of travel to

ensure fault-free operation and synchronise the measured and actual beam tilt of the antenna.

Configuration data A stored table or function defining the relationship between the physical position of the drive and electrical beamtilt.

Device type A 1-byte field identifying the type of a device, for example an antenna drive or amplifier (See Appendix B of AISG1 standard for a list of assigned device types).

Little-endian The order of transmission in which the least-significant bytes of a multi-byte representation of a number are transmitted first.

Return code A response to a command contained in a single hex byte. (See Appendix C of AISG1 standard for a list of assigned return codes.) Most return codes indicate either successful completion of a command or a reason for its failure.

Reset A process by which a processor, flash memory, FPGA or other device is returned to a known state of initialisation. This normally includes initialising ports, clearing the FPGA RAM, and for processors following the reset vector and commencing execution at that address.

Serial number An identifying alphanumeric designation for each product complying with this specification, assigned by the product manufacturer and having a maximum length of 17 bytes. The serial number is stored as ASCII characters. Note that the Serial Number is part of the Unique ID of an AISG1 compliant device.

Tilt (also downtilt, tilt angle, beamtilt) The angle between the direction orthogonal to the antenna axis

and the maximum of its main beam in the elevation plane. A



positive tilt angle means that the antenna beam is directed below the horizontal plane. An antenna has separate values for electrical and mechanical tilt. In the case of an antenna with a RET facility the electrical tilt is variable and is controlled by the interface described in this specification. The mechanical tilt is fixed by the geometry of the installation. In this specification the tilt referred to is always the electrical tilt unless otherwise stated.

Unique ID Unique Identification code for any given device. It is the combination of the vendor code and serial number used to address antenna line devices on one or more complete mobile radio networks. The provision of the vendor code allows each vendor to manage serial numbers independently in accordance with their own established practice within the assigned field. The only constraint is that serial numbers must not be repeated to guarantee uniqueness of the code.

Vendor code A unique ASCII 2-character code assigned by AISG to each vendor manufacturing products conforming to this specification (See Appendix A of AISG1 standard for a list of assigned vendor codes).

White box testing Test design approach that allows the use of knowledge on internal system design and implementation to determine the test data. Also known as structural testing.



6. LAYER 1 COMPLIANCE TESTS

6.1 General objective

This section focuses on the impact of Layer 1 operational conditions on the behaviour of the communication system defined by the AISG1 1.0 standard. The devices to which this set of tests is applied are assumed to be compliant to the standard in terms of electrical characteristics. Whether the system undergoing the tests makes use of the RS485 or coaxial interface is transparent to the compliance evaluation.

6.2 Default Data Rate and Data Format Objective: Verify that the default data rate in the system is set to 9600 BPS and that

the data format is 1 start bit - 8 data bits - 1 stop bit and no parity. Secondary/primary station response on layers 2 and 7 is not the central element under test in this set; hence the procedures and results do not cover them in full detail.

Applies to: All Secondary Devices/All control stations Test type: Normal Elements: Primary control station under test Secondary station (Device type independent) Tools: Primary control station (vendor independent)

Secondary station emulator and AISG1 compliant device

6.2.1 Primary station compliance test

Initial Conditions: • Secondary station emulator configured at 9600 BPS • Secondary station emulator with address 0 • Transmission line between elements set up correctly Procedure: 1. Start the Primary control station that is to be tested for compliance 2. Initialise the necessary information to include the Secondary station emulator in

the devices managed by the Primary station 3. If the Primary station offers means to set up the data rate, make sure that 9600

BPS is selected 4. Start communication by sending an Address Assignment command 5. Terminate application

Expected Results: • If the Primary station offers means to set up the data rate, the pre-selected value

should be 9600 BPS • The address assignment command should be successful and the value sent

must be the one shown in the Secondary station emulator • The emulator understands only data in the AISG1 specified format. The primary

must conform to this data format.



6.2.2 Secondary station compliance test

Initial Conditions: • Transmission line between elements set up correctly • Secondary station connected to the power supply with known address (preferably

address 0). • Vendor independent primary control station ready Procedure: 1. Input the Secondary station data in the Primary station 2. Set the Data Rate to 9600 BPS 3. Start communication by sending an Address Assignment command 4. Terminate application

Expected Results: • The address assignment command should be successful and the value sent

must be the one shown in the Primary station. • The Secondary station should be able to understand this command because it

should be ready to start communication at 9600 BPS by default

6.3 Resumption of operation after interruption of supply Objective: Verify the behaviour of the secondary device in the event of DC supply

black-out/brown-out. The primary station is assumed in this set of tests to be connected to a permanent power supply. Secondary/primary station response on layers 2 and 7 is not the central element under test in this set; hence the procedures and results do not cover them in full detail.

Applies to: All Secondary Devices/All primary stations Test type: Limit Elements: Secondary station (RET type 1 and type 3, TMA/TMAB type 2/4

respectively) Tools: Primary control station (vendor independent)

6.3.1 RET Type 1 Power loss/restore during nominal communication

Initial Conditions: • Secondary station configured and in connected status with the primary control

station. • Secondary station Max/Min tilt set. • Secondary station Current tilt known. • Secondary station optional data set (if supported). Procedure: 1. While the secondary station is connected and responding to polls, disconnect its

power supply. Wait for 10 seconds. 2. Re-connect device’s power supply. 3. Logically re-connect the device. 4. Read the electrical tilt value. 5. Read the optional data. 6. Read the Error Status of the device.



Expected Results: • At power cut: Primary station should signal loss of connection. • At power re-connection: Secondary station should not perform any self test or

calibration routines. • At logical re-connection: the device should respond to the polls normally, no

communication reconfiguration is required. • Device stored data (optional data inclusive) should be preserved. • The tilt value read after re-connection should be equal to the tilt value before

switching the power supply off. • The Error status should not show any operational codes related to the power cut,

in particular, Position Lost or Not Calibrated.

6.3.2 RET Type 1 Power loss/restore during tilt change operation

Initial Conditions: • Secondary station configured and logically connected with the primary control

station. • Secondary station Max/Min tilt set in device. • Secondary station optional data set (if supported). • Current electrical tilt set to the minimum value. Procedure: 1. While the secondary station is connected and responding to polls, send a Set Tilt

command to set the tilt value equal to the Maximum limit. 2. While the tilt operation is executed, disconnect the device power supply and wait

10 seconds. 3. Re-connect device’s power supply 4. Logically re-connect the device. 5. Read the electrical tilt value. 6. Read the optional data. 7. Read the Error status of the device. Expected Results: • At power cut: Primary station should signal loss of connection and stop polls

towards this device. • At power re-connection: Secondary station should not perform any self test or

calibration routines • At logical re-connection: Secondary station should respond to the polls normally,

no communication reconfiguration is required. • Device stored data (optional data inclusive) should be preserved. • The primary may or may not keep the previous tilt value, but it must show whether

the Secondary station has sent the “Position Lost” alarm or not. • The Error Status returned by the device should show the presence of the Position

Lost operational status and no other code related to the power cut.



6.3.3 RET Type 1 Power loss/restore during calibration operation


station. • Secondary station Max/Min tilt set in device. • Secondary station Current electrical tilt set. • Secondary station optional data set (if supported). Procedure: 1. While the secondary station is logically connected, send a RET calibrate

command. 2. While the operation is executed, disconnect the device power supply and wait 10

seconds. 3. Re-connect device’s power supply 4. Logically re-connect the device. 5. Read the electrical tilt value. 6. Read the optional data. 7. Read the Error Status of the device. Expected Results: • At power cut: Primary station should signal loss of connection and stop polls

towards this device. • At power re-connection: Secondary station should not perform any self test or

calibration routines • At logical re-connection: Secondary station should respond to the polls normally,

no communication reconfiguration is required. • Device stored data (optional data inclusive) should be preserved. • The primary may or may not keep the previous tilt value, but it must show whether

the Secondary station has sent the alarms “Not Calibrated” and “Position Lost” or not.

• The Error Status returned by the device should show the presence of the Position Lost and Not Calibrated operational status.

6.3.4 RET Type 3 Power loss/restore during nominal communication


station. • Secondary station Max/Min tilt set. • Secondary station Current tilt known. • Secondary station optional data set (if supported). Procedure: 1. While the device is connected, disconnect its power supply. Wait for 10 seconds. 2. Re-connect device’s power supply. 3. Logically re-connect the device. 4. Read the electrical tilt value. 5. Read the optional data. 6. Read the Error Status of the device.



Expected Results: • At power cut: Primary station should signal loss of connection and stop polls

towards this device. • Device type 3 goes to vendor default operational state. • At power re-connection: Secondary station should recover its previous state after

reconnection. Commands from the primary station might be either replied with RNR frames to indicate that the device will not process any frame or ignored until the previous state is fully recovered.

• At logical re-connection: the secondary device should respond to the polls normally, no communication reconfiguration is required.

• Device stored data (optional data inclusive) should be preserved. • The tilt value read after re-connection should be equal to the tilt value before

switching the power supply off. • The Error status should not show any operational codes related to the power cut,

in particular, Position Lost or Not Calibrated.

6.3.5 RET Type 3 Power loss/restore during tilt change operation


station. • Secondary station Max/Min tilt set in device. • Secondary station optional data set (if supported). • Current electrical tilt set to the minimum value. Procedure: 1. While the secondary station is connected and responding to polls, send a Set Tilt

command to set the tilt value equal to the Maximum limit. 2. While the tilt operation is executed, disconnect the device power supply and wait

10 seconds. 3. Re-connect device’s power supply 4. Send a Connect command to device. 5. Read the electrical tilt value. 6. Read the optional data. 7. Read the Error status of the device. Expected Results: • At power cut: Primary station should signal loss of connection and stop polls

towards this device. • Device type 3 goes to vendor default operational state. • At power re-connection: Secondary station operates in the default state. • At logical re-connection: Secondary station should respond to the polls normally,

no communication reconfiguration is required. • Device stored data (optional data inclusive) should be preserved. • The primary may or may not keep the previous tilt value, but it must show that the

Secondary station has sent the “Position Lost” alarm. • The Error Status returned by the device should show the presence of the Position

Lost operational status and no other code related to the power cut.



6.3.6 RET Type 3 Power loss/restore during calibration operation


station. • Secondary station Max/Min tilt set in device. • Secondary station Current electrical tilt set. • Secondary station optional data set (if supported). Procedure: 1. While the secondary station is connected and responding to polls, send a RET

calibrate command. 2. While the operation is executed, disconnect the device power supply and wait 10

seconds. 3. Re-connect device’s power supply 4. Logically re-connect the device. 5. Read the electrical tilt value. 6. Read the optional data. 7. Read the Error Status of the device. Expected Results: • At power cut: Primary station should signal loss of connection and stop polls

towards this device. • Device type 3 goes to vendor default operational state. • At power re-connection: Secondary station operates in the default state. • At logical re-connection: Secondary station should respond to the polls normally,

no communication reconfiguration is required. • Device stored data (optional data inclusive) should be preserved. • The primary may or may not keep the previous tilt value, but it must show that the

Secondary station has sent the alarms “Not Calibrated” and “Position Lost”. • The Error Status returned by the device should show the presence of the Position

Lost and Not Calibrated operational status.

6.3.7 TMA Type 2 Power loss/restore during nominal communication


station. • Secondary station Max/Min supported gain set. • Secondary station Current gain known (if supported). • Secondary station Mode known (if bypass supported). • Secondary station optional data set (if supported).



Procedure: 1. While the secondary station is connected and responding to polls, disconnect its

power supply. Wait for 10 seconds. 2. Re-connect device’s power supply. 3. Logically re-connect the device. 4. Read the Gain and Mode values. 5. Read the optional data. 6. Read the Error Status of the device. Expected Results: • At power cut: Primary station should signal loss of connection and stop polls

towards this device. • At power re-connection: Secondary station should recover its previous state after

reconnection without performing any self test operations. • At logical re-connection: the secondary device should respond to the polls

normally, no communication reconfiguration is required. • Device stored data (optional data inclusive) should be preserved. • The read values after re-connection should be equal to the values before switching

the power supply off. • The Error status should not show any operational codes related to the power cut,

in particular. No Alarms are raised after the logical connection.

6.3.8 TMA Type 2 Power loss/restore during Gain or Mode change operation*


station. • Secondary station Max/Min gain set in device. • Secondary station Mode set in normal (if bypass is supported). • Secondary station optional data set (if supported). • Current gain set to the minimum value (if adjustable gain is supported). Procedure: 1. While the secondary station is connected and responding to polls, send a

Gain/Mode set to set the gain value to the Maximum limit/mode to bypass. 2. While the change is executed, disconnect the device power supply and wait 10

seconds. 3. Re-connect device’s power supply 4. Logically re-connect the device. 5. Read the gain/mode value. 6. Read the optional data. 7. Read the Error status of the device. Expected Results: • At power cut: Primary station should signal loss of connection with this device. • At power re-connection: Secondary station should resume operation at its last

known state. The set gain value/mode should be kept in non-volatile memory and * If TMA supports variable gain and/or bypass mode, test applicable only if changes require a delayed response.



updated only when the set command is successful or when the performance degrades and the alarms minor/major are generated.

• Commands from the primary station should be replied with RNR frames to indicate that the device will not process any frame or ignored until its previous state is fully recovered.

• At logical re-connection: Secondary station should respond to the polls normally, no communication reconfiguration is required.

• Device stored data (optional data inclusive) should be preserved.





This section focuses on Layer 2 – link management procedures as specified in the AISG1 standard. For compatibility reasons, the tests on this section will focus on the link control within the AISG1 standard framework, in particular focus on the Commands and Responses implemented as the TWA UNC 1, 4, 15.1 as shown in table 7.3 of the standard. It also tests the compliance to the 16-bit FCS implementation with control-octet transparency specified by HDLC. Secondary device configuration (address, parameters) and device scanning mechanisms are part of this layer of the system. The polling mechanism in terms of timing and expected response is tested here, but the details of the embedded messages in the INFO fields (where applicable) and the behaviours associated to them are not within the scope of this section.

7.2 Address Assignment Objective: Verify the HDLC address management, both in primary and secondary

devices. Reserved addresses 0x00 and 0xff are tested within their scope of use as a communication system. Address assignments of 0x00 or 0xff are not valid commands. It is assumed that in all implementations of the primary station these assignments are prevented. The secondary device may or may not implement protection to prevent these address assignments but such protection is not within the scope of these tests.

Applies to: All Secondary Devices/All control stations Test type: Normal Elements: Primary control station under test

Secondary station (Device type independent, operating and connected to power supply)

Tools: Primary control station (vendor independent) Secondary station emulator HDLC Frame Analyser/Viewer

7.2.1 Primary station compliance test

Initial Conditions: • Secondary station emulator configured at 9600 BPS • Secondary station emulator with address 0 Procedure: 1. Start the Primary control station that is to be tested for compliance 2. Initialise the necessary information to include the Secondary station emulator in


BPS is selected 4. Start communication by sending an Address Assignment command, with the

address set to 126 dec (0x7e) 5. After reply of command, repeat the Address Assignment with the address set to

125 dec (0x7d)



Expected Results: • If the Primary station offers means to set up the data rate, the pre-selected value

should be 9600 BPS • An XID frame compliant to 7.4.3.1 is generated. Format Identifier and user defined

parameter set are embedded in the correct format. • The primary transmits the XID frame compliant with [2] in terms of control octet

transparency, which is mandatory for bytes 0x7E (HDLC flag pattern) and 0x7D (HDLC control escape pattern).

• Secondary emulator eliminates the transparency information to restore the original raw XID frame

• Secondary emulator checks the frame integrity through 16-bit FCS and accepts the command if compliant.

• Primary station must accept the response frame: • <0x7e 0x7d 0x5e 0x73 0x8f 0x24 0x7e> for the first address assignment • <0x7e 0x7d 0x5d 0x73 0xe7 0x0e 0x73> for the second.

(UA response with 16-bit FCS and control octet transparency inserted). • No further frames are sent from the secondary device. The primary station can

only then start transmission of HDLC frames different than XID and UI (UI is only acceptable as broadcast SetBitRate command).

7.2.2 Secondary station compliance test

Initial Conditions: • Vendor independent primary station emulator configured at 9600 BPS • Secondary device preferably not initialised. Procedure: 1. Identify the device in the primary station by inputting its Unique ID and, if known, its

type. 2. Start communication by sending an Address Assignment command, with the

address set to 126 dec (0x7e) 3. After reply of command, repeat the Address Assignment with the address set to

125 dec (0x7d) Expected Results: • No traffic should be registered over the link before the primary sends the

command. Secondary station must not send any frames except the replies to the commands (UNC, TWA mode).

• An XID frame compliant to 7.4.3.1 is generated. Format Identifier and user defined parameter set are embedded in the correct format.

• The primary transmits the XID frame compliant with [2] in terms of control octet transparency, which is mandatory for bytes 0x7E (HDLC flag pattern) and 0x7D (HDLC control escape pattern).

• Secondary station must answer with the response frame: • 0x7e 0x7d 0x5e 0x73 0x8f 0x24 0x7e for the first address assignment, • 0x7e 0x7d 0x5d 0x73 0xe7 0x0e 0x73 for the second within the time specified

in section 7.10.2 (UA response with 16-bit FCS and control octet transparency inserted).



• No further frames are sent from the secondary device unless the primary automatically sends other HDLC commands towards this device.

7.2.3 Address reset to 0x00: Device logical removal from network.

Initial Conditions: • Secondary station configured at 9600 BPS. • Secondary station has a known address and is already initialised on the Primary

control station. Procedure: 1. Generate an Address Assignment command with the Unique ID information of a

non-existent device in the network, or if the primary does not allow manual declaration of devices, send to a Device different from the one undergoing this test. The command must carry an assigned address value equal to the address of the secondary device under test.

2. After the address assign has been acknowledged (a device answered) or timed out (command sent to a non-existent device), send an XID frame carrying a Device Scan with the Unique ID of the device under test.

Expected Results: • Secondary station receives the address assignment frame but does not generate

a response. • The primary station reports a time-out of the Address Assignment (in the case of

sending the command to a non-existent device). • The secondary station receives and processes the Device Scan frame and

generates a response carrying the address 0x00.

7.3 Address Assignment with errors over the transmission Objective: Verify limit execution conditions of the address assignment command.

These tests verify that the devices (primary or secondary) hold a stable, known state, after a failure of the command.

Applies to: All Secondary Devices/All control stations Test type: Limit Elements: Primary control station under test



7.3.1 Primary station: Incorrect frame type response received

Initial Conditions: • Secondary station emulator configured at 9600 BPS • Secondary station emulator with address 0x00 Procedure:



1. Start the Primary control station that is to be tested for compliance 2. Initialise the necessary information to include the Secondary station emulator in


BPS is selected 4. Start communication by sending an Address Assignment command, with the

address set to 126 dec (0x7e) 5. Emulator responds with an unexpected frame (i.e. RR frame, any HDLC frame

different from the expected UA response).

Expected Results: • Primary station rejects the response and the address assignment command fails.

7.3.2 Primary station: Incorrect FCS in response frame

Initial Conditions: • Secondary station emulator configured at 9600 BPS Procedure: 1. Start the Primary control station that is to be tested for compliance 2. Initialise the necessary information to include the Secondary station emulator in

the devices managed by the Primary station, data rate is set to 9600 BPS. 3. Start communication by sending an Address Assignment command 4. Emulator sends as a response the following frame 0x7e 0x7d 0x5e 0x73 0x00 0x00 0x7e (FCS does not match payload) Expected Results: • Primary station rejects the response; the address assignment command fails.

7.3.3 Primary station: No response received

Initial Conditions: • A non-existing device is declared in the primary station (or use device emulator to

insert a device in the managed device list, then disconnect the emulator). Procedure: 1. Send an Address Assignment command to the physically disconnected device. Expected Results: • Primary station reports a time-out, the command fails and the primary station

allows the user to continue normal operation.

7.3.4 Primary station: Partial response received

Initial Conditions: • Secondary station emulator configured at 9600 BPS • Secondary station can be configured to generate incomplete HDLC frames

(remove start/end flags). Procedure: 1. Start the Primary control station



2. Initialise the necessary information to include the Secondary station emulator in the devices managed by the Primary station, set the data rate as 9600 BPS

3. Start communication by sending an Address Assignment command with address 126 dec (0x7e).

4. Emulator response is started, but no end flag is sent. 5. Repeat the command, but allow the emulator to answer normally. Expected Results: • The primary transmits the XID frame compliant with [2] in terms of control octet

transparency, which is mandatory for bytes 0x7E (HDLC flag pattern) and 0x7D (HDLC control escape pattern).

• The primary station must report a time-out failure for the command. The received frame should be dropped, since it is not contained between a pair of flags.

• The address assignment fails and the primary can resume normal operation on subsequent frames. (E.g. no alteration of start-end flag reception is observed).

• The second command is sent successfully and its corresponding response is processed correctly.

7.3.5 Secondary station: Unmatched Device Unique ID

Initial Conditions: • Secondary station configured at 9600 BPS. Procedure: 1. Send an Address Assignment command to a non-existent device on the network

or to a different device than the one undergoing the test procedure.

Expected Results: • Secondary station receives the frame but does not generate any activity over the

link.

7.3.6 Secondary station: Incorrect FCS in command frame.

Initial Conditions: • Secondary station configured at 9600 BPS. Procedure: 1. An Address Assignment command carrying the Unique ID information of the

secondary device under test, but with incorrect FCS, is generated and sent through the link.

Expected Results: • Secondary station receives the frame but does not generate a response. • The command must time-out because no device in the network sends a

response.

7.3.7 Secondary station: No end flag received for the address assignment.

Initial Conditions:



• Primary station test tool configurable to omit start/end flags in command frames. • Secondary station configured at 9600 BPS. • Secondary station already configured with a known address. Procedure: 1. Generate an address assignment command frame for the device under test is

generated by the primary, but without the final flag. 2. Wait 5 seconds and send a Device Scan command with the Unique ID information

of the device under test. Expected Results: • The address assignment command should time-out, no device in the network

should answer. • The device scan command must be accepted and a response with the known

address should be sent within a UA frame. • Neither a disruption in start-end flag processing nor a change in the device

address should be produced after dropping an incomplete address assignment frame.

7.4 Device Scan Objective: Verify the correct execution of the device scan and that the state of the

devices in the network is normal after its execution. These tests focus on the command format and the responses from the secondary device. The network scan procedure itself is a tree search based on multiple device scan XID frames.


Secondary station (Device type independent, operating and connected to power supply) Device Scan procedure must be executed at 9600 BPS

Tools: Primary control station (vendor independent) capable of generating device scan frames (either network scan or specific device searches).

Secondary station emulator HDLC Frame Analyser/Viewer

7.4.1 Secondary station Device Scan response format

Initial Conditions: • Secondary device is connected to the network, unknown to the primary station

(E.g. not currently being managed by primary) • Device scanning provided by primary station (either as a network scan or as a

specific device search). Procedure: 1. Generate an XID frame conveying a Device Scan command with the necessary

information to produce a response from the secondary device under test.



Expected Results: • Upon reception of the Device Scan, the device should answer with the correct

frame as specified in [1]. • The declared length in the Group Length control byte from the frame must agree

with the device specification: n+5 if the Device type is not included in the response, n+8 if device type is included in response

• Primary station must show the information coming from the responding device and include it in its managed device list.

7.4.2 Secondary station Device Scan with unmatched information

Initial Conditions: • Secondary device is connected to the network. • Primary station capable of generating multiple device scan frames. • This test verifies the effectiveness of a network scan. Procedure: 1. If provided by the primary station, launch a network scan – inherently, this will

generate device scan frames that may or may not be answered by the devices connected to the network.

2. If no network scan is provided, use any facilities to generate XID device scan frames provided by the software to generate multiple frames some of which are known to be answered back.

Expected results: • Secondary device will not generate any traffic over the link for unmatched scan

frames. • However, it should respond to ALL frames that match its information. That is,

when the sought ID provided by the command and the sought mask match the device’s unique ID length and a match is produced between the sought ID and the result of masking the device’s ID with the information provided by the command.

• Note that more than one secondary devices can reply to the same frame, which might cause a data collision. This is a normal behaviour and it should be managed by the primary station, hence collisions are outside the scope of this particular test.

7.4.3 Secondary station Device Scan with incorrect FCS

Initial Conditions: • Secondary device is connected to the network. • Test primary station capable of generating specific device scan frames. The

primary station response management is not under test. • Test primary station capable of sending corrupt data frames. Procedure: 1. Generate an XID device scan frame that should be answered normally by the

secondary device. 2. Corrupt the FCS from the command frame, then send it over the link



Expected Results: • The corrupt frame generated and sent over the link must not generate any kind of

response.

7.4.4 Secondary station Device Scan without end flag

Initial Conditions: • Secondary device is connected to the network. • Test primary station capable of generating specific device scan frames. The

primary station response management is not under test. • Test primary station capable of sending incomplete data frames. Procedure: 1. Generate an XID frame with the Device Scan command containing information

that will generate a response from the device under test, but do not send an end flag to the command.

2. After some time, generate an XID frame with the Device Scan command containing information that will generate a response from the device under test.

Expected Results: • The first command must not generate any response activity over the link. • The second command should generate a correct response from the secondary. • This proves that the previous frame processing was already dropped and that the

start/end flag detection mechanism was not disrupted on the secondary.

7.4.5 Primary Station: Correct Device scan response received from unknown device

Initial Conditions: • Only one secondary device emulator connected to the network to ensure a

correct, non-clashing response. • Inclusion of Parameter 4 in the response (device type) is an option of the emulator

as a testing tool. • Primary station without any devices declared in its managed device list. Procedure: 1. Set the emulator to include the Device Type in the response frame to device

scans. 2. Launch the network scan procedure from the primary station.

Even though the scanning procedure implementation is not specified, it should finish and produce a result. The execution time is not specified and will vary between different vendors.

3. Modify the parameters of the emulator tool to act as a different device (different id/address) and do not include the device type in the response frame to device scans.

Expected Results: • The first scan finds the first configuration of the emulator. It should appear as a

new device managed by the primary.



• If the primary supports more than one type of device, the available command set corresponds to the device type.

• If the primary does not support the specific command set for the device, it should at least be able to display the type of device and allow execution of global, generic commands.

• After the second scan response, the primary should insert the device in its managed list, but a warning should be generated to indicate that the device type is still unknown and the device can only be handled as a generic AISG device.

• Implicit in both results is the fact that the Primary station must be able to decide its response processing behaviour by analysing the contents of the response, in particular the length of the parameter field.

7.4.6 Primary Station: Incorrect Device scan response received from unknown device

Initial Conditions: • Only one secondary device emulator connected to the network to ensure a non-

clashing response. • Primary station without any devices declared in its managed device list. Procedure: 1. Launch the device scan procedure from the primary station. 2. Emulator is set to respond with an incorrect frame to the first match of a Device

Scan command it detects. This incorrect frame is formed either by corrupting its FCS or by omitting the end flag. Subsequent responses to matching frames should be correct and compliant to the specified format.

Expected Results: • The primary should be able to detect the device. • The implementation of the scan is not specified, however it is assumed that it is

implemented in the form of a search tree. The objective of any search of this type is to find “leafs”, in this case, the unique IDs of a set of devices. The first, incorrect response, must be ignored in terms of its contents, but it means that the primary should scan through the branch because its previous command generated some sort of activity.

7.4.7 Primary Station: Device scan response from a known device with updated information


clashing response. • Primary station with an empty managed device list.



Procedure: 1. Launch the device scan procedure from the primary station. 2. After the scan finishes, modify the address/device type in the emulator and launch

the device scan again. Expected Results: • On the first scan, the device will be inserted in the list. • On the second scan, no new device is inserted in the list, but the changes made

to the device corresponding to this unique ID are detected. • The address should be updated to the detected value. • A change in the device type is a robustness test. It should be changed in the

display of the device description, but it is assumed that in a real device a given Unique ID will be linked with only one device type.

7.4.8 Primary Station: Device scan response from two devices with the same logical address


clashing response. • Primary station with an empty managed device list. Procedure: 1. Launch the device scan procedure from the primary station. 2. After the scan finishes, modify the emulator data to define a new device with a

different unique ID, but with the same logical address as the previous one. Expected Results: • On the first scan, the first device will be inserted in the list. • On the second scan, the second device will be inserted in the list, but the primary

should prevent the user from logically connecting at least one of the devices until a new address is assigned to one of them.

• A protection mechanism should be provided to ensure that no clashes occur over the link, either by the previously mentioned warning or by automatically managing the addresses over the link.

7.4.9 System test: Device Scan with multiple devices on the bus.

Initial Conditions: • Test should be performed once the previous tests have been executed and the

behaviour of the system elements is known (i.e. the procedure finishes and yields a result, the frame formats are correct).

• No frame errors are forced in this test. If they occur, the scan procedure itself should be able to manage them correctly.



• The devices connected to the network can be real or emulated devices, as long as they have different unique Id values.

Procedure: 1. Launch the device scan procedure from the primary station, wait until it finishes. 2. Send Address Assignment commands to the devices found on the network. Expected Results: • The device scan should be able to find all devices in the network. • After the primary reports that the scan is finished, no traffic should be detected on

the network unless a command is explicitly sent. • The address assignment should be successful and only the device that

corresponds to the address assignment values should generate a response. This section of the test is to ensure that the information on the found devices is correct and that the state of the devices on the bus is stable and ready to operate.

• Each device must be inserted only once in the primary station list. • Scanning can be a long process, in particular when the network is populated with

devices carrying a long unique ID.

7.5 Layer 2 Parameter setting. Objective: Verify the execution of the parameter setting commands embedded in the

XID frames as described in section 7.3.1.1 of [1]. This section focuses on the format of the command and on the changes reflected in the layer 2 management. Layer 7 commands are used to verify some of the behaviours at layer 2, but in this set of tests layer 7 details are not of relevance. FRMR frames implementation (if supported) should be tested in this section.

Applies to: All Primary control stations/All secondary devices that specifically support this command.

Test type: Normal Elements: Primary control station under test



7.5.1 Compatible settings sent through command

Initial Conditions: • Secondary station maximum INFO field length and maximum Transmit/Receive

window size are known • Secondary station is managed by the primary station and already has an address

assigned.



Procedure: 1. Send the parameter determination frame to the secondary device with the default

values of window size (1) and a data length of 74 bytes. 2. Upon reception of the acknowledge, logically connect the device 3. Attempt to send a layer 7 command with an unsupported I-frame length.

Expected Results: • The secondary should accept the new parameters, since it is mandatory to

implement support of INFO fields of size 0 to 74 bytes. • The response for the parameter setting should correspond to the desired values

sent in the command. • Primary station should provide a mechanism to prevent the transmission of

frames that do not fit in a frame (section 7.9 of [1]).

7.5.2 Incompatible settings sent through command


window size are known • Secondary station is in the list of managed devices in the primary station • Secondary station already has an address assigned. Procedure: 1. Send the parameter determination frame to the secondary device with values that

exceed the maximum limits supported by the device. Expected Results: • Secondary device generates the correct response with the maximum values it can

support to indicate that it can not use the values sent in the command. • Primary station processes response frame and sets the parameters to the

maximum values contained in the response frame.

7.5.3 System behaviour: Secondary does not support parameter setting command.


window size are known and fixed. • Secondary station does not support Parameter Setting command. • Secondary station is in managed by primary station and already has an address

assigned. Procedure: 1. Send a parameter determination command to the device.

Expected Results: • Since the parameter determination command expires without response, the

primary should use the default parameters instead of the desired values that were sent in the command.



• The layer 2 default parameters are Transmit/Receive window size = 1, maximum INFO field length = 74 bytes.

7.6 Logical connection management. Objective: Verify the behaviour of the system at layer 2 under connected and

disconnected modes of operation. Applies to: All Secondary Devices/All control stations Test type: Normal Elements: Primary control station under test



7.6.1 Connection Establishment

Initial Conditions: • Secondary station configured: Address, parameters and device type known Procedure: 1. Logically connect the secondary device (Primary transmits an SNRM frame). 2. Send layer 7 commands with the poll bit set.

Expected Results: • The secondary device goes into connected state. The primary station manages

the device as connected upon reception of the command acknowledgement. • The related send/receive state variables must be reset. • A connected device should be polled at a regular interval by the primary station, so

there should be activity on the link to indicate so. • Although not specified, a mechanism to verify the connected status of a

device should be executed upon logical connection to a secondary device. Transmitting RR frames with the poll bit set at regular intervals can do this since the secondary by definition must support them. This provides an implementation of the “virtual full-duplex link”, since the device can transmit its alarms spontaneously as long as it remains in the connected status.

• Layer 7 commands should be executed successfully and the Send/Receive state variables on both sides should be updated according to the activity and incremented respecting the modulo 8 sequence numbering system.

7.6.2 Disconnected mode behaviour

Initial Conditions: • Secondary station physically connected to the network • Secondary station unknown/not configured in primary station. Procedure: 1. Configure the secondary station by using the address assignment, device scan

and parameter determination commands.



2. Send a layer 7 command with the poll bit set to the device 3. Send an RR-frame with the poll bit set to the device 4. Send a UI frame to the device.

Expected Results: • The secondary device should process and answer (where necessary) all XID

commands (address assignment, device scan and parameter determination). • Layer 7 commands (which by definition are embedded in I-frames) should

generate DM-frames (HDLC Disconnected Mode frames) as responses from the secondary device. This indicates that the device is in the link, but logically disconnected, hence, upper layers can not process the commands

• RR frames with the poll bit set should also generate a DM-frame as a response. • UI frame is accepted (UI frames are only used for the bit rate settings).

7.6.3 Disconnect command

Initial Conditions: • Secondary station is connected and there is polling activity Procedure: 1. Send a logical disconnection command to the secondary device (DISC frame). 2. Send layer 7 commands with the poll bit set (to force a response from the

secondary).

Expected Results: • Upon reception of the DISC command, the device goes into Disconnected mode

and will respond as in the previous test case. Upon reception of the acknowledgement to the DISC command via an UA-frame, the primary will manage the device as disconnected.

• The virtual full duplex link is stopped. The secondary device must not generate I-frames under any circumstances.

• Subsequent Layer 7 commands generate DM-frames.

7.6.4 Polling mechanism interrupted

Initial Conditions: • Secondary station is connected and there is polling activity Procedure: 1. Physically disconnect the device from the network. 2. Re-connect the device to the network

Expected Results: • The primary reports the loss of connection, since the polling activity receives no

responses. • There are two acceptable behaviours: The primary can choose to manage the

non-responding device as disconnected and hence it will force the user to send a



SNRM command to the secondary, so the buffers are cleared and the state variables reset. Otherwise, it can attempt to resume operation from the last acknowledged frame.

7.6.5 Primary station: RNR frame reception.

Initial Conditions: • Secondary emulator is connected and there is polling activity Procedure: 1. Force a response in the form of an RNR frame from the secondary device. This

response shall occur after an I-frame command.

Expected Results: • Upon reception of RNR frame, the primary receives an acknowledgement for all

the I-frames it sent before the one that caused the RNR. • No more I-frames are sent to the device • Primary station keeps on polling through RR frames in order to get the response

to the last I-frame.

7.6.6 System test: I-frame sequence number error.

Initial Conditions: • Secondary emulator is connected and there is polling activity • Secondary emulator configured to answer layer 7 commands with an intentionally

incorrect sequence numbers. Procedure: 1. Logically connect the secondary device. 2. Send a layer 7 command that forces an incorrect response.

Expected Results: • The primary station should apply the recovery mechanisms provided by [2]. If it is

not possible to recover from the error, a warning should be issued and the device managed as disconnected in order to force a sequence number reset on the next logical connection.

• The basic expected result is to be able to restart communication with the secondary device after resetting the sequence numbering.

7.7 Frame error rate. Objective: This is a test of the robustness of the implementation. It is performed by

monitoring the communication over a long period of time or under heavy traffic conditions.

Applies to: All Secondary Devices/All control stations Test type: Robustness Elements: Primary control station under test


Tools: Primary control station (vendor independent)



Secondary station emulator HDLC Frame Analyser

Procedure: 1. Connect a frame analyser to the transmission line. 2. The frame analyser should keep count of the total number of frames that are

transmitted through the link as well as the total number of frame checksum failures. Expected results: • System should be compliant to specification (max. 1 error every 5000 frames) • The success of this test under laboratory conditions is almost guaranteed and

therefore is not essential for preliminary compliance testing. This robustness test should be performed under conditions similar to field operation, considering installation issues, transmission line lengths, noise levels on the field and so on.

• Error frame counter should be incremented when: a) The FCS of a response is incorrect b) An incomplete frame is dropped (i.e. no end flag). Although a frame without start flag would be an error, it can not be counted because this information should simply be ignored by the receivers at both ends (inter frame activity is always ignored).





This section focuses on the application layer in terms of command/response format and management. Layer 7 provides the tools to control the devices. As specified in [1], layer 7 is a set of commands that can be divided in 4 subsets: global mandatory commands, global optional commands and two device specific command sets (RET and TMA).

Although by definition in the OSI standard Layers should be independent and their functionality transparent to each other, given that this system does not implement a clear link-application interface (e.g. neither a transport nor a network layer is defined), the management of the communication can not be fully transparent. Some of the commands at layer 7 require interaction and specific behaviours of the underlying layer 2 (e.g. Reset).

This document focuses on the existing command set for revision 1.0 of the specification. Vendor Specific commands are not covered by this document, since the standard only describes the format in which they should be embedded, but their behaviour is not of the public domain.

8.2 Global Mandatory Commands

Objective: Verify the behaviour of AISG global mandatory commands at a system level. These commands and their responses should conform to the format specified in section 8.1 and 8.2 of [1]. All commands should be executed within 1 second of their reception, with the exception of Self Test command, which might involve actuators, hence is given a longer time out (recommended: 4 minutes maximum wait time). These commands are independent of the device type and should always be available even if the device type has not yet been confirmed.



Tools: Primary control station (vendor independent) Secondary station emulator

8.2.1 Get Device type: Known device type

Initial Conditions: • Network running at a fixed bit-rate. • Secondary stations/emulators configured (address/transmission parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on, no operational problems are

present in the device. Procedure: 1. Send the command Get Device Type from primary station to a given secondary in

the network. Expected Results:



• Command execution is successful and a response is generated by the secondary and received in the primary station within 1 second.

• The device type in the primary station matches the device type of the addressed secondary station.

• The primary station provides an adequate command set for the device. If device type is not supported, it should be handled as a generic AISG device. It must be possible to use the rest of the global commands.

• The secondary station answers with a known AISG type identification. • No other device should respond to the command

8.2.2 Get Device type: Unknown device type

Initial Conditions: • Network running at a fixed bit-rate. • Secondary stations/emulators configured in layer 2 parameters

(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on, no operational problems are

present in the device. Procedure: 1. Send the command Get Device Type from primary station to a given secondary in

the network. The command should fit in one frame with the poll-bit set. Expected Results: • Command execution is successful and a response is generated by the secondary

and received in the primary station within 1 second. • Primary should report that device type code received does not match any of the

available command sets. • Device is still available for other global operations. • If the primary does not provide a mechanism that blocks the specific device type

command sets, then the secondary should answer accordingly if any of these commands is used: It must send the COMMAND UNKNOWN response code embedded in a Fail response frame.

8.2.3 Get Device type: command failure


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure:



1. Send the command Get Device Type from primary station to a given secondary in the network. The command should fit in one frame with the poll-bit set.

2. An operational problem preventing the execution of the command is raised either during execution or by a previous condition of the device.

Expected Results: • A FAIL response is generated by the secondary within 1 second of the reception of

the command. • The Primary reports that there has been a failure in the execution of the command

and should translate the return codes to messages readable by the operator. • Device should still be able to respond to polls, unless the current operational

status forces a logical disconnection.

8.2.4 Device Reset: No other command is currently executed.



present in the device. Procedure: 1. Send the command Reset from primary station to a given secondary in the

network. Expected Results: • Reset procedure should conform to the execution of an end of operation frame

exchange as described in B.7.1 of [2] (General closing procedure for NRM-TWA). • In general terms:

a) Primary: issues the RESET command with the poll bit set in the I-frame control field.

b) Secondary: receives RESET command, processes it and if format/addressing is correct, captures the reset state, but continues on normal connected operation mode and sends an I-frame response with the final bit set in the control field.

c) Primary: receives the acknowledgement of RESET, generates an RNR frame with the poll bit set to signal end of operation.

d) Secondary: receives the RNR frame, verifies the sequence number and if correct, generates and sends an RR frame to indicate its end of operation, immediately afterwards it executes the software reset.

e) Primary: receives the RR frame from the device, then the primary can handle the device as disconnected.

Special conditions:



• If the RNR frame is not generated by the primary, the secondary should not complete the reset procedure, since it is this frame that indicates the end of operation as specified in Appendix B of [2]

• After reset, the device in the primary is managed as disconnected, but its configuration data is preserved. The state of the device is also disconnected and no data is lost.

8.2.5 Device Reset: During command execution.



present in the device. • Secondary device must support more than one outstanding layer 7 command. Procedure: 1. Send a layer 7 command that is known to produce a extended delay (for example

commands involving actuators). 2. While the device is still processing the other command, send a software reset. Expected Results: • The previous command execution should be stopped, then the device should

respond as specified in the normal, non-concurrent reset procedure.

Special conditions: • If after receiving the layer 7 command the device answers with an RR frame or

another I-frame, it is assumed that it will be able to process another I-frame. If a device answers with RNR, then the reset command can not even be sent until the previous command finishes.

8.2.6 Get Error Status: Normal and Abnormal response.


(address/parameters). • Device managed by the primary station. • Device is connected and polling activity is going on. Procedure: 1. Send the command Get Error Status from primary station to a given secondary in

the network. Expected Results:



• Addressed Secondary processes the command and generates a response within 1 second of receiving the command.

• If no operational errors that prevent the execution of the command are present or none are raised while executing it, then the operation is successful, and an OK response is generated to report the operational status of the device. All current operational conditions are reported within the response.

• If there are errors during the execution of the command, a FAIL response is generated and all the operational return codes that prevented the execution to be successful are reported within the response.

• The primary station displays the return codes as messages understandable by the operator.

8.2.7 Get Hardware & Software information: Normal and abnormal response.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure: 1. Send the command from primary station to a given secondary in the network. Expected Results: • Addressed Secondary processes the command and generates a response within

1 second of receiving the command. • If no operational errors that prevent the execution of the command are present or

none are raised while executing it, then the operation is successful, and an OK response is generated conforming to the format given in [1].

• The OK response frame should not exceed the length of the default data frame. The Primary station should verify the contents of the Product Number (15 bytes), the Serial Number (17 bytes) and the software/hardware versions. These last two fields should be ASCII values, as specified in section 8.4 of [1] for all alphanumeric fields.

• The primary should be able to update and display this information. • If there are errors during the execution of the command, a FAIL response is

generated and all the operational return codes that prevented the execution to be successful are reported within the response.

• The primary station displays the return codes as messages understandable by the operator, and they should represent the causes for Failure of the command.

• In case that a version number (or both) is not present, they should be part of the OK response, with the length byte set to 0. For example, if no hardware version exists, the frame should include the following fields after <OK>: <prodNR_length><ProdNr><SerNo_length><SerNo><0><SWVer_lenght><SWVer>

8.2.8 Clear Alarms: Normal and abnormal response.

Initial Conditions:



• Network running at a fixed bit-rate. • Secondary stations/emulators configured in layer 2 parameters

(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. • Device has reported at least the appearance of an alarm. Procedure A, device is enabled. 1. Send the command from primary station to a given secondary in the network. Expected Results A: • Addressed Secondary processes the command and generates a response within


none are raised while executing it, then the operation is successful, and an OK response is generated conforming to the format given in [1]. The device disables itself automatically.

• The OK response indicates that the device has lost record of its alarm log. The device operational status is a different entity from the alarms, even if they share the same return codes. Clearing alarms should empty the log of status changes, but should not reset the operational status of the device.

• Upon reception of the OK response, the primary may or may not clear its own alarm log for the given device. This behaviour is not specified.


• The primary station displays the return codes as messages understandable by the operator, and they should represent the causes for Failure of the command.

Procedure B, device is disabled. 1. Send the command from primary station to a given secondary in the network. Expected Results B: • Command generates the FAIL response and Device Disabled should be included

in the return code list of the command execution.

8.2.9 Enable/Disable command: Normal and abnormal response.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure A, enabling the device. 1. Read an optional data field supported by the secondary device using the get

device data command.



2. Send multiple instances of the enable command from primary station to a given secondary in the network.

Expected Results A: • Addressed Secondary processes the command and generates a response within

1 second of receiving the command. • After the enabled command is accepted and acknowledged, the primary has write

permission on the secondary device/emulator. Regardless of how many times the enabled command is sent, if the device is already enabled it shall remain enabled.

• On acknowledge of the enable command, the primary should allow write operations towards the secondary device.

• After the command is sent for the first time, if the device was disabled, the operational status should now change to enabled and consequently an alarm reporting the change should be generated and sent through the link.

Procedure B, writing to an enabled device 1. Send a command to modify the same optional data field that was read in step 1 of

procedure A. 2. Read it back 3. Send a command to modify the same field again. Expected Results B: • On step 1, the value will be stored in the device and on step 2 the new value will

be read back without problems • Device should automatically disable itself after execution of the command. Again,

this produces a change in the operational status of the device that should be logged and reported through an alarm.

• On step 3, the command should generate a FAIL response and Device Disabled should be included in the list of return codes that prevented the correct execution of the command.

Procedure C: 1. Send an enable command and upon acknowledge send a disable command. Expected Results C: • The alarm log should include again two entries indicating the appearance and

disappearance of the Device Disabled operational code. • The following commands require the write permission on the device before

execution: • Global commands: Clear Alarms, Self-Test, Write Memory and Get Device

Data. • Optional commands: Download start. This is the only command that

should not signal a device disabled status after being processed. Otherwise, an enable command would be required for Store Data Start, Store Data Block Segment, Download end, hence altering the mechanism defined in appendix E of [1].

• RET Commands: Calibrate, Send Configuration Data, Set Tilt • TMA Commands: Set mode, set gain.



Execution of these commands without a previous Enable command acknowledged shall result in failure with device disabled code in the list of execution return codes of the command.

8.2.10 Self-Test: Normal and Abnormal response.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure A: 1. Enable the device for writing. 2. Send the command Self Test from primary station to a given secondary in the

network. Expected Results A: • Addressed Secondary processes the command and generates a response within

an acceptable time (4 minutes should be the maximum allowed waiting time). The total execution time depends on each device, which implements test routines that are proprietary of each vendor and not part of this specification.

• If no operational errors that prevent the execution of the command are present or none are raised while executing it, then the operation is successful. An OK response is generated to report the operational status of the device (i.e. All the return codes of the problems/operational conditions found during the self test). If no problems are found during the execution of the self test, the response includes only OK and no return codes



Procedure B: 1. Disable the device for writing. 2. Send the command Self Test from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set. Expected Results B: • Addressed Secondary processes the command and generates an immediate Fail

response containing the Device Disabled return code in its list. No test operations are performed by the device.

8.2.11 Device Read Memory: Normal and Abnormal response.

Initial Conditions: • Network running at a fixed bit-rate.



• Secondary stations/emulators configured in layer 2 parameters (address/parameters).

• Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure A: 1. Send the command Read Memory to a given secondary in the network. 2. In this procedure, make sure that the base address and the number of bytes to be

read do not exceed the addressing space of the device. 3. Make sure that the INFO field is large enough to carry the number of bytes to be

read (use Parameter determination if supported). Expected Results A: • Addressed Secondary processes the command and generates a response within


none are raised while executing it, then the operation is successful, and an OK response is generated carrying the desired information.



Procedure B, attempt to read beyond the user-memory space: • In order to perform this test it is necessary to know the amount of memory

addressable in the device. 1. Send the command Read Memory to a given secondary in the network. The

command should fit in one frame with the poll-bit set. 2. In this procedure, make sure that the base address is within the addressing space

of the device, but the total number of bytes to be read results in attempting to read locations outside the memory addressable space.

3. Make sure that the INFO field is large enough to carry the number of bytes to be read (use Parameter determination if supported).

Expected Results B: • Addressed Secondary processes the command and generates a response within

1 second of receiving the command. • The device might respond either by an OK response carrying:

• Only the amount of bytes that were readable, • A wrap around of the data read (e.g. Fill the bytes beyond range with the

first bytes of the addressable space) Or respond with a FAIL response including the return codes that prevent execution of the command for the particular device implementation.

Procedure C: 1. Send the command Read Memory to a given secondary in the network. 2. In this procedure, the base address lays outside the addressing space of the

device.



Expected Results C: • Addressed Secondary processes the command and generates a response within

1 second of receiving the command. • The device might respond either by an OK response carrying a wrap around of the

data read or with a FAIL response including the return codes that prevent execution of the command for the particular device implementation.

8.2.12 Device Write Memory: Normal and Abnormal response.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure A: 1. Enable the secondary device. 2. Send the command Write Memory to a given secondary in the network. The

command should fit in one frame with the poll-bit set. 3. In this procedure, make sure that the base address and the number of bytes to be

written do not exceed the addressing space of the device. 4. Make sure that the INFO field is large enough to carry the number of bytes to be

written (use Parameter determination if supported). Expected Results A: • Addressed Secondary processes the command and generates a response within


none are raised while executing it, then the operation is successful, and an OK response is generated.



Procedure B: 1. Enable the secondary device. 2. Send the command Write Memory to a given secondary in the network. The

command should fit in one frame with the poll-bit set. 3. In this procedure, make sure that the base address is within the addressing space

of the device, but the total number of bytes to be written results in attempting to access locations outside the memory addressable space.

4. Make sure that the INFO field is large enough to carry the number of bytes to be written (use Parameter determination if necessary).

Expected Results B:




• The device might respond either with OK, indicating that the device has partially written the contents of the command to the device memory, or with a FAIL carrying the return codes related to memory access problems (Flash, EEPROM, RAM, depending on the implementation) and possibly a data error.

Procedure C: 1. Enable the device. 2. Send the command Write Memory to a given secondary in the network. The

command should fit in one frame with the poll-bit set. 3. In this procedure, the base address lays outside the addressing space of the

device. Expected Results C: • Addressed Secondary processes the command and generates a response within

1 second of receiving the command. • The device responds with a FAIL carrying the return codes related to memory

access problems that prevent execution of the command for the particular device implementation.

Procedure D: 1. Disable the device. 2. Send the command Write Memory to a given secondary in the network. The

command should fit in one frame with the poll-bit set. 3. The address/size of buffer to be written is not relevant to this test, as long as it fits

within one frame. Expected Results D: • Addressed Secondary processes the command and generates an immediate

FAIL response carrying the return code for Device Disabled. No further processing is performed.

8.2.13 Get Supported Bit Rates: Normal and abnormal response.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure: 1. Send the command Get Bit Rates to a given secondary in the network. The

command should fit in one frame with the poll-bit set.



Expected Results: • Addressed Secondary processes the command and generates a response within


none are raised while executing it, then the operation is successful, and an OK response is generated. This response contains the list of bit rates supported by the device. In all circumstances the value for 9600 BPS must be present in the response.

• If there are errors during the execution of the command, a FAIL response is generated and all the operational return codes that prevented the execution to be successful are reported.

8.2.14 Set Device Data: Normal and abnormal responses.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure A: 1. Enable the secondary device. 2. Send the Set Device Optional data command formed by data fields that are

supported by the secondary device. Expected Results A: • Addressed Secondary processes the command and generates a response within



• If there are errors during the execution of the command, a FAIL response is generated and all the operational return codes that prevented the execution to be successful are reported.

Procedure B: 1. Enable the secondary device. 2. Send the Set Device Optional data command formed by a mixture of data fields

supported and not supported by the secondary device. Expected Results B: • Addressed Secondary processes the command and generates a response within



• The unsupported fields are ignored. Even if a given field is not implemented (e.g. no memory space assigned for it in the secondary device), the field size is known



since it is specified in [1] and the device should in general be able to advance the necessary bytes and continue processing the command. However, if the device is unable to determine the size of the unknown field, it is acceptable that it stops processing the data frame and signals the error with a FAIL response.

• If there are errors during the execution of the command, a FAIL response is generated and all the operational return codes that prevented the execution are reported.

Procedure C: 1. Disable the secondary device. 2. Send the Set Device Optional data command. Expected Results C: • Addressed Secondary processes the command and generates an immediate

FAIL response carrying the return code for Device Disabled. No further processing is performed.

8.2.15 Get Device Data: Normal and abnormal responses.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. Procedure A: 1. Send the Get Device Optional data command formed by data fields that are

supported by the secondary device. Expected Results A: • Addressed Secondary processes the command and generates a response within


none are raised while executing it, then the operation is successful, and an OK response is generated. The Response carries the values requested by the command. Note that no information regarding the size of the requested data fields is inserted in the response. The primary should be able to identify all data fields since they are all specified in [1].

• If there are errors during the execution of the command, a FAIL response is generated and all the operational return codes that prevented the execution are reported.

Procedure B: 1. Send the Get Device Optional data command formed by a mixture of data fields

supported and not supported by the secondary device. Expected Results B:




• If no operational errors that prevent the execution of the command are present or none are raised while executing it, then the operation is successful, and an OK response is generated.

• The unsupported fields are ignored. The rest of the behaviour is the same as Procedure A.

8.2.16 Alarm reporting mechanism.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on. • Secondary device emulator capable of altering its current operational status. Procedure: 1. Send a command known to alter the state of a device (such as enable/disable). 2. Use the emulator and generate several operating errors during normal polling

activity. Expected Results: • A device that changes the enable/disable status should report that change in the

form of an alarm in layer 7. The primary station should be able to process the response to the enable command and on the next poll activity (either by another command or an RR frame) it should be able to process the alarm.

• For step 2, the emulator will generate an alarm every time the status of the operational codes changes, hence on the next poll activity from the primary, an alarm message will be sent.

• The objective of the test is to verify the system’s “virtual full-duplex” channel, in which the secondary device “spontaneously” sends alarms messages and the primary station should be able to report them to the end user.

8.3 Global Optional Commands

Objective: These options are used to implement two special functions on the communication system: Software download and additional bit rate support.



These commands are not particularly linked to a device type, and they are not essential to the communication system. Testing on this section covers the format of the commands, but the focus is on the behaviour of the system during the necessary exchanges to perform the procedures. Appendix E of [1] gives the general layout of the download procedure, from which test cases can derive for normal operation and failures at different points of the process. Section 8.4.15.1 lays out the procedure to perform the bit rate change on the AISG1 compliant network through the use of an Unnumbered Information (UI) frame to issue a broadcast command.

Applies to: All Secondary Devices/All control stations that support Software download/bit rate changes




Secondary device with optional command support.

8.3.1 Software download: Download start command.



present in the device. • Device link parameter determination has been modified to support a larger data

frame to optimise channel utilisation during download. Procedure: 1. Send the Download Start to the secondary device under test. 2. Wait for the response to command. Expected Results: • The secondary device processes the Download Start command. • If the format of the command is correct, the device clears the necessary space in

the memory. The device status should be busy and no other I-frames are processed until it finishes.

• Upon completion successful completion of the tasks, an OK response is generated. If a problem is present or appears during execution of the command, a FAIL response containing the return codes for the conditions that prevented the execution of the command is sent back.

• If the primary receives an OK response, the process may continue, otherwise, the download process is aborted.

• The device write-enabled status is not checked further, as it is assumed that the device is already engaged in the Download process defined by Appendix E of [1].



• A larger time than 1 second is given for the execution of the command, since erase operations on Flash/EEPROM might require more processing time than the usual read accesses.

8.3.2 Software download: Store Data Start and Store Data Block Segment.




frame to optimise channel utilisation during download. • Download start has been acknowledged with an OK response. Procedure: 1. Send the block information in the format provided by [1] for Store Data Start

command and wait for acknowledge 2. Start downloading the program block using the Store Data Block Segment

command. 3. Wait for acknowledge and repeat step 2 for the next block segment until the whole

block is downloaded. Expected Results: • The secondary device processes the command Store Data Start. • If the format of the command is correct, the device sends an OK response

containing the number of the block it is expecting. When a data block is accepted it is assumed that the device will have enough buffering space to write the entire data block.

• If a problem is present or appears during execution of the command, a FAIL response containing the return codes for the conditions that prevented the execution of the command is sent back.

• If the primary receives an OK response, the process may continue, otherwise, the download procedure is restarted on the last block that was downloaded correctly.

• The Store Data Block Segment must carry an optimal payload according to the selected layer 2 configuration (if default values are used, the maximum segment size is 69 bytes).

• By definition in [1], a block can contain only up to 256 segments. Whether a data block uses all the available segments depends on the size of the block and the size of the segment.

• Each Store Data Block Segment command must be acknowledged before 2 minutes, which allows enough processing time to store data in flash. If the store is successful, an OK response is generated containing the number of the segment that was just stored.

• If a Fail response appears containing a return code related to Flash operation status (failure to erase or write), the process is aborted. If the return code relates



to the segment numbering, then the primary should re-start the process from the last acknowledged segment.

• The primary determines when a block has been entirely transmitted by keeping track of the acknowledged segment sequence numbers. When a block is finished, the primary prepares to transmit the next block (if there is one).

8.3.3 Software download: Download ending procedure.




frame to optimise channel utilisation during download. • Last segment of last block downloaded has been acknowledged with an OK

response. Procedure: 1. Send the Download End command to the secondary device. 2. Wait for acknowledge. If positive, send a RESET command. If failure is detected,

report the error and prompt to re-start download. Expected Results: • Upon reception of the command, the secondary station verifies that the program it

received is not corrupted. If successful, the block is installed and a positive response is generated. The checksum mechanism is specific to a vendor. From the point of view of the download process negotiation, the program is complete if all segments and blocks were acknowledged successfully.

• After the positive response is received in the primary, a RESET command is issued and the Secondary device should resume its operation with the downloaded program.

• If there is a checksum failure, it is reported in the return codes of the FAIL response. The primary then knows that the downloaded block was corrupted and then should prompt the user for action.

• The state of the device in case of a Failure at this point is unstable, since no software might be present in the device.

8.3.4 Bit rate change procedure.

Initial Conditions: • Network running at the lowest, default rate of 9600 BPS. • Secondary stations/emulators configured in layer 2 parameters

(address/parameters). • Device included in the managed device list in the primary station. Determination of maximum supported rate: 1. Send the Get Bit Rates command to all devices in the network (one by one).



Expected results: • The primary station should be able to determine the maximum bit rate supported

by the network. • Maximum network speed is limited to the lowest supported data rate found. Basic

implementations must always support 9600 BPS. Primary operation rate change: 1. Send the UI frame to set the bit rate to the maximum possible. No response is

expected from the secondary devices. 2. Primary continues operation as normal; verifying the Framing Error and Bytes

received counters for each of the devices it manages. Expected Results: • After sending the command, the primary operates at the new rate. Each device in

the network that received and understood the command changes its rate and resets its Framing Error and Received Bytes counters.

Secondary operation rate change: If the secondary station did not receive the command, it should still be able to catch up with the new rate by using the procedure defined in [1]. • After a line-dead time out the device switches to its maximum supported rate and

monitors the line using the Framing Error and Received Bytes counters. • If nothing is detected, then the line is assumed to be idle and the device returns to

its last known operating rate. • If valid activity is detected, the device stays on the maximum rate and after 5 error

free frames it fixes the operating rate. • If invalid activity is detected (Framing Error and Received Bytes counters are non-

zero), the device assumes that the link is not idle, but that the rate is not correct, so it falls to the next inferior supported rate and resets the counters.

• If nothing valid is detected and the rate is already the lowest, then the device goes back to its last known rate.

8.4 RET Device specific commands

Objective: The following test scenarios apply only to Remote Electrical Tilt units. Format and expected behaviours under normal conditions are verified. It also applies to a small section of the Set Device Optional data, which manages information related to the tilting range of the device.

Applies to: RET Secondary Devices/All control stations Test type: Normal Elements: Primary control station under test





8.4.1 RET Set Optional Data: Max/Min tilt.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on Procedure A – Maximum >= Minimum tilt value: 1. Enable the RET Device 2. Send the Set Device Data command with the values of the tilt range in the correct

format. Expected Results A: • The command should be accepted, processed and an OK response is generated. • If present prior to the set Device data, the operational status Out of Range should

be cleared, and an alarm disappeared event should be logged and transmitted. • Unless the range is specified through these data fields, operations on RET devices

will fail. • If the values are equal, the only way to avoid the alarm Out of Range is to set the

current electrical tilt to the same value. This is not recommended practice and should be avoided, but in strict terms does not go against the standard.

Procedure B – Minimum > Maximum tilt value: Repeat procedure A, the values of tilt range are in the correct format. Expected Results B: • Secondary device should raise the alarm Out of Range and no tilt operations

should be allowed until the range is corrected.

8.4.2 RET Calibration: Normal and abnormal responses.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on



Procedure A – No operational problems on device, RET data set: 1. Enable the RET Device 2. Send the command RET Calibrate from primary station to a given secondary in

the network. The command should fit in one frame with the poll-bit set. Expected Results A: • Command execution is successful and a response is generated by the secondary

and received in the primary station within 4 minutes. The calibration routine tests the device through its whole tilt range.

• The primary receives the response OK. In case of failure during execution of the calibration routine, the return codes related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected.

• In particular problems related to RET Calibration are RET Not Calibrated and Actuator faults, as well as Out of Range. Position Lost should not be generated by Calibration, since a calibration routine is normally performed to recover the operational status of the device in order to set (or reset) the Electrical Tilt. Not Scaled can not be generated by the Calibrate command. The reason is explained by Procedure B.

Procedure B –Calibrate RET with operational status Not Scaled and/or without Max/Min tilt set: 1. Enable the RET Device 2. Send the command RET Calibrate from primary station to a given secondary in

the network. The command should fit in one frame with the poll-bit set. Expected Results B: • Command fails to execute immediately. If the device is not scaled (no set-up table

linking the RET to the antenna) or no tilt range is provided (in which case the operational status Out of Range should be present), then calibration is impossible and should not be attempted.

Procedure C – Calibrate RET with actuator failure: 1. Enable RET Device 2. Send the Calibrate command from primary station. Expected Results C: • Calibration routine is launched, but the device should be able to detect an actuator

fault (jam or lack of response). The routine should stop and send the FAIL response with the corresponding return codes.

Procedure D – Response takes longer than 4 minutes: 1. Enable RET Device 2. Send the calibrate command from primary station. Expected Results D: • If no response is given within 4 minutes, the Primary station should declare the

command as timed-out. Even if there is a response after these 4 minutes, the Primary station should ignore it, since the device is not compliant to the AISG1 standard.



Procedure E – Device response to other RET commands during calibration: 1. Send a Get Tilt command while device is calibrating Expected Results E: • Sending tilt related commands to the RET unit while it is performing a task that

involves the actuator should not be allowed by the primary station. In any case, if for some reason this occurs, the device should reject them, either by RNR frames at layer 2 indicating that no more I-frames will be processed or by responding with an I-frame FAIL response containing the Busy return code.

8.4.3 RET Send Configuration Data: Normal and abnormal responses.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on Procedure A – No operational problems on device, RET data set: 1. Enable the RET Device 2. Send the command RET Send Configuration Data from primary station to a given

secondary in the network. The command should fit in one frame with the poll-bit set.

Expected Results A: • The command should be processed, the data written in the device and an OK

response should be generated. • The primary will consider the device as configured/reconfigured only upon

reception of the OK response. • In case of failure during execution of the calibration routine, the return codes

related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected. The primary station will consider the device as Not Scaled, since it can not assert the current status of the configuration data stored in the device.

Procedure B – RET Send Configuration data with operational status Not Scaled: 1. Enable the RET Device 3. Send the command RET Send Configuration Data from primary station to a given

secondary in the network. The command should fit in one frame with the poll-bit set.

Expected Results B: • If command is executed successfully, the device replies with OK, the state Not

Scaled is removed and an alarm disappeared is logged and transmitted to the Primary station.



• If the command fails, the return codes contained in the response should indicate the reasons for failure. The status Not Scaled will still be present in the device.

8.4.4 RET Set Tilt: Normal and abnormal responses.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on Procedure A – No operational problems on device, RET data set, Tilt within operating range: 1. Enable the RET Device 2. Send the command RET Set Tilt from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set. Expected Results A: • Command execution is successful and a response is generated by the secondary

and received in the primary station within 2 minutes. • The primary receives the response OK. In case of failure during execution of the

tilt setting routine, the return codes related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected.

• In particular problems related to RET Set Tilt are Actuator faults. A failure on this command will also raise the Position Lost alarm, since the desired value is not reached due to an external mechanical problem.

• The value is not considered as set in the primary until an OK response is received.

Procedure B – No operational problems on device, RET data set, Tilt outside operating range: 1. Enable the RET Device. 2. Send the command RET Set Tilt from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set and the desired value is smaller/greater than the minimum/maximum tilt values.

Expected Results B: • Command execution fails immediately. The previous tilt is preserved (if valid), and

this new tilt is rejected with the return code Out of Range. Procedure C – Set Tilt with operational status Not Scaled and/or without Max/Min tilt set: 1. Enable the RET Device 2. Send the command RET Set Tilt from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set.



Expected Results C: • Command fails to execute immediately. If the device is not scaled (no set-up table

linking the RET to the antenna) or no tilt range is provided (in which case the operational status Out of Range should be present), then tilt setting operations are impossible.

Procedure D – Set Tilt with actuator failure: 1. Enable RET Device 2. Send the Calibrate command from primary station. Expected Results D: • Routine is launched, but the device should be able to detect an actuator fault (jam

or lack of response). The routine should stop and send the FAIL response with the corresponding return codes.

Procedure E – Response takes longer than 2 minutes: 1. Enable RET Device 2. Send the Set Tilt command from primary station. Expected Results E: • If no response is given within 2 minutes, the Primary station should declare the

command as timed-out. Even if there is a response after this time, the Primary station should ignore it, since the device is not compliant to the AISG1 standard.

Procedure F – Device response to other RET commands during set tilting: • Same as procedure E for the RET calibration command.

8.4.5 RET Get Tilt: Normal and abnormal responses.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on Procedure A – No operational problems on device, RET data set, Tilt set within operating range: 1. Enable the RET Device 2. Send the command RET Get Tilt from primary station to a given secondary in the


and received in the primary station within 1 second.



• The primary receives the response OK. In case of failure during execution of the routine, the return codes related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected.

• In particular problems related to RET Get Tilt are Actuator faults. A failure on this command will also raise the Position Lost alarm, since it is impossible to read the current tilt value.

Procedure B – No operational problems on device, RET data set, Tilt outside specified operating range: 1. Enable the RET Device. 2. Send the command RET Get Tilt from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set. Expected Results B: • Command execution is successful if the tilt value can be recovered. However,

since the operational conditions are not normal, the alarm Out of Range is raised to indicate that although a value was read, it is currently outside the specified operative range set in by the max/min tilt values.

Procedure C – Get Tilt with operational status Not Scaled and/or without Max/Min tilt set or Not Calibrated: 1. Enable the RET Device 2. Send the command RET Get Tilt from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set. Expected Results C: • Command fails to execute immediately. If the device is not scaled (no set-up table

linking the RET to the antenna) or no tilt range is provided (in which case the operational status Out of Range should be present), or the device is not calibrated, the readings from the device would not make any real sense.

8.4.6 RET Actuator tilt modified physically.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on

Procedure: This is a robustness test. The objective is to modify the tilt by external action over the device. Expected Results:

• The device should be able to detect that the tilt value is no longer within the acceptable range of the last set tilt. A Position Lost alarm should be raised, logged and reported.



8.5 TMA Device specific commands

Objective: The following test scenarios apply only to Tower Mounted Amplifiers. Format and expected behaviours under normal conditions are verified. It also applies to a small section of the Set Device Optional data, which manages information related to the gain range of the device.

Applies to: TMA Secondary Devices/All control stations. Some TMAs may support variable gain values as well as a bypass mode. However, not all units offer such support, hence the tests should be performed only where applicable.




8.5.1 TMA Set Optional Data: Max/Min gain.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on Procedure A – Maximum >= Minimum gain value: 1. Enable the TMA Device 2. Send the Set Device Data command with the values of the gain range in the

correct format. Expected Results A: • The command should be accepted, processed and an OK response is generated. • If present prior to the set Device data, the operational status Gain Out of Range

should be cleared, and an alarm disappeared event should be logged and transmitted.

• Unless the range is specified through these data fields, operations on TMA devices with variable gain support will fail.

• If the values are equal, the only way to avoid the alarm Gain Out of Range is to set the TMA gain equal to the same value. This is not recommended practice and should be avoided, but in strict terms does not go against the standard.

Procedure B – Minimum > Maximum gain value: Repeat procedure A, the values of gain range are in the correct format. Expected Results B: • Secondary device should raise the alarm Gain Out of Range and no gain setting

operations should be allowed until the range is corrected.



8.5.2 TMA set mode: normal and abnormal response.


(address/parameters). • Device included in the managed device list in the primary station. • Device is connected and polling activity is going on Procedure A – No operational problems on device, TMA data set, device in normal mode: 1. Enable the TMA Device 2. Send the command Set TMA Mode with the data field indicating a change to

bypass mode. The command should fit in one frame with the poll-bit set. Expected Results A: • Command execution is successful and a response is generated by the secondary

and received in the primary station within 1 second. • The primary receives the response OK. In case of failure during mode switch, the

return codes related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected.

Procedure B – No operational problems on device, TMA data set, device in bypass mode: 1. Enable the TMA Device 2. Send the command Set TMA Mode with the data field indicating a change to

normal mode. The command should fit in one frame with the poll-bit set. Expected Results B: • Command execution is successful and a response is generated by the secondary

and received in the primary station within 1 second. • The primary receives the response OK. In case of failure during mode switch, the

return codes related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected.

Procedure C – Automatic Mode Switch upon Major Alarm: • This is a limit test. The objective is to verify that upon a major failure on the

normal mode of the TMA, the device will automatically switch to bypass mode and report a major alarm to inform the primary that the performance is severely affected.

• If no bypass mode is supported, the alarm should be reported and the device should be deemed as having an unacceptable performance.

8.5.3 TMA Set Gain: Normal and abnormal responses.

Initial Conditions: • Network running at a fixed bit-rate.



• Secondary stations/emulators configured in layer 2 parameters (address/parameters).

• Device included in the managed device list in the primary station. • Device is connected and polling activity is going on Procedure A – No operational problems on device, TMA data set, Gain within operating range: 1. Enable TMA Device. 2. Send the command TMA Set Gain from primary station to a given secondary in the


and received in the primary station within 2 minutes. • The primary receives the response OK. The value is not considered as set in the

primary until an OK response is received. • In case of failure during execution of the gain setting routine, the return codes

related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected.

Procedure B – No operational problems on device, TMA data set, Gain outside operating range: 1. Enable the TMA Device. 2. Send the command TMA set gain from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set and the desired value is smaller/greater than the minimum/maximum gain values.

Expected Results B: • Command execution fails immediately. The previous gain is preserved (if valid),

and this new value is rejected with the return code Gain Out of Range. Procedure C – Set Gain without Max/Min gain set: 1. Enable the TMA Device 2. Send the command TMA Set Gain from primary station to a given secondary in the

network. The command should fit in one frame with the poll-bit set. Expected Results C: • Command fails to execute immediately. If the no range is provided (in which case

the operational status Gain Out of Range should be present), then gain setting operations are impossible.

8.5.4 TMA Get Gain: Normal and abnormal responses.


(address/parameters). • Device included in the managed device list in the primary station.



• Device is connected and polling activity is going on Procedure A – No operational problems on device, TMA data set, 1. Enable the TMA Device 2. Send the command TMA Get Gain from primary station to a given secondary in

the network. The command should fit in one frame with the poll-bit set. Expected Results A: • Command execution is successful and a response is generated by the secondary

and received in the primary station within 1 second. • The primary receives the response OK. In case of failure during execution of the

routine, the return codes related to the failure should be reported in the FAIL response. If necessary, the operational status of the device needs to be updated and a new alarm logged for every problem detected.

Procedure B – No operational problems on device, TMA data set, Gain outside specified operating range: 1. Enable the TMA Device. 2. Send the command TMA Get Gain from primary station to a given secondary in

the network. The command should fit in one frame with the poll-bit set. Expected Results B: • Command execution is successful if the gain value can be recovered. However,

since the operational conditions are not normal, the alarm Gain Out of Range is raised to indicate that although a value was read, it is currently outside the specified operative range set in by the max/min gain values.

system compatibility test plan for aisg standard no. …/file/... · · 2011-02-11system...

Documents