Showing posts with label 5G. Show all posts
Showing posts with label 5G. Show all posts

Wednesday 30 November 2022

Disaster Roaming in 3GPP Release-17

One way all operators in a country/region/geographic area differentiate amongst themselves is by the reach of their network. It's not in their interest to allow national roaming. Occasionally a regulator may force them to allow this, especially in rural or remote areas. Another reason why operators may choose to allow roaming is to reduce their network deployment costs. 

In case of disasters or emergencies, if an operator's infrastructure goes down, the subscribers of that network can still access other networks for emergencies but not for normal services. This can cause issues as some people may not be able to communicate with friends/family/work. 

A recent example of this kind of outage was in Japan, when the KDDI network failed. Some 39 million users were affected and many of them couldn't even do emergency calls. If Disaster Roaming was enabled, this kind of situation wouldn't occur.

South Korea already has a proprietary disaster roaming system in operation since 2020, as can be seen in the video above. This automatic disaster roaming is only available for 4G and 5G.

In 3GPP Release-17, Disaster Roaming has been specified for LTE and 5G NR. In case of LTE, the information is sent in SIB Type 30 while in 5G it is in SIB Type 15.

3GPP TS 23.501 section 5.40 provides summary of all the other information needed for disaster roaming. Quoting from that:

Subject to operator policy and national/regional regulations, 5GS provides Disaster Roaming service (e.g. voice call and data service) for the UEs from PLMN(s) with Disaster Condition. The UE shall attempt Disaster Roaming only if:

  • there is no available PLMN which is allowable (see TS 23.122 [17]);
  • the UE is not in RM-REGISTERED and CM-CONNECTED state over non-3GPP access connected to 5GCN;
  • the UE cannot get service over non-3GPP access through ePDG;
  • the UE supports Disaster Roaming service;
  • the UE has been configured by the HPLMN with an indication of whether Disaster roaming is enabled in the UE set to "disaster roaming is enabled in the UE" as specified in clause 5.40.2; and
  • a PLMN without Disaster Condition is able to accept Disaster Inbound Roamers from the PLMN with Disaster Condition.

In this Release of the specification, the Disaster Condition only applies to NG-RAN nodes, which means the rest of the network functions except one or more NG-RAN nodes of the PLMN with Disaster Condition can be assumed to be operational.

A UE supporting Disaster Roaming is configured with the following information:

  • Optionally, indication of whether disaster roaming is enabled in the UE;
  • Optionally, indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN';
  • Optionally, list of PLMN(s) to be used in Disaster Condition.

The Activation of Disaster Roaming is performed by the HPLMN by setting the indication of whether Disaster roaming is enabled in the UE to "disaster roaming is enabled in the UE" using the UE Parameters Update Procedure as defined in TS 23.502 [3]. The UE shall only perform disaster roaming if the HPLMN has configured the UE with the indication of whether disaster roaming is enabled in the UE and set the indication to "disaster roaming is enabled in the UE". The UE, registered for Disaster Roaming service, shall deregister from the PLMN providing Disaster Roaming service if the received indication of whether disaster roaming is enabled in the UE is set to "disaster roaming is disabled in the UE".

Check the specs out for complete details. 

From my point of view, it makes complete sense to have this enabled for the case when disaster strikes. Earlier this year, local governments in Queensland, Australia were urging the Federal Government to immediately commit to a trial of domestic mobile roaming during emergencies based on the recommendation by the Regional Telecommunications Independent Review Committee. Other countries and regions would be demanding this sooner or later as well. It is in everyone's interest that the operators enable this as soon as possible.

Related Posts:

Posted by Zahid Ghadialy at 07:35 Leave a comment...1 comments so far
Labels: , , , , , , , , , , ,

Tuesday 22 November 2022

Preparing for Metaverse-Ready Networks

Metaverse means different things for different people. If you explain Metaverse with an example, many people understand but they are generally looking at things from a different point of view. A bit like blind men and an elephant. Similarly when we talk about Metaverse-ready networks, it can mean different things to different people, depending on their background.

Back in Oct 2021, Facebook changed its name to Meta with a vision to bring the metaverse to life and help people connect, find communities and grow businesses. This was followed by a blog post by Dan Rabinovitsj, Vice President, Meta Connectivity, highlighting the high-level requirements for these metaverse-ready networks. 

At Fyuz 2022, the Telecom Infra Project (TIP) announced the launch of Metaverse-Ready Networks Project Group primary whose objective is to accelerate the development of solutions and architectures that enhance network readiness to support metaverse experiences. Meta Platforms, Microsoft, Sparkle, T-Mobile and Telefónica are the initial co-chairs of this Project Group.

Cambridge Wireless' CWIC 2022 discussed 'The Hyperconnected Human'. One of the sessions focussed on 'Living in the Metaverse' which I think was just brilliant. The slides are available from the event page and the video is embedded below:

Coming back to metaverse-ready networks, the final day of Fyuz 2022 conference featured 'The Meta Connectivity Summit' produced by Meta. 

The main stage featured a lot of interesting panel sessions looking at metaverse use cases and applications, technology ecosystem, operator perspectives as well as a talk by CIO of Softbank. The sessions are embedded below. The breakout sessions were not shared. 

Metaverse is also being used as a catch-all for use cases and applications in 6G. While many of the requirements of Metaverse will be met by 5G and beyond applications, 6G will bring in even more extreme requirements which would justify the investments in the Metaverse-Ready Networks.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , ,

Thursday 20 October 2022

EPS Fallback Mechanism in 5G Standalone Networks

Ralf Kreher explained EPS Fallback mechanism in his post earlier, which is still quite popular. This post contains couple of videos that also explain this procedure. 

The first is a very short and simple tutorial from Mpirical, embedded below:

The second is a slightly technical presentation explaining how 5G system can redirect the 5G VoNR capable device to the 4G system to continue for IMS based VoLTE voice call.

Related Posts:

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , ,

Tuesday 11 October 2022

The Role of Connectivity and Devices in Healthcare


Over the last few months I have discussed the role of 5G in different industries as part of various projects. Some of these discussions are part of my blog posts while others aren’t.

5G is often promoted as a panacea for all industries including healthcare. This presentation and video looks not only at 5G but other connectivity options that can be used to provide solutions for healthcare. In addition, this presentation looks at different components of the mobile network and explore the role of devices in healthcare.

Presentation and video below

You can download the slides here.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , ,

Thursday 29 September 2022

Four Ways 5G Can Improve the Battery Life of User Equipment (UE)

We have looked at different approaches in this blog and the 3G4G website on reducing the power consumption (see related posts below). In a blog post some months back, Huawei highlighted how 5G can improve the battery life of UE. The blog post mentioned four approaches, we have looked at three of them on various blogs. 

The following is from the blog post:

RRC_INACTIVE State

A UE can access network services only if it establishes a radio resource control (RRC) connection with the base station. In legacy RATs, a UE is either in the RRC_CONNECTED state (it has an RRC connection) or the RRC_IDLE state (it does not have an RRC connection). However, transitioning from the RRC_IDLE state to the RRC_CONNECTED state takes a long time, so it cannot meet the low latency requirement of some 5G services. But a UE cannot just stay in the RRC_CONNECTED state because this will consume much more UE power.

To solve this problem, 5G introduces the RRC_INACTIVE state, where the RRC connection is released but the UE context is retained (called RRC Release with Suspend), so an RRC connection can be quickly resumed when needed. This way, a UE in the RRC_INACTIVE state can access low-latency services whenever needed but consume the same amount of power as it does in the RRC_IDLE state.

DRX + WUS

Discontinuous reception (DRX) enables a UE in the RRC_CONNECTED state to periodically, instead of constantly, monitor the physical downlink control channel (PDCCH) to save power. To meet the requirements of different UE services, both short and long DRX cycles can be configured for a UE. However, when to wake up is determined by the predefined cycle, so the UE might wake up unnecessarily when there is no data scheduled.

Is there a way for a UE to wake up only when it needs to? Wake-up Signal (WUS) proposed in Release 16 is the answer. This signal can be sent before the next On Duration period (during which the UE monitors the PDCCH) so that the UE wakes up only when it receives this signal from the network. Because the length of a WUS is shorter than the On Duration Timer, using WUS to wake up a UE saves more power than using only DRX.

BWP Adaptation

In theory, working on a larger bandwidth consumes more UE power. 5G provides large bandwidths, but it is unnecessary for a UE to always work on large bandwidth. For example, if you play online mobile games on a UE, only 10 MHz of bandwidth is needed for 87% of the data transmission time. As such, Bandwidth Part (BWP) is proposed in 5G to enable UEs to work on narrower bandwidths without sacrificing user experience.

BWP adaptation enables the base station to dynamically switch between BWPs based on the UE’s traffic volume. When the traffic volume is large, a UE can work on a wide BWP, and when the traffic volume is small, the UE can work on a narrow one. BWP switching can be performed based on the downlink control information (DCI) and RRC reconfiguration messages. This ensures that a UE always works on a bandwidth that supports the traffic volume but does not consume too much power.

Maximum MIMO Layers Reduction

According to 3GPP specifications, the number of receive and transmit antennas used by a UE cannot be fewer than the maximum number of MIMO layers in the downlink and uplink, respectively. For example, when a maximum of four downlink MIMO layers are configured for a UE, the UE must enable at least four receive antennas to receive data. Therefore, if the maximum number of MIMO layers can be reduced, the UE does not have to activate as many antennas, reducing power consumption.

This can be achieved in 5G because the number of MIMO layers can be re-configured based on assistance information from UEs. After receiving a request to reduce the number of MIMO layers from a UE, the base station configures fewer MIMO layers for the UE through an RRC reconfiguration message. In this way, the UE can deactivate some antennas to save power.

Power consumption in the networks and the devices is a real challenge. While the battery capacity and charging speeds are increasing, it is also important to find ways to optimise the signalling parameters, etc. One such approach can be seen in the tweet above regarding regarding T-Mobile in The Netherlands, selectively switching off a carrier in the night and switching it back when the cell starts loading or in the morning.

We will see lot more innovations and optimisations to dynamically update the technologies, parameters, optimisations to ensure power savings wherever possible.

Related Posts: 

Posted by Zahid Ghadialy at 11:35 Leave a comment...0 comments so far
Labels: , , , , ,

Monday 19 September 2022

Is there a compelling Business Case for 5G Network Slicing in Public Networks?

Since the industry realised how the 5G Network Architecture will look like, Network Slicing has been touted as the killer business case that will allow the mobile operators to generate revenue from new sources.

Last month ABI Research said in a press release:

According to global technology intelligence firm ABI Research, 5G slicing revenue is expected to grow from US$309 million in 2022 to approximately US$24 billion in 2028, at a Compound Annual Growth Rate (CAGR) of 106%. 

“5G slicing adoption falls into two main categories. One, there is no connectivity available. Two, there is connectivity, but there is not sufficient capacity, coverage, performance, or security. For the former, both private and public organizations are deploying private network slices on a permanent and ad hoc basis,” highlights Don Alusha, 5G Core and Edge Networks Senior Analyst at ABI Research. The second scenario is mostly catered by private networks today, a market that ABI Research expects to grow from US$3.6 billion to US$109 billion by 2023, at a CAGR of 45.8%. Alusha continues, “A sizable part of this market can be converted to 5G slicing. But first, the industry should address challenges associated with technology and commercial models. On the latter, consumers’ and enterprises’ appetite to pay premium connectivity prices for deterministic and tailored connectivity services remains to be determined. Furthermore, there are ongoing industry discussions on whether the value that comes from 5G slicing can exceed the cost required to put together the underlying slicing ecosystem.”

Earlier this year, Daryl Schoolar - Research Director at IDC tackled this topic in his blog post:

5G network slicing, part of the 3GPP standards developed for 5G, allows for the creation of multiple virtual networks across a single network infrastructure, allowing enterprises to connect with guaranteed low latency. Using principles behind software-defined network and network virtualization, slicing allows the mobile operator to provide differentiated network experience for different sets of end users. For example, one network slice could be configured to support low latency, while another slice is configured for high download speeds. Both slices would run across the same underlying network infrastructure, including base stations, transport network, and core network.

Network slicing differs from private mobile networks, in that network slicing runs on the public wide area network. Private mobile networks, even when offered by the mobile operator, use infrastructure and spectrum dedicated to the end user to isolate the customer’s traffic from other users.

5G network slicing is a perfect candidate for future business connectivity needs. Slicing provides a differentiated network experience that can better match the customers performance requirements than traditional mobile broadband. Until now, there has been limited mobile network performance customization outside of speeds. 5G network slicing is a good example of telco service offerings that meet future of connectivity requirements. However, 5G network slicing also highlights the challenges mobile operators face with transformation in their pursuit of remaining relevant.

For 5G slicing to have broad commercial availability, and to provide a variety of performance options, several things need to happen first.

  • Operators need to deploy 5G Standalone (SA) using the new 5G mobile core network. Currently most operators use the 5G non-standalone (NSA) architecture that relies on the LTE mobile core. It might be the end of 2023 before the majority of commercial 5G networks are using the SA mode.
  • Spectrum is another hurdle that must be overcome. Operators still make most of their revenue from consumers, and do not want to compromise the consumer experience when they start offering network slicing. This means operators need more spectrum. In the U.S., among the three major mobile operators, only T-Mobile currently has a nationwide 5G mid-band spectrum deployment. AT&T and Verizon are currently deploying in mid-band, but that will not be completed until 2023.
  • 5G slicing also requires changes to the operator’s business and operational support systems (BSS/OSS). Current BSS/OSS solutions were not designed to support the increased parameters those systems were designed to support.
  • And finally, mobile operators still need to create the business propositions around commercial slicing services. Mobile operators need to educate businesses on the benefits of slicing and how slicing supports their different connectivity requirements. This could involve mobile operators developing industry specific partnerships to reach different business segments. All these things take time to be put into place.

Because of the enormity of the tasks needed to make 5G network slicing a commercial success, IDC currently has a very conservative outlook for this service through 2026. IDC believes it will be 2023 until there is general commercial availability of 5G network slicing. The exception is China, which is expected to have some commercial offerings in 2022 as it has the most mature 5G market. Even then, it will take until 2025 before global revenues from slicing exceeds a billion U.S. dollars. In 2026 IDC forecasts slicing revenues will be approximately $3.2 billion. However, over 80% of those revenues will come out of China.

