PowerLine Coordinator V2.

0 Firmware
Requirements Specifications
Update Date: June 27, 2022

The information and methodologies outlined herein are proprietary, trade secret, and copyrighted, with all rights reserved
to Smart Wires. Copying or distributing this material without prior permission is strictly prohibited.
PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

Revision History
Revision Description Signature Date
Author Asfa Mehmood 30-May-22
Initial PowerLine Coordinator V2.0
1.0 Verified
Requirement Document
Approved
Author Asfa Mehmood 27-June-22
Interphase Balancing
1.1 Verified
Communication Protocol
Approved

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

Table of Contents
1. Introduction.................................................................................................................................................
1.1. Purpose................................................................................................................................................6
1.2. Scope....................................................................................................................................................6
1.3. Standards and Directives......................................................................................................................8
1.4. Smart Wires PLC V2 Control Board Requirement IDs Structure...........................................................8
1.5. Non-Functional Requirements Specification........................................................................................8
1.6. Quality..................................................................................................................................................8
1.7. PLC V2 Functionality Overview.............................................................................................................9
2. Communication Architecture......................................................................................................................
2.1. Ethernet Communication...................................................................................................................10
2.2. Packet Header....................................................................................................................................10
2.3. Protocol Header.................................................................................................................................11
2.4. Fiber Optics Schedular.......................................................................................................................13
2.5. Network Packets................................................................................................................................14
2.6. Application Data Unit (APDU) Packets...............................................................................................16
2.7. Interphase Balancing (IPB) Communication Protocol.........................................................................23
3. Cyber Security............................................................................................................................................
3.1. Fibre-Optic Network Security.............................................................................................................28
4. References.................................................................................................................................................

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

List of Figures
Figure 1-1: E2E System Diagram with FO Communications---------------------------------------------------------------------7
Figure 1-2: FO Communications Ring-------------------------------------------------------------------------------------------------8
Figure 1-3: PLC V2 Architecture-------------------------------------------------------------------------------------------------------10
Figure 1-4: PLC V2 Front View---------------------------------------------------------------------------------------------------------10
Figure 1-5: PLC V2 Rear View----------------------------------------------------------------------------------------------------------10
Figure 2-1: Ethernet Packet------------------------------------------------------------------------------------------------------------11
Figure 2-2: Ethernet Type--------------------------------------------------------------------------------------------------------------11
Figure 2-3:Protocol Header------------------------------------------------------------------------------------------------------------12
Figure 2-4: Cmd Type--------------------------------------------------------------------------------------------------------------------12
Figure 2-5: MAC Flags-------------------------------------------------------------------------------------------------------------------13
Figure 2-6: MAC Hash Validation-----------------------------------------------------------------------------------------------------13
Figure 2-7 Protocol Schedular---------------------------------------------------------------------------------------------------------14
Figure 2-8 Unicast Address-------------------------------------------------------------------------------------------------------------15
Figure 2-9 Group Address--------------------------------------------------------------------------------------------------------------15
Figure 2-10 : Application Data Unit Packet Field---------------------------------------------------------------------------------18
Figure 2-11 : Application Data Unit Packet Header for Request Packet----------------------------------------------------18
Figure 2-12 : Application Data Unit Packet Header for Response Packet--------------------------------------------------18
Figure 2-13 Telemetry Commands Scheduling------------------------------------------------------------------------------------21
Figure 2-14 Commands Passes--------------------------------------------------------------------------------------------------------22
Figure 2-15 Interphase Request Packet---------------------------------------------------------------------------------------------24
Figure 2-16 Interphase Request Packet Header----------------------------------------------------------------------------------24
Figure 2-17 Interphase Response Packet-------------------------------------------------------------------------------------------25
Figure 3-1: Device Initialization and Authentication-----------------------------------------------------------------------------31

List of Tables
Table 0-1 Acronyms-----------------------------------------------------------------------------------------------------------------------5
Table 1-1: Requirement IDs Structure------------------------------------------------------------------------------------------------8
Table 1-2: Quality--------------------------------------------------------------------------------------------------------------------------8
Table 1-3: LEDs and their functionalities--------------------------------------------------------------------------------------------9
Table 2-1: APDU Commands-----------------------------------------------------------------------------------------------------------16
Table 2-2: App command sub-type-------------------------------------------------------------------------------------------------17
Table 2-3: Command Target Type--------------------------------------------------------------------------------------------------18
Table 2-4: Scope of packet under various field settings-----------------------------------------------------------------------19

Note

Notes are used to remind the users of important points

and tips related to the system.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

Acronyms
Terms Definition
PLM PowerLine Manager
SWGF Smart Wires Guardian Family
SWFD Smart Wires Field Devices
iFOD i-series Fiber-Optic Driver Board
SV SmartValve
EIU Electrical Injection Unit
EIUC Electrical Injection Unit Controller
SB SmartBypass
FCC Fast Critical Communication
PLC PowerLine Coordinator
NC Network Coordinator
SWAM Smart Wires Data Access and Management Protocol
SWIM Smart Wires ISM Mesh Protocol
PRD Product Requirement Document
MCU Microprocessor Control Unit
OTA Over-the-Air
RSSI Received Signal Strength Indicator
CRC Cyclic redundancy check
NIB Network Interface Bridge
SCR Silicon-Controlled Rectifier
AES Advanced Encryption Standard
FHSS Frequency Hopping Spread Spectrum
TCP/IP Transmission Control Protocol/Internet Protocol
UDP User Datagram Protocol
IEEE Institute of Electrical and Electronics Engineers
DC Direct Current
RMS Root Mean Square
PSU Power Supply Unit
CTP Current Transformer for Power
V&V Verification and Validation
VI Vacuum Interrupter
µp Microprocessors
Desat Desaturation
NTC Negative Temperature Coefficient
VSL Vacuum Switch Link
PLL Phase Lock Loop
FCS Fault Current Sensor
PI Proportional Integral Gains
SWG Smart Wire Grid
Table 0-1 Acronyms

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

