Showing posts with label Open RAN. Show all posts
Showing posts with label Open RAN. 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.

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.

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.

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.

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.

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:
According to the press release:

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:

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.

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)
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).

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.

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...

Tuesday, 22 October 2019

From traditional RAN to Open RAN - O-RAN: Goals and Challenges


My Open RAN tutorial has recently gained popularity with recent announcements from Altiostar, Mavenir, Parallel Wireless, Telefonica and Vodafone. With TIP Summit in few weeks time, I am hoping for a lot more curious people to discover that blog post and video.

Olivier Simon, Director, Radio Innovation, Orange spoke about "O-RAN: Goals and Challenges" at Open Networking Summit Europe 2019. In his presentation, he explained how O-RAN will trigger more intelligence and openness in the RAN domain. He talked about which use cases will require this new architecture and why O-RAN is coming at the right time. Major architectural change are necessary in the next years in order to improve E2E latency and benefit from the flexibility of virtualized network functions. O-RAN will provide the right framework in order to perform this transformation in an open manner and keeping at the same time economies of scale thanks to a global adoption.


The presentation also touches on O-RAN Software Community. The O-RAN Alliance recently partnered with the Linux Foundation to establish the O-RAN-Software Community (O-RAN-SC), to provide that open source software application layer to the RAN. O-RAN-SC will foster development of an open source infrastructure platform for running 5G RAN solutions.

The key aspects of ORAN-SC are:
  • New Open Community focused on RAN Software in collaboration with O-RAN Alliance
  • Set up for collaboration across OPNFV, ONAP, Akraino and other Open Source projects

Here is the video of the conference embedded below:



Related Posts:

Tuesday, 15 October 2019

Summary of #CWTEC 2019 Conference: 5G, Satellites & Magic MIMO

I was involved in helping organise yet another CW TEC conference this year. The topic was quite interesting and we had some brilliant speakers. Some of the excellent presentations were shared too, links below. Here is a very quick summary of the event, linking also to couple of excellent summaries below.

The topic was a bit unusual and it rhymed very well with the attendees which were from many different backgrounds, from 5G, communications, satellites, electronics, T&M companies, etc. Here is the opening video that will show you the motivations behind this



The day started with a breakfast briefing from Cambridge Consultants that looked at how Massive MIMO is the key to unlocking 5G User Experiences. Presentations available here.


Session 1 was titled "What has Massive MIMO ever done for us?". The narrative for the session was as follows:
Clearly the desire for more and more capacity in cellular networks has driven the industry to find more and more novel techniques. The work done over the years and boosted by Tom Marzetta’s article titled “Noncooperative Cellular Wireless with Unlimited Numbers of Base Station Antennas” has set high expectations for this emergent technology, so much so the term Magic MIMO has been coined. However, how significant is it into today’s early 5G rollout and what can we expect over the coming years? Are there still further enhancements we should expect to see?

There were 3 talks as follows:
  • Sync Architectures for 5G NR by Chris Farrow, Technical Manager, Chronos Technology (slides)
  • Three UK’s RAN transformation: Spectrum, RAN architecture strategy, Why? by Dr Erol Hepsaydir, Head of RAN and Devices Strategy and Architecture, Three UK (slides)
  • Active antenna systems in RAN: performance, challenges and evolution by Anvar Tukmanov, Wireless Research Manager, BT (slides)


Session 2 looked at "Non-Terrestrial & Hybrid Networks". The narrative for the session was as follows:
There are different initiatives underway to make satellite and other non-terrestrial networks as part of 5G. In addition, many different mobile operators have demonstrated compelling use-cases with drones, balloons and other aerostats. Other innovative approaches like European Aviation Network uses a hybrid-network using terrestrial network supported by a satellite connection as a backhaul for in-flight Wi-Fi. In addition to latency, what other challenges are stopping mass adoption of Non-terrestrial and Hybrid networks? What about advanced features like slicing, etc.?

There were 3 talks as follows:

  • Opportunities for blending terrestrial and satellite technologies by Dr Jaime Reed, Director, Consulting, Space, Defence and Intelligence, CGI (slides)
  • Non-terrestrial Networks: Standardization in 5G NR by Dr Yinan Qi, Senior 5G Researcher, Samsung R&D Institute UK (slides)
  • Satellites and 5G: A satellite operator’s perspective by Simon Watts, Principal Consultant, Avanti Communications (slides)


Session 3 looked at "5G: A Catalyst for Network Transformation". The narrative was as follows:
5G has set high expectations in the user as well as operator community. While eMBB can be supported with an upgrade of existing 4G infrastructure, URLLC and mMTC may require massive change in the network architecture. Operators have already started the transformation process with backhaul upgrades, new data centers, distributed core and cloud rollouts, etc. How are networks evolving to accommodate these deep changes? What other changes will be required in the network to support the growth until the next new generation arrives?
This session featured 3 talks as well
  • An Introduction to Open RAN Concept by Zahid Ghadialy, Senior Director, Strategic Marketing, Parallel Wireless UK & EMEA (slides)
  • Powering the successful deployment of 5G infrastructure by David George, Vice President of EMEA and APAC, Sitetracker (slides)
  • The 5G transformation: no sweet without sweat by Antonella Faniuolo, Head of Network Strategy, Planning, Digital & Optimisation, Vodafone (slides)


The final session topic was "Getting ready for Beyond-5G Era". The narrative was as follows:
Many technologies like Full duplex, etc. that were originally intended to be part of 5G were not able to make it into the standards. Along with these, what other revolutionary changes are needed to make Beyond-5G technologies not only fulfil the vision, ambition and use-cases that were originally envisaged for 5G but to take it a step further and make it a game changer.
This session featured 3 talks as well, as follows:
  • Thinking Beyond 5G: Projects and Initiatives by Alan Carlton, Vice President, InterDigital Europe (slides not available)
  • 5G Evolution: Progressive enhancement and new features for new markets by Matthew Baker, Head of Radio Physical Layer and Coexistence Standardization, Nokia (slides)
  • Why 6G’s design goals need far more than just radio & core innovation by Dean Bubley, Analyst & Futurist, Disruptive Analysis (slides not available)
And my personal highlight was that I launched World's first coloured 5G tie


Hopefully you found the presentations shared as useful. Please also read the summaries of CWTEC provided below.


Related Articles:

Monday, 4 February 2019

A quick tutorial on Open RAN, vRAN & White Box RAN


I made a short tutorial based on my understanding of Open RAN, Virtualised RAN and WhiteBox RAN. Slides and video embedded below.






Related Posts: