Download 5 Requirements - ISO/IEC JTC1 SC25 WG1 Home Page

ISO/IEC JTC 1/SC 25/WG 1
N 1126
Date: 2004–8–31
Replaces ISO/IEC JTC 1/SC 25/WG 1 N 1100a
ISO/IEC JTC 1/SC 25
INTERCONNECTION OF INFORMATION TECHNOLOGY EQUIPMENT
Secretariat: Germany (DIN)
DOC TYPE:
CD
TITLE:
ISO/IEC CD 15045-2 Information technology —
Interconnection of information technology equipment —
Home Electronic System — (HES) Gateway — Part
2: Modularity and Protocol
SOURCE:
SC 25/WG 1
PROJECT:
25.01.03.02-02
STATUS:
Working Draft
ACTION ID:
ACT
DUE DATE:
2004-10-30
REQUESTED
ACTION:
National body members of SC 25/WG 1 are
asked to review and comment on this CD.
MEDIUM:
Defined
No. of Pages:
28 (excluding cover)
DISTRIBUTION:
ISO/IEC JTC 1 SC 25/WG 1
Size in KB: yyy (including cover)
Secretary - ISO/IEC JTC 1 / SC 25 - Dr.-Ing. Walter P. von Pattay
Member of ZVEI FV 7 & FV 8, Gotthelfstr. 34, D -81677 München, Germany
Tel.: +49 89-923 967 57, Tfx.: +49 89-923 967 59
EM: [email protected]
Ftp address: "ftp.iec.ch", login: "sc25mem", password: see SC 25 N 449
Home page: ”http://www.iec.ch/sc25”
INTERNATIONAL
STANDARD
(DRAFT)
Information technology –
Home electronic system (HES) – gateway
Part 2:
Modularity and protocol
ISO/IEC
15045-2
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
–2–
15045-2  ISO/IEC:2004
CONTENTS
Page
1
Scope ............................................................................................................................... 4
2
Purpose ............................................................................................................................ 5
2.1
2.2
3
Statement of purpose............................................................................................... 5
Design philosophy ................................................................................................... 5
2.2.1 Distributed Gateway System ........................................................................ 6
2.3 Goals and non-goals ................................................................................................ 6
2.4 Conformity ............................................................................................................... 6
References ....................................................................................................................... 7
4
Terminology ...................................................................................................................... 7
5
4.1 Definitions ............................................................................................................... 7
4.2 Abbreviations ........................................................................................................... 9
Requirements.................................................................................................................. 10
6
5.1 Modularity requirements ........................................................................................ 10
System model ................................................................................................................. 10
7
6.1 Abstract HES system ............................................................................................. 10
6.2 Generic Interworking Function (GIWF) ................................................................... 11
6.3 Conformance paradigm—roles ............................................................................... 11
Architecture .................................................................................................................... 12
7.1
7.2
7.3
7.4
7.5
8
Half-gateway Modularity ........................................................................................ 12
WAN interface module ........................................................................................... 14
HAN interface module ............................................................................................ 15
Service module ...................................................................................................... 15
Data flows.............................................................................................................. 16
7.5.1 Control plane ............................................................................................. 16
7.5.2 Content (data) plane .................................................................................. 16
Internal Processes .......................................................................................................... 16
8.1
8.2
8.3
8.4
8.5
9
Protocol stacks ...................................................................................................... 17
Internal Protocol (RGIP) ........................................................................................ 19
Internal bus ........................................................................................................... 19
Service requirements ............................................................................................. 20
Network management ............................................................................................ 20
8.5.1 Module address allocation ......................................................................... 20
8.5.2 Module service discovery ........................................................................... 20
8.5.3 Inter-module packet priority and routing ..................................................... 20
Conformance .................................................................................................................. 21
A.
9.1 Basic functions and requirements .......................................................................... 21
9.2 Compliance of qualifying products and networks .................................................... 21
Overview of case examples ............................................................................................ 23
1.1
1.2
VDSL scenario ....................................................................................................... 23
VDSL scenario ....................................................................................................... 24
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
B.
–3–
15045-2  ISO/IEC:2004
1.3 Healthcare management scenario .......................................................................... 25
1.4 DSL/HomePNA scenario ........................................................................................ 25
Overview of internal bus topologies ................................................................................ 26
1.5
1.6
1.7
Mesh topology ....................................................................................................... 26
Star topology ......................................................................................................... 26
Combined mesh and star topology ......................................................................... 27
ISO/IEC JTC 1/SC 582713336
1
FOREWORD
2
3
4
5
6
7
8
ISO (the International Organisation for Standardisation) and IEC (the International
Electrotechnical Commission) form the specialised system for world -wide standardisation.
National bodies that are members of ISO or IEC participate in the development of
International Standards through technical committees established by the respective
organisation to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organisations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
9
10
11
12
In the field of information technology, ISO and IEC have established a joint technical
committee, ISO/IEC JTC 1. International Standards adopted by the joint technical committee
are circulated to national bodies for voting. Publication as an International Standard requires
approval by at least 75 % of the national bodies casting a vote.
13
14
15
This part of ISO/IEC 15045 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 25, Interconnection of Information Technology
Equipment.
16
17
ISO/IEC 15045 consists of the following parts, under the general title: Information technology
— Home electronic system (HES) Gateway.
18

Part 1: A Residential gateway model for HES
19

Part 2: Modularity and protocol
20

Part 3: Security
21

Part 4: Safety
22

Part 5: Privacy
23

Part 6: Conformance
24
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
–2–
15045-2  ISO/IEC:2004
25
INTRODUCTION
26
27
28
29
30
31
The rapid, widespread development and deployment of numerous standards, technologies,
services, and products for communication withi n or to the home has created problems of
incompatibility, non-interoperability, complexity, and expense for consumers, service
providers, and manufacturers. This situation necessitates a standard for enabling and
ensuring co-existence, compatibility, or interoperability between such network standards,
specifications, and products from multiple manufacturers or providers.
32
33
34
35
36
37
38
39
For example, it is desirable and beneficial that networks or products for home lighting control
be able to share sensor or actuator information with other networks or products for home
energy management, home security, or audio-visual distribution. Likewise, it would be
efficient and convenient for broadband access networks, regardless of technology employed
(e.g., DSL, cable, satellite, wireless, fibre-optic, etc.), to share delivery of common voice,
video and data signals with a variety of home appliances ( e.g., TVs, entertainment products,
phones, computers, thermostats, medical equipment, etc.), regardless of manufacturer or
provider.
40
41
42
43
44
45
46
47
48
49
50
51
This document is part of a series of standards and technical reports for the Home Electronic
System (HES) that deal with the topic of control and communication networks in homes and
other small buildings. Part 1 of this standard, ISO/IEC 15045 -1, A Residential Gateway Model
for HES, published in 2004, defines a basic model of the residential gateway, including
functional requirements. This part 2 defines a common framework for implementing platforms
for achieving interconnection and interoperability of home system products and applications
from any manufacturer or provider in a manner that is safe, reliable, predictable and
consistent. It accomplishes such interoperability by defining a standard modular architecture,
a common signalling bus and protocol for interconnecting the modules. It relies on a common
intermediate language for interoperability of applications based on a Common Interoperability
System (HES-AS) as defined in the standard ISO/IEC 18012, Guidelines for Product
Interoperability.
52
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
53
54
55
56
57
58
59
60
15045-2  ISO/IEC:2004
–3–
It is possible that a user will purchase and install products employing two (or more) dissimilar
networks, known as a home area networks (HANs), within the same premises. However, the
user will expect these products and networks to behave as if they were logically the same
network, Therefore, when linked by some physical means, each network must include an
interface that conforms to this standard, as shown in Figure 1. Likewise, service providers
outside the house using a variety of wide area networks (WANs) may wi sh to exchange
information with these HANs. In order to achieve such interoperability, these WANs must also
provide an interface that conforms to this standard.
61
62
O1
O2
O3
O4
63
HGI
WGI
64
Wide Area Network X
65
66
Home Area Network A
HomeNetwor
kA
Physical
HESgateway
O1
WGI
Wide Area Network Y
67
HGI
O2
O3
Logical
link
O4
Home Area Network B
68
WGI
69
= WAN Gateway Interface
On
70
HGI
= HAN Gateway Interface
= Object on network
71
72
Figure 1 - Interoperating Networks
73
This document comprises the following sections:
74
75

Overview sections that define the scope and purpose of the standard, key terminology,
and normative and informative references.
76
77
78

A requirements section that defines the normati ve functional requirements for the gateway
system and associated modules, including modular interface and stakeholder
requirements.
79
80

A system model section that defines the abstract HES system, the generic interworking
function and the conformance paradigm.
81
82
83

An architecture section that defines wide area network (WAN) modules, home area
network (HAN) modules, service modules, data flows (for both content (data) and control
planes), and illustrative reference models.
84
85
86
87

An internal process section that defines protocol stacks, the residential gateway internal
protocol (RGIP), the internal bus, service requirements, and network management
requirements. Also, specific requirements are included to address issues of safety,
security, and privacy.
88
89

A conformance section to which all interoperating networks, modules, and intermediary
equipment on the Home Electronic System shall comply.
90
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
Information technology — Interconnection of information technology
equipment — Home Electronic System (HES) — Gateway — Part 2:
Modularity and Protocol
91
92
93
94
–4–
1
Scope
95
96
97
98
99
100
101
102
103
104
105
106
107
ISO/IEC 15045-1 (part 1) specifies the functional requirements and basic architecture for the
residential gateway. This part, ISO/IEC 15045-2 (part 2), specifies a residential gateway
modular structure and an internal protocol and language that may be used to implement a
conforming gateway system for HES. This part specifies the structure, functional and
signalling requirements for modular interfaces and internally connecting busses with sufficient
detail to create products that can offer interoperable gateway functionalities. It specifies with
sufficient detail all required layers, or stacks, of the internal protocol (RGIP) needed to design
interoperable Home Electronic System network interface and service modules. Required
layers of specific WAN or HAN protocols are not specified, but are left entirely to the product
manufacturer. The RGIP and other protocol stacks rely on an interoperability language
(specified in the International Standard, ISO/IEC 18012) that resides above lay er seven, the
application layer (of the ISO Reference Model) and interfaces to the aforementioned protocol
stacks.
108
ISO/IEC 15045-2 (this International Standard) is applicable to:
109

Standalone local/home area networks (HANs), connected devices, and applicatio ns.
110
111

Multiple implementation of local/home area networks (HANs), connected devices, and
applications.
112
113

Wide area networks (WANs) (also known as access networks) and applications connected
to home area networks (HANs), connected devices, and applications.
114
115
116
117
118
119
120
121
122
ISO/IEC 15045-2 (this International Standard) specifies interoperability requirements and
methods for system set-up, operation and management applied to devices connected to a
single home network system or to different home network systems. Although a single uniform
home network system would simplify such operations, this standard recognises that multiple
dissimilar network systems may co-exist in the same premises. This standard specifies
requirements to ensure that devices from multiple manufacturers and /or multiple network
systems will work together as a total Home Electronic System (HES) to provide service to a
specific application. Also, this standard specifies requirements that assure that a specific
device could provide service for multiple applications .
123
ISO/IEC 15045-2 specifies interoperability requirements with respect to:
124

Transport and interpretation/translation of control (control plane) information
125

Transport of content (data plane) information
126

Set-up of gateway modules (e.g., protocols for initial address acquisition)
127

Certain ongoing basic network management functions
128
129
130
131
132
This document presumes that home networks share common resources, such as devices, to
support application functions (including device addressing and binding, resource allocation,
error management, etc.) and that mechanisms exist, defined in other parts of this standard, or
in other standards, to ensure that there is no mutual interference. It does not specify how this
is done.
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
–5–
15045-2  ISO/IEC:2004
133
2
Purpose
134
2.1
Statement of purpose
135
136
137
138
139
140
This standard provides an open, modular, and expandable framework for the delivery of
broadband services to the consumer that can accommodate diverse networks on both the
HAN and WAN side. It can also provide a basic firewall function that will protect the
autonomy, safety, privacy, and security of the consumer, yet enable trusted relationships with
preferred service providers. The basic functionality of the HES -gateway system showing its is
shown in Figure 2.
141
142
HESgateway
WANs
HANs
143
144
WAN
145
WAN
interfaces
146
HAN
translator
Firewall
HAN
(both
sides of interfaces
transl.)
147
148
Figure 2—HES-gateway System Functionality
149
150
151
152
In addition to providing access to WAN based services, this standard can also enable
interoperability or interworking of HAN-based appliances, products and services by providing
a framework for situating the functions that perform the mappings between disparate, possibly
proprietary, HES systems. The common element is that of home services, such as:
153

Entertainment/video
154

Data/Internet access
155

Telephony
156

Energy management
157

Environmental control (heating and cooling)
158

Security monitoring
159

Appliance telemetry
160