The 'Outspoken Industry Analyst' Dean Bubley believes that Network Slicing is one of the worst strategic errors made by the mobile industry, since the catastrophic choice of IMS for communications applications. In a LinkedIn post he explains:

At best, slicing is an internal toolset that might allow telco operations or product teams (or their vendors) to manage their network resources. For instance, it could be used to separate part of a cell's capacity for FWA, and dynamically adjust that according to demand. It might be used as an "ingredient" to create a higher class of service for enterprise customers, for instance for trucks on a highway, or as part of an "IoT service" sold by MNOs. Public safety users might have an expensive, artisanal "hand-carved" slice which is almost a separate network. Maybe next-gen MVNOs.

(I'm talking proper 3GPP slicing here - not rebranded QoS QCI classes, private APNs, or something that looks like a VLAN, which will probably get marketed as "slices")

But the idea that slicing is itself a *product*, or that application developers or enterprises will "buy a slice" is delusional.

Firstly, slices will be dependent on [good] coverage and network control. A URLLC slice likely won't work reliably indoors, underground, in remote areas, on a train, on a neutral-host network, or while roaming. This has been a basic failure of every differentiated-QoS monetisation concept for many years, and 5G's often-higher frequencies make it worse, not better.

Secondly, there is no mature machinery for buying, selling, testing, supporting. price, monitoring slices. No, the 5G Network Exposure Function won't do it all. I haven't met a Slice salesperson yet, or a Slice-procurement team.

Thirdly, a "local slice" of a national 5G network will run headlong into a battle with the desire for separate private/dedicated local 5G networks, which may well be cheaper and easier. It also won't work well with the enterprise's IT/OT/IP domains, out of the box.

Also there's many challenges getting multi-operator slices, device OS links to slice APIs, slice "boundary controllers" between operators, aligning RAN and core slices, regulatory questionmarks and much more.

There are lots of discussion in the comments section that may be of interest to you, here.

My belief is that we will see lots of interesting use cases with slicing in public networks but it will be difficult to monetise. The best networks will manage to do it to create some plans with guaranteed rates and low latency. It would remain to be see whether they can successfully monetise it well enough. 

For technical people and newbies, there are lots of Network Slicing resources on this blog (see related posts 👇). Here is another recent video from Mpirical:

Related Posts: 

Posted by Zahid Ghadialy at 09:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , ,

Monday 22 August 2022

DCCA Features and Enhancements in 5G New Radio

In another new whitepaper on 5G-Advanced, Nokia has detailed DCCA (DC + CA) features and enhancements from Rel-15 until Rel-18. The following is an extract from the paper:

Mobility is one of the essential components of 5G-Advanced. 3GPP has already defined a set of functionalities and features that will be a part of the 5G-Advanced Release 18 package. These functionalities can be grouped into four areas: providing new levels of experience, network extension into new areas, mobile network expansion beyond connectivity, and providing operational support excellence. Mobility enhancements in Release 18 will be an important part of the ‘Experience enhancements” block of features, with the goal of reducing interruption time and improving mobility robustness.

Fig. 2 shows a high-level schematic of mobility and dual connectivity (DC)/Carrier Aggregation (CA) related mechanisms that are introduced in the different 5G legacy releases towards 5G-Advanced in Release 18. Innovations such as Conditional Handover (CHO) and dual active protocol stack (DAPS) are introduced in Release 16. More efficient operation of carrier aggregation (CA), dual connectivity (DC), and the combination of those denoted as DCCA, as well as Multi-Radio Access Technology DC (MR-DC) are introduced through Releases 16 and 17.

For harvesting the full benefits of CA/DC techniques, it is important to have an agile framework where secondary cell(s) are timely identified and configured to the UE when needed. This is of importance for non-standalone (NSA) deployments where a carrier on NR should be quickly configured and activated to take advantage of 5G. Similarly, it is of importance for standalone (SA) cases where e.g. a UE with its Primary Cell (PCell) on NR Frequency Range 1 (FR1) wants to take additional carriers, either on FR1 and/or FR2 bands, into use. Thus, there is a need to support cases where the aggregated carriers are either from the same or difference sites. The management of such additional carriers for a UE shall be highly agile in line with the user traffic and QoS demands; quickly enabling usage of additional carriers when needed and again quickly released when no longer demanded to avoid unnecessary processing at the UE and to reduce its energy consumption. This is of particular importance for users with time-varying traffic demands (aka burst traffic conditions).

In the following, we describe how such carrier management is gradually improved by introducing enhancements for cell identification, RRM measurements and reduced reporting delays from UEs. As well as innovations related to Conditional PSCell Addition and Change (CPAC) and deactivation of secondary cell groups are outlined.

The paper goes on to discuss the following scenarios in detail for DCCA enhancements:

  • Early measurement reporting
  • Secondary cell (SCell) activation time improvements
    • Direct SCell activation
    • Temporary RS (TRS)-based SCell Activation
  • Conditional Secondary Node (SN) addition and change for fast access
  • Activation of secondary cell group

The table below summarizes the DCCA features in 5G NR

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , ,

Tuesday 16 August 2022

Managing 5G Signalling Storms with Service Communication Proxy (SCP)

When we made our 5G Service Based Architecture (SBA) tutorial some four years back, it was based on Release-15 of the 3GPP standards. All Network Functions (NFs) simply sent discovery requests to the Network Repository Function (NRF). While this works great for trials and small scale deployments it can also lead to issues as can be seen in the slide above.

In 3GPP Release-16 the Service Communication Proxy (SCP) has now been introduced to allow the Control Plane network to handle and prioritize massive numbers of requests in real time. The SCP becomes the control point that mediates all Signalling and Control Plane messages in the network core.

SCP routing directs the flow of millions of simultaneous 5G function requests and responses for network slicing, microservice instantiation or edge compute access. It also plays a critical role in optimizing floods of discovery requests to the NRF and in overall Control Plane load balancing, traffic prioritization and message management.

A detailed whitepaper on '5G Signaling and Control Plane Traffic Depends on Service Communications Proxy (SCP)' by Strategy Analytics is available on Huawei's website here. This report was a follow on from the 'Signaling — The Critical Nerve Center of 5G Networks' webinar here.

Related Posts:

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , ,

Wednesday 10 August 2022

AI/ML Enhancements in 5G-Advanced for Intelligent Network Automation

Artificial Intelligence (AI) and Machine Learning (ML) has been touted to automate the network and simplify the identification and debug of issues that will arise with increasing network complexity. For this reason 3GPP has many different features that are already present in Release-17 but are expected to evolve further in Release-18. 

I have already covered some of this topics in earlier posts. Ericsson's recent whitepaper '5G Advanced: Evolution towards 6G' also has a good summary on this topic. Here is an extract from that:

Intelligent network automation

With increasing complexity in network design, for example, many different deployment and usage options, conventional approaches will not be able to provide swift solutions in many cases. It is well understood that manually reconfiguring cellular communications systems could be inefficient and costly.

Artificial intelligence (AI) and machine learning (ML) have the capability to solve complex and unstructured network problems by using a large amount of data collected from wireless networks. Thus, there has been a lot of attention lately on utilizing AI/ML-based solutions to improve network performance and hence providing avenues for inserting intelligence in network operations.

AI model design, optimization, and life-cycle management rely heavily on data. A wireless network can collect a large amount of data as part of its normal operations. This provides a good base for designing intelligent network solutions. 5G Advanced addresses how to optimize the standardized interfaces for data collection while leaving the automation functionality, for example, training and inference up to the proprietary implementation to support full flexibility in the automation of the network.

AI/ML for RAN enhancements

Three use cases have been identified in the Release 17 study item related to RAN performance enhancement by using AI/ML techniques. Selected use cases from the Release 17 technical report will be taken into the normative phase in the next releases. The selected use cases are: 1) network energy saving; 2) load balancing; and 3) mobility optimization.

