Response time does not only depend on the EEO, it also is a function of how fast the interfaces to the underlying equipment can respond. The kind of adjustments that the EEO makes to manage QoE most closely resemble provisioning (the set up of network components). Because legacy systems were designed in a time of manual interfaces where provisioning took hours, days, and sometimes months; many of these systems have very slow response time interfaces. So, while the EEO can respond in less than a second, the underlying system components may not be able to.

As VNF’s (Virtual Network Functions) are rolled out, they tend to implement the legacy interfaces with the legacy sluggishness. Therefore, we use a grading system instead:  A for less than a second; B for less than a minute; C for less than 10 minutes; and D for less than an hour. As time goes on, and the requirement for rapid response becomes clear, response times may increase and our grading system ratchet up.

The role of End-to-End Orchestration in QoE

LTE Advanced has a function called SON that does load balancing between basestations (eNodeB’s).  In metropolitan areas it is common for a UE (User Equipment - handset, etc.) to be in range of a number of basestations. Ten is a rough average.  LTE SON works to distribute UE’s in such a way as to provide the best QoE for all active users. Unfortunately, it makes its decisions only based on the RAN (Radio Access Network) capacity of each basestation in a neighborhood. This capacity is set in initial provisioning and is often independent of the underlying capacity of the basestation.  This load balancing is blind to backhaul capacity. Backhaul capacity can be impaired by component failure, traffic congestion from other traffic sources, weather, or other factors.  A rough average is that at any given time, 1 percent of the basestations have impaired backhaul. When that happens, users experience dropped calls, delayed or dropped texts, delayed emails, poor or no response to web searches, and so on. Users, respond by trying multiple times, which increases the overall traffic in the neighborhood creating congestion on the other basestations. The QoE of the whole neighborhood is affected. This can mean that 10 percent of the neighborhoods have poor QoE.

EEO manages QoE by first detecting that the backhaul impairment has occurred and then reducing the RAN capacity of the affected basestation by moving part of its capacity to its neighbors.  This assures the UE’s assigned to the affected basestation good QoE, stops all the retries, and maximizes the usefulness of the capacity (combined RAN and Backhaul) that exists in the neighborhood.  When the backhaul capacity of the affected basestation has been returned to normal, the EEO moves RAN capacity back to the affected basestation.

In a 100 million subscriber network with one million macro basestations, there are 10,000 basestations with impaired backhaul (with average neighborhoods of 10 basestations) affecting 100,000 basestations. Each LTE basestation has 6,000 software settable parameters many of which generate large volume data streams. Then, these data streams must be combined with the data streams from the many switches and routers that make up the backhaul network.  

In many cases the backhaul network also provides connectivity to central cite processing systems.  So, a problem in backhaul may also make it difficult for the fault information to reach a central site in a timely fashion.  This makes it very difficult to do EEO from a single central site system.  Better QoE can be provided by a distributed system working at the edges.  As the information needed exists at the edge and all required changes can be made at the edge.  There may be a need for some central coordination, but the most efficient way to provide this kind of QoE management is at the edge.