Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.
This standard specifies formats and methods for floating-point arithmetic in computer systems: standard and extended functions with single, double, extended, and extendable precision, and recommends formats for data interchange. Exception conditions are defined and standard handling of these conditions is specified.
This standard defines a protocol and procedures for the transport of timing over bridged and virtual bridged local area networks. It includes the transport of synchronized time, the selection of the timing source (i.e., best master), and the indication of the occurrence and magnitude of timing impairments (i.e., phase and frequency discontinuities). The PDF of this standard is available at the IEEEGET program. The "IEEE Get Program" grants public access to view and download individual PDFs of select standards at no charge. Visit http://standards.ieee.org/about/get/index.html for details.
This standard specifies how the MAC Service is supported by Virtual Bridged Local Area Networks, the principles of operation of those networks, and the operation of VLAN-aware Bridges, including management, protocols, and algorithms. Incorporates IEEE Std 802.1Q-2005, IEEE Std 802.1ad-2005, IEEE Std 802.1ak-2007, IEEE Std 802.1ag-2007, IEEE Std 802.1ah-2008, IEEE Std 802-1Q-2005/Cor-1-2008, IEEE Std 802.1ap-2008, IEEE Std 802.1Qaw-2009, IEEE Std 802.1Qay-2009, IEEE Std 802.1aj-2009, IEEE Std 802.1Qav-2009, IEEE Std Qau-2010, and IEEE Std Qat-2010. The PDF of this standard is available at no cost, compliments of the IEEE 802 group. http://grouper.ieee.org/groups/802/1/
A standardized framework for the Smart Appliances Reference Ontology based on the results of a European Commission Study Group on Smart Appliances ontologies and of a Specialist Task Force on the maintenance and evolution of the Reference Ontology taking into account all the interest of the relevant stakeholders.
The Internet of Things (IoT) is predicted to become one of the most significant drivers of growth in various technology markets. Most current standardization activities are confined to very specific verticals and represent islands of disjointed and often redundant development. The architectural framework defined in this standard will promote cross-domain interaction, aid system interoperability and functional compatibility, and further fuel the growth of the IoT market. The adoption of a unified approach to the development of IoT systems will reduce industry fragmentation and create a critical mass of multi-stakeholder activities around the world.
The present document addresses the requirements for communications between the authorized representatives who can be involved in the responses and actions when handling an emergency. It describes the functional requirements for communications between the authorized representatives involved in the responses and actions when handling an emergency. The level of precision has been chosen to avoid interaction with the specific local, regional or national organizations and diagrams of relations between authorized representatives. It follows from this that adaptations will have to be done when implementing the present document at a local level. Furthermore, the scope of the present document also encompasses various types of services that can bring an added value to this basic scenario or add new scenarios, such as the services brought by other technologies e.g. IoT devices that support communications between authorities during emergencies.
The Pan-European Mobile Emergency Application (PEMEA) architecture provides the requirements and architecture for a solution to provide emergency application interconnection. It specifies the protocols and procedures enabling interoperable implementations of the architecture and provides extension points to enable new communication mechanisms as they evolve.
Cellular IoT support and evoluation for the 5G system (SP-18118) is a 3GPP completed work item (WID) for Release 16 as part of the stage 2 work (5G phase 2).
The frequency bands used for broadcasting below 30 MHz are: •Low Frequency (LF) band: from 148,5 kHz to 283,5 kHz, in ITU Region 1 [1] only; •Medium Frequency (MF) band: from 526,5 kHz to 1 606,5 kHz, in ITU Regions 1 [1] and 3 [1] and from 525 kHz to 1 705 kHz in ITU Region 2 [1]; •High Frequency (HF) band: a set of individual broadcasting bands in the frequency range 2,3 MHz to 27 MHz, generally available on a Worldwide basis. These bands offer unique propagation capabilities that permit the achievement of: •large coverage areas, whose size and location may be dependent upon the time of day, season of the year or period in the (approximately) 11 year sunspot cycle; •portable and mobile reception with relatively little impairment caused by the environment surrounding the receiver. There is thus a desire to continue broadcasting in these bands, perhaps especially in the case of international broadcasting where the HF bands offer the only reception possibilities which do not also involve the use of local repeater stations.
The present document is a choice of Test Purposes Description Language (TPDL), with the intention to capture all of the information required by the Test Template and should be parseable using software.
The Testing Framework (document format) specifies a testing framework defining a methodology for the development of the test strategies, test systems and resulting test specifications. The present document identifies the implementation under test (scope of the testing), the format for the test specification, the test architecture, the points of control and observation, the naming conventions (e.g. for test case ID and test case grouping ID), etc. It also provides the Implementation Conformance Statement which is basically a checklist for a client-owner so they know what parts of the specification will be tested and if any is optional. The ICS will be published as a separate GS.