The selected use cases can be supported by enhancements to current NR interfaces, targeting performance improvements using AI/ML functionality in the RAN while maintaining the 5G NR architecture. One of the goals is to ensure vendor incentives in terms of innovation and competitiveness by keeping the AI model implementation specific. As shown in Fig.2 (on the top) an intent-based management approach can be adopted for use cases involving RAN-OAM interactions. The intent will be received by the RAN. The RAN will need to understand the intent and trigger certain functionalities as a result.

AI/ML for physical layer enhancements

It is generally expected that AI/ML functionality can be used to improve the radio performance and/or reduced the complexity/overhead of the radio interface. 3GPP TSG RAN has selected three use cases to study the potential air interface performance improvements through AI/ML techniques, such as beam management, channel state information feedback enhancement, and positioning accuracy enhancements for different scenarios. The AI/ML-based methods may provide benefits compared to traditional methods in the radio interface. The challenge will be to define a unified AI/ML framework for the air interface by adequate AI/ML model characterization using various levels of collaboration between gNB and UE.

AI/ML in 5G core

5G Advanced will provide further enhancements of the architecture for analytics and on ML model life-cycle management, for example, to improve correctness of the models. The advancements in the architecture for analytics and data collection serve as a good foundation for AI/ML-based use cases within the different network functions (NFs). Additional use cases will be studied where NFs make use of analytics with the target to support in their decision making, for example, network data analytics functions (NWDAF)- assisted generation of UE policy for network slicing.

If you are interested in studying this topic further, check out 3GPP TR 37.817: Study on enhancement for data collection for NR and ENDC. Download the latest version from here.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , , , ,

Tuesday 2 August 2022

GSMAi Webinar: Is the Industry Moving Fast Enough on Standalone 5G?

I recently participated in a webinar, discussing one of my favourite topics, 5G Standalone (5G SA). If you do not know about 5G SA, you may want to quickly watch my short and simple video on the topic here.

Last year I blogged about GSA's 5G Standalone webinar here. That time we were discussing why 5G SA is taking time to deliver, it was sort of a similar story this time. Things are changing though and you will see a lot more of these standalone networks later this year and even early next year. 

The slides of the webinar are available here and the video is embedded below:

Here are some of my thoughts on why 5G SA is taking much longer than most people anticipated:

  • 5G SA will force operators to move to 5G core which is a completely new architecture. The transition to this is taking much longer than expected, especially if there are a lot of legacy services that needs to be supported.
  • Many operators are moving towards converged core with 4G & 5G support to simply the core. This transition is taking long.
  • For taking complete advantage of 5G architecture, cloud native implementation is required. Some operators have already started the transition to cloud native but others are lagging.
  • 5G SA speeds will be lower than NSA speeds hence some operators who don't have a lot of mid-band spectrum are delaying their 5G SA rollouts.
  • Many operators have managed to reduce their latency as they start to move to edge datacentres, hence the urgency for 5G standalone has reduced.
  • Most operators do not see any new revenue opportunities because of 5G SA, hence they want to be completely ready before rolling out 5G SA
  • Finally, you may hear a lot about not enough devices supporting 5G SA but that's not the device manufacturers views.  See this tweet from GSA 👇

Do you agree with my reasoning? If not, please let me know in the comments.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , ,

Monday 25 July 2022

Demystifying and Defining the Metaverse

There is no shortage of Metaverse papers and articles as it is the latest trend in the long list of technologies promising to change the world. Couple of months back I wrote a post about it in the 6G blog here.

IEEE hosted a Metaverse Congress with the Kickoff Session 'Demystifying and Defining the Metaverse' this month as can be seen in the Tweet above. The video embedded below covers the following talks:

  • 0:01:24 - Opening Remarks by Eva Kaili (Vice President, European Parliament)
  • 0:09:51 - Keynote - Metaverse Landscape and Outlook by Yu Yuan (President-Elect, IEEE Standards Association)
  • 0:29:30 - Keynote - Through the Store Window by Thomas Furness (“Grandfather of Virtual Reality”)
  • 0:52:30 - Keynote - XR: The origin of the Metaverse as Water-Human-Computer Interaction (WaterHCI) by Steve Mann (“Father of Wearable Computing”)
  • 1:22:17 - Keynote - A Vision of the Metaverse: AI Infused, Physically Accurate Virtual Worlds by Rev Lebaredian (VP of Omniverse & Simulation Technology, NVIDIA)

Some fantastic definitions, explanations, use cases and vision on Metaverse. The final speaker nicely summarised Metaverse as shown in this slide below.

Worth highlighting point 6 that the Metaverse is device independent. I argued about something similar when we try and link everything to 6G (like we linked everything to 5G before). We are just in the beginning phase, a lot of updates and clarifications will come in the next few years before Metaverse starts taking a final shape.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , ,

Monday 18 July 2022

APT 600 MHz Band Gets Approval from 3GPP

The current 600 MHz 5G band (n71) is getting an extension as 3GPP approves plan for APT 600 MHz band. Back in April, the 29th meeting of the APT Wireless Group (AWG-29) organized by the Asia Pacific Telecommunity (APT) concluded with the final approval of the new APT 600 MHz band plan that hoped to open an additional 40+40 MHz prime UHF spectrum. A similar approach back in 2013 resulted in the 45+45 MHz in the 700 MHz band, known in 3GPP as n28.

3GPP TSG RAN 96 (all docs here) approved a new work item to standardize the APT 600 MHz band plan which was initially proposed by the ITU-APT Foundation of India (IAFI).

RP-221778 (revision of RP-221062), provides a detailed justification for this new band. Quoting from the document:

The 470-694 MHz frequency range is allocated to the broadcasting service and mobile service on a co-primary basis in ITU Region 3. The frequency band 470-698 MHz, or parts thereof, was identified by WRC-15 in 7 countries in Region 3 through new footnote No. 5.296A for use by those administrations as listed wishing to implement terrestrial IMT systems. In addition, there is interest from other significant markets to do the same. Elsewhere, USA, Mexico and several other countries in ITU Region 2 also identified this band for IMT through footnotes 5.295 and 5.308A. It is noted that resolves 2 of revised Resolution 224 (Rev.WRC-19) to encourage administrations to take into account results of the existing relevant ITU Radio communication Sector studies, when implementing IMT applications/systems in the frequency bands 694-862 MHz in Region 1, in the frequency band 470-806 MHz in Region 2, in the frequency band 790-862 MHz in Region 3, in the frequency band 470-698 MHz, or portions thereof, for those administrations mentioned in No. 5.296A, and in the frequency band 698 790 MHz, or portions thereof, for those administrations mentioned in No. 5.313A.

