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:

• A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn
• 3G4G: Open RAN, OpenRAN and O-RAN

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. 

A new version of @GSMA 5G Roaming Guidelines was released in May 2020 - https://t.co/GCcDG68wnK#Free5Gtraining #5G #5GNetworks #5GS #5GC #5GRoaming #VPLMN #HPLMN #SEPP #LBO #HR #EPC pic.twitter.com/ZzL1io0QF5

— 5G Training (@5Gtraining) June 8, 2020

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:

• The 3G4G Blog: Everything you need to know about 5G Security
• 3G4G: Security in Mobile Cellular Systems
• The 3G4G Blog: Service Based Architecture (SBA) for 5G Core (5GC) Tutorial
• The 3G4G Blog: 5G eXtended Reality (5G-XR) in 5G System (5GS)
• The 3G4G Blog: Guest Post - Exploring Network Convergence of Mobile, Broadband and Wi-Fi

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.

Beginners: UICC & SIM from 3G4G

Related Posts:

• The 3G4G Blog: Multi-SIM: The Jargon
• The 3G4G Blog: M2M embedded UICC (eSIM) Architecture and Use Cases
• The 3G4G Blog: The Journey from Communications Service Provider (CSP) to Digital Service Provider (DSP)
• 3G4G: MNO, MVNO, MVNA, MVNE: Different types of mobile operators
• The 3G4G Blog: UICC and ISIM (IMS SIM)

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.

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.

Beginners: Different Types of Service Providers (SPs) from 3G4G

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:

• 3G4G: MNO, MVNO, MVNA, MVNE: Different types of mobile operators
• The 3G4G Blog: Quick tutorial on Mobile Network Sharing Options
• The 3G4G Blog: How MOCN RAN-Sharing Works
• Connectivity Technology Blog: Different Types Of Service Providers
• Operator Watch Blog: Jio is the Largest Mobile Network in India by Subscriber Numbers

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.

Nice new whitepaper - Nokia dynamic spectrum sharing for rapid 5G coverage rollout - https://t.co/HdnTz4ZIgr

via @nokianetworks #Free5Gtraining #5G #5GNR #5GNetworks #Nokia #4G #5GSpectrum #Spectrum #DSS #DynamicSpectrum pic.twitter.com/APSnW9vrUp

— 5G Training (@5Gtraining) May 7, 2020

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.

A nice webinar looking at 5G Dynamic Spectrum Sharing a.k.a. DSS. A simple explanation is, use MBSFN subframes to tell LTE users that these resource blocks are not available and then use that spectrum for 5G NR.https://t.co/ettybXHMWV pic.twitter.com/zq7BQ9ImdB

— 3G4G (@3g4gUK) December 7, 2019

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.

VodafoneZiggo launching 5G in Netherlands using DSS from Ericsson in 1800MHz band. Due to spectrum situation in Ned this is all VZ has at launch so it's 5G on the icon but offering customers only 10% faster speeds than they can get with 4G. https://t.co/BLirTX8XjU

— Keith Dyer (@keithdyer) April 28, 2020

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.

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:

• A Look into 5G Virtual/Open RAN - Part 5: Inter-gNB DU Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

5G Remote Surgery and Telehealth Solutions

One of the most controversial 5G use cases is the remote surgery. In this post I want to quickly look at the history and what is possible. Before I go to that, here is a short summary video that I am embedding upfront.



As far as I can recall, Ericsson was the first vendor that started talking about remote surgery. This is a tweet from back in 2017.

With #5G and the tactile internet, doctors can perform remote
surgery on a patient anywhere in the world. https://t.co/U81bayv3ws pic.twitter.com/pSXFg1NCJX

— Ericsson (@ericsson) August 28, 2017

Huawei didn't want to be far behind so they did one at MWC Shanghai in 2018. Their tweet with video is embedded below.

Meet the Remote Surgery Robot. At #MWCS18, Huawei stiches together a vivid picture of how #5G’s reliable connection can save lives: https://t.co/cobykl1KKP #WirelessXLabs pic.twitter.com/Pbme8BmcoT

— Huawei (@Huawei) June 28, 2018

In January 2019, South China Morning Post (SCMP) showed a video of a remote surgery on an animal. While the video and the article didn't provide many details, I am assuming this was done by Huawei as detailed here. The video of the surgery below.



This was followed by Mobile World Congress 2019 demo where a doctor used 5G to direct surgery live from a stage at MWC to Hospital Clinic Barcelona over 3 miles away. The team of doctors was removing a cancerous tumor from a patient's colon. This video from that is embedded below.



Vodafone New Zealand had a silly remote surgery of a dog video but looks like they have removed it.  Nothing can beat this Telecom Italia ad embedded below.



There are some realistic use cases. One of them being that with 5G the number of cables / wires in a hospital can be reduced saving on the disinfection.

NTT Docomo showcased 5G Mobile SCOT (Smart Cyber Operating Theater) which is an Innovative solution to enable advanced medical treatment in diverse environments. You can read more details here.

There are lots of other things going on. Here is a short list:

• April 2020: Because of Coronavirus COVID-19, NT Times has an article on Telemedicine Arrives in the U.K.: ‘10 Years of Change in One Week’ - even though this does not involve 5G, it just shows that we are moving in that direction.
• February 2020: 5G-aided remote CT scans used to diagnose COVID-19 patients in China (link)
• February 2020: Verizon teamed with Emory Healthcare to test new 5G use cases for the medical industry at the latter’s Innovation Hub in Atlanta, in a bid to discover how the technology can be used to improve patient care. The collaboration will explore applications including connected ambulances; remote physical therapy; medical imaging; and use of AR and VR for training. (link)
• February 2020: Vodafone 5G Healthcare – Conference & Experience Day (link)
• November 2019: TIM enables first live remote-surgery consultation using 5G immersive reality (link)
• October 2019: Along with a hospital in Malaga, Telefónica has presented what it claims is the first expert assistance system for medical interventions that runs on 5G. (link and video)
• September 2019: Mobile Future Forward 2019 - World's First Remote VR Surgery Demo conducted on Sept 4th, 2019 in Seattle by Chetan Sharma, James Youngquist, Evie Powell, Nissim Hadar, David Colmenares, and Gabe Jones. (link)

Finally, a nice video on Benefits of 5G for Healthcare Technology by T-Mobile



Related Posts:

• The 3G4G Blog: NTT Docomo's Vision on 5G Evolution and 6G
• The 3G4G Blog: 5G eXtended Reality (5G-XR) in 5G System (5GS)
• The 3G4G Blog: Real-life 5G Use Cases for Verticals from China
• The 3G4G Blog: 5G Private and Non-Public Network (NPN)
• The 3G4G Blog: 5G and Industry 4.0
• The 3G4G Blog: Spectrum for 5G NR beyond 52.6 GHz

How the A6 Measurement Event triggers Secondary Cell Change in LTE Carrier Aggregation Calls

Last week I read in Martin Sauter's blog about the LTE RRC A6 measurement event.

Although I am quite interested in RRC measurements I have never seen the A6 event in action. Rather the eNB vendors have implemented carrier aggregation in a way that the UE provides its capabilities and according to the this the maximum possible numbers of component carriers is added to the connection. There is no RRC measurement report before adding secondary LTE cells to the connection. So what is the A6 event good for and is it used at all?

Surprisingly I needed only 2 attempts to find an example of using the A6 event in a live network configuration. It is used when more component carriers are available than the UE can simultaneously handle. E.g. if there are 4 or more cells with different carrier frequencies available in the same antenna sector the A6 event ensures after the initial CA configuration that the cells with the best radio conditions are selected as secondary cells.

Let's have a look at this scenario in detail. Figure 1 shows the report configuration for the A6 event. Keep the reportConfigId = 3 in mind.

Figure 1: Report Configuration for Event A6

The next step is the configuration of the Measurement ID as shown in figure 2. Here the reportConfigId is combined with a measObjectId that represents the carrier frequency of the potential SCell.

