EN 50090-4-1:2004

SLOVENSKI SIST EN 50090-4-1:2005

STANDARD
september 2005
Stanovanjski in stavbni elektronski sistemi (HBES) – 4-1. del: Nivoji,
neodvisni od medijev – Aplikacijski nivo za HBES razreda 1
Home and Building Electronic Systems (HBES) – Part 4-1: Media independent
layers – Application 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-1
NORME EUROPÉENNE
EUROPÄISCHE NORM February 2004

ICS 35.100.70; 97.120 Supersedes R205-007:1996

English version
Home and Building Electronic Systems (HBES)
Part 4-1: Media independent layers –
Application 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-1: Couches indépendantes Teil 4-1: Medienunabhängige Schicht –
des media – Anwendungsschicht für ESHG Klasse 1
Couche application 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-1:2004 E
Contents
Foreword.4
Introduction.5
1 Scope .5
2 Normative references .5
3 Terms, definitions and abbreviations .5
3.1 Terms and definitions.5
3.2 Abbreviations .6
4 Services of the application layer .6
4.1 Communication modes .6
4.2 Service primitives of the application layer.7
5 Application layer Protocol Data Unit (APDU) .8
6 Application layer services.11
6.1 Application layer services on multicast communication mode.11
6.2 Application layer services on broadcast communication mode .17
6.3 Application layer services on point-to-point connection-less communication mode.36
6.4 Application layer services on point-to-point connection-oriented communication mode .51
6.5 Router-specific application layer services on point-to-point connection-oriented
communication mode.79
7 Parameters of application layer.80
7.1 Association table.80
7.2 Verify flag .80
Figure 1 – Interaction of the application layer for services that are not remote confirmed .7
Figure 2 – Interaction of the application layer for services that are remote confirmed .8
Figure 3 – APDU (example) .8
Figure 4 – Mapping the ASAP to the TSAP (example) .11
Figure 5 – Mapping a TSAP to an ASAP .11
Figure 6 – Handling requests and responses.11
Figure 7 – Message flow for the A_Group_Value_Read service .12
Figure 8 – A_GroupValue_Read-PDU (example) .12
Figure 9 – A_GroupValue_Response-PDU (example), length of ASAP data is more than 6 bit .13
Figure 10 – A_GroupValue_Response-PDU (example) length of ASAP data is 6 bit or less.13
Figure 11 – Message flow for the A_Group_Value_Write service .15
Figure 12 – A_GroupValue_Write-PDU (example), length of ASAP data is more than 6 bit.16
Figure 13 – A_GroupValue_Write-PDU (example), length of ASAP data is 6 bit or less .16
Figure 14 – A_IndividualAddress_Write-PDU (example).17
Figure 15 – A_IndividualAddress_Read-PDU (example).19
Figure 16 – A_IndividualAddress_Response-PDU (example) .19
Figure 17 – Message flow for the A_IndividualAddressSerialNumber_Read service.21
Figure 18 – A_IndividualAddressSerialNumber_Read-PDU (example).22
Figure 19 – A_IndividualAddressSerialNumber_Response-PDU (example).22
Figure 20 – A_IndividualAddressSerialNumber_Write-PDU (example).24
Figure 21 – A_ServiceInformation_Indication_Write-PDU (example).26

– 3 – EN 50090-4-1:2004
Figure 22 – A_DomainAddress_Write-PDU.27
Figure 23 – A_DomainAddress_Read-PDU (example).29
Figure 24 – A_DomainAddress_Response-PDU (example).29
Figure 25 – A_DomainAddressSelective_Read-PDU (example).31
Figure 26 – A_NetworkParameter_Read-PDU (example) .32
Figure 27 – A_NetworkParameter_Response-PDU (example).33
Figure 28 – A_NetworkParameter_Write-PDU (example) .35
Figure 29 – A_PropertyValue_Read-PDU (example) .37
Figure 30 – A_PropertyValue_Response-PDU (example).37
Figure 31 – A_PropertyValue_Write-PDU (example).40
Figure 32 – A_PropertyDescription_Read-PDU (example).43
Figure 33 – A_PropertyDescription_Response-PDU (example).43
Figure 34 – A_DeviceDescriptor_Read-PDU (example).46
Figure 35 – A_DeviceDescriptor_Response-PDU (example) .47
Figure 36 – Message flow for A_Link_Read Service .48
Figure 37 – A_Link_Read-PDU (example).49
Figure 38 – A_Link_Response-PDU .49
Figure 39 – Message flow for A_Link_Write Service .50
Figure 40 – A_Link_Write-PDU .50
Figure 41 – A_ADC_Read-PDU (example).52
Figure 42 – A_ADC_Response-PDU (example) .52
Figure 43 – A_Memory_Read-PDU (example) .54
Figure 44 – A_Memory_Response-PDU (example).55
Figure 45 – A_Memory_Write-PDU (example).57
Figure 46 – A_MemoryBit_Write-PDU .60
Figure 47 – A_UserMemory_Read-PDU (example).63
Figure 48 – A_UserMemory_Response-PDU .63
Figure 49 – A_UserMemory_Write-PDU .66
Figure 50 – A_UserMemoryBit_Write-PDU (example).69
Figure 51 – A_UserManufacturerInfo_Read-PDU (example) .72
Figure 52 – A_UserManufacturerInfo_Response-PDU.72
Figure 53 – A_Restart-PDU (example) .74
Figure 54 – A_Authorize_Request-PDU (example) .75
Figure 55 – A_Authorize_Response-PDU (example) .76
Figure 56 – A_Key_Write-PDU (example) .78
Figure 57 – A_Key_Response-PDU (example) .78
Table 1 – APCI overview.9
Table 2 – Function table for A_MemoryBit_Write-Services .59
Table 3 – Function table for A_UserMemoryBit_Write-Services.68
Table 4 – Association table of keys to access levels .77

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-1 on 2003-12-02.
This European Standard supersedes R205-007: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
with the EN have to be withdrawn (dow) 2006-12-01
EN 50090-4-1 is part of the EN 50090 series of European Standards, which will comprise the following
parts:
Part 1: Standardization 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

– 5 – EN 50090-4-1:2004
Introduction
This document specifies the services and protocol of the application layer for usage in Home and Building
Electronic Systems. Some services are targeted to field level communication between devices. Other
services are exclusively reserved for management purposes. Some services can be used for both
management and run-time communication.
1 Scope
This part of the EN 50090 specifies the services and protocol of the application layer for usage in Home
and Building Electronic Systems. It provides the services and the interface to the user process as defined
in EN 50090-3-2. This procedure is based on the services and the protocol is provided by the Transport
Layer, Network Layer and Data Link Layer as specified in EN 50090-4-2.
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)
Home and Building Electronic Systems (HBES) –
EN 50090-1
Part 1: Standardization 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-2:2004
Part 4-2 Media independent layers – Transport layer, network layer and general
parts of data link layer for HBES Class 1
EN 50090-7-1:2004 Home and Building Electronic Systems (HBES) –
Part 7-1: System management – Management procedures
EN 50173-1:2002 Information technology - Generic cabling systems
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
application (in the sense of network application)
a system with its associated transmission method which is supported by telecommunications cabling

[EN 50173-1:2002, definition 3.1.2]
3.1.2
user application
software functionality, the control algorithm that runs in one single device

———————
1)
At draft stage.
3.2 Abbreviations
AL Application Layer
AD-converter Analog-to-Digital-converter
APDU Application layer Protocol Data Unit
APCI Application layer Protocol Control Information
ASAP Application layer Service Access Point
Acon Application layer confirmation
con confirmation
CPU Central Processing Unit
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
ind indication
Lcon Local confirmation
PDU Protocol Data Unit
Rcon Remote confirmation
req request
res response
TL Transport Layer
TPDU Transport layer Protocol Data Unit
TSAP Transport layer Service Access Point
USERMSG User Message
4 Services of the application layer
4.1 Communication modes
The application layer shall provide a large variety of application services to the application process.
Application processes in different devices interoperate by using services of application layer over
communication modes. According to transport layer, the following different types of communication
modes shall exist:
a) point-to-multipoint, connection-less (multicast);
b) point-to-domain, connection-less (broadcast);
c) point-to-all-points, connection-less (system broadcast);
d) point-to-point, connection-less;
e) point-to-point, connection-oriented.
The application layer services that are offered shall depend on the communication mode. An application
layer service shall not be applied on a communication mode for which it is not specified.
Some services may be used on the point-to-point connection-oriented, as well as the point-to-point
connection-less communication mode, although application layer services shall always be mapped to
transport layer services depending on the type of the communication mode.

