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, 6 October 2022

Key enablers for mass IoT adoption

At 'The Things Conference' in Amsterdam in September, Roman Nemish, Co-Founder & President of TEKTELIC presented a critical view of different IoT technologies and argued that LoRaWAN is the only technology that will eventually make mass IoT possible.

The following is the intro to the talk from the conference:

IoT technology has progressed from home to city-scale applications, making it a crucial part of any operational process. IoT sensors are becoming more affordable, reliable, and easy to deploy.

The Internet of Things has already brought advancement to healthcare, retail, city infrastructure, and manufacturing with many other opportunities still open.

We are ready to explain why IoT deployment has transformed from privilege to necessity, what benefits it can bring to your business, and how you win the competition using IoT.

Enterprise IoT Insights have a good take on the talk here. The following is an extract:

Nemish, president at TEKTELIC, argued that new-wave cellular IoT – in the form of NB-IoT and LTE-M, primarily – is “too expensive” for consumers and too small-margin for mobile operators; that “most IoT opportunities are 10-25 times smaller [than the kinds of deals that would] attract operator attention”. Cellular IoT has “vast potential”, he concluded, but requires a “different approach”.

In other words, there is not enough profit in (low-power) cellular IoT for mobile operators to give it proper focus – and the deals are not big enough to make them really care. The IoT game – based on finely-calculated returns on volume-deals not going much higher than 100,000 units at a time – is better served by smaller-sized providers, without regional spectrum licences, offering broadly-equivalent technologies in unlicensed bands, he implied.

But experiences with Sigfox and LoRaWAN (in some formats) – the French-born IoT twin-tech that started the whole low-power wide-area (LPWA) movement, and forced the cellular community to come up with their own alternatives – have not been much better, necessarily, the story goes. Sigfox pumped $350 million over 10 years into its technology and network, only to go into receivership at the start of 2022 with fewer than 20 million devices under management.

The problem, said Nemish, is with the business model, and not the tech. (As an aside, a takeaway from The Things Conference last week, as from the LoRaWAN World Expo in Paris in the summer, and from any number of private discussions in between, is the IoT market is mature enough to let go of its closely-held tech differences, and acknowledge that customers don’t really care so long as it works – and so the blame switches to the business model, instead.)

Nemish blamed Sigfox’s ‘failure’ on exclusive single-market contracts and cripping licensing fees; these “killed most operator business plans”, he suggested. Of course, Sigfox lives to see another day – and, it might be noted, Taiwan-based IoT house Unabiz, its new owners, have just hosted the 0GUN Alliance of Sigfox operators in France to bash-out a new operator model, and a collaborative approach to a “unified LPWAN world”.

And LoRaWAN is not exempt in the analysis, either. In Amsterdam, Nemish held up the madly-hyped Helium model for crypto-led community network building as another failed IoT business model. Again – and of course, with a critical appraisal of a LoRaWAN network by a LoRaWAN provider – the tech is not the problem, just the way it is being offered. Because Helium, he said, with $1 billion of public community funding, has “no use” after three years.

As per the slide, parent Nova Labs has “failed to sign customers, implement SLA(s), or plan network evolution”, he suggested. The community behind it, originally bedsit enthusiasts on to a good thing, are not motivated by “IoT adoption but [by] crypto-mania”, said Nemish. Just look on eBay, where 10,000 secondhand Helium miners (gateways) are being flogged, to see how its star has fallen, he said – along with its stock, with HNT trading up 12 percent at around $5 at writing, on the back of a deal for decentralised 5G with T-Mobile in the US, but down from a high of nearly $30 a few months ago.

The article highlights some heated discussions on the presentation and slides. You can read the whole article here.

The closing slide nicely summarises that IoT deployment is a marathon, not a sprint. End users are interested in solving real-world problems. Partner to develop complete IoT solutions that can be integrated simply with any IoT platform and with clearly defined API. Also have a strong engineering team to support customer integration and early deployment.

Here is the video of the talk for anyone interested:

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...1 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: , , , , , , , , , , ,

Saturday, 10 September 2022

CUPS for Flexible U-Plane Processing Based on Traffic Characteristics

I looked at Control and User Plane Separation (CUPS) in a tutorial, nearly five years back here. Since then most focus has been on 5G, not just on my blogs but also from the industry. 

Earlier this year, NTT Docomo's Technical Journal looked at CUPS for Flexible U-Plane Processing Based on Traffic Characteristics. The following is an extract from the article:

At the initial deployment phase of 5th Generation mobile communication systems (5G), the 5G Non-Stand-Alone (NSA) architecture was widely adopted to realize 5G services by connecting 5G base stations to the existing Evolved Packet Core (EPC). As applications based on 5G become more widespread, the need for EPC to achieve higher speed and capacity communications, lower latency communications and simultaneous connection of many terminals than ever has become urgent. Specifically, it is necessary to increase the number of high-capacity gateway devices capable of processing hundreds of Gbps to several Tbps to achieve high-speed, high-capacity communications, to distribute gateway devices near base station facilities to achieve even lower latency communications, and to improve session processing performance for connecting massive numbers of terminals simultaneously.

Conventional single gateway devices have both Control Plane (C-Plane) functions to manage communication sessions and control communications, and User Plane (U-Plane) functions to handle communications traffic. Therefore, if the previously assumed balance between the number of sessions and communications capacity is disrupted, either the C-Plane or the U-Plane will have excess processing capacity. In high-speed, high-capacity communications, the C-Plane has excess processing power, and in multiple terminal simultaneous connections, the U-Plane has excess processing power because the volume of communications is small compared to the number of sessions. If the C-Plane and U-Plane can be scaled independently, these issues can be resolved, and efficient facility design can be expected. In addition, low-latency communications require distributed deployment of the U-Plane function near the base station facilities to reduce propagation delay. However, in the distributed deployment of conventional devices with integrated C-Plane and U-Plane functions, the number of sessions and communication volume are unevenly distributed among the gateway devices, resulting in a decrease in the efficiency of facility utilization. Since there is no need for distributed deployment of C-Plane functions, if the C-Plane and U-Plane functions can be separated and the way they are deployed changed according to their characteristics, the loss of facility utilization efficiency related to C-Plane processing capacity could be greatly reduced.

CUPS is an architecture defined in 3GPP TS 23.214 that separates the Serving GateWay (SGW)/Packet data network GateWay (PGW) configuration of the EPC into the C-Plane and U-Plane. The CUPS architecture is designed so that there is no difference in the interface between the existing architecture and the CUPS architecture - even with CUPS architecture deployed in SGW/PGW, opposing devices such as a Mobility Management Entity (MME), Policy and Charging Rules Function (PCRF), evolved NodeB (eNB)/ next generation NodeB (gNB), and SGWs/PGWs of other networks such as Mobile Virtual Network Operator (MVNO) and roaming are not affected. For C-Plane, SGW Control plane function (SGW-C)/PGW Control plane function (PGW-C), and for U-Plane, SGW User plane function (SGW- U)/PGW User plane function (PGW-U) are equipped with call processing functions. By introducing CUPS, C-Plane/U-Plane capacities can be expanded individually as needed. Combined SGW-C/PGW-C and Combined SGW-U/PGW-U can handle the functions of SGW and PGW in common devices. In the standard specification, in addition to SGW/PGW, the Traffic Detection Function (TDF) can also be separated into TDF-C and TDF-U, but the details are omitted in this article.

From above background, NTT DOCOMO has been planning to deploy Control and User Plane Separation (CUPS) architecture to realize the separation of C-Plane and U-Plane functions as specified in 3rd Generation Partnership Project Technical Specification (3GPP TS) 23.214. Separating the C-Plane and U-Plane functions of gateway devices with CUPS architecture makes it possible to scale the C-Plane and U-Plane independently and balance the centralized deployment of C-Plane functions with the distributed deployment of U- Plane functions, thereby enabling the deployment and development of a flexible and efficient core network. In addition to solving the aforementioned issues, CUPS will also enable independent equipment upgrades for C-Plane and U-Plane functions, and the adoption of U-Plane devices specialized for specific traffic characteristics.

In the user perspective, the introduction of CUPS can be expected to dramatically improve the user experience through the operation of facilities specializing in various requirements, and enable further increases in facilities and lower charges to pursue user benefits by improving the efficiency of core network facilities.

Regarding the CUPS architecture, a source of value for both operators and users, this article includes an overview of the architecture, additional control protocols, U-Plane control schemes based on traffic characteristics, and future developments toward a 5G Stand-Alone (5G SA) architecture.

The article is available here.

Related Posts: 

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

Friday, 26 August 2022

How Multiband-Cells are used for MORAN RAN Sharing

In the previous blog post I have explained the concept of multi-band cells in LTE networks and promised to explain a bit deeper how such cells can be used in Multi-Operator RAN (MORAN) scenarios. 

MORAN is characterized by the fact that all network resources except the radio carriers and the Home Subscriber Server (HSS) are shared between two or more operators. 

What this means in detail can be see in Step 1 of the figure below. 

The yellow Band #1 spectrum of the multi-band cell is owned by Network Operator 1 while the blue spectrum of Band #2 and Band #3 belongs to Network Operator 2.

Band #1 is the default band. This means if a UE enters the cell is always has to establish the initial RRC signaling connection on Band #1 as shown in step 1.

The spectrum owned by Network Operator 2 comes into the game as soon as a dedicated radio bearer (DRB), in the core network known as E-RAB, is established in this RRC connection. 

Then we see intra-frequency (intra-cell) handover to Band #2 where the RRC signaling connection is continued. Band #3 is added for user plane transport as a secondary "cell" (the term refers to the 3GPP 36.331 RRC specification). 

The reason for this behavior can be explained when looking a frequency bandwidths. 

The default Band #1 is a low frequency band with a quite small bandwidth, e.g. 5 MHz. as it is typically used for providing good coverage in rural areas. Band #2 is also a lower frequency band, but Band #3 is a high frequency band with maximum bandwidth of 20 MHz. So Band #3 brings the highest capacity for user plane transport and that is the reason for the handover to the spectrum owned by Network Operator 2 and the carrier aggregation used on these frequency bands. 

However, due to the higher frequency the footprint of Band #3 is lower compared to the other two frequency bands. 

For UEs at the cell edge (or located in buildings while being served from the outdoor cell) this leads quite often to situations where the radio coverage of Band #3 becomes insufficient. In such cases the UE typically sends a RRC measurement event A2 (means: "The RSRP of the cell is below a certain threshold."). 

If such A2 event is received by the eNB it stops the carrier aggregation transport and releases the Band #3 resources so that all user plane transport continues to run on the limited Band #2 resources as shown in step 3.

And now in the particular eNB I observed a nice algorithm starts that could be seen as a kind of zero-touch network operation although it does not need big data nor artificial intelligence. 

10 seconds after the secondary frequency resources of Band #3 have been deleted they are added again to the connection, but if the UE is still at the same location the next A2 will be reported soon and carrier aggregation will be stopped again for 10 seconds and then the next cycle starts.

This automation loop is carried out endlessly until the UE changes its location or the RRC connection is terminated. 

Related Posts:

Posted by Ralf Kreher at 11:48 Leave a comment...1 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: , , , , , , , , , ,
Subscribe to: Posts (Atom)