Lighting control
161
2.2
162
163
164
165
166
167
168
169
Conventional gateway, e.g. set-top box designs, generally take a “one-size-fits-all” approach
tailored to some defined set of services on both the HAN and WAN side. In the quest for low
cost and economies of scale in manufacturing, modularity and expandability are sacrificed,
along with flexibility that service providers frequently need. Often, the result is a "big box"
that tries to accommodate many functions and services, yet frequently fails to provide the key
features that are most needed in any particular situation. These big boxes have been
characterised as “set-top boxes on steroids,” and are frequently designed around a powerful
central processor and operating system.
Design philosophy
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
–6–
15045-2  ISO/IEC:2004
170
2.2.1
Distributed Gateway System
171
172
173
174
175
176
177
This standard is based on a model, the Distributed Gateway System (DGS), that seeks to
design around the minimum feasible functional unit, rather than the maximum. There is no
requirement for a central processor or controller in a DGS. Rather, the most generalised
implementation of the DGS uses a distributed computing model consisting of a network of
semi-autonomous interfaces and agents running in dedicated embedded microcomputers
situated on individual modules or circuit cards and interconnected by an internal high speed
serial bus or “backplane.” Each module is associated with a single HAN or WAN.
178
179
180
181
182
183
184
185
The HES-gateway accommodates the conventional (simple) gateway (one WAN and one
HAN) as a specific case, within a generally defined DGS architectural framework. The DGS is
a modular architecture that supports multiple WANs and HANs. It imposes no specific
requirements on implementations, although compliance with it implies a certain specific
choice of modularity that preserves the integrity of the CIS (Common Interoperability System).
With respect to protocols and communications services, the DGS model is analogous to the
OSI Reference Model for Communications (ISO 7498) in that a specific implementation is not
required to include every element (layer) of the OSI Reference Model.
186
187
188
189
190
191
192
193
The interface to each HAN or WAN might be hosted in a variety of HES -gateway
configurations. These HAN and WAN modules may be housed in a common gateway chassis
or in multiple gateways that are easily interconnected. This system of modules is self configuring and should be hot-pluggable. This approach is roughly analogous to the “blade
server” architecture now becoming widely employed in the commercial networking industry.
In more specialised implementations, although the modules might be combined and the
internal protocol and bus might be collapsed, the principle of modularity at the CIS level shall
be preserved.
194
195
196
197
198
199
200
201
Much like the design of the Internet, the HES-gateway seeks simplicity by separating content
and application from transport and delivery. Such separ ation moves as much “intelligence” as
possible out of the gateway. Applications and services reside on the periphery of the gateway
(i.e., on the respective HANs and WANs or on service modules) where they can grow and
develop in directions not dependent on the gateway itself. The HES-gateway system design
seeks to minimise the information or knowledge that the gateway needs about the products
and services residing on each network. Rather, it provides a means of finding such
information when needed.
202
203
204
205
206
207
This distributed minimalist architecture provides a measure of “future -proofing” by employing
internal bus and protocol or language elements that are layered and upward compatible with
future additions or changes. For example, the language elements shall be de fined and
contained in a metadata registry that can be endlessly re -configured and accessed by product
developers. Protocol stacks for an expanding list of WAN and HAN protocols may be
maintained in an open-source library that is also available to developers.
208
2.3
209
210
211
212
213
214
215
[brief summary of goals and non-goals, see last paragraph of “scope” section] This standard
seeks to establish a general-purpose interoperability platform or “translator” among home
area networks and between specific wide area net works and such home area networks. This
standard does not attempt to be a central controller or control system; and does not attempt
to improve or resolve disparities or shortcomings among transmission technologies, protocols
or application languages. However, this standard does seek to provide the premises with
basic elements of security (i.e., firewall), safety, and autonomy.
216
2.4
217
218
[brief summary of conformity approach (e.g., self cetification, conformity testing trademark,
etc.)]
Goals and non-goals
Conformity
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
–7–
15045-2  ISO/IEC:2004
219
3
References
220
3.1
Normative references
221
222
223
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.
No:
Reference
Descriptive Title
[1]
ISO 7498 : 1984
Information processing systems - Open Systems
Interconnection - Basic Reference Model
[2]
ISO/IEC TR-14543
Home Electronic System Architecture
[3]
ISO/IEC TR-14762
Guidelines for Functional Safety for Home Control
Systems
[4]
ISO/IEC FDIS 18012-1
ISO/IEC 18012-1 Information technology —
Interconnection of information technology equipment —
Home electronic system — Guidelines for product
interoperability — Part 1: Introduction
[5]
ISO/IEC FDIS 18012-2
ISO/IEC 18012-2 Information technology —
Interconnection of information technology equipment —
Home electronic system — Guidelines for product
interoperability — Part 2: Taxonomy and Lexicon 1
[6]
IEEE 802.3ae
IEEE xxxx [need completeXAUI reference here]
224
3.2
Informative References
225
For the purposes of this International Standard, the following references may be useful.
226
227
[add informative references here—must be published material only, will add a Bibliography at
the end]
228
4
Terminology
229
4.1
Definitions
230
231
For the purposes of this International Standard, the following definitions are applicable. [are
these the right terms we need to define?]
232
233
234
4.1.1 API
Application Programming Interface: The collection of invocation methods and associated
parameters used by one piece of software to request actions from another piece of software
235
236
237
4.1.2 Bus
A common communication path or means of interconnecting devices under a single
administration, such as a LAN comprising devices sharing a common set of pathways ( e.g.,;
———————
1 To be published
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
–8–
15045-2  ISO/IEC:2004
238
239
SCI or PCI internal to a single PC; USB, Ethernet, or Firewire for a distributed device
interconnect) .
240
241
242
243
244
245
246
4.1.3 CIS
The Common Ineroperability System is an internal HES-gateway system that includes 1) an
HES-AS (Abstract System), an HES-gateway oriented application language that includes a
syntactic structure and semantic definitions comprising a lexicon of terms including objects
and methods (actions); and 2) a set of network -specific Generic Interworking Function (GIWF)
processes to express (i.e., translate) any message to or from any specific HAN or WAN
message.
247
248
249
4.1.4 Co-existence
Two or more networks within a premises that do not interfere with one another; the same as
compatiblility.
250
251
252
253
254
255
4.1.5 Component
A logical subunit of a larger, encompassing concept. For exa mple, the concept of
Interoperability is broken down into constituent components such as Safety, Management,
and Operation. These constituent components are further broken down within their respective
sections. The term component is also used to refer to logical subunits of system architecture
concepts, such as the components of a networking implementation ( e.g., addressing)
256
257
258
259
4.1.6 Device
A distinct physical unit on a network. It can either be an end node on the network, or an
intermediate node (as in the case of a gateway, router, or bridge device connecting two
distinct physical networks)
260
261
262
263
4.1.7 RGIP
The Residential Gateway Internal Protocol is the full 7 layer protocol stack that may be used
to communicate the HES-AS code (resulting from the GIWF translation process, above layer
7) to the Residential Gateway Internal Bus.
264
265
266
4.1.8 Gateway
An interface between dissimilar networks. A gateway may provide services up to layer 7 and
above. The HES-gateway provides protocol and language translation services above layer 7.
267
268
269
270
271
4.1.9 Half-gateway
A device that provides the required services for one of the networks of the HES -gateway
system. In the context of this standard, the half -gateway provides protocol and language
translation services above layer 7 and provides an interface to the RGIP for purposes of
connecting to one or more other half-gateways serving other networks.
272
273
274
4.1.10 HES
The Home Electronic System is a network of networks, accessing and operating within the
home, that is compatible and interoperable.
275
276
277
278
279
4.1.11 HES AS (Abstract System)
An HES-gateway oriented abstract intermediate language for representing the messages of
any HAN or WAN. It is an internal HES-gateway oriented application language that includes a
syntactic structure and semantic definitions comprising a lexicon of terms including objects
and methods (actions).
280
281
282
4.1.12 Interoperability
Logical entities function together for applications on a network [reconcile with definitions in
the interop document]
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
–9–
15045-2  ISO/IEC:2004
283
284
285
4.1.13 MIB
Management Information Base, a mem ory function in some portion of the gateway that stores
information useful for various network management functions.
286
287
288
4.1.13 Network
A distinct interconnection or set of nodes or devices that share a common communication
protocol and are mutually compatible and interoperable.
289
290
291
4.1.14 Object
A unit of software functionality. Used as traditionally defined in object -oriented programming.
[Why not use a standard definition, e.g. Booch, Grady, etc.?]
292
293
4.1.15 Product
A device or network of devices that may be purchased to make up a Home Electronic System
294
295
296
4.1.16 Single implementation
A single, homogeneous network implementation, where interoperability is only of concern
within the single network
297
298
299
300
4.1.17 Multiple implementation
A mixed collection of two or more network implementations. To establish interoperability, each
network shall have a routing path to every other network in the system. This path may involve
one or more hops through multiple intermediate networks
301
302
303
304
305
4.1.17 Intermediate implementation
A mixed collection of two or more network implementations. To establish connectivity, it
provides for a common intermediate translation between any two networks, assuring a worst case translation path of two hops (from any network to the common translation, and then from
the common translation to the destination network
306
4.2
API
CIS
DBS
DSL
GWIF
HAN
HES
IP
MIB
NTSC
OSI
PAL
POTS
RGIP
SNMP
USB
VDSL
WAN
307
Abbreviations
Application Programming Interface
Common Interoperability System
Direct Broadcast Satellite
Digital Subscriber Line
Generic InterWorking Function
Home Area Network
Home Electronic System
Internet Protocol
Management Information Base
National Television Standards Committee (TV standard, USA)
Open Systems Interconnection
Phase Alternate Line (TV standard, Europe)
Plain Old Telephone Service (voice)
Residential Gateway Internal Protocol
Simple Network Management Protocol
Universal Serial Bus
Very high speed DSL
Wide Area Network
Note: The abbreviations shown in italics above are HES-specific terms.
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 10 –
308
5
Requirements
309
5.1
Modularity requirements
310
311
312
313
314
315
316
317
318
319
320
321
The basic function of the HES Gateway is to translate messages between networks that use
different communication protocols.
This translation is accomplished by the Common
Interoperability System (HES-CIS), as specified in ISO/IEC 18012. Each message shall be
translated into a common intermediate language, the HES Abstract System (HES -AS). The
translation process in the HES Gateway is performed by a network -specific Generic
Interworking Function (GIWF). In the case of the DGS where modules (half-gateways) are
physically distributed on an HES-gateway internal bus, then the translated message may be
transported via the RGIP protocol to the receiving GIWF which then translates it into the
language and protocol of the target network. The RGIP accommodates multiple WANs and
HANs without requiring separate translators for each possible combination of networks (e.g.,
WAN and HAN, or HAN and HAN) A simple gateway linking one WAN and one HAN may
incorporate the dual translation process without using the RGIP.
322
323
324
325
326
327
328
In the most generalised implementation of the HES Distributed Gateway System, network
interoperability shall be achieved by a dedicated interface module for each network that
provides a GIWF linking this network to an abstract HES system network (AS) and internal
protocol (RGIP). Alternatively, specific appliances may incorporate such GIWF and AS/RGIP
interface functions (examples are provided in the section on reference models). Also, an
optional specialised implementation such as the “simple gateway” (i.e., see ISO/IEC 15045-1,
A.2.6.2) may combine modules into a single unit and collapse the internal bus entirely.
329
330
331
332
Each module may be visualised as a “half-gateway” connected by an internal protocol and
bus. This bus need not be confined to a common chassis, but could be extended throughout
the premises using an appropriate bus technology or tunnelling technique. Such a distributed
half-gateway implementation options further described in later sections.
333
6
System model
334
6.1
Abstract HES system
335
336
337
The generalised HES-gateway system model is depicted in Figure 3, known as the CIS
(Common Interoperability System) by which interoperability between all possible systems
(present and future) may be achieved.
338
Abstract HES System (AS)
339
340
341
GIWF #1
GIWF #2
GIWF #3
GIWF #4
#1AS
#2AS
#3AS
#4AS
342
343
System #1
System #2
System #3
344
345
Figure 3—Common Interoperability System (CIS)
ISO/IEC JTC 1/SC 582713336
System #4
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
– 11 –
15045-2  ISO/IEC:2004
346
347
348
349
350
The CIS defines an abstract system, the Home Electronic System -Abstract System (HES-AS)
or language for expressing the set of common functions served by all home systems
(including individual HANs and WANs). Each sp ecific system is defined by a specific subset
of the CIS, known as a Generic Interworking Function (GIWF). The HES -AS and GWIF are
specified in ISO/IEC 18012, Guidelines for Product Interoperability.
351
6.2
352
353
354
355
356
357
358
The GIWF serves as a translator between the abstract (common) system and any specific
system. The abstract HES is expressed and conveyed by an RGIP (Residential Gateway
Internal Protocol) that includes a common protocol and an application language. In terms of
the 7-Layer OSI Reference Model (ISO 7489), the GIWF resides above layer 7 (application
layer) of the protocol stacks associated with any particular system’s interface module
processor. An HES-gateway stack model is described further in a later section on the HES gateway internal processes.
359
6.3
360
[brief description of the conformance paradigm and roles of manufacturers]
Generic Interworking Function (GIWF)
Conformance paradigm—roles
361
362
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
– 12 –
15045-2  ISO/IEC:2004
363
7
Architecture
364
365
The basic physical architecture of the HES-gateway including associated architectural
domains is shown in Figure 4.
366
Domain of HES-gateway
Domain of WAN
Domain of HAN
367
368
WAN
369
WAN
interface
module
370
371
HESgateway
internal
bus
and
RGIP
HAN
interface
module
HAN
service
module
372
373
374
Figure 4—HES-gateway Architectural Domains
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
The HES-gateway architecture consists of three domains, the domain of the HES -gateway
standard and the domains of the WAN and the HAN. The center block represents the HES gateway internal physical bus (optionally present) that conveys messages using the RGIP.
The interface modules shown in Figure 4 are provided by manufacturers seeking to support
various WAN or HAN networks. Each such module includes a portion that is in conformance
with the HES-gateway standard and talks the language of CIS (standardized in ISO/IEC
18012) using specific GIWFs residing on each module. These modules interconnect with each
other using the RGIP and internal bus. All information processing resides on indivi dual
modules and not on the bus or elswhere. The Internal Bus block depicted avove in Figure 4
represents only a data transfer or switching/arbitration function. There is no specific limit to
the number of modules (WAN, HAN, or service [see 7.3]) that ma y be accommodated in any
given configuration. However, the physical realisation of the RGIP and internal bus may set a
practical limit. Three basic types of modules comprise a HES -gateway: WAN interface
modules, HAN interface modules, and service modules (7.3). The latter two are associated
with the domain of the HAN.
390
7.1
391
392
393
394
395
396
397
398
A useful way of thinking about the HES-gateway architecture is in terms of the “Half -gateway”
module. The half-gateway is a modular unit that provides the services a nd interface for one
of the specific networks served by the HES-gateway. It communicates with the other half gateways by use of the HES-gateway internal bus and its RGIP. Each half -gateway provides
the translation from a specific network to the HES-AS language. The HES-AS language is
then transported over the internal bus to such other specific half -gateway as may be
appropriate. The HAN and WAN interface modules shown in figure 4 may be thought of as
half-gateways.
Half-gateway Modularity
399
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
– 13 –
15045-2  ISO/IEC:2004
400
401
402
Halfgateway
WAN
403
HAN
Appliance(s)
HES-gateway Internal bus
404
405
WAN
HAN
HAN
Appliance(s)
406
407
Figure 5—Half-gateway Model
408
409
410
411
412
413
Figure 5 depicts the use of two options for a half -gateway. The top example represents a
case where the half-gateway module is physically removed from the HES-gateway unit,
possibly co-located with an HAN appliance, and is linked by an extension of the internal bus
and protocol. In this case, the HAN translation takes place in the half -gateway. The bottom
example represents a case where the half-gateway employs a protocol that is already
interoperable with the end user HAN appliance(s).
414
415
416
The following half-gateway modules show the distribution of functionality within each module.
Only the portions of the drawings located within the “domain of the HES -gateway” are
intended to contain normative elements for purposes of this standa rd.
417
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 14 –
418
7.2
WAN interface module
419
420
421
422
423
424
The WAN interface module is a unit that provides a complete interface between a specific
WAN and the HES-gateway internal bus and RGIP. A generalised block diagram of the WAN
interface module is shown in Figure 6. The portion la belled “Domain of HES-Gateway” is
outside the WAN domain. For explanatory purposes, the following description will follow the
flow of data from WAN to HAN. Typical WANs might include access networks such as cable,
xDSL, DBS, optical fiber, or wireless (e.g., LMDS, MMDS, IEEE 802.16, etc.).
425
Domain of HES-gateway
426
427
428
429
430
WAN
Specific
WAN
interface
WAN
interface
processes
WAN
private
MIB
GIWF&
internal
processes
shared
MIB
RGIP
interface
processes
RGIP
private
MIB
RGIP
&
RG bus
interface
RGIP
& RG
bus
431
432
Figure 6—WAN Interface Block Diagram
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
The Specific WAN interface would include physical layer signalling, decoders or
demodulators. WAN interface processes would include data processing and any protocol
stack necessary to extract the message content meaningful to the application ( i.e., up to the
application layer (OSI layer 7)) and deliver it to the GIWF and internal gateway processes for
translation into the RGIP. The WAN interface proc esses are determined by the specific
manufacturer and could also include any processes necessary for management of the WAN
connection, according to the technology it supports, e.g. DSL, E1/T1, etc. A private memory
or MIB (Management Information Base) might be needed to maintain such a connection ( e.g.,
such as information relevant to maintaining a customer account relationship, passwords,
usage statistics, account codes, etc.). The use of the term “MIB” here is borrowed from the IP
(Internet Protocol) world, but in this case (unlike IP and SNMP—Simple Networking
Management Protocol) it is not intended to imply external access to the MIB by other than a
specific service provider. For instance, in the case of WAN modules, the intent is to provide a
place to store private information about the WAN connection, that would allow a service
provider or manufacturer to protect customer-specific information from competitors that may
also have WAN modules installed in the same HES-gateway system.
449
450
451
452
453
454
455
456
The GIWF and internal gateway processes may also have access to a MIB for storage of
information that might need to be shared by the WAN and the gateway ( e.g., connection
status, error, data format or routing information). Once the data has been translated into the
RGIP by the GIWF process, it is passed to the RGIP internal processes, including protocol
stack, that then passes it on to the internal bus and then to the appropriate HAN module(s).
The RGIP private MIB might be used to store information necessary for the proper delivery of
such information (e.g., HES-gateway internal configuration information, addressing and
routing, gateway management information, user preferences, access codes, etc.).
457
458
459
The portion of Figure 6 that lies within the domain of HES-gateway must be in conformance
with the standard. The structure and content of the remaining portion is entirely at the option
of the specific module manufacturer.
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 15 –
460
7.3
461
462
463
464
465
466
467
The HAN interface module is a unit that provides a complete interface between the HES gateway internal bus and RGIP and a specific HAN. A generalised block diagram of the HAN
interface module is shown in Figure 7. The portion labelled “Domain of HES -Gateway is
outside the HAN domain. Again, the data flow will be traced in the WAN to HAN direction for
purposes of explanation. Typical HANs might include IEEE 1394 (Firewire or I -Link), CEBus,
USB, Ethernet, IEEE 802.11 (WiFi), Bluetooth, Echonet, Konnex, HomePNA, NTSC video,
PAL video, or POTS.
468
HAN interface module
Domain of HES-gateway
469
RGIP
interface
processes
470
471
472
RGIP
&
RG
bus
RGIP
&
RG bus
interface
RGIP
private
MIB
473
GIWF &
internal
Processes
shared
MIB
HAN
interface
processes
HAN
private
MIB
specific
HAN
interface
HAN
474
475
Figure 7—HAN Interface Block Diagram
476
477
478
479
480
481
482
483
484
485
486
The operation of the HAN interface module follows a complementary pattern to the WAN
interface module. The internal bus delivers the RGIP data to a RG bus interface. It is then
passed to the RGIP interface processes where it is ex tracted up to layer 7 and delivered to
the GIWF for translation into the specific HAN protocol. The RGIP private MIB might be used
for storing local information such as internal configuration information ( e.g., addressing and
routing, gateway management information, etc.). The GIWF and internal processes block
formats the data and manages the appropriate user processes on the HAN side ( e.g.,
streaming, segmentation, error control, etc.), using a shared MIB, if necessary.
The
translated data are then passed to the HAN interface processes, which actually manages the
passing of data to the HAN devices, via the HAN specific interface. The HAN private MIB
might be used for HAN configuration or services information, addressing or routing.
487
488
489
490
The portion of Figure 7 that lies within the domain of HES-gateway must be in conformance
with this standard. The structure and content of the remaining portion is entirely at the option
of the specific module manufacturer. The HES-gateway portion is not responsible for spec ific
knowledge about the HAN configuration or managing its services.
491
7.4
492
493
494
495
496
497
498
499
500
A third type of module in the HES-gateway is the Service Module. The Service Module
resides in the domain of the HES-gateway and of the HAN. The Service Module has no HA N
interface but acts as an agent for managing specific services on the HAN by having access to
internal HES-gateway data traffic, and may be associated with specific HAN services. Typical
Service Module applications might include security, firewall, data encryption, AAA
(Authentication, Authorisation, and Accounting), energy management ( e.g., demand side
management, remote meter reading), entertainment ( e.g., Interactive TV, PPV, VOD, etc.), or
safety. Such applications and services might include those sp ecified by OSGi (Open Services
Gateway Initiative) or TAHI (The Application Home Initiative).
Service module
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 16 –
501
7.5
Data flows
502
503
504
505
506
507
The general data flows between the WAN and the HES-gateway system are shown in Figure
8, a copy of Figure 6 with data “pipes” overlaid to illustrate th e termination of three kinds of
data streams. The various functions in the HES-gateway may be managed remotely or from
within the HAN, or by a combination of both. Individual portions of the HES -gateway (HAN or
WAN modules) may be managed by separate entities requiring multiple remote management
functions.
508
Domain of HES-gateway
509
510
WAN
GIWF&
interface
User Service internal
Functions
processes
processes
511
512
WAN
Specific
WAN interface
WAN
Gateway Functions
private
MIB
WAN Functions
513
514
RGIP
interface
processes
shared MIB
RGIP
private MIB
RGIP
&
RG bus
interface
RGIP
& RG
bus
515
516
Figure 8—Data Flows
517
518
519
520
521
522
523
WAN functions are those that are only intended to manage the specific WAN interface and are
the domain of the WAN service provider (e.g., connection establishment signalling, access
authorization, accounting, etc.). The gateway functions are those that are shared between
the WAN service provider and the gateway, but do not pass through the gateway to the HAN
side (e.g., resource binding or routing information). User service functions are those that flow
through to some application in the domain of the HAN ( e.g., a video data stream, user data,
etc.).
524
7.5.1
525
526
527
528
529
530
531
[description of control information processing; It is clear that the RGIP will imply a lot of
control plane processing, especially in the half -gateway case where connection will possibly
be transient. However, how are you going to write this into this standard when no external
reference exists? SIP, for example is the usual pr otocol put forward by the IP community.
There is no equivalent from telcos – SS#7 does not provide for user interaction except via
local DTMF and possibly other proprietary signalling.
Sorry – maybe I’m confused.
Teleconference topic?]
532
7.5.2
533
534
[description of content (data) processing; resource “discovery process”: bandwidth etc. info
available to service providers – available in the WAN-side or shared MIB?]
535
8
536
537
The HES-gateway internal processes include: 1) protocol stacks for both specific networks
and the RGIP, 2) the RGIP, 3) the internal bus, and 4) network management functions.
Control plane
Content (data) plane
Internal Processes
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 17 –
538
8.1
Protocol stacks
539
8.1.1
Generalised model
540
541
542
543
544
A generalised model of the HES-gateway protocol stacks is shown in Figure 9. These stacks
follow the convention of the OSI (Open Systems Interconnection) 7 layer model, which
describes communication functions from the physical layer (layer 1) through the application
layer (layer 7). The OSI model is used here for illustrative purposes only and is not intended
to be normative. The stack models in Figure 9 apply to either WAN or HAN modules.
545
HES-gateway Module #1
HES-gateway Module #2
GIWF: 1< > abstract system
GIWF: 2< > abstract system
548
Application
Application
Application
Application
549
Presentation
Presentation
Presentation
Presentation
550
Session
Session
Session
Session
Transport
Transport
Transport
Transport
552
Network
Network
Network
Network
553
Data Link
Data Link
Data Link
Data Link
554
Physical
Physical
Physical
Physical
546
GIWF
Application
547
551
OSI
Layers
555
556
HES-gateway internal bus
Data
Transfer
HES-gateway RGIP
Network 1
Network 2
557
558
Figure 9—HES-gateway Generalised Protocol Stack Model
559
560
561
562
563
564
565
566
567
Data transfer from network 1 to network 2 would begi n by entering the network 1 HESgateway module and passing upward to the top of the specific network 1 stack where it is then
passed to the GIWF which exists above the application layer. The GIWF translates the
network 1 application language into the RGIP and then sends it downward through the RGIP
stack to the HES-gateway internal bus. The data are transferred by the internal bus to the
network 2 HES-gateway module where it is passed upward through its RGIP stack to the
GIWF where it is translated into the application language of network 2. The data are then
passed down the specific network 2 stack to network 2 —and then on to its final destination on
network 2.
568
569
570
571
572
The specific network stacks are defined by the specific product manufacturer or by existing
standards or other specifications. Many of these stacks may be accumulated and maintained
in an open source library for use by those developing HES -gateway modules.
Also
associated with each of these stacks is a GIWF mapping the specific protocol to the ab stract
system defined as part of the HES-gateway CIS.
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 18 –
Specific model – simple gateway
573
8.1.2
574
575
576
The simple gateway protocol stack model (one WAN, one HAN) is depicted in the figure
below. It eliminates the RGIP and internal bus by incorporating both half -gateways on a
single module to form a complete one-to-one gateway.
577
HES-gateway Simple Gateway Module
578
GIWF: 1< > abstract system
579
abstract system < > GIWF: 2
580
581
582
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Data Link
Data Link
Physical
Physical
Network 1
Network 2
583
OSI
Layers
584
585
586
587
588
Data
Transfer
589
590
Figure 10—HES-gateway Special Case: Simple Gateway Protocol Stack Model
591
592
8.1.3
GIWF application
593
594
595
596
597
598
599
600
It is important to note that the GIWF is the application and not part of its associated stacks.
The HES-gateway standard specifies the GIWF and the RGIP portions of this model.
However, there is nothing to preclude additional application functions being added on top of
the GIWF, depending on the particular network app lication being served. For instance,
various service agents might reside above the GIWF, monitor the data flow, and modify or
control the flow of data, or even initiate data messages, as might be appropriate to any
particular application. An example might be the insertion of routing or addressing information,
or perhaps to establish or terminate a data-stream connection.
601
602
603
In the case of the service module, the specific network stacks would be absent and only the
RGIP would be employed. For example, typical service agents might include those specified
by the OSGi or TAHI consortia.
604
8.1.4
Data flow control plane signalling
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
– 19 –
15045-2  ISO/IEC:2004
605
[Text to be added.]
606
607
608
609
610
611
Figure 14, as a generalised model, might be taken to imply that all communication into and
out of HES-gateway traverses all 7 layers of the ISO stack. Although this would be true in
regard to “control plane” signalling, it would not be strictly true in cases of other data plane or
data steam traffic. Some traffic will connect at the physical layer, data link layer, or networ k
layer, as perhaps in the case of TLS or IPsec. Other traffic having little in the way of protocol
stack, such as analogue CATV or POTS, may need to connect at the physical layer.
612
8.2
613
614
615
616
617
618
619
The term, RGIP (Residential Gateway Internal Protocol) is used here to refer to a complete 7
layer protocol (temporary insertion: “including the lower -layer protocols being used, which are
typically commonly-used protocols such as IP or Ethernet”) and an HES oriented application
language that includes a syntactic structure and semantic definitions comprising a lexicon of
terms including objects and methods (actions). The RGIP is defined and standardised in such
a way that it will allow the GIWF process to express ( i.e., translate) any message to or from
any specific HAN or WAN message.
620
8.3
621
622
623
624
625
626
627
The HES-gateway internal bus, if present, may be implemented using a high speed point -topoint serial bus (e.g., such as Ethernet, USB, or IEEE 1394[c1]). A common module
connector will deliver both data and power. Although the transfer of isochronous data within
the gateway will be frequently needed, a high data rate and a relatively small number of
modules employed will allow for adequate internal bandwidth to avoid congestion. Also with
some standard busses, higher data rates may be anticipated to be available for later
implementations that will be upward compatible.
628
629
630
Two internal bus topologies are specified . The first is a star topology, where every module is
connected via a switch module. Alternativel y, for higher speeds, a mesh topology can be
implemented, eliminating the need for a switch module.
631
632
633
The high-speed point-to-point serial electrical specifications are drawn from the IEEE 802.3ae
(XAUI) standard [6] for 10 Gbit Ethernet. Only one lane is required for HES instead of the 4
lanes for XAUI. The transfer baud rate is up to 3.125 Gbps.
634
635
636
637
638
639
640
641
The internal bus can be extended directly between clusters of modules, permitting a
distributed gateway. Modules can be independently powered or clusters may o btain their
power separately using modular wall plug power supplies, thus easing the task of expanding
the HES-gateway system incrementally. Alternatively, the internal bus can be extended by
the use of a tunneling protocol employing one of the HAN networ ks common to both clusters.
Such tunneling could even employ wireless HANs, although such may impose bandwidth
limitations, depending on the situation. Figure 11 depicts the HES -gateway internal bus
extension methods described above..
Internal Protocol (RGIP)
Internal bus
642
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 20 –
643
644
HES-gateway chassis 1
645
646
HAN a
WAN x
647
648
protocol c
Interface
HES-gateway Internal bus
649
650
interconnect
tunnel via
protocol c
HES-gateway chassis 2
651
protocol c
Interface
WAN y
652
653
HAN b
654
655
656
Figure 11—HES-gateway Internal Bus Extension Methods
657
8.4
Service requirements
658
659
660
The HES-gateway will provide for the possibility of some level of uninterruptable power, such
that basic services may be preserved independently of the availability of house power, much
as in the case of POTS.
661
8.5
662
663
664
665
666
667
The HES-gateway system, if implemented as a Distributed Gateway System, has no central
controller. Modules may be installed at any time and a set of basic network man agement
elements provided on each module will allow dynamic self -configuration. Depending on
system or service requirements, more advanced network management elements could later
be added in the form of a specialised service module. The HES -gateway standard will include
basic network management elements dealing with the following internal gateway processes:
668

Module address allocation
669

Module service discovery
670

Inter-module packet priority and routing
671
Other network management functions may be provided b y modular applications.
672
8.5.1
Module address allocation
673
8.5.2
Module service discovery
674
8.5.3
Inter-module packet priority and routing
Network management
675
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
– 21 –
15045-2  ISO/IEC:2004
676
9
Conformance
677
9.1
Basic functions and requirements
678
679
HES products and networks shall be required to implement the requirements of this standard
of product interoperability under the following qualifying criteria:
680

Where two or more dissimilar HANs are installed or implemented in a premises
681

Where two or more dissimilar HANs are required to interoperate or interwork in a premises
682
683

Where a product acts as a bridge, router, gateway or residential gateway between two or
more dissimilar HANs in a premises
684
9.2
685
686
In order to conform to this standard of Product Interoperability, products and networks that
meet the qualifying criteria shall:
687
688

Implement functional safety as specified in ISO/IEC TR 14762 Guidelines for Functional
Safety for Home Control Systems.
689

Implement measures to avoid or minimise potential hazards as specified in Section 5.
Compliance of qualifying products and networks
690
691

Prevent the unattended initiation/operation of potentially hazardous devices as
specified in Section 5.2
692
693
694

Allow initiation commands to be sent to automatic or relocatable programmable
devices only if the device can return reliably explicit information as to the state of the
load on the device as specified in 5.3 and 5.4
695
696
697

Implement specific rules for instances where commands from one HAN actuate
devices on another dissimilar HAN as specified in 5.5 or if there is a situation of linked
state changes between them as specified in 5.6
698
699

Ensure security measures are implemented if commands derive from a WAN source as
specified in 5.7
700
701

Ensure that address translation between dissimilar HANs is clearly defined and
disallow commands and broadcast messages if not, as specified in 5.8 and 5.9
702
703

Manage the installation of HES products and configuration interworking as specified in
Section 6.
704
705
706

Installation, configuration and management shall be carried out by personnel and
systems appropriate to the procedures provided by the HAN as specified in 6.2 and
6.3.
707
708
709

If two dissimilar HANs are configured in premises, this shall be carried out by
personnel and systems appropriate to the procedures provided by the more complex
HAN as specified in 6.2 and 6.3.
710
711

To provide configuration interoperability, devices are require d to support the
components of configuration levels 1 to 4 as specified in 6.2 and Table 1.
712
713
714
715

To provide configuration interoperability for devices on multiple and dissimilar
networks, the components of configuration levels 1 to 4 shall be supported by the e ndpoint devices as well as the device between the networks as specified in 6.2 and Table
1.
716
717
718
719

Network or networks operating within a premises require that addressing, transport, data
and applications shall interoperate as specified in Section 7.