– 7 – EN 50090-4-1:2004
4.2 Service primitives of the application layer
Each specified application layer service shall be invoked by the transport layer primitives request (req),
indication (ind) and confirmation (con). For a remote confirmed service, the remote device shall use the
same transport layer primitives to respond to the service.
The transport layer confirmation primitive shall only be a confirmation from the transport layer instance
and shall include all data from the request plus the state which indicates whether the service was sent
successfully or not. The application layer shall map the transport layer confirmation primitive to a local
application layer confirmation (Lcon).
Local Remote/Response
Application Process
User of AL User of AL
A_Service.Lcon A_Service.ind
A_Service.req
Application Layer
T_Service.req T_Service.con T_Service.ind
(WRITE_PDU) (WRITE_PDU) (WRITE_PDU)
Transport Layer
Figure 1 – Interaction of the application layer
for services that are not remote confirmed
In case of a remote confirmed service the remote device shall initiate the response (res) primitive and the
application layer shall map this service primitive to a transport layer request primitive. The local
application layer shall receive the transport layer indication primitive and shall map it to an application
layer confirmation (Acon). The transport layer confirmation in the remote device shall be mapped by the
remote application layer to a remote confirmation (Rcon).
NOTE In the following service specifications the local application layer confirmation and the remote confirmation (Rcon) are not
always described.
Local Remote/Response
Application Process
User of AL User of AL
A_Service.req A_Service.Lcon A_Service.Acon A_Service.ind A_Service.Rcon A_Service.res
Application Layer
T_Service.req T_Service.con T_Service.ind
T_Service.ind
T_Service.con
T_Service.req
(READ_PDU) (READ_PDU)
(RESPONSE_PDU)
(READ_PDU) (RESPONSE_PDU)
RESPONSE_PDU
Transport Layer
Figure 2 – Interaction of the application layer
for services that are remote confirmed

5 Application layer Protocol Data Unit (APDU)
An example of an APDU that can be used is shown in Figure 3.
Octet 21
Octet 6 Octet 7 Octet 8 .
APDU
L-4 L-7
Figure 3 – APDU (example)
– 9 – EN 50090-4-1:2004
Table 1 – APCI overview
APCI Application layer Service Allowed communication
mode(s)
(bit position)
Octet n Octet n+1
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 0 0 0 A_GroupValue_Read X
0 0 0 1    A_GroupValue_Response X
0 0 1 0    A_GroupValue_Write X

0 0 1 1 0 0 0 0 0 0 A_IndividualAddress_Write X
0 1 0 0 0 0 0 0 0 0 A_IndividualAddress_Read X
0 1 0 1 0 0 0 0 0 0 A_IndividualAddress_Response X
1 1 1 1 0 1 1 1 0 0 A_IndividualAddressSerialNumber_Read X
1 1 1 1 0 1 1 1 0 1 A_IndividualAddressSerialNumber_Response X
1 1 1 1 0 1 1 1 1 0 A_IndividualAddressSerialNumber_Write X
1 1 1 1 0 1 1 1 1 1 A_ServiceInformation_Indication_Write X
1 1 1 1 0 1 1 0 1 0 A_NetworkParameter_Read  X
1 1 1 1 0 1 1 0 1 1 A_NetworkParameter_Response  X X
1 1 1 1 1 0 0 1 0 0 A_NetworkParameter_Write X X

