Showing posts with label 3GPP. Show all posts
Showing posts with label 3GPP. Show all posts

Monday 21 June 2021

3GPP Standards on Edge Computing

A sub-set of 3GPP Market Representation Partners hosted a 2-part webinar series in April 2021 looking at edge computing for industry verticals and on-going standardisation work in 3GPP. The first part write-up is available here. The webinar was attended by a mix of organisations from both verticals and the telecommunication industry, helping to share a common understanding on edge computing. 

The webinar brought together top experts at the 3GPP plenary level, SA2 (Architecture) and SA6 (application enablement and critical communication applications) for a deep-dive into how 5G and related standards can help harmonise and enable technologies like edge computing and artificial intelligence to work together much more efficiently. 

The webinar was co-chaired by Georg Mayer, 3GPP SA Chairman and Stephanie Parker, Trust-IT and Vice-chair of the 5G-IA Pre-Standardisation WG with the John Favaro, Trust-IT and member of the 5G PPP Automotive Working Group. 

The webinar was attended by a mix of organisations from both verticals and the telecommunication industry, helping to share a common understanding on edge computing.

This video embedded below is the recording of the webinar on edge computing held on Thursday 22 April 2021 part 2 - 3GPP Standards on Edge Computing as an educational deep dive to help industry verticals gain a better understanding of an evolving landscape. It gives key insights into 3GPP standardisation work on edge computing with an overview of the main activities taking place within SA (System Aspects and Architecture). Presentations and panel discussions zoom in on the network layer with SA2 Architecture and on the application layer for vertical enablement with SA6 Application Enablement and Critical Communication Applications. The panel discussion with SA TSG, SA2 and SA6 chairmen sheds light on the role of artificial intelligence from both the network and application perspectives, underscoring the vital importance of industry verticals in the standardisation process to meet their specific requirements in 3GPP as a truly global initiative.

PDF of presentations as follows:

Global5G has a summary with main takeaways and poll findings here. The following is from there:

Main Takeaways

  1. 5G will help technologies like edge computing and artificial intelligence to harmonise and enable them to work together much more efficiently.
  2. 3GPP Release 17 is foundational for edge computing but more will come in future releases given its importance in mobile communications and as we gradually move beyond 5G. The webinar was therefore a timely deep-dive into today's landscape. 
  3. Artificial Intelligence and edge computing can both serve as building blocks but in different ways: 
    • Network layer perspectives: AI can further optimise edge computing applications.
    • Application layer persepctives: Edge computing can be a building block for AI, e.g. offloading limited capabilities from the device to the network.
  4. Global initiatives like 3GPP can help reduce regional fragmentation, drive convergence and enable network-compliant rollouts that benefit the ecosystem around the world.
  5. As a global initiative, 3GPP is well placed to build on its strong relationships and collaborations with ETSI MEC and GSMA. 
  6. It is absolutely essential that industry verticals get involved in 3GPP working groups, which is where key activities take place and where their requirements should be channelled. It is also important that verticals understand how their seemingly specific requirements could be relevant to other sectors. Being part of 3GPP is a complex but highly rewarding experience. It does not need to be a life-long commitment.

Poll Findings - Participant Viewpoints

Do you participate in standardization on edge computing?

Interestingly most respondents do not take part in any standardisation initiatives. Hence the webinar series was an opportunity to highlight the many activities taking place and encourage participants to get involved. Those that do take part mostly contribute to 3GPP and other forums (29%) like ETSI (SDO) and industry associations like 5GAA and 5G-ACIA as some of the early movers on edge computing. Beyond 3GPP, a smaller number of respondents (11%) contribute to ETSI and other forums such as 5GAA and GSMA and the same amount (11%) are involved in other forums.

How important do you think coordination on edge computing standardisation is?

Coordination on edge computing standardisation needs to be prioritised with 65% of respondents saying it's vital and another 33% saying it's quite important. Only 1 respondent said it's not needed. An important output via the 5G-IA Pre-Standardisation WG and supported by panellists and organisers (5G-IA, 5GAA, 5G-ACIA and PSCE) would be a user-friendly guide on edge computing standardisation to help stakeholders navigate the landscape. 

Do you see a need for new areas of standardisation for edge computing?

Findings from this poll are particularly interesting as we have a close split between those that think more standardisation work is needed (47%) and those that don't know (43%) with just 10% saying it's not needed. Webinar organisers have come up with two possible explanations. On the one hand, we may be looking at a fragmented landscape that would benefit from more unification, also from an architecture perspective. On the other hand, organisations looking at the landscape may simply be overwhelmed by the dverse activities taking place. They may also have new applications sitting on top of the network but are not sure if they need to be standardised. Practical guidance could go a long way in clarifying this uncertainty. 

Again, a quick guide on edge computing standardisation could be a useful output, highlighting also the good cooperation already taking place as an important step in the right direction. 

You can see Part 1 of this webinar here.

Related Posts

Saturday 19 June 2021

Edge Computing - Industry Vertical Viewpoints


