Showing posts with label RRC. Show all posts
Showing posts with label RRC. Show all posts

Friday, 17 July 2020

A Look into 5G Virtual/Open RAN - Part 7: Change of gNB-CU-UP without Handover

This will be the last part of my series about Virtual/Open RAN signaling procedures. In this final post (although not the last one on this blog) I would like to present a very unique procedure that emerges from the facts of virtualization and automation of the RAN. And again I would like to present the big picture overview of the scenario that is called "Change of gNB-CU UP" (without handover). The full message flow (ladder diagram) can be found in 3GPP 38.401, chapter 8.9.5.

In the same chapter one can read that the trigger point for starting a change of the gNB-CU UP is quite vague. 3GPP writes: "e.g. a measurement report". However, which particular measurement event should trigger such a procedure? Even when looking into the Rel. 16 versions of 3GPP 38.331 (NR RRC) it becomes evident that all measurement events that are not dealing with NR sidelink or V2X connectivity are triggered by changing reference signal strength or rising interference. 

However, in case of a gNB-CU UP change without handover the UE does not move to a different cell. This makes me think - correct me if I am wrong - the true trigger points for this procedures come form a different entity, e.g. from the AI-driven policies and algorithms of the RAN Intelligence Controller (RIC) that is a fundamental element of the Open RAN architecture.


So what is necessary from a signaling perspective to change the gNB-CU UP during an ongoing connection?

There are new transport network resources aka GTP/IP-Tunnels required to steer the user plane traffic to and through the RAN. A new F1-U tunnel is necessary as well a a new NG-U tunnel, because also the user plane traffic between RAN and the UPF in the 5G core network must be exchange using a new route.

When it is clear which new UP transport tunnels need to be established (and which old ones need to be deleted) it is really simple to understand the overall scenario.

A F1AP UE Context Modification procedure is performed to switch the F1-U tunnel. NGAP Path Switch procedure is performed to switch the NG-U tunnel. And an E1AP Bearer Context Modification procedure is the prerequisite, because it delivers the new UL GTP-TEID for the F1-U tunnel as well as the new DL GTP-TEID for the NG-U tunnel.

Unfortunately the authors of 3GPP 38.401 are not very precise when mentioning protocol procedures defined in other specs. Thus, they speak about "bearer modification" when looking at F1AP and "Path Update" for NGAP.

It is not a big deal, but something you just need to know if you want to analyze real-world message flows of this scenario.

Related Posts:

Monday, 6 July 2020

A Technical Introduction to 5G NR RRC Inactive State


I looked at the RRC Inactive state back in 2017, but the standards were not completely defined. In the meantime standards have evolved and commercial 5G networks are rolling out left, right and centre. I made a short technical introduction to the RRC_INACTIVE state, comparing it with the 4G states in RRC and NAS. I also looked at some basic signalling examples and there are lots of relevant references at the end. Video and slides embedded below.






Related Posts:

Saturday, 4 July 2020

An Introduction to Vehicle to Everything (V2X) and Cellular V2X (C-V2X)


We made an introductory tutorial explaining vehicle to everything. There are 2 different favours of V2X as shown in this tweet below


One is based on IEEE 802.11p (802.11bd in future). It is known by different names, DSRC, ITS-G5, etc. The other is the cellular V2X or C-V2X. It started as basic D2D but has evolved over the time. The slides and video are embedded below but this topic will need revisiting with more details.







Related Posts:

Tuesday, 30 June 2020

A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn

In previous blog posts I have discussed intra-gNB-DU handover and inter-gNB-DU handover scenarios.Now it is time to look at inter-gNB-CU handover that uses the Xn interface.

At the RRC protocol layer there will be the measurement setups and measurement reports as in the intra-gNB handover cases. And F1AP UE Context Setup and Release Procedures are identical with the ones discussed for inter-gNB-DU handover. Only the cause values are expected to be different, e.g. "successful handover".

Thus, I do not want to  focus here on la adder diagram call flow (that is by the way very well described in 3GPP 38.401, chapter 8.9.4), but invite you to have a look at a "big picture" that you see below.

(click image to enlarge)

What characterizes the inter-gNB handover is the transfer of the UE RRC/NGAP context form the source gNB-CU to the target gNB-CU. When the Xn interface is available to connect two neighbor gNBs this context transfer is executed using the XnAP Handover Preparation procedure. The Initiating Message of this procedure transfers the UE context parameters to the target gNB-CU. Then embedded in the Successful Outcome message the handover command is sent in return to the source gNB-CU that forwards it to the UE. In addition a temporary user plane transport tunnel for the purpose of data forwarding is established and later on released on the Xn user plane interface.

Once the UE performed the handover on the radio interface all the transport tunnels for the payload transmission need to be switched from the old gNB to the new one. This includes the tunnel to the UPF that is managed by the NGAP. Thus, the target gNB-CU starts the NGAP Path Switch procedure. 

In the target gNB environment it is necessary to establish a new F1AP UE context, new E1AP Bearer Context and new F1-U payload transport tunnel. All this happens BEFORE the Handover Command is sent to the source gNB/UE. And once there is an indication that the handover is completed all the radio and transport resources controlled by the source gNB will be released.

So the figure above looks complicated, but actually the underlying logic of context/data forwarding, radio resource allocation and transport tunnel switching is quite simple.

Special note: In case there is no Xn interface available the UE context/handover information can be transmitted using NGAP Handover Preparation procedure on the source side of the connection and NGAP Handover Resource Allocation procedure on the target side of the connection.

Related Posts:

Tuesday, 23 June 2020

Comparison Layer 2 Measurements LTE vs. 5G NR


Yesterday (2020-06-22) 3GPP uploaded the version 1.0 of TS 38.314 "Layer 2 Measurements" for 5G New Radio Rel. 16.

I was wondering about the difference compared to the same LTE standard defined in 3GPP TS 36.314.

The initial look at the table of contents shows significantly less measurements in the NR spec, but a new counter for the number of stored inactive UE contexts. This is due to the introduction of RRC Inactive state in NR RRC specified in 3GPP TS 38.331)

All other differences in the NR standard are related to chapter number 4.2.1.6 "Other measurements defined in TS 28.552".

Here one finds the references to Data Volume, Average Throughput Measurement per UE and DRB as well as PRB usage measurements.

Adding these additional measurements to the list we see in the table of contents it emerges that indeed the number of stored inactive UE contexts is the only major difference in comparison with the LTE standard. 

Friday, 12 June 2020

A Look into 5G Virtual/Open RAN - Part 5: Inter-gNB DU Handover

My last blog post discussed the intra-gNB-DU handover. Now it is time to look at inter-gNB-DU handover. This means: the target cell is located in the same gNB, but connected to a different gNB Distributed Unit (gNB-DU) than the source cell.

The figure below shows the message flow:

(Click on the image to enlarge)

As you can see it was not so easy to show all the messages in one flow chart and again I have simplified things a little bit. So it is not shown that NR RRC messages are transparently forwarded by the gNB-DU when sent to or received from the UE.

It should also be noted that between step 8 and 9 the UE performs a random access procedure on the radio interface that is also not shown.

Beside this the RRC measurement configuration and measurement report is identical with the same procedure in the intra-gNB-DU handover case (step 1+2)

However, due to the fact the target cell is connected to a different gNB-DU a new F1AP UE context must be established on the incoming F1-C leg (step 3+4). As in a new connection setup scenario the target gNB-DU provides all necessary lower layer parameters for the target cell radio link including a new c-RNTI.

Since we need also a new user plane transport tunnel to exchange payload on the F1-U interface between the target gNB-DU and the gNB-CU UP an E1AP Bearer Context Modification procedure is performed in step 5+6.

The following F1AP UE Context Modification Request is used to transmit the handover command (NR RRC Reconfiguration message with target cell parameters) towards the UE (step 7). In step 8 the F1AP UE Context Modification Response confirms that the handover command was forwarded to the UE.

After successful random access the UE sends NR RRC Reconfiguration Complete message on the new radio link (step 9) and this triggers the F1AP UE Context Release procedure on the outgoing F1-C leg.

Related Posts:

Friday, 29 May 2020

Visualisation of Intra-gNB Handover in an End-to-End Monitoring Tool


In my last blog post I described the message flow of an intra-gNB-DU handover.

Today I want show how such a handover can be visualized using a ladder diagram in an end-to-end passive monitoring tool. The tool shown in the figure below is the NETSCOUT nGenious Session Analyzer (nSA).

The data source is a cell trace feed according to 3GPP 32.421/32.423. Unfortunately F1AP and E1AP messages are missing in the trace so that we cannot distinguish if this is an intra- or inter-gNB DU handover.

(click to enlarge)

Nevertheless the tool offers the great advantage to find the handover procedure quickly within all the other messages of the trace. It also links the outgoing (source) and incoming (target) side in case that different feeds from different cells need to be combined.

For the NR RRC messages are send/received by the UE, but there is a good reason to show the icon "Cell" on top the ladder diagram. With this approach it is possible to spot immediately the changing cell location of the UE and NR RRC Reconfiguration procedure that is used to execute the handover. So the icon does not represent a cell, but an UE within a cell - and with a bit imagination you can recognize this in the icon graphic itself.

Selecting the handover message it is possible to open the Inline Decode tab and browse through the bits and bytes of NR RRC. As expected beside many other parameters the new UE Identity (new C-RNTI) to be used by the UE after arriving in the target cell is one of the most important information elements and confirms that this particular NR RRC Reconfiguration message is indeed the command for executing the intra-gNB handover.

Thursday, 14 May 2020

A Look into 5G Virtual/Open RAN - Part 4: Intra-gNB DU Handover

In the previous posts of this series I described O-RAN interfaces and protocols, connection establishment and connection release procedures. Now it is time to look at handovers.

As mentioned in one of the earlier posts the gNB-CU CP will be in charge of controlling hundreds of gNB-DUs in a similar way like the 3G RNC was in charge of controlling hundreds of UMTS NodeBs. As a result the most common 5G SA intra-system handovers will be intra-gNB handovers. These handovers can further be classified into intra-gNB-DU handovers (inter- as well as intra-frequency) and inter-gNB-DU handovers.

Due to the virtualization of RAN network functions we will also find another form of switching transmission path, which is a change of the gNB-CU UP during the call without mobility of the UE. This scenario I will discuss later in a separate blog post.

Today I want to focus on the intra-gNB DU handover. Here the UE moves from one cell to another one within the same distributed unit as shown in the figure below.



A prerequisite is the successful establishment of a NR RRC connection and a F1AP UE Context between the gNB-DU and the gNB-CU CP.

The F1AP transports all RRC messages between these two entities. Indeed, it transports the PDCP blocks and the gNB-DU is not aware that these PDCP blocks contain RRC messages. However, for better illustration I have not shown the PDPC part in the ladder diagram.

What we see in step 1 is a NR RRC Reconfiguration message that contains RRC measurement configurations to be enabled on the UE side. A typical trigger event for intra-frequency handovers is the A3 event that is already known from LTE RRC.

Once the UE detects a better neighbor cell meeting the A3 criteria it sends a RRC Measurement Report to the gNB-CU CP (step 2).

In step 3 the gNB-CU CP orders the gNB-DU to perform a F1AP UE Context Modification. The purpose is to allocate radio resources for the UE in the target cell and to prepare the cell change.

The gNB-DU replies with F1AP UE Context Modification Response. This messages contains the new C-RNTI and a large block of lower layer configuration parameters (e.g. for RLC and MAC layer) that need to be sent to the UE and thus, need to be transported to the gNB-CU CP before, because it is the only RAN function capable to communicate with the UE using the RRC protocol.

Hence, in step 5 we see another downlink RRC message transfer. This time it is used to transport the handover command towards the UE. The handover command is a NR RRC Reconfiguration message and it contains the new C-RNTI (new UE identity within the cell) as well as the physical cell ID of the target cell and the full set of lower layer configuration parameters previously provided by the gNB-DU.

When the gNB-CU CP receives the RRC Reconfiguration Complete message sent by the UE in step 6 the handover is successfully completed and the UE is now served by the cell with NR PCI 2.

As mentioned before there is neither XnAP (communication between two neighbor gNBs) nor NGAP (communication between gNB and AMF) involved in this handover procedure.

Related Posts:

Thursday, 7 May 2020

How the A6 Measurement Event triggers Secondary Cell Change in LTE Carrier Aggregation Calls


Last week I read in Martin Sauter's blog about the LTE RRC A6 measurement event.

Although I am quite interested in RRC measurements I have never seen the A6 event in action. Rather the eNB vendors have implemented carrier aggregation in a way that the UE provides its capabilities and according to the this the maximum possible numbers of component carriers is added to the connection. There is no RRC measurement report before adding secondary LTE cells to the connection. So what is the A6 event good for and is it used at all?

Surprisingly I needed only 2 attempts to find an example of using the A6 event in a live network configuration. It is used when more component carriers are available than the UE can simultaneously handle. E.g. if there are 4 or more cells with different carrier frequencies available in the same antenna sector the A6 event ensures after the initial CA configuration that the cells with the best radio conditions are selected as secondary cells.

Let's have a look at this scenario in detail. Figure 1 shows the report configuration for the A6 event. Keep the reportConfigId = 3 in mind.


Figure 1: Report Configuration for Event A6

The next step is the configuration of the Measurement ID as shown in figure 2. Here the reportConfigId is combined with a measObjectId that represents the carrier frequency of the potential SCell.

Figure 2: Measurement ID for Event A6
Now, if the event A6 is triggered in the UE a RRC Measurement Report with this measId = 3 is sent to the eNB as shown in Figure 3.

Figure 3: RRC Measurement Report for Event A6
There we see the RSRP and RSRQ of the primary cell (PCell) and of the currently serving secondary cells (SCells). By the way the servFreqId stands for the sCellIndex value that was linked to the physical cell ID (PCI) when this SCell was added in a previous RRC Connection Reconfiguration procedure. 

And as one can see the neighbor cell with PCI = 470 has significantly better RSRP and RSRQ to offer than both currently used SCell. 

Consequently the eNB decides to replace the SCell with sCellIndex value 1 with the better cell (PCI 470). This is again done with a RRC Connection Reconfiguration procedure as shown in figure 4. And this is the way how the A6 event is used.


Figure 4: Change of SCell
  

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.


Figure 1: Connection Release due to "user inacativity"
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.

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:

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

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.

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.



Monday, 9 March 2020

How LTE RRC (4G) and NR RRC (5G) Protocols are used in Parallel in EN-DC (5G NSA)

Last week I had a fruitful discussion with a fellow blogger on the web, Martin Sauter (@mobilesociety) regarding a post in which he compared features of LTE RRC (3GPP 36.331) and NR RRC (3GPP 38.331).

It was Martin's impression that the NR RRC protocol is primarily designed to be used in the 5G standalone mode. However, as I wrote in a comment to his post the NR RRC protocol is already used in EN-DC radio connections.

The reason is that the UE must be informed about Hundreds of lower layer 5G parameters (physical, MAC, RLC) that are needed for the payload transmission over 5G frequencies. Indeed, when it comes to user plane data transmission the gNB works almost independently and the UE must handle LTE and NR radio links in parallel.So it has two different radio units (even if combined into a single radio chip set). This double-functionality is also one important reason why 5G smartphones are quite expensive. It is a lot of software and know-how that sits inside these chips.

How much surplus code is really necessary to enable 5G technology becomes visible when looking at trace data using a state-of-the-art protocol test and monitoring tool.

When reading the 3GPP 36.331 (LTE RRC) standard document one might have the impression that just a few 5G parameters have been incorporated into this protocol to support EN-DC connections.

However, when looking into the details of e.g. the nr-SecondaryCellGroupConfig-r15 it turns out that some this single information element is indeed a huge block of NR information (total size: 1111 Byte)

It is an entire 5G RRC message (rRCReconfiguration) that is piggybacked by the LTE rrcConnectionReconfiguration message, because in 5G non-standalone mode this is the only way to transmit 5G signaling information to the UE. And as highlighted in the upper part of the screenshot there are a couple of NR RRC messages transported in so-called NR-RRCContainers* during the EN-DC Establishment Procedure.

And what about 5G standalone mode? For this radio access technology the 3GPP 38.331 Rel. 15 protocol is suitable as well. Hence, some parameters mentioned in the standard paper will never be seen in EN-DC. A perfect example is S-NSSAI (Single Network Slice Selection Assistance Information), because network slicing requires the connection with a 5G core network as a prerequisite. 


(click on image for larger version)

* This is not an 3GPP term, but coined by the developers of the decoding engine.

Wednesday, 4 March 2020

A Look into 5G Virtual/Open RAN - Part 1

Although it is understood in general that virtualization and increasing complexity are inherent characteristics of 5G networks many people are surprised when they realize the significant differences of 5G RAN architecture and signaling procedures compared to what they know from LTE or UTRAN.

In this blog post series I want to highlight some details that are not immediately visible when reading the 3GPP specs.

Figure 1 shows a virtualized gNB and the protocols it uses to communicate with its internal entities as well as with the UE and peer entities in neighbor network elements/functions.

Figure 1: Virtual Network Functions and Protocols in 5G RAN
(click on the image to see full size)

The core of the whole thing is the gNB-Central Unit for the Control Plane (gNB-CU CP). This function communicates directly with the UE using the NR RRC protocol. It also "talks" to the 5G Core Network represented by the AMF using the NGAP, a protocol very similar to the S1AP known from E-UTRAN. Neighboring 5G base stations are contacted using the XnAP, neighboring eNBs can be reached by using X2AP.

The other virtual functions of the gNB are the Central Units for User Plane (gNB-CU UP) and the Distributed Units (gNB-DU). While the gNB-CU UP is responsible for handling the transport of payload the gNB-DUs deal with all the allocation of radio resources, especially the scheduling. As a result the lower layer radio interface protocols, especially RLC and MAC terminate in the gNB-DUs.

For the RAN monitoring tools and the 3GPP Minimization of Drive Test (MDT) feature this means that RRC and Logged Measurement Reports sent by UEs will be available at gN-CU CP while all uplink radio quality measurements and call-related user plane metrics is only available at the gNB-DU - see figure 3.

Figure 2: Distribution of un-correlated RAN measurement tasks among different gNB virtual functions
(click on the image to see full size) 

And today, there is no 3GPP-standardized procedure to correlate this measurement information collected by different virtual gNB functions.

The full impact of the 5G RAN virtualization becomes even more evident when looking at Figure 3. It shows a single gNB-CU CP in charge of controlling several gNB-CU UPs and gNB-DUs.

In a live network deployment a single gNB-CU CP will control hundreds of gNB-DUs and maybe several gNB-CU UPs. This is why it is misleading to compare the connectivity of a gNB-CU CP with that of a LTE eNB. Rather it could be compared with a UTRAN RNC controlling a similar number of 3G base stations.


Figure 3: 5G RAN Connectivity
(click on the image to see full size)

Looking back into figure 1 we see that the F1AP is used for communication between gNB-CU CP and its gNB-DUs while the E1AP is the protocol that connects the gNB-CU CP with surrounding gNB-CU UPs.

Call-related control plane procedures of F1AP and E1AP are very similar to what is known from NGAP. There is a UE context established between the gNB-CU CP and the gNB-DU. On F1-U a GTP tunnel is established for user plane transport. At the same time an E1 Bearer Context in gNB-CU CP and gNB-CU UP keeps track of the most relevant user plane transport parameters.

All in all for setting up a single subscriber connection in the virtualized 5G RAN there are significantly more signaling transactions necessary than in E-UTRAN. Figure 4 shows a practical example.

Figure 4: 5G RAN Call Trace in NETSCOUT Session Analyzer
(click on the image to see full size)
The volume and complexity of signaling information is increasing when the UE moves or is redirected to virtual functions within one gNB e.g. due to load balancing.

The next blog post of this series will dive deeper into details of such call scenarios.

Stay tuned...

Related Posts:

Friday, 2 August 2019

3GPP Minimization of Drive Test (MDT) Signaling at a Glance

There are growing numbers of UEs that are capable of reporting 3GPP-defined measurements for the purpose of minimization of drive test as defined in 3GPP TS 37.320. Although only a subset of the capable devices have this feature enabled it is worth to have a closer look at the signaling procedures and measurements.

3GPP MDT data can be gathered in two different modes: immediate and logged.

immediate mode – as illustrated in figure 1 - provides measurements for RAN and UE. The UE measurements are derived from RRC measurement reports. The RAN adds the power headroom reported on the MAC layer, and the Received Interference Power (RIP) measured on the physical radio interface layer at the cell`s antenna as well as, reports for the data volume, IP throughput, user plane packet delay, and packet loss measured by the eNodeB.
Figure 1: Immediate 3GPP MDT Measurements*

logged mode – an example is shown in Figure 2 - the UE stores information related to accessibility problems in IDLE mode, failures during RRC establishment, and handover random access as well as radio link failures including connection loss. The MDT events log is sent to the network when it is requested. After connection loss, the MDT logged mode report is sent after the next successful radio connection establishment.

Figure 2: Logged 3GPP MDT Measurements*

The RRC measurement samples and Radio Link Failure (RLF) reports also contain detailed location information for example, on GPS/GNSS coordinates, although the 3GPP Release 9 Technical Report TR 36.805 stated: “The extensive use of positioning component of the UE shall be avoided since it would significantly increase the UE power consumption.”

Although, the encoding of logged mode reports and immediate UE measurements are defined in 3GPP TS 36.331 (RRC), the message formatting of the immediate RAN measurement events follow different proprietary specifications of the network element manufacturers (NEMs).

It is also up to the NEMs which of the M2... M7 immediate reports are implemented and how often such measurements will be generated during an ongoing connection. 

* all parameter values shown in the figures have been chosen randomly for illustrative purpose and do not reflect the situation of a real call or network 

Sunday, 5 November 2017

RRC states in 5G

Looking back at my old post about UMTS & LTE (re)selection/handovers, I wonder how many different kinds of handovers and (re)selection options may be needed now.

In another earlier post, I talked about the 5G specifications. This can also be seen in the picture above and may be easy to remember. The 25 series for UMTS mapped the same way to 36 series for LTE. Now the same mapping will be applied to 38 series for 5G. RRC specs would thus be 38.331.

A simple comparison of 5G and LTE RRC states can be seen in the picture above. As can be seen, a new state 'RRC Inactive' has been introduced. The main aim is to maintain the RRC connection while at the same time minimize signalling and power consumption.

Looking at the RRC specs you can see how 5G RRC states will work with 4G RRC states. There are still for further studies (FFS) items. Hopefully we will get more details soon.

3GPP TS 22.261, Service requirements for the 5G system; Stage 1 suggests the following with regards to inter-working with 2G & 3G

5.1.2.2 Legacy service support
The 5G system shall support all EPS capabilities (e.g., from TSs 22.011, 22.101, 22.278, 22.185, 22.071, 22.115, 22.153, 22.173) with the following exceptions:
- CS voice service continuity and/or fallback to GERAN or UTRAN,
- seamless handover between NG-RAN and GERAN,
- seamless handover between NG-RAN and UTRAN, and
- access to a 5G core network via GERAN or UTRAN.