The logical addressing scheme used shall be independent of the underlying transport
mechanism as specified in 7.2
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
– 22 –
15045-2  ISO/IEC:2004
720
721
722

Translation between the logical addressing scheme and the transport addressing
scheme shall be handled as a mapping function of the layer that binds the logical
network to a particular transport as specified in 7.2
723
724

For a networked system to be interoperable, it shall support one of the three network
configurations specified in 7.3
725
726

To provide information exchange interoperability, there shall be a common, d efined set
of value type primitives in a common lexicon as described in 7.4 and 7.5
727
728
729
730

A lexicon of common actions shall be defined as specified in 7.5 for direct translation
between networks and for a common language for configuration and application
actions such that actions of an application on one network shall be translated correctly
to the actions of the same application on another network in the premises.
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 23 –
Annex A
(Informative)
731
732
733
734
735
Case Examples
736
A. Overview of case examples
737
738
739
This section includes block diagrams depicting a series of case examples of “typical” or
“possible” HES-gateway configurations or scenarios applying the generalized architecture
specified earlier. These case examples are provided for purposes of illustration.
740
1.1 VDSL scenario
741
WAN services
742
743
VDSL
access
WAN interfaces
VDSL
decoder
ATM
SAR
744
HAN interfaces
MPEG 2
RF
decoder modulator
Ethernet
interface
745
746
HES-gateway Internal bus
747
VoIP
decoder
POTS
converter
HAN appliances
TV
set
PC
phones
748
Figure A.1—VDSL Scenario
749
750
751
752
753
754
755
756
757
758
759
760
761
Figure A.1 depicts the use of VDSL (Very-high-speed Digital Subscriber Line) service to
provide voice, video and data service to the home. In this particular case, voice, video and
data packets are delivered via VDSL (layer 1) service employing ATM (Asynchronous
Transfer Mode) packet switching technology. The video packets, using MPEG 2 compression,
in this example, are then decoded and converted to conventional RF modulated video and
audio signals for display on a conventional TV set. A typical installation might employ more
than one MPEG 2 interface module, depending on the capacity of the VDSL access service
and the needs of the viewer. The MPEG 2 interface might also include a remote control
receiver for initiating data traffic back to the video source to change channels or other
purposes. In this example, the VoIP decoder could use a POTS (Plain Old Telephone
Service) converter to provide multiple phone lines to the home and allow the use o f
conventional telephone sets. The Ethernet interface might also provide a hub for multiple
PCs or other Ethernet-based appliances.
762
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 24 –
763
764
1.2 VDSL scenario
765
WAN services
766
767
768
769
DSL
access
DBS
dish
WAN interfaces
DSL
decoder
ATM
SAR
DBS
receiver
770
771
HES-gateway Internal bus
HAN interfaces
HAN appliances
MPEG 2
RF
decoder modulator
TV
set
Ethernet
interface
VoIP
decoder
PC
POTS
converter
phones
772
Figure A.2—DBS/DSL Scenario
773
774
775
776
777
778
Figure A.2 depicts the use of DBS (Direct Broadcast Satellite) combined with DSL (Digital
Subscriber Line) service to provide voice, video and data service to the home, much as in the
preceding figure. In this case, video is provided by DBS and voice and data are provided by
DSL. This arrangement may be employed where VDSL service is not available, or where DBS
delivery is more advantageous. Also, DSL provides a reverse channel for the DBS service for
PPV (Pay-Per-View), service provisioning or other interactive applications.
779
WAN services
780
DSL
access
781
782
783
cable
drop
WAN interfaces
DSL
decoder
ATM
SAR
digital cable
decoder
784
HES-gateway Internal bus
HAN interfaces
HAN appliances
MPEG 2
RF
decoder modulator
TV
set
Ethernet
interface
PC
CEBus
interface
Meter, energy
appliances
785
786
energy management
service module
787
788
Figure A.3—Cable/DSL/Energy Management CEBus Scenario
789
790
791
792
793
Figure A.3 depicts the use of cable combined with DSL service to provide video and data
service to the home. Such an arrangement might be employed when data service over cable
is not available or when DSL might also be desirable for certain services. In this example, a
CEBus (Consumer Electronics Bus) interface is also shown that might be used for remote
meter reading and energy management functions. These functions might be managed by a
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 25 –
794
795
special service module provided by an energy utility or other service provider offering
efficiency and cost advantages to the user.
796
1.3 Healthcare management scenario
797
WAN services
798
DSL
access
WAN interfaces
DSL
decoder
ATM
SAR
HAN interfaces
IEEE 802.11WiFi
interface
799
800
801
HAN appliances
healthcare
appliances
healthcare monitoring
service module
HES-gateway Internal bus
802
803
Figure A.4—Healthcare Management Suggestion
804
805
806
807
808
Figure A.4 depicts the use of DSL service to provide data service to specialized healthcare
monitoring and management applications in the home. The specific healthcare appliances
might employ wireless connections and be managed by a special service module provided by
medical or healthcare related services. The DSL access could also be shared with other
entertainment, data or communication applications shown in the previous figures.
809
1.4 DSL/HomePNA scenario
810
811
812
813
814
WAN services
DSL
access
(over
POTS)
WAN interfaces
DSL
decoder
ATM
SAR
HES-gateway Internal bus
HAN interfaces
HAN appliances
HomePNA
interface
POTS wiring
HomePNA
bridge
POTS
Phones
Ethernet
Appliances
815
816
Figure A.5—DSL/HomePNA Scenario
817
818
819
820
821
822
823
824
Figure A.5 depicts the use of DSL service and HomePNA (Home Phone Network Alliance)
signalling technology utilising the existing POTS wiring and connectors to provide combined
conventional voice and Ethernet data services. The HomePNA interface module combines
the analogue voice POTS signals with the digital Ethernet signals to convey the voice and
data services from the WAN interface.
A HomePNA bridge can extract the
Ethernet/HomePNA signals or provide other appropria te formats, such as USB (Universal
Serial Bus) or PCI (Peripheral Component Interconnect), to be used by various data
application terminals.
825
826
827
828
829
Note that if one of the Ethernet Appliances on the HAN is a bridge to another HAN
technology, such as 802.11x (wireless) or HomePlug (utilising PLC - Power Line Carrier), this
simple HAN can be expanded with segments based on different HAN technologies. This
expansion of the HAN opens the possibility of receiving other WAN services through separate
HES-gateways connected to these appended HAN segments.
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 26 –
830
831
832
Annex B
(Informative)
833
834
Internal Bus Topologies
835
B. Overview of internal bus topologies
836
837
838
This Annex shows HES-gateway internal bus topologies.
The internal bus may be
implemented in either a mesh topology or a star topology; or it may include a combination of
both. These topological examples are provided for purposes of illustration.
839
1.5 Mesh topology
840
841
842
843
844
845
The mesh topology provides a direct, dedicated path from each node to every other node.
Packet routing or switching is accomplished by appropriate hardware in each node in order to
select a dedicated signal path between each module (node). A single backplane of connected
modules (nodes) would require a sufficient number of electrical conductors to provide a
separate transmit, receive, common, and ground between each module that might share the
common backplane. A diagram of the mesh topology is provided in figure B1.
846
847
N
848
N
N
849
N
850
N
851
852
N
N
N
853
854
Figure B.1—Mesh Topology
855
1.6 Star topology
856
857
858
859
860
861
The star topology provides a shared path between each node in the network. Packet routing
or switching is accomplished by a central switch device that reads packet addresses and
directs the packet to the appropriate destination node. The star topology is more efficient in
the use of connectors and conductors, but requi res an additional infrastructure element to
provide the switching function. Also, the star topology imposes speed limitations because of
the shared nature of the transmission path.
862
863
864
865
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 27 –
866
867
N
868
N
869
N
870
871
872
S
N
N
873
874
875
N
876
N
877
N
878
879
Figure B.2—Star Topology
880
881
882
1.7 Combined mesh and star topology
883
884
885
The mesh topology may be combined with a star topology. In this case, one of the mesh
nodes routes packets to the switch of the star network. A diagram of the combined mesh and
star topology is provided in figure B3.
886
N
N
887
N
N
N
N
888
889
N
S
NN
N
890
891
N
892
N
N
N
N
N
893
894
Figure B.3—Combined Mesh and Star Topology
895
ISO/IEC JTC 1/SC 582713336
ISO/IEC FDIS 15045-2  IEC:2004
ISO/IEC JTC1 SC25/WG 1 N 1xxx
15045-2  ISO/IEC:2004
– 28 –
896
Bibliography
897
898
899
EN 41 003, Particular safety
telecommunications networks
requirements
for
equipment
to
be
connected
to
900
IEC 60950-1, Information technology equipment - Safety - Part 1: General requirements
901
902
IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic
safety-related systems
903
904
905
906
IEC 62151, Safety of equipment electrically connected to a telecommunication network
ISO/IEC TR-14543 (all parts), Information technology - Home Electronic System (HES)
Architecture
ISO/IEC JTC 1/SC 582713336