Showing posts with label Release 16. Show all posts
Showing posts with label Release 16. Show all posts

Sunday, 19 January 2020

2-step RACH Enhancement for 5G New Radio (NR)

5G Americas recently published a white paper titled, "The 5G Evolution: 3GPP Releases 16-17" highlighting new features in 5G that will define the next phase of 5G network deployments across the globe. It's available here. One of the sections in that details the 2-step RACH enhancement that is being discussed for a while in 3GPP. The 2-step process would supercede the 4-step process today and would reduce the lartency and optimise the signalling.


Here are the details from the 5G Americas whitepaper:

RACH stands for Random Access Channel, which is the first message from UE to eNB when it is powered on. In terms of Radio Access Network implementation, handling RACH design can be one of the most important / critical portions.
The contention-based random-access procedure from Release 15 is a four-step procedure, as shown in Figure 3.12. The UE transmits a contention-based PRACH preamble, also known as Msg1. After detecting the preamble, the gNB responds with a random-access response (RAR), also known as Msg2. The RAR includes the detected preamble ID, a time-advance command, a temporary C-RNTI (TC-RNTI), and an uplink grant for scheduling a PUSCH transmission from the UE known as Msg3. The UE transmits Msg3 in response to the RAR including an ID for contention resolution. Upon receiving Msg3, the network transmits the contention resolution message, also known as Msg4, with the contention resolution ID. The UE receives Msg4, and if it finds its contention-resolution ID it sends an acknowledgement on a PUCCH, which completes the 4-step random access procedure.

The four-step random-access procedure requires two round-trip cycles between the UE and the base station, which not only increases the latency but also incurs additional control-signaling overhead. The motivation of two-step RACH is to reduce latency and control-signaling overhead by having a single round trip cycle between the UE and the base station. This is achieved by combining the preamble (Msg1) and the scheduled PUSCH transmission (Msg3) into a single message (MsgA) from the UE, known as MsgA. Then by combining the random-access respond (Msg2) and the contention resolution message (Msg4) into a single message (MsgB) from the gNB to UE, see Figure 3.13. Furthermore, for unlicensed spectrum, reducing the number of messages transmitted from the UE and the gNB, reduces the number of LBT (Listen Before Talk) attempts.

Design targets for two-step RACH:

  • A common design for the three main uses of 5G, i.e. eMBB, URLLC and mMTC in licensed and unlicensed spectrum.
  • Operation in any cell size supported in Release 15, and with or without a valid uplink time alignment (TA).
  • Applicable to different RRC states, i.e. RRC_INACTIVE, RRC_CONNECTED and RRC_IDLE states.
  • All triggers for four-step RACH apply to two-step RACH including, Msg3-based SI request and contention-based beam failure recovery (CB BFR).

As described earlier, MsgA consists of a PRACH preamble and a PUSCH transmission, known as MsgA PRACH and MsgA PUSCH respectively. The MsgA PRACH preambles are separate from the four-step RACH preambles, but can be transmitted in the same PRACH Occasions (ROs) as the preambles of fourstep RACH, or in separate ROs. The PUSCH transmissions are organized into PUSCH Occasions (POs) which span multiple symbols and PRBs with optional guard periods and guard bands between consecutive POs. Each PO consists of multiple DMRS ports and DMRS sequences, with each DMRS port/DMRS sequence pair known as PUSCH resource unit (PRU). two-step RACH supports at least one-to-one and multiple-to-one mapping between the preambles and PRUs.

After the UE transmits MsgA, it waits for the MsgB response from the gNB. There are three possible outcomes:

  1. gNB doesn’t detect the MsgA PRACH ➡ No response is sent back to the UE ➡ The UE retransmits MsgA or falls back to four-step RACH starting with a Msg1 transmission.
  2. gNB detects MsgA preamble but fails to successful decode MsgA PUSCH ➡ gNB sends back a fallbackRAR to the UE with the RAPID (random-access preamble ID) and an uplink grant for the MsgA PUSCH retransmission ➡ The UE upon receiving the fallbackRAR, falls back to four-step RACH with a transmission of Msg3 (retransmission of the MsgA PUSCH).
  3. gNB detects MsgA and successfully decodes MsgA PUSCH ➡ gNB sends back a successRAR to the UE with the contention resolution ID of MsgA ➡ The reception of the successRAR successfully completes the two-step RACH procedure.

As described earlier, MsgB consists of the random-access response and the contention-resolution message. The random-access response is sent when the gNB detects a preamble but cannot successfully decode the corresponding PUSCH transmission. The contention resolution message is sent after the gNB successfully decodes the PUSCH transmission. MsgB can contain backoff indication, fallbackRAR and/or successRAR. A single MsgB can contain the successRAR of one or more UEs. The fallbackRAR consists of the RAPID: an uplink grant to retransmit the MsgA PUSCH payload and time-advance command. The successRAR consists of at least the contention resolution ID, the C-RNTI and the TA command.

For more details on this feature, see 3GPP RP-190711, “2-step RACH for NR” (Work-item description)

Monday, 16 December 2019

5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17


It's been a while since I last wrote about IAB on this blog here. At that time 3GPP Release-16 was being discussed. Since then things have moved on. While Release-16 is being prepared for final release soon, Release-17 study and work items have just been agreed upon.

IAB is included as part of Rel-16 but there isn't a comprehensive document or presentation easily available to details all that it will contain. Similarly the enhancements for Release-17 are available only superficially. Qualcomm is well known for making some really excellent presentations available on 5G. One of their presentations from January (here) has some details on IAB (pg. 32 - 35). There was also an excellent presentation by Navid Abedini, Qualcomm from IEEE Sarnoff Symposium, 2019 which is embedded at the end.


In a 3GPP RAN#84 discussion document RP-191181, Samsung has provided a comprehensive summary of what is being done as part of Rel-16 and what did not make in that:
  • Rel-16 IAB aims at basic operations
    • Architecture and protocol design
    • IAB integration procedure 
    • Routing, BAP and BH configuration
    • CP and UP data transmission  via IAB
    • Topology support: 
      • Spanning Tree (ST) and Directed acyclic graph (DAG) 
      • Intra-Donor adaptation is prioritized
  • The following cannot  be supported in Rel-16
    • Mobile IAB
    • Topology support: Mesh
  • Some functionalities in Rel-16 may not be completed due to time constrains e.g. 
    • Topology adaptation between IAB donors
    • Mechanisms for efficient control signaling transmission
Ericsson also provides a good summary in RP-190971 regarding Release 16 IAB and Rel-17 enhancements:
  • IAB Rel-16 provide basic support for multi-hop and multi-path relaying. 
  • The solution supports 
    • QoS prioritization of traffic on the backhaul link
    • Flexible resource usage between access and backhaul
    • Topology adaptivity in case link failure
  • In Rel-17 it would be possible to further evolve the IAB solution targeting increased efficiency and support for new use cases


Meanwhile in the recently concluded RAN#86, AT&T provided a good detailed summary on what enhancements are required for IAB as part of Rel-17 in RP-192709
  • Duplexing enhancements
    • Multiplexing beyond TDM (FDM/SDM/multi-panel Tx/Rx) including multi-parent scenarios, case 6/7 timing alignment, power control/CLI optimizations
  • Topology enhancements
    • Mobile IAB: CP/UP split + Group mobility 
    • Inter-CU topology adaptation
    • Mesh-connectivity between IAB nodes for local control/user plane routing
  • User plane enhancements
    • Multi-hop scheduling enhancement – exchange of benefit metric between IAB nodes to enable radio-aware multi-hop scheduling to improve throughput performance
  • Network Coding
    • Study benefits compared to duplication over redundant backhaul routes

We will have to wait and see what makes it into the enhancements and what don't. Meanwhile here is a video from Navid Abedini, Qualcomm from IEEE Sarnoff Symposium, 2019




Related Posts:

Monday, 9 December 2019

5G Evolution with Matthew Baker, Nokia


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



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



Related Posts:

Monday, 2 December 2019

Guest Post: Exploring Network Convergence of Mobile, Broadband and Wi-Fi

This is a guest post by Ben Toner, Founder and Director, Numerous Networks


Are multiple networks better than one?

How many articles have you read with a title similar to "Which technology is better, 5G or Wi-Fi6?" If, like me, you regularly use Wi-Fi and cellular (I still use 4G though) then you might find it hard to take sides.

Enter Network Convergence - the concept of bringing multiple networks together to get the best of them all. Imagine, as an end user, not having to decide which network to use but instead feeling satisfied that your data was traversing the best combination of networks at that moment in time.

Imagine a business traveler being connected to Wi-Fi which is slow or busy while trying to take that all important conference call while sitting in an airport. Because you are roaming you want to use that Wi-Fi but you do not want to compromise the video call quality. If your network and device could work together to use just enough cellular data to supplement the slow Wi-Fi so that you stayed within your daily roaming quota but never lost a moment in the video call - then you would probably be very happy with that service. Better still, as you start walking off, if the call transitioned from Wi-Fi to cellular with no dropouts or hangup then you might be delighted!

Earlier I underlined best because that in itself is somewhat complicated.  The example above is easy to desribe but quite hard for to achieve within a framework where all possible scenarios are handled that well, for every user. The common questions which need to be factored into any such choice are:
  • What do I as the end user want? 
  • What performance can each network deliver. 
  • How important is the transfer of content at that time and 
  • How much am I willing to pay for it (how many MB of my data plan am I willing to use?). 

This is one of the challenges that we cannot easily solve today, but technology is being developed to help in that process. The operators and device vendors are working within standardisation to develop technology which can provide such a converged service. However at this time there is still a rules mechanism behind it all which does not really describe how user input and preference is going to be captured.

In the last 10 years I have witnessed many battles within service providers when deciding what "one size fits all" service to offer everyone when deciding how to make service provider Wi-Fi available to their customers; all fuelled by my points above.

A lot of concepts are well designed and somewhat mature but deciding exactly what will be implemented in standards is currently ongoing.

In the following slides and video I introduce this whole concept of Network Convergence. The following content introduces the concept and then takes a detailed look at the ATSSS; technology being defined in 3GPP. I also have highlighted the technologoies you can get hold of today to try out network convergence.

I encourage you all to download the example technologies and try convergence for yourself. I'm eager to hear opinions of what technologies work best for each of you. And better still, what is not being provided which you think should be...

Looking forward to your feedback and answering your questions...





Ben Toner
Founder and Director, Numerous Networks


Related Posts:

Thursday, 7 November 2019

Introduction to 5G ATSSS - Access Traffic Steering, Switching and Splitting


Last month we made a short tutorial on 5G and Fixed-Mobile Convergence (FMC). One of the features covered in that was ATSSS. It deserved a bit more detail so we made a short tutorial on this feature.

Access Traffic Steering, Switching and Splitting or ATSSS for short is being standardized as part of 3GPP Rel-16 and allows traffic steering across multiple accesses at a finer granularities than a PDU session.  It is an optional feature both on the UE and the 5GC network. ATSSS introduces the notion of Multi Access PDU session, a PDU session for which the data traffic can be served over one or more concurrent accesses (3GPP access, trusted non-3GPP access and untrusted non-3GPP access). The simplest way to visualize it is as shown below:


The presentation and video is embedded below:







Related Posts:

Sunday, 15 September 2019

Thursday, 29 August 2019

LTE / 5G Broadcast Evolution


It's been a while since I last wrote about eMBMS. A report by GSA last month identified:
- 41 operators known to have been investing in eMBMS
- 5 operators have now deployed eMBMS or launched some sort of commercial service using eMBMS
- GSA identified 69 chipsets supporting eMBMS, and at least 59 devices that support eMBMS


BBC R&D are testing the use of 4G/5G broadcast technology to deliver live radio services to members of the public as part of 5G RuralFirst - one of 6 projects funded under the UK Government’s 5G Phase 1 testbeds and trials programme (link).

