Wednesday, 12 August 2020

Telecom Services and Data Pricing

With the mobile technology gaining even more subscribers and smartphones becoming common, the telecom services pricing that includes voice, SMS and data is falling. Many operators are now including bundles with generous amounts to satisfy everyone. In many European countries, it is very common to have plans with unlimited everything. 

One of the reports that ITU releases is called "Measuring Digital Development: ICT Price Trends". The latest report for 2019 was released in May this year. The press release says:

On average, prices for mobile-voice, mobile-data and fixed-broadband services are decreasing steadily around the world, and in some countries even dramatically. The reduction in price relative to income is even more dramatic, suggesting that, globally, telecommunication and information and communication technology services are becoming more affordable. However, both trends do not translate into rapidly increasing Internet penetration rates which suggests that there are other barriers to Internet use, concludes ITU in its new statistical report, Measuring Digital Development: ICT Price Trends 2019.

The latest statistics from ITU confirm that affordability may not be the only barrier to Internet uptake, and that other factors such as: 

  • low level of education, 
  • lack of relevant content, 
  • lack of content in local languages, 
  • lack of digital skills, and a 
  • low-quality Internet connection may also prevent effective use. 


Key results​:

  • An entry-level mobile-voice basket remains broadly affordable in most countries. In 70 countries, a low-usage mobile-voice plan was available for less than 1 per cent of gross national income (GNI) per capita, and in a further 37 countries it stood below 2 per cent. Although causality is difficult to prove, price reductions have undoubtedly helped contribute to the rapid rise in the mobile-voice penetration rate, alongside growing competition and better price monitoring and evaluation by regulators.
  • The expansion of bundled services has further reduced prices, as combined data-and-voice baskets are generally less expensive than the sum of the two separate baskets in most markets.
  • Prices have decreased from 2013 to 2019 relative to GNI per capita The global average price of a mobile-data basket of 1.5 GB shrank from 8.4 per cent of GNI per capita in 2013 to 3.2 per cent in 2019, at a compound annual growth rate of almost -15 per cent. When expressed in USD, the global average price of a mobile-data basket of at least 1.5 GB dropped by 7 per cent on average annually between 2013 and 2019.
  • Good progress has been made towards the Broadband Commission for Sustainable Development's target of achieving affordable broadband costing 2-5 per cent of GNI per capita by 2025, but still more remains to be done. There are still nine developing countries and 31 LDCs that have yet to reach the 2 per cent target by 2025.
  • Fixed-broadband packages remain generally more expensive than mobile-data packages (although data allowances are not always directly comparable). Over the past four years, the affordability of fixed broadband has not changed substantially, but advertised download speeds continue to increase.

(click on the image to enlarge)

Some of the results are quite interesting as shown in the image above. The picture on top left shows the different types of packages. The report analyses price data for five key services based on the following five baskets:

  1. mobile-data-and-voice basket (i.e. voice, SMS and mobile data combined) – low consumption (70 minutes, 20 SMSs and 500 MB);
  2. mobile-data-and-voice basket – high consumption (140 minutes, 70 SMSs and 1.5 GB);
  3. mobile-voice (including voice and SMS);
  4. mobile-data;
  5. fixed-broadband.

Chart 1 shows Mobile data and voice baskets in USD for 2019. LDCs stands for Least Developed Countries

Chart 2 shows Mobile data and voice baskets in PPP$, where PPP stands for purchasing power parity. This is defined as basket of goods based comparison approach (see here)

Finally, chart 3 shows Mobile data and voice basket as a % of GNI p.c. GNI stands for gross national income. Expressing prices relative to GNI per capita (GNI p.c.), as a measure of affordability, reveals huge gaps between prices for different levels of development. In developed countries, the price of a low-consumption mobile-data-and-voice basket was equivalent to 1 per cent of GNI p.c. in 2019. In developing countries, this basket cost 7.5 per cent of GNI p.c., while in the LDCs this rose sharply to 17 per cent. For high-consumption mobile-data-and-voice baskets, the differences were even larger.

Source - Visual capitalist. Click link to see complete picture

Visual Capitalist has a nice summary of data prices for 1GB of Mobile data in different parts of the world. A striking trend worth noting is that four out of five of the most expensive countries (Malawi, Benin, Chad, Yemen & Botswana) for mobile data are in Sub-Saharan Africa (SSA).


Cable.co.uk have an interactive map here, that allows you to see prices in different parts of the world. As you would guess, the cheapest data prices in the world is in India.

Finally, eXtensia has a list of data costs in African countries from 2019 here, a lot has changed in the last year so you may have to check if the information you need is correct as of today.

Related Posts:

Thursday, 6 August 2020

What about 5G Network Architecture Option 4 (a.k.a. NE-DC) ?

You heard the news about Standalone (SA) 5G network(s)? T-Mobile USA announced this week that "T-Mobile is the first operator in the world to launch a commercial nationwide standalone 5G network". Nationwide is the key word here. Back in February, the Saudi operator STC announced that "stc - Kuwait first to launch 5G E2E SA network in MENA". We will see a lot more announcements about SA 5G this year.


I blogged in detail about the 5G Network Architecture options in this post earlier here. There we looked at the different options in details and typical migration path between the options. Whenever any operator / vendor talks about SA 5G today, they are talking about Option 2. That was back in 2018. Since then, many of the options have lost momentum.

As we all know, the current 5G networks are Non-Standalone or NSA. They are also known as Option 3 or EN-DC. The next evolution is Standalone of SA deployment. It is also known as Option 2. Right now, not many operators or vendors are talking about other options.



While some of the operators have toned down asking for Option 7 (NGEN-DC) & 4 (NE-DC) support, others haven't. Deutsche Telekom is one such operator.


In a webinar on the topic 'The Journey to Standalone 5G' back in March (available on demand here - for DT part, jump to 39 minutes point), Peter Stevens, Principal Engineer, Mobile Access, Deutsche Telekom UK discussed why DT views Option 4 as important for them. In fact if you look at the picture above, you see that they even refer to Option 4 as SA.


One of the motivations from RAN point of view is that because many UEs are not accepting low-low LTE-NR band combinations. So if an operator decided to go with nationwide SA, they have to make the cell sizes smaller than they have to be. This can create coverage gaps with 5G SA. Of course many of the newer features work far better with 5G core (5GC) so option 4 will provide speed benefits of Option 3 NSA without the limitations of 4G EPC.


Standalone without Option 4 can reduce data rates as you can see in the picture above and explained in another of our posts here.


Finally, this last picture summaries the alternatives to Option 4, Dynamic Spectrum Sharing (DSS) or fallback to NSA when 5GC services are not needed. As the slide says, neither of these options is considered a good mainstream alternative to Option 4.

Let me know your thoughts about this in the comments below.

Related Posts:

Saturday, 1 August 2020

Artificial Intelligence (AI) / Machine Learning (ML) in 5G Challenge by ITU


ITU is conducting a global ITU AI/ML 5G Challenge on the theme “How to apply ITU's ML architecture in 5G networks". If you don't know the difference between AI & ML, this picture from the old blog post may help.


The ITU website says:

Artificial Intelligence (AI) will be the dominant technology of the future and will impact every corner of society. In particular, AI / ML (machine learning) will shape how communication networks, a lifeline of our society, will be run. Many companies in the ICT sector are exploring how to make best use of AI/ML. ITU has been at the forefront of this endeavour exploring how to best apply AI/ML in future networks including 5G networks. The time is therefore right to bring together the technical community and stakeholders to brainstorm, innovate and solve relevant problems in 5G using AI/ML. Building on its standards work, ITU is conducting a global ITU AI/ML 5G Challenge on the theme “How to apply ITU's ML architecture in 5G networks". 

Participants will be able to solve real world problems, based on standardized technologies developed for ML in 5G networks. Teams will be required to enable, create, train and deploy ML models (such that participants will acquire hands-on experience in AI/ML in areas relevant to 5G). Participation is open to ITU Member States, Sector Members, Associates and Aca​demic Institutions and to any individual from a country that is a member of ITU. ​

There are also some cash prizes, etc. There are various topics with presentation slides & recordings freely available. 

I found the slides from ITU AI/ML in 5G Challenge —”Machine Learning for Wireless LANs + Japan Challenge Introduction” (link) very interesting. There are many other topics including AR / VR / XR, etc, as well.

Have a look at the ITU website here.


Related Posts:

Monday, 27 July 2020

Key Technology Aspects of 5G Security by Rohde & Schwarz


The 3G4G page contains a lot of useful papers and links to security here but we have also looked at evolution of security from 4G to 5G here. Rohde & Schwarz has a short 8-minute video in which wireless technology manager, Reiner Stuhlfauth, explains the key technology aspects ensuring 5G security. The video is embedded below.



Related Links:

Sunday, 19 July 2020

Mobile Initiated Connection Only (MICO) mode in 5G System


Mobile Initiated Connection Only (MICO) mode is designed for IoT devices that send small amounts of data and do not need to be paged. An example of this could be a smart bin that sends a message to the waste collection company saying it is 50% full, etc. This way the bin emptying lorry can plan to empty it in the next collection round. Here there is no reason to page the bin as there is no mobile terminated data that would be required.

MICO mode has to be negotiated between the device and AMF in 5GC. A device in MICO mode cannot be paged as it would not listen to paging to conserve battery power. This extreme power saving mode can ensure that the battery can last for very long time, ideally years thereby making this vision of billions of connected IoT devices a reality.


In an earlier post on RRC Inactive state, we looked at NAS states, along with RRC states. When the UE is in MICO mode, the AMF in 5GC will consider the UE to be unreachable when it is in CM-IDLE state. In addition, a periodic registration timer is also allocated to the MICO mode UEs. The UE has to confirm the MICO mode again during registration update.

The video and presentation are embedded below:





Related Posts:

Friday, 17 July 2020

A Look into 5G Virtual/Open RAN - Part 7: Change of gNB-CU-UP without Handover

This will be the last part of my series about Virtual/Open RAN signaling procedures. In this final post (although not the last one on this blog) I would like to present a very unique procedure that emerges from the facts of virtualization and automation of the RAN. And again I would like to present the big picture overview of the scenario that is called "Change of gNB-CU UP" (without handover). The full message flow (ladder diagram) can be found in 3GPP 38.401, chapter 8.9.5.

In the same chapter one can read that the trigger point for starting a change of the gNB-CU UP is quite vague. 3GPP writes: "e.g. a measurement report". However, which particular measurement event should trigger such a procedure? Even when looking into the Rel. 16 versions of 3GPP 38.331 (NR RRC) it becomes evident that all measurement events that are not dealing with NR sidelink or V2X connectivity are triggered by changing reference signal strength or rising interference. 

However, in case of a gNB-CU UP change without handover the UE does not move to a different cell. This makes me think - correct me if I am wrong - the true trigger points for this procedures come form a different entity, e.g. from the AI-driven policies and algorithms of the RAN Intelligence Controller (RIC) that is a fundamental element of the Open RAN architecture.


So what is necessary from a signaling perspective to change the gNB-CU UP during an ongoing connection?

There are new transport network resources aka GTP/IP-Tunnels required to steer the user plane traffic to and through the RAN. A new F1-U tunnel is necessary as well a a new NG-U tunnel, because also the user plane traffic between RAN and the UPF in the 5G core network must be exchange using a new route.

When it is clear which new UP transport tunnels need to be established (and which old ones need to be deleted) it is really simple to understand the overall scenario.

A F1AP UE Context Modification procedure is performed to switch the F1-U tunnel. NGAP Path Switch procedure is performed to switch the NG-U tunnel. And an E1AP Bearer Context Modification procedure is the prerequisite, because it delivers the new UL GTP-TEID for the F1-U tunnel as well as the new DL GTP-TEID for the NG-U tunnel.

Unfortunately the authors of 3GPP 38.401 are not very precise when mentioning protocol procedures defined in other specs. Thus, they speak about "bearer modification" when looking at F1AP and "Path Update" for NGAP.

It is not a big deal, but something you just need to know if you want to analyze real-world message flows of this scenario.

Related Posts:

Sunday, 12 July 2020

Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'


At the TSG#88e Plenary meetings that ended on 03 July 2020, Release 16 was completed with both the Stage 3 freeze and the ASN.1 and OpenAPI specification freeze being approved. The 3GPP Release-16 page has more details on timelines but they may shift. See at the bottom of this post.

Anritsu have uploaded a short presentation on their channel that I am embedding below. I have skipped the beginning part but of you feel like you want to listen, jump to the beginning.




Meanwhile in the recently concluded TSG#88e Plenary meetings, there is a discussion on some of the timelines for Release-17 and Rel-18 moving. This graph below is from SP-200606.


In another piece of 3GPP news, RAN Working Group 6 (WG6 or RAN6) – responsible for the GERAN and UTRAN radio and protocol work - was formally closed.  No new features but specs will be maintained as necessary, of course.

Finally, here is a short video interview by 3GPP in which Balazs Bertenyi looks back at the recent TSG RAN Plenary e-meeting. He talks about the challenges, about IMT-2020, Rel-16 being just on time & the prospects for Rel-17.

Release 16 - RAN progress from 3GPPlive on Vimeo.


Related Posts:

Monday, 6 July 2020

A Technical Introduction to 5G NR RRC Inactive State


I looked at the RRC Inactive state back in 2017, but the standards were not completely defined. In the meantime standards have evolved and commercial 5G networks are rolling out left, right and centre. I made a short technical introduction to the RRC_INACTIVE state, comparing it with the 4G states in RRC and NAS. I also looked at some basic signalling examples and there are lots of relevant references at the end. Video and slides embedded below.






Related Posts:

Saturday, 4 July 2020

An Introduction to Vehicle to Everything (V2X) and Cellular V2X (C-V2X)


We made an introductory tutorial explaining vehicle to everything. There are 2 different favours of V2X as shown in this tweet below


One is based on IEEE 802.11p (802.11bd in future). It is known by different names, DSRC, ITS-G5, etc. The other is the cellular V2X or C-V2X. It started as basic D2D but has evolved over the time. The slides and video are embedded below but this topic will need revisiting with more details.







Related Posts:

Tuesday, 30 June 2020

A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn

In previous blog posts I have discussed intra-gNB-DU handover and inter-gNB-DU handover scenarios.Now it is time to look at inter-gNB-CU handover that uses the Xn interface.

At the RRC protocol layer there will be the measurement setups and measurement reports as in the intra-gNB handover cases. And F1AP UE Context Setup and Release Procedures are identical with the ones discussed for inter-gNB-DU handover. Only the cause values are expected to be different, e.g. "successful handover".

Thus, I do not want to  focus here on la adder diagram call flow (that is by the way very well described in 3GPP 38.401, chapter 8.9.4), but invite you to have a look at a "big picture" that you see below.

(click image to enlarge)

What characterizes the inter-gNB handover is the transfer of the UE RRC/NGAP context form the source gNB-CU to the target gNB-CU. When the Xn interface is available to connect two neighbor gNBs this context transfer is executed using the XnAP Handover Preparation procedure. The Initiating Message of this procedure transfers the UE context parameters to the target gNB-CU. Then embedded in the Successful Outcome message the handover command is sent in return to the source gNB-CU that forwards it to the UE. In addition a temporary user plane transport tunnel for the purpose of data forwarding is established and later on released on the Xn user plane interface.

Once the UE performed the handover on the radio interface all the transport tunnels for the payload transmission need to be switched from the old gNB to the new one. This includes the tunnel to the UPF that is managed by the NGAP. Thus, the target gNB-CU starts the NGAP Path Switch procedure. 

In the target gNB environment it is necessary to establish a new F1AP UE context, new E1AP Bearer Context and new F1-U payload transport tunnel. All this happens BEFORE the Handover Command is sent to the source gNB/UE. And once there is an indication that the handover is completed all the radio and transport resources controlled by the source gNB will be released.

So the figure above looks complicated, but actually the underlying logic of context/data forwarding, radio resource allocation and transport tunnel switching is quite simple.

Special note: In case there is no Xn interface available the UE context/handover information can be transmitted using NGAP Handover Preparation procedure on the source side of the connection and NGAP Handover Resource Allocation procedure on the target side of the connection.

Related Posts:

Tuesday, 23 June 2020

Comparison Layer 2 Measurements LTE vs. 5G NR


Yesterday (2020-06-22) 3GPP uploaded the version 1.0 of TS 38.314 "Layer 2 Measurements" for 5G New Radio Rel. 16.

I was wondering about the difference compared to the same LTE standard defined in 3GPP TS 36.314.

The initial look at the table of contents shows significantly less measurements in the NR spec, but a new counter for the number of stored inactive UE contexts. This is due to the introduction of RRC Inactive state in NR RRC specified in 3GPP TS 38.331)

All other differences in the NR standard are related to chapter number 4.2.1.6 "Other measurements defined in TS 28.552".

Here one finds the references to Data Volume, Average Throughput Measurement per UE and DRB as well as PRB usage measurements.

Adding these additional measurements to the list we see in the table of contents it emerges that indeed the number of stored inactive UE contexts is the only major difference in comparison with the LTE standard. 

Monday, 22 June 2020

Carrier Aggregation (CA) and Dual Connectivity (DC)


This topic keeps coming up every few months with either someone asking me for clarifications or someone asking us to make a video. While I don't think I will mange to get round to making a video sometime soon, there are some excellent resources available that should help a new starter. Here they are in an order I think works best



The first resource that I think also works best is this webinar / training from Award Solutions. It covers this topic well and the image at the top of the post is a god summary for someone who already understands the technology.


It may also help to understand that in the 5G NSA can have 4G carrier aggregation as well as 5G carrier aggregation in addition to dual connectivity.


If you saw the video earlier, you noticed that DC actually came as part of LTE in Release-12. We covered it in our Telecom Infrastructure blog here. NTT Docomo Technical journal had a detailed article on 'Carrier Aggregation Enhancement and Dual Connectivity Promising Higher Throughput and Capacity' that covered DC in a lot more technical detail, albeit from LTE point of view only. The article is available here. A WWRF whitepaper from the same era can also provide more details on LTE Small Cell Enhancement by Dual Connectivity. An archived copy of the paper is available here.

Another fantastic resource is this presentation by Rapeepat Ratasuk and Amitava Ghosh from Mobile Radio Research Lab, Nokia Bell Labs. The presentation is available here and details the MCG (Master Cell Group) Split Bearer and SCG (Secondary Cell Group) Split Bearer, etc. This article from Ericsson also provides more detail on this topic while ShareTechNote takes it one level even deeper with technical details and signalling here and here.

So hopefully this is a good detailed starting point on this topic, until we manage to make a simple video someday.

Friday, 12 June 2020

A Look into 5G Virtual/Open RAN - Part 5: Inter-gNB DU Handover

My last blog post discussed the intra-gNB-DU handover. Now it is time to look at inter-gNB-DU handover. This means: the target cell is located in the same gNB, but connected to a different gNB Distributed Unit (gNB-DU) than the source cell.

The figure below shows the message flow:

(Click on the image to enlarge)

As you can see it was not so easy to show all the messages in one flow chart and again I have simplified things a little bit. So it is not shown that NR RRC messages are transparently forwarded by the gNB-DU when sent to or received from the UE.

It should also be noted that between step 8 and 9 the UE performs a random access procedure on the radio interface that is also not shown.

Beside this the RRC measurement configuration and measurement report is identical with the same procedure in the intra-gNB-DU handover case (step 1+2)

However, due to the fact the target cell is connected to a different gNB-DU a new F1AP UE context must be established on the incoming F1-C leg (step 3+4). As in a new connection setup scenario the target gNB-DU provides all necessary lower layer parameters for the target cell radio link including a new c-RNTI.

Since we need also a new user plane transport tunnel to exchange payload on the F1-U interface between the target gNB-DU and the gNB-CU UP an E1AP Bearer Context Modification procedure is performed in step 5+6.

The following F1AP UE Context Modification Request is used to transmit the handover command (NR RRC Reconfiguration message with target cell parameters) towards the UE (step 7). In step 8 the F1AP UE Context Modification Response confirms that the handover command was forwarded to the UE.

After successful random access the UE sends NR RRC Reconfiguration Complete message on the new radio link (step 9) and this triggers the F1AP UE Context Release procedure on the outgoing F1-C leg.

Related Posts:

Tuesday, 9 June 2020

5G Roaming with SEPP (Security Edge Protection Proxy)

SEPP (Security Edge Protection Proxy) is part of the roaming security architecture as shown in the figure above. Ericsson's article, "An overview of the 3GPP 5G security standard" describes the use of SEPP as follows:

The use of SBA has also pushed for protection at higher protocol layers (i.e. transport and application), in addition to protection of the communication between core network entities at the internet protocol (IP) layer (typically by IPsec). Therefore, the 5G core network functions support state-of-the-art security protocols like TLS 1.2 and 1.3 to protect the communication at the transport layer and the OAuth 2.0 framework at the application layer to ensure that only authorized network functions are granted access to a service offered by another function.

The improvement provided by 3GPP SA3 to the interconnect security (i.e. security between different operator networks) consists of three building blocks:

  • Firstly, a new network function called security edge protection proxy (SEPP) was introduced in the 5G architecture (as shown in figure 2). All signaling traffic across operator networks is expected to transit through these security proxies
  • Secondly, authentication between SEPPs is required. This enables effective filtering of traffic coming from the interconnect
  • Thirdly, a new application layer security solution on the N32 interface between the SEPPs was designed to provide protection of sensitive data attributes while still allowing mediation services throughout the interconnect

The main components of SBA security are authentication and transport protection between network functions using TLS, authorization framework using OAuth2, and improved interconnect security using a new security protocol designed by 3GPP.

NG.113 5G Roaming Guidelines v2.0 clarifies:

4.2 Inter PLMN (N32) Interface

The Inter-PLMN specification 3GPP TS 29.573 has been produced by 3GPP to specify the protocol definitions and message flows, and also the APIs for the procedures on the PLMN (Public Land Mobile Network) interconnection interface (i.e. N32)

As stated in 3GPP TS 29.573 the N32 interface is used between the SEPPs of a VPLMN and a HPLMN in roaming scenarios. Furthermore, 3GPP has specified N32 to be considered as two separate interfaces: N32-c and N32-f.

N32-c is the Control Plane interface between the SEPPs for performing the initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding. See section 4.2.2 of 3GPP TS 29.573.

Once the initial HTTP/2 handshake is completed the N32-c connection is torn down. This connection is End-to-End between SEPPs and does not involve IPX to intercept the HTTP/2 connection; although the IPX may be involved for IP level routing.

N32-f is the Forwarding interface between the SEPPs, that is used for forwarding the communication between the Network Function (NF) service consumer and the NF service producer after applying the application level security protection. See section 4.2.3 of 3GPP TS 29.573.

N32-f can provide Application Level Security (ALS) as specified in 3GPP TS 33.501 between SEPPs, if negotiated using N32-c. ALS provides the following protection functionalities: -

  • Message protection of the information exchanged between NF service consumer and producer
  • Forwarding of the application layer protected message from a SEPP in one PLMN to another PLMN by way of using IPX providers on the path. The IPX providers on the path may involve the insertion of content modification instructions which the receiving SEPP applies after verifying the integrity of such modification instructions.

The HTTP/2 connection used on N32-f is long lived; and when a SEPP establishes a connection towards another PLMN via IPX, the HTTP/2 connection from a SEPP terminates at the next hop IPX.

N32-f makes use of the HTTP/2 connection management requirements specified in 3GPP TS 29.500. Confidentiality protection shall apply to all IE’s for the JOSE protected message forwarding procedure, such that hop-by-hop security between SEPP and the IPXs should be established using an IPSec or TLS VPN.

If an IPX is not in the path between SEPPs, then an IPSec of Transport Layer Security, TLS VPN will be established directly.

Note: N32-f shall use “http” connections generated by a SEPP, and not “https”

The SEPP will act as a non-transparent Proxy for the NF’s when service based interfaces are used across PLMNs, however inside IPX service providers, an HTTP proxy may also be used to modify information elements (IE’s) inside the HTTP/2 request and response messages.

Acting in a similar manner to the IPX Diameter Proxy used in EPC roaming, the HTTP/2 Proxy can be used for inspection of messages, and modification of parameters. 


The picture in the tweet above shows how SEPP will play a role in Local Break Out (LBO) roaming as well as Home Routed (HR) roaming.

Related Posts:

Tuesday, 2 June 2020

Embedded SIM (eSIM) and Integrated SIM (iSIM)

It's been a while since I wrote detailed posts explaining UICC and SIM cards. Since then the SIM cards have evolved from Mini SIM to Micro SIM and Nano SIM. They are evolving even further, especially for M2M / IoT devices as embedded SIM (eSIM or eUICC) and integrated SIM (iSIM).


Embedded SIMs (eSIMs) or embedded Universal Integrated Circuit Cards (eUICCs) are physical SIMs that are soldered into the device and enable storage and remote management of multiple network operator profiles (remote SIM provisioning). The form factor of eSIM is known as MFF2.

The integrated SIMs (iSIMs) moves the SIM from a separate chip into a secure enclave alongside the application processor and cellular radio on a purpose-built system on a chip (SoC).

We made a short tutorial explaining UICC & SIM and then looking at eSIM, iSIM and how remote SIM provisioning works. The video and slides are embedded below. The slides contain a lot of useful links for further reading.







Related Posts:

Friday, 29 May 2020

Visualisation of Intra-gNB Handover in an End-to-End Monitoring Tool


In my last blog post I described the message flow of an intra-gNB-DU handover.

Today I want show how such a handover can be visualized using a ladder diagram in an end-to-end passive monitoring tool. The tool shown in the figure below is the NETSCOUT nGenious Session Analyzer (nSA).

The data source is a cell trace feed according to 3GPP 32.421/32.423. Unfortunately F1AP and E1AP messages are missing in the trace so that we cannot distinguish if this is an intra- or inter-gNB DU handover.

(click to enlarge)

Nevertheless the tool offers the great advantage to find the handover procedure quickly within all the other messages of the trace. It also links the outgoing (source) and incoming (target) side in case that different feeds from different cells need to be combined.

For the NR RRC messages are send/received by the UE, but there is a good reason to show the icon "Cell" on top the ladder diagram. With this approach it is possible to spot immediately the changing cell location of the UE and NR RRC Reconfiguration procedure that is used to execute the handover. So the icon does not represent a cell, but an UE within a cell - and with a bit imagination you can recognize this in the icon graphic itself.

Selecting the handover message it is possible to open the Inline Decode tab and browse through the bits and bytes of NR RRC. As expected beside many other parameters the new UE Identity (new C-RNTI) to be used by the UE after arriving in the target cell is one of the most important information elements and confirms that this particular NR RRC Reconfiguration message is indeed the command for executing the intra-gNB handover.

Tuesday, 26 May 2020

The Journey from Communications Service Provider (CSP) to Digital Service Provider (DSP)

Reliance Jio has recently been called as India's first digital service provider (DSP), but what exactly is a DSP and how does an existing mobile network transform from the traditional communications service provider (CSP) to a DSP?

Service Providers are also known as Telecommunications Service Provider (TSP) or Communications Service Provider (CSP). Basically, they refer to someone who provides services.

Mobile Network Operators (MNOs) are also referred to as Mobile Service Providers (MSPs) or Wireless Service Providers (WSPs). Even though CSP is a generic term, it generally always refers to MSP.

The term “Digital Service Provider" applies to any company that distributes media online. In the case of telcos, it's an organization that has moved on from offering core, traditional telecom services, to providing mobile broadband access, services, content and apps, all sold directly from the device.

Analysys Mason provides this simple equation to explain how a CSP can transform into DSP


Another way of representing this is to compare CSP & DSP as shown in the table below

We made a tutorial on this topic, the slides and video is embedded below. If you want to jump directly to the DSP part, move to 2:35 in the video.





Finally, another term that gets thrown around often confuses people is Telco & Netco


Telco stands for Telecommunications Company, which basically means Mobile Network Operator.

NetCo or Network cooperation is the practice of a Mobile Network Operator (MNO) sharing part of its Radio Access Network (RAN) with another MNO.

There are other terms like Towerco & Infraco that probably deserve their own post.


Related Posts:



Tuesday, 19 May 2020

5G Dynamic Spectrum Sharing (DSS)

