I did a presentation back in 2013 on the concept of smart batteries. Even though there has been a lot of progress in wireless charging since back then, it hasn't reached even close to the vision that I have. As a result, I converted it into a video to start a discussion on if and when this would be possible. The slides and video are embedded below and I welcome any discussion in comments below.
Friday, 1 May 2020
The Futuristic Concept of 'Smart & Intelligent' Batteries
I did a presentation back in 2013 on the concept of smart batteries. Even though there has been a lot of progress in wireless charging since back then, it hasn't reached even close to the vision that I have. As a result, I converted it into a video to start a discussion on if and when this would be possible. The slides and video are embedded below and I welcome any discussion in comments below.
Tuesday, 28 April 2020
Comparing S1AP and NGAP UE Context Release
As an addition to my blog post about the 5G RAN Release procedure I would like to have an in-depth view at the details of NGAP UE Context Release Complete message.
Indeed, the S1AP (known from E-UTRAN) and the NGAP are very similar protocols and when reading the 3GPP specs it is obvious that many message names are identical and the procedures fulfill the same purpose when looking at call scenarios.
However, the difference is visible in the details as one can see when looking at the figure below.
While the S1AP UE Context Release Complete message does not contain any additional information we find in the NGAP UE Context Release Complete the identity of the last serving 5G cell, represented by the NR-CGI, the last visited Tracking Area Identity (TAI) and a list with the IDs of the PDU sessions (E-RABs) that have been terminated when the UE context was released.
This additional information in very valuable for network troubleshooting, since in LTE (S1AP) only the ID (ECGI) of the initial serving cell or a new serving cell ID at inter-node handover was signaled. And if you wanted to know how many E-RABs have been terminated with a S1AP UE Context Release procedure it was necessary to look back into the full sequence of call-related S1AP messages starting with the messages for Initial Context Setup.
All in all, with 5G NGAP trace analysis and the life of RAN engineers becomes easier. Thank you, 3GPP!
Comparision of S1AP and NGAP UE Context Release Complete Messages |
Labels:
3GPP,
NGAP,
S1AP,
Signalling
Friday, 24 April 2020
A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend
The 3rd post of this series introduces the details of connection release in the 5G RAN.
Indeed, we find most of the release causes known from E-UTRAN in the 5G specs and it is clear that all protocols that have been involved in the connection setup need to be perform a release procedure at the end of the connection.
However, again the split into different virtual functions brings the demand for some addition messages.
This is illustrated in figure 1 for the a release due to "user inactivity", which means: the gNB-CU UP detected that for a define time (typical settings for the user inactivity timer are expected to be between 10 and 20 seconds) no downlink payload packets have been arrived from the UPF to be transmitted.
So the gNB-CU UP sends an E1AP Bearer Context Inactivity Notification message to the gNB-CU CP that triggers the release procedures on NGAP, F1AP, RRC and E1AP. The RRC Releases message is transported over the F1 interface to the gNB-DU where is forwarded across the radio interface to the UE.
An alternative to the connection release is the RRC Suspend procedure shown in figure 2. Here the UE is ordered to switch to the RRC Inactive state, which allows a very quick resume of the RRC connection when necessary.
In case of suspending the RRC connection the RRC Release message contains a set of suspend configuration parameters. The probably most important one is the I-RNTI, the (RRC) Inactive Radio Network Temporary Identity.
If the RRC connection is suspended, F1AP and E1AP Contexts are released, but the NGAP UE Context remains active. Just NGAP RRC Inactivity Transition Report is sent to the AMF.
Related Posts:
Indeed, we find most of the release causes known from E-UTRAN in the 5G specs and it is clear that all protocols that have been involved in the connection setup need to be perform a release procedure at the end of the connection.
However, again the split into different virtual functions brings the demand for some addition messages.
This is illustrated in figure 1 for the a release due to "user inactivity", which means: the gNB-CU UP detected that for a define time (typical settings for the user inactivity timer are expected to be between 10 and 20 seconds) no downlink payload packets have been arrived from the UPF to be transmitted.
So the gNB-CU UP sends an E1AP Bearer Context Inactivity Notification message to the gNB-CU CP that triggers the release procedures on NGAP, F1AP, RRC and E1AP. The RRC Releases message is transported over the F1 interface to the gNB-DU where is forwarded across the radio interface to the UE.
Figure 1: Connection Release due to "user inacativity" |
Figure 2: RRC Connection Suspend |
In case of suspending the RRC connection the RRC Release message contains a set of suspend configuration parameters. The probably most important one is the I-RNTI, the (RRC) Inactive Radio Network Temporary Identity.
If the RRC connection is suspended, F1AP and E1AP Contexts are released, but the NGAP UE Context remains active. Just NGAP RRC Inactivity Transition Report is sent to the AMF.
Related Posts:
Labels:
Connection Release,
E1AP,
F1AP,
NGAP,
Open RAN,
RRC,
RRC Inactive State,
Signalling,
vRAN
Monday, 20 April 2020
A Look at the same RRC Message in LTE and 5G Stand-alone Call Scenarios
Some weeks ago the differences in 4G LTE RRC (3GPP 36.331) and 5G NR RRC (3GPP 38.331) and how both protocols interact in EN-DC call scenarios have been discussed in another blog post.
Now I would like to share a visual comparison of the RRC (Connection) Setup Complete message as it is seen in LTE (including EN-DC) and 5G stand-alone (SA) radio connections.
From the figure below one can see that although this message fulfills the same purpose in both radio access technologies its particular contents may look quite differently.
Different variants of RRC (Connection) Setup Complete message in LTE and 5G stand-alone call scenarios |
Sunday, 19 April 2020
SCF Releases 5G Functional API to Enable Open Small Cells Ecosystem
The Small Cell Forum (SCF) announced the publication of documents focused on stimulating a competitive ecosystem for vendors of 5G-era small cell hardware, software and equipment. The expanded set of specifications contained in these documents are:
- SCF222 - 5G FAPI: PHY API Specification
- SCF223 - 5G FAPI: RF and Digital Frontend Control API
- SCF224 - 5G FAPI: Network Monitor Mode API
Expanding upon the 5G Physical Layer API specification, published in July 2019, the new specifications enable small cells to be constructed piece-by-piece using components from different vendors, in order to address the diverse mixture of 5G use cases relatively easily, a common goal to all of the specifications made by Small Cell Forum.
The new release also includes two completely new specifications, SCF223: 5G NR FAPI P19 FrontEnd Interface Specification and SCF224: Network Monitor Mode API for Small Cells.
According to Dr. Prabhakar Chitrapu, Chair of SCF, “FAPI helps Equipment Vendors to mix PHY & MAC Software from different suppliers via this open FAPI interface. So, FAPI is an 'internal' interface.”
“5G-nFAPI (network FAPI) is a 'network' interface and is between a Distributed Unit and Centralised Unit of a Split RAN/Small Cell network solution. An open specification of this interface (nFAPI) will help network architects by allowing them to mix distributed and central units from different vendors.”
SCF nFAPI is enabling Open RAN ecosystem in its own way by allowing any small cell CU/DU (S-CU / S-DU) to connect to any small cell radio unit (S-RU)
Here is a video playlist from SCF that explains the new API's
Related Posts:
- Telecoms Infrastructure Blog: Small Cell Forum Releases 5G FAPI API Specifications
- The 3G4G Blog: A quick tutorial on Open RAN, vRAN & White Box RAN
- Telecoms Infrastructure Blog: SuperMicro's 5G Pole-Mounted DU Server Solution
Labels:
5G,
APIs,
Open RAN,
Small Cell Forum,
Small Cells,
Videos
Tuesday, 14 April 2020
Mobility Analysis: Austrians Stay at Home
The Austrian company Invenium Data Insights GmbH has partnered with the mobile network operator A1 to analyze and visualize subscriber mobility pattern on a public dashboard to illustrate the impact of the severe restrictions on people’s mobility (and its expected reversal) due to the COVID-19 pandemic.
In a side note (in the screenshot highlighted in yellow) and in their blog the partners guarantee that the underlying data is fully anonymous and not derived from customer data. This was certified by TüV, an independent Technical Inspection Association.
Although I have no insight into this particular project I assume that the underlying raw data is provided by eNBs using the 3GPP-defined maximum detail level cell trace according to 3GPP 32.423.
This means that the trace collection entity gets the full ASN.1 contents of all RRC, S1AP and X2AP messages, but NAS messages - if provided at all - are encrypted. Also the eNB has not insight into any user plane applications since it has no means to decode the IP payload. This guarantees that neither IMSI, IMEI, web addresses nor phone numbers are found in the raw data.
The key for a meaningful mobility analysis using this data might be the fact that the S-TMSI value in E-UTRAN rarely changes and due to user inactivity settings each subscriber generates multiple RRC connections per hour. Within these RRC connections we find RRC Measurement Reports and typically also some vendor-specific events providing other important radio parameters from the radio interface lower layers including uplink radio quality measurements like PUSCH SINR.
By looking at multiple RRC connections of the same S-TMSI and the reported air interface measurements it is possible to determine if the subscriber remains at the same place or moves around. It it also possible to determine if a subscriber is located indoor or outdoor.
The trace collection entity writes the analysis results into a comprehensive data set that can be used to mask and scramble even S-TMSI values for additional data privacy. The raw data is deleted.
At the end this methodology allows a highly reliable mobility analysis while simultaneously protecting the data privacy of subscribers. The key difference in comparison to statistics based on crowd-sourced data as published e.g. by umlaut is the fact that the 3GPP cell trace provides data for all RRC connections in the network while crowd-sourced data collection requires the installation of certain apps (in case of umlaut only Android apps are supported) and the subscriber's confirmation to collect the data.
However, it must be mentioned that the 3GPP cell trace cannot be used as a data source for the widely discussed Corona contact tracking apps that allow to identify subscribers that have been in close proximity with someone who has been tested positive for COVID-19. For this purpose cell trace data lacks the necessary accuracy to determine the subscriber's and its neighbor's positions.
Screenshot of the public dashboard (click picture to enlarge) |
In a side note (in the screenshot highlighted in yellow) and in their blog the partners guarantee that the underlying data is fully anonymous and not derived from customer data. This was certified by TüV, an independent Technical Inspection Association.
Although I have no insight into this particular project I assume that the underlying raw data is provided by eNBs using the 3GPP-defined maximum detail level cell trace according to 3GPP 32.423.
This means that the trace collection entity gets the full ASN.1 contents of all RRC, S1AP and X2AP messages, but NAS messages - if provided at all - are encrypted. Also the eNB has not insight into any user plane applications since it has no means to decode the IP payload. This guarantees that neither IMSI, IMEI, web addresses nor phone numbers are found in the raw data.
The key for a meaningful mobility analysis using this data might be the fact that the S-TMSI value in E-UTRAN rarely changes and due to user inactivity settings each subscriber generates multiple RRC connections per hour. Within these RRC connections we find RRC Measurement Reports and typically also some vendor-specific events providing other important radio parameters from the radio interface lower layers including uplink radio quality measurements like PUSCH SINR.
By looking at multiple RRC connections of the same S-TMSI and the reported air interface measurements it is possible to determine if the subscriber remains at the same place or moves around. It it also possible to determine if a subscriber is located indoor or outdoor.
The trace collection entity writes the analysis results into a comprehensive data set that can be used to mask and scramble even S-TMSI values for additional data privacy. The raw data is deleted.
At the end this methodology allows a highly reliable mobility analysis while simultaneously protecting the data privacy of subscribers. The key difference in comparison to statistics based on crowd-sourced data as published e.g. by umlaut is the fact that the 3GPP cell trace provides data for all RRC connections in the network while crowd-sourced data collection requires the installation of certain apps (in case of umlaut only Android apps are supported) and the subscriber's confirmation to collect the data.
However, it must be mentioned that the 3GPP cell trace cannot be used as a data source for the widely discussed Corona contact tracking apps that allow to identify subscribers that have been in close proximity with someone who has been tested positive for COVID-19. For this purpose cell trace data lacks the necessary accuracy to determine the subscriber's and its neighbor's positions.
Labels:
3GPP,
Austria,
cell trace,
COVID-19,
RRC
Sunday, 12 April 2020
Spectrum for 5G NR beyond 52.6 GHz
3GPP TR 38.807: Study on requirements for NR beyond 52.6 GHz has recently been revised with all the new information post WRC-19. There is a section that details potential use cases for this new spectrum.
Quoting from the specs:
The relatively underutilized millimeter-wave (mmWave) spectrum offers excellent opportunities to provide high speed data rate, low latency, and high capacity due to the enormous amount of available contiguous bandwidth. However, operation on bands in frequencies above 52.6GHz will be limited by the performance of devices, for example, poor power amplifier (PA) efficiency and larger phase noise impairment, the increased front-end insertion loss together with the low noise amplifier (LNA) and analog-to-digital converter (ADC) noise. In addition, bands in frequencies above 52.6GHz have high propagation and penetration losses challenge. Even so, various use cases are envisioned for NR operating in frequencies between 52.6GHz and 114.25GHz. Some of the use cases are illustrated in Figure 5.1-1 and following section provide detailed description of the uses cases. It should be noted that there is not a 1-to-1 mapping of use cases and wireless interfaces, e.g. Uu, slidelink, etc. Various wireless interfaces could be applicable to various uses cases described.
There is quite detailed information for each use case in the document that I am not detailing here.
It also details information on the allocation within the frequency range 52.6 GHz to 116 GHz in ITU Radio Regulation (see table below). The column with comments contains (a subset of) information on protection requirements for incumbent services. For the full details please refer to the Radio Regulations.
Quoting from the specs:
Within the range 52.6 to 116 GHz, the frequency bands 66-76 GHz (including 66-71 and 71-76 GHz) and 81-86 GHz are being studied under WRC-19 Agenda Item 1.13 for potential IMT identification. Results of sharing and compatibility studies, potential technical and regulatory conditions are included in Draft CPM Report, and the final decisions are to be made in WRC-19 with respect to IMT identification or no IMT identification, along with the corresponding technical and regulatory conditions.
For 66-71 GHz, Studies were carried out for the ISS, MSS (Earth-to-space) indicating that sharing is feasible, with a need for separation distance in the order of few kilometers for the case of MSS (space-to-Earth). The need for studies addressing interference from IMT towards RNS is still under debate. Thus, final conclusions in the regulatory and technical conditions for this band cannot be drawn.
For 71-76 GHz, studies were carried out for the FS, RLS and FSS (space-to-Earth) indicating that sharing with FS and FSS is feasible. However, additional limits of the IMT BS and UE unwanted emissions is needed to protect RLS in the adjacent frequency band 76-81 GHz.
For 81-86 GHz, studies were carried out for the FS, FSS (Earth-to-space), RAS (in band and adjacent band), EESS (passive) and RLS. Studies are not needed for the SRS (passive), as this service is dealing with sensors around other planets and no interference issue is expected. Studies were also not carried out for the MSS. The results of those studies indicate that sharing with FS, FSS and RAS (in band and adjacent band) is feasible. Notice that additional limits of the IMT BS and UE unwanted emissions would be needed to ensure protection of EESS (passive) in the adjacent frequency band 76-81 GHz and RLS in the adjacent frequency band 86-82 GHz.
An interesting paper looking at Waveforms, Numerology, and Phase Noise Challenge for Mobile Communications Beyond 52.6 GHz is available here.
Related Posts:
New spectrum above 52.6 GHz – Potential use cases and deployment scenarios from a presentation by Kari Pajukoski, Oskari Tervo and Jari Hulkkonen, Nokia at the #6GSummit https://t.co/BqYPK7xpcz #Free5GTraining pic.twitter.com/6gqz0jCL3A— 5G Training (@5Gtraining) January 16, 2020
Quoting from the specs:
The relatively underutilized millimeter-wave (mmWave) spectrum offers excellent opportunities to provide high speed data rate, low latency, and high capacity due to the enormous amount of available contiguous bandwidth. However, operation on bands in frequencies above 52.6GHz will be limited by the performance of devices, for example, poor power amplifier (PA) efficiency and larger phase noise impairment, the increased front-end insertion loss together with the low noise amplifier (LNA) and analog-to-digital converter (ADC) noise. In addition, bands in frequencies above 52.6GHz have high propagation and penetration losses challenge. Even so, various use cases are envisioned for NR operating in frequencies between 52.6GHz and 114.25GHz. Some of the use cases are illustrated in Figure 5.1-1 and following section provide detailed description of the uses cases. It should be noted that there is not a 1-to-1 mapping of use cases and wireless interfaces, e.g. Uu, slidelink, etc. Various wireless interfaces could be applicable to various uses cases described.
- High data rate eMBB
- Mobile data offloading
- Short-range high-data rate D2D communications
- Vertical industry factory application
- Broadband distribution network
- Integrated access backhaul (IAB)
- Factory automation/Industrial IoT (IIoT)
- Augmented reality/virtual reality headsets and other high-end wearables
- Intelligent Transport Systems (ITS) and V2X
- Data Center Inter-rack Connectivity
- Smart grid automation
- Radar/Positioning
- Private Networks
- Critical medical communication
There is quite detailed information for each use case in the document that I am not detailing here.
Getting ready for our 5G training next week - https://t.co/6YXW3YlDvD - this picture summarises the 5G mmWave frequency proposals pre #WRC15, approved for study at WRC-15 and available for IMT post #WRC19#3G4G5G #CWTechTrain #5G #Spectrum #5GTraining @cambwireless @UK_5G pic.twitter.com/KoWEpD89Pz— 3G4G (@3g4gUK) March 3, 2020
It also details information on the allocation within the frequency range 52.6 GHz to 116 GHz in ITU Radio Regulation (see table below). The column with comments contains (a subset of) information on protection requirements for incumbent services. For the full details please refer to the Radio Regulations.
Quoting from the specs:
Within the range 52.6 to 116 GHz, the frequency bands 66-76 GHz (including 66-71 and 71-76 GHz) and 81-86 GHz are being studied under WRC-19 Agenda Item 1.13 for potential IMT identification. Results of sharing and compatibility studies, potential technical and regulatory conditions are included in Draft CPM Report, and the final decisions are to be made in WRC-19 with respect to IMT identification or no IMT identification, along with the corresponding technical and regulatory conditions.
For 66-71 GHz, Studies were carried out for the ISS, MSS (Earth-to-space) indicating that sharing is feasible, with a need for separation distance in the order of few kilometers for the case of MSS (space-to-Earth). The need for studies addressing interference from IMT towards RNS is still under debate. Thus, final conclusions in the regulatory and technical conditions for this band cannot be drawn.
For 71-76 GHz, studies were carried out for the FS, RLS and FSS (space-to-Earth) indicating that sharing with FS and FSS is feasible. However, additional limits of the IMT BS and UE unwanted emissions is needed to protect RLS in the adjacent frequency band 76-81 GHz.
For 81-86 GHz, studies were carried out for the FS, FSS (Earth-to-space), RAS (in band and adjacent band), EESS (passive) and RLS. Studies are not needed for the SRS (passive), as this service is dealing with sensors around other planets and no interference issue is expected. Studies were also not carried out for the MSS. The results of those studies indicate that sharing with FS, FSS and RAS (in band and adjacent band) is feasible. Notice that additional limits of the IMT BS and UE unwanted emissions would be needed to ensure protection of EESS (passive) in the adjacent frequency band 76-81 GHz and RLS in the adjacent frequency band 86-82 GHz.
An interesting paper looking at Waveforms, Numerology, and Phase Noise Challenge for Mobile Communications Beyond 52.6 GHz is available here.
Related Posts:
- The 3G4G Blog: Examples of 5G Use Cases & Applications
- The 3G4G Blog: 5G Private and Non-Public Network (NPN)
- The 3G4G Blog: 5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17
- The 3G4G Blog: What is Industrial IoT (IIoT) and how is it different from IoT?
- The 3G4G Blog: 5G and Industry 4.0
- Connectivity Technology Blog: 5G Indoor Precise Positioning
- The 3G4G Blog: 5G eXtended Reality (5G-XR) in 5G System (5GS)
Saturday, 4 April 2020
5G eXtended Reality (5G-XR) in 5G System (5GS)
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.
XR use cases playlist
A lot of info on this topic is from Qualcomm, GSMA, 3GPP and 5G Americas whitepaper, all of them in the links in the slides.
Related Posts:
- The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
- The 3G4G Blog: 5G and Fixed-Mobile Convergence (FMC)
- The 3G4G Blog: Introduction to 5G ATSSS - Access Traffic Steering, Switching and Splitting
- Guest Post by Ben Toner - Exploring Network Convergence of Mobile, Broadband and Wi-Fi
- Connectivity Technology Blog: 5G Indoor Precise Positioning
- Operator Watch Blog: NTT Docomo presentation on 5G Launch Plans and Use Cases Solutions Partnership
- 3G4G: 3GPP 5G Specifications
- 3G4G: 5G (IMT-2020) Wireless
Labels:
3GPP,
5G,
5G Americas,
AR / VR / MR / XR,
Future Technologies,
GSMA,
Network Architecture,
Qualcomm,
Release 16,
Use Cases
Wednesday, 1 April 2020
A Look into 5G Virtual/Open RAN - Part 2
In the first blog post of this series the different virtual RAN functions, interfaces and protocols have been discussed. Now it is time to have a look at a set of procedures that are required for the establishment of an UE connection in virtual 5G RAN.
When looking at the 5G RAN there are two of such tunnels: one on NG-U (aka N3) that is controlled by NGAP, and one on F1-U that is controlled by F1AP - see figure 1.
On behalf of these two tunnels payload data can be transported between the 5G core network User Plane Function (UPF) to the gNB Distributed Unit (gNB-DU) and vice versa. For the transport over the 5G RAN fronthaul (realized e.g. as eCPRI) and across the radio interface a dedicated radio bearer (DRB) for the user plane transport must be configured by the gNB Central Unit for the Control Plane (gNB-CU CP).
As in LTE it is the RRC protocol that establishes this DRB. However, due to the virtualization the different protocol layers for the air interface are also distributed and the gNB-DU is in charge of all the lower layer PHY/RLC/MAC parameters (e.g the c-RNTI), while the gNB-CU CP assigns higher layer parameters of PDCP and RRC like the DRB-ID. Since only the gNB-CU CP can send downlink RRC messages to the UE the lower layer parameters from the DU first need to be sent in uplink direction to the gNB-CU CP.
Beside this parameter exchange the F1AP is also responsible for the tunnel management of the F1-U Tunnel.
The downlink tunnel endpoint information is provided by the gNB-DU using F1AP, but the uplink tunnel endpoint terminates at the gNB-CU UP and thus, its endpoint parameters are received by the gNB-CU CP when it exchanges information with the gNB-CU UP on behalf of the E1AP protocol.
A similar situation we see for the NG-U tunnel that is controlled by NGAP, the protocol for communication between gNB-CU CP and the Access and Mobility Management Function (AMF) in the 5G core. Neither the gNB-CU CP nor hte AMF have direct access to the NG-U tunnel endpoints. Hence, E1AP is used again to transmit the downlink tunnel parameters to the gNB-CU CP while the uplink tunnel endpoint parameters must be sent by the UPF to the Session Management Function (SMF) using the Packet Forwarding Control Protocol (PFCP) and later by the SMF to the AMF over the service-based interface where the tunnel endpoint parameters are embedded in a JavaScript Object Notation (JSON) container.
By the way, JSON is a quite generic format for exchanging and storing different kind of data. Between the AMF and the SMF JSON is used to transport Non-Access Stratum Session Management messages (defined in 3GPP 24.501).
It looks complicated, because the F1AP messages carry RRC plus NAS messages in uplink and downlink direction, but when understanding the underlying logic it is easy.
The very first step (in the figure: step 0) is the random access procedure executed on the MAC layer involving the UE and the gNB-DU.
After successful random access the UE sends the NR RRC Setup Request message. This is the Initial UL RRC Message transported by the F1AP from the gNB-DU to the gNB-CU CP. Actually the F1AP carries PDCP transport blocks and inside the PDCP the NR RRC messages are found, but to keep it simple I do not show the PDCP header in the ladder diagram.
Beside RRC Setup Request there are also some other initial NR RRC messages and RRC response messages possible (see step 1 and 2).
More RRC messages are transported over F1AP until the RRC Connection establishment is complete.
The NR RRC Setup Complete message also transports the initial NAS message and the reception of this message by the gNB-CU CP triggers the setup of a F1AP UE context. The concept of UE context management in F1AP is the same as in NGAP or - when looking back into the E-UTRAN - in S1AP.
The GTP/IP transport tunnel on F1-U is established during F1AP UE Context Setup assisted by E1AP Bearer Context Setup procedure that provides the necessary tunnel endpoint parameters.
In the same manner the NG-U tunnel is established by the NGAP Initial UE Context Setup procedure.
Additional NAS messages (especially for session management) and NR RRC Reconfiguration are exchanged to establish the end-to-end UE connection through the core network. And that's it.
Related Posts:
The Big Picture
In 5G standalone RAN the crucial elements for user plane payload transport of an UE connection are GTP/IP transport tunnels and a dedicated radio bearer on the radio interface.When looking at the 5G RAN there are two of such tunnels: one on NG-U (aka N3) that is controlled by NGAP, and one on F1-U that is controlled by F1AP - see figure 1.
On behalf of these two tunnels payload data can be transported between the 5G core network User Plane Function (UPF) to the gNB Distributed Unit (gNB-DU) and vice versa. For the transport over the 5G RAN fronthaul (realized e.g. as eCPRI) and across the radio interface a dedicated radio bearer (DRB) for the user plane transport must be configured by the gNB Central Unit for the Control Plane (gNB-CU CP).
As in LTE it is the RRC protocol that establishes this DRB. However, due to the virtualization the different protocol layers for the air interface are also distributed and the gNB-DU is in charge of all the lower layer PHY/RLC/MAC parameters (e.g the c-RNTI), while the gNB-CU CP assigns higher layer parameters of PDCP and RRC like the DRB-ID. Since only the gNB-CU CP can send downlink RRC messages to the UE the lower layer parameters from the DU first need to be sent in uplink direction to the gNB-CU CP.
Beside this parameter exchange the F1AP is also responsible for the tunnel management of the F1-U Tunnel.
The downlink tunnel endpoint information is provided by the gNB-DU using F1AP, but the uplink tunnel endpoint terminates at the gNB-CU UP and thus, its endpoint parameters are received by the gNB-CU CP when it exchanges information with the gNB-CU UP on behalf of the E1AP protocol.
Figure 1: Network Functions, Protocols and Parameters involved in Setup of User Plane Data Transmission Resources (click on the image to see full size) |
By the way, JSON is a quite generic format for exchanging and storing different kind of data. Between the AMF and the SMF JSON is used to transport Non-Access Stratum Session Management messages (defined in 3GPP 24.501).
The Ladder Diagram
Having the Big Picture in mind it is now easier to look at the ladder diagram with the individual RAN messages for UE connection setup - shown in Figure 2.
It looks complicated, because the F1AP messages carry RRC plus NAS messages in uplink and downlink direction, but when understanding the underlying logic it is easy.
Figure 2: 5G VRAN Successful UE Connection Setup (click on the image to see full size) |
The very first step (in the figure: step 0) is the random access procedure executed on the MAC layer involving the UE and the gNB-DU.
After successful random access the UE sends the NR RRC Setup Request message. This is the Initial UL RRC Message transported by the F1AP from the gNB-DU to the gNB-CU CP. Actually the F1AP carries PDCP transport blocks and inside the PDCP the NR RRC messages are found, but to keep it simple I do not show the PDCP header in the ladder diagram.
Beside RRC Setup Request there are also some other initial NR RRC messages and RRC response messages possible (see step 1 and 2).
More RRC messages are transported over F1AP until the RRC Connection establishment is complete.
The NR RRC Setup Complete message also transports the initial NAS message and the reception of this message by the gNB-CU CP triggers the setup of a F1AP UE context. The concept of UE context management in F1AP is the same as in NGAP or - when looking back into the E-UTRAN - in S1AP.
The GTP/IP transport tunnel on F1-U is established during F1AP UE Context Setup assisted by E1AP Bearer Context Setup procedure that provides the necessary tunnel endpoint parameters.
In the same manner the NG-U tunnel is established by the NGAP Initial UE Context Setup procedure.
Additional NAS messages (especially for session management) and NR RRC Reconfiguration are exchanged to establish the end-to-end UE connection through the core network. And that's it.
Related Posts:
Labels:
5G,
Network Architecture,
Open RAN,
Signalling,
vRAN
Sunday, 29 March 2020
Mobile Voice Communications is neither Dying, nor Dead!
If you have been following the mobile industry for a long time, you could be forgiven for thinking that voice communications is dead. This 2013 article for example talks about the impending death of voice and this 2018 article talks about how smartphones have killed the art of conversation. These are just examples and I have read many similar articles in the last 5-10 years.
The thing is that a lot of unnecessary calls became SMS and messages once the price of SMS and data went down. Similarly, voice ceased to be a differentiator in many markets so they started offering unlimited voice and/or SMS locally. This does not necessarily solve my requirements for international calling so I moved on to Viber, WeChat and WhatsApp.
The annual TeleGeography Report and Database update (just released) estimates that international over-the-top (OTT) voice traffic reached 1 trillion minutes in 2019, compared to just 432 billion minutes of international carrier traffic.
Anyway, with the lockdown in many countries because of coronavirus COVID-19, people have re-discovered the use of voice communications again. While I prefer having meetings on the internet, sometimes it's just simpler to call using your phone. A friend discovered that while she has some 40 GB data allowance that was generally more than enough, working from home means that she is having to use her device as a hotspot that is using up all her data. Switching from OTT calling to unlimited voice calling in her package means that she doesn't have to worry about voice calls eating her data package.
She is not alone. Operators all over are reporting the rise in voice communications:
Funnily I just remembered that in a survey of over 1000 people in the USA regarding what they want from 5G, the third most important thing was "clearer voice quality". If you want to understand how voice quality is measured that see this tweet below
We may keep on seeing a boom in voice traffic as more lockdowns occur and they are even stricter. We will have to wait and see of this habit of talking sticks or it's just for this unusual situation.
Related Posts:
The thing is that a lot of unnecessary calls became SMS and messages once the price of SMS and data went down. Similarly, voice ceased to be a differentiator in many markets so they started offering unlimited voice and/or SMS locally. This does not necessarily solve my requirements for international calling so I moved on to Viber, WeChat and WhatsApp.
The annual TeleGeography Report and Database update (just released) estimates that international over-the-top (OTT) voice traffic reached 1 trillion minutes in 2019, compared to just 432 billion minutes of international carrier traffic.
Anyway, with the lockdown in many countries because of coronavirus COVID-19, people have re-discovered the use of voice communications again. While I prefer having meetings on the internet, sometimes it's just simpler to call using your phone. A friend discovered that while she has some 40 GB data allowance that was generally more than enough, working from home means that she is having to use her device as a hotspot that is using up all her data. Switching from OTT calling to unlimited voice calling in her package means that she doesn't have to worry about voice calls eating her data package.
She is not alone. Operators all over are reporting the rise in voice communications:
- 27 Mar 2020 - O2 UK reported, "Since March 16th we have seen approximately 57% more voice traffic at the busiest point of the day. Typically voice traffic increases 5% year on year, and in a week we have experienced an increase of voice traffic comparable to nine years of regular demand." (link)
- 26 Mar 2020 - Official numbers reported by CTIA from Verizon, AT&T, T-Mobile, Sprint and U.S. Cellular stated that mobile voice traffic was up 24.3% while mobile data traffic was up 9.2% (see photo above - link)
- 24 Mar 2020 - Telenor Norwar tweeted, "Traffic has increased sharply since the coronary smith was seriously registered in this country. 50% increase in mobile voice, 25% increase in mobile data and 30-40% increase in fixed broadband"
- 24 Mar 2020 - T-Mobile USA released some interesting stats including gaming, etc. With regards to voice, their announcement said, "People are talking and texting more. Messaging is up dramatically, with a 26% increase in SMS (texting) and a 77% increase in MMS (pictures, multi-party texts, etc.). And, the amount of time people spend on calls has increased 17% nationwide." (link)
- 20 Mar 2020 - Telia in Denmark reported, "Thursday, March 12, the volume of speech in the network thus increased by 24% compared to the day before. Over the weekend 50% more was spoken - obviously due to a need to gain status on family and friends in the new situation. In the past working week, about 60% more has been spoken on the phone than on a normal week in March." (translated from original)
Is voice important for an operator? Probably not very much in the developed markets where users pay a good amount for data packages. In developing countries, voice is still a good source of revenue. At the TIP summit last year, Malaysian telecom giant Axiata said that ""every gigabyte costs about $1.40 to manufacture...generates only 80 cents in revenue...The 2G voice business currently funds any losses". This is not a long term sustainable model for these operators.
Of the 1000 people surveyed, top 5 things people in the USA want from 5G:— Zahid Ghadialy (@zahidtg) March 23, 2018
• Faster data speeds
• Improved coverage – fewer dead spots
• Clearer voice quality 🤔
• better battery life
• lower cost servicehttps://t.co/aK4ym25seW
Funnily I just remembered that in a survey of over 1000 people in the USA regarding what they want from 5G, the third most important thing was "clearer voice quality". If you want to understand how voice quality is measured that see this tweet below
How do you measure voice quality! pic.twitter.com/a9aNBVMa9L— 3G4G (@3g4gUK) May 2, 2017
We may keep on seeing a boom in voice traffic as more lockdowns occur and they are even stricter. We will have to wait and see of this habit of talking sticks or it's just for this unusual situation.
Related Posts:
- The 3G4G Blog: A quick starter on 4G voice (for beginners)
Labels:
Apps Messaging,
Apps SMS,
O2,
OTT,
Revenues,
Stats,
T-Mobile USA,
UK,
USA,
Voice Communications
Subscribe to:
Posts (Atom)