Spectrum below 1 GHz is expectedly well suited for mobile broadband applications.  In particular, the unique propagation characteristics of the bands below 1 GHz allow for wider area coverage, which in turn requires fewer infrastructures and facilitates service delivery to rural or sparsely populated areas. In this regard, the 700MHz ecosystem is growing swiftly: there are over 34 commercial networks deployments.  The APT700 band plan coming out from Region 3 played a huge role in its success globally. Outside of APAC, countries in Region 2 have adopted or plan to adopt the APT700 band plan (3GPP band 28) for LTE system deployments. The lower duplexer of APT700 plan has also been adopted for Region 1 since the conclusion of WRC-15.

As the utilisation of the 700MHz spectrum increases over time, it is desirable to look at additional spectrum that could be considered as a companion besides 3GPP Band 28. Therefore, the use of parts of the 600MHz band for the mobile broadband service would provide a vital means of delivering high quality, wide area broadband services including in rural areas and deep inside buildings. The timely availability of frequency arrangements is essential for the development of IMT specifications and standards and the early consideration by Administrations in the footnotes referred to above of suitable frequency arrangements. 

The APT region is very diverse and consists of highly developed and developing countries and some with extremely large and rural population base. The sub 1 GHz bands is well suited for the later.

During the last year or so, 3GPP RAN 4 has completed a study item on the feasibility of various duplex filter options for use in this band. The results of this study are documented in TR 38.860. This study was sent to the AWG in an LS RP-212629 in Sep 2021 with a request to provide guidance on a preferred band plan and information on regulatory aspects for the normative work to begin. The AWG 28 meeting has considered the request of the 3GPP and has provided a response to this LS. In this response the LS has indicated a preference for option B1 (full band) and has also requested for the work to begin immediately with a view to completion by Dec 2022. Additionally, the answers to the regulatory questions sought by the 3GPP have now been provided via a reply LS RP 221045.

The band plan for the option B1 that has a single duplexer or full band- is shown in Table 1 below.

The Tx-Rx is "reverse-duplex"; in other words, the downlink frequency band is below the duplex gap while the uplink frequency band is above the duplex gap. This arrangement is opposite to conventional notation; however, for this band, it provides the benefit of aligning the uplink band adjacent to 3GPP band 28 thereby minimizing interference conditions at the 703 MHz boundary.

Accordingly, the companies listed here request 3GPP to start normative work on the following option. 

  • Option B1 with a single duplexer 

For anyone interested in studying this further might want to refer to 3GPP TR 38.860: Study on Extended 600 MHz NR band.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , ,

Tuesday 5 July 2022

5G and Cyber Security

Dr. Seppo Virtanen is an Associate Professor in Cyber Security Engineering and Vice Head of Department of Computing, the University of Turku, Finland. At 5G Hack The Mall 2022, he presented a talk on Cybersecurity and 5G. 

In the talk he covered the following topics:

  • Cybersecurity and Information Security
  • The CIA (Confidentiality, Integrity and Availability) Model
    • Achieving the goals of the CIA model
  • Intrusion and Detection
    • Intrusion detection, mitigation and aftercare
  • Smart Environments
    • Abstraction levels
    • Cybersecurity in smart environments
    • Cyber security concerns in smart environments
    • Security concerns in Smart Personal Spaces
    • Security concerns in Smart Rooms and Buildings
    • Security concerns of a participant in a smart environment
    • Cyber Security Concerns in Smart Environments
  • Cyber Security in the 5G context
  • Drivers for 5G security
  • Securing 5G

This video embedded below is a nice introduction to cybersecurity and how it overlaps with 5G:

Related Posts:

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , ,

Tuesday 28 June 2022

3GPP Explains TSG CT Work on UAS Connectivity, Identification and Tracking

Drones, technically Unmanned Aerial Vehicles/Systems or UAVs/UASs, have been a subject of interest for a very long time due to the wide variety of use cases they can offer. In the recent issue of 3GPP Highlights newsletter, Lena Chaponniere, 3GPP Working Group CT1 Vice-Chair has written an article about TSG CT work on UAS Connectivity, Identification and Tracking. Interestingly, the 3GPP abbreviation for UAS is slightly different, Uncrewed Aerial Systems.

Quoting from the newsletter: 

One of the defining drivers of 5G is the expansion beyond traditional mobile broadband to provide solutions meeting the needs of vertical industries.

A very good example of 3GPP rising up to this challenge is the work done in Release 17 to use cellular connectivity to support Uncrewed Aerial Systems (UAS), thereby enabling this vertical to benefit from the ubiquitous coverage, high reliability, QoS, robust security, and seamless mobility provided by the 3GPP system.

