Before moving forward with directly CX Metrics itself, let me give an assumed example:

Sample assumption:

• We built Company X and started to provide an education service. This education company has a website, application and customer service. All modern systems, whiteboards, online education platforms etc.

Key question: How will we understand if everything is going well with our customers in the business?

Answer: Measure Customer Experience and Manage It!

• Customer Experience: as the name suggests, it is the feeling and experience by customers when they interact with our Company X services and products. Any single interaction and touchpoints are considered under the Customer Experience umbrella. And just note here, the abbreviated version of Customer Experience is generally known as CX. Below we may find just a few examples of touchpoints:

• Company website and mobile application (e.g., user friendly and updated information)
• Customer related processes (e.g., easy and fast service ordering)
• Customer service agents (e.g., supportive agents)
• Contact details (e.g., is our company reachable and responsive)

and many other

• Management of Customer Experience (CXM or CEM): is a strategy and a methodology and should be tailored to the company’s goals with following accepted metrics and principles. Sometimes CXM and CEM are used as interchangeable but sometimes both have slightly different views. But regardless of abbreviations, both are for managing customer’s experience to improve or exceed it.

• CX Metrics: most of us know how much fuel our car uses, or we know how much electricity we consume at home. And based on that we take actions. So, we have some metrics, it is same concept here in CXM. We have metrics where are measured in touchpoints. As I am a telecom expert, here I will focus on CX Metrics for Telecommunications only, but most of them are relevant for other industries too. Two kinds of categories we have CX Metrics in Telecom:

• Inside-out CX Metrics (observation and analysis-based metrics from a network perspective, for example CEI, SQI etc.)
• Outside-in CX Metrics (customer survey-based metrics from customers’ perspectives, for example NPS®, CSAT etc.)

   Both inputs are bricks of Customer Experience Management, but it does not mean both inputs reflect each other smoothly all the time but certainly solidly related.

  The CX Metrics are not limited only to what will be talked about here, but I will try to go through with the most well-known and important ones. Any Medical industry, Hotel industry, Textile industry or Tobacco industry, Telecommunications industry and literally any industry must have CX Metrics and management strategy. Even though historically companies used different methodologies to provide better service to customers, Customer Experience appeared on stage starting from 1980s-1990s and especially in Telecommunications industry it started to be used mostly in early 2000s. Of course, even before the 1980s similar concepts were used by many companies but not necessarily to be the term as Customer Experience.

  Mostly known fact is Disney started to focus on CX if we want to understand the beginning of CXM history, was highly involved in creating a holistic customer journey – from the park’s design to the guest interactions with staff. This level of attention to every detail laid the groundwork for what would later be known as CX. We may look at the book “Be Our Guest: Perfecting the Art of Customer Service” by Disney Institute for CXM baby steps as they understood the importance at that time.

  So, let’s go now to the topic. Below we will go most legacy and modern CX metrics:

• CSAT – Customer Satisfaction CX Metric

It is basically calculated between number 1 and 5 with this typical question after providing a service as a survey question below. It could be online like a pop-up message after a service delivery in mobile application or in a store like a small screen with 5 emojis etc.

“How satisfied were you with your experience?”

1 – Very unsatisfied

2 – Unsatisfied

3 – Neutral

4 – Satisfied

5 – Very satisfied

Formula:

CSAT = (Number of Satisfied Customers / Total Number of Survey Responses​) × 100%

Example:

1 – Very unsatisfied (3 customers)

2 – Unsatisfied (6 customers)

3 – Neutral (5 customers)

4 – Satisfied (20 customers)

5 – Very satisfied (22 customers)

CSAT = (20+22) / (22 + 20 + 5 + 6 + 3) × 100% = 75%

  Most probably a question will raise in our mind after calculation like “is that a good or bad value?”. There is no direct answer for that as it depends on company strategy, even though usually more than 80% is considered as an excellent value but targets depend on final goals for each company and industry. Another crucial point to consider, all surveys where customers make selection depends on their emotions, feelings and decisions. One customer may consider same level of service delivery 5 but other not patient customer may select 3.

• CES – Customer Effort Score CX Metric

  It is another important metric in Customer Experience Management which measures how much efforts customers make to order a service, to purchase a product or to resolve an issue. Usually, the customers do not care about how much the processes are complicated or fascinated, well or bad designed. They care about how fast they will be able to achieve their wish.

  A small sidenote: I am a frequent user of Amazon last ten years, that is a fantastic experience I have so far at least and now I see their CES is 6.3 which was an expected result. Of course, we cannot compare it with Telecommunications which has own challenges.

Below is a typical question in survey is presented to customers after resolving an issue:

“How fast and smoothly was your raised problem resolved?”

1 – Nearly impossible
2 – Very hard
3 – Somewhat hard
4 – Moderate effort
5 – Fairly simple
6 – Simple
7 – Very easy

There is no strict rule in the formula of CES, some companies use number range (1-7), some use (1-5) or even (1-10). And even naming could also be different, like in this example we mentioned 7 – Very easy but it could also be tagged as opposite.

Formula:

CES = (Number of Weighted Responses / Total Number of Survey Responses​)

Example:

We received 250 survey responses

1 – selected by 12 customers
2 – selected by 15 customers
3 – selected by 18 customers
4 – selected by 19 customers
5 – selected by 39 customers
6 – selected by 89 customers
7 – selected by 58 customers

CES = (1×12 + 2×15 + 3×18 + 4×19 + 5×39 + 6×89 + 7×58) / 250 = 5.2

Generally, CES value less 6 is considered a bit poor and need some improvement plan in 7 scale CES.

Less efforts and easy reaching to the provided service mean the company focuses on CES, otherwise bureaucracy and complexity is not the way of good service delivery.

Typical examples:

We want to order an eSIM:

• Visited website, fill major information and make payment. Then Boom: eSIM QR Code is ready to scan via email or portal itself in a few minutes.
• You encountered a problem with eSIM profile, visit company application to get in touch with an agent. If AI powered agents cannot help, then it should easily direct to real human support rather than asking not related questions.

Both are typical cases will definitely be reflected in a good result in CES with surveys.

• NPS® – Net Promoter Score® CX Metric

This is very well known and widely used by almost all industries over last two decades, it reflects net how much promoters are in your business after extracting detractors.

NPS® has a range from 0 to 10.

• Promoters (Score 9-10)
• Passives (Score 7-8)
• Detractors (Score 0-6)

If the customers selected 9 or 10 in your NPS® survey, these are mostly loyal customers and have high potential to re-purchase your services/products or positively recommend to others.

If the customers selected 7 or 8 in the NPS® survey, these are mostly satisfied customers but not willing to promote your service/product to others, even easily may move to other company services.

If the customers picked up one of these numbers between 0 and 6 then that is not a good signal, as these customers will do most potentially negative reviews and opinions about your brand, service or product in all possible platforms.

This is a typical NPS® survey question is asked to vote:

“How likely do you recommend our service/product to your friend and colleague from 0 to 10 score?”

Formula:

NPS = %Promoters – %Detractors

Example:

We received 100 survey responses

• Promoters (Score 9-10) selected by 38 customers
• Passives (Score 7-8) selected by 12 customers
• Detractors (Score 0-6) selected by 50 customers

Promoters = (38 / 100) x 100% = 38%

Passives = (12 / 100) x 100% = 12%

Detractors = (50 / 100) x 100% = 50%

In this example NPS Score = 38% – 50% = -12

Is that good or bad NPS® value? Negative NPS® value is giving warning signal that there are more Detractors than Promoters which is risk for the business and need urgent action.

• ART – Average Resolution Time CX Metric

This is a generic CX Metric, but also useful to have insight in which speed the open cases are resolved. Example, a Call Agent received 5 cases per day from multiple customers and below is the resolution duration per case:

Case 1 = 16 min

Case 2 = 30 min

Case 3 = 18 min

Case 4 = 6 min

Case 5 = 12 min

ART = (16 + 30 + 18 + 6 + 12) / 5 = 16.4 min

  There cannot be strict bad or good values for ART, because it is internal decision of each company based on strategies and business goals. It could be a technical issue resolution or just query and answers or totally different resolution item.

• CLV – Customer Lifetime Value CX Metric

   Typical reason of having a business is to revenue if it is not a governmental project or non-profit organisation or similar. And businesses need to find strategies to bring customers and hold them for long periods of time. But is that enough? Short answer no, because just having a customer is not sufficient to gain revenue but need to measure of the Customer Lifetime Value. The aim to understand how much value the customer is adding to the business:

Formula:

CLV = (Revenue from a customer per year) x (Relationship with the customer in years) – total costs spent for the customer (acquisitions costs, operational costs, service costs etc.)

It is simplified and generic formula to calculate the CLV, but just a reminder that like CLV many other CX Metrics could be adapted and customized based on a business model and targets.

• CCR – Customer Churn Rate CX Metric

Customer Churn Rate, which is normal for any business, but once it increases beyond threshold then could be a nightmare for any business, because the customers stop temporarily or permanently to use the services. Cancelling the contract, suspending or stopping the subscriptions etc. The consequences are very obvious from financial point of view. The general formula to calculate CCR is very simple unless there is customized formula used by any other company. Here it is:

Formula:

CCR = Customers lost during the period / Customers at the start of the period

Example:

The customers at the start of the period: 1200

The same customers lost during the period: 89

CCR = (89 / 1200) x 100% = 7.4%

This is very simplified version of CCR, of course if new customers arrived in the middle of year and left after some time, they may also be considered but the formula may be adjusted.

Most important to find out is root cause of high Churn Rate, there could be tons of reasons or just few. Right understanding and identifying the underlaying problem and utilizing the CX Metrics are the fundamentals. That is why, each CX Metric has own value and direct relation with CCR.

Each industry has different acceptable churn rate, in Telecommunications generally annualized CCR it is 15%-20% if there are high competition. Below example is from US for different industries from Statista Inc. in 2020:

Customer churn rate in the United States in 2020, by industry

• CEI – Customer Experience Index CX Metric

This is another CX Metric but not limited with telecom industry, it can be utilized and adapted, implemented in any industry for customers. The CEI may consists of few sub-indicators, or even more like tens, hundreds which depends on company strategy. Generally, in telecommunications the mobile operators use CEI to reflect individual user experience from network perspective and majority of these data are derived from either billing systems, operation tools or probing solutions (e.g., Huawei SmartCare, Radcom, Anritsu, Veego, Elisa Polystar and several others).

Example:

• Voice (e.g., quality, call drop, call success, call setup time etc.)
• Video (e.g., video resolution, time to play, buffering etc.)
• Data (e.g., packet loss, latency etc.)
• SMS (e.g., delivery success rate, delivery delay etc.)

These sub-KPIs could be weighted and normalized to percentage units. But just a small reminder, there are no any written-on-stone rules how to build the CEI similar like most other CX Metrics. It can be less or more sub-KPIs under CEI. Each sub-KPI means Key Performance Indicators (e.g., for Data these are packet loss, latency etc.).

