Networking

The ATIS Cloud Services Forum is examining a number of services that establish the foundation for development, operations, deployment, and management of cloud-based services. These include content delivery, telepresence, and virtual desktop. Video services, including the already-present one-way and growing two-way communications, will be a substantial catalyst for additional growth and expansion of the Internet. Telepresence services provide a business model and architectural model that are foundational to cloud services, and provide important elements of the Cloud Services Data Model for Cloud Service Enablers. This specification focuses on telepresence services, recognizing that telepresence services are an integral part of a broader unified communications solution set.
There are many aspects of the telepresence service. This is an evolving document establishing a foundation for continuing work efforts. The specification explores a provider-agnostic and product-agnostic implementation, and will consider two primary aspects of the telepresence service that are detailed here by the examination of use cases deployed today and those resulting in the application of "the cloud" and other aspects of business and technology architecture guiding service evolution in the future. First, a description of the telepresence service is provided. Second, a more detailed description of the two key aspects of the telepresence service is provided. Topics 2f and 2g detail aspects of telepresence interconnectivity which will be addressed in a future specification.

Specify additions to and appropriate modifications of IEEE Std 802.3 to add greater than 1 Gb/s Physical Layer (PHY) specifications and management parameters for media and operating conditions for applications in the automotive environment.

This project is to specify additions to and appropriate modifications of IEEE Std 802.3 to add Physical Layer specifications and Management Parameters for 100 Gb/s, 200 Gb/s, and 400 Gb/s electrical interfaces based on 100 Gb/s signaling.

Define Physical Layer specifications (PHY) and management parameters for the transfer of Ethernet format frames at 400 Gb/s over fewer than 16 pairs of multimode fiber physical media.

Define physical layer specifications and management parameters for the transfer of Ethernet format frames at 50 Gb/s, 200 Gb/s, and 400 Gb/s at reaches greater than 10 km over single-mode fiber. Make TDECQ (Transmitter and dispersion eye closure for PAM4) related changes to existing 200 Gb/s and 400 Gb/s physical medium dependent sublayers over single-mode fiber.

The scope of the project defines physical layer specifications and management parameters for symmetric bidirectional 10 Gb/s, 25 Gb/s, and 50 Gb/s operation over single strand of single mode fiber of at least 10 km.

Replace references to the IEC 60950 series of standards (including IEC 60950-1 "Information technology equipment - Safety - Part 1: General requirements") with appropriate references to the IEC 62368 "Audio/video, information and communication technology equipment" series and make appropriate changes to the standard corresponding to the new references.

This amendment adds physical layer specifications and management parameters for optical subscriber access supporting point-to-multipoint operations using wavelength division multiplexing over an increased-reach (up to at least 50 km) passive optical network (PON).

Define physical layer specifications and management parameters for the transfer of Ethernet format frames at 100 Gb/s and 400 Gb/s at reaches greater than 10 km over DWDM systems.

Regional cloud providers that operate data centers and associated wide-area networking across their region are well positioned to cooperatively build a global cloud infrastructure with other regional cloud providers, and thus, become a valuable party for Content and Application Providers (CPs and APs). We call the formalization of such cooperation a federated cloud. In a federated cloud, application and/or content requests placed to a cloud provider can be served locally -- e.g., by a supporting cloud provider, even when this supporting cloud provider only has an indirect relationship to the AP or CP by way of a primary cloud provider. In this case, a primary cloud provider is defined as the cloud provider with which an AP or CP has a direct contractual arrangement for cloud services. A federated cloud member simultaneously acts as a primary cloud provider and a supporting cloud provider as defined by their relationship with different APs and CPs.
 
In a federated cloud, part or all of each individual provider's compute, storage, and networking resources become part of a federated pool of cloud resources. Management systems of these individual (regional) cloud providers are linked to facilitate end-to-end cloud services capability. By definition, a federated cloud includes a clearing house to settle expenditures and revenues of the end-to-end cloud services based on agreed methods, interfaces, and procedures for settlement.

The concept of a Federated Cloud comprised of interconnected Service Providers (SP) was introduced in ATIS Standard ATIS-0200003, CDN Interconnection Use Case Specifications and High Level Requirements [https://global.ihs.com/doc_detail.cfm?&csf=ASA&input_doc_number=%20&inpu.... This initial standard described the role of the SPs in the cloud as distributors of content from Content Providers (CP) to End Users (EU). Thus, SPs serve as Content Distribution Network (CDN) Providers. The set of content delivery Life Cycle interactions between two CDN Providers is defined in ATIS-0200003. The method for content distribution in ATIS-0200003 was limited to Unicast Cache-based distribution.
Under certain conditions depending on network configurations and type of content, it may be advantageous to distribute content via Multicast methods. From a network perspective, Multicast is scalable and results in significant savings in efficiencies and capacity utilization.
The purpose of this ATIS Standard is to introduce Multicast-based content distribution. This standard provides the following:

• Overview of the Multicast delivery mechanism
• Set of content types that are suitable for delivery via Multicast methods
• Description of various Multicast methods that can be deployed to interconnect two CDN Providers and distribute content.

The scope of this Standard is limited to use cases and requirements to support the interactions between two CDN Providers for content distribution via Multicast. The Use Cases describe:

1. Generic interactions supporting Life Cycle Multicast use between two CDN Providers.
2. Specific Multicast configurations/scenarios that can be deployed for interconnection and content distribution.

Multicast related specifics to support Billing, Provisioning, Reporting, and other network functions will be covered in future ATIS documents. Multicast-based content delivery to mobility-based End User devices is for further study.

The goal of this SA1 work item is to develop Stage 1 normative service requirements for multi-hop relay by enhancing the work done for “Indirect 3GPP Communication” in TS 22.278. 

This work will consider the potential requirements and KPIs in different domains (e.g. inHome, Smart Cities, Smart Farming, Smart Factories, Smart Energy, Public Safety, Logistics) identified and concluded in TR 22.866 and use them as the basis for developing stage 1 normative requirements. 

This work item aims to update TS 22.261 to include multi-hop support for UE-to-Network Relay UEs regarding the following aspects:

• General aspects.
• Permissions and authorization.
• Relay selection.
• Relays for IoT.
• Service continuity.
• Functionality Exposure to 3rd parties.
• Traffic scenarios.

Scenarios where the remote UEs and those UE-to-Network relay UEs in proximity to the remote UE are out-of-coverage are also in scope of this WI. Special attention to national regional regulatory requirements (e.g. emergency calls) shall be paid.

• Gap filling and evolutions:

While some verticals are already covered in earlier generations of mobile networks, others are new, each bringing their own set of requirements. However, one common requirement is better energy efficiency and more extensive coverage compared with what 3G and 4G can provide. Release 16 service requirements already include the possibility of having direct 3GPP communication or indirect 3GPP communication with the use of relays. Nevertheless, this may not be enough for the needs of the possible use cases from the area listed. Incorporating multihop relays into 5G will help to improve the energy efficiency and the coverage of the 5G system.

• Rapporteur and supporting members:

The rapporteur of this WI is KPN. Supporting individual members (SIMs) include TNO, Police of the Netherlands, French Ministry of the Interior and Philips alongside global supply-side companies.

• Latest update:

June 2019 (SP-190307; Unique Identifier: 840034). All active (not completed) items under the sole responsibility of SA1 are available here.