1. Introduction
1.1. Purpose
The purpose of this document is to provide functional requirement specifications for PowerLine Coordinator
V2. The document provides specifications of different functionalities performed by PLC V2. It includes
communications, cybersecurity interphase balancing, and redundancy related information. time
synchronization

1.2. Scope
The PowerLine Coordinator v2 is intended to be a rugged and reliable communication device to serve as an
intermediary between the SmartValves and the PowerLine Gateway™. It is intended to be responsible for
managing the FO communication links between itself and the SmartValves. It will also be responsible for
communicating with the PowerLine Gateway for control and status reporting. The communication with the
PowerLine Gateway will be via a proprietary and secure authenticated protocol over TCP/IP. The PowerLine
Coordinator v2 will be a robust and reliable communication device that acts on behalf of PowerLine Gateway
to:
• Establish a ring-based secure authenticated FO communication link with SmartValves
• Establish a proprietary/authenticated communication link with the SmartValves
• Commission the SmartValves
• Aggregate data and control multiple SmartValves
• Cache and reliably transfer firmware image to the SmartValve devices as part of the Smart Wires’
proprietary firmware upgrade protocol

The PowerLine Coordinator v2 will be an important component of the Smart Wires End-to-End (E2E)
Communication and Control System that enables the utility to seamlessly commission, observe, control, and
maintain the overall Smart Wires solution. Figure 1-1 shows the communication architecture with PowerLine
Coordinator v2 when using the FO communication option.
This document specifies the high-level requirements the PowerLine Coordinator v2 must fulfill.

Figure 1-1: E2E System Diagram with FO Communications

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

Figure 1-2: FO Communications Ring

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

1.3. Standards and Directives

The PowerLine Coordinator v2 shall comply with the following other standards, as referenced in the
requirements to follow.
• IEC 61000-6-2:2005
• IEC 61000-6-4:2007 /A1:2011
• IEC 61000-3-2:2014
• IEC 61000-3-3:2013
• ETSI EN 301 489-1 V2.1.1 (2017-02)
• ETSI EN 301 489-3 V2.1.1 (2017-03)
• Radiation limits of IEC 62271-1:2017
• As applicable with IEC 61000-6-5:2015

1.4. Smart Wires PLC V2 Control Board Requirement IDs Structure

The following structure is followed for requirement IDs.
SWPLC2-XX-XX-XXXX
<Project> - <Functional/Non-Functional specification> - <Safety/Non-Safety specifications> - <Function
Number>
No. Functions Acronym
1. Project SWPLC2
Functional/Non-Functional Specification
2. Functional Specifications FS
3. Non-Functional Specifications NFS
Safety/Non-Safety Specification
4. Safety Specification SR
5. Non-Safety Specification NS
6. Function Number XXX
Table 1-2: Requirement IDs Structure

1.5. Non-Functional Requirements Specification

All the requirements that come under this section will be part of the non-functional area of the firmware and
firmware development lifecycle.

1.6. Quality
This requirement applies to PLC V2 Bypass Control Board.
Sub-ID Description
The applicable design and regulations for the project must comply with coding and design
1.
guidelines.
The following attributes of the firmware must be taken into consideration:
1. Adaptability
2. Availability/robustness
2. 3. Correctness
4. Maintainability
5. Reusability
6. Testability
Table 1-3: Quality

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

1.7. PLC V2 Functionality Overview

Figure 1-3: PLC V2 Architecture

Figure 1-4: PLC V2 Front View

Figure 1-5: PLC V2 Rear View

The LEDs with their respective functions are shown in table 4:
[Requirement ID: SWPLC2-FS-NSR-001A]

Table 1-4: LEDs and their functionalities

Description Purpose
POWER 1 System Power
POWER 2 System Power
SYSTEM HEALTH System Health
TIME SYNC Time Synchronization
COMMS Communication Status

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2. Communication Architecture
2.1. Ethernet Communication
The communication loop that starts from the primary PLC goes through all field devices A1, B1, and C1
all the way to An, Bn, Cn and terminates at secondary PLC (see Figure 1-2). This communication loop
operates at 1 Gbps (Gigabit per second) which is 125 MBps (Megabytes per second). The maximum
ethernet packet size inclusive of the protocol header and payload can be 1500 bytes.

2.2. Packet Header

1. Several packets exchanged between PLC and SmartValve Ethernet interface, these packets are routed
from PLC
2. Each packet contains 14 bytes of MAC header including destination MAC address, source MAC
address, and Ethernet type as shown in the figure.

Figure 2-6: Ethernet Packet

1. ‘Ethernet type’ packets categorized into the following two sub categorizes
a. 0x5860 - Ethernet Packet from Gateway/PLC
b. 0x0800 - Utility Packets

Figure 2-7: Ethernet Type

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2.3. Protocol Header

After 14 bytes of MAC header, the packet contains protocol header of 46 bytes including 4 bytes of MAC hash.

Figure 2-8:Protocol Header

Following are the details of MAC header fields:

2.3.1. Protocol Version
It indicates the version of the protocol in use. Initially this will be set to zero.
2.3.2. Header Length
It indicates the number of bytes in MAC header.
2.3.3. Destination IDs
Two bytes unique id of the packet destination device.
2.3.4. Source IDs
Two bytes unique id of the packet source device.
2.3.5. Cmd Type
a. Network Packet (0x00) type is used to authenticate, join, rejoin and leave a device on the network
b. Fault packets (0x01) are used to identify faults from device to PLC
c. Application packets (0x02) use to categorized device commands from User Interface
d. Interphase packets (0x03) are used for IPB synchronization between three phases

Figure 2-9: Cmd Type

2.3.6. Cmd Id
Not used currently
2.3.7. MAC Flags
Single byte Mac Flags field is further split into 8 bits. Currently only 2 bits are in use. Rest of the 6 bits
are reserved for future modifications
Mac Security bit is set to indicate that packet has mac security attached in the end of packet. This security
is attained through 4-byte hash value. Hash calculation uses HMAC SHA-256 algorithm with inputs: MAC
header and network key. This hash is calculated on mac layer.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

App Security bit has a similar use as that of Mac security bit. It appends hash for application layer payload
and indicates that security needs to be validated. Hash calculation uses HMAC SHA-256 algorithm.

Figure 2-10: MAC Flags

2.3.8. Payload Length
Indicates the total length of payload data.
2.3.9. Sequence Number
is used to facilitate retries. A node will increment the Sequence Number each time it sends a message on
the MAC layer except for retries
2.3.10. Timestamp
Timestamp of when packet was built by the node
2.3.11. MAC Hash
4 bytes MAC Hash is calculated over the MAC header fields and appended at the end of MAC header provided
MAC security flag is set. Upon reception the receiver calculates the MAC Hash and compares with the Hash
appended in the packet. Only those matched Hash packets are processed by the unit

Figure 2-11: MAC Hash Validation

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2.4. Fiber Optics Schedular

Basic Schedular runs at 5mSec interval with first two packets reserved as IPB packets. Third packet can either
be a network or application data unit command. Responses for all transmitted packets follow in sequence of
transmission.
1. In every slot, two IPB packet requests are sent to gather IPB data. Each group has three devices. A total of
six IPB responses are received by PLC in a slot by each device.
2. At start when none of the devices in PLC nodes list is authenticated with the network, PLC schedules
network packets at intervals to authenticate node devices. As soon as a device gets authenticated,
application data unit packets are also scheduled for regular communication with devices.
3. Network packets (NMEM message and challenge message) are scheduled in every 15 th schedular
pass(75mSec). Until all nodes are authenticated with PLC, network membership message is followed by
four network challenge messages in four consecutive network packet slots. When all nodes have joined
network, NMEM messages are sent over all network packet passes.
4. Challenge message initiates a four-way handshake with the node which wants to join the network. In
response to challenge message, PLC receives network join response (NJR) packet from the node. On
reception of NJR, PLC sends keying packet in the next other commands pass and awaits acknowledgment
from node in the same slot. For network membership message, PLC does not receive any responses.
Further details on network packets can be found in 2.5.
5. Application packets include telemetry request command and other APDU commands (listed in 2.6.1).
Scheduler alternates between Telemetry request command and other command passes (if scheduled).
6. Telemetry command is always scheduled as unicast. Other APDU commands can be unicast, multicast or
broadcast. Responses for unicast commands are received in the same slot, whereas, responses for
broadcast and multicast commands may take several slots before being marked as complete.
7. Due to redundant path, PLC receives twice the number of required responses. These unrequired packets
are discarded at MAC layer.

Figure 2-12 Protocol Schedular

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2.5. Network Packets

2.5.1. Network Layer Addressing
There are three addresses to address a unit.
a) Unicast Address
b) Broadcast Address
c) Groupcast Address
The six bytes unicast address of a unit is derived from unit serial number with LSBs as zero. In addition to
unicast address, the devices are also assigned with group address on network authentication. A unique group
address is generated by using interphase group id as MSB of the address. The ethernet switch on devices is
configured with both unicast and group addresses. The switch on node allows the packet through, if unicast
address or group address is matched. Switch allow packets if address is set to broadcast as well. 0xFFFFFFF is
used for broadcast address.

Figure 2-13 Unicast Address

Figure 2-14 Group Address

2.5.2. Network Joining and Registration

Network Packet Type are further divided into following frame types.
1) Network Membership Message (0x04)
2) Network Challenge Message (0x03)
3) Network Join Request Message (0x00,0x01,0x02)

First byte in network packet defines this frame type.

2.5.3. Network Membership (NMEM) Message

Network Membership messages are sent periodically in order to let the new nodes in the network
know that they are part of this network or not.
1. Nodes will be assigned to a particular PowerLine Coordinator using PowerLine Manager. The
PowerLine Coordinator will send out Network Membership Messages containing the addresses of all
the nodes that are part of the network. Nodes who have not yet authenticated with the network, will
register with the PowerLine Coordinator by seeing their addresses in the Network Membership
Messages.
2. Nodes that are already part of the network, will leave the network if they do not see their address in
the list.
3. The PowerLine Coordinator will continuously send Network Membership messages with periodicity of
375 milliseconds.
4. When the PowerLine Coordinator sends the NM message it will be sent as a broadcast message.
5. Unlike SWIM, single NM message from PLC is enough to publish the entire network membership list.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

6. Nodes which have not joined the network will listen for Network Membership messages. When an
NM is received, the node will scan this message looking for its address. If its address is not included in
the message, it will reset its addresses and configuration.
7. NM is scheduled periodically with intervals of 375 milli-seconds
2.5.4. Network Challenge Message
1. The Network Challenge message supplements the information in the Network Management message
in order to facilitate a node to join the network. The Network Membership message is only used to let
a node know that it is part of a network. Information presented in the Network Challenge message is
necessary for it to actually join the network.
2. Unlike SWIM, network challenge message in fibre-optic communication is unicast packet.
3. The following information is available in the Network Challenge message.
a. Network Packet Frame Type (0x03)
b. Single byte Nonce length followed by NonceNC. The NonceNC is the authentication challenge
sent out by the PowerLine Coordinator to invite response from targeted SmartBypass device
who want to exchange authentication information with it.
c. PowerLine Coordinator’s address
d. The challenge message will also contain the latest configuration version.
4. The challenge messages are sent only if there are any node addresses left to be authenticated.
5. Challenge messages are scheduled to be sent at an interval of 75 milli-seconds for four passes. In
every fifth slot, membership message is scheduled.

2.5.5. Network Join Request (NJR) Message

The network join request is used by nodes to authenticate with the network. These messages are
used to exchange the group key as well as the unique PLG key for authentication. If a node does not already
have these keys when it is part of a particular network, it will request the PowerLine Coordinator using a 3-way
NRJ messages exchange.
The network joining process involves three steps. Each NJR has separate packet type as shown below.
1. Node to PowerLine Coordinator: Response to Challenge (0x00).
2. PowerLine Coordinator to Node: Keying (0x01)
3. Node to PowerLine Coordinator: Acknowledgement (0x02)
For each of these messages there is a variable length block of bytes, specified by the Cryptography Block
Length.
The Cryptography Block Length only specifies the authentication and keying specific information length. There
are additional bytes after the cryptographic block length.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2.6. Application Data Unit (APDU) Packets

1.1.1 List of APDU Commands:
Application packets include telemetry request command and other APDU commands. Currently supported
other commands are listed below:

Command Command Id Description

Telemetry 0x01 Device Telemetry
OTA Notify 0x20 Device OTA Notify
OTA Validate 0x21 Validate the OTA Image CRC
OTA Activate 0x22 Activate OTA Image Trigger

OTA Cancel 0x23 Cancel Ongoing OTA Process

Injection 0x30 Injection/Monitoring

Reset 0x31 Reset devices

Generic Application Supports multiple commands with
0x32
Command multiple sub-IDs
Initializes file transfer from PLC to
File Transfer Notify 0x40
devices
File Transfer
0x41 File segments wise acknowledge
Acknowledgment
File Transfer
0x42 File transfer completion
Complete
Bulk Read Transfer 0x43 Bulk Readback from devices
Various device settings (Personality
Settings 0x50 Configurations, IPB Control, Quiet Mode
& EDR configuration attributes).
EDR Utility Command 0x60 EDR Utility Communication

E2E EDR Command 0x61 E2E EDR Communication

Regrouping 0x70 To reform a new IPB group

Table 2-5: APDU Commands

1.1.2 APDU Packet field

APDU Packet composes an application layer header, payload data and packet hash. Figure 2-10 shows the
application data unit packet.
Application Packet Header – APDU packet length varies with command type and target type. Moreover,
packet headers for request and response also differ.
Payload – It is the payload data of application layer packet. Its size varies with command type and target type.
Hash – If App security bit in Mac Flags field of packet MAC header (as described in topic 2.3.7.) is set, a 4-byte
security hash is appended at the end of APDU packet. It is calculated using either the private key of single node
(if packet is targeted for a single bypass.) or group key of network (if packet is for more than one unit.). It is
used to detect packet validity.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

Private key: Private Keys are unique for each bypass.

Group Key: All nodes in one network are assigned same group key.

Figure 2-15 : Application Data Unit Packet Field

Figure 2-16 : Application Data Unit Packet Header for Request Packet

Figure 2-17 : Application Data Unit Packet Header for Response Packet
1. App Header Length – This parameter contains the header length of the packet. It denotes the index
where payload starts. Application packet header length varies with command type and target type.
2. App Command Type – Defines type of command on a broader level e.g. telemetry, E2E EDR, Firmware
OTA command.
3. App Command Minor Type – Command minor type defines the particular action under app command
type. This parameter is kept zero for app commands which do not need minor command type.
4. App Command Sub Type – Nodes do not respond on all types of commands received from PLC. They
decide on whether to send a response based on this parameter.

Mac Packet
App Command Source Destination
Destination Description
Sub Type Value Device Device
Address
Packet for single node. Node sends
Node address
response. No APP_CMD_FOR_RESP
(0xABCDEF98)
required in this case.
0 PLC Bypass
APP_CMD Nodes do not send response and wait
Broadcast
for APP_CMD_FOR_RESP
(0xFFFFFFFF)
packet from PLC to send response.

PLC address Command Sub Type is set 1 in every

1 Bypass PLC
(0xABCDEF98) APP_RESP packet received by PLC from node.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

This type is set in packet after sending

Node address APP_CMD_FOR APP_CMD sub type packet. Nodes wait
2 PLC Bypass
(0xABCDEF98) _RESP for this command in order to send
response.

Table 2-6: App command sub-type

5. Command ID – Command ID is a record of new command. Command ID is always incremented on new

trigger for a particular app command type. In case of retries, command ID is kept same.
6. Command Target Type – This parameter represents target type which the command is targeting e.g.
Target bypass (other parameters in packet define single bypass unit or more), target bypass and
converters, target single converter or all converters.

Command
Value Packet Scope
Target Type

Target Type is set 0 if packet is intended for single or multiple bypass/es.

TARGET_BYPASS 0 Mac header minor ID, selection filter (described in table 2.5) decide
between single and multiple bypasses.

TARGET_CNV 1 When a single converter is targeted, this value is set in target type field.

This value says a whole unit including bypass and its underlying
TARGET_BYPASS_CNV 2
converters should be targeted.

TARGET_ALL_CNV 3 All converters are targeted for this packet.

Table 2-7: Command Target Type

7. Apply Selection – When a packet is broadcasted, all nodes check if selection is applied. If this field is
marked true, devices only process the command after applying selection filter.
8. Number of Nodes – It is the number of nodes the command is targeted for.
9. Selected IDs – It contains unique Node IDs of nodes which the command is targeting. All nodes look for
their IDs in the list in order to process the packet. Selected IDs list size varies with number of nodes. It
can be of one byte for single unit and maximum 30 bytes for all units in network.
Parameter 9 and 10 i.e. Number of Nodes and Selection IDs are appended only if ‘Apply Selection’ parameter is
marked and ‘Target Type’ is not set as TARGET_CNV.
10. Diagnostics TX Count – Transmission count so far.
11. Diagnostics RX Count – Reception count so far.
12. Reset Diagnostics Cmd – Field to indicate diagnostics count need to be reset.
13. Reserved – This field is kept reserved for future modifications.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

Mac Packet Command Selection Filter

Apply
Header Minor Target (Num of Nodes Target Description
Selection
ID Type + Selected IDs)

Packet for only one bypass.

Node address Single
0 No Node address is unique to
(0xABCDEF98) Bypass
TARGET_BYP only one bypass.
ASS Multiple Packet for all bypasses with
Broadcast 1 Yes
Bypasses node ID in selected IDs list.
(0xFFFFFFFF)
0 No All Bypasses Packet for all bypasses.
4-byte converter address is
Node address Single
TARGET_CNV 1 No appended at the start of
(0xABCDEF98) Converter
packet payload.
Single whole unit (single
Node address
0 No One unit bypass with all connected
(0xABCDEF98)
converters)
All bypasses
and This type is packet is
0 No converters processed by whole unit setup
TARGET_BYP
connected (all bypasses and converters).
ASS_ CNV
Broadcast with them.
(0xFFFFFFFF) Multiple
All bypasses in selected IDs
bypasses
and their underlying
1 Yes and their
converters process this
underlying
packet.
converters.
Converters This packet will be for all
Node address
0 No under single converters under single
(0xABCDEF98)
bypass. bypass.
All
This command is for all
converters
TARGET_ALL 1 Yes converters. No bypass
under all
_CNV processes this packet.
Broadcast bypasses.
(0xFFFFFFFF) All
All bypasses and their
converters
0 No converters will process this
under all
command.
bypasses.

Table 2-8: Scope of packet under various field settings

2.7.1. Telemetry Request Packets

If a node/device is in network with PLC, this SmartValve will constantly provide its status/telemetry data over
the communication line to PLC. The PLC then transmits this data to the Gateway where this data is stored and
later retrieved by the Smart Interface.
 The PLC issues a telemetry request for each node/SmartValve in every slot. If there are any other
commands scheduled, schedular will switch between both commands with telemetry request sent in
one slot and other command in next slot. In following slot, PLC can again issue telemetry request for
next node/device in ring.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

 Telemetry requests are unicast. Target node address is populated in the packet for the respective
node. The node that is addressed, responds with the telemetry data within the same 5 milliseconds.
 There can be a maximum of 10 nodes/devices connected per phase. Which makes a total of 30
devices (max) on all phases. Assuming it takes 5 milliseconds to fetch telemetry data from each device
at alternate schedular pass, it will take a maximum of 2 x 5ms x 30 = 300 milliseconds to get telemetry
data from all devices.
 This delay assumes that the communication between PLCs and the devices is based on fiber optic
cable.
 If the PLC does not receive telemetry data from a particular device for 6 consecutive cycles
(approximately 2 seconds) then the device will be marked as off-line and this status will be
communicated to the gateway.
 If a device is authenticated to be in network with PLC and is marked offline, PLC marks that
node/device as online on receiving telemetry data from this node, and sends this data to the
Gateway.
 The telemetry data is sent to the Gateway every 10 seconds.
 Telemetry generally comprises of statuses required to monitor PLC and SmartValve devices.
 Complete list of telemetry parameters can be seen in the telemetry sheet.

Figure 2-18 Telemetry Commands Scheduling

1.1.3 Telemetry refresh rate:

PLC receives telemetry packets from devices every 10 milliseconds (5ms for telemetry and 5ms for command).
There can be a maximum of 30 devices connected to a PLC in Smart Valve v1.04. That makes a maximum
refresh rate of telemetry of a device/node is 300 milliseconds.
1.1.4 Other APDU Command Passes and Scheduling
Depending upon the number of target devices for application layer command and command
successes, application layer command can take single or multiple passes before being marked as complete.
1. When there is any other APDU command to be sent, command is scheduled and inserted in Transmission
FIFO. Once scheduled, scheduler loads the command from FIFO and transmits it over fiber-optic. After
transmission, PLC always switches to telemetry command. Alternate scheduler slot passes are reserved for
transmission of FIFO commands.
2. Other APDU commands can be unicast (for single node), multicast (for multiple nodes) or broadcast (for all
nodes).
3. If the other command to be sent is unicast, target node address is populated in the packet header. The
targeted node responds in the same slot.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

4. If response of a unicast other command is not received to PLC in the same slot, two retries can be made
before clearing this command from FIFO.
5. For multicast and broadcast packet transmission, node address field is set to 0xFF i.e. Broadcast, and
target node IDs are populated in the packet. Nodes, on reception of this packet, will check for their unique
node ID in the packet to decide whether to process the packet or discard it.
6. When nodes receive multicast or broadcast command from PLC, each node waits for a proceeding unicast
command for response of the same type, to send response to PLC. PLC then transmits a unicast command
to all nodes in order to receive response.
7. This unicast command for response has two retries before PLC moves to next unit in network.
8. If all node responses are received, PLC marks command as complete and clears the Tx FIFO.
9. If response from any of the nodes is not received and retries have expired, PLC retries whole command
cycle four times.
10. When all retries have expired, command is discarded and cleared from TX FIFO.

Figure 2-19 Commands Passes

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

1.1.5 Request Time of Commands

PLC awaits acknowledgement after sending each command. If it is not received, the command will be
sent again.
If a command is for all devices, it is broadcasted. The response time will depend on the number of devices
connected. For example,
Let’s assume an injection command is triggered in a 10 units per phase network
1) First a broadcast injection command will be sent.
2) Then 30 unicasts will be sent for response gathering.
3) All the time telemetry will be scheduled in every alternate schedular pass
4) Total of 62 = ((30 + 1) *2) passes will be required for injection command completion in best case
scenario.
1 Pass = 5 mSec
62 Passes = 310 mSec

5) 3 tries are sent for this type of unicast command.

6) 5 tries are sent if retries in first attempt expire.
7) The worst-case response time for 30 devices will be
((((30*3) +1) *2) * 5) = 910 passes
~ 5 Secs.
1.1.6 Online-Offline Marking
2.6.1. Mark Online
 Authenticated but not online
Reception of any authenticated application layer response from a device is enough to mark it
as online.
 Not Authenticated
Device is marked online after a successful three-way handshaking.
2.6.2. Mark Offline
If for six consecutive telemetry requests, no response is received or response packet hash validation is
failed, node is marked offline. Depending upon the commands scheduled in FIFO and number of units in the
network the offline marking time will differ.

For a 10 units per phase network, the worst-case time to mark a unit offline is around 2 Sec.
One complete cycle of Units = 60 Passes = 300 mSec
6 complete cycles of Units = 6 * 300 mSec ~ 2 Sec

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2.7. Interphase Balancing (IPB) Communication Protocol