Figure 2: Measurement ID for Event A6

Now, if the event A6 is triggered in the UE a RRC Measurement Report with this measId = 3 is sent to the eNB as shown in Figure 3.

Figure 3: RRC Measurement Report for Event A6

There we see the RSRP and RSRQ of the primary cell (PCell) and of the currently serving secondary cells (SCells). By the way the servFreqId stands for the sCellIndex value that was linked to the physical cell ID (PCI) when this SCell was added in a previous RRC Connection Reconfiguration procedure. 

And as one can see the neighbor cell with PCI = 470 has significantly better RSRP and RSRQ to offer than both currently used SCell. 

Consequently the eNB decides to replace the SCell with sCellIndex value 1 with the better cell (PCI 470). This is again done with a RRC Connection Reconfiguration procedure as shown in figure 4. And this is the way how the A6 event is used.

Figure 4: Change of SCell

  

Virve 2.0 - Finland's 4G/5G Public Safety Network

State Security Networks Group Finland (Erillisverkot) safeguards the Finnish society by offering authorities and critical operators engaged in critical infrastructure and services secure and reliable ICT services. Much like in the civilian world, communication between authorities includes transferring images and video material to an increasing degree, which results in ever-growing data transfer volumes and, subsequently, new kinds of demands for all communication networks. 

Virve is a means of ensuring communication and cooperation between authorities and other partners across organisational borders into the future. It also entails the introduction of a higher service standard, as the transfer to broadband, estimated to take place in 2022, will make it possible to transfer video material, images and data. This will mean that it will be possible to send video material in a reliable and secure way in the case of accidents, for example. The radio network Virve, based on Tetra technology, will reach the end of its lifecycle by the end of the 2020s. The current Virve network will be used simultaneously with the new Virve 2.0 network until, at least, 2025.

Erillisverkot will acquire the broadband Virve 2.0 radio access network as a service from Elisa and the core systems from Ericsson. Separate networks will ensure the continuity of critical communications and operational capability of public safety in all situations in the future.

I would assume this would be MOCN, similar to the UK deployment of ESN networks as shown here.

Virve 2.0 subcribers will use Elisa’s public radio network, which the operator is expanding to become Finland’s largest data and voice network.

About 80 million messages pass through the Virve system every week. Elisa is committed to increasing the coverage, capacity and verification of its mobile network to meet the requirements of Virve 2.0.

The new online services will provide support for critical communication between public authorities and other parties.

The addition of image, video, and other wireless broadband services alongside existing Virve services will enable a better and more up-to-date view of the day-to-day operations of authorities and other actors.

The IoT enables automatic monitoring of rescue personnel and mobile use of surveillance cameras and drones.

The Virve 2.0 radio network service will be in use from 2021 and will include the 4G and 5G technologies and the internet of things. The contract is for ten years.

Finally, a recent advert of Elisa explaining 5G to outside world



Further Study:

• Erillisverkot: Obstacles for MCX Broadband and how to overcome them [PDF]
• Erillisverkot: Virve Broadband Plans for the Future - Critical Communications Europe 2019 [PDF]
• 5G-XCast Whitepaper: Rapidly Deployable Network System for Critical Communications in Remote Locations [PDF]
• Erillisverkot: White paper - Virve 2.0 RFI Summary of responses [PDF]
• Erillisverkot: Factsheet - What is Virve 2.0? [PDF]

Related Posts:

• Operator Watch Blog: Elisa claims "first in world to launch commercial 5G" - technical details and controversy
• The 3G4G Blog - Finland: A country with only Unlimited Data Plans
• The 3G4G Blog: 3GPP Release-16, Release-17 & Beyond...
• The 3G4G Blog: Update from 3GPP on LTE & 5G Mission Critical Communications
• The 3G4G Blog: Update on UK's Emergency Services Network (ESN) from #BAPCO2019
• The 3G4G Blog: A practical use of MOCN in ESN
• Telecoms Infrastructure Blog: Meshing for BYOC (Bring Your Own Coverage)