• SQI – Service Quality Index CX Metric

SQI is very complex in CX Metric bucket and closely linked into network operations. Generally, SQI is reflecting Measurement of Service Quality which can encompasses network availability, incident resolution speed, service outage and even under SQI coverage area we can add device level insights like how the Apple handsets are performing in comparison with Samsung or Huawei handsets etc.

As a metric the SQI could be weighted and normalized similar like CEI, from concepts perspective but of course values and thresholds could be totally different.

• Sentiment Analysis – finally CX Metric in this article

Most of the above CX Metrics have been used in telecoms for almost decades but still will be part of CEM (Customer Experience Management) for upcoming decades with optimized and modernized versions. But recently Sentiment Analysis became more prominent and completed CX Metrics with advanced technologies, AI and Big data. Basically, if customers are not happy with the provided services they may post and share experiences, emotions over social networks like X (former Twitter), Facebook or Google Review etc. And Sentiment Analysis algorithms will catch these angers, feelings and notes to give automatically priceless insights to see and to take actions. Of course, there are a lot of challenges for reliability of these data, but it is a valuable insight input for a brand image.

The post Boring Telecom CX Metrics? Let’s look at them again! appeared first on Telecompedia.

D-RAN stands for Distributed-RAN, it is one of the early versions of radio access network where Remote Radio Head (RRH, also known as RRU) and Base-band Unit (BBU) are co-located in the physical location for each cell site. So, the RAN is distributed all over the geographical area.

Of course, it was beneficial until new options arrived at the stage, which we will talk one by one according to the phases below.

Disadvantages:

• Vendor lock-in for both hardware RRH/BBU and software must be from the same vendor
• Insufficient resource sharing. In case of low traffic areas, RAN capacity will not be sufficiently utilized.
• High operatorial costs. Each site should be visited by field maintenance engineers which directly impacts OPEX.

C-RAN stands for Centralized-RAN and also known as Cloud-RAN. It is an enhanced version of D-RAN. Why? The reason, now the BBU will not be co-located with RRH in the cell site place. BBU of multiple cell sites will be in the same physical premises and the resources can be shared dynamically (called as BBU Pool or BBU Hotel). That is a great achieved approach with many advantages.

Interface name between BBU and RRH is called as fronthaul

Advantages:

• Computing resource sharing constitutes such as CPU, RAM etc.
• Reduced operational costs, where multiple sites can be maintained from the same physical location. Saving from rental fees (larger place is required in case of RRH/BBU co-location).
• Improved inter-cell coordination (e.g., eICIC works more efficiently due to low latency communication between different sites).

Disadvantages:

• Still keeps vendor dependency like D-RAN
• High data burden on fronthaul due to large amount of data from RRH to BBU for processing. But further to overcome this issue 3GPP proposed functional splits between three entities like Radio Unit, Distributed Unit (DU) and Central Unit (CU). In this case some major processing can be done in DU (e.g., RLC, MAC, PHY) and in CU (e.g., RRC, PDCP and SDAP in 5G scenario).

vRAN stands for Virtualized-RAN. It is almost same like C-RAN but now there is no hardware dependency on some major entities of the RAN architecture. BBU as a software package is on top of COTS servers. What does it mean ?

It means, BBU (it can also be functional split like vDU and vCU) is only a software package provided by a vendor. It will be located on the COTS server as a VNF or CNF.

COTS servers are commercially available off-the-shelf, so it can be easily purchased from a COTS server producer and put the BBU software top of it.

But even though it could be achieved software-hardware decoupling at BBU level, still it has disadvantages like:

• Not open interfaces, still vendor proprietary exits. RRH and BBU (vDU and vCU) must be from the same vendor.

Open RAN, this is latest enhanced version of RAN solution. It keeps all benefits of C-RAN and vRAN solutions but now opens interfaces between RRH, vDU and vCU plus adds intelligent to the radio access network. In this case there will be no vendor lock-in, and the MNO can compose the RAN network with different vendors.

For having complete understanding of Open RAN solution, you can check these articles:

Open RAN with Bullets – Part 1

Open RAN with Bullets – Part 2

Let’s recap here about different approaches of Radio Access Networks:

D-RAN: Radio Unit and Baseband Unit co-locate in each cell site. Software and hardware must be from the same vendor.

C-RAN: Radio Unit locates in cell site, but Baseband Unit locates in centralized location. Software and hardware must be from the same vendor.

vRAN: Radio Unit locates in cell site and Baseband Unit locates in centralized location or can be functional split as DU, CU. The BBU is virtualized and locates on top of COTS server, but still BBU and RRU must be from the same vendor.

Open RAN: as the name gives hint, the interfaces will be open between Radio Unit, DU, and CU. There is no vendor dependency, each entity can be supplied from different vendor. You may also see O-RAN and OpenRAN (without hyphen) in different documents. These are not another versions of RAN solution, to find an answer check Open RAN with Bullets – Part 1

• D-RAN is not C-RAN
• C-RAN is not vRAN
• vRAN is not Open RAN

but Open RAN has parts from all previous RAN solutions, and it is intelligent with RIC.

Reference:

• VIAVI – Cloud-RAN Deployment with CPRI Fronthaul Technology
• Potentials and Challenges of C-RAN Supporting – Rui Wang, Honglin Hu, Xiumei Yang
• Coordination inside centralized radio access networks with limited fronthaul capacity – Jialong Duan

The post D-RAN, C-RAN, vRAN and Open RAN appeared first on Telecompedia.

Above illustration depicts:

1. External application server which connects to Non-Real Time RIC. Either it can be V2X Server or UAV Server, it depends on the use case. Usually, enrichment information is obtained from the server to use in AI/ML model tuning.
2. Even though here it is shown as different cloud infrastructure for each element of RAN domain, it is also possible to be on the same physical resources. So, O-CU, O-DU can be hosted on the same cloud environment. Consequently, it depends on deployment strategy of the service providers.
3. We can see RAN protocol stack functional split between elements. Example SDAP is hosted by O-CU-UP and RLC, MAC are hosted by O-DU. General idea of the RAN functional split comes from the 3GPP and it has multiple suggestions (Option 1, Option 2, Option 3 etc.). But the O-RAN Alliance obtained Option 7 and Option 2 and specified it in Open RAN.

Which functional split to be used depends on service deployment scenarios such as URLLC, but O-RAN Alliance supports most optimal one as depicted above.

4. Even though 5G Core network is not mandatory to be presented while explaining the Open RAN, but I think it would be better if we can see big picture like connection of O-CU UP with UPF which carries user plane traffic and O-CU CP with AMF which carries control plane traffic.

Open RAN Elements Bundling Options

Although O-RAN specified elements in Open RAN architecture as different nodes and individual E2 and O1 connections to those elements:

• Near-Real Time RIC
• O – CU – CP
• O – CU – UP
• O – DU
• O – RU

It is also possible to bundle these nodes in different deployments options (so far it is specified 7 options by O-RAN), and in this case O1 and E2 interfaces will be connected to the bundle (as group) and manage them as single element.

• Aggregation O-CU-CP and O-CU-UP
• Aggregation Near-RT RIC, O-CU-CP and O-CU-UP

Click on image to enlarge

• Aggregation O-CU-CP, O-CU-UP and O-DU
• Aggregation O-CU-CP, O-CU-UP, O-DU and O-RU

Click on image to enlarge

• Aggregation O-DU and O-RU
• Aggregation Near-RT RIC, O-CU-CP, O-CU-UP, O-DU and O-RU

Click on image to enlarge

References:

• Toward Next Generation Open Radio Access – IEEE Network Magazine 2022
• O-RAN-Architecture-Description, Technical Specification

The post Open RAN with Bullets – Part 2 appeared first on Telecompedia.

Initially I planned to summarize overall Open RAN approach in one post with 3-4 pages, but it will not be possible and may reach up to 10 pages. That is the reason today we will talk about Open RAN architecture overview then upcoming series use cases and split options will be covered. I will try to put the key information with bullets to memorize well. Let’s start with:

– OpenRAN or O-RAN. Are both totally different or working for the same goal ? In a short answer the goal is same for Open RAN approach.

• Without hyphen or space, the term OpenRAN was initiated by Facebook and its partners, and the primary approach is to build 2G, 3G, 4G and 5G RAN solutions based on general-purpose vendor-neutral hardware, open interfaces, and software. It is under global community of organization and companies as Telecom Infra Project (TIP).
• O-RAN is an alliance of many organizations and companies for Open RAN approach. It generates specifications to be tested, produces solutions, and deployed by the vendors and operators respectively.
• So, we if can try recap the main difference between two groups as O-RAN group is to build standards for Open RAN approach and OpenRAN group is mostly to accelerate the development and deployment by the vendors and mobile network operators. This is what I could reach as conclusion so far, maybe later I will be able to find exact differentiation.

– What is the primary purpose of Open RAN approach?

• No more vendor lock-in necessity in RAN domain. It will urge to build multi-vendor ecosystem by the MNOs. Example, RRH can be supplied by Nokia, vDU/vCU can be supplied by Huawei and xApp can be provided by a small software company.
• Intelligent automated RAN domain management and optimization. 3^rd party software developer companies will take major part on it with rApps and xApps (will talk about a bit later in this article with few use cases)
• If there is automation, it is obvious that cost saving will be one of the primary benefits of Open RAN solution. TCO or with complete name total cost of ownership will be reduced.

– How will above targets be achieved?

• Open and interoperable interfaces between multiple nodes of RAN domain. It means, different vendor products will operate smoothly with each other. That is the main job of O-RAN alliance to produce specifications.
• Usage of big data and AI/ML models to make more intelligent of traditional RAN domain.

– How is the high level of O-RAN specified Open RAN architecture ?

– Several new elements can be seen in this architecture like:

• O-Cloud
• O-RU
• O-DU
• O-CU-UP
• O-CU-CP
• O-eNB
• Near-Real Time RIC
• Non-Real Time RIC
• SMO (Service Management and Orchestration Framework)

– As well as several interface names may be not familiar with you:

• O2
• O1
• E2
• A1
• Open FH CUS-Plane
• Open FH M-Plane
• The rest are same with 3GPP specified like E1, F1-c, F1-u, X2-c X2-u, Xn-u, Xn-c, NG-c, NG-u

Before jumping to the introduction of each element and interface in this architecture, let me give a hint that, not everything is new name from scratch. Most of them are similar with 3GPP given name. Just O-RAN alliance added capital “O” in front of existing terms to present them as “Open”. Like vDU is presenting Virtualized DU and here it is O-DU.

• O-Cloud is a cloud computing platform with physical infrastructure (e.g., storage, network card, CPU etc.).
• O-DU (Distributed Unit), O-CU-UP (Central Unit – User Plane), O-CU-CP (Central Unit – Control Plane) may be virtualized network function (VNF) or container network function (CNF) on top of the O-Cloud.
• O-RU is Open Radio Unit, like traditionally known as RRH or RRU but now it supports interoperability with other vendors too. Virtualization of O-RU is future study according to the O-RAN specification.
• O-eNB is an enhanced version of eNodeB which is also known as ng-eNB can work under 5G Core. It is expected to support O-RAN specifications too.

– Near-Real Time RIC, let’s get more details about it:

• Near Real Time means operation and decision time is between 10ms-1s, it is very close to the real time processes of the network elements like in O-CU or O-DU.
• RIC is RAN Intelligent Controller, as cited above that one of the primary purposes of Open RAN approach is automation and management. That is the RIC is doing here.
• Near Real Time RIC collects fine-grained (detailed, low-level) information from the RAN elements through E2 interfaces and may use AI/ML models for further resource control or optimization of RAN elements.
• Near Real Time RIC can host 3^rd party software applications which is called xApp, the amount may be one or more. The role of those xApps can be above mentioned actions like data collection, optimization.
• Near Real Time RIC can be hosted in O-Cloud infrastructure.

– SMO or Service Management and Orchestration Framework, it is similar conventional EMS (Element Management System in various domain like RAN or Core). But SMO has more capability and responsibility like:

• Cloud management and orchestration like scale-in, scale-out. Delete, create, modify resources and software management etc. All is done through O2 interface between SMO and O-Cloud.
• Fault management, configuration management, performance management of RAN elements. All is done through O1 interface between SMO and RAN elements.
• SMO and O-RU, there is an interface between these entities. It is called as Open Fronthaul Management Plane like abbreviated as Open FH M-Plane. SMO role here is to make O-RU start-up installation, software management, fault management, configuration management and performance management.

– Non-Real Time RIC:

• As the name is similar to Near-Real Time RIC, but now the execution times of use cases are not near real time and is almost 1 second or more.
• It is hosted within SMO
• Like Near-Real Time RIC, also Non-Real Time RIC can obtain 3^rd party software applications, and it is called rApp. When we say 3^rd party software application, the full set of SMO can also be supplied by the same vendor which depends on MNO chose.
• Primary roles of Non-Real Time RIC are to enable non-real time optimization of RAN elements, provide policy-based guidance to applications (xApps) of Near-Real Time RIC through A1 interface.
• Non-Real Time RIC also trains AI/ML models and makes data analytics.

References:

• O-RAN-Architecture-Description, Technical Specification
• Telecominfraproject (TIP)
• O-RAN Alliance
• NTT Docomo, 5G Open RAN Ecosystem

The post Open RAN with Bullets – Part 1 appeared first on Telecompedia.

The post LTE UL Power Control in illustrations appeared first on Telecompedia.

The post LTE Regular MIMO in illustrations appeared first on Telecompedia.

The post LTE DRX in illustrations appeared first on Telecompedia.

Power control is one of the most complicated subject in wireless communication technologies. Today we will try to have an overall idea about LTE Uplink Power Control with understanding each part of the calculation mechanism, but prior to diving to the topic let’s check a bit other things related to the power.

In physics, definition of power is the amount of energy transferred or converted per unit time. The unit of the power is Watt, but it can also be converted to other units such as dBm (Watt is a linear unit, while dBm is a logarithmic unit). Why we mentioned dBm here, because basically in radio telecommunication measurements the dBm or in longer version decibel-milliwatt is also used.

1 watt is equal to 30dBm (1W = 1000mW = 30dBm)

2 watts is equal to 33dBm (2W = 2000mW = 33dBm)

1 milliwatt is equal to 0 dBm (1mW = 0dBm)

Ok, but in the field when we open our drive test tool and we can see the measured signal level with negative values, e.g. -95dBm RSRP. Is it convertible to Watt too? Yes, we can with different magnitude: milliWatt(mW), microWatt(µW), nanoWatt(nW), picoWatt(pW), femtoWatt(fW), attoWatt(aW). Let see some examples for measured RSRP in Watt:

If two devices need to be communicated each other either over wire or wirelessly, then they need to transmit the required information with some amount of power. Let’s give an example from a mobile network. Imagine there are 100 mobile phone users under nearby same network cells and all the mobile phones are pushing their maximum power for transmission to the network cells in uplink direction. What will happen in this scenario? Intra-cell and inter-cell interference, huge handset power consumption. And consequently, it will cause for poor network performance and bad experience for customers.

Is there any way to eliminate the interference and avoid battery drain of the handsets? Yes, the answer is to control the transmission power of the mobile phones. Not to use the maximum power instead of that to use needed power if possible.

LTE Uplink Power Control

3GPP organization has technical specifications for power control in LTE. As we are talking about uplink direction here, then we need to mention PRACH, PUSCH, PUCCH and SRS power control. Each of them has own defined mathematical calculation formula. Vendors might have a bit different calculation including some extra features, but generally they should follow the specified standards. At first glance it might look as scary or boring, but don’t worry we will try to break into pieces and give simplified explanation for each part of the related formula.

Power Control on PRACH

Before initiation of physical random access procedure, the UE should receive the PRACH related information in advance from the higher layers through SIB2. You can find those information (parameters) in this page.

This is a short description from 3GPP: “From the physical layer perspective, the L1 random access procedure encompasses the transmission of random access preamble and random access response.  The remaining messages are scheduled for transmission by the higher layer on the shared data channel and are not considered part of the L1 random access procedure. A random-access channel occupies 6 resource blocks in a subframe or set of consecutive subframes reserved for random access preamble transmissions. The eNodeB is not prohibited from scheduling data in the resource blocks reserved for random access channel preamble transmission”

Now, let’s go one by one over each part of the PRACH Uplink Power control calculation formula:

1. P_PRACH is a preamble transmission power on physical random access channel (PRACH).
2. P_CMAX is configured maxium UE allowed output power. The transmitter characteristics are specified at the antenna connector of the UE with a single or multiple transmit antennas. For UE with integral antenna only, a reference antenna with a gain of 0 dBi is assumed. Here an integral antenna means permanent fixed antenna, which may be built-in, designed as an indispensable part of the user equipment. On the following shortened table, we can find UE power class per frequency band.

1. Preamble Received Target Power indicates target UE transmit power for the PRACH expected by the eNodeB. Lower value of this parameter will negative impact random access success rate, but higher value will improve it with causing interference on neighboring cells. Proper parameter definition is important (e.g. -104dBm, -106dBm etc.).
2. PL is downlink path loss estimation calculated by the UE for the serving cell. This is the related formula:

 PLc = referenceSignalPower – higher layer filtered RSRP

where referenceSignalPower is delivered by the network to the UE through SIB2 (see details). Higher layer filtered RSRP means that the measured raw RSRP might not be reported to the network and Layer3 filtering can be applied to the measured result before using for evaluation of reporting criteria or for measurement reporting, by the following formula:

where

M_n is the latest received measurement result from the physical layer;

F_n is the updated filtered measurement result, that is used for evaluation of reporting criteria or for measurement reporting;

F_n-1 is the old filtered measurement result, where F₀ is set to M₁ when the first measurement result from the physical layer is received; and

a = 1/2^(k/4), where k is the filterCoefficient for the corresponding measurement quantity received by the quantityConfig;

Power Control on PUSCH

Physical Uplink Shared Channel is used to transfer user data from the user equipment to the radio network. Like other physical channels when the data is transferred then it needs to be on a certain power for reaching to the destination. High transmit power can cause interference and fast UE battery drain, in opposite way with extreme low power may cause for undelivered data to the network. So, transmit power needs to be controlled.

But how the UE will be aware of the power control mechanism? The answer is serving cell itself. It will instruct the UE about the transmit power through PDCCH. The serving cell sends scheduling information to the UE over PDCCH, then the UE starts to transmit user data on PUSCH. The UE already knows which subframe, MCS and how many resource blocks will be used with the instruction. Now the further step is to calculate transmit power on PUSCH for each subframe (so calculation is based on every 1ms) with using below formula:

1. P_PUSCH is transmit power of UE on physical uplink shared channel (PUSCH).
2. P_CMAX is configured maxium UE allowed output power. For details see above in Power Control on PRACH. Same description is valid for PUSCH too.
3. M_PUSCH is the bandwidth of the PUSCH resource assignment expressed in number of resource blocks.
4. P_{0_PUSCH} is a composition of cell specific and UE specific components configured by higher layers and delivered to the UE to be used in power calculation to transmit on PUSCH, it is also described like eNodeB expected power or eNodeB target received power in some vendor libraries:

P_{0_PUSCH} =P_{0_NOMINAL_PUSCH} + P_{0_UE_PUSCH}

5. α (pronunciation is Alpha [ˈælfə]) is used as pathloss compensation factor. It is provided by the serving cell to the UE to be used for PUSCH power calculation in open loop. Following values can be setup {0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1}.
6. PL is downlink path loss estimation calculated by the UE for the serving cell. For details see above in Power Control on PRACH. Same description is valid for PUSCH too.
7. Δ_TF,c (i) depends on deltaMCS-Enabled parameter whether a UE needs to adjust the transmit power based on the MCS changes or not. It also has own small formula, let’s have a look:

where,

• BPRE is number of information bits per resource element for the scheduled MCS.
• K_s depends on deltaMCS-Enabled parameter switch. If it enabled then K_s is 0, if the switch is disabled then K_s is 1.25. The parameter indication is provided by the serving cell to the UE through RRC Connection Setup message.

Amazing! We have come a long way. It doesn’t look so easy, but we are trying to simplify for you. Let’s take a breath and go to the last piece of the formula which is closed loop part. So far the formula was presenting open loop power control section.

1. f_c (i ) is closed loop power control component and the current PUSCH power control adjustment state for serving cell which is defined by following formulas (a means cumulative, and b means absolute based on Accumulation-enabled parameter provided by higher layers):

δ_PUSCH  referred to as a TPC command and is signaled on PDCCH with DCI Format0 or DCI Format3/3A on subframe i – K_PUSCH for serving cell. For FDD, K_PUSCH is 4 subframes (4ms). For TDD, it depends on UL/DL configuration as below:

Above we mentioned TPC command, what does it mean? TPC or with a complete name Transmit Power Control is used in Closed Loop Power Control mechanism to instruct the user equipment to adjust its transmit power (increase or decrease).

Power Control on PUCCH

Physical Uplink Control Channel (PUCCH) is used to carry uplink control information from the UE to the radio network. The conveyed message might be formatted per information type, number of bits. And this type of formations is called PUCCH Formats. Here are some examples such as PUCCH Format1, PUCCH Format1a, PUCCH Format2 and others. The carried information range is large, here we can see just few of them: scheduling request, acknowledgement responses or retransmission requests, channel quality index.

As other physical uplink channels, there should also be some specified standards on PUCCH to control transmission power. Here are we have it:

1. P_PUCCH is transmit power of UE on physical uplink control channel (PUCCH).
2. P_CMAX is configured maxium UE allowed output power. For details see above in Power Control on PRACH. Same description is valid for PUCCH too.
3. P_{0_PUCCH} is a composition of cell specific and UE specific components configured by higher layers and delivered to the UE to be used in power calculation to transmit on PUCCH.
4. PL is downlink path loss estimation calculated by the UE for the serving cell. For details see above in Power Control on PRACH. Same description is valid for PUCCH too.
5. h(nCQI, nHARQ) is a PUCCH format dependent value, in different PUCCH Format the result might be different.

• nCQI: corresponds to the number of information bits for the channel quality information
• nHARQ: is the number of HARQ-ACK bits sent in subframe

6. Δ_{F_PUCCH}(F ) each value of this parameter corresponds to a PUCCH Format and impacts on PUCCH transmit power. It is delta value and the unit is dB. For instance, Δ_{F_PUCCH} for PUCCH Format1 might be set as -2dB, 0dB or 2dB.
7. ΔTxD(F’): if the UE is configured by higher layers to transmit PUCCH on two antenna ports, the value of this parameter is provided by higher layers for each PUCCH format; otherwise the value is 0.
8. g(i) is closed loop power control component and the current PUCCH power control adjustment state. It also has small formula, let’s skim on it:

• For FDD, M=1 and k₀ = 4
• For TDD, values of M and k_m depends on UL/DL configuration.
• δ_PUCCH referred to as a TPC command and is signaled on PDCCH with DCI format 1A/1B/1D/1/2A/2/2B/2C/2D

Power Control on SRS

Sounding Reference Signal (SRS) is a kind of transmitted signal from UE to the serving cell on the last symbol of the subframe of SC-FDMA. If the entire uplink bandwidth could be used all the time, then we would not need such kind of reference signal. But it cannot be, so we would need to use it. Then what is the purpose of this this? The purpose is to help the eNodeB to estimate channel quality of uplink path at different frequencies.

If we are talking about transmission between the UE and eNodeB then it means, there is a power usage and we need to control it not make side effects.

1. P_SRS is transmit power of UE on sounding reference signal (SRS).
2. P_CMAX is configured maxium UE allowed output power. For details see above in Power Control on PRACH. Same description is valid for SRS too.
3. P_{SRS_OFFSET}(m), basically SRS follows similar PUSCH power control calculation method. PSRS_OFFSET indicates the power offset of the sounding reference signal to the PUSCH. The unit is dB, and configurable (e.g. -4.5,-3,-1.5,0,1.5,3 depends on vendor).
4. M_SRS is the bandwidth of the SRS transmission expressed in number of resource blocks
5. Following three parameters are same with PUSCH power control parameters, you can find details above in PUSCH clause: P_{0_PUSCH} ,α, PL and f_c (i )

References: 3GPP 36.101, 3GPP 36.213, 3GPP36.331

The post LTE UL Power Control appeared first on Telecompedia.

  Here we will try to give general idea for DRX feature in Idle Mode and Connected Mode. 

  Once new type of mobile terminals with wide screen arrived to the market, or another case many mobile applications started to be used by the subscribers then fast battery drain become bothering.

  Of course, there was a most effective solution for this issue, and it was DRX or in other word Discontinuous Reception. Similar features exist in legacy technologies too, but in this article the topic is only LTE DRX.

  Some of the mobile operators could achieve 40%-45% power saving with DRX in their trials, sometimes less or even no effectiveness was observed in some terminals (it might be related with chipset producer). But generally, DRX is a powerful option for energy saving.

  When a new feature was invented, definitely we can see its advantages and also disadvantages. We already know about its positive part which is energy saving at mobile equipment, but what about side effect?

  Side effect or negative part or whatever we want to call are packet delay and packet loss (e.g. eNodeB can schedule data at specified time but the UE may be in sleeping mode at that time). Parameters of DRX are very sensitive, if any unreasonable value are defined on it then it can cause for serious QoS degradation.

  Typically a UE (user equipment) should always listen to the network to see if there is a new data for downlink or need to wait for UL Grant to transfer the data. This notification arrives through PDCCH channel. The PDCCH mapped to the first OFDM symbols in every downlink subframe, it can be 1, 2, and 3 symbols too (depends on configuration).

Let’s come back to DRX

• Question 1: What is the relation between UE monitoring the PDDCH on each subframe and DRX ?
• Answer 1: The relation is power consumption, where the UE spends huge energy if it continuously keeps monitoring and decodes each PDCCH message.
• Question 2: How does the DRX help to save energy at UE side ?
• Answer 2: DRX will let the UE not to listen every PDCCH. The UE will monitor the PDCCH in a specified period and then it will switch OFF its transceiver.

On the following images we can see generic illustrations of DRX Disabled and DRX Enabled scenarios.

• On DRX disabled option, the UE keeps monitoring the PDCCHs on each subframe.
• On DRX enabled option, the UE monitors the PDCCH on a predefined time durations then goes to sleep.

This is not an actual DRX working procedure, it is just for giving an idea how the DRX is influencing the UE power consumption. DRX can work in RRC Connected and RRC Idle modes, it is also called C-DRX and Idle Mode DRX respectively.

• C-DRX has two stages as Short DRX Cycle and Long DRX Cycle. The Short DRX Cycle is optional, it is mostly used to avoid immediate action for large sleeping mode of Long DRX Cycle. It is clear from the below illustrations or in this version (see All in One).
• The PDCCH monitoring in Idle Mode DRX happens on Paging Occasion per Paging DRX cycle

  Now let’s have a look one complete DRX procedure including all steps. The parameter values are not from actual network configurations, so it should not be considered as reference. The purpose is to draw an exemplification of DRX.

From left to right:

• Each rectangle is a subframe, duration is 1ms
• Data Info: there is scheduled new data for the UE, obtained the information from PDCCH
• On green parts there are data transmission or reception
• DRX Inactivity Timer: Specifies the number of consecutive PDCCH-subframe(s) after successfully decoding a PDCCH indicating a new UL or DL user data transmission for this UE.
• DRX Short Cycle Timer: This parameter specifies the number of consecutive subframe(s) the UE shall follow the short DRX cycle after the DRX Inactivity Timer has expired.
• On Duration Timer: Specifies the number of consecutive PDCCH-subframe(s) at the beginning of a DRX Cycle where UE transceiver is ON to listen the PDCCH.

• C-DRX parameters are delivered to UE through RRC ConnectionReconfiguration or RRC Connection Setup. Once no any new data was decoded while listening period (onDurationTimer) and the times passed through Short DRX Cycles and Long DRX Cycles the time reaches to be releasing of RRC Connection with RRC Connection Timer expiration. This release command comes from the network. When the RRC Connection release command comes then the UE moves to Idle Mode, next hop is DRX Mode in Idle Mode where the UE wakes up on each Paging DRX Cycles and keeps its ear on PDCCH to see if there is any new data for the UE (e.g. Downlink) through paging messages.
• Idle Mode DRX parameters are broadcasted with SIB2. The frames that paging messages are transmitted over the Uu interface are fixed. These fixed positions are indicated by the paging frames (PFs) and the paging occasion (PO) subframes. One PF is one radio frame, which may contain one or multiple POs. One PO is a subframe containing the paging radio network temporary identifier (P-RNTI), which is transmitted over the PDCCH. The UE reads paging messages over the physical downlink shared channel (PDSCH) according to the P-RNTI.

   Let’s describe the process one more time. The UE made call setup then requested UL Grant to send data or received DL Grant for downlink data. We can see on green part. After some time, there is no any new scheduled data for the UE and DRX Inactivity Timer started. When the DRX Inactivity Timer expires as a second step Short DRX Cycles starts to run (it is optional, some operator do not use), if no any data arrives or requested during that period then next step is Long DRX Cycles. If the UE keeps its passive status (no UL/DL data) then RRC Connection will be released by the serving cell once the RRC Inactivity Timer expires. After release of RRC Connection the UE moves to Idle Mode and starts to use Idle Mode DRX for monitoring PDCCH.

The post LTE DRX (Discontinuous Reception) appeared first on Telecompedia.

Radio side of the network is more complicated in comparison with other domains, because of mobility and user behaviour. A user can be nearby the serving cell under perfect radio environment, and another user can be in the cell edge with very bad radio coverage. So consequently, one of them may be able to get very good experience but other not. It is just one of the simple examples. Both users are very important for the operators and need to deliver better service to them. But how?

In that reason radio equipment manufacturers always spend a huge of amount for their research and development departments to invent or enhance the existing features to overcome such problems.

One of the crucial features in LTE is MIMO which we will talk about, it is used to for radio link robustness, improve spectral efficiency and enhance user data throughput. As we can see here MIMO has several options, not just to robust radio link and it can also give another benefit.

MIMO is a complex technique in terms of working principle and is already used for legacy technologies: e.g WiFi, HSPA+, WiMax, LTE and LTE-Advanced.

Multiple-input and Multiple-output is the complete name of MIMO, below quote is from Wikipedia:

“At one time, in wireless the term “MIMO” referred to the use of multiple antennas at the transmitter and the receiver. In modern usage, “MIMO” specifically refers to a practical technique for sending and receiving more than one data signal simultaneously over the same radio channel by exploiting multipath propagation.”

What we can understand from the quote, in modern usage the MIMO is mostly used for different signal streams to be transmitted simultaneously with taking advantage of multipath propagation and it will result higher data throughput.

MIMO Overview

In MIMO terminology we can see multiple antenna configurations:

SISO

Single Input Single Output, it is very simple configuration in antenna system. Only one transmit and one receive antenna is used. No diversity, no extra option to improve SINR and data throughput. Due to multipath signal effect, this system is vulnerable.

SIMO

Single Input Multiple Output, it is also known as Receive Diversity. The receiver will receive same data by multiple receiver points and will make selection of best signal (Switched Diversity) or combining (Maximum Ratio Combining – MRC) to improve signal to noise ratio. Because of the different transmission paths, the receiver sees two differently faded signals.

MISO

Multiple Input Single Output, also known as Transmit Diversity: same versions of the data will be transmitted over different path to improve link reliability. It is like redundant versions on different path.

MIMO

Multiple Input Multiple Output,

• More than one antenna in both receiver and transmitter sides
• Mostly intended for two types of benefits:
• Spatial Multiplexing: an information which is going to be transmitted will be separated into multiple streams and transmitted independently through different paths. Target is to improve data throughput at receiver side, but not helps for radio link reliability.
• Diversity Gain: each channel towards to the receiver may experience different level of fading and interference. Here on different channels, multiple versions of the same information are transmitted and selection or combining happens on receivers’ side. From such kind of multipath propagation, the diversity technique may exploit a gain which is called Diversity Gain. Tradeoff is obvious between Spatial Multiplexing and Diversity Gain.

Transmission Modes

3GPP specified variety versions of antenna techniques for different usage scenarios and classified them under Transmission Mode numbers for DL and UL separately. Classification might be due to capacity, link reliability, high speed user or low speed user, beamforming etc.

The post LTE Regular DL MIMO appeared first on Telecompedia.