Interphase packets are shared with devices within a group. A group is a set of three Smart Valve devices
connected on each phase. In Figure 1 for example A1, B1 and C1 form a group, A2, B2 and C2 form another
group, and so on. A maximum of 30 devices can be connected in a network, therefore, maximum 10 groups
can be formed. If one device from within a group fails to remain in injection mode due to any external or
internal fault and goes in bypass/monitoring mode, it needs to inform the other two devices in the group so
that they can also stop injecting. If this is not done the phases will become unbalanced. This feature requires
real-time communication between the devices within a group where each device needs to communicate with
the other two to confirm its current mode of operation (injection or monitoring). These devices communicate
through PLC. PLC requests data from nodes and sends this data back to the group.
2.7.1. Packet Type List
There are two types of packets for IPB communication as:
1. Interphase Request Packet, sent from PLC to devices.
2. Interphase Response Packet, sent to PLC from device.
2.7.2. Interphase Request Packet
In each slot two interphase request packets are scheduled from PLC if number of configured groups are
more than 1. If configured group is 1 then just 1 interphase packet will be sent in each slot. Interphase request
packet contains 80-byte packet header. Interphase header field is described in figure 2-15. After the interphase
request header, packet contains 1350 bytes of payload belonging to three phases (450 bytes each phase) of
the group pointed by field “Data Group” in the header. Therefore, in MAC header field, the MAC payload
length is 80+(3*450) = 1430 bytes.

Figure 2-20 Interphase Request Packet

Figure 2-21 Interphase Request Packet Header

1. Protocol Version – It is the header protocol version, currently set as 1.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2. Header Length – This field marks the header length. It is also the index at which the payload starts. It has
a fixed value i.e. 80 bytes.
3. Command Type – In case of Interphase packets, currently only one command type is available i.e. Bulk
data request command.
4. Requested Group – It represents the group for which data is requested.
5. Data group – It represents the group whose data is being shared in the payload. In first slot, when no
previous data has been gathered yet, this field is set as 0xFF.
As interphase packet is a broadcast packet so the information of “Data Group” is received by every other
group. Only the group mentioned in ‘Data group field’ will process this packet. Similarly, only “Requested
Group” sends response in return though all groups receive packet.
6. Payload Length – This two-byte field represents the length of attached payload. It is a fixed value i.e. 450
bytes. It is the maximum supported IPB payload length. Currently, only 60 bytes are populated out of
450. Rest of the bytes are set as zero.
7. Configured Group – Total configured groups count is sent in packet in this field. At device end, it is used
for calculating the communication break timeout value.
8. Schedule Time – This is the slot time of schedular. Currently set as 5ms. This value also plays role in
calculating the communication break timeout value.
9. ASN – This field contains the absolute slot number. It is used to keep check of slot in which packet is
received.
10. Data Sync – Data sync is 20 bytes data calculated at PLC using bypass telemetry parameters. It contains
group specific parameters including number of phases, bypass count, cnv. count etc. This field is used by
nodes for syncing purpose.
11. Reserved – These 42 bytes are reserved for future modifications.
12. Interphase Request Hash – Last 4 bytes of interphase request packet header contain the hash which is
calculated over the first 76 bytes of the interphase request packet header. Network group key is used to
calculate this hash.
2.7.3. Interphase Request Packet Security
Header hash and Payload hash, appended at the end of header and payload respectively, are used to check
packet corruption. All three devices with group ID as that of ‘data group’ field in request packet header will
process this packet. When interphase request packet is received by the node it verifies the following before
processing the packet:
 MAC header hash
 Interphase request header hash
 Interphase request payload hash of other two phases’ device data.

2.7.4. Interphase Response Packet

In response to interphase request packet each node of the requested group replies with packet having the 60
bytes of interphase response.

Figure 2-22 Interphase Response Packet

1. Protocol Version – Interphase protocol version is set as 2.
2. Header Length – It is the length of the header. Currently header length is 8.
3. ASN – It is same as that of IPB request packet header. Nodes copy PLC ASN in this field It is the same as
that of request packet ASN.
4. Group ID – It contains the group id of the sending device. A unique group ID is assigned to all 10 groups in
network.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

5. Phase ID – All groups have three devices each on three phases. Each node appends its own phase ID in
this field.
6. Payload – A 48-byte payload is appended in the response packet. This field is the actual data needed to
keep phase balance.
7. Interphase Response Hash – Packet contains 4-byte hash value at the end of the packet. It is
cumulatively calculated over header and payload. Every unit uses interphase seed key to calculate packet
hash. Hash is essential to mark packet authenticity.

2.7.5. IPB Response Packet Security

Last 4 bytes of interphase response packet contain the hash which is calculated over the first 56 bytes of the
interphase response packet.
When interphase response packet is received on the PLC, it verifies the following:
 Valid MAC hash

Interphase response hash is not verified at this step and packet is copied as it is. The packet is sent in
interphase request packet as a part of payload. Interphase response hash is only processed and verified at the
node.
2.7.6. IPB Packet scheduling
IPB packets contain data that needs to be shared between three devices of a group. This sharing of data is
possible through PLC. PLC requests data from all three devices of a group and share it back to the same group
in next slot. This packet contains data of all three devices. Devices, on reception, copy and process the data of
other two devices and drop its own data from packet.
1. Interphase packets from PLC request data from a group whose group ID is specified in ‘Requested Group
Field’ of the packet header. Devices match their own group id with this field and send their data in
response. Three response packets from each phase of a group will be received by PLC in the same slot.
2. This received data of all three nodes of a group will be sent back to the group in following slot. PLC
appends this data in the request command as payload. Thus, payload field of request command contains
data of three nodes with payload size three times of data of one node.
3. The group whose data is present in payload is marked in request packet header. The group ID mentioned
in ‘Data Group’ field of request packet header in following slot is same as that of the ‘Requested Group’
field of previous slot’s request packet header. If no data has been collected yet, in case of first
interphase request packet, data group field is set 0xFF and data field is set as zero.
4. Interphase request packet is sent as broadcast i.e. 0xFF…FF, therefore, all devices connected in network
receive the packet. Data group and Requested group fields in packet header help devices decide
whether to send response, process the packet or discard it.
5. Two request type packets for IPB are sent by PLC in one slot. In response to these two packets, six
devices respond to share their data and six devices receive data of their group members.
6. When devices receive request packet, if their group id matches the data group id, devices only copy the
data of other two phases’ devices. Devices further process the data for phase balance.
7. PLC also sends data to devices for synchronization of phase currents. This data is calculated using device
telemetry parameters and appended in request packet header.

2.7.7. Request Time of Interphase Commands

Interphase packet is always broadcasted so that packet is shared with both data group and requested
group.
A Maximum of 10 groups is supported. In each 5 ms slot, information of 2 groups is shared. Hence, it will take
5 passes to share the IPB information within all group in the ring i.e. 5 slot passes x 5 milliseconds = 25ms.
In similar manner, information of 2 groups is requested in one slot. It will also take 5 slot passes to gather data
of all ten groups. Gather data time for whole network equals 25ms.
Since gathering and sharing is performed by same packet. Collectively it takes only 25ms to perform both
operations.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2.7.8. IPB Packet Validation

IPB communication needs to be error-free for the protection of network from irregular behaviors. This is
achieved by implementing security on packets. In this protocol, packet security is verified at the device end.
Security checking goes as:
1. PLC requests data from devices. IPB request packet is described in Figure 2-15. Devices, on reception,
validate the packet before processing. This packet after initial validation further undergoes security checks
in case of data processing.
2. Initial Validation:
a) Header parameters with fixed values such as protocol version, header length and command type are
verified (see Figure 2-16). In addition, payload length should not be zero.
b) Packet will proceed validation process if it is targeted for this group. To verify, device’s group id
should match with either of the requested or data group id.
c) MAC Hash is verified.
d) IPB header hash is validated. Network group key is used to validate this hash.
e) This process confirms the accuracy of packet. Now, Packet is sent for processing.
3. If the device is requested group, it simply copies the ASN received in request packet to response packet
along with its data. No further authentication is checked.
4. If device is data group, packet processing needs to take place. In order to copy packet data with accurate
values, further verification is performed on the payload field.
5. This payload field is exact copy of the packet sent by same group’s devices in previous slot. PLC on
reception of response packet does not perform security checking but sends back the packet as payload in
request packet. This payload is verified on the device end.
6. Payload Validation:
a. Protocol version, header length, group id, phase id is verified. See Figure 2-17 for details.
b. Now, packet hash appended at the end of response packet is validated for any data corruption.
Interphase seed key is used to validate hash.
c. In the end, packet ASN is checked. ASN should not be older than previous slot.
7. Each phase device leaves behind its own data and processes data of other two phases only.
8. Here, validation process is successful, and data is now processed for syncing and phase balancing.
2.7.8.1. IPB Peer Offline/Online status:
Gateway keeps check of IPB communication over the three phases of a group. Whenever there is a
communication break for a specific error cycle, devices transmit this peer comm error status to gateway
through PLC. Communication break error cycles are configurable from gateway.
2.7.8.2. Peer Offline
1. Devices calculate the timeout value based on the error cycle value and the maximum time in which data of
all configured groups can be collected.
2. This maximum time value is calculated using the configured group count and scheduling time value
received in request data packet.
3. If last received packet time of any peer device exceeds more than this calculated timeout value, phase
communication error is set for this peer device.
4. This error status is communicated to gateway through PLC.
2.7.8.3. Peer Online
5. Now, when peer device again joins communication and node starts receiving its data, node does not mark
it online until the stable communication time threshold has reached without any packet loss. This stable
comm time is the time of 5000 slots i.e.
5000 slots * 5 ms = 25ms
2.7.9. IPB Regrouping
Whenever a SmartValve unit or units in a network stop responding or respond after long time, regrouping
for all devices is triggered on PLC. Regrouping is the operation in which non-responsive device is deleted from
network resulting in changed group IDs for devices. Similarly, when a node comes online after so long that
regrouping has been performed once, regrouping command is sent for this particular node.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

1. Gateway sends group IDs and node IDs of groups to PLC. This information is according to the SI
configuration. On the other hand, all nodes continuously send their group IDs to PLC in their telemetry
data.
2. PLC uses this information to compare gateway information with each node’s group ID. Whenever a
mismatch in both group IDs is detected, regrouping command is triggered on PLC.

2.7.9.1. Regrouping command scheduling

1. IPB Regrouping command is sent as APDU other command. First, a broadcast is sent to all active nodes. No
response is received for broadcast command.
2. In the following APDU slot pass/es, PLC sends unicast command/s for active device/es mentioned in
selected IDs list. One command packet will be sent in one APDU pass slot.
3. PLC targets one device at a time sending commands to all active devices. This command contains new
group id for each node. This new configuration of groups is received from gateway.
4. On reception, devices change their group ids on run time to newly received group ids after successful
packet validation process.
5. In response to this unicast packet, all nodes will respond with acknowledgment.
6. Keeping in mind alternate telemetry pass and single broadcast command, it will take ((1 + number of
active nodes) * 2) passes for whole command to complete.
7. This whole process has now changed the grouping of devices. From now on, IPB communication between
PLC and nodes will take place with these newly assigned group IDs.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

3. Cyber Security
2.8. Fibre-Optic Network Security
The Smart Wires Fibre-Optic Network relies on two security mechanisms. To ensure integrity of these
messages, they will be protected by a keyed HMAC, based on a group key. Any node receiving a secured
message which cannot be validated will drop the message. This type of security is implemented at the MAC
layer.

To ensure end-to-end protection, the application layer messages between the PowerLine Coordinator
and the node are also protected by a keyed HMAC. End-to-end security uses a unique key negotiated between
the particular node and the PowerLine Coordinator. For broadcast application layer commands group key is
used for End-to-end security.

2.8.1. Initial handshaking

The PowerLine Coordinator and the nodes will be seeded from the factory. The seeding process will involve
preplacing an initial set of secret material which can be used to authenticate the device and establish an initial
trust relationship between the device and the PowerLine Coordinator. Specifically, during the manufacturing
process devices will be given a unique 16-byte cryptographically random value. When devices are placed in the
field, the seed values will be used to facilitate authentication. The seed values of all SmartValve devices that
are assigned to a PowerLine Coordinator will be communicated to it by the gateway before the network is
formed.
1. As part of the network joining procedure, the PowerLine Coordinator will periodically unicast an
authentication challenge. This authentication challenge contains a nonce (NonceNC). This nonce will
be a combination of the network’s absolute slot number at the time of the authentication challenge,
and a twelve-byte random value, resulting in a sixteen-byte challenge. This message is unprotected,
as a security relationship has not yet been established between the nodes and the PowerLine
Coordinator.
2. When a node receives a nonce, it must evaluate the timeliness of the ASN component of the nonce.
(Not implemented yet)
3. Each node receiving the challenge, that sees its name in the NMEM list but does not yet have a valid
pair of cryptographic keys, will respond with its own nonce (NonceD) and an authentication value.
This will be sent out in the variable length cryptographic block of the NJR message as step 0. The
authentication value is generated using HMAC-SHA-256, as per RFC 4868. The authentication value is
calculated over the concatenation of the PowerLine Coordinator’s MAC Address, the Node’s MAC
Address, NonceNC, and NonceD using the node’s preplaced seed material. The authenticator protects
this message; however, the security bit is not set on this message, or the subsequent messages in the
authentication process, as these messages do not use the normal security mechanism. The PowerLine
Coordinator will calculate the authentication value for each response and compare it with the value
received from each SmartValve. If the values match, the node has demonstrated it has possession of

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

the appropriate seed key, and thus the system can be assured of its identity. The PowerLine
Coordinator will mark that node as authenticated in its internal security table.
4. PLC will then send the node a keying message. The PowerLine Coordinator will generate and share
the new 16-byte random key for the SmartValve, along with the group key for the network and
interphase group key. To securely transfer the key material, the PowerLine Coordinator will encrypt
the material, using AES-CTR mode. The IV for the AES-CTR algorithm is the current 4-byte ASN
repeated twice. The ASN is also transmitted inside the packet. The Key for the AES-CTR algorithm is
the HMAC of NonceNC and NonceD using the seed of the SmartValve. This information is sent to the
SmartValve, along with an authenticator. The information will travel in the Cryptography block of the
Network Join message with step set to one.
5. Upon receiving this message, the Node will respond by sending back an acknowledgement consisting
of the original nonce sent in the first challenge (NonceNC), authenticated with the new SmartValve
key it received in the last step. The PowerLine Coordinator will validate that the NonceNC matches
the one originally sent, and that the authenticator is correct. This confirms to the PowerLine
Coordinator that the device in question has successfully received the new keys. The information will
travel in the Network Join message step 2 packet.
The cryptographic message exchange is as follows:
Challenge(PLC → SmartBypass): NonceNC
where NonceNC=Concatenate(ASN of Challenge Message, 12 cryptographically random bytes)
Response(PLC ← SmartBypass): NonceD, Authenticator
where NonceD=Concatenate(ASN of Response Message, 12 cryptographically random bytes)
Authenticator=HMAC(Concatenate(MAC AddressNC, MAC AddressD, NonceNC, NonceD), Seed)

Keying(PLC → SmartBypass): Encypt(IV,Key) (KeyMaterial), ASN of message, Authenticator

where IV = Concatenate(ASN of Keying Message, ASN of Keying Message)
Key = Truncate(HMAC(Concatenate(NonceNC, NonceD), Seed),16)
KeyMaterial=Concatenate(GroupKey, PLGKey, Interphase Key)
Authenticator=HMAC(Concatenate(MAC AddressNC, MAC AddressD, EncryptedKeyMaterial), Seed)

Acknowledgment(PLC ← SmartBypass):NonceNC, Authenticator

where NonceNC is original NonceNC provided by PowerLine Coordinator
Authenticator=HMAC(Concatenate(MAC AddressNC, MAC AddressD, NonceNC), PLGKey)
The state diagram below shows the process and the different states that the PowerLine Coordinator might
track for the SmartBypass devices on its network:

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

Uninitialized Loaded
[GW Pushes Node List to NC]

Initial

[GW pushes level assignments to NC]

[NC sends NMEM & Challenge

Assigned Challenged
(NonceNC)]

[Node fails to respond]

[Node responds with NonceD]

Authenticated
[Node fails to acknowledge key]

[NC sends key to Node]

Keyed

[Node acknowledges key]

Joined

Figure 3-23: Device Initialization and Authentication

Note: that the authentication process cannot begin until the seeds for the SmartValve devices have been
loaded into the PowerLine Coordinator from Gateway.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

2.8.2. Message Authentication

MAC Hash of packets is calculated with network key. It is calculated only over the MAC header of the packet.
Application Hash is calculated over the Application layer payload. For unicast packets, application hash is
calculated based on private key. Whereas for broadcast application layer packets network key-based hash is
used.

Packet Type Packet MAC Header Hash Application Hash

Challenge X X

Network Layer NJR X X

Network
X X
Membership
Unicast 🗸 🗸 (Private Key)
Application Layer Packet

Broadcast 🗸 (Network Key)

🗸
Packet
🗸 (Header with Network
Key) *
Request
🗸 🗸 (Payload with
Interphase Packet Packet
Interphase Group Key)

Response 🗸 (Interphase group Key)

🗸
Packet **

Fault Packet 🗸 X***

Table 3-1
* Devices validate the Interphase request header hash with network key. Whereas the 60 bytes
payload of each device is validated with the interphase group key.
** PLC does not validate the IPB response Payload hash due to timing constraints. Only MAC header
hash is validated and data is buffered. The IPB packet payload hash is validate by the group devices.
*** There is no application layer payload in Fault packet type.

© 2022 Smart Wires | www.smartwires.com

PowerLine Coordinator V2.0 Firmware Requirements Specifications
Revision: 1.1

4. References

© 2022 Smart Wires | www.smartwires.com