Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Deep packet inspection wikipedia , lookup
Bus (computing) wikipedia , lookup
Network tap wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Computer network wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Internet protocol suite wikipedia , lookup
Airborne Networking wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
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 #1AS #2AS #3AS #4AS 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