1 1 1 1 0 1 0 1 0 1 A_PropertyValue_Read  X X
1 1 1 1 0 1 0 1 1 0 A_PropertyValue_Response  X X
1 1 1 1 0 1 0 1 1 1 A_PropertyValue_Write  X X
1 1 1 1 0 1 1 0 0 0 A_PropertyDescription_Read  X X
1 1 1 1 0 1 1 0 0 1 A_PropertyDescription_Response  X X
1 1 1 1 1 0 0 1 0 1 A_Link_Read  X X
1 1 1 1 1 0 0 1 1 0 A_Link_Response  X X
1 1 1 1 1 0 0 1 1 1 A_Link_Write  X X

0 1 1 0    A_ADC_Read   X
0 1 1 1    A_ADC_Response   X
1 0 0 0 0 0  A_Memory_Read   X
1 0 0 1 0 0  A_Memory_Response   X
1 0 1 0 0 0  A_Memory_Write   X

1 0 1 1 0 0 0 0 0 0 A_UserMemory_Read   X
1 0 1 1 0 0 0 0 0 1 A_UserMemory_Response   X
1 0 1 1 0 0 0 0 1 0 A_UserMemory_Write   X
1 0 1 1 0 0 0 1 0 0 A_UserMemoryBit_Write      (not for future use)      X
1 0 1 1 0 0 0 1 0 1 A_UserManufacturerInfo_Read   X
1 0 1 1 0 0 0 1 1 0 A_UserManufacturerInfo_Response   X

1 0 1 1 0 0 0 1 1 1   X
.. .. Reserved USERMSG
1 0 1 1 1 1 0 1 1 1   X
1 0 1 1 1 1 1 0 0 0   X
.. .. manufacturer specific area for USERMSG
1 0 1 1 1 1 1 1 1 0   X
APCI
APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
Multicast
Broadcast
Point-to-all-
points
connection-less
Point-to-point
connection-less
Point-to-point
connection-
oriented
Table 1 – APCI overview (continued)
APCI Application layer Service Allowed communication
mode(s)
(bit position)
Octet n Octet n+1
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

1 1 0 0 0 0 0 0 0 0 A_DeviceDescriptor_Read  X
1 1 0 1 0 0 0 0 0 0 A_DeviceDescriptor_Response  X
1 1 1 0 0 0 0 0 0 0 A_Restart  X

Coupler specific services
1 1 1 1 0 0 0 0 0 0 A_Open_Routing_Table_Req  (not for future use)      X
1 1 1 1 0 0 0 0 0 1 A_Read_Routing_Table_Req  (not for future use)   X
1 1 1 1 0 0 0 0 1 0 A_Read_Routing_Table__Res (not for future use)   X
1 1 1 1 0 0 0 0 1 1 A_Write_Routing_Table_Req  (not for future use)   X
1 1 1 1 0 0 1 0 0 0 A_Read_Router_Memory_Res (not for future use)   X
1 1 1 1 0 0 1 0 0 1 A_Read_Router_Memory_Res (not for future use)   X
1 1 1 1 0 0 1 0 1 0 A_Write_Router_Memory_Req (not for future use)   X
1 1 1 1 0 0 1 1 0 1 A_Read_Router_Status_Req   (not for future use)   X
1 1 1 1 0 0 1 1 1 0 A_Read_Router_Status_Res   (not for future use)   X
1 1 1 1 0 0 1 1 1 1 A_Write_Router_Status_Req   (not for future use)   X

1 1 1 1 0 1 0 0 0 0 A_MemoryBit_Write          (not for future use)   X
1 1 1 1 0 1 0 0 0 1 A_Authorize_Request   X
1 1 1 1 0 1 0 0 1 0 A_Authorize_Response   X
1 1 1 1 0 1 0 0 1 1 A_Key_Write   X
1 1 1 1 0 1 0 1 0 0 A_Key_Response   X

Open Media Specific Services
1 1 1 1 1 0 0 0 0 0 A_DomainAddress_Write X
1 1 1 1 1 0 0 0 0 1 A_DomainAddress_Read X
1 1 1 1 1 0 0 0 1 0 A_DomainAddress_Response X
1 1 1 1 1 0 0 0 1 1 A_DomainAddressSelective_Read X

The APDU shall correspond to the Transport layer Protocol Data Unit (TPDU), but shall be reduced by
the transport control field. The application control field shall be encoded and decoded by application layer
and shall contain the application layer service codes (APCI). The application control field shall have a
length of either 4 bit or 10 bit, as specified for each application layer service, in Clause 6.
The codes that shall be used for the application control field are shown in Table 1. The complete Protocol
Data Unit (PDU) for each service primitive is shown in the description of every service.
Not defined and not supported application layer services shall ignored by the application layer.

APCI
APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
data/APCI
Multicast
Broadcast
Point-to-all-point
connection-less
Point-to-point
connection-less
Point-to-point
connection-oriented
– 11 – EN 50090-4-1:2004
6 Application layer services
6.1 Application layer services on multicast communication mode
6.1.1 General
A multicast communication mode shall connect transport layer service access points (TSAP) to
application layer service access points (ASAP). When one device sends an A_GroupValue-Service each
device which is member of this group shall receive the A_GroupValue_Service.
If the application layer of a device receives an A_GroupValue_Write-Service, it shall map the contained
ASAP to exactly one TSAP; it shall search for other associations between ASAPs and the found TSAP
informs all these associated ASAPs. It is specified in 6.1.3 how this shall be done.
Association Table
transmit request
request on TSAP via ASAP 1
update on TSAP 1 ASAP 2
Figure 4 – Mapping the ASAP to the TSAP (example)
If the application layer of a device receives an A_GroupValue_Read-Service, it shall search for all ASAPs
associated to this TSAP and shall inform all the associated ASAPs. Only one read response shall be
generated by the user. It is specified in 6.1.2 how this shall be done.
read ASAP 1
Association Table
read disable
A_GroupValue_Read–Service
with TSAP = 1
11 transmit request response via ASAP 2
read enable
read ASAP 2
ASAP 3 is not informed if a
read response is already obtained

Figure 5 – Mapping a TSAP to an ASAP
If a transmission is requested (read response or write) via an ASAP, the application layer shall take the
associated TSAP, update all the ASAPs with the same TSAP and generate an
A_Group-Service-Request.
Association Table
transmit request
write/response on TSAP 1 20 write/response via ASAP 1
write/response ASAP 2
update on TSAP 1
Figure 6 – Handling requests and responses

6.1.2 A_GroupValue_Read Service
Application layer user TL Application layer user
A_GroupValue_Read.req T_Data_Group.req T_Data_Group.ind A_GroupValue_Read.ind

A_GroupValue_Read-PDU A_GroupValue_Read-PDU
A_GroupValue_Read.Lcon T_Data_Group.con

A_GroupValue_Read-PDU
A_GroupValue_Read.Acon T_Data_Group.ind T_Data_Group.req A_GroupValue_Read.res

A_GroupValue_Response-PDU A_GroupValue_Response-PDU
T_Data_Group.con A_GroupValue_Response.Rco
n
A_GroupValue_Response-PDU
Figure 7 – Message flow for the A_Group_Value_Read service
The A_GroupValue_Read.req primitive shall be applied by the user of application layer, to receive an
update of the value of its ASAP by making a communication partner respond with an
A_GroupValue_Read.res, i.e. the service shall be confirmed by the remote application process. The
ASAP shall be associated to the TSAP, i.e. with a group address, as specified in EN 50090-4-2. All other
group members shall receive the A_GroupValue_Response-PDU as well.
The local application layer shall accept the service request, map the ASAP to the TSAP and pass it with a
T_Data_Group.req to the local transport layer. The parameters TSAP and priority shall be mapped to the
corresponding parameters of the T_Data_Group.req primitive, the TSDU shall be an
A_GroupValue_Read-PDU.
The user of the HBES system can during configuration decide about this mapping between ASAPs and TSAPs.
The remote application layer shall map a T_Data_Group.ind primitive with
TSDU = A_GroupValue_Read-PDU to an A_GroupValue_Read.ind primitive. The arguments TSAP and
priority shall be mapped to the corresponding arguments ASAP and priority of the
A_GroupValue_Read.ind primitive. One A_GroupValue_Read.ind primitive shall be generated per ASAP
that is assigned to the corresponding TSAP.
The remote application process shall evaluate the received A_Group_Value_Read-PDU and use the
argument ASAP to obtain the response. It shall respond to the A_GroupValue_Read.ind primitive with an
A_GroupValue_Read.res primitive containing the obtained response.
The user of the HBES system can decide during configuration, whether or not the A_GroupValue_Read.res primitive is generated,
although exactly one ASAP should generate the A_GroupValue_Read.res primitive.
It is left to the user application programmer to decide whether an A_GroupValue_Read.Acon time-out supervision is necessary.
Two different formats of the A_GroupValue_Response-PDU are used depending on the length of the
value. The maximum length of the value shall be 14 octets. Unused data bits shall be set to zero.
Octet 6 Octet 7
APCI
7 6 54 3 2 1 0 765 43 210
Figure 8 – A_GroupValue_Read-PDU (example)

APCI
APCI
APCI
APCI
– 13 – EN 50090-4-1:2004
Octet 8.Octet
Octet 6 Octet 7
Value (up to 14
APCI
octets)
7 6 5 4 3 210 76 543 21 076 54 321 0

0001000000DDDDDDDD
Figure 9 – A_GroupValue_Response-PDU (example),
length of ASAP data is more than 6 bit
Values that only consist of 6 bits or less shall have the following optimized
A_GroupValue_Response-PDU format:
Octet 6 Octet 7
APCI
7 6 5 4321076543210
0001 DDDDDD Data
Figure 10 – A_GroupValue_Response-PDU (example)
length of ASAP data is 6 bit or less
The remote application layer shall accept the service response, map the ASAP to the TSAP and pass it
with a T_Data_Group.req to the local transport layer. The parameters ack_request, TSAP,
hop_count_type and priority shall be mapped to the corresponding parameters of the T_Data_Group.req
primitive, the TSDU shall be a A_GroupValue_Response-PDU.
The local application layer shall map a T_Data_Group.ind primitive with
TSDU = A_GroupValue_Response-PDU to an A_GroupValue_Read.Acon primitive. The arguments
TSAP and priority shall be mapped to the corresponding arguments ASAP and priority of the
A_GroupValue_Read. Acon primitive. More than one A_GroupValue_Read.Acon primitive may occur
depending on the number of group members that have been configured to respond.
A_GroupValue_Read.req(ack_request, ASAP, priority, hop_count_type)
ack_request: this parameter shall be used to indicate whether a layer-2 acknowledge is
mandatory or optional
ASAP: this parameter shall be used to contain the service access point
hop_count_type: this parameter shall be used to indicate whether the hop_count shall be set to 7 or
if the network layer parameter shall be used
priority: this parameter shall be used to contain the priority that shall be used to transmit
the requested service; it shall be “system”, “urgent”, “normal” or “low”

APCI
APCI
APCI APCI
APCI
APCI
APCI
APCI
A_GroupValue_Read.Lcon(ack_request ,ASAP, priority, hop_count_type, a_status)
ack_request: this parameter shall be used to indicate whether a layer-2 acknowledge has been
indicated as mandatory or optional in the transmitted frame
ASAP: this parameter shall be used to contain the service access point
hop_count_type: this parameter shall be used to indicate whether the hop_count of the transmitted
frame has been set to 7 or if the network layer parameter has been used
priority: this parameter shall be used to indicate the priority that has been used to the
transmit the requested frame; it shall be “system”, “urgent”, “normal” or “low”
a_status: ok: this value of this parameter shall be used to indicate that the transmission of the
A_GroupValue_Read.req has been successful
not_ok: this value of this parameter shall be used to indicate that the transmission of the
A_GroupValue_Read.req did not succeed

A_GroupValue_Read.ind(ASAP, priority, hop_count_type)
ASAP: this parameter shall be used to contain the service access point
hop_count_type: this parameter shall be used to indicate whether the hop count of the received
frame equals 7 or not
priority: this parameter shall be used to indicate the priority of the received frame; it shall
be “system”, “urgent”, “normal” or “low”

