TSDSI's Low Mobility Large Cell (LMLC) Requirements in 5G

Back in November 2020, ITU completed the evaluation for global affirmation of IMT-2020 technologies. Three new technologies were successfully evaluated by ITU and were found to conform with the International Mobile Telecommunications 2020 (IMT-2020) vision and stringent performance requirements. The technologies are: 3GPP 5G-SRIT and 3GPP 5G-RIT submitted by the Third Generation Partnership Project (3GPP), and 5Gi submitted by Telecommunications Standards Development Society India (TSDSI). 

I have explained in earlier videos that 5G-SRIT  and 5G-RIT corresponds to Non-Standalone and Standalone respectively. 5Gi on the other hand is an updated version of 5G-RIT designed mainly to improve rural coverage. 

ITU completes evaluation for global affirmation of IMT-2020 technologies - https://t.co/dmALByqXh1 - So the 2 3GPP (@3GPPLive) 5G technologies 5G-SRIT and 3GPP 5G-RIT, and 5Gi submitted by TSDSI (@TSDSI_India) conform with IMT-2020 vision and stringent performance requirement. https://t.co/lFhfugcLux

— Zahid Ghadialy (@zahidtg) November 27, 2020

TSDSI announced this as follows:

TSDSI’s 5G Radio Interface Technology named as “5Gi” has cleared the rigorous processes of  International Telecommunication Union (ITU) and has been approved by the SG5 of ITU as a part of Draft Recommendation M.[IMT-2020.SPECS] in its meeting held on 23rd November 2020.

5Gi, the first  ever Mobile Radio Interface Technology contribution from India to become part of ITU-R’s  IMT recommendation, went through a rigorous evaluation process of the ITU-R working groups over the past 3 years before getting the approval.

This standard is a major breakthrough for bridging the rural-urban digital divide in 5G deployment due to enhanced coverage. It enables connecting majority of India’s villages through towers located at gram panchayats in a cost effective manner. It has found support from several countries as it addresses their regional needs from a 5G standpoint.

The standard will now be circulated by ITU to member states for adoption and approval. Specifications are expected to be published by ITU in early February 2021.

TSDSI thanks its members, the Department of Telecommunications, Govt. of India and its partners for their support over the last four years in helping get this standard reach the final stage in ITU.

In a keynote address presented to the 2020 IEEE 5G World Forum plenary session, Radha Krishna Ganti from TSDSI discusses rural connectivity challenges in India, Low Mobility Large Cell requirements, benefits of implementing LMLC for rural coverage, and internet ecosystem updates. His talk is embedded as follows:

TSDSI explains their 5Gi technology as follows:

TSDSI standard fulfils the requirements of affordable connectivity in rural, remote and sparsely populated areas. Enhanced cell coverage enabled by this standard, will be of great value in countries and regions that rely heavily on mobile technologies for connectivity but cannot afford dense deployment of base stations due to lack of deep fibre penetration,  poor economics and challenges of geographical terrain. The International Telecommunication Union (ITU), a UN body that is setting requirements for IMT 2020 (aka 5G), had earlier adopted the Low-Mobility-Large-Cell (LMLC) use case proposed by TSDSI as a mandatory 5G requirement in 2017. This test case addresses the problem of rural coverage by mandating large cell sizes in a rural terrain and scattered areas in developing as well as developed countries. Several countries supported this as they saw a similar need in their jurisdictions as well. TSDSI successfully introduced an indigenously developed 5G candidate Radio Interface Technology, compatible with 3GPP Technology, at the International Telecommunications Union (ITU) in 2019 for IMT 2020 ratification. The RIT incorporates India-specific technology enhancements that can enable larger coverage for meeting the LMLC requirements. It exploits a new transmit waveform that increases cell range developed by research institutions in India (IIT Hyderabad, CEWiT and IIT Madras) and supported by several Indian companies. It enables low-cost rural coverage and has additional features which enable higher spectrum efficiency and improved latency.

While technically this sounds interesting and as discussed in the talk, would make sense due to a large market like India, there are other solutions that are already possible that probably may make this redundant.

As someone who worked with the rural communities to bring coverage in hard to reach areas, small cells and In-band backhaul was one such solution to improve coverage in not-spot areas. Examples of that here and here. Relays are other option that don't cost much but can bring coverage quickly, at a much lower price.

Typically, in practice, the cells easily reach 10km radius. In theory this distance can be as much as 100km. Last year, Australian operator Telstra and vendor Ericsson announced that they have successfully managed to increase the range of an LTE cell from 100 km to 200 km. So, we can already have large cells with existing 4G/5G cells. 

Facebook connectivity is working on SuperCell concept, a Wide-Area Coverage Solution for Increasing Mobile Connectivity in Rural Communities. Details here. NGMN published a paper on Extreme Long Range Communications for Deep Rural Coverage. Details here.

Finally, we also have 5G Integrated Access and Backhaul (IAB) that can be used for backhauling and solving backhaul issues. They will end up playing a role in rural areas as well as dense urban areas eventually.

Let me know what you think.

Related Posts:

• The 3G4G Blog: IMT-2020 (5G) Requirements
• 3G4G: 5G Terminology
• Free 6G Training: TSDSI's Vision for India to Leapfrog to 5.5G / 6G
• The 3G4G Blog: Reliance Jio and 5G Network Architecture Option 6
• The 3G4G Blog - Opinion: What is "Real 5G" or "True 5G" 

3GPP RAN Plenary Update and Evolution towards 5G-Advanced

(click on image to enlarge)

ETSI recently held a webinar to provide a 3GPP RAN Plenary update by Wanshi Chen, Senior director of technology at Qualcomm Technologies, who was appointed as the RAN Chair not too long back. The webinar video is embedded below. The following is from the 3GPP summary of the webinar:

Wanshi Chen acknowledged that Release 17 - the third release of 5G specifications - has been under pressure due to COVID-19 restrictions, but despite making the move to e-meetings, he reported that the group’s experts have managed to ensure positive progress towards the freeze of the RAN1 physical layer specifications on schedule, by December 2021.

This is to be followed by the Stage 3 freeze (RAN2, RAN3 and RAN4) by March 2022 and the ASN.1 freeze and the performance specifications completion by September 2022 – On the timeline agreed back in December 2019.

This staggered timeline has been made achievable with careful planning and management, demonstrated to the webinar viewers via a complex planning schedule, with a slide showing the array of Plenary & WG meetings and Release landmarks - Interspersed with a series of planned periods of inactivity, to allow delegates some relief from 3GPP discussions.

Wanshi Chen noted that the efficiency of e-meetings has not been comparable with physical meetings, in terms of getting everything done. To compensate for that, the companies involved have planned two RAN1 meetings in 4Q21 and two meetings for each of the RAN working groups in the 1Q22. He observed: “We will monitor Release 17 RAN progress closely and take the necessary actions to make sure we can get the release completed on time.”

Release 18 Planning

Looking forward to Release 18 and the start of work on 5G-Advanced, Chen outlined the schedule for an online RAN workshop from June 28 – July 2, to define what will be in the release. The workshop will set the scene for email discussions about the endorsed topics for consideration. The work will culminate with Release 18 Package Approval, at the December 2021 Plenary (RAN#94).

The high-level objective of the workshop will be to gather company proposals in three areas:

• eMBB driven work;
• Non-eMBB driven functionality;
• Cross-functionality for both.

Wanshi Chen concluded that during the Release 18 planning process, some capacity must be kept in hand; keeping around 10% of WG effort in reserve, for workload management and to meet late, emerging critical needs from commercial deployments.

The following Q&A topics were covered, along with the time stamps:

• The effect of the pandemic and eMeeting management schedules and tools (19.25).
• Balance between commercial needs and societal needs, emergency services, energy efficiency, sustainability (21.20).
• The importance of the verticals in the second phase of 5G – With 5G-Advanced. How will this Rel-18 workshop compare in scale with the 5G Phoenix workshop in 2015? (23.00)
• The job of the Chair is to be impartial…but Wanshi guesses that Antennas, MiMo enh., Sidelink, Positioning, xR, AI machine learning…. could come up in Rel-18! (26.15)
• Will 5G-Advanced have a strong identity & support? (30.05)
• The potential for hybrid meetings – No clear answers yet, but we have learnt a lot in the past year.(34.35)
• The link between gathering new requirements and use cases in SA1 and RAN work and RAN1’s role in focusing these needs for radio work. (40.10)
• Software-ization of the RAN. Do you see more open RAN work coming to 3GPP? (44.18)
• Machine type communications and IoT – Where is IoT going in 3GPP RAN? (47.01)
• Some thoughts on Spectrum usage from a 3GPP point of view, is that difficult to fathom for non-experts? (52.00)
• Can Standards writing become more agile, less linear? (54.00)

If you want to get hold of the slides, you will have to register on BrightTALK here and then download from attachments.

Signals Research Group has a short summary of 3GPP RAN #91 electronic plenary held in late March. It is available to download after registration from here.

xoxoxoxoxoxo Updated later, 07 June 2021 oxoxoxoxoxoxox 

5G-Advanced logo is now available as shown above. Guidelines on how to use the logo is available on 3GPP here.

Related Posts:

• The 3G4G Blog: Initiative to Remove Non-inclusive terms from 3GPP Specifications
• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• The 3G4G Blog: Spectrum for 5G NR beyond 52.6 GHz 

Initiative to Remove Non-inclusive terms from 3GPP Specifications

3GPP just published 2nd issue of 3GPP highlights here. (Issue 1 is here). The contents of the newsletter includes:

• TECHNICAL HIGHLIGHTS
• A Release 17 update
• Artificial Intelligence and Machine Learning in NG-RAN: New Study in RAN3
• 3GPP Multimedia Codecs, Systems and Services
• Is healthcare the next big thing for 5G?
• From IMT-2020 to beyond
• PARTNER FOCUS
• PCSE - Enabling Operational Mobility for European Public Safety Responders
• WBA - One Global Network with OpenRoaming(TM)
• ESOA - Fulfilling the promise of Anytime, from anywhere and on any device & networks (ATAWAD)
• TCCA - Trusted standards mean trusted communications
• GSA - mmWave bands for 5G
• NGMN - Global alignment for the benefit of end users as new focus areas emerge
• 5GAA - Study of Spectrum Needs for Safety Related Intelligent Transportation Systems – Day 1 and Advanced Use Cases
• A LOOK INSIDE
• Ensuring device compliance to standards
• Release 17 timeline agreed
• Initiative to remove non-inclusive terms in specifications
• New Members listing
• The 3GPP group structure
• CALENDAR
• Calendar of 3GPP meetings
• NEWS IN BRIEF

In this post we are looking at the Initiative to remove non-inclusive terms in specifications. Quoting from the newsletter:

3GPP groups have started the process of replacing terminology in our specifications that is non-inclusive. The entire leadership proposed jointly a change request (CR) to the specification drafting rules (TR21.801), following an initiative led by several individual members.

In their joint proposal to the TSG SA#90-e meeting, the leaders wrote: “While there are potentially numerous language issues that could be considered offensive, there are two that are most acknowledged and focused on in the industry and applicable to the 3GPP Specifications. These terminologies are “Master / Slave” and “Whitelist / Blacklist” that are often used in 3GPP and other telecommunications technical documents.” 

What next? - Change requests will now follow on any Release 17 reports and specifications that need their content brought in line with this policy.

Further reading:

• SP-201042: Tdoc from the leadership - Inclusive Language in 3GPP Specifications
• SP-201142: Change Request to Specification drafting rules.
• SP-201143: Liaison Statement on: Use of Inclusive Language in 3GPP.
• TR21.801: 3GPP Specification drafting rules

The main page for 3GPP highlights is here.

Related Posts:

• The 3G4G Blog: NWDAF in 3GPP Release-16 and Release-17
• The 3G4G Blog: Positioning Techniques for 5G NR in 3GPP Release-16
• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• The 3G4G Blog: 5G Evolution with Matthew Baker, Nokia
• The 3G4G Blog: Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)
• The 3G4G Blog: 5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17
• The 3G4G Blog: Business Role Models for Network Slicing and iRAT Mobility for Cellular Internet of Things (CIoT) in Release 16
• The 3G4G Blog: 5G Enhanced URLLC (eURLLC) 

NWDAF in 3GPP Release-16 and Release-17

We looked at Network Data Analytics Function, NWDAF, in detail here. While the 3GPP Release-16 work just starting back then, we have now completed Rel-16 and looking at Release 17. 

The 5G Core (5GC) supports the application of analytics to provide Intelligent Automation of the network, In Rel-16 the set of use cases that are proposed for the NWDAF has been widely expanded. 

In an earlier post, we looked at the ATIS webinar discussing Release-16 & forthcoming features in Rel-17. Puneet Jain, Director of Technical Standards at Intel and 3GPP SA2 Chairman talked briefly about NWDAF. The following is from his talk:

Release-16 provides support for Network Automation and Data Analytics.  Network Data Analytics Function (NWDAF) was defined to provide analytics to 5G Core Network Functions (NFs) and to O&M. It consists of several services that were defined in 3GPP Rel-16 and work is now going in Release 17 to further extend them. 

In release 16 Slice load level related network data analytics and observed service experience related network data analytics were defined. NF load analytics as well Network Performance analytics was also specified. NWDAF provides either statistics or prediction on the load communication and mobility performance in the area of interest. 

Other thing was about the UE related analytics which includes UE mobility analytics, UE communication analytics, Expected UE behavior parameter, Related network data analytics and abnormal behavior related network data analytics.

The NWDAF can also provide user data congestion related analytics. This can be done by one time reporting or continuous reporting in the form of statistics or prediction or both to any other network function. 

QoS sustainability analytics, this is where the consumer of QoS sustainability analytics may request NWDAF analytics information regarding the QoS change statistic for a specific period in the past in a certain area or the likelihood of QoS change for a specific period in future, in certain areas. 

In Release 17, studies are ongoing for network automation phase 2. This includes some leftover from Release 16 such as UE driven analytics, how to ensure that slice SLA is guaranteed and then also new functionality is being discussed that includes things like support for multiple NWDAF instance in one PLMN including hierarchies, how to enable real-time or near-real-time NWDAF communications, how to enable NWDAF assisted user pane optimization and last which is very interesting is about interaction between NWDAF and AI model and training service owned by the operator.

This article on TM Forum talks about NWDAF deployment challenges and recommendations:

To deploy NWDAF, CSPs may encounter these challenges:

• Some network function vendors may not be standards compliant or have interfaces to provide data or receive analytics services.
• Integrating NWDAF with existing analytics applications until a 4G network is deployed is crucial as aggregated network data is needed to make decisions for centralized analytics use cases.
• Many CSPs have different analytics nodes deployed for various use cases like revenue assurance, subscriber/marketing analytics and subscriber experience/network management. Making these all integrated into one analytics node also serving NWDAF use cases is key to deriving better insights and value out of network data.
• Ensuring the analytics function deployed is integrated to derive value (e.g., with orchestrator for network automation, BI tools/any UI/email/notification apps for reporting).

Here are some ways you can overcome these challenges and deploy efficient next-generation analytics with NWDAF:

• Mandate a distributed architecture for analytics too, this reduces network bandwidth overhead due to analytics and helps real-time use cases by design.
• Ensure RFPs and your chosen vendors for network functions have, or plan to have, NWDAF support for collecting and receiving analytics services.
• Look for carrier-grade analytics solutions with five nines SLAs.
• Choose modular analytics systems that can accommodate multiple use cases including NWDAF as apps and support quick development.
• Resource-efficient solutions are critical for on-premise or cloud as they can decrease expenses considerably.
• Storage comes with a cost, store more processed smart data and not more raw big data unless mandated by law.
• In designing an analytics use case, get opinions from both telco and analytics experts, or ideally an expert in both, as they are viewed from different worlds and are evolving a lot.

This is such an important topic that you will hear more about it on this blog and elsewhere.

Related Posts:

• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Automating the 5G Core using Machine Learning and Data Analytics
• The 3G4G Blog: Artificial Intelligence - Beyond SON for Autonomous Networks
• 3G4G: 5G Service Based Architecture (SBA) 

ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'

3GPP Organizational Partner, ATIS (Alliance for Telecommunications Industry Solutions), recently delivered a webinar (video & slides below) titled "5G Standards Developments in 3GPP Release 16 and Beyond". 

3GPP News details:

An expert panel brings you up-to-speed on the current state of 5G standardization. The webinar delivers a broad overview of 3GPP's work and introduces some of the key technology elements. It is suitable for people in technical roles and technical executives who want to understand the current state of 5G standardization.

In Release 16, 3GPP delivered important updates to 5G specifications to broaden their range of commercial applications and improve the efficiency of networks. 3GPP is now further enhancing 5G in Release 17 and starting to plan Release 18. This webinar provides an up-to-date view of the completed 3GPP Release 16 work with a particular focus on how the work is expanding capabilities of 5G and enhancing the technical performance of the mobile system. It also looks ahead to future 3GPP deliverables and their use cases.

The webinar features, Iain Sharp, Principal Technologist at ATIS (Moderator), Greg Schumacher, Global Standards at T-Mobile USA and 3GPP SA and SA1 Vice Chairman, Puneet Jain, Director of Technical Standards at Intel and 3GPP SA2 Chairman and Wanshi Chen, Senior Director, Technology at Qualcomm and 3GPP RAN1 Chairman

Many interesting topics have been covered including the updates on mMTC and URLLC. 

There is also details about new features coming in 3GPP Release-17 and an early look at what 3GPP Release-18 might include, as can be seen in the picture above.

Slides are available here and video is embedded below.

Related Posts:

• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• The 3G4G Blog: 2-step RACH Enhancement for 5G New Radio (NR)
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System
• The 3G4G Blog: 3GPP MDT - How it works and what is new in Rel. 16
• The 3G4G Blog: Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)
• The 3G4G Blog: Would 5G NSA undergo Sunset? When?
• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• The 3G4G Blog: 5G and Fixed-Mobile Convergence (FMC) 

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:

• 3G4G: Open RAN, OpenRAN and O-RAN

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:

• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G Health & Safety
• 3G4G: 5G (IMT-2020) Wireless
• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: An Introduction to Vehicle to Everything (V2X) and Cellular V2X (C-V2X)
• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn
• The 3G4G Blog: Carrier Aggregation (CA) and Dual Connectivity (DC)
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Embedded SIM (eSIM) and Integrated SIM (iSIM)

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. 

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

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.

Spectrum for 5G NR beyond 52.6 GHz

3GPP TR 38.807: Study on requirements for NR beyond 52.6 GHz has recently been revised with all the new information post WRC-19. There is a section that details potential use cases for this new spectrum.

New spectrum above 52.6 GHz – Potential use cases and deployment scenarios from a presentation by Kari Pajukoski, Oskari Tervo and Jari Hulkkonen, Nokia at the #6GSummit https://t.co/BqYPK7xpcz #Free5GTraining pic.twitter.com/6gqz0jCL3A

— 5G Training (@5Gtraining) January 16, 2020

Quoting from the specs:

The relatively underutilized millimeter-wave (mmWave) spectrum offers excellent opportunities to provide high speed data rate, low latency, and high capacity due to the enormous amount of available contiguous bandwidth. However, operation on bands in frequencies above 52.6GHz will be limited by the performance of devices, for example, poor power amplifier (PA) efficiency and larger phase noise impairment, the increased front-end insertion loss together with the low noise amplifier (LNA) and analog-to-digital converter (ADC) noise. In addition, bands in frequencies above 52.6GHz have high propagation and penetration losses challenge. Even so, various use cases are envisioned for NR operating in frequencies between 52.6GHz and 114.25GHz. Some of the use cases are illustrated in Figure 5.1-1 and following section provide detailed description of the uses cases. It should be noted that there is not a 1-to-1 mapping of use cases and wireless interfaces, e.g. Uu, slidelink, etc. Various wireless interfaces could be applicable to various uses cases described.

• High data rate eMBB
• Mobile data offloading
• Short-range high-data rate D2D communications
• Vertical industry factory application
• Broadband distribution network
• Integrated access backhaul (IAB)
• Factory automation/Industrial IoT (IIoT)
• Augmented reality/virtual reality headsets and other high-end wearables
• Intelligent Transport Systems (ITS) and V2X
• Data Center Inter-rack Connectivity
• Smart grid automation
• Radar/Positioning
• Private Networks
• Critical medical communication

There is quite detailed information for each use case in the document that I am not detailing here.

Getting ready for our 5G training next week - https://t.co/6YXW3YlDvD - this picture summarises the 5G mmWave frequency proposals pre #WRC15, approved for study at WRC-15 and available for IMT post #WRC19#3G4G5G #CWTechTrain #5G #Spectrum #5GTraining @cambwireless @UK_5G pic.twitter.com/KoWEpD89Pz

— 3G4G (@3g4gUK) March 3, 2020

It also details information on the allocation within the frequency range 52.6 GHz to 116 GHz in ITU Radio Regulation (see table below). The column with comments contains (a subset of) information on protection requirements for incumbent services. For the full details please refer to the Radio Regulations.

Quoting from the specs:

Within the range 52.6 to 116 GHz, the frequency bands 66-76 GHz (including 66-71 and 71-76 GHz) and 81-86 GHz are being studied under WRC-19 Agenda Item 1.13 for potential IMT identification. Results of sharing and compatibility studies, potential technical and regulatory conditions are included in Draft CPM Report, and the final decisions are to be made in WRC-19 with respect to IMT identification or no IMT identification, along with the corresponding technical and regulatory conditions.

For 66-71 GHz, Studies were carried out for the ISS, MSS (Earth-to-space) indicating that sharing is feasible, with a need for separation distance in the order of few kilometers for the case of MSS (space-to-Earth). The need for studies addressing interference from IMT towards RNS is still under debate. Thus, final conclusions in the regulatory and technical conditions for this band cannot be drawn.

For 71-76 GHz, studies were carried out for the FS, RLS and FSS (space-to-Earth) indicating that sharing with FS and FSS is feasible. However, additional limits of the IMT BS and UE unwanted emissions is needed to protect RLS in the adjacent frequency band 76-81 GHz.

For 81-86 GHz, studies were carried out for the FS, FSS (Earth-to-space), RAS (in band and adjacent band), EESS (passive) and RLS. Studies are not needed for the SRS (passive), as this service is dealing with sensors around other planets and no interference issue is expected. Studies were also not carried out for the MSS. The results of those studies indicate that sharing with FS, FSS and RAS (in band and adjacent band) is feasible. Notice that additional limits of the IMT BS and UE unwanted emissions would be needed to ensure protection of EESS (passive) in the adjacent frequency band 76-81 GHz and RLS in the adjacent frequency band 86-82 GHz.

An interesting paper looking at Waveforms, Numerology, and Phase Noise Challenge for Mobile Communications Beyond 52.6 GHz is available here.


Related Posts:

• The 3G4G Blog: Examples of 5G Use Cases & Applications
• The 3G4G Blog: 5G Private and Non-Public Network (NPN)
• The 3G4G Blog: 5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17
• The 3G4G Blog: What is Industrial IoT (IIoT) and how is it different from IoT?
• The 3G4G Blog: 5G and Industry 4.0
• Connectivity Technology Blog: 5G Indoor Precise Positioning
• The 3G4G Blog: 5G eXtended Reality (5G-XR) in 5G System (5GS)

5G eXtended Reality (5G-XR) in 5G System (5GS)

We have been meaning to make a tutorial on augmented reality (AR), virtual reality (VR), mixed reality (MR) and extended reality (XR) for a while but we have only managed to do it. Embedded below is video and slides for the tutorial and also a playlist of different use cases on XR from around the world.