A key component of this work took place in CT Working Groups, which under the leadership of Sunghoon Kim (CT Work Item rapporteur) and Waqar Zia (rapporteur of new specifications TS 29.255 and TS 29.256) developed the necessary protocols and APIs to meet the service requirements specified in 3GPP SA1 and the architectural enhancements specified in 3GPP SA2, as part of the Release 17 Work Item on ‘ID_UAS’.

The key functions of the 3GPP architecture for ID_UAS are depicted in the following figure:

The work in CT Working Groups focused on specifying support for the following features:

UAV remote identification: The CAA (Civil Aviation Administration)-Level UAV ID was introduced in the 3GPP system. It is a globally unique, electronically and physically readable, and tamper resistant identification which allows the receiving entity to address the correct USS for retrieval of UAV information and can be assigned solely by the USS, via means outside the scope of 3GPP, or assigned by the USS with assistance from 3GPP system, whereby the USS delegates the role of “resolver” of the CAA-Level UAV ID to the UAS NF.

AV USS authentication and authorization (UUAA): The first step for the owner of the UAV is to register the UAV with the USS, via a procedure outside the scope of 3GPP, which can take place offline or using internet connectivity. During this procedure, the CAA-level UAV ID is configured in the UAV and the aviationlevel information (e.g. UAV serial number, pilot information, UAS operator, etc.) is provided to the USS.

The UE at the UAV then registers with the 3GPP system by using existing procedures for 3GPP primary authentication, with the MNO credentials stored in the USIM.

After successful authentication of the UE, the UUAA procedure is performed, to enable the 3GPP Core Network to verify that the UAV has successfully registered with the USS. In 5GS, this procedure can take place during the 3GPP registration, or during the establishment of a PDU session for UAS services.

For the former, CT1 extended the registration procedure in TS 24.501 to enable the UE to indicate its CAA-Level UAV ID into a new container (Service-level-AA container) included in the Registration Request message, which triggers the AMF to initiate UUAA with the USS by invoking the Nnef_Authentication service toward the UAS NF, as specified by CT4 in new specification TS 29.256, and the UAS NF to invoke the Naf_Authentication service toward the USS, as specified by CT3 in new specification TS 29.255.

For the latter, CT1 extended the PDU session establishment procedure in TS 24.501 to enable the UE to indicate its CAA-Level UAV ID via the Service-level-AA container included in the PDU Session Establishment Request message, which triggers the SMF to initiate UUAA with the USS via the UAS NF by invoking the services mentioned above. In order to enable exchanging the authentication messages between the UE and the USS, CT1 specified a new Session Management procedure in TS 24.501, in which the SMF sends a Service-level Authentication Command to the UE in a Downlink NAS Transport message. The UE replies to this command with a Service-level Authentication Complete carried in an Uplink NAS Transport message. In EPS, the UUAA procedure takes place during PDN connection establishment, and the information exchanged to that end between the UAV and the PGW is carried in the Service-level-AA container included in the ePCO

C2 communication over cellular connectivity: C2 communication over cellular connectivity consists of the UAV establishing a user plane connection to receive C2 messages from a UAVC, or to report telemetry data to a UAVC. Authorization for C2 communication by the USS is required and includes authorization for pairing of the UAV with a UAVC, as well as flight authorization for the UAV.

C2 communication authorization may be performed:

  • during the UUAA procedure (if UUAA is carried out at PDU session/PDN connection establishment) when the UAV requests establishment of a PDU Session/PDN connection for both UAS services and C2 communication
  • during PDU session modification/UE requested bearer resource modification when the UAV requests to use an existing PDU session/PDN connection for C2 communication
  • during a new PDU session/PDN connection establishment, if the UAV requests to use a separate PDU Session/PDN connection for C2 communication

To support this, CT1 extended the PDU session establishment and modification procedures in TS 24.501 to enable inclusion of the CAA-level UAV ID and an application layer payload containing information for UAVC pairing and for UAV flight authorization in the Service-level-AA container carried in the PDU Session Establishment Request and PDU Session Modification Request messages. The ePCO Information Element in TS 24.008 was also extended to enable it to include the above-mentioned information.

UAV location reporting and tracking: UAV location reporting and tracking was specified by CT3 and CT4 by re-using the existing Nnef_EventExposure service specified in TS 29.522 with the UAS NF acting as NEF/SCEF and interacting with other network functions (e.g. GMLC and AMF/MME) to support UAV tracking. The following tracking modes were specified:

  • UAV location reporting mode: the USS subscribes to the UAS NF UAV to be notified of the location of the UAV, and can indicate the required location accuracy and whether the request is for immediate reporting or deferred reporting (e.g. periodic reporting)
  • UAV presence monitoring mode: the USS subscribes for the event report of UAV moving in or out of a given geographic area
  • List of Aerial UEs in a geographic area: the USS requests the UAS NF for reporting a list of the UAVs in given geographic area and served by the PLMN.

The PDF of newsletter is available here.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , ,
Subscribe to: Posts (Atom)