5G Dynamic Spectrum Sharing is a hot topic. I have already been asked about multiple people for links on good resources / whitepapers. So here is what we liked, feel free to add anything else you found useful as part of comments.


Nokia has a nice high level overview of this topic which is available here. I really liked the decision tree as shown in the tweet above. I am going to quote a section here that is a great summary to decide if you want to dive deeper.

DSS in the physical layer
DSS allows CSPs to share resources dynamically between 4G and 5G in time and/or frequency domains, as shown on the left of Figure 3. It’s a simple idea in principle, but we also need to consider the detailed structure at the level of the resource block in order to understand the resource allocations for the control channels and reference signals. A single resource block is shown on the right side of Figure 3.

The 5G physical layer is designed to be so similar to 4G in 3GPP that DSS becomes feasible with the same subcarrier spacing and similar time domain structure. DSS is designed to be backwards compatible with all existing LTE devices. CSPs therefore need to maintain LTE cell reference signal (CRS) transmission. 5G transmission is designed around LTE CRS in an approach called CRS rate matching.

5G uses demodulation reference signals (DMRS), which are only transmitted together with 5G data and so minimize any impact on LTE capacity. If all LTE devices support Transmission Mode 9 (TM9), then the shared carrier has lower overheads because less CRS transmission is required. The control channel transmission and the data transmission can be selected dynamically between LTE and 5G, depending on the instantaneous capacity requirements.


The second resource is this Rohde & Schwarz webinar here. As can be seen in the tweet above, it provides nice detailed explanation.

Finally, we have a Comprehensive Deployment Guide to Dynamic Spectrum Sharing for 5G NR and 4G LTE Coexistence, which is a nice and detailed whitepaper from Mediatek. Quoting a small section from the WP for anyone not wanting to go too much in deep:

The DSS concept is based on the flexible design of NR physical layer. It uses the idea that NR signals are transmitted over unused LTE resources. With LTE, all the channels are statically assigned in the time-frequency domain, whereas the NR physical layer is extremely flexible for reference signals, data and control channels, thus allowing dynamic configurations that will minimize a chance of collision between the two technologies. 

One of the main concepts of DSS is that only 5G users are made aware of it, while the functionalities of the existing LTE devices remain unaffected (i.e. LTE protocols in connected or idle mode). Therefore, fitting the flexible physical layer design of NR around that of LTE is needed in order to deploy DSS on a shared spectrum. This paper discusses the various options of DSS implementation, including deployment challenges, possible impacts to data rates, and areas of possible improvements.

NR offers a scalable and flexible physical layer design depicted by various numerologies. There are different subcarrier spacing (SCS) for data channels and synchronization channels based on the band assigned. This flexibility brings even more complexity because it overlays the NR signals over LTE, which requires very tight coordination between gNB and eNB in order to provide reliable synchronization in radio scheduling.

The main foundation of DSS is to schedule NR users in the LTE subframes while ensuring no respective impact on LTE users in terms of essential channels, such as reference signals used for synchronization and downlink measurements. LTE Cell Reference Signals (CRS) is typically the main concept where DSS options are designated, as CRS have a fixed time-frequency resource assignment. The CRS resources layout can vary depending on the number of antenna ports. More CRS antenna ports leads to increased usage of Resource Elements (REs). CRS generates from 4.76% (1 antenna port) up to 14.29% (4 antenna ports) overhead in LTE resources. As CRS is the channel used for downlink measurements, avoiding possible collision with CRS is one of the foundations of the DSS options shown in figure 1. The other aspect of DSS design is to fit the 5G NR reference signals within the subframes in a way to avoid affecting NR downlink measurements and synchronization. For that, DSS considers the options shown in figure 1 to ensure NR reference signals such as Synchronization Signal Block (SSB) or Demodulation Reference Signal (DMRS) are placed in time-frequencies away from any collision with LTE signals.

MBSFN, option 1 in figure 1, stands for Multi-Broadcast Single-Frequency Network and is used in LTE for point-to-multipoint transmission such as eMBMS (Evolved Multimedia Broadcast Multicast Services). The general idea of MBSFN is that specific subframes within an LTE frame reserve the last 12 OFDM symbols of such subframe to be free from other LTE channel transmission. These symbols were originally intended to be used for broadcast services and are “muted” for data transmission in other LTE UE. Now this idea has been adjusted for use in a DSS concept, so that these reserved symbols are used for NR signals instead of eMBMS. While in general LTE PDCCH can occupy from 1 to 3 symbols (based on cell load), the first two OFDM symbols of such MBSFN subframe are used for LTE PDCCH, and DSS NR UE can use the third symbol. Using MBSFN is completely transparent to legacy LTE-only devices from 3GPP Release 9 onwards, as such LTE UE knows that these subframes are used for other purposes. In this sense this is the simplest way of deploying DSS. This method has disadvantages though. The main one is that if MBSFN subframes are used very frequently and it takes away resources from LTE users, heavily reducing LTE-only user throughput. Note that option 1 shown in figure 1 does not require LTE MBSFN Reference Signals to be used, because the MBSFN subframe is used to mute the subframe for DSS operation only, and LTE CRS shall only be transmitted in the non-MBSFN region (within the first two symbols) of the MBSFN subframe.