If you are not familiar with the 5G Service Based Architecture (SBA) and 5G Core (5GC), best to check this earlier tutorial before going further. A lot of comments are generally around Wi-Fi instead of 5G being used for indoors and we completely agree. 3GPP 5G architecture is designed to cater for any access in addition to 5G access. We have explained it here and here. This guest post also nicely explains Network Convergence of Mobile, Broadband and Wi-Fi.

Intermediate: 5G and Extended Reality (XR) from 3G4G

XR use cases playlist



A lot of info on this topic is from Qualcomm, GSMA, 3GPP and 5G Americas whitepaper, all of them in the links in the slides.


Related Posts:

• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• The 3G4G Blog: 5G and Fixed-Mobile Convergence (FMC)
• The 3G4G Blog: Introduction to 5G ATSSS - Access Traffic Steering, Switching and Splitting
• Guest Post by Ben Toner - Exploring Network Convergence of Mobile, Broadband and Wi-Fi
• Connectivity Technology Blog: 5G Indoor Precise Positioning
• Operator Watch Blog: NTT Docomo presentation on 5G Launch Plans and Use Cases Solutions Partnership
• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G (IMT-2020) Wireless

How LTE RRC (4G) and NR RRC (5G) Protocols are used in Parallel in EN-DC (5G NSA)

Last week I had a fruitful discussion with a fellow blogger on the web, Martin Sauter (@mobilesociety) regarding a post in which he compared features of LTE RRC (3GPP 36.331) and NR RRC (3GPP 38.331).

It was Martin's impression that the NR RRC protocol is primarily designed to be used in the 5G standalone mode. However, as I wrote in a comment to his post the NR RRC protocol is already used in EN-DC radio connections.

The reason is that the UE must be informed about Hundreds of lower layer 5G parameters (physical, MAC, RLC) that are needed for the payload transmission over 5G frequencies. Indeed, when it comes to user plane data transmission the gNB works almost independently and the UE must handle LTE and NR radio links in parallel.So it has two different radio units (even if combined into a single radio chip set). This double-functionality is also one important reason why 5G smartphones are quite expensive. It is a lot of software and know-how that sits inside these chips.

How much surplus code is really necessary to enable 5G technology becomes visible when looking at trace data using a state-of-the-art protocol test and monitoring tool.

When reading the 3GPP 36.331 (LTE RRC) standard document one might have the impression that just a few 5G parameters have been incorporated into this protocol to support EN-DC connections.

However, when looking into the details of e.g. the nr-SecondaryCellGroupConfig-r15 it turns out that some this single information element is indeed a huge block of NR information (total size: 1111 Byte)

It is an entire 5G RRC message (rRCReconfiguration) that is piggybacked by the LTE rrcConnectionReconfiguration message, because in 5G non-standalone mode this is the only way to transmit 5G signaling information to the UE. And as highlighted in the upper part of the screenshot there are a couple of NR RRC messages transported in so-called NR-RRCContainers* during the EN-DC Establishment Procedure.

And what about 5G standalone mode? For this radio access technology the 3GPP 38.331 Rel. 15 protocol is suitable as well. Hence, some parameters mentioned in the standard paper will never be seen in EN-DC. A perfect example is S-NSSAI (Single Network Slice Selection Assistance Information), because network slicing requires the connection with a 5G core network as a prerequisite. 

(click on image for larger version)

* This is not an 3GPP term, but coined by the developers of the decoding engine.

How MOCN RAN-Sharing Works

Shared RAN deployment scenarios are an excellent opportunity for mobile network operators to lower their investments on both, network hardware and operational costs by sharing resources.

The MORAN approach where each operator continues to have its dedicated spectrum (= radio network cells) is easy to understand.

However, the Multi-Operator Core Network (MOCN) is a bit more complex, especially if one of the involved operators asks for service assurance KPIs that apply to its - and only its - subscribers. In this case it is a prerequisite to find out which "call" belongs to which core network operator to enable further KPI correlation and aggregation.

The figure below illustrates how this works:

(click on picture for larger version)

In the System Information Block (SIB) 1 of the cell a list of PLMN-IDs is broadcasted followed by a single Tracking Area Code (which can be combined each of the PLMN-IDs to get multiple TAIs) and a single Cell Identity.

Encoding is specified in 3GPP 36.331 (RRC) as follows:

SystemInformationBlockType1 ::=     SEQUENCE {

    cellAccessRelatedInfo              SEQUENCE {

       plmn-IdentityList                 PLMN-IdentityList,

       trackingAreaCode                  TrackingAreaCode,

       cellIdentity                      CellIdentity,

The spec further defines that the ECGI is the CellIdentiy combined with the first (!!!) PLMN-ID from the PLMN-ID List:

CellGlobalIdEUTRA field descriptions
cellIdentity Identity of the cell within the context of the PLMN.
plmn-Identity Identifies the PLMN of the cell as given by the first PLMN entry in the plmn-IdentityList in SystemInformationBlockType1.

So there is one and only 1 ECGI per radio cell in the network, but multiple PLMN-IDs and hence, multiple TAI, one fore each core network operator, are broadcasted.

During RRC establishement a particular UE signals on behalf on the selected PLMN-ID information element in the RRC Connection Setup Complete message to which core network operator shall be used.

This information is "translated" by the eNB into ECGI and TAI with different PLMN-IDs. While the ECGI displays the PLMN-ID of the operator that owns the RAN equipment the TAI shows the selected PLMN-ID of the UE's core network operator. 

Related Posts:

• The 3G4G Blog: Quick tutorial on Mobile Network Sharing Options
• The 3G4G Blog: Mobile Network Infrastructure Sharing in Japan over Electric Power Infrastructure
• The 3G4G Blog: A practical use of MOCN in ESN

5G Evolution with Matthew Baker, Nokia

I wrote a summary of CW (Cambridge Wireless) TEC conference here a couple of months back. The last session was on "Getting ready for Beyond-5G Era". Matthew Baker, Head of Radio Physical Layer & Co-existence Standardization, Nokia Bell Labs was one of the speakers. His talk provided a summary of 3GPP Rel-15 and then gave a nice and short summary of all the interesting things coming in Rel-16 and being planned for Rel-17. The slides from his presentation is embedded below:

5G Evolution: Progressive Enhancement & N ew Features for New Markets from 3G4G

Nokia also created a short video where Matthew talks about these new features. It's embedded below:



Related Posts:

• Summary of #CWTEC 2019 Conference: 5G, Satellites & Magic MIMO
• 5G and Fixed-Mobile Convergence (FMC)
• R&S Webinar on LTE-A Pro and evolution to 5G
• Introduction to NR-Light a.k.a. NR-Lite
• An Introduction to Non-Terrestrial Networks (NTN)

When does your 5G NSA Device Show 5G Icon?

After I wrote about the 5G Icon Display back in February, I received lots of other useful and related materials, mostly from 3GPP standards delegates. Based on this updated information, I created a presentation and video called 'The 5G Icon Story'. Only recently did I realize that I didn't add it to the blog. So here it is.

And for people who are impatient and directly want to jump to the main point, it's UpperLayerIndication in SIB 2 as can be seen above.

The slides and video is embedded below.

Intermediate: The 5G Icon Story from 3G4G

Related Posts:

• Updated 5G Terminology Presentation (Feb 2019)
• Prof. Andy Sutton: 5G Radio Access Network Architecture Evolution - Jan 2019
• An Introduction to Non-Terrestrial Networks (NTN)
• 5G and Fixed-Mobile Convergence (FMC)

New 3GPP Release-17 Study Item on NR-Lite (a.k.a. NR-Light)

3GPP TSG RAN#84 was held from June 3 – 6, 2019 at Newport Beach, California. Along with a lot of other interesting topics for discussion, one of the new ones for Release-17 was called NR-Lite (not 5G-lite). Here are some of the things that was being discussed for the Study item.

In RP-190831, Nokia proposed:

• NR-Lite should address new use cases with IoT-type of requirements that cannot be met by eMTC and NB-IoT:
• Higher data rate & reliability and lower latency than eMTC & NB-IoT
• Lower cost/complexity and longer battery life than NR eMBB
• Wider coverage than URLLC
• Requirements and use cases –
• Data rates up to 100 Mbps to support e.g. live video feed, visual production control, process automation
• Latency of around [10-30] ms to support e.g. remote drone operation, cooperative farm machinery, time-critical sensing and feedback, remote vehicle operation
• Module cost comparable to LTE
• Coverage enhancement of [10-15]dB compared to URLLC
• Battery life [2-4X] longer than eMBB
• Enable single network to serve all uses in industrial environment
• URLLC, MBB & positioning

The spider chart on the right shows the requirements for different categories of devices like NB-IoT, eMTC (LTE-M), NR-LITE, URLLC and eMBB.

The understanding in the industry is that over the next 5 years, a lot of 4G spectrum, in addition to 2G/3G spectrum, would have been re-farmed for 5G. By introducing NR-Lite, there would be no requirement to maintain multiple RATs. Also, NR-Lite can take advantage of 5G system architecture and features such as slicing, flow-based QoS, etc.

Qualcomm's views in RP-190844 were very similar to those of Nokia's. In their presentation, the existing 5G devices are billed as 'Premium 5G UEs' while NR-Lite devices are described as 'Low tier 5G UEs'. This category is sub-divided into Industrial sensors/video monitoring, Low-end wearables and Relaxed IoT.

The presentation provides more details on PDCCH Design, Co-existence of premium and Low Tier UEs, Peak Power and Battery Life Optimizations, Contention-Based UL for Small Data Transmission, Relaying for Wearable and Mesh for Relaxed IoT

Ericsson's presentation described NR-Lite for Industrial Sensors and Wearables in RP-191047. RP-191048 was submitted as New SID (Study Item Description) on NR-Lite for Industrial Sensors and Wearables. The SID provides the following details:

The usage scenarios that have been identified for 5G are enhanced mobile broadband (eMBB), massive machine-type communication (mMTC), and time critical machine-type communication (cMTC). In particular, mMTC and cMTC are associated with novel IoT use cases that are targeted in vertical industries. 

In the 3GPP study on “self-evaluation towards IMT-2020 submission” it was confirmed that NB IoT and LTE M fulfill the IMT-2020 requirements for mMTC and can be certified as 5G technologies. For cMTC support, URLLC was introduced in Release 15 for both LTE and NR, and NR URLLC is further enhanced in Release 16 within the enhanced URLLC (eURLLC) and Industrial IoT work items.

One important objective of 5G is to enable connected industries. 5G connectivity can serve as catalyst for next wave of industrial transformation and digitalization, which improve flexibility, enhance productivity and efficiency, and improve operational safety. The transformed, digitalized, and connected industry is often referred to as Industry 4.0. Industrial sensors and actuators are prevalently used in many industries, already today. Vast varieties of sensors and actuators are also used in automotive, transport, power grid, logistics, and manufacturing industries. They are deployed for analytics, diagnostics, monitoring, asset tracking, process control, regulatory control, supervisory control, safety control, etc. It is desirable to connect these sensors and actuators to 5G networks. 

The massive industrial wireless sensor network (IWSN) use cases and requirements described in TR 22.804, TS 22.104 and TS 22.261 do include not only cMTC services with very high requirements, but also relatively low-end services with the requirement of small device form factors, and/or being completely wireless with a battery life of several years. 

The most low-end services could already be met by NB-IoT and LTE-M but there are, excluding URLLC, more high-end services that would be challenging. In summary, many industrial sensor requirements fall in-between the well-defined performance objectives which have driven the design of eMBB, URLLC, and mMTC. Thus, many of the industrial sensors have connectivity requirements that are not yet best served by the existing 3GPP NR technology components. Some of the aforementioned requirements of IWSN use cases are also applicable to other wide-area use cases, such as wearables. For example, smart watches or heath-monitoring wearables require small device form factors and wireless operation with weeks, months, or years of battery life, while not requiring the most demanding latency or data rates. 

IWSN and wearable use cases therefore can motivate the introduction of an NR-based solution. Moreover, there are other reasons why it is motivated to introduce a native NR solution for this use case: 

• It is desired to have a unified NR based solution.
• An NR solution could provide better coexistence with NR URLLC, e.g., allowing TDD configurations with better URLLC performance than LTE.
• An NR solution could provide more efficient coexistence with NR URLLC since the same numerology (e.g., SCS) can be adopted for the mMTC part and the URLLC part.
• An NR solution addresses all IMT-2020 5G frequency bands, including higher bands and TDD bands (in FR1 and FR2).

The intention with this study item is to study a UE feature and parameter list with lower end capabilities, relative to Release 15 eMBB or URLLC NR, and identify the requirements which shall be fulfilled. E.g., requirements on UE battery life, latency, reliability, connection density, data rate, UE complexity and form factor, etc.  If not available, new potential NR features for meeting these requirements should further be studied.

There were other description of the SID from Samsung, ZTE, etc. but I am not detailing them here. The main idea is to provide an insight for people who may be curious about this feature.


Related Posts:

• 3G4G Training: Introduction to NR-Light a.k.a. NR-Lite
• The 3G4G Blog - 3GPP 5G Standardization Update post RAN#84 (July 2019)
• The 3G4G Blog - Ultra Reliability: 5x9s (99.999%) in 3GPP Release-15 vs 6x9s (99.9999%) in 3GPP Release-16
• The 3G4G Blog - 5G SpeedTests and Theoretical Max Speeds Calculations
• The 3G4G Blog - Updated 5G Terminology Presentation (Feb 2019)

An Introduction to Non-Terrestrial Networks (NTN)

I made a short introductory tutorial explaining what is meant by Non-Terrestrial Networks. There is is lot of work on this that is planned for Release-17. Slides and video below.

Beginners: Non Terrestrial Networks (NTN) from 3G4G

Related Posts:

• Connectivity Technology Blog: TIP has launched 'Non-Terrestrial Connectivity Solutions' Group
• The 3G4G Blog: Connectivity on Planes
• The 3G4G Blog: Satellites & Non-terrestrial networks (NTN) in 5G
• 3G4G Small Cells Blog: Flying Small Cells are here...