Resources Centre
CATEGORIES
Enrollment Criteria for WBA E2E QoS Trials Phase 1: Enhancing QoS over Wi-Fi Links
The document outlines the enrollment criteria for the WBA E2E (End-to-End) QoS (Quality of Service) Trials, specifically focusing on Phase 1, which aims to enhance QoS over Wi-Fi links. Learn more about WBA E2E QoS Project.
Join the E2E QoS Trials – Phase 1: Improving QoS over Wi-Fi Links
As we look forward to 2024, the WBA invites industry players to join the Wireless Broadband Alliance and become integral participants in the E2E Wi-Fi QoS program. This phase is dedicated to enhancing Quality of Service over Wi-Fi links. Our upcoming initiatives include completing the test plan, initiating trials, and unveiling Deployment Guidelines. Additionally, we will concentrate on consolidating efforts, crafting guidelines for deployment, and delving into Low Latency Services (L4S) to cater to applications with low latency requirements.
For organizations eager to engage in this exciting project, we encourage you to reach out to the WBA Program Management Office (PMO) at pmo@wballiance.com. Be part of shaping the future of Wi-Fi.
E2E QoS Improvement: Optimizing QoS Over Wi-Fi
Operators and Enterprises can use QoS as a powerful market differentiator to attract and retain customers, such as business travelers who need reliable, high-performance Wi-Fi in airports. Enterprises need Wi-Fi networks that can provide the right QoS for each application, such as prioritizing HD video collaboration sessions over email and file transfers. And home Wi-Fi networks need to balance a variety of bandwidth-intensive, latency-sensitive applications, including multiplayer gaming, 4K streaming and remote work videoconferencing — often all simultaneously.
E2E QoS Improvement: Optimizing QoS Over Wi-Fi report explores how network operators can meet the unique QoS requirements for a wide variety of use cases and deployments, including gaming, residential broadband, live 4K video, enterprise, airports, stadiums and more.
As its name implies, end-to-end (E2E) QoS includes the application, such as cloud gaming or streaming video, Wi-Fi network elements such as access points (APs) and Wi-Fi client devices (like mobile phones and laptops). The E2E concept is about providing both visibility into and control over the user experience by leveraging QoS mechanisms at each step of a packet’s journey across the Wi-Fi ecosystem.
The paper discusses the use of ITU-T SG12 recommendations and corresponding tools to access objective mean opinion scores (MOS) the QoS streams during the trials with outcomes from the trials.
Additional future, WBA work includes expanding network topology to incorporate Wi-Fi mesh (Wi-Fi Alliance EasyMesh), extending QoS management to non-Wi-Fi links for E2E QoS and integrating new QoS management mechanisms from ongoing work in the IEEE802.11 Working Group and/or Wi-Fi Alliance QoS Management TG, and/or IETF.
Get Ready for Wi-Fi 7- Applying New Capabilities to the Key Use Cases
- Double the bandwidth and three times the speed of Wi-Fi 6
- Advanced support for latency-sensitive use cases
Operator Managed Wi-Fi Reference Architecture and Requirements
With the increasing prevalence of Wi-Fi as the primary method of internet connectivity, the term “Wi-Fi” has become synonymous with the internet itself. Consequently, users perceive their internet quality of experience (QoE) as synonymous with Wi-Fi QoE. Users no longer differentiate between Wi-Fi service and internet service, expecting their Wi-Fi issues to be resolved by their internet service provider (ISP). This shift has turned Wi-Fi into a managed service, specifically managed by the operator, hence the term “operator-managed.”
This is WBA’s first document on operator-managed Wi-Fi, and it is anticipated that later phases of work will expand the scope of the requirements hereby defined.
The technical paper, “Operator Managed Wi-Fi: Reference Architecture and Requirements” outlines a new operator-managed Wi-Fi (OMWi) reference architecture. The proposed framework will combine multiple available standards to streamline Wi-Fi data collection, Wi-Fi management, configuration, and optimization of home networks, simplifying the analysis and decision-making process for carriers.
This paper represents the first phase of that journey, presenting an operator-managed Wi-Fi reference architecture that combines the benefits of all available standards, including Wi-Fi Alliance (WFA) Wi-Fi EasyMesh™, Wi-Fi CERTIFIED Data Elements™, and Broadband Forum (BBF) User Services Platform (USP) Data Models TR-369 and TR-181. Wi-Fi Alliance EasyMesh™, for instance, can be utilized as the standard interface for Wi-Fi data collection, Wi-Fi management, configuration, and optimization on home networks with a standalone gateway.
Private 5G And Wi-Fi Convergence – Key Use Cases And Requirements
The paper outlines four possible deployment models for bringing 5G into enterprise networks, as well as the key considerations for choosing each one, such as the nature of the application, latency in the core and RAN interfaces, and the location and manageability of services. The four models are as follows:
- On-premises core network and application services – Data sovereignty, site resiliency, and application latency requirements are ensured by keeping all traffic on-prem. Access to conventional enterprise cloud-based applications is enabled, subject to normal limitations around resiliency and latency.
- On-Premises user plane and application services – The paper outlines several reasons to move the control plane to the cloud, such as the need for control plane aggregation in a multi-site 5G core network deployment. All other 5G elements and the application services are on-premises, except the 5G control plane elements.
- Cloud-based core network and application services – User plane traffic from 5G devices will always have to enter the cloud. In such deployment models, it may be possible to move the 5G core network and user plane elements to the cloud where the applications services are located.
- The hybrid model – There are some application services in the cloud, and some are on-prem. To support such a model, there can be two different Data Network Names (DNN’s), one for supporting applications that are on-premises and another for supporting applications in the cloud.