A press release by Samsung Electronics back in May announced that it has signed an expansion contract with KT Corporation (KT) to provide public safety (PS-LTE) network solutions based on 3GPP standard Release 13 for 10 major metropolitan regions in South Korea including Seoul by 2020. One of the features of PS-LTE that the PR listed was LTE Broadcast (eMBMS): A feature which allows real time feeds to hundreds of devices simultaneously. It enables thousands of devices to be connected at once to transfer video, images and voice simultaneously using multicast technology

Dr. Belkacem Mouhouche – Samsung Electronics Chief Standards Engineer  and Technical Manager of 5G projects: 5G-Xcast and 5G-Tours Presented an excellent overview on this topic at IEEE 5G Summit Istanbul, June 2019. His presentation is embedded below.



5G-Xcast is a 5GPPP Phase II project focused on Broadcast and Multicast Communication Enablers For the Fifth Generation of Wireless Systems.

They have a YouTube channel here and this video below is an introduction to project and the problems it looks to address.




Further Reading:

Related posts:

Monday, 5 August 2019

An Introduction to Non-Terrestrial Networks (NTN)


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






Related Posts:

Tuesday, 9 July 2019

3GPP 5G Standardization Update post RAN#84 (July 2019)

3GPP recently conducted a webinar with Balazs Bertenyi, Chairman of 3GPP RAN in which he goes through some of the key features for 5G Phase 2. The webinar also goes through the details of 5G Release-15 completion, status of Release-16 and a preview of some of Release-17 features.

Slides & video embedded below. Slides can be downloaded from 3GPP website here.







Related Posts:

Tuesday, 18 June 2019

3GPP Release-16, Release-17 & Beyond...

6G Summit featured quite a few talks from people looking at evolution beyond Release-16. The future releases will still be 5G, maybe become 5.5G, like 3GPP Release-13 which was known as LTE-Advanced Pro officially was unofficially known as 4.5G.


Back at the 6G Summit in Finland, Dr. Peiying Zhu from Huawei looked at the topics being discussed for Release-17 and beyond.


Thanks to Mika Klemettinen for sharing the pictures on Twitter, as the presentation was not shared.

3GPP is working towards defining Release-16. TS 21.916 - Release description; Release 16 is still not yet available on the 3GPP reflector. Once that is available, we will know for sure about all the Rel-16 changes. Release-17 is long way away. Having said that, there is no shortage of discussions as some of these Rel-17 features were discussed in the recent RAN Plenary.
Jungwon Lee, VP, Samsung also shared a summary of 3GPP Release-16 and Rel-17 features at IEEE 5G Summit in San Diego recently. Quite a few interesting features in all the pictures above that we will no doubt look at in the future posts.

3GPP also shared a presentation recently (embedded below), looking at not only Release-15 & 16 but also looking at focus areas for Release-17




Related Posts and Articles:
  • The 3G4G Blog - Ultra Reliability: 5x9s (99.999%) in 3GPP Release-15 vs 6x9s (99.9999%) in 3GPP Release-16
  • The 3G4G Blog - Update from 3GPP on LTE & 5G Mission Critical Communications
  • 3GPP - Release 16
  • Light Reading - 5G Standards Group Struggles to Balance Tech With Politics
  • Eiko Seidel - 5G Mission Critical Networks (Proximity Services in Rel.17)
  • The 3G4G Blog - Slides and Videos from the 1st 6G Wireless Summit - March 2019
  • The 3G4G Blog - Couple of talks by NTT Docomo on 5G and Beyond (pre-6G)
  • The 3G4G Blog - China Telecom: An examination of the current industrial trends and an outlook of 6G
  • Mission Critical Communications: Mission-Critical Features for Release 17 Discussed at Latest 3GPP Meetings

Thursday, 21 March 2019

Update from 3GPP on LTE & 5G Mission Critical Communications


Adrian Scrase, CTO of ETSI & Head of MCC, 3GPP presented an update at BAPCO / CCE 2019 on Public Safety LTE and 5G. His presentation is embedded below.

There has been quite a progress in this area since I wrote my last post on Release-14 here.
This is the list of features that are planned for Release-16. There is also an update on Satellite communications but I will look at it separately in another post. Here are the slides:



The presentation can be directly downloaded from 3GPP website here.

Related posts:

Sunday, 29 July 2018

Automating the 5G Core using Machine Learning and Data Analytics

One of the new entities introduced by 3GPP in the 5G Core SBA (see tutorial here) is Network Data Analytics Function, NWDAF.
3GPP TR 23.791: Study of Enablers for Network Automation for 5G (Release 16) describes the following 5G Network Architecture Assumptions:

1 The NWDAF (Network Data Analytics Function) as defined in TS 23.503 is used for data collection and data analytics in centralized manner. An NWDAF may be used for analytics for one or more Network Slice.
2 For instances where certain analytics can be performed by a 5GS NF independently, a NWDAF instance specific to that analytic maybe collocated with the 5GS NF. The data utilized by the 5GS NF as input to analytics in this case should also be made available to allow for the centralized NWDAF deployment option.
3 5GS Network Functions and OAM decide how to use the data analytics provided by NWDAF to improve the network performance.
4 NWDAF utilizes the existing service based interfaces to communicate with other 5GC Network Functions and OAM.
5 A 5GC NF may expose the result of the data analytics to any consumer NF utilizing a service based interface.
6 The interactions between NF(s) and the NWDAF take place in the local PLMN (the reporting NF and the NWDAF belong to the same PLMN).
7 Solutions shall neither assume NWDAF knowledge about NF application logic. The NWDAF may use subscription data but only for statistical purpose.

Picture SourceApplication of Data Mining in the 5G Network Architecture by Alexandros Kaloxylos

Continuing from 3GPP TR 23.791:

The NWDAF may serve use cases belonging to one or several domains, e.g. QoS, traffic steering, dimensioning, security.
The input data of the NWDAF may come from multiple sources, and the resulting actions undertaken by the consuming NF or AF may concern several domains (e.g. Mobility management, Session Management, QoS management, Application layer, Security management, NF life cycle management).
Use case descriptions should include the following aspects:
1. General characteristics (domain: performance, QoS, resilience, security; time scale).
2. Nature of input data (e.g. logs, KPI, events).
3. Types of NF consuming the NWDAF output data, how data is conveyed and nature of consumed analytics.
4. Output data.
5. Possible examples of actions undertaken by the consuming NF or AF, resulting from these analytics.
6. Benefits, e.g. revenue, resource saving, QoE, service assurance, reputation.

Picture SourceApplication of Data Mining in the 5G Network Architecture by Alexandros Kaloxylos

3GPP TS 23.501 V15.2.0 (2018-06) Section 6.2.18 says:

NWDAF represents operator managed network analytics logical function. NWDAF provides slice specific network data analytics to a NF. NWDAF provides network analytics information (i.e., load level information) to a NF on a network slice instance level and the NWDAF is not required to be aware of the current subscribers using the slice. NWDAF notifies slice specific network status analytic information to the NFs that are subscribed to it. NF may collect directly slice specific network status analytic information from NWDAF. This information is not subscriber specific.

In this Release of the specification, both PCF and NSSF are consumers of network analytics. The PCF may use that data in its policy decisions. NSSF may use the load level information provided by NWDAF for slice selection.

NOTE 1: NWDAF functionality beyond its support for Nnwdaf is out of scope of 3GPP.
NOTE 2: NWDAF functionality for non-slice-specific analytics information is not supported in this Release of the specification.

3GPP Release-16 is focusing on 5G Expansion and 5G Efficiency, SON and Big Data are part of 5G Efficiency.
Light Reading Artificial Intelligence and Machine Learning section has a news item on this topic from Layer123's Zero Touch & Carrier Automation Congress:

The 3GPP standards group is developing a machine learning function that could allow 5G operators to monitor the status of a network slice or third-party application performance.

The network data analytics function (NWDAF) forms a part of the 3GPP's 5G standardization efforts and could become a central point for analytics in the 5G core network, said Serge Manning, a senior technology strategist at Sprint Corp.

Speaking here in Madrid, Manning said the NWDAF was still in the "early stages" of standardization but could become "an interesting place for innovation."

The 3rd Generation Partnership Project (3GPP) froze the specifications for a 5G new radio standard at the end of 2017 and is due to freeze another set of 5G specifications, covering some of the core network and non-radio features, in June this year as part of its "Release 15" update.

Manning says that Release 15 considers the network slice selection function (NSSF) and the policy control function (PCF) as potential "consumers" of the NWDAF. "Anything else is open to being a consumer," he says. "We have things like monitoring the status of the load of a network slice, or looking at the behavior of mobile devices if you wanted to make adjustments. You could also look at application performance."

In principle, the NWDAF would be able to make use of any data in the core network. The 3GPP does not plan on standardizing the algorithms that will be used but rather the types of raw information the NWDAF will examine. The format of the analytics information that it produces might also be standardized, says Manning.

Such technical developments might help operators to provide network slices more dynamically on their future 5G networks.

Generally seen as one of the most game-changing aspects of 5G, the technique of network slicing would essentially allow an operator to provide a number of virtual network services over the same physical infrastructure.

For example, an operator could provide very high-speed connectivity for mobile gaming over one slice and a low-latency service for factory automation on another -- both reliant on the same underlying hardware.

However, there is concern that without greater automation operators will have less freedom to innovate through network slicing. "If operators don't automate they will be providing capacity-based slices that are relatively large and static and undifferentiated and certainly not on a per-customer basis," says Caroline Chappell, an analyst with Analysys Mason .

In a Madrid presentation, Chappell said that more granular slicing would require "highly agile end-to-end automation" that takes advantage of progress on software-defined networking and network functions virtualization.

"Slices could be very dynamic and perhaps last for only five minutes," she says. "In the very long term, applications could create their own slices."

Despite the talk of standardization, and signs of good progress within the 3GPP, concern emerged this week in Madrid that standards bodies are not moving quickly enough to address operators' needs.

Caroline Chappell's talk is available here whereas Serge Manning's talk is embedded below:



I am helping CW organise the annual CW TEC conference on the topic The inevitable automation of Next Generation Networks
Communications networks are perhaps the most complex machines on the planet. They use vast amounts of hardware, rely on complex software, and are physically distributed over land, underwater, and in orbit. They increasingly provide essential services that underpin almost every aspect of life. Managing networks and optimising their performance is a vast challenge, and will become many times harder with the advent of 5G. The 4th Annual CW Technology Conference will explore this challenge and how Machine Learning and AI may be applied to build more reliable, secure and better performing networks.

Is the AI community aware of the challenges facing network providers? Are the network operators and providers aware of how the very latest developments in AI may provide solutions? The conference will aim to bridge the gap between AI/ML and communications network communities, making each more aware of the nature and scale of the problems and the potential solutions.

I am hoping to see some of this blog readers at the conference. Looking forward to learning more on this topic amongst others for network automation.

Related Post:

Sunday, 27 May 2018

enhanced Public Warning System (ePWS) in 3GPP Release-16

I wrote about PWS 9 years back here. Since then there has been little chance to PWS until recently. According to 3GPP News:

Additional requirements for an enhanced Public Warning System (ePWS) have been agreed at the recent 3GPP TSG SA#79 meeting, as an update to Technical Specification (TS) 22.268.

3GPP Public Warning Systems were first specified in Release 8, allowing for direct warnings to be sent to mobile users on conventional User Equipment (PWS-UE), capable of displaying a text-based and language-dependent Warning Notification.

Since that time, there has been a growth in the number of mobile devices with little or no user interface - including wrist bands, sensors and cameras – many of which are not able to display Warning Notifications. The recent growth in the number of IoT devices - not used by human users – also highlights the need for an alternative to text based Warning Notifications. If those devices can be made aware of the type of incident (e.g. a fire or flood) in some other way than with a text message, then they may take preventive actions (e.g. lift go to ground floor automatically).

3GPP SA1 delegates also considered how graphical symbols or images can now be used to better disseminate Warning Notifications, specifically aimed at the following categories of users:

  • Users with disabilities who have UEs supporting assistive technologies beyond text assistive technologies; and
  • Users who are not fluent in the language of the Warning Notifications.

Much of the work on enhancing the Public Warning System is set out in the ePWS requirements specification: TS 22.268 (SA1). You should also keep an eye on the 3GPP protocol specifications (CT1, Stage 3 work) in Release 16, covering:

  • Specifying Message Identifiers for ePWS-UE, especially IoT devices that are intended for machine type communications
  • Enabling language-independent content to be included in Warning Notifications

The work on ePWS in TS 22.268 (Release 16) is expected to help manufacturers of User Equipment meet any future regulatory requirements dedicated to such products.


Related Specs:

  • 3GPP TR 22.869: Feasibility study on enhancements of Public Warning System; Stage 1
  • 3GPP TS 22.268: Public Warning System (PWS) requirements - Stage 1 for Public Warning System
  • 3GPP TS 23.041: Technical realization of Cell Broadcast Service (CBS) - CT1 aspects of Stage 3 for Public Warning System 
  • 3GPP TS 29.168: Cell Broadcast Centre interfaces with the Evolved Packet Core; Stage 3 - CT4 aspects of Stage 3 for Public Warning System


Further reading:

Friday, 9 February 2018

Tuesday, 6 February 2018

QUIC - Possibly in 5G, 3GPP Release-16


Over the last year or so, I have heard quite a few discussions and read many articles around why QUIC is so good and why we will replace TCP with QUIC (Quick UDP Internet Connection). One such article talking about QUIC benefits says:

QUIC was initially developed by Google as an alternative transport protocol to shorten the time it takes to set up a connection. Google wanted to take benefits of the work done with SPDY, another protocol developed by Google that became the basis for the HTTP/2 standard, into a transport protocol with faster connection setup time and built-in security. HTTP/2 over TCP multiplexes and pipelines requests over one connection but a single packet loss and retransmission packet causes Head-of-Line Blocking (HOLB) for the resources that were being downloaded in parallel. QUIC overcomes the shortcomings of multiplexed streams by removing HOLB. QUIC was created with HTTP/2 as the primary application protocol and optimizes HTTP/2 semantics.


What makes QUIC interesting is that it is built on top of UDP rather than TCP. As such, the time to get a secure connection running is shorter using QUIC because packet loss in a particular stream does not affect the other streams on the connection. This results in successfully retrieving multiple objects in parallel, even when some packets are lost on a different stream. Since QUIC is implemented in the userspace compared to TCP, which is implemented in the kernel, QUIC allows developers the flexibility of improving congestion control over time, since it can be optimized and better replaced compared to kernel upgrades (for example, apps and browsers update more often than OS updates).

Georg Mayer mentioned about QUIC in a recent discussion with Telecom TV. His interview is embedded below. Jump to 5:25 for QUIC part only

Georg Mayer, 3GPP CT work on 5G from 3GPPlive on Vimeo.

Below are some good references about QUIC in case you want to study further.

Tuesday, 16 January 2018

3GPP-VRIF workshop on Virtual Reality Ecosystem & Standards in 5G

Its been a year since I last posted about Augmented / Virtual Reality Requirements for 5G. The topic of Virtual Reality has since made good progress for 5G. There are 2 technical reports that is looking at VR specifically. They are:

The second one is work in progress though. 

Anyway, back in Dec. 3GPP and Virtual Reality Industry Forum (VRIF) held a workshop on VR Ecosystem & Standards. All the materials, including agenda is available here. The final report is not there yet but I assume that there will be a press release when the report is published.

While there are some interesting presentations, here is what I found interesting:

From presentation by Gordon Castle, Head of Strategy Development, Ericsson





From presentation by Martin Renschler, Senior Director Technology, Qualcomm


For anyone wanting to learn more about 6 degrees of freedom (6- DoF), see this Wikipedia entry. According to the Nokia presentation, Facebook’s marketing people call this “6DOF;” the engineers at MPEG call it “3DOF+.”
XR is 'cross reality', which is any hardware that combines aspects of AR, MR and VR; such as Google Tango.

