我的标准
购物车
400-168-0010
This standard defines an abstraction layer for multiple home network technologies. The abstraction layer provides a common data and control service access point to the heterogeneous home network technologies described in the following specifications: IEEE Std 1901TM-2010, IEEE Std 802.11TM-2012, IEEE Std 802.3TM-2008, and MoCA® 1.1.1,2 This standard is extensible to work with other home network technologies. The abstraction layer supports a dynamic interface selection for transmission of packets arriving from any interface (upper protocol layers or underlying network technologies). End-to-end quality of service (QoS) is enabled in an IEEE 1905.1 network. Also specified are procedures, protocols, and guidelines to provide a simplified user experience to add devices to the network, to set up encryption keys, to extend the network coverage, and to provide network management features to address issues related to neighbor discovery, topology discovery, interface selection, QoS negotiation, and network control and management.
The scope of this document is as follows: a) In bridged networks running MTBP, ports shall be identified as either a meshed tree port that participates in the meshed tree resolution, or a host port, to which a local host is connected. Only meshed tree ports are allowed to participate in the meshed tree resolution. b) MTBP provides superior fault tolerance by preconfiguring several logical trees from a root. One of these logical trees is considered the primary tree and is used for forwarding… read more broadcast frames. In the event of a network component failure and immediately on failure detection of the primary branch, broadcast frame forwarding is taken over by any one of the other preconfigured tree branches. This is achieved with minimal message dissemination and delay. c) The addition of a bridge configured to run MTBP will allow the bridge to send a request to join (via MT_JOIN message) message to all other bridges to which it is connected. The new bridge will join the bridges already in the topology. The new bridge then receives multiple invitations from its neighbors to join tree branches that they are already part of. The new bridge decides to join the multiple tree branches and stores the multiple paths in order of preference. One of these paths shall be the path for broadcast frame forwarding. read less
This standard specifies the following: Architecture for the transport of mobile fronthaul traffic over packet-based networks (e.g., Ethernet), including user data traffic, and management and control plane traffic; Requirements and definitions for the fronthaul networks, including data rates, timing and synchronization, and quality of service (QoS). The standard also analyzes functional partitioning schemes between remote radio units (RRUs) and baseband units (BBUs) that improve fronthaul link… read more efficiency and interoperability among transport equipment, and that facilitate the realization of cooperative radio functions, such as massive multiple input read less
IEEE Std 1920.1 defines air-to-air communications over self-organized aerial ad hoc networks and describes the reference architecture for aerial networks, where aircraft can form a network to share information with one another with or without any supporting infrastructure, such as satellite or cellular communications. This standard is intended for RLOS and BRLOS small UASs used for civil and commercial applications. The architecture can also be extended to include additional platforms, making… read more it a useful guide for other aircraft systems. The communications and networking standards are independent of the type of network (wireless, cellular, or other). The main objective of the IEEE Std 1920.1 data model is to define and format data consistently in a common, secure data structure that can be leveraged across the industry. This can help improve the integrity, safety, and security of the data regardless of the types of use cases, communication technologies, or diversity of the vehicles utilized. IEEE Std 1920.1 does not specify procedures or protocols that define the means to access radio-frequency spectrum and manage its use (i.e., an "air interface"). IEEE Std 1920.1 does not specify the size, maximum take-off weight (MTOW), modes of propulsion, and other characteristics of the UAS. It is expected that most UASs with less than 250 kg MTOW can use the protocols defined in IEEE Std 1920.1. An MTOW above 250 kg would put the UAS in the scope of certification requirements that impose requirements beyond those applicable to aircraft operating communications services within the scope of IEEE Std 1920.1. read less
This standard specifies a method for computation of an energy efficiency upper bound for an apparatus processing a particular communication signal waveform. This method utilizes the signal envelope probability density function in combination with apparatus' power dissipation characteristics.
This recommended practice specifies a set of guidelines for the development of power-proportional digital architectures so that energy is only consumed when computations are underway. Digital architectures could encompass individual devices such as CPUs and systems on chip (SoCs), or specialized computing platforms such as smartphones, smartwatches, and individual servers, or larger systems and networks of distributed compute and data servers. These architectures could consist of components such as processors, specialized accelerators, memory, interconnects, storage, networks, and power supplies. In power-proportional power supplies, various techniques can be used to conserve and store energy when computation is halted, keeping it available for immediate use upon restart. The objective of such power supplies is to respond to nanosecond variations in the computing load in the presence of complementary metal-oxide semiconductor (CMOS) static power dissipation.
This standard establishes a framework for drone interface to payload. It defines the interfaces, performance metrics, provisioning, operation control, and management for drone payload devices. This standard specifies payload interface requirements for drones that have a maximum take-off mass (MTOM) less than 25 kg, the drones' built-in payload not included.
1.1 General This part of ISO/IEC 20000 is a service management system (SMS) standard. It specifies requirements for the service provider to plan, establish, implement, operate, monitor, review, maintain and improve an SMS. The requirements include the design, transition, delivery and improvement of services to fulfill service requirements. This part of ISO/IEC 20000 can be used by: a) an organization seeking services from service providers and requiring assurance that their service requirements… read more will be fulfilled; b) an organization that requires a consistent approach by all its service providers, including those in a supply chain; c) a service provider that intends to demonstrate its capability for the design, transition, delivery and improvement of services that fulfill service requirements; d) a service provider to monitor, measure and review its service management processes and services; e) a service provider to improve the design, transition and delivery of services through effective implementation and operation of an SMS; f) an assessor or auditor as the criteria for a conformity assessment of a service provider's SMS to the requirements in this part of ISO/IEC 20000. Figure 2 illustrates an SMS, including the service management processes. The service management processes and the relationships between the processes can be implemented in different ways by different service providers. The nature of the relationship between a service provider and the customer will influence how the service management processes are implemented. 1.2 Application All requirements in this part of ISO/IEC 20000 are generic and are intended to be applicable to all service providers, regardless of type, size and the nature of the services delivered. Exclusion of any of the requirements in Clauses 4 to 9 is not acceptable when a service provider claims conformity to this part of ISO/IEC 20000, irrespective of the nature of the service provider's organization. Conformity to the requirements in Clause 4 can only be demonstrated by a service provider showing evidence of fulfilling all of the requirements in Clause 4. A service provider cannot rely on evidence of the governance of processes operated by other parties for the requirements in Clause 4. Conformity to the requirements in Clauses 5 to 9 can be demonstrated by the service provider showing evidence of fulfilling all requirements. Alternatively, the service provider can show evidence of fulfilling the majority of the requirements themselves and evidence of the governance of processes operated by other parties for those processes, or parts of processes, that the service provider does not operate directly. The scope of this part of ISO/IEC 20000 excludes the specification for a product or tool. However, organizations can use this part of ISO/IEC 20000 to help them develop products or tools that support the operation of an SMS. NOTE ISO/IEC TR 20000-3 provides guidance on scope definition and applicability of this part of ISO/IEC 20000. This includes further explanation about the governance of processes operated by other parties. read less
This standard defines the general requirements and test methods for measuring conformance to ISO/IEC 9945-1 1990 (IEEE Std 1003.1-1990 ) hereinafter referred to as "POSIX.1" {3}. It also defines the test assertions for measuring conformance to POSIX.1 {3}. This standard is intended for use by --Developers of POSIX.1 {3} test methods;--Implementors of POSIX.1 {3} implementations; --Application writers for POSIX.1 {3} conforming implementations; --POSIX.1 {3} testing laboratories; and --Otheres interested in validating the conformance of a vendor-claimed POSIX.1 {3} implementation
This standard establishes a framework for the design, specification, evaluation, and deployment of age verification systems. The term ‘age assurance’ includes ‘age verification’ and ‘age estimation’ methods unless otherwise stated, and where consistent with all applicable laws and regulations. It includes the following:--The key terms, definitions, and abbreviations, together with the roles and responsibilities of key actors in the age assurance process. Requirements for establishing different… read more levels of confidence (asserted, standard, enhanced, and strict)associated with the types of age assurance systems.--Requirements for privacy protection, data security, and information systems management that are specific to the age assurance process. It does not specify--Detailed information about countermeasures (i.e., anti-spoofing techniques), methods to detect presentation attacks, algorithms, or sensors.--Methods to assess the overall system-level security or vulnerability. read less
This standard involves multiple aspects, including self-discipline and professional ethics of cryptocurrency exchange platforms, as well as relevance between them and cryptocurrency wallets. This standard also describes the exchanges' business logic, operational procedures, and user authentication programs. In addition, this standard provides a small but necessary number of technical requirements, including terminologies, basic architectural framework, key indicators, end-user interface… read more specifications, in order to achieve the previously mentioned goals. read less
This standard defines multiple aspects of the entity-based risk mutual assistance model (RMAM) through blockchain technology, including the interested entities involved, the relationship between entities, the general architecture, RMAM nodes, data sources, and digital assets. It builds a model to help the users to initiate, execute and settle a whole life-cycle mutual assistance plan with possible compensation through blockchain technology credibly and reliably.
对不起，暂未有相关搜索结果！
