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

Wednesday 12 July 2023

Small Data Transmission (SDT) in LTE and 5G NR

One of the features that was introduced part of 5G NR 3GPP Release 17 is known as Small Data Transmission (SDT). When small amount of data, in case of an IoT device, needs to be sent, there is no need to establish data radio bearers. The information can be sent as part of signalling message. A similar approach is available in case of 4G LTE. 

Quoting from Ofinno whitepaper 'Small Data Transmission: PHY/MAC', 

The SDT in the 3GPP simply refers to data transmission in an inactive state. Specifically, the SDT is a transmission for a short data burst in a connectionless state where a device does not need to establish and teardown connections when small amounts of data need to be sent.

In the 3GPP standards, the inactive state had not supported data transmission until Release 15. The 3GPP standards basically allowed the data transmission when ciphering and integrity protection are achieved during the connection establishment procedure. Therefore, the data transmission can occur after the successful completion of the establishment procedure between the device and network.

The problem arises as a device stays in the connected state for a short period of time and subsequently releases the connection once the small size data is sent. Generally, the device needs to perform multiple transmissions and receptions of control signals to initiate and maintain the connection with a network. As a payload size of the data is relatively smaller compared with the amounts of the control signals, making a connection for the small data transmission becomes more of a concern for both the network and the device due to the control signaling overhead.

The 3GPP has developed the SDT procedure to enable data transmission in the inactive state over the existing LTE and NR standards. The device initiates the SDT procedure by transmitting an RRC request message (e.g., SDT request message) and data in parallel instead of transmitting the data after the RRC request message processed by a network. Additional transmission and/or reception are optional. The device performs this SDT procedure without transition to the connected state (i.e., without making a connection to the network).

The SDT enables for the network to accept data transmission without signaling intensive bearer establishment and authentication procedure required for the RRC connection establishment or resume procedure. For example, in the SDT procedure, the device needs only one immediate transmission of a transport block (TB) that contains data and RRC request message. Furthermore, the device does not need to perform procedures (e.g., radio link monitoring) defined in the connected state since the RRC state is kept as the inactive state. This results in improving the battery life of the device by avoiding control signaling unnecessary for transmission of small size data.

The principle of the SDT is very simple. The network configures radio resources beforehand for the data transmission in the inactive state. For example, if the conditions to use the configured radio resources satisfy, the device transmits data and the RRC request message together via the configured radio resources. In the 3GPP standards, there are two types of the SDT depending on the ways to configure the radio resources: (1) SDT using a random access (RA) and (2) SDT using preconfigured radio resources. 

Figure 2 (top) illustrates different types of the SDT referred in 3GPP LTE and NR standards. The SDT using the random access in LTE and NR standards is referred to as an EDT (early data transmission) and RA-SDT (Random Access based SDT), respectively. For both the EDT and the RA-SDT, the device performs data transmission using shared radio resources of the random access procedure. Thus, the contention with other devices can occur over the access to the shared radio resources. The shared radio resources for the SDT are broadcast by system information and are configured as isolated from the one for a nonSDT RA procedure, i.e., the legacy RA procedure. On the other hands, the CG-SDT uses the preconfigured radio resources dedicated to the device. The SDT using the preconfigured radio resource is referred to as transmission via PUR (Preconfigured Uplink Resource) in the LTE standards. The NR standards refers the SDT using the preconfigured radio resource as CG-SDT (Configured Grant based SDT). The network configures the configuration parameters of the preconfigured radio resources when transiting the device in the connected state to the inactive state. For example, an RRC release message transmitted from the network for a connection release contains the configuration parameters of PUR or CG-SDT. No contention is expected for the SDT using the preconfigured radio resource since the configuration parameters are dedicated to the device. 

You can continue reading the details in whitepaper here. Ofinno has another whitepaper on this topic, 'Small Data Transmission (SDT): Protocol Aspects' here.

3GPP also recently published an article on this topic here. Quoting from the article:

With SDT it is possible for the device to send small amounts of data while remaining in the inactive state. Note that this idea resembles the early GSM systems where SMS messages where sent via the control signalling; that is, transferring small amounts of data while the mobile did not have a (voice) connection.

SDT is a procedure which allows data and/or signalling transmission while the device remains in inactive state without transitioning to connected state. SDT is enabled on a radio bearer basis and is initiated by the UE only if less than a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled. Otherwise the normal data transmission scheme is used.

With SDT the data is transmitted quickly on the allocated resource. The IoT device initiates the SDT procedure by transmitting an RRC request message and payload data in parallel, instead of the usual procedure where the data is transmitted after the RRC request message is processed by a network.

It is not only the speed and the reduced size of the transmitted data which make SDT such a suitable process for IoT devices. Since the device stays in the inactive state, it does not have to perform many tasks associated with the active state. This further improves the battery life of the IoT device. Additional transmission and/or reception are optional.

There are two ways of performing SDT:

  1. via random access (RA-SDT)
  2. via preconfigured radio resources (CG-SDT)

Random Access SDT

With RA-SDT, the IoT device does not have a dedicated radio resource, and it is possible that the random access message clashes with similar RA-SDT random access messages from other IoT devices. The device gets to know the radio resources for the RA procedure from system information messages, in a similar way to non RA-SDT devices. However, the RA radio resources for SDT and non SDT devices are kept separate; that is, these device types do not interfere with each other in random access

The RA-SDT procedure can be a two-step or a four-step random access procedure. In two-step procedure the payload data is already sent with the initial random access message, whereas in four-step procedure the device first performs contention resolution with the random access request - random access response message pair, and then sends the UL payload with RRC Resume Request. The procedure may continue with further uplink and downlink small data transmissions, and then it is terminated with an RRC Release from the network.

Below are the signalling diagrams for both two-step and four-step RA-SDT procedures. Note that in both cases the UE stays in the RRC inactive state during the whole process.

Configured Grant SDT

For CG-SDT, the radio resources are allocated periodically based on the estimation of the UE’s traffic requirements. This uplink scheduling method is called Configured Grant (CG). With CG-SDT there will be no message clashes with other IoT devices since the radio resources are dedicated for each device. The resource allocation is signalled to the IoT device by the network when the device leaves the connected state.

If the amount of data in the UE's tx buffer is larger than a defined limit, then the data transmission is done using the normal non-SDT procedure.

For SDT process, the device selects the CG-SDT as the SDT type if the resources for the CG-SDT are configured on the selected uplink carrier. If the resources for the CG-SDT are unavailable or invalid, the RA-SDT or the non-SDT RA procedure will be chosen if those are configured. If no SDT type configuration is available then a normal non-SDT data transmission is performed.

With IoT devices proliferating, it makes sense to optimise data transfer and anything else that will reduce the power consumption and let the battery in the devices last for much longer.

Related Posts

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

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:

Wednesday 10 March 2021

Everything you need to know about 5G Security

5G & Security are both big topics on this blog as well as on 3G4G website. We reached out to 3GPP 5G security by experts from wenovator, Dr. Anand R. Prasad & Hans Christian Rudolph to help out audience understand the mysteries of 5G security. Embedded below is video and slides from a webinar they recorded for us.

You can ask any security questions you may have on the video on YouTube

The slides could be downloaded from SlideShare.

Related Posts:

Tuesday 17 November 2020

5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD

Earlier this year, MediaTek had announced that its MT2625 NB-IoT chip has been validated for LwM2M over NIDD on SoftBank Corp.’s cellular network across Japan. This achievement marks the first global commercial readiness of LwM2M over NIDD; a secure, ultra-efficient IoT communications technique that is being adopted by operators worldwide. The benefits of LwM2M over NIDD include security improvements, cost-efficient scalability and reduced power consumption.

LwM2M over NIDD is a combination of the communication technology "NIDD (Non-IP Data Delivery)" that does not use an IP address in LTE communication NB-IoT for IoT and the device management protocol "LwM2M (Lightweight M2M)" advocated by the Open Mobile Alliance. It's been a while since I wrote about Open Mobile Alliance on this blog. OMA SpecWorks is the successor brand to the Open Mobile Alliance. You can read all about it here.

OMA SpecWorks’ LightweightM2M is a device management protocol designed for sensor networks and the demands of a machine-to-machine (M2M) environment. With LwM2M, OMA  SpecWorks has responded to demand in the market for a common standard for managing lightweight and low power devices on a variety of networks necessary to realize the potential of IoT. The LwM2M protocol, designed for remote management of M2M devices and related service enablement, features a modern architectural design based on REST, defines an extensible resource and data model and builds on an efficient secure data transfer standard called the Constrained Application Protocol (CoAP). LwM2M has been specified by a group of industry experts at the OMA SpecWorks Device Management Working Group and is based on protocol and security standards from the IETF.

You can get all the LwM2M resources here and the basic specs of 'Lightweight M2M 1.1: Managing Non-IP Devices in Cellular IoT Networks' here.
The 5G Americas whitepaper 'Wireless Technology Evolution Towards 5G: 3GPP Release 13 to Release 15 and Beyond' details how Current Architecture for 3GPP Systems for IOT Service Provision and Connectivity to External Application Servers. It also talks about Rel-13 Cellular IoT EPS Optimizations which provide improved support of small data transfer over control plane and user plane. Control Plane CIoT EPS Optimization transports user data (measurements, ID, status, etc.) via MME by encapsulating user data in NAS PDUs and reduces the total number of control plane messages when handling a short data transaction. Control Plane CIoT EPS optimization, designed for small infrequent data packets, can also be used for larger data bursts depending in UE Radio capability.

User data transported using the Control Plane CIoT EPS Optimization, has special characteristics, as different mobility anchor and termination nodes.

Therefore, the Preferred Network Behavior signaling must include information on:
  • Whether Control Plane CIoT EPS optimization is supported
  • Whether User Plane CIoT EPS optimization is supported
  • Whether Control Plane CIoT EPS optimization is preferred or whether User Plane CIoT EPS optimization is preferred
These optimizations have enabled:
  • Non-IP Data Delivery (NIDD) for both: mobile originated and mobile terminated communications, by using SCEF (Service Capability Exposure Function) or SGi tunneling. However, it has to be taken into account that Non-IP PDUs may be lost and its sequence is not guaranteed
  • For IP data, the UE and MME may perform header compression based on Robust Header Compression (ROHC) framework
  • NB-IoT UE can attach but not activate any PDN connection
  • High latency communication handled by the buffering of downlink data (in the Serving GW or the MME)
  • SMS transfer
  • EPS Attach, TA Update and EPS Detach procedures for NB-IoT only UEs, with SMS service request
  • Procedures for connection suspend and resume are added
  • Support for transfer of user plane data without the need for using the Service Request procedure to establish Access Stratum context in the serving eNodeB and UE
When selecting an MME for a UE that is using the NB-IoT RAT, and/or for a UE that signals support for CIoT EPS Optimizations in RRC signaling, the eNodeB’s MME selection algorithm shall select an MME taking into account its Release 13 NAS signaling protocol.

Mpirical has a nice short video explaining 5G Non IP Data Delivery. It is embedded below.

IoT has not taken off as expected and prophesised for years. While the OMASpecWorks is doing some fantastic work by defining simplified approach for IoT deployment, its current member list doesn't have enough operators to drive the uptake required for its spec adoption. They would argue that it doesn't matter how many members there are as the NIDD approach is completely optional and over-the-top. Let's wait and see how it progresses.

Related Posts:

Sunday 20 September 2020

Reliance Jio and 5G Network Architecture Option 6

Last week I read about Jio looking at 5G Network Architecture Option 6. There were also a few discussions on Twitter with users sounding a bit confused. So here is my attempt to explain what is Option 6. Video and slides embedded below. 

You can also see this original video where Satish Jamadagni, Vice President - Network Planning Engineering, Head of Standards at Reliance Jio talks about the need for Option 6. 

Feel free to leave your thoughts in the comments below.

Related Posts:

Sunday 12 July 2020

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

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

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

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

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

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

Release 16 - RAN progress from 3GPPlive on Vimeo.

Related Posts:

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:

Sunday 27 October 2019

R&S Webinar on LTE-A Pro and evolution to 5G

Rohde & Schwarz recently uploaded a webinar video on their YouTube channel. I found it really useful. It's embedded below.

Topics covered:

  • LTE-M / NB-IoT
    • feMTC
    • UE Category M2
    • OTDOA based positioning
  • UE Categories
  • Unlicensed Spectrum Overview
  • LTE in Unlicensed Spectrum
    • LWA, LWIP
    • LAA, eLAA
    • Wi-Fi
    • LBT
    • LWA mobility
  • Carrier Aggregation Enhancements
  • Multi-user superposition transmission (MUST)
  • Single cell - point to multipoint transmission (SC-PTM)
    • SC-PTM Channel Structure
    • SC-PTM Channel Flow
  • Massive MIMO
  • V2X Overview
    • eNB scheduling - transmission mode 3
    • Distributed scheduling - transmission mode 4
    • Direct communication
  • LTE Advanced Pro (Release 15)
    • Further NB-IoT Enhancements
    • Even further enhanced MTC - eMTC4 (Rel-15)

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:

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:

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:

Monday 24 September 2018

5G New Radio Standards and other Presentations

A recent Cambridge Wireless event 'Radio technology for 5G – making it work' was an excellent event where all speakers delivered an interesting and insightful presentation. These presentations are all available to view and download for everyone for a limited time here.

I blogged about the base station antennas last week but there are other couple of presentations that stood out for me.

The first was an excellent presentation from Sylvia Lu from u-Blox, also my fellow CW Board Member. Her talk covered variety of topics including IoT, IIoT, LTE-V2X and Cellular positioning, including 5G NR Positioning Trend. The presentation is embedded below and available to download from Slideshare

The other presentation on 5G NR was one from Yinan Qi of Samsung R&D. His presentation looked at variety of topics, mainly Layer 1 including Massive MIMO, Beamforming, Beam Management, Bandwidth Part, Reference Signals, Phase noise, etc. His presentation is embedded below and can be downloaded from SlideShare.

Related Posts:

Thursday 12 July 2018

Minimum Bandwidth Requirement for 5G Non-Standalone (NSA) Deployment

I was attending the IEEE 5G World Forum live-stream, courtesy of IEEE Tv and happen to hear Egil Gronstad, Senior Director of Technology Development and Strategy at T-Mobile USA. He said that they will be building a nationwide 5G network that will initially be based on 600 MHz band.

During the Q&A, Egil mentioned that because of the way the USA has different markets, on average they have 31 MHz of 600 MHz (Band 71). The minimum is 20 MHz and the maximum is 50 MHz.

So I started wondering how would they launch 4G & 5G in the same band for nationwide coverage? They have a good video on their 5G vision but that is of course probably going to come few years down the line.

In simple terms, they will first deploy what is known as Option 3 or EN-DC. If you want a quick refresher on different options, you may want to jump to my tutorial on this topic at 3G4G here.

The Master Node (recall dual connectivity for LTE, Release-12. See here) is an eNodeB. As with any LTE node, it can take bandwidths from 1.4 MHz to 20 MHz. So the minimum bandwidth for LTE node is 1.4 MHz.

The Secondary Node is a gNodeB. Looking at 3GPP TS 38.101-1, Table 5.3.5-1 Channel bandwidths for each NR band, I can see that for band 71

NR band / SCS / UE Channel bandwidth
NR Band
5 MHz
101,2 MHz
152 MHz
202 MHz
252 MHz
30 MHz
40 MHz
50 MHz
60 MHz
80 MHz
90 MHz
100 MHz




The minimum bandwidth is 5MHz. Of course this is paired spectrum for FDD band but the point I am making here is that you need just 6.4 MHz minimum to be able to support the Non-Standalone 5G option.

I am sure you can guess that the speeds will not really be 5G speeds with this amount of bandwidth but I am looking forward to all these kind of complaints in the initial phase of 5G network rollout.

I dont know what bandwidths T-Mobile will be using but we will see at least 10MHz of NR in case where the total spectrum is 20 MHz and 20 MHz of NR where the total spectrum is 50 MHz.

If you look at the earlier requirements list, the number being thrown about for bandwidth was 100 MHz for below 6 GHz and up to 1 GHz bandwidth for spectrum above 6 GHz. Don't think there was a hard and fast requirement though.

Happy to hear your thoughts.

Friday 9 February 2018