A_GroupValue_Read.res(ack_request, ASAP, priority, hop_count_type, data)
ack_request: this parameter shall be used to indicate whether a layer-2 acknowledge is
mandatory or optional
ASAP: this parameter shall be used to contain the service access point
hop_count_type: this parameter shall be used to indicate whether the hop_count shall be set to 7 or
if the network layer parameter shall be used
priority: this parameter shall be used to contain the priority that shall be used to transmit
the requested service; it shall be “system”, “urgent”, “normal” or “low”
data: the parameter shall be used to contain the value of the associated service access
point
– 15 – EN 50090-4-1:2004
A_GroupValue_Read.Rcon(ack_request, ASAP, priority, hop_count_type, data, a_status)
ack_request: this parameter shall be used to indicate whether a layer-2 acknowledge has been
indicated as mandatory or optional in the transmitted frame
ASAP: this parameter shall be used to contain the service access point
hop_count_type: this parameter shall be used to indicate whether the hop_count of the transmitted
frame has been set to 7 or if the network layer parameter has been used
priority: this parameter shall be used to indicate the priority that has been used to the
transmit the requested frame; it shall be “system”, “urgent”, “normal” or “low”
data: this parameter shall be used to contain the value of the associated service access
point
a_status: ok: this value of this parameter shall be used to indicate that the transmission of the
A_GroupValue_Read.res has been successful
not_ok: this value of this parameter shall be used to indicate that the transmission of the
A_GroupValue_Read.res did not succeed

A_GroupValue_Read.Acon(ASAP, priority, hop_count_type, data)
ASAP: this parameter shall be used to contain the service access point
hop_count_type: this parameter shall be used to indicate whether the hop count of the received
frame equals 7 or not
priority: this parameter shall be used to indicate the priority of the received frame; it shall
be “system”, “urgent”, “normal” or “low”
data: this parameter shall be used to contain the value of the associated service access
point
6.1.3 A_GroupValue_Write Service
Application layer user TL Application layer user
A_GroupValue_Write.req T_Data_Group.req T_Data_Group.ind A_GroupValue_Write.ind

A_GroupValue_Write-PDU A_GroupValue_Write-PDU
A_GroupValue_Write.Lcon T_Data_Group.con

A_GroupValue_Write-PDU
Figure 11 – Message flow for the A_Group_Value_Write service
The A_GroupValue_Write.req primitive shall be applied by the user of application layer, to send an
update of its ASAP to all connected ASAPs. The service shall not be confirmed by the remote application
process, the confirmation shall be caused by the local T_Data_Group.con. The ASAP shall be associated
to the TSAP i.e. with a group address, as specified in EN 50090-4-2. All group members shall receive the
A_GroupValue_Write-PDU.
The local application layer shall accept the service request, map the ASAP to the TSAP and pass it with a
T_Data_Group.req to the local transport layer.
NOTE The user of the HBES system can during configuration decide about this mapping between ASAPs and TSAPs.
The parameters TSAP and priority shall be mapped to the corresponding parameters of the
T_Data_Group.req primitive, the TSDU shall be an A_GroupValue_Write-PDU.

The remote application layer shall map a T_Data_Group.ind primitive with
TSDU = A_GroupValue_Write-PDU to an A_GroupValue_Write.ind primitive. The arguments TSAP and
priority shall be mapped to the corresponding arguments ASAP and priority of the
A_GroupValue_Write.ind primitive. One A_GroupValue_Write.ind primitive shall be generated per ASAP
that is assigned to the corresponding TSAP (i.e. group_address).
Two different formats of the A_GroupValue_Write-PDU are used depending on the length of the value.
The maximum length of the value shall be 14 octets. Unused data bits shall be set to zero.
Octet 6 Octet 7 Octet 8.to.Octet 21
APCI Value (up to 14 octets)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

0 0 1 0 0 0 0 0 0 0 D D D D D D D D
Figure 12 – A_GroupValue_Write-PDU (example),
length of ASAP data is more than 6 bit
Values that only consist of 6 bits or less shall have the following optimized A_GroupValue_Write-PDU
format:
Octet 6 Octet 7
APCI
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

0 0 1 0 d d d d d d
Figure 13 – A_GroupValue_Write-PDU (example),
length of ASAP data is 6 bit or less
If the local application layer receives a T_Data_Group.con from the local transport layer, it shall pass an
A_GroupValue_Write.Lcon primitive to the local application process. If the confirmation is positive
(t_status = ok), the local application layer shall pass a positive A_GroupValue_Write.Lcon (a_status = ok)
to the local application process. If the confirmation is negative (t_status = not_ok), the local application
layer shall pass an A_GroupValue_Write.Lcon (a_status = not_ok) to the local user indicating that the
transmission of the associated T_Data_Group.req did not succeed.
A_GroupValue_Write.req(ack_request, ASAP, priority, hop_count_type, data)
ack_request: this parameter shall be used to indicate whether a layer-2 acknowledge is
mandatory or optional
ASAP: this parameter shall be used to contain the service access point
priority: this parameter shall be used to contain the priority that shall be used to transmit
the requested service; it shall be “system”, “urgent”, “normal” or “low”
hop_count_type: this parameter shall be used to indicate whether the hop_count shall be set to 7 or
if the network layer parameter shall be used
data: this parameter shall be used to contain the data of the associated application layer
service access point
APCI
APCI
APCI
APCI
APCI
APCI
APCI
APCI
– 17 – EN 50090-4-1:2004
A_GroupValue_Write.Lcon(ack_request, ASAP, priority, hop_count_type, data, a_status)
ack_request: this parameter shall be used to indicate whether a layer-2 acknowledge has been
indicated as mandatory or optional in the transmitted frame
ASAP: this parameter shall be used to contain the service access point
priority: this parameter shall be used to indicate the priority that has been used to the
transmit the requested frame; it shall be “system”, “urgent”, “normal” or “low”
hop_count_type: this parameter shall be used to indicate whether the hop_count of the transmitted
frame has been set to 7 or if the network layer parameter has been used
data: this parameter shall be used to contain the data of the associated application layer
service access point
a_status: ok: this value of this parameters shall be used to indicate that the transmission of the
A_GroupValue_Write.req has been successful
not_ok: this value of this parameters shall be used to indicate that the transmission of the
A_GroupValue_Write.req did not succeed

A_GroupValue_Write.ind(ASAP, priority, hop_count_type, data)
ASAP: this parameter shall be used to contain the service access point
priority: this parameter shall be used to indicate the priority of the received frame; it shall
be “system”, “urgent”, “normal” or “low”
hop_count_type: this parameter shall be used to indicate whether the hop count of the received
frame equals 7 or not
data: this parameter shall be used to contain the data of the associated application layer
service access point
6.2 Application layer services on broadcast communication mode
6.2.1 A_IndividualAddress_Write Service
The A_IndividualAddress_Write.req primitive shall be applied by the user of application layer to modify
the individual address in a communication partner. The communication partner shall not be identified in
the service, i.e. the destination shall be defined by selecting a destination manually. This may be done by
pressing a button on exactly one device that brings this device into a ´programming mode´, i.e. only the
device where the button is pressed shall accept the A_IndividualAddress_Write.ind, others shall ignore it.
The way that a product is set to ´programming mode´ may be manufacturer specific.
The local application layer shall accept the service request and pass it with a T_Data_Broadcast.req to
the local transport layer. The parameter priority, implicitly with value ‘system’, shall be mapped to the
corresponding parameter of the T_Data_Broadcast.req primitive, the TSDU shall be an
A_IndividualAddress_Write-PDU.
Octet 6 Octet 7 Octet 8 Octet 9
New address New address
APCI
(high) (low)
7 65 4 3 2 1 0 7 654321076543210765432 1 0

0 0 1 1000000 xxxxxxxxxxxxxx x X
Figure 14 – A_IndividualAddress_Wri
...