Today I launched my first video. It is about the 3GPP Minimization of Drive Test (MDT) and what is new for this feature in Rel. 16 / 5G networks.
This video explains the overall concept of the MDT feature defined by 3GPP. Individual signaling procedures for immediate and logged mode MDT reporting are presented as well as the latest enhancements for 5G networks defined in 3GPP Release 16.
I have been thinking about the long term evolution of 5G and have now reached the conclusion that it would make sense in the long run to switch off non-standalone 5G. This would of course be only after 5G core has been tested and used extensively. Instead of writing my reasoning, here is a 10 minute video and the corresponding slides.
Mobile Initiated Connection Only (MICO) mode is designed for IoT devices that send small amounts of data and do not need to be paged. An example of this could be a smart bin that sends a message to the waste collection company saying it is 50% full, etc. This way the bin emptying lorry can plan to empty it in the next collection round. Here there is no reason to page the bin as there is no mobile terminated data that would be required.
MICO mode has to be negotiated between the device and AMF in 5GC. A device in MICO mode cannot be paged as it would not listen to paging to conserve battery power. This extreme power saving mode can ensure that the battery can last for very long time, ideally years thereby making this vision of billions of connected IoT devices a reality.
In an earlier post on RRC Inactive state, we looked at NAS states, along with RRC states. When the UE is in MICO mode, the AMF in 5GC will consider the UE to be unreachable when it is in CM-IDLE state. In addition, a periodic registration timer is also allocated to the MICO mode UEs. The UE has to confirm the MICO mode again during registration update.
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.
We have been meaning to make a tutorial on augmented reality (AR), virtual reality (VR), mixed reality (MR) and extended reality (XR) for a while but we have only managed to do it. Embedded below is video and slides for the tutorial and also a playlist of different use cases on XR from around the world.
If you are not familiar with the 5G Service Based Architecture (SBA) and 5G Core (5GC), best to check this earlier tutorial before going further. A lot of comments are generally around Wi-Fi instead of 5G being used for indoors and we completely agree. 3GPP 5G architecture is designed to cater for any access in addition to 5G access. We have explained it here and here. This guest post also nicely explains Network Convergence of Mobile, Broadband and Wi-Fi.
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:
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.
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).
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)
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
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:
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...
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:
We recently made a new video looking at how 5G architecture caters for Trusted and Untrusted Wireless Access as well as Wireline Access. The presentation discusses:
Untrusted non-3GPP access networks;
Trusted non-3GPP access networks (TNAN);
Wireline access networks;
Non-5G-Capable over WLAN (N5CW);
Access Traffic Steering, Switching and Splitting (ATSSS)
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
#eMBMS
- 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 eMBMShttps://t.co/EjjOH1tQxypic.twitter.com/Gcc35BFC8H
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.
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.
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.
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
We made a tutorial some time back explaining how to calculate reliability and what is the difference between 5x9s in 3GPP Release-15 5G vs 6x9s in 3GPP Release-16. Slides and video below
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:
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:
1The 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. 2For 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. 35GS Network Functions and OAM decide how to use the data analytics provided by NWDAF to improve the network performance. 4NWDAF utilizes the existing service based interfaces to communicate with other 5GC Network Functions and OAM. 5A 5GC NF may expose the result of the data analytics to any consumer NF utilizing a service based interface. 6The interactions between NF(s) and the NWDAF take place in the local PLMN (the reporting NF and the NWDAF belong to the same PLMN). 7Solutions shall neither assume NWDAF knowledge about NF application logic. The NWDAF may use subscription data but only for statistical purpose.
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.
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:
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.
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