From presentation by Devon Copley, Former Head of Product, Nokia Ozo VR Platform
Some good stuff in the pres.

From presentation by Youngkwon Lim, Samsung Research America; the presentation provided a link to a recent YouTube video on this presentation. I really liked it so I am embedding that here:



Finally, from presentation by Gilles Teniou, SA4 Vice chairman - Video SWG chairman, 3GPP





You can check and download all the presentations here.

Further Reading:

Sunday, 7 January 2018

Satellites & Non-terrestrial networks (NTN) in 5G


Satellites has been an area of interest of mine for a while as some of you know that I used to work as Satellite Applications & Services Programme manager at techUK. I have written about how I see satellites complementing the mobile networks here and here.

Its good to see that there is some activity in 3GPP going on about satellites & Non-terrestrial networks (NTN) in 5G. While there are some obvious roles that satellites can play (see pic above), the 5G work is looking to cover a lot more topics in details.

3GPP TR 38.913: Study on scenarios and requirements for next generation access technologies looks at 12 different scenarios, the ones relevant to this topic ate Air to ground, Light aircraft and Satellite to terrestrial.
3GPP TR 38.811: Study on New Radio (NR) to support non terrestrial networks (Release 15) covers this topic a bit more in detail. From looking at how satellites and other aerial networks work in general, it looks at the different NTN architecture options as can be seen above.
People looking to study this area in detail should probably start looking at this TR first.

3GPP also released a news item on this topic last week. It also refers to the above TR and a new one for Release 16. The following from 3GPP news:

The roles and benefits of satellites in 5G have been studied in 3GPP Release 14, leading to the specific requirement to support satellite access being captured in TS 22.261 - “Service requirements for next generation new services and markets; Stage 1”, recognizing the added value that satellite coverage brings, as part of the mix of access technologies for 5G, especially for mission critical and industrial applications where ubiquitous coverage is crucial.

Satellites refer to Spaceborne vehicles in Low Earth Orbits (LEO), Medium Earth Orbits (MEO), Geostationary Earth Orbit (GEO) or in Highly Elliptical Orbits (HEO).

Beyond satellites, Non-terrestrial networks (NTN) refer to networks, or segments of networks, using an airborne or spaceborne vehicle for transmission. Airborne vehicles refer to High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) - including tethered UAS, Lighter than Air UAS and Heavier than Air UAS - all operating at altitude; typically between 8 and 50 km, quasi-stationary.

These Non-terrestrial networks feature in TSG RAN’s TR 38.811 “Study on NR to support non-terrestrial networks”. They will:
  • Help foster the 5G service roll out in un-served or underserved areas to upgrade the performance of terrestrial networks
  • Reinforce service reliability by providing service continuity for user equipment or for moving platforms (e.g. passenger vehicles-aircraft, ships, high speed trains, buses)
  • Increase service availability everywhere; especially for critical communications, future railway/maritime/aeronautical communications
  • Enable 5G network scalability through the provision of efficient multicast/broadcast resources for data delivery towards the network edges or even directly to the user equipment

The objective of TR 38.811 is to study channel models, to define the deployment scenarios as well as the related system parameters and to identify and assess potential key impact areas on the NR. In a second phase, solutions for the identified key impacts on RAN protocols/architecture will be evaluated and defined.

A second study item, the “Study on using Satellite Access in 5G” is being addressed in Working Group SA1.  It shall lead to the delivery of the corresponding Technical Report TR 22.822 as part of Release 16.

This study will identify use cases for the provision of services when considering the integration of 5G satellite-based access components in the 5G system. When addressing the integration of (a) satellite component(s), use cases will identify new potential requirements for 5G systems addressing:
  • The associated identification of existing / planned services and the corresponding modified or new requirements
  • The associated identification of new services and the corresponding requirements
  • The requirements on set-up / configuration / maintenance of the features of UE’s when using satellite components related features as well for other components from the 5G system
  • Regulatory requirements when moving to (or from) satellite from (or to) terrestrial networks