The two other options illustrated in figure 1 are dealing with non-MBSFN subframes that contain LTE reference signals. Option 2 is ‘mini-slot’ based; mini-slot scheduling is available in NR for URLLC applications that require extremely low latency. The symbols can be placed anywhere inside the NR slot. In respect to DSS, mini-slot operation just eliminates the usage of the symbols that contain LTE CRS and schedule only free ones for NR transmission. The basic limitation of this method comes from the concept itself. It is not very suitable for eMBB applications as too many resources are outside of NR scheduling. However it still can be utilized in some special cases like 30 kHz SSB insertion which will be described later in this paper.

Option 3 is based on CRS rate matching in non-MBSFN subframes, and it is expected to be the one most commonly used for NR data channels. In this option, the UE performs puncturing of REs used by LTE CRS so that the NR scheduler knows which REs are not available for NR data scheduling on PDSCH (Physical Downlink Shared Channel). The implementation of this option can be either Resource Block (RB)-level when the whole RB containing LTE CRS is taken out of NR scheduling, or RE-level where NR PDSCH scheduling avoids particular REs only. The end result of this method is that the scheduler will reduce the NR PDSCH transport block size as the number of REs available for scheduling become less in a slot.


Personally, I am not a big fan of DSS mainly because I think it is only useful in a very few scenarios. Also, it helps operators show a 5G logo but doesn't provide a 5G experience by itself. Nevertheless, it can come in handy for the coverage layer of 5G.


In one of the LinkedIn discussions (that I try and avoid mostly) somebody shared this above picture of Keysight Nemo DSS lab test results. As you can see there is quite a bit of overhead with DSS.

Thursday, 14 May 2020

A Look into 5G Virtual/Open RAN - Part 4: Intra-gNB DU Handover

In the previous posts of this series I described O-RAN interfaces and protocols, connection establishment and connection release procedures. Now it is time to look at handovers.

As mentioned in one of the earlier posts the gNB-CU CP will be in charge of controlling hundreds of gNB-DUs in a similar way like the 3G RNC was in charge of controlling hundreds of UMTS NodeBs. As a result the most common 5G SA intra-system handovers will be intra-gNB handovers. These handovers can further be classified into intra-gNB-DU handovers (inter- as well as intra-frequency) and inter-gNB-DU handovers.

Due to the virtualization of RAN network functions we will also find another form of switching transmission path, which is a change of the gNB-CU UP during the call without mobility of the UE. This scenario I will discuss later in a separate blog post.

Today I want to focus on the intra-gNB DU handover. Here the UE moves from one cell to another one within the same distributed unit as shown in the figure below.



A prerequisite is the successful establishment of a NR RRC connection and a F1AP UE Context between the gNB-DU and the gNB-CU CP.

The F1AP transports all RRC messages between these two entities. Indeed, it transports the PDCP blocks and the gNB-DU is not aware that these PDCP blocks contain RRC messages. However, for better illustration I have not shown the PDPC part in the ladder diagram.

What we see in step 1 is a NR RRC Reconfiguration message that contains RRC measurement configurations to be enabled on the UE side. A typical trigger event for intra-frequency handovers is the A3 event that is already known from LTE RRC.

Once the UE detects a better neighbor cell meeting the A3 criteria it sends a RRC Measurement Report to the gNB-CU CP (step 2).

In step 3 the gNB-CU CP orders the gNB-DU to perform a F1AP UE Context Modification. The purpose is to allocate radio resources for the UE in the target cell and to prepare the cell change.

The gNB-DU replies with F1AP UE Context Modification Response. This messages contains the new C-RNTI and a large block of lower layer configuration parameters (e.g. for RLC and MAC layer) that need to be sent to the UE and thus, need to be transported to the gNB-CU CP before, because it is the only RAN function capable to communicate with the UE using the RRC protocol.

Hence, in step 5 we see another downlink RRC message transfer. This time it is used to transport the handover command towards the UE. The handover command is a NR RRC Reconfiguration message and it contains the new C-RNTI (new UE identity within the cell) as well as the physical cell ID of the target cell and the full set of lower layer configuration parameters previously provided by the gNB-DU.

When the gNB-CU CP receives the RRC Reconfiguration Complete message sent by the UE in step 6 the handover is successfully completed and the UE is now served by the cell with NR PCI 2.

As mentioned before there is neither XnAP (communication between two neighbor gNBs) nor NGAP (communication between gNB and AMF) involved in this handover procedure.

Related Posts: