EN 50090-4-2:2004

SLOVENSKI SIST EN 50090-4-2:2005

STANDARD
september 2005
Stanovanjski in stavbni elektronski sistemi (HBES) – 4-2. del: Nivoji,
neodvisni od medijev – Transportni nivo, mrežni nivo in splošni deli nivoja za
prenos podatkov za HBES razreda 1
Home and Building Electronic Systems (HBES) – Part 4-2: Media independent
layers – Transport layer, network layer and general parts of data link layer for HBES
Class 1
ICS 97.120 Referenčna številka
©  Standard je založil in izdal Slovenski inštitut za standardizacijo. Razmnoževanje ali kopiranje celote ali delov tega dokumenta ni dovoljeno

EUROPEAN STANDARD EN 50090-4-2
NORME EUROPÉENNE
EUROPÄISCHE NORM February 2004

ICS 35.100.05; 97.120 Supersedes R205-008:1996

English version
Home and Building Electronic Systems (HBES)
Part 4-2: Media independent layers -
Transport layer, network layer and general parts
of data link layer for HBES Class 1

Systèmes électroniques pour les foyers Elektrische Systemtechnik für Heim
domestiques et les bâtiments (HBES) und Gebäude (ESHG)
Partie 4-2: Couches indépendantes Teil 4-2: Medienunabhängige Schicht -
des media - Transportschicht, Vermittlungsschicht
Couches transport, réseau und allgemeine Teile
et parties générales de la couche der Sicherungsschicht für ESHG Klasse 1
données pour HBES Classe 1
This European Standard was approved by CENELEC on 2003-12-02. CENELEC members are bound to
comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in one official version (English). A version in any other language made by
translation under the responsibility of a CENELEC member into its own language and notified to the Central
Secretariat has the same status as the official version.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden,
Switzerland and United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

© 2004 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.

Ref. No. EN 50090-4-2:2004 E
Contents
Foreword .3
Introduction.4
1 Scope.4
2 Normative references.4
3 Terms, definitions and abbreviations .4
3.1 Terms and definitions.4
3.2 Abbreviations.5
4 Requirements for the physical layer and independent data link layer .6
4.1 Functions of the data link layer.6
4.2 Possible media and their impact on Layer-2 .7
4.3 Data link layer services .7
4.4 Data link layer protocol .16
4.5 Parameters of Layer-2.16
4.6 Specific devices .17
5 Requirements for the network layer .17
5.1 Functions of the network layer.17
5.2 Network layer services and protocol .19
5.3 Parameters of the network layer.25
5.4 Network layer state machines.25
6 Requirements for the transport layer.29
6.1 Functionality of the transport layer .29
6.2 Transport layer Protocol Data Unit (TPDU).30
6.3 Overview communication modes .30
6.4 Transport layer services.32
6.5 Parameters of transport layer .41
6.6 State machine of connection-oriented communication mode.42
Annex A (informative) Examples of transport layer connection oriented
state machine state diagrams .54
A.1 Connect and disconnect .54
A.2 Reception of data .57
A.3 Transmission of data .59
Figure 1 – Individual address .5
Figure 2 – Group address .5
Figure 3 – Interaction of the data link layer .7
Figure 4 – Exchange of primitives for the L_Data-Service .8
Figure 5 – Frame_format Parameter .11
Figure 6 – Coding of Extended Frame Format.12
Figure 7 – Interaction of the network layer (not for Bridges or Routers).18
Figure 8 – General functionality of a router or a bridge .18
Figure 9 – Format of the NPDU (example) .19
Figure 10 – Interaction of the transport layer.29
Figure 11 – Format of the TPDU (example).30
Figure 12 – Transport control field .30
Table 1 – Usage of priority .10
Table 2 – Actions of the connection oriented state machine .44
Table 3 – Transition table – Style 1.46
Table 4 – Transition table – Style 1-rationalized.48
Table 5 – Transition table – Style 2.50
Table 6 – Transition table – Style 3.52

– 3 – EN 50090-4-2:2004
Foreword
This European Standard was prepared by the Technical Committee CENELEC TC 205, Home and
Building Electronic Systems (HBES) with the help of CENELEC co-operation partner Konnex Association
(formerly EHBESA).
The text of the draft was submitted to the Unique Acceptance Procedure and was approved by CENELEC
as EN 50090-4-2 on 2003-12-02.
This European Standard supersedes R205-008:1996.
CENELEC takes no position concerning the evidence, validity and scope of patent rights.
Konnex Association as Cooperating Partner to CENELEC confirms that to the extent that the standard
contains patents and like rights, the Konnex Association's members are willing to negotiate licenses
thereof with applicants throughout the world on fair, reasonable and non-discriminatory terms and
conditions.
Konnex Association Tel.: + 32 2 775 85 90
Neerveldstraat, 105 Fax.: + 32 2 675 50 28
Twin House e-mail: info@konnex.org
B - 1200 Brussels www.konnex.org
Attention is drawn to the possibility that some of the elements of this standard may be the subject of
patent rights other than those identified above. CENELEC shall not be held responsible for identifying any
or all such patent rights.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2004-12-01
– latest date by which the national standards conflicting 2006-12-01
with the EN have to be withdrawn (dow)
EN 50090-4-2 is part of the EN 50090 series of European Standards, which will comprise the following
parts:
Part 1: Standardisation structure
Part 2: System overview
Part 3: Aspects of application
Part 4: Media independent layers
Part 5: Media and media dependent layers
Part 6: Interfaces
Part 7: System management
Part 8: Conformity assessment of products
Part 9: Installation requirements

Introduction
This standard specifies the Media independent requirements for the data link layer and the requirements
for the network layer and the transport layer for Home and Building Electronic Systems.
This standard provides the communication stack targeted for providing the services specified in
EN 50090-3-2 “User Process” and EN 50090-4-1 “Application Layer for HBES Class 1”. It can be used as
communication stack on the physical layers as specified in EN 50090-5.
1 Scope
This part of the EN 50090 specifies the services and protocol in a physical layer independent way for the
data link layer and for the network layer and the transport layer for usage in Home and Building Electronic
Systems
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
1)
EN 50090-1 Home and Building Electronic Systems (HBES) –
Part 1: Standardisation structure
EN 50090-3-2:2004 Home and Building Electronic Systems (HBES) –
Part 3-2: Aspects of application – User process for HBES Class 1
Home and Building Electronic Systems (HBES) –
EN 50090-4-1:2004
Part 4-1: Media independent layers – Application layer for HBES Class 1
EN 50090-5 series Home and Building Electronic Systems (HBES) –
Part 5: Media and media dependent layers
ISO 7498 series Information technology - Open Systems Interconnection - Basic reference model
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this part the terms and definitions given in EN 50090-1 and the following apply.
3.1.1
individual address
IA
unique identifier for every device in a network. The individual address is a 2-octet value that consists of
an 8-bit subnetwork address and an 8-bit device address
———————
1)
At draft stage.
– 5 – EN 50090-4-2:2004
3.1.2
sub network address
SNA
part of the individual address, consists of a 4-bit line address and a 4-bit area address, that specifies the
subnetwork in which the device is mounted
3.1.3
area address
part of the individual address that specifies the area in which the device is mounted
3.1.4
line address
part of the individual address that specifies the line in which the device is mounted
3.1.5
device address
unique identifier for every device in a subnetwork. The device address is an 8-bit value
NOTE Figure 1 shows the relationship between individual address, subnetwork address, area address, line address and device
address.
Individual Address
Octet 0 Octet 1
7 6 5 4 3 210 765 432 10
Area Line
Address Address
Device Address
Subnetwork Address
Figure 1 – Individual address
3.1.6
group address
GA
a 2-octet value
Group Address
Octet 0 Octet 1
7 6 5 432 107 654 321 0
Main Group Sub Group
Figure 2 – Group address
3.1.7
datagram
full sequence of elements (physical symbols) transporting a frame on the physical medium
3.1.8
frame
sequence of octets exchanged between data link layers through the physical layer

3.2 Abbreviations
ack Acknowledge
APDU Application layer Protocol Data Unit
con confirmation
GA Group Address
HBES Class 1 refers to simple control and command.
HBES Class 2 refers to Class 1 plus simple voice and stable picture transmission
HBES Class 3 refers to Class 2 plus complex video transfers
IA Individual Address
ind indication
iack Immediate Acknowledge
LPDU Link layer Protocol Data Unit
LSDU Link layer Service Data Unit
nack Negative Acknowledge
NPDU Network layer Protocol Data Unit
NSDU Network layer Service Data Unit
PDU Protocol Data Unit
req request
SNA Sub-Network Address
TSAP Transport layer Service Access Point
TPDU Transport layer Protocol Data Unit
UART Universal Asynchronous Receiver Transmitter

4 Requirements for the physical layer and independent data link layer
4.1 Functions of the data link layer
The data link layer (also called "Layer-2") is the layer between the data link layer user and the physical
layer. The data link layer conforms to the definitions of the ISO/OSI model (ISO 7498) data link layer. It
provides medium access control and logical link control.
The data link layer is concerned with reliable transport of single frames between two or more devices on
the same subnetwork.
When transmitting it is responsible for
- building up a complete frame from the information passed to it by the network layer,
- gaining access to the medium according to the particular medium access protocol in use,
and
- transmitting the frame to the data link layer in the peer entity or entities, using the
services of the physical layer.
If the transmission fails, the transmitting data link layer may decide to try again after a certain interval. In
particular, if the remote device signals that its buffers are temporarily full, the data link layer will wait for a
pre-determined time and then attempt to re-transmit the frame (flow control).
When receiving, data link layer is responsible for
- determining whether the frame is intact or corrupted,
- deciding after destination address check to pass the frame to upper layers, and
- issuing positive or negative acknowledgements back to the transmitting data link layer.

– 7 – EN 50090-4-2:2004
The data link layer shall provide some means to prevent from service duplication (in case of repetitions
because of corrupted acknowledgement frames).
The services provided include individual, group and broadcast addressing options.
The data link layer uses the services of the physical layer and provides services to the data link layer user
(see Figure 3).
Local Layer-2 Management Local Layer-2 User Remote Layer-2 User Remote Layer-2
Management
L_Poll_Data.con
L_Data.ind
L_Data.req L_Data.con
L_Busmon.ind
L_ServiceInfo.ind
L_SystemBroadcast.ind
L_SystemBroadcast.req
L_SystemBroadcast.con
L_Poll_Data.req
L_Poll_Data_Update.req/con
Data Link Layer Data Link Layer
local L-2 services
poll data service data service data service poll data service
L_PDU
Figure 3 – Interaction of the data link layer
4.2 Possible media and their impact on Layer-2
The data link layer is defined for the following media:
Twisted Pair 0;
Twisted Pair 1;
Powerline 110;
Powerline 132;
Radio Frequency.
Data link layer will also be defined for the following media:
Infra-red;
Ethernet.
The data link layer is open for new media in the future.
Each medium needs a dedicated medium access control and a logical link control that adapts to the
medium access control. This clause focuses on medium independent features, this is, mainly on the
provided service interface to network layer.
The physical layer dependent requirements are specified in EN 50090-5.
4.3 Data link layer services
4.3.1 Data link layer modes
The data link layer mode defines which data link layer services shall be available to the data link layer
user. There shall be 2 data link layer modes:
a) the normal mode;
b) the busmonitor mode.
In normal mode the remote L_Data service, the remote L_SystemBroadcast service, the remote
L_Poll_Data service and the local L_Service_Information service shall be available to the data link layer
user. In busmonitor mode only the local L_Busmon service shall be available. The data link layer mode is
a parameter of Layer-2.
The frame effectively sent on the physical medium Link layer Protocol Data Unit (LPDU) is medium
dependent. Therefore it is described in EN 50090-5.
4.3.2 L_Data service
4.3.2.1 General
The L_Data service is a frame transfer service. It transmits a single Link layer Service Data Unit (LSDU)
to data link layer of one or several devices connected to the same subnetwork. The destination address
may be an individual address or a group address (multicast or broadcast). The service is acknowledged
or not, depending on the quality of service requested.
There shall be three service primitives:
a) L_Data.Req shall be used to transmit a frame;
b) L_Data.Ind shall be used to receive a frame;
c) L_Data.Con shall be used as a local primitive generated by the local Layer-2 for its
own client to indicate that it is satisfied with the transmission.
Originating User Service Provider Remote User
Request
Confirm  Indication
Figure 4 – Exchange of primitives for the L_Data-Service
If the local user of Layer-2 prepares an LSDU for the remote user it shall apply the L_Data.req primitive to
pass the LSDU to the local Layer-2. The local Layer-2 shall accept the service request and try to send the
LSDU to the remote Layer-2 with the relevant frame format.
The local Layer-2 shall pass an L_Data.con primitive to the local user that indicates either a correct or
erroneous data transfer. Depending if an L2-acknowledgement is requested or not, this confirmation is
related to the reception of the L2-acknowledgement, or only to the transmission of the frame on the
medium.
– 9 – EN 50090-4-2:2004
L_Data.req(source_address, destination_address, address_type, priority, octet_count, ack_request,
frame_format, lsdu)
source_address this parameter shall be used to indicate the source address of the requested
frame; it shall be the individual address of the device that requests the service
primitive
destination_address: this parameter shall be used to indicate the destination address of the requested
frame; it shall be either an individual address or a group address
address_type: this parameter shall be used to indicate whether the destination_address of the
requested frame is an individual address or a group address
priority: this parameter shall be used to indicate the priority that shall be used to the
transmit the requested frame; it shall be “system”, “urgent”, “normal” or “low”
octet_count: this parameter shall be used to indicate the length information of the requested
frame
ack_request: this parameter shall be used to indicate whether a Layer-2 acknowledge is
mandatory or optional
frame_format: standard or extended frame format
lsdu: this parameter shall be used to contain the user data to be transferred by Layer-2

L_Data.con(destination_address, address_type, priority, frame_format, lsdu, l_status)
destination_address: this parameter shall be used to indicate the destination address of the transmitted
frame; it shall be either an individual address or a group address
address_type: this parameter shall be used to indicate whether the destination_address of the
transmitted frame is an individual address or a group address
priority: this parameter shall be used to indicate the priority that has been used to transmit
the transmitted frame; it shall be “system”, “urgent”, “normal” or “low”
lsdu: this parameter shall be used to indicate the length information of the transmitted
frame
frame_format: standard or extended frame format
l_status: ok: this value of this parameter shall be used to indicate that the transmission of the
frame has been successful
not_ok: this value of this parameter shall be used to indicate that the transmission of the
frame did not succeed
L_Data.ind(source_address, destination_address, address_type, priority, ack_request, octet_count,
frame_format, lsdu)
source_address: this parameter shall be used to indicate the source address of the received frame;
it shall be the individual address of the device that has transmitted the service
primitive
destination_address: this parameter shall be used to indicate the destination address of the received
frame; it shall be either an individual address or a group address
address_type: this parameter shall be used to indicate whether the destination_address of the
received frame is an individual address or a group address
priority: this parameter shall be used to indicate the priority of the received frame; it shall
be “system”, “urgent”, “normal” or “low”
ack_request: this parameter shall be used to indicate whether a Layer-2 acknowledge is
mandatory or optional
octet_count: this parameter shall be used to indicate the length information of the received
frame
frame_format: standard or extended frame format
lsdu: this parameter shall be used to contain the user data that has been received by
Layer-2
4.3.2.2 Usage of priority
Table 1 – Usage of priority
Priority Priority Usage
value
11 low shall be used for long frames, burst traffic,
01 normal shall be used as the default for short frames
10 urgent shall be used exclusively for urgent frames
00 system shall be used for high priority, system
configuration and management procedures

The usage conditions for these priorities are specified in EN 50090–4-1.
In a network, the frame traffic using urgent priority shall not exceed 5 % of the total traffic (integration
period: 1 minute maximum).
4.3.2.3 Octet count
This service parameter shall contain the number of octets of the transported Application layer Protocol
Data Unit (APDU).
The Octet Count parameter shall be used on each medium to encode the LPDU length field as follows:
- for standard frames, the length field shall contain the number of octets in the APDU coded in 4 Bit,
- for extended frames, the length field shall contain the number of octets in the APDU coded in 8 Bit
except the value FFh. The value FFh (255) is used as an escape-code.

– 11 – EN 50090-4-2:2004
The escape-code (“ESC”) shall be available for future high speed media to enable larger lengths.
4.3.2.4 Ack_request
This service parameter shall be used to indicate whether a link layer acknowledge is requested or not.
4.3.2.5 Frame_format
This parameter shall be used to select the Standard or Extended Frame Format for Data Link Layer and
shall include information for the used extended frame type.
If the frame_format parameter is 0 the Standard Frame Format shall be used. If this parameter is different
from 0 it shall be used as the frame_format in the extended control field.
For the definition of the extended control field see the medium dependent layer description in
EN 50090-5.
Octet 3
7 6 5 4 3 2 1 0
FT = Frame type (0 = Standard, 1 = Extended)
(for standard the frame type bit in the control field is 1)
EFF = Frame Format in case of FT=1 = Extended Frame Format

FT 0 0 0 t t t t
0 0 0 0 0 0 0 0 Standard Frame Format Standard Group or Individual
1 0 0 0 0 0 0 0 Extended Frame Format Standard Group or Individual
1 0 0 0 0 1 x x LTE-HEE extended address type
All other codes are reserved for future use
Figure 5 – Frame_format Parameter
The Extended Frame Format from the frame_format parameter shall be placed in the extended control
field. The position of the extended frame type is medium dependent.
The decision whether to use Standard or Extended Frame Format shall be made in the Application Layer
and selected by the frame_format parameter in T_Data_. services. The remote Application Layer shall
be tolerant towards usage of long frames if short frames would be sufficient:
example: A_PropertyValue_Read-PDU shall fit into Standard (short) Frame Format. But if received using
Extended (long) Frame Format it shall be accepted anyway by the remote Application Layer and the
corresponding A_PropertyValue_Response-PDU shall be transported using the appropriate short or long
format.
Frame type
Extended
Frame Format
Extended Frame Format (EFF)
b b b b
3 2 1 0
CtrlE CtrlE CtrlE CtrlE Usage
3 2 1 0
Standard messages enabling long APDU > 15 octets
0 0 0 0 Standard usage of DA for peer to peer or group
messages
0 0 0 1 Reserved
0 0 1 0
0 0 1 1
0 1 X X LTE-HEE extended message format
CtrlE CtrlE containing extension of DA group address
1, 0
1 0 0 0 Reserved
1 0 0 1
1 0 1 0
1 0 1 1
1 1 0 0
1 1 0 1
1 1 1 0
1 1 1 1 Escape
Figure 6 – Coding of Extended Frame Format
The Extended Frame Format shall not be used instead of Standard Frame Format if encoding capabilities
of L_Data-Standard frame are sufficient (e.g. for short frames).
4.3.3 L_SystemBroadcast service
The L_SystemBroadcast service is a frame transfer service. It shall transmit a single link layer service
data unit (LSDU) to the data link layer of all devices within the network. The destination address shall be
the system broadcast address (Domain Address = 0000h and destination address = 0000h and
address_type = “multicast”). The service may acknowledged or not, depending on the transmission
medium.
There shall be three service primitives:
1. L_SystemBroadcast.req shall be used to transmit a frame;
2. L_SystemBroadcast.ind shall be used to receive a frame;
3. L_SystemBroadcast.con shall be a local primitive generated by the local Layer-2 for its own client to
indicate the success of the transmission.
If the local user of Layer-2 prepares a LSDU for the remote user it shall apply the L_SystemBroadcast.req
primitive to pass the LSDU to the local Layer-2. The local Layer-2 shall accept the service request and
shall try to send the LSDU to the remote Layer-2 with the relevant frame format.
The local Layer-2 shall pass a L_SystemBroadcast.con primitive to the local user that shall indicate either
a correct or erroneous data transfer. Depending if a L2-acknowledgement is requested or not, this
confirmation shall be related to the reception of the L2-acknowledgement, or only to the transmission of
the frame on the medium.
– 13 – EN 50090-4-2:2004
L_SystemBroadcast.req(destination_address, address_type, priority, octet_count, ack_request, lsdu)
destination_address: this parameter shall be used to indicate the destination address of the requested
frame; it shall be the system broadcast address 0000h
address_type: this parameter shall be set to “multicast”
priority: this parameter shall be used to indicate the priority that shall be used to the
transmit the requested frame; it shall be “system”, “urgent”, “normal” or “low”
octet_count: this parameter shall be used to indicate the length information of the requested
frame
ack_request: this parameter shall be used to indicate whether a Layer-2 acknowledge is
mandatory or optional
lsdu: this parameter shall be used to contain the user data to be transferred by Layer-2

L_SystemBroadcast.con(source_address, destination_address, address_type, priority, octet_count, lsdu,
l_status)
source_address this parameter shall be used to indicate the source address of the requested
frame; it shall be the individual address of the device that requests the service
primitive
destination_address: this parameter shall be used to indicate the destination address of the requested
frame; it shall be the system broadcast address 0000h
address_type: this parameter shall be set to “multicast”
priority: this parameter shall be used to indicate the priority that shall be used to the
transmit the requested frame; it shall be “system”, “urgent”, “normal” or “low”
octet_count: this parameter shall be used to indicate the length information of the requested
frame
ack_request: this parameter shall be used to indicate whether a Layer-2 acknowledge is
mandatory or optional
l_status: ok: this value of this parameter shall be used to indicate that the transmission of the
L_SystemBroadcast.req service has been successful
not_ok: this value of this parameter shall be used to indicate that the transmission of the
L_SystemBroadcast.req service did not succeed

L_SystemBroadcast.ind(source_address, destination_address, address_type, priority, ack_request,
octet_count, lsdu)
source_address: this parameter shall be used to indicate the source address of the received frame;
it shall be the individual address of the device that has transmitted the service
primitive
destination_address: this parameter shall be used to indicate the destination address of the received
frame; it shall be the system broadcast address 0000h
address_type: this parameter shall be set to “multicast”
priority: this parameter shall be used to indicate the priority of the received frame; it shall
be “system”, “urgent”, “normal” or “low”
ack_request: this parameter shall be used to indicate whether a Layer-2 acknowledge is
mandatory or optional
octet_count: this parameter shall be used to indicate the length information of the received
frame
lsdu: this parameter shall be used to contain the user data that has been received by
Layer-2
4.3.4 L_Poll_Data service and protocol
The L_Poll_Data service is a confirmed multicast service. The local user of Layer-2 shall use the
L_Poll_Data.req primitive to request data from one or more remote users. The local Layer-2 shall accept
the service request and try to send the L_Poll_Data.req to the remote Layer-2 with frame format 3. The
destination address shall always be a poll group address. The poll group address shall be a parameter of
Layer-2.
L_Poll_Data request frames that are not correctly received shall be discarded.
After receiving a correct L_Poll_Data request frame with a poll_group_address equal to its own poll group
addresses, the remote Layer-2 shall respond with a single Poll_Data character. The remote Layer-2 shall
obtain the Poll_Data octet from its user with the L_Poll_Update.req primitive. The Poll_Data character
shall be transmitted in the response slot associated with this device. The device’s response slot shall be a
defined time slot in which the Poll_Data slave device shall transmit the Poll_Data character. The duration
of a response slot shall be an idle time of 5 times followed by a single Universal Asynchronous Receiver
Transmitter (UART) character.
EXAMPLE If e.g. a device has the third response slot then the device has to wait for two Poll_Data
characters transmitted by other devices, until the device is transmitting its Poll_Data character in the third
response.
The response slot number shall be a parameter of Layer-2.
A device shall not respond if its response slot number is larger than the number of expected poll data
(nr_of_expected_poll_data) in the request frame.
The local Layer-2 shall expect a number of Poll_Data characters from the poll group. If an expected
Poll_Data character has not started after five bit times, the local Layer-2 shall send a FILL (FEh) after six
bit times. The remote Layer-2 can therefore still count Poll_Data characters even if a member of the poll
group doesn’t respond.
The local Layer-2 shall pass a L_Poll_Data.con primitive to the local user that contains the received
Poll_Data and FILL octets or an information that the service failed.

– 15 – EN 50090-4-2:2004
The L_Poll_Data Service can only be applied between devices on a single physical segment. The number
of expected Poll_Data characters is limited to 16.

L_Poll_Data.req(destination, nr_of_expected_poll_data)
destination: this parameter shall be used to indicate the destination address of the
requested frame; it shall be a poll group address
nr_of_expected_poll_data: this parameter shall be used to indicate the number of expected poll data
cycles
L_Poll_Data.con(l_status, poll_data_sequence)
l_status: ok: this value of this parameter shall be used to indicate that a valid
poll_data_sequence has been composed
not_ok: this value of this parameter shall be used to indicate that it was not possible to
compose a valid poll_data_sequence, i.e. collision occurred during transmission
of a FILL, or at least one Poll_Data not correct
poll_data_sequence: this parameter shall be used to contain the sequence of Poll_Data octets and
FILL octets
L_Poll_Update.req(Poll_Data)
Poll_Data: this parameter shall be used to contain the value of the Poll_Data octet that shall
be transmitted in the L_Poll_Data_Response frame

L_Poll_Update.con() Indicates that the L_Poll_Update.req has been accepted by the local Layer-2.

4.3.5 L_Busmon service
The L_Busmon service is a local Data Link service available only in busmonitor mode. It consists of the
L_Busmon.ind primitive that transfers each received frame from the local Layer-2 to the local Layer-2
user.
L_Busmon.ind(L_Status, time_stamp, lpdu)
L_Status: this parameter shall be used to contain information whether a frame error, bit
error or a parity error has been detected in the received frame. Additional
information about the number of already received frames may also be contained
time_stamp: this parameter shall be used to contain the time information of the time when the
first start bit of the frame has been received
lpdu: this parameter shall be used to contain all octets of the received frame

4.3.6 L_Service_Information service
The L_Service_Information service is a local Data Link service available in Data Link Normal Mode. It
consists of the L_Service_Information.ind primitive.

L_Service_Information.ind() this service primitive shall be used to indicate that a frame has been received
which contained the individual address of the local Layer-2 as source
address.
4.4 Data link layer protocol
4.4.1 Protocol
The data link layer shall offer a reliable frame transfer service between devices on the same subnetwork.
This means that corrupted frames shall be detected and retransmitted (i.e. repeated) for a number of
times and that only information of correctly received frames shall be presented to the data link layer user.
The maximum frame length that is supported may be adapted to the needs of a device.
Frames that are corrupted or that exceed the reception capacity of a device shall be discarded.
Some means may be provided to prevent from information duplication (i.e. that this information is not
presented several times to the data link layer user).
Most of these functions are done in a medium dependent way, as specified in EN 50090-5.
4.4.2 Recommendations for duplication prevention
Some means to prevent duplication are available on certain media. However, there is always a remaining
risk of duplication.
The following guidelines to handle this can be taken into account:
- noise at the medium should be reduced as much as necessary to avoid corrupted
acknowledgements;
- the medium, transmission method and transmitter and receiver technology shall provide
basic noise immunity (see the media descriptions in EN 50090-5);
- be aware, during internal or external user application programming, of the possibility that in
some cases a duplicated L_Data service may occur. This will be rare on media with collision
avoidance but far more common on media without collision prevention or detection or media
that are more noise sensitive;
- excessive use of the priority ‘urgent’ is not recommended on certain media.
4.5 Parameters of Layer-2
The following parameters influence the behaviour of Layer-2 and shall be implemented inside Layer-2 in
order to operate correctly:
– domain address: domain address of the network the device belongs to (on open
media);
– individual address: unique individual address of this device;

– 17 – EN 50090-4-2:2004
– group address table: table with the group address(es) of this device;
– nack_retry: defines the number of retries in case of a Negative AcKnowledge
(NACK) response or a acknowledgement time-out;
– busy_retry: defines the number of retries in case of a BUSY/FULL response;
– poll group address: the poll group address of this device;
– response slot number: the response slot number of this device (for polling mode);
– data link layer mode: either the normal mode or the busmonitor mode of the data link
layer.
4.6 Specific devices
4.6.1 The Layer-2 of a bridge
A bridge connects two segments of one single subnetwork.
NOTE The notion of bridge provides only limited interest: it is not able to correctly handle the L2-acknowledgement, without
detailed knowledge of the network.
A bridge shall forward frames and L2-Acknowledgements shall be sent on each side of the bridge
depending on the destination address: the bridge shall know which device addresses are used on each
2)
side of the bridge . All other Layer-2 services shall be ignored.
A bridge does not need to have an individual address. A bridge may have an individual address to allow
setting parameters.
4.6.2 The layer-2 of a router
A router is a device that interconnects a hierarchically higher subnetwork and a hierarchically lower
subnetwork.
The Layer-2 of a router shall respond to a correct L_Data.request frame on either one of the three
following conditions:
a) the value of the destination address is listed in the routing_table ();
b) the destination address is an individual address that indicates that the destination is on the
other side of the router;
c) the destination address is equal to the individual address of the router.
In these cases, the L_Data.ind service primitive shall be passed to the Layer-3. All other Layer-2 services
shall be ignored.
5 Requirements for the network layer
5.1 Functions of the network layer
The network layer (Layer-3) is the layer between the data link layer and the network layer user. This
network layer shall comply to the definitions of the ISO/OSI model (ISO 7498) network layer.
———————
2) Sending back an L2-Acknowledgement cannot be done by the devices through the bridge: delays will be
incompatible with the Layer-2 protocol on most media.
Systematic sending of L2-Acknowledgement and forwarding of frames through the bridge (i.e. as a repeater with
delay) would inhibit the L2-ack functionality. Mechanisms relying on this function to check addresses available
would be fooled. That is why such bridges are not allowed.

The network layer shall use the L_Data and the L_SystemBroadcast service of the Data link layer and
shall provide N_Data_Individual, N_Data_Group, N_Data_Broadcast and N_Data_SystemBroadcast
services to the network layer User, see Figure 7.
Local Layer-3 User Remote Layer-3 User

N_Data_Individual.req N_Data_Individual.con N_Data_Individual.ind
N_Data_Group.ind
N_Data_Group.req N_Data_Group.con
N_Data_Broadcast.ind
N_Data_Broadcast.con
N_Data_Broadcast.req
N_Data_SystemBroadcast.ind
N_Data_SystemBroadcast.req N_Data_SystemBroadcast.con
NPDU
Network Layer Network Layer
L_Data.req L_Data.con L_SystemBroadcast.req L_SystemBroadcast.con L_Data.ind L_SystemBroadcast.ind

Figure 7 – Interaction of the network layer
(not for Bridges or Routers)
Filter Algorithm
N_Data_Group.req
N_Data_Group.ind
Individual Address
N_Data_Individual.req
N_Data_Individual.ind
N_Data_Broadcast.req
Network Layer Network Layer
N_Data_Broadcast.ind
L_Data.ind
L_Data.Req
L_Data.con
Data Link Layer Data Link Layer
........
........
Figure 8 – General functionality of a router or a bridge
Communication across subnetworks with filter characteristics shall use devices called routers, as
specified in 5.4.4. Routers are devices that allow to couple two link layer protocol instances together,
which are connected to different subnetworks. For routing frames from one subnetwork to the other the
router shall use a filter algorithm. Furthermore a router shall remove misrouted messages so that they
cannot flood the network. All the filter algorithms of a network together define the allowed communication
paths between any two devices.
Communication across subnetworks without filter characteristics needs devices called bridges, see also
Figure 8. Like a router a bridge allows to couple two Data link layer protocol instances together, which are
connected to different subnetworks. But a bridge shall not have the filter property of a router and therefore
shall not require any filter algorithm.
Two different mechanisms for routing are used. For group addressing a filter algorithm shall be used. For
individual addressing the routing shall be done by interpreting the individual address of the received
frame.
– 19 – EN 50090-4-2:2004
Two different network layer users must be distinguished:
a) the network layer user in a standard device: this is the transport layer, as specified in
Clause 6;
b) the network layer user in a router: this is the filter algorithm.
5.2 Network layer services and protocol
5.2.1 Network layer protocol data unit (NPDU)
The NPDU shall correspond to the LPDU of an L_Data-Frame without the control field, source address,
destination address, address type flag and the octet count.
An example of a NPDU that can be used is shown in Figure 9 below.
Octet 5 Octet 6 Octet 7 Octet 8 . Octet N
NPDU NPDU
NSDU
application user data
application control field
L-3 L-2 L-4 L-7
Figure 9 – Format of the NPDU (example)
5.2.2 Network layer services
5.2.2.1 N_Data_Individual service
The local user of network layer shall prepare a Network layer Service Data U
...