A sub-set of 3GPP Market Representation Partners hosted a 2-part webinar series in April 2021 looking at edge computing for industry verticals and on-going standardisation work in 3GPP. The webinar was attended by a mix of organisations from both verticals and the telecommunication industry, helping to share a common understanding on edge computing. 

The first webinar brought together experts from the 5G Automotive Association (5GAA), the 5G Alliance for Connected Industry and Automation (5G-ACIA), Edge Gallery, ETSI Multi-access edge computing (MEC) and the Automotive Edge Computing Consortium (AECC) to highlight opportunities and updates on how diverse market sectors can benefit from offloading data at the edge of the network. Further insights came from interactive discussions and polling with participants. This webinar is part of a 5G user webinar and workshop series designed for industry verticals co-hosted by 5G-IA, 5GAA, 5G-ACIA and PSCE as Market Representation Partners of 3GPP.

This video embedded below is the recording of the webinar on Tuesday 20 April on edge computing - part one, giving an educational deep dive on industry vertical viewpoints. 5GAA (5G Automotive Association) gives an overview of its white paper, use cases and upcoming trials for Cellular-V2X in the automotive sector. Edge Gallery shows how it is supporting the Industrial Internet of Things with its 5G open-source solutions and application development support. ETSI MEC explain its common and extensible application enabling platform for new business opportunities. 5G-ACIA (5G Alliance for Connected Industry and Automation) describes new work on the applicability of 5G industrual edge computing within the associaton. The Automotive Edge Computing Consortium (AECC) brings insights into how it is driving data to the edge.

Bios and PDF presentations as follows:

Global5G has a summary with main takeaways and poll findings here. The following is from there:

Main takeaways

  1. The webinar was an excellent deep-dive into the edge computing landscape highlighting on-going work in automotive, manufacturing and the Industrial Internet of Things, as well as standardisation work in ETSI and open-source approaches. 
  2. It illustrated the value of edge computing with strong signs coming from industry in terms of growing interest and adoption roadmaps. There is an impressive number of initiatives across the globe embracing edge computing, with examples of cooperation globally as seen in 5GAA, 5G-ACIA, AECC and ETSI MEC. 
  3. Industrial automation, digital twins and infrastructure control among the main drivers for growing demand. 
  4. Collaboration on edge computing is essential and will become even more important as applications increasingly move to the edge. Continued discussions are needed to have greater clarity at multiple layers: business and technology, SW and HW. Collaboration can also support efforts to educate consumers and businesses, both key to uptake and achieving network compliant rollout.  
  5. The collaboration underpinning the 3GPP MRP webinar series is an excellent example of how we can intensify joint efforts across the ecosystem working towards convergence and ensuring RoI, e.g. for telecom investments. 

Poll Findings - Participant viewpoints

Where would you position your organisation in terms of implementing edge computing?

Only 16% of respondents already have a commercial strategy in place for edge computing while 26% are starting to develop one. Therefore 42% are expected to have one in short term. 30% are at early learning stage to understand market opportunities and 28% are exploring its potential. 

In which verticals do you expect the first implementations other than automotive?

The automotive sector is an early mover in edge computing, as testified by 5GAA and AECC presentations in the webinar with both having published studies and white papers. 5GAA is planning trials in 2021 in various locations globally so another webinar on this topic in 2022 would be helpful. After automotive, manufacturing is expected to be the next sector to implement edge, as testified by the 5G-ACIA presentation. All three associations are market representation partners of 3GPP, with 5GAA also contributing to standardisation work. In the 5G PPP, 5GCroCo (cross-border automotive use cases) has contributed to standardisation activities of both 5GAA and AECC. Gaming, AR/VR and media is the next sector expected to adopt edge computing. 

What are your top 2 priority requirements for edge computing? 

Low latency is the top requirement for most respondents (33%) followed by interoperability and service continuity (both on 20.5%) with transferring and processing large volumes of data and very high reliability in joint third place (both on 12.8%). It' will be important to see how many of these requirements feature in early deployments as not all of them will be there at first rollout. The poll also shows how requirements combine together, e.g. 2 priority requirements: Low latency + very high reliability; Interoperability + Service continuity; Interoperability + Low latency; 3 requirements: Interoperability + Service continuity + Transferring and processing large volumes of data and 4 requirements: Interoperability + Service continuity + Low latency + Transferring and processing large volumes of data. 

Part 2 of this webinar is available here.

Related Posts

Monday 7 June 2021

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. 

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:

Monday 17 May 2021

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:

Wednesday 17 March 2021

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:

Tuesday 2 February 2021

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:

Sunday 27 September 2020

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.

Friday 17 July 2020

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

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

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

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


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

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

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

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

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

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

Related Posts:

Sunday 12 July 2020

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


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

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




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


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

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

Release 16 - RAN progress from 3GPPlive on Vimeo.


Related Posts:

Tuesday 23 June 2020

Comparison Layer 2 Measurements LTE vs. 5G NR


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

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

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

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

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

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

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

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.



Sunday 12 April 2020

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.


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.


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:

Saturday 4 April 2020

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.





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:

Monday 9 March 2020

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.

Tuesday 21 January 2020

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: