SIST EN 50090-4-2:2005

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

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

Elektrische Systemtechnik für Heim und Gebäude (ESHG) -- Teil 4-2: Medienunabhängige Schicht - Transportschicht, Vermittlungsschicht und allgemeine Teile der Sicherungsschicht für ESHG Klasse 1

Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) -- Partie 4-2: Couches indépendantes des media - Couches transport, réseau et parties générales de la couche données pour HBES Classe 1

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

General Information

• Status: Published
• Publication Date: 31-Aug-2005
• ICS: 35.100.05 - Multilayer applications
• ICS: 35.240.67 - IT applications in building and construction industry
• ICS: 97.120 - Automatic controls for household use
• Technical Committee: KIN - Mains communicating systems
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Sep-2005
• Due Date: 01-Sep-2005
• Completion Date: 01-Sep-2005
• Ref Project: EN 50090-4-2:2004 - 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

Relations

• Revised: SIST CLC/R 205-008:1998 - Home and Building Electronic Systems (HBES) -- Technical Report 8: Transport Layer and Network Layer, Class 1
• Effective Date: 13-May-2010

Standards Content (Sample)

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
SIST EN 50090-4-2:2005(en)
©  Standard je založil in izdal Slovenski inštitut za standardizacijo. Razmnoževanje ali kopiranje celote ali delov tega dokumenta ni dovoljeno

---------------------- Page: 1 ----------------------

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

---------------------- Page: 2 ----------------------

EN 50090-4-2:2004 – 2 –
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

---------------------- Page: 3 ----------------------

– 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: [e-mail]
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

---------------------- Page: 4 ----------------------

EN 50090-4-2:2004 – 4 –
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.

---------------------- Page: 5 ----------------------

– 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

---------------------- Page: 6 ----------------------

EN 50090-4-2:2004 – 6 –
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.

---------------------- Page: 7 ----------------------

– 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.

---------------------- Page: 8 ----------------------

EN 50090-4-2:2004 – 8 –
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.

---------------------- Page: 9 ----------------------

– 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

---------------------- Page: 10 ----------------------

EN 50090-4-2:2004 – 10 –
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.

---------------------- Page: 11 ----------------------

– 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

---------------------- Page: 12 ----------------------

EN 50090-4-2:2004 – 12 –

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.

---------------------- Page: 13 ----------------------

– 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_SystemBro
...