Wednesday, 6 May 2020

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:

Friday, 1 May 2020

The Futuristic Concept of 'Smart & Intelligent' Batteries


I did a presentation back in 2013 on the concept of smart batteries. Even though there has been a lot of progress in wireless charging since back then, it hasn't reached even close to the vision that I have. As a result, I converted it into a video to start a discussion on if and when this would be possible. The slides and video are embedded below and I welcome any discussion in comments below.






Tuesday, 28 April 2020

Comparing S1AP and NGAP UE Context Release


As an addition to my blog post about the 5G RAN Release procedure I would like to have an in-depth view at the details of NGAP UE Context Release Complete message.

Indeed, the S1AP (known from E-UTRAN) and the NGAP are very similar protocols and when reading the 3GPP specs it is obvious that many message names are identical and the procedures fulfill the same purpose when looking at call scenarios.

However, the difference is visible in the details as one can see when looking at the figure below.

While the S1AP UE Context Release Complete message does not contain any additional information we find in the NGAP UE Context Release Complete the identity of the last serving 5G cell, represented by the NR-CGI, the last visited Tracking Area Identity (TAI) and a list with the IDs of the PDU sessions (E-RABs) that have been terminated when the UE context was released.

This additional information in very valuable for network troubleshooting, since in LTE (S1AP) only the ID (ECGI) of the initial serving cell or a new serving cell ID at inter-node handover was signaled. And if you wanted to know how many E-RABs have been terminated with a S1AP UE Context Release procedure it was necessary to look back into the full sequence of call-related S1AP messages starting with the messages for Initial Context Setup.

All in all, with 5G NGAP trace analysis and the life of RAN engineers becomes easier. Thank you, 3GPP! 

Comparision of S1AP and NGAP UE Context Release Complete Messages

Friday, 24 April 2020

A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend

The 3rd post of this series introduces the details of connection release in the 5G RAN.

Indeed, we find most of the release causes known from E-UTRAN in the 5G specs and it is clear that all protocols that have been involved in the connection setup need to be perform a release procedure at the end of the connection.

However, again the split into different virtual functions brings the demand for some addition messages.

This is illustrated in figure 1 for the a release due to "user inactivity", which means: the gNB-CU UP detected that for a define time (typical settings for the user inactivity timer are expected to be between 10 and 20 seconds) no downlink payload packets have been arrived from the UPF to be transmitted.

So the gNB-CU UP sends an E1AP Bearer Context Inactivity Notification message to the gNB-CU CP that triggers the release procedures on NGAP, F1AP, RRC and E1AP. The RRC Releases message is transported over the F1 interface to the gNB-DU where is forwarded across the radio interface to the UE.


Figure 1: Connection Release due to "user inacativity"
An alternative to the connection release is the RRC Suspend procedure shown in figure 2. Here the UE is ordered to switch to the RRC Inactive state, which allows a very quick resume of the RRC connection when necessary.

Figure 2: RRC Connection Suspend

In case of suspending the RRC connection the RRC Release message contains a set of suspend configuration parameters. The probably most important one is the I-RNTI, the (RRC) Inactive Radio Network Temporary Identity.

If the RRC connection is suspended, F1AP and E1AP Contexts are released, but the NGAP UE Context remains active. Just NGAP RRC Inactivity Transition Report is sent to the AMF.

Related Posts:

Monday, 20 April 2020

A Look at the same RRC Message in LTE and 5G Stand-alone Call Scenarios


Some weeks ago the differences in 4G LTE RRC (3GPP 36.331) and 5G NR RRC (3GPP 38.331) and how both protocols interact in EN-DC call scenarios have been discussed in another blog post.

Now I would like to share a visual comparison of the RRC (Connection) Setup Complete message as it is seen in LTE (including EN-DC) and 5G stand-alone (SA) radio connections.

From the figure below one can see that although this message fulfills the same purpose in both radio access technologies its particular contents may look quite differently.

Different variants of RRC (Connection) Setup Complete message in LTE and 5G stand-alone call scenarios

Sunday, 19 April 2020

SCF Releases 5G Functional API to Enable Open Small Cells Ecosystem


The Small Cell Forum (SCF) announced the publication of documents focused on stimulating a competitive ecosystem for vendors of 5G-era small cell hardware, software and equipment. The expanded set of specifications contained in these documents are:
According to the press release:

Expanding upon the 5G Physical Layer API specification, published in July 2019, the new specifications enable small cells to be constructed piece-by-piece using components from different vendors, in order to address the diverse mixture of 5G use cases relatively easily, a common goal to all of the specifications made by Small Cell Forum.

The new release also includes two completely new specifications, SCF223: 5G NR FAPI P19 FrontEnd Interface Specification and SCF224: Network Monitor Mode API for Small Cells.


According to Dr. Prabhakar Chitrapu, Chair of SCF, “FAPI helps Equipment Vendors to mix PHY & MAC Software from different suppliers via this open FAPI interface. So, FAPI is an 'internal' interface.”

“5G-nFAPI (network FAPI) is a 'network' interface and is between a Distributed Unit and Centralised Unit  of a Split RAN/Small Cell network solution. An open specification of this interface (nFAPI) will help network architects by allowing them to mix distributed and central units from different vendors.”

SCF nFAPI is enabling Open RAN ecosystem in its own way by allowing any small cell CU/DU (S-CU / S-DU) to connect to any small cell radio unit (S-RU)

Here is a video playlist from SCF that explains the new API's



Related Posts:

Tuesday, 14 April 2020

Mobility Analysis: Austrians Stay at Home

The Austrian company Invenium Data Insights GmbH has partnered with the mobile network operator A1 to analyze and visualize subscriber mobility pattern on a public dashboard to illustrate the impact of the severe restrictions on people’s mobility (and its expected reversal) due to the COVID-19 pandemic.

Screenshot of the public dashboard (click picture to enlarge)

In a side note (in the screenshot highlighted in yellow) and in their blog the partners guarantee that the underlying data is fully anonymous and not derived from customer data. This was certified by TüV, an independent Technical Inspection Association.

Although I have no insight into this particular project I assume that the underlying raw data is provided by eNBs using the 3GPP-defined maximum detail level cell trace according to 3GPP 32.423.

This means that the trace collection entity gets the full ASN.1 contents of all RRC, S1AP and X2AP messages, but NAS messages - if provided at all - are encrypted. Also the eNB has not insight into any user plane applications since it has no means to decode the IP payload. This guarantees that neither IMSI, IMEI, web addresses nor phone numbers are found in the raw data.

The key for a meaningful mobility analysis using this data might be the fact that the S-TMSI value in E-UTRAN rarely changes and due to user inactivity settings each subscriber generates multiple RRC connections per hour. Within these RRC connections we find RRC Measurement Reports and typically also some vendor-specific events providing other important radio parameters from the radio interface lower layers including uplink radio quality measurements like PUSCH SINR.

By looking at multiple RRC connections of the same S-TMSI and the reported air interface measurements it is possible to determine if the subscriber remains at the same place or moves around. It it also possible to determine if a subscriber is located indoor or outdoor.

The trace collection entity writes the analysis results into a comprehensive data set that can be used to mask and scramble even S-TMSI values for additional data privacy. The raw data is deleted.

At the end this methodology allows a highly reliable mobility analysis while simultaneously protecting the data privacy of subscribers. The key difference in comparison to statistics based on crowd-sourced data as published e.g. by umlaut is the fact that the 3GPP cell trace provides data for all RRC connections in the network while crowd-sourced data collection requires the installation of certain apps (in case of umlaut only Android apps are supported) and the subscriber's confirmation to collect the data.

However, it must be mentioned that the 3GPP cell trace cannot be used as a data source for the widely discussed Corona contact tracking apps that allow to identify subscribers that have been in close proximity with someone who has been tested positive for COVID-19. For this purpose cell trace data lacks the necessary accuracy to determine the subscriber's and its neighbor's positions.