Context - G3-PLC Alliance

Transcription

G3 PLC – WS3 Interoperability
MAC Layer interoperability
Test process and test suite for new comers v0.2
Context
This document describes the test process and the suite of the interoperability test that will be
performed in the WS3 for the new comers on the MAC layer of the G3-PLC protocol for the
CENELEC-A band, the FCC band and the ARIB band.
Those tests will be divided in several groups:
(GR1) Encoding/decoding of MAC frames
(GR2) Encoding/decoding of MAC frames with Security enabled
(GR3) Tests of the behaviour of the MAC layer when receiving various MAC frames
(GR4) Test of the timing related mechanisms
The tests names are structured as “MAC_GRx_yyy_TEST_TEMPLATE” where x is the number of
the group, yyy is a 3 digit number identifying the test (tests are numbered sequentially) and
TEST_TEMPLATE is a reminder of this test goal.
Page 1/46
Table of content
Context.................................................................................................................................................1
1 Test procedure...................................................................................................................................3
1.1 Access needed to perform the tests...........................................................................................3
1.2 Test definition...........................................................................................................................3
1.3 Test vectors evaluation..............................................................................................................4
1.4 Plug-Fest...................................................................................................................................5
2 (GR1) Encoding/decoding of the MAC frames................................................................................7
2.1 MAC_GR1_001_Data_frame_encoding_1..............................................................................7
2.4 MAC_GR1_004_Command_frame_beacon_request_encoding__test_vector_only_(optional)
.......................................................................................................................................................10
2.5 MAC_GR1_005_Command_frame_tone-map_response_encoding......................................11
2.6 MAC_GR1_006A_Segmentation_2_segments......................................................................12
2.7 MAC_GR1_006B_Segmentation_2_segments......................................................................14
2.8 MAC_GR1_007_Segmentation_3_segments.........................................................................15
3 (GR2) MAC Security.....................................................................................................................17
3.1 MAC_GR2_001_Short_frame_ciphering...............................................................................17
3.2 MAC_GR2_002_Long_frame_ciphering...............................................................................18
3.3 MAC_GR2_003_Invalid_ciphering_dropping.......................................................................19
3.4 MAC_GR2_004_unset_key_dropping...................................................................................21
3.5 MAC_GR2_005_Short_frame_ciphering_2...........................................................................22
4 (GR3) Tests of the behaviour of the MAC layer when receiving various MAC frames................24
4.1 MAC_GR3_001_Acknowledge_mechanism.........................................................................24
4.2 MAC_GR3_002_ PAN_Coordinator_reply_to_Beacon_Request..........................................25
4.3 MAC_GR3_003_Node_reply_to_Beacon_Request...............................................................26
4.4 MAC_GR3_004_Reply_to_Tone-Map_request_in_data_frame............................................27
4.5 MAC_GR3_005_Reply_to_Tone-Map_request_in_command_frame (optional test)...........29
4.6 MAC_GR3_006_Address_filtering_PAN_ID_and_PAN_ID_conflict..................................31
4.7 MAC_GR3_007_Address_filtering_short_address................................................................32
4.8 MAC_GR3_008_Address_filtering_extended_address.........................................................34
4.9 MAC_GR3_009_Address_filtering_broadcast_address........................................................35
4.10 MAC_GR3_0010_Address_filtering_broadcast_PAN_ID...................................................36
4.11 MAC_GR3_011_PAN_ID_conflict (Removed)...................................................................37
4.12 MAC_GR3_012_Neighbour_Table_add_unknown.............................................................37
4.13 MAC_GR3_013_Neighbour_Table_Tone-Map_response...................................................39
5 (GR4) Test of the timing related mechanisms................................................................................40
5.1 MAC_GR4_001_Delay_between_data_frame_and_ACK.....................................................40
5.2 MAC_GR4_002_Delay_between_ACK_and_frame_contention_free_priority....................42
5.3 MAC_GR4_003_Delay_between_ACK_and_frame_high_priority......................................43
5.4 MAC_GR4_004_Delay_between_ACK_and_frame_normal_priority..................................44
Page 2/46
1 Test procedure
The MAC interoperability tests are defined as a list of calls to MAC layer primitives, resulting in
G3 frames that are received and decoded by another implementation. The resulting MAC layer
indications are compared to the expected result.
All tests will be executed during a Plug-Fest.
Tests from groups 1 and 2 will also be executed before the Plug-Fest via a test vectors evaluation, as
a way to speed up the interoperability process and detect problems before the Plug-Fest.
1.1 Access needed to perform the tests
In order to execute the MAC interoperability tests, each implementer must have access to:
– The MAC layer primitives
– The MAC Information Base (IB) with read and write access
– The neighbour table with read and write access.
– The result of the last ToneMap “decision” (read only access, used by tests covering
ToneMap response messages).
Those accesses are needed during both test vector exchange and the Plug-Fest.
1.2 Test definition
The tests are defined by the following elements:
– An initial state, defining for example the content of the neighbour table, the security keys in
place, the MAC address and the PAN_ID of the device, …
– A list of MAC layer primitives calls, with the parameters defined.
– A list of MAC layer indications that are expected as the result of the test.
– A scenario describing the expected sequence of events. This description is only informative,
the test result is only decided by the triggered MAC layer indications.
An example of a test definition could be (informative):
MAC_GR0_001_TEST_EXAMPLE
Description: this test describes an example of encoding test. It is informative and may be incorrect.
Scenario: One small MAC frame is sent by the sender implementation with acknowledge required,
which should result in one PHY frame sent on the line, an acknowledge sent by the receiver
implementation and a MAC frame indication by the receiver implementation.
Initial state:
– Sender:
– Short MAC address = 0x002A, extended MAC address = 0x1122334455667788, PAN_ID =
Page 3/46
0x7A1D
– The neighbour table has one entry for MAC address 0x010C with tone-map-needed = false.
– Receiver:
– Short MAC address = 0x010C, extended MAC address = 0x8877665544332211, PAN_ID =
0x7A1D
– The neighbour table is empty.
List of MAC layer primitives calls:
The sender call the MCPS-DATA.request primitive with:
– SrcAddrMode = short address, DstAddrMode = short address
– DstPANId = 0x7A1D
– DstAddr = 0x010C
– msdu = 112233445566778899AABBCCDDEEFF and msduLength = 15
– msduHandle = 0x00
– TxOptions = acknowledged transmission (other parameters have fixed values)
– SecurityLevel = 0 (KeyIdMode, KeySource and KeyIndex values are ignored)
– QualityOfService = Normal priority
List of expected MAC layer indications:
1) The receiver should receive the following MCPS-DATA.indication:
– SrcAddrMode = short address, DstAddrMode = short address, SrcAddr = 0x002A, DstAddr
= 0x010C
– SrcPANId = DstPANId = 0x7A1D
– msduLinkQuality, DSN and Timestamp values are ignored.
1.3 Test vectors evaluation
Test vectors are only applicable to encoding tests (groups 1 and 2).
The implementer executes the tests by calling MAC layer primitives and collects the resulting
PD-DATA.request calls. In order for the test to correctly proceed, all acknowledge requests are
supposed answered by a positive ACK. The test vector is the resulting list of psdu parameters.
Page 4/46
The test vectors from the implementer are collected by TRIALOG. TRIALOG compares them with
the reference test vectors. TRIALOG provides then the implementer with a synthesis document
gathering the results of the comparison.
MAC primitives
MIB access
MAC Layer
Implementer A
Evaluation by TRIALOG
Test
Vector
PD-DATA.request
The means used to perform the encoding tests and capture the PD-Data.request calls are left to the
implementer (it can be done either on simulator or real hardware).
The test vector file format is defined as one file per test, with one psdu per line, the psdu is
expressed in hexadecimal form.
For example, a test resulting in two PHY frames sent could be (note: this example is informative):
0102030405060708090A0B0C0D0E0F101112131415161718191A
0102030405060708090A0B0C0D0E0F10
1.4 Plug-Fest
During a Plug-Fest, the physical implementations are linked by a cold wire. As the MAC exchanges
will go through the PHY layer, the PHY layer implementations need to be interoperable.
The tests will be done with 1 sending implementation and 1 receiving implementation. An
additional oscilloscope is needed for GR4 tests.
MAC primitives
MIB access
MAC primitives
MIB access
MAC Layer
Implementer A
MAC Layer
Implementer B
PHY Layer
Implementer A
PHY Layer
Implementer B
Power line
Oscilloscope
(Only for GR4 tests)
Page 5/46
One of the implementation shall be a reference implementation (an implementation having already
passed successfully the MAC IOT). Tests between new comers implementation will be also
performed, if at least two new comers participate to the Plug-Fest.
Page 6/46
2 (GR1) Encoding/decoding of the MAC frames
Those tests validate the encoding of a MAC frame, by having one implementer sending a MAC
frame (resulting in one or several PHY frames and acknowledges) and another implementer
receiving and decoding the frame.
Timings are not taken into account for this group of tests.
2.1 MAC_GR1_001_Data_frame_encoding_1
Description: This test covers part 1 of 3 for the encoding of a short MAC data frame, without
security.
The data frame to send is parametrised with msdu length = 15, source & destination using short
address, source PAN_ID different from destination PAN_ID (implying no PAN ID compression), no
ACK requested, no Tone-Map request, Priority = Normal.
Initial state:
– Sender:
0x781D
– macDSN parameter is set to 0x5E.
– The neighbour table have one entry for MAC address 0x010C with:
– Age set to macMaxAgeTime (so no ToneMap is requested).
– IsNeighbour set to macMaxNeighborValidTime.
– Modulation = ROBO mode.
– ToneMap = all sub-carriers used, TxGain = 0, TxCoeff = 0 (for each carrier group)
– Receiver:
0x781D
1) The sender call the MCPS-DATA.request primitive with:
– DstPANId = 0xFFFF
Page 7/46
– TxOptions = unacknowledged transmission (other parameters have fixed values)
– QualityOfService = Normal
= 0x010C
– SrcPANId = 0x781D, DstPANId = 0xFFFF
– DSN = 0x5E
– msduLinkQuality and Timestamp values are ignored.
security.
The data frame to send is parametrised with msdu length = 15, source & destination using extended
address, source PAN_ID equal to destination PAN_ID (implying PAN ID compression), ACK
requested, no Tone-Map request, Priority = high priority.
Initial state:
– Sender:
0x781D
– macDSN parameter is set to 0x6A.
– As an extended destination address is used, the state of the neighbour table has no impact on
the test behaviour.
– Receiver:
0x781D
Page 8/46
– SrcAddrMode = extended address, DstAddrMode = extended address (imply ROBO mode,
no Tone-Map request)
– DstPANId = 0x781D (equal to sender PAN_ID)
– DstAddr = 0x8172635445362718
– QualityOfService = High priority
– SrcAddrMode = extended address, DstAddrMode = extended address, SrcAddr =
0x1122334455667788, DstAddr = 0x8172635445362718
– SrcPANId = 0x781D, DstPANId = 0x781D
– DSN = 0x6A
security.
The data frame to send is parametrised with msdu length = 15, source using extended address,
destination using short address, source PAN_ID equal to destination PAN_ID (implying PAN ID
compression), ACK requested, Tone-Map request (controlled by the initial state of the neighbour
table), Contention control = contention allowed, Priority = Normal.
Initial state:
– Sender:
0x781D
– Age set to 0 (so a ToneMap should be requested).
Page 9/46
– Receiver:
0x781D
– SrcAddrMode = extended address, DstAddrMode = short address
– DstPANId = 0x781D (equal to sender PAN_ID)
– SrcAddrMode = extended address, DstAddrMode = short address, SrcAddr =
0x1122334455667788, DstAddr = 0x010C
– DSN = 0x6A
2.4 MAC_GR1_004_Command_frame_beacon_request_encoding__test
_vector_only_(optional)
Description: This test was meant to cover the encoding of a Beacon Request frame. As no MAC
layer indication is called when receiving a Beacon Request, the test is modified to be executable
Page 10/46
during a test vector exchange (but it can not be run during a Plug-Fest).
The underlying mechanism is also covered by the MAC_GR3_002 and MAC_GR3_003, which can
be run during a Plug-Fest.
Initial state:
– Sender:
– Short MAC address = 0x002A, PAN_ID = 0x781D
– Receiver:
– Short MAC address = 0x010C, PAN_ID = 0x781D
1) The sender call the MLME-SCAN.request primitive with:
– ScanType = 1 (active scan)
– ScanChannels = all 27 bits set to zero.
– ScanDuration = 5 seconds (using the default value defined for adpActiveScanDuration).
– ChannelPage = 0
– SecurityLevel = 0 (KeyIdMode, KeySource and KeyIndex values are ignored).
As a result of this primitive call, a call to PD-DATA.request should be made by the sending
implementation. A test vector is created from this call as defined in §1.3.
The receiving implementation should decode the test vector, and understand it as a MAC Beacon
Request command frame.
2.5 MAC_GR1_005_Command_frame_tone-map_response_encoding
Description: This test covers the encoding of a Tone-Map Response frame. The result of the
decoding of the Tone-Map request will be checked in the neighbour table of the receiver.
As the Tone-Map content is an internal choice of the MAC layer (that also depends on the LQI
provided by the PHY layer), every implementer must have a specific access to the Tone-Map
“decision” made by the MAC layer.
Initial state:
– Sender:
0x781D
Page 11/46
– Age set to 0 (so a ToneMap should be requested).
– Receiver:
0x781D
The sending of a ToneMap Response is not possible using a MAC layer primitive. Thus the
implementer has to generate the sending by its own means.
None
Content of the Neighbour table for the receiver:
– The neighbour table have one entry for MAC address 0x002A with:
– Modulation = ? mode.
– ToneMap = ?, TxGain = ?, TxCoeff = ?
The implementer must provide the content of the “decision” to be checked against the receiver
neighbour table. The values to provide are:
•
TXRES
•
TXGAIN
•
MOD
•
TM
•
LQI
•
TXCOEF for each sub-band
2.6 MAC_GR1_006A_Segmentation_2_segments
Description: This test covers part 1 of 2 of the segmentation mechanisms of MAC layer on the
CENELEC-A band-plan.
The PHY layer is configured to use a DBPSK modulation with no notching and no tone-mapping.
Page 12/46
A MAC data frame with a msdu of 300 bytes is used, which should result in 2 PHY frames.
Initial state:
– Sender:
– macDSN parameter is set to 0x29.
– Modulation = DBPSK mode.
– ToneMap = all sub-carriers used, TxGain = 0, TxCoeff = 0 for each carrier group
– Receiver:
– DstPANId = 0x781D
– msdu = (0xFF)*300 and msduLength = 300
– QualityOfService = Normal Priority
= 0x010C
Page 13/46
– DSN = 0x29
2.7 MAC_GR1_006B_Segmentation_2_segments
Description: This test covers the segmentation mechanisms of MAC layer on the FCC and ARIB
band-plans.
The PHY layer is configured to use a DBPSK modulation with no notching and a tone-map using
only 9 carriers.
Initial state:
– Sender:
– ToneMap = only 3 sub-carriers used :
– For FCC band-plan “111000000000000000000000”b
– For ARIB band-plan “111000000000000000”b
– TxGain = 0, TxCoeff = 0 for each carrier group
– Receiver:
Page 14/46
= 0x010C
– DSN = 0x29
2.8 MAC_GR1_007_Segmentation_3_segments
Description: This test covers part 2 of 2 of the segmentation mechanisms of MAC layer on the
CENELEC-A band-plan.
The PHY layer is configured to use a ROBO modulation with no notching and no tone-mapping.
Initial state:
– Sender:
– Receiver:
Page 15/46
= 0x010C
– DSN = 0x29
Page 16/46
3 (GR2) MAC Security
Those tests validate the encoding of a MAC frame with security enabled, by having one
implementer sending a MAC frame (resulting in one or several PHY frames and acknowledges) and
another implementer receiving and decoding the frame.
3.1 MAC_GR2_001_Short_frame_ciphering
Description: This test covers the ciphering of a short MAC data frame.
A msdu of 45 bytes is provided, along with the GMK key and frame counter to use to cipher the
frame. The security configuration use ENC-MIC-32.
Initial state:
– Sender:
– macFrameCounter set to 0x00000000
– One GMK set in the macKeyTable : KeyIndex = 0x00, Key =
0x11111111111111111111111111111111
– Receiver:
– The FrameCounter entry for the sending device must be set to 0x00000000. This entry being
internal to the MAC Layer, the means used to initialize this value is left to the implementer.
–
One GMK set in the macKeyTable : KeyIndex = 0x00, Key =
0x11111111111111111111111111111111
Page 17/46
– msdu = (0x75)*45 and msduLength = 45
– SecurityLevel = 1, KeyIdMode = 0x01, KeyIndex = 0x00, KeySource value is ignored.
= 0x010C
– SecurityLevel = 5 (ENC-MIC-32), KeyIdMode = 0x01, KeyIndex = 0x00, KeySource value
is ignored.
– DSN = 0x29
3.2 MAC_GR2_002_Long_frame_ciphering
Description: This test covers the ciphering of a long MAC data frame.
The PHY layer is configured to use a DBPSK modulation with no notching and no tone-mapping.
frame. The security configuration use ENC-MIC-32. This should result in the transmission of 2
MAC segments.
Initial state:
– Sender:
Page 18/46
0x11111111111111111111111111111111
– Receiver:
–
0x11111111111111111111111111111111
– msdu = (0xA2)*300 and msduLength = 300
= 0x010C
– msdu = (0xA2)*300 and msduLength = 300
is ignored.
– DSN = 0x29
3.3 MAC_GR2_003_Invalid_ciphering_dropping
Description: This test checks that a frame using an invalid ciphering is dropped on reception.
Page 19/46
frame. The security configuration use ENC-MIC-32.
The frame is decoded with a supplied GCM key different from the one used for encoding. The
frame should be dropped with a ciphering error (the computed MIC is invalid, generating a
MLME-COMM-STATUS.indication with status = SECURITY_ERROR).
Initial state:
– Sender:
0x11111111111111111111111111111111
– Receiver:
–
0x22222222222222222222222222222222
– msdu = (0x8B)*45 and msduLength = 45
is ignored.
Page 20/46
1) The receiver should receive a MLME-COMM-STATUS.indication with status =
SECURITY_ERROR
3.4 MAC_GR2_004_unset_key_dropping
Description: This test checks that a frame using an unknown key is dropped on reception.
A msdu of 45 bytes is provided, along with the GMK key to be set in slot id 1 and frame counter to
use to cipher the frame. The security configuration uses ENC-MIC-32.
The frame is decoded without the GMK key set in the slot 1 (empty slot). The frame should be
dropped with a ciphering error (generating a MLME-COMM-STATUS.indication with status =
UNAVAILABLE_KEY).
Initial state:
– Sender:
0x11111111111111111111111111111111
– Receiver:
– The FrameCounter for the sending device must be set to 0x00000000. This entry being
–
No GMK set in the macKeyTable.
Page 21/46
– msdu = (0x8B)*45 and msduLength = 45
is ignored.
1) The receiver should
UNAVAILABLE_KEY
receive
a
MLME-COMM-STATUS.indication
with
status
=
3.5 MAC_GR2_005_Short_frame_ciphering_2
Description: This test covers the ciphering of a short MAC data frame.
frame. The security configuration use ENC-MIC-32. The frame counter and key value are different
from the previous tests, in order to catch endianness issues.
Initial state:
– Sender:
– macFrameCounter set to 2 685 554 979 (0xA0125123)
0xAB10341145111BC3C12DE8FF11142204
– Receiver:
Page 22/46
–
0xAB10341145111BC3C12DE8FF11142204
= 0x010C
is ignored.
– DSN = 0x29
Page 23/46
4 (GR3) Tests of the behaviour of the MAC layer when
receiving various MAC frames
The tests of the behaviour group are done between 2 implementations A and B, and the tests verify
some of the specified exchanges controlled by MAC layer between A and B.
Expected tests result are defined as a list of MAC layer indications and the final content of the
MAC neighbour table for each implementation.
Those tests are executed during a Plug-Fest.
4.1 MAC_GR3_001_Acknowledge_mechanism
This test checks that
– An acknowledge is sent by B in response to a data frame with ACK_Request enabled
coming from A.
– The acknowledge is correctly understood by A.
A data frame is sent by A with ACK_Request enabled. Then B must send an ACK PHY frame and A
must not send the data frame again.
Expected interactions on the line:
The device A should send a MAC data frame with the acknowledge request bit set.
The device B should send an acknowledgement frame.
Initial state:
– Device A:
0x781D
– Device B:
0x781D
Page 24/46
1) The device A call the MCPS-DATA.request primitive with:
1) The device A should receive the following MCPS-DATA.confirm:
– status = SUCCESS
– Timestamp value is ignored.
2) The device B should receive the following MCPS-DATA.indication:
= 0x010C
– DSN, msduLinkQuality and Timestamp values are ignored.
4.2 MAC_GR3_002_ PAN_Coordinator_reply_to_Beacon_Request
This test checks that the reception of a Beacon Request triggers the sending of a Beacon. The
receiver of the Beacon Request is configured as a PAN coordinator.
The device B should send a beacon request frame.
The device A should respond with a beacon frame (with informations indicating that the device is a
PAN coordinator).
Page 25/46
Initial state:
– Device A:
– Configured as PAN coordinator.
– Short MAC address = 0x0000, extended MAC address = 0x1122334455667788, PAN_ID =
0x781D
– Device B:
– No Short MAC address configured, extended MAC address = 0x8172635445362718, no
PAN_ID (= 0xFFFF).
1) The device B call the MLME-SCAN.request primitive with:
– ScanType = 0x01 (active scan)
– ScanChannels = 0 (unused)
– ScanDuration = 5 seconds
– ChannelPage = 0
1) The Device B should receive the following MLME-BEACON-NOTIFY.indication:
– PanDescriptor =
– PAN ID = 0x781D
– LBAAddress = 0x0000
– RC_COORD = 0
– LinkQuality value is ignored.
4.3 MAC_GR3_003_Node_reply_to_Beacon_Request
This test checks that the reception of a Beacon Request triggers the sending of a Beacon. The
receiver is configured as a “normal” node (correspond to a coordinator node in 802.15.4 wording).
The device B should send a beacon request frame.
The device A should respond with a beacon frame (with informations indicating that the device is a
normal G3 node).
Page 26/46
Initial state:
– Device A:
0x781D
– Device B:
– No Short MAC address configured, extended MAC address = 0x8172635445362718, no
PAN_ID (= 0xFFFF).
1) The device B call the MLME-SCAN.request primitive with:
– ScanType = 0x01 (active scan)
– ScanChannels = 0 (unused)
– ScanDuration = 5 seconds
– ChannelPage = 0
1) The Device B should receive the following MLME-BEACON-NOTIFY.indication:
– PanDescriptor =
– PAN ID = 0x781D
– LBAAddress = 0x002A
– RC_COORD and LinkQuality values are ignored.
4.4 MAC_GR3_004_Reply_to_Tone-Map_request_in_data_frame
This test checks that the reception of a Data frame with the Tone-Map Request field set to true
triggers the sending of a Tone-Map response.
Note: this test must be executed once for each band-plan tested (CENELEC-A, FCC/ARIB), as the
tone-map response messages are different.
The device A should send a MAC data frame with the TMR bit set.
The device B should send a Tone-Map Response (MAC command frame)
The device A should send an acknowledgement frame.
Page 27/46
Initial state:
– Device A:
0x781D
– Age set to 0 (so a ToneMap will be requested).
– Device B:
0x781D
Page 28/46
= 0x010C
3) The device A should have the following neighbour table entry for MAC address 0x010C:
– Age > 0 (indicate that a Tone-Map response have been received)
– The modulation value can not be predicted, however a value different from ROBO indicate
that a tone-map response have been received.
– ToneMap, TxGain and TxCoeff value are ignored.
4.5 MAC_GR3_005_Reply_to_Tone-Map_request_in_command_frame
(optional test)
This test checks that the reception of a Command frame (Tone-Map response) with the Tone-Map
Request field set to true triggers the sending of a Tone-Map response.
The device A should send a MAC data frame with the TMR bit set.
The device B should send a Tone-Map Response (MAC command frame) with the TMR bit set.
The device A should send an acknowledgement frame.
The device A should send a Tone-Map Response (MAC command frame).
Initial state:
– Device A:
0x781D
Page 29/46
– Age set to 0 (so a ToneMap will be requested).
– Device B:
0x781D
– Age set to 0 (so a ToneMap will requested).
= 0x010C
Page 30/46
3) The device A should have the following neighbour table entry for MAC address 0x010C:
4) The device A should have the following neighbour table entry for MAC address 0x002A:
4.6 MAC_GR3_006_Address_filtering_PAN_ID_and_PAN_ID_conflict
This test checks that a frame with a non-broadcast destination PAN_ID different from the receiver
PAN_ID is dropped and that the PAN_ID conflict mechanism is started (generation of a MLMESYNC-LOSS.indication primitive with LossReason = PAN_ID_CONFLICT by the receiver).
The device A should send a MAC data frame. This frame should be sent several time due to the
absence of acknowledge reply.
The device B must not send an acknowledgement frame.
Initial state:
– Device A:
0x781D
– Device B:
0x781D
Page 31/46
– DstPANId = 0x0001
– status = NO_ACK
2) no MCPS-DATA.indication should be generated by the device B.
3) The device B should generate a MLME-SYNC-LOSS.indication primitive:
– LossReason = ALTERNATE_PANID_DETECTION;
– PANId = 0x0001
– LogicalChannel = 0 (not used)
– ChannelPage = 0 (not used)
– SecurityLevel = 0 (not used)
– KeyIdMode, KeySource and KeyIndex can be ignored.
4.7 MAC_GR3_007_Address_filtering_short_address
This test checks that a frame with a non-broadcast short destination MAC address different from the
receiver short address is dropped.
Page 32/46
The device A should sent a MAC data frame. This frame should be sent several time due to the
Initial state:
– Device A:
0x781D
– Device B:
0x781D
– DstAddr = 0x0089
– status = NO_ACK
Page 33/46
4.8 MAC_GR3_008_Address_filtering_extended_address
This test checks that a frame with an extended destination MAC address different from the receiver
extended address is dropped.
The device A should send a MAC data frame. This frame should be sent several time due to the
Initial state:
– Device A:
0x781D
– Device B:
0x781D
– SrcAddrMode = short address, DstAddrMode = extended address
– DstAddr = 0xAEADAEADAEADAEAD
– status = NO_ACK
Page 34/46
4.9 MAC_GR3_009_Address_filtering_broadcast_address
This test checks that a frame with a short destination MAC address equal to 0xFFFF is indicated by
the receiver.
The device A should send a MAC data frame.
Initial state:
– Device A:
0x781D
– Device B:
0x781D
– DstAddr = 0xFFFF
– TxOptions = no acknowledge required (other parameters have fixed values)
1) The device A should generate the following MCPS-DATA.confirm:
Page 35/46
2) The device B should generate the following MCPS-DATA.indication:
= 0xFFFF
4.10 MAC_GR3_0010_Address_filtering_broadcast_PAN_ID
This test checks that a frame with an PAN_ID destination equal to 0xFFFF (and a short destination
MAC address equal to 0xFFFF) is accepted by the receiver, regardless of the receiver PAN_ID
configured value.
Initial state:
– Device A:
0x781D
– Device B:
0x781D
– DstPANId = 0xFFFF
Page 36/46
– DstAddr = 0xFFFF
– TxOptions = no acknowledge required (other parameters have fixed values)
1) The device A should generate the following MCPS-DATA.confirm:
2) The device B should generate the following MCPS-DATA.indication:
= 0xFFFF
– SrcPANId = 0x781D, DstPANId = 0xFFFF
4.11 MAC_GR3_011_PAN_ID_conflict (Removed)
This test have been merged with GR3_006 and removed from the Test Suite.
4.12 MAC_GR3_012_Neighbour_Table_add_unknown
This test checks that when receiving a frame, the receiver adds an entry in the neighbour table for
this sender short address.
Initial state:
Page 37/46
– Device A:
0x781D
– Device B:
0x781D
= 0x010C
Page 38/46
3) The device B should have the following neighbour table entry for MAC address 0x002A:
– Age = 0.
– IsNeighbour = macMaxNeighborValidTime.
– ToneMap = all sub-carriers used
– TxGain = 0, TxCoeff = 0 (for each carrier group)
4.13 MAC_GR3_013_Neighbour_Table_Tone-Map_response
This test checks that when receiving a Tone-Map response, the receiver updates the entry in the
neighbour table for this sender short address and sets the Age field to a non-zero value.
This test duplicates MAC_GR3_004 and should be removed.
Page 39/46
5 (GR4) Test of the timing related mechanisms
Those test checks that the timing during exchanges between 2 implementations respects the
specification timing description. Only the respect of the intervals defined by the specification are
tested.
Those tests are executed during a Plug-Fest. The measurements will be done using an oscilloscope
connected to the cold-wire.
For this execution of the interoperability tests, the following values are used:
– For CENELEC-A band-plan:
– aRIFS = aCIFS = 8 symbols.
– Symbol duration = 695µs.
– For FCC band-plan:
– aRIFS = aCIFS = 10 symbols.
– Symbol duration = 231,66µs.
– For ARIB band-plan:
– aRIFS = 10 symbols, aCIFS = 108 symbols.
– Symbol duration = 231,66µs.
– macHighPriorityWindowSize = 7, resulting in HPCW = 14 symbols.
– macMinBE = 3.
The expected duration described in the tests are tested with a tolerance of +/- 1 symbols, to take into
account measures imprecision.
5.1 MAC_GR4_001_Delay_between_data_frame_and_ACK
The duration between the end of a valid MAC frame with Acknowledge Request set to true and the
beginning of the resulting acknowledge is measured. This duration must respect the RIFS value (see
G3 specification §C.4).
Initial state:
– Device A:
0x781D
– Device B:
Page 40/46
0x781D
= 0x010C
Physical measurements:
The data frame must be seen on the line only once (if not, the acknowledgement may not be
correctly working between the devices).
The delay between the end of the frame and the start of the acknowledge is measured, a duration of
(RIFS) is expected.
For CENELEC-A, this duration corresponds to = 5,56 ms.
For FCC/ARIB, this duration corresponds to = 2,32 ms.
Page 41/46
5.2 MAC_GR4_002_Delay_between_ACK_and_frame_contention_free_
priority
The duration between the end of an acknowledge and the start of the following MAC frame which
uses the contention free access level of priority is measured. This duration must be greater than
CIFS and smaller than (CIFS + CFS) (see G3 specification §C.4).
Initial state:
– Device A:
0x781D
– Device B:
0x781D
– msdu = 0xFF * 300 and msduLength = 300
= 0x010C
Page 42/46
– msdu = 0xFF * 300 and msduLength = 300
Two data frames should be seen on the line (2 segments).
The delay between the end of the first segment acknowledge and the start of the second segment is
measured. This duration should be between CIFS and (CIFS + CFS).
For CENELEC-A, the duration measured should be between 5,56 ms and 6,95 ms.
For FCC, the duration measured should be between 2,32 ms and 2,78 ms.
For ARIB, the duration measured should be between 25 ms and 25,46 ms.
5.3 MAC_GR4_003_Delay_between_ACK_and_frame_high_priority
uses the high priority access level is measured. This duration must be greater than (CIFS + CFS)
and smaller than (CIFS + CFS + HPCW) (see G3 specification §C.4).
Due to the random back-off value chosen by the sender, the test must be executed several times in
order to validate the correct usage of the priority window range.
Initial state:
– Device A:
0x781D
– Device B:
0x781D
1) The device A call the MCPS-DATA.request primitive 2 times with:
Page 43/46
Note: the two MCPS-DATA.request must be called without delay in between, so the frames are sent
on the line without idle time and the CSMA priority apply.
1) The device B should receive the following MCPS-DATA.indication twice:
= 0x010C
Two data frames should be seen on the line (independent frames).
The delay between the end of the first frame acknowledge and the start of the second frame is
measured. This duration should be between (CIFS + CFS) and (CIFS + CFS + HPCW).
For ARIB, the duration measured should be between 25,46 ms and 28,71 ms.
5.4 MAC_GR4_004_Delay_between_ACK_and_frame_normal_priority
uses the normal priority access level is measured. The test assumes that no collision can occur (only
one sender on the line at a given time). This duration must be greater than (CIFS + CFS + HPCW)
and smaller than (CIFS + CFS + HPCW + ((2^minBE – 1) * aSlotTime)) (see G3 specification
§C.4).
Page 44/46
Due to the random back-off value chosen by the sender, the test must be executed several times in
order to validate the correct usage of the priority window range.
Initial state:
– Device A:
0x781D
– Device B:
0x781D
1) The device A call the MCPS-DATA.request primitive 2 times with:
Note: the two MCPS-DATA.request must be called without delay in between, so the frames are sent
on the line without idle time and the CSMA priority apply.
1) The device B should receive the following MCPS-DATA.indication twice:
= 0x010C
Page 45/46
Two data frames should be seen on the line (independent frames).
The delay between the end of the first frame acknowledge and the start of the second frame is
measured. This duration should be between:
– (CIFS + CFS + HPCW)
– (CIFS + CFS + HPCW + ((2^minBE – 1) * aSlotTime))
For ARIB, the duration measured should be between 28,71 ms and 31,95 ms.
Page 46/46

Context - G3-PLC Alliance

Transcription

Similar documents

LA FAVORITA

Pebble Camera - Joyful Living Services

How to set up Filter IP/ MAC on Zyxel VMG1302-T10A... 1. Type 192.168.1.1 at the Browser Address then hit Enter,...

The Most Advanced Electronic Highlighter The IRISPen™ Executive

Get the look

tv sports shop food voices sex

Poster "CNIT and UTH/NICTA experiment"

Spectra AV – Technical Specifications

Word 2016 for Mac - Information Technology Services

Term Sheet - Freddie Mac