FI-WARE architecture view Sample Clauses

FI-WARE architecture view. Figure 5 shows the IoT architecture as defined by the FI-WARE project. This architecture has already taken into account the ETSI M2M specification and has extended it to incorporate OMA NGSI work [9]. The following large functional blocks can be identified in this architecture: backend, Gateway, IoT devices and legacy devices. The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of devices, several Gateways and the backend. The Generic Enablers shown in the figure below implement functionalities distributed across these elements. The backend functional block provides a number of functions and acts as the main interfaces to access the IoT devices and the information they produce. It provides both REST and NGSI interfaces for interaction with the users as well as corresponding functions like things and resources management; publish/subscribe functionality and connectivity management. The backend can be connected southbound to Gateways and/or IoT compliant devices (devices that will implement the standardised interface i.e. ETSI M2M). Backend consists of three main GEs, namely IoT Broker, Configuration Management and Backend Device Management. The IoT Broker GE is a component for retrieving and aggregating information from the Internet of Things. The Configuration Manager GE (ConfMan GE for short) is the part of the IoT Backend which is responsible for context availability registration. The Backend Device Management GE is the central component for the IoT backend. It provides the resource-level management of remote assets (devices with sensors and/or actuators) as well as core communication capabilities such as basic IP connectivity and management of disconnected devices. The Gateway provides similar functionality, but on the local level, i.e. it provides functions like things and resource management for the IoT and legacy devices connected to the Gateway. It consists of three GEs, namely Data Handling, Gateway Device Management and Protocol Adapter. The Gateway Device Management GE contains much of the "core" Gateway functionality. It is responsible for the communication with the Backend and IoT and non-IoT devices. The Gateway Device Management GE includes the functional components to handle the registration/connection phases towards the Backend/Platform, to translate the incoming data or messages in an internal format and to send the outgoing data or messages in the ETSI M2M format (marshal...
Sample 1
AutoNDA by SimpleDocs
FI-WARE architecture view. Figure 2 shows the IoT architecture as defined by the FI-WARE project. This architecture has already taken into account the ETSI M2M specification and has extended it to incorporate OMA NGSI work [8]. The following large functional blocks can be identified in this architecture: backend, gateway, IoT devices and legacy devices. The backend functional block provides a number of functions and acts as the main interfaces to access the IoT devices and the information they produce. It provides both ETSI M2M and NGSI interface for interaction with the users as well as corresponding functions like things and resources management; publish/subscribe functionality and connectivity management. The gateway provides similar functionality, but on the local level, i.e. it provides functions like things and resource management for the IoT and legacy devices connected to the gateway. IoT devices can be connected to a gateway (e.g. IPv4-based devices with private addresses) or directly to the backend (e.g. IPv6-based devices with public addresses). Legacy devices are always connected via a gateway. Figure 2: FI-WARE IoT architecture [5] IoT6 Architecture
Sample 1

Related to FI-WARE architecture view

  • Network Interconnection Architecture Each Party will plan, design, construct and maintain the facilities within their respective systems as are necessary and proper for the provision of traffic covered by this Agreement. These facilities include but are not limited to, a sufficient number of trunks to the point of interconnection with the tandem company, and sufficient interoffice and interexchange facilities and trunks between its own central offices to adequately handle traffic between all central offices within the service areas at P.01 grade of service or better. The provisioning and engineering of such services and facilities will comply with generally accepted industry methods and practices, and will observe the rules and regulations of the lawfully established tariffs applicable to the services provided.

  • Architecture The Private Improvements shall have architectural features, detailing, and design elements in accordance with the Project Schematic Drawings. All accessory screening walls or fences, if necessary, shall use similar primary material, color, and detailing as on the Private Improvements.

  • Configuration Management The Contractor shall maintain a configuration management program, which shall provide for the administrative and functional systems necessary for configuration identification, control, status accounting and reporting, to ensure configuration identity with the UCEU and associated cables produced by the Contractor. The Contractor shall maintain a Contractor approved Configuration Management Plan that complies with ANSI/EIA-649 2011. Notwithstanding ANSI/EIA-649 2011, the Contractor’s configuration management program shall comply with the VLS Configuration Management Plans, TL130-AD-PLN-010-VLS, and shall comply with the following:

  • Trunk Group Architecture and Traffic Routing The Parties shall jointly engineer and configure Local/IntraLATA Trunks over the physical Interconnection arrangements as follows:

  • Information Technology Enterprise Architecture Requirements If this Contract involves information technology-related products or services, the Contractor agrees that all such products or services are compatible with any of the technology standards found at xxxxx://xxx.xx.xxx/iot/2394.htm that are applicable, including the assistive technology standard. The State may terminate this Contract for default if the terms of this paragraph are breached.

  • Interface A defined set of transmission facilities that separate Load Zones and that separate the NYCA from adjacent Control Areas. Investor-Owned Transmission Owners. A Transmission Owner that is owned by private investors. At the present time these include: Central Xxxxxx Gas & Electric Corporation, Consolidated Edison Company of New York, Inc., New York State Electric & Gas Corporation, Niagara Mohawk Power Corporation, Orange and Rockland Utilities, Inc., and Rochester Gas and Electric Corporation.

  • Access Toll Connecting Trunk Group Architecture 9.2.1 If CBB chooses to subtend a Verizon access Tandem, CBB’s NPA/NXX must be assigned by CBB to subtend the same Verizon access Tandem that a Verizon NPA/NXX serving the same Rate Center Area subtends as identified in the LERG.

  • Interfaces Bellcore’s GR-446-CORE defines the interface between the administration system and LIDB including specific message formats. (Bellcore’s TR-NWP-000029, Section 10)

  • Network Interface Device (NID) 2.7.1 The NID is defined as any means of interconnection of end-user customer premises wiring to BellSouth’s distribution plant, such as a cross-connect device used for that purpose. The NID is a single-line termination device or that portion of a multiple-line termination device required to terminate a single line or circuit at the premises. The NID features two independent xxxxxxxx or divisions that separate the service provider’s network from the end user’s customer-premises wiring. Each chamber or division contains the appropriate connection points or posts to which the service provider and the end user each make their connections. The NID provides a protective ground connection and is capable of terminating cables such as twisted pair cable.

  • Physical Architecture 59.2.1 CenturyLink's network architecture in any given local exchange area and/or LATA can vary markedly from another local exchange area/LATA. Using one or more of the NIMs herein, the Parties will agree to a physical architecture plan for a specific LATA, or if appropriate based on other requirements in Section 59, Local Calling Area. The physical architecture plan, as described in the Local Interconnection POI Profile, will be discussed during joint implementation planning. CLEC and CenturyLink agree to Interconnect their networks through existing and/or new Interconnection Facilities between CLEC switch(es) and CenturyLink's End Office Switch(es) and/or Tandem Switch(es). The physical architecture plan will be in accordance with Forecasting and Planning requirements in Article IV.

Time is Money Join Law Insider Premium to draft better contracts faster.