# Employee Study & Development
## Literature Study 1 : Open Radio Access Network (O-RAN) Systems Architecture and Design
Name : Raffie Winata
In this week we will discuss about Chapter 1 section, there are :
## Chapter 1: Open radio access network overview
* [The Open Radio Access Network Alliance On C-RAN, Open vRAN, OpenRAN, xRAN, and Telecommunications Infrastructure Project](https://hackmd.io/8bhNR9rNSUOFmBiMc1zi5g#1-The-Open-Radio-Access-Network-Alliance-On-C-RAN-Open-vRAN-OpenRAN-xRAN-and-Telecommunications-Infrastructure-Project)
* Spectrum: Enabling 5G
* Traditional base station architecture
* 5G base station architecture
* Functional Splits
* Coordinated Multipoint
* A real-life example: enterprise 5G networking
* Summary and conclusions
* References
* Further reading
---
#### 1. The Open Radio Access Network Alliance On C-RAN, Open vRAN, OpenRAN, xRAN, and Telecommunications Infrastructure Project
**The Open Radio Access Network Alliance**
Founding members of the O-RAN Alliance are AT&T, China Mobile, Deutsche Telekom AG NTT DOCOMO Inc, and Orange but by now membership has increased after including the Who's Who" in the wireless industry.
The stated target of O-RAN is to break the closed nature of current radio access network (RAN) implementations. O-RAN explicitly aims specifically at 3GPP networks instead of 802.11 (VW-Fi) and other wireless standards. O-RAN means to decouple hardware and software implementations allowing vendor (hardware,software and system) to focus on providing components rather than a complete solution.
O-RAN is organized into working groups that own specific hardware, software, and system components. These working are:

**Working Group 1 : Use cases and overall architecture workgroup**
WG1 focuses on use cases and system-level requirements as well as organizing proof of concepts to showcase O-RAN products to the wider market. This working group is operator led (AT&T, CMCC).
**Working Group 2 : Non-Real-Time RIC and A1 interface Workgroup**
WG2 owns the definition of the non-real-tinme (RT) RAN Intelligent Controller (RIC) and the A1 interface. The non-RT RIC controls radio resource management (RRM), hÃgher layer procedure optimization, and RAN policy optimization, including Artificial Intelligence (A)/ Machine Learning model application. Communication between the near-RT RIC and the non-RT RIC is defined by the A1 interface functionally this interface carries polic-based quidance of near-RT RIC functions/use cases and appropriate feedback/input data in the return path.
At its lowest level, non-RT RIC COnverts system goals (RAN intent) and observed parameters and counters to policies that quide the RT RIC toward fulfilling the system goals. Deliverables include: A1 interface specification
**Working Group 3 : Near-Real-Time RIC and E2 interface Workgroup**
WG3 owns the near-RT RIC architecture and functionalities. Deliverables include:
* E2 interface specification. Note that the E2 interface is 3GPP-defined. WG3 provides a framework with a defined subset of 3GPP messages.
**Working Group 4 : Open Fronthaul interface Workgroup**
WG4 owns the definition of fronthaul interfaces. Deliverables include:
* Managementplane (MP) spesification. A NETCONF/YANG-based M-Plane
* Control, user, and synchronization plane(CP,UP,SP) specification
* Fronthaul interoperability test specification
**Working Group 5 : Open F1/W1/E1/X2/Xn interface Workgroup**
WG5 own the definition of mid/bachaul interfaces, like how WG4 own the fronthaul interfaces, deliverabes include:
* O1 interface specification
* Mid/backhaul specification
**Working Group 6 : Cloudification and Orchestration interface Workgroup**
WG6 identifies use cases that demonstrate the benefits of hardware/software decoupling(cloudification), including RIC,DU,CU, and RU. it also defines deployment scenarios, requirements, and reference designs for the cloud platform, including network function virtualization infrastructure, virtual infrastructure manager(VIM) for container/VM orchestration, and accelator abstraction layers(AAL)
**Working Group 7 : White Box Hardware interface Workgroup**
WG7 focuses on the architecture of DU and RU reference hardware design development.
**Working Group 8 : Stack Reference Design Workgroup**
WG8 focuses on the architecture of reference software
**Working Group 9 : Open-X-haul Transport Workgroup**
WG9 defines an architecture for fronthaul (DU2RU), midhaul (CU2DU), and backhaul (CU2core) transport network
* Transport requirements documents
* Packet transport network architecture
**Open Radio Access Network Members**
O-RAN is an operator-driven standards body to make sure that operator goal such as openess and software centricity are met. Members include white box hardware, software, and systems vendors as well as other companies in the wireless supply chain such as test equipment and component/silicon vendors and research institutes.
**Why Now ?**
O-RAN are groundbreaking, there are a couple of reasons to point out:
* History evidence, O-RAN is trying to achive has already been shown effective in the wireline networking world
* Moore's law, the concepts of software-defined radio (SDR) have been explored since the 2000s, but O-RAN is only getting serious consideration in the B2020s. Why is this? One aspect to consider is the advancement in silicon technology that has made a move from proprietary application-specific integrated circuit (ASIC)-based implementations to software defined implementations possible
* Standard flexibility, 5G is different from previous standars, in that the standars is design ground-u to support flexibilty. With flexibility in standards comes flexibility in deployment options and this is contrary to an implementation strategy that has been honed over decades to support a single (macro) base station deployment. Flexibility is enabled by software and drives software-centric implementations from a wide ecosystem of nontraditional vendors. This is exactly what O-RAN enables,
* Vendor lock in
**On C-RAN, Open vRAN, OpenRAN, xRAN, and Telecommunications Infra Project**
O-RAN is established as the de facto standard for open, disaggregated, and software-defined 3GPP network implementations. But the O-RAN standards body is not the only for first) to aim for this goal, a lot of the initial R&D and concept development on O-RAN topics has been done.
An initial MOU on C-RAN collaboration was signed in April 2010 between the China Mobile Research Institute (CMRI) and ZTE, IBM, Huawei, and Intel. C-RAN targets cloud computing on general-purpose servers in a centralized location for 2G, 3G, and 4G communication standards.
According CMRI, colocation of radio equipment in a centralized location allows for resource sharing, leading to significant cost reduction
The C-RAN concept imposed many early engineering challenges:
* Bandwith and timing requirements for antenna sample transport are high/strict
* The concept of a C-RAN virtualized environment assumes a virtualized SDR environment which leads to high performance requirements.
These engineering challenges triggered the alternative interpretation of the "C" in G- RAN: Centralized. The Centralized RAN architecture does use the resource pooling concept and provides many of the CRAN advantages (capacity sharing, advanced algorithms) without Imposing the engineering challenge of implementing DSP algorithms on (inefficient) general-purpose processors.
The XRAN Forum was established in 2016, releasing its first specification in 2018 for fronthaul communication between the DU and the RU, XRAN member-ship included AT&T, Deutsche Telekom, KDDI, NTT Docomo, SK Telecom, Telstra, and Verizon which made it more operator-centric compared to G-RAN which was more vendor-centric. developing standards for interfaces between wireless network components targeting Interoperability between those components.The XRAN Forum defined the use of NETCONF/YANG standards for configuring and managing RAN architecture as well as the first versions of what now are the O-RAN CUS plane standards. At the Mobile World Congress (MWC) 2018, xRAN and the O-RAN Alliance announced their merger ensuring the adoption of the XRAN standards into O-RAN.
Open vRAN, announced by Cisco in MWC 2018, was a virtualized RAN architecture using general-purpose computing for the implementation of wireless standards, initially only supported by a single operator (Reliance Jio). The Open vRAN ecosystem has developed multiple successful demos and trials on 3GPP and O-RAN standards
The Telecommunications Infrastructure Project (TIP) was founded by Facebook in 2016, and supported by Deutsche Telekom, Intel, Nokia, and SK Telecom. concept of a software-defined RAN and started the OpenRAN project. The Target of OpenRAN is to disaggregate hardware and software and resulting from this to run wireless stacks on general-purpose hardware. TIP is less focused on standards development and more on use-case definition and hardware/software implementations. TIP and the O-RAN Alliance announced a liaison agreement at MWC 2020 to ensure their alignment in developing interoperable O-RAN solutions
#### 2. Spectrum: Enabling 5G
Ultimately, spectrum is the enabler for wireless deployment, and 5G deployments are no exception to this. We differentiate between:
* licensed spectrum that is owned by large operators deploying (typically) nationwide networks,
* licensed spectrum that is owned by private companies, and
* unlicensed spectrum that is available to anybody adhering to spectral usage models.
**License Operator Spectrum**
the 5G waveform is not significantly more efficient (810%) compared to the 4G waveform. If the spectrum is not being made more broadly available by industry regulators, the chances for successful deployment of SG are limited.
the first and most obvious path to making more spectrum available is freeing up previously un- or under-utilized spectrum. Consider the 3x GHz band that has traditionally been used for everything from fixed wireless access to satellite services. Different slices of this spectrum have been made available across the globe for licensing by wireless operators. This spectrum has a relatively large bandwidth (typically up to 100 MHz) and reason-able propagation characteristics. This spectrum is considered the cornerstone of 5G deployment.
The existing 2G, 3G, and 4G spectrum is slowly being repurposed for 5G use. The 2G (GSM) bands may still have legacy use (loT and other purposes) but the 3G spectrum is underutilized and can be repurposed for 5G deployment. Dynamic Spectrum Sharing enable 4G and 5G networks to share RF bandwidth to gradually transition spectrum usage as consumer equipment upgrades take place,
Low-band spectrum dedicated to loT use cases is also under consideration, reusing traditional television bands for 3GPP operation, given that television services are moving to digital/IP-based.
The largest amount of spectrum freed for licensed (operator) 3GPP use is in the mmWave bands, These wide (GHz 1) bands provide step function in capacity but come with technology standards through poor propagation characteristics that force deployment of much smaller cell sizes, overlay networks
**License Private Spectrum**
Deployment of private networks requires the availability of spectrum to deploy the network on. Spectrum availability typically defines the deployment format. There is no harmonized spectrum for private networks across the globe. By implication, equipment choice, RF regulation, and cost will end up varying by region. Government harmonization efforts are underway but are not expected to solve this challenge in the short-term future.
**Unlicense Spectrum**
As mentioned earlier, mmWave spectrum is a key to unlocking 5G potential. Licensed mmWave spectrum for 5G is mainly in the 24-26, 28, and 39 GHz bands. Another option is to use unlicensed spectrum in, 7 GHz bands. 3GPP defined the use of unlicensed spectrum already for 4G/LTE. In 5G, NR- Unlicensed (NR-U) standards define the use of what traditionally would be Wi-Fi spectrum for use with the 5G/NR waveform in a coexistence scenario. This allows Wi-Fi bands to supplement data throughput. This is known as LAA (License Assisted Access) or anchored NR-U
Technology challenges to address when supporting NR-U include:
* Spectrum sharing with existing users including Dynamic Frequency Selection, Listen-Before-Talk, and Transmit Power Control techniques and
* low transmit power support which constrains coverage to (largely) indoor operation, just like Wi-Fi.
Spectrum in the 6-7 GHz band is an obvious candidate for NR-U deployment
#### 3. Traditional base station architecture
At a high level, these systems include the following functional components that are described in more detail elsewhere in this document and are shown in below :

User plane PDCP and transport
* Transport functions include IP/IPSec and GTP tunneling to carry the user IP packet between the RAN and the core network.
* POCP key functions include air interface ciphering, packet (re-ordering and retransmission. and header compression.
User plane MAC/RLC
* RLC functions include packet segmentation and retransmission.
* MAC layer functions include wireless air Interface scheduling, packet concatenation and multiplexing, and HARQ retransmission
High physical layer
* Functions include packet encoding/decoding including cyclic redundancy.check
* Scrambling rate adaptation, and modulation
* Frequency-domain grid (resource element) mapping.
Low-physical layer
* 3GPP functions include time2frequency conversion (OFDM modulation) and optionally beamforming.
* Non-3GPP-defined functions are digital front-end (DFE) processing such as up/down conversion and filtering, crest factor reduction, and digital pre-distortion.
RF
* Converts the digital baseband 10 signal into a high-power radio frequency signal that is transmitted over the air (and vice versa)
* Control plane
**All in one base station**
Built and deployed in the 1980s and 1990s, 1G and 2G systems were architected as a system in a box where all components described above were integrated into a single unit, with coax cables toward the RU that is mounted on top of the RF tower conceptualized.
The internal architecture of the all-in-one base station was highly proprietary and not visible to the network operator. Given its all-in-one nature, there was no possibility to mix and match components from different vendors

**3G/4G/5G Macro Cell**
Starting from 3G standard support in the 2000s and migrating to 4G/LTE in the 2010s, large vendors started to disaggregate the base station by splitting the radio head from the baseband through a semi-standardized interface: Common Public Radio Interface (CPRI) or Open Base Station Architecture Initiative (OBSAI), the implementation was made highly proprietary through the use of optional features, the disaggregation achieved the goal of removing high-cost (RF power coax) cabling but did not allow for vendor mix and match between baseband and radio head.

both CPRI and OBSAI standards use proprietary serialization/deserialization standards and application-specific (silicon) devices for their implementations.
As system performance requirements increased over time, the base station architecture evolved to separate into two main components: The Network Interface Card (NIC) and the Line Card, as shown for a three-sector base station.
This evolution allows better scalability to increase performance from a single sector to a sector, six-sector, and above.
At the same time, the system vendor landscape changed during the 3G and 4G decades. 3G and first-generation base stations were developed by many companies facing Intense competition, the industry went through a sequence of mergers during the 3G/4G period, with the famous five": Ericsson, Huawei, Nokia, Samsung, and ZTE capturing ~95% of the Infrastructure market.
#### 4. 5G base station architecture
**Integrated Small Cell**
The integrated small cell (ISC) in many ways is a massive size, power, and cost optimized version of the all in one base station that we describe earlier.

Define as a base station in a box and implemented as a base station on a chip, the ISC is a targeting 2 market:
* Coverage limmitation, for those user who have courage issues (dropped cal, too few bars, and low internwt troughput, an ISC can provide an in home solution at a reasonable cost)
* Capacity enhancement, high traffic areas and traffic rate that can be beyond the capacity of the traditional macro base station, especially when the location of the high traffic area is at near the cell edge,
First-generation ISC (femtocells), the femtocell concept has never been adopted as widely as initially anticipated and as a result, the number of chipsets/products supporting this market has diminished over time. Reasons for the lack of market traction include:
* Interference with macro base station
* Consumer value proposition
* Alternative solution such as WI-FI solve (pieces) of the problem in an often more cost-effectie way
The ISC is expected to play a larger role in 5G deployments because of the physical characteristics of the deployments in higher frequency bands (C-Band, mmWave).
**Pico/Microcell**
The Pico/micro follows much the same concept of physical implementation as the ISC, but at a larger scale, supporting typically multiple concurrent RF bands and potentially multiple operators, RF output power / antenna can be higher as the pico/microcell is owned and managed by the wireless network operators

The higher output power of the Picocell allows much less dense deployment compared to ISC but still provides the required capacity enhancement
**Distributed Antenna Systems**
A different physical implementation but target the same goal as ISC or Pico/Microcells and that is coverage and capacity enhancements, these systems rely on a central base station (potentially reused from a macro base station system design) connecting to multiple/many (low-power, low-cost) RUs that provide RF coverage over a wider geographical range.
The DAS design reuse from traditional macro base stations implies that the solutions are inherently compatible with macro systems and benefit from the same hardware/software enhancements over time. DAS systems an interesting value proposition to the system vendors that can now leverage existing engineering work to a large extent

**Massive Multiple Input Multiple Output**
The use of MIMO for capacity extension to move from single antenna deployments to two, four, or eight antennas is nothing new: both 3GPP and Wi-Fi systems have employed these techniques for many years. What massive MIMO does is increase the antenna count to much higher numbers (e.g., 32 or 64), to enable a step function in the potential throughput of the system, without changing the system architecture of the traditional "macro base station" split between the base station and (now, more complex) radio head is maintained as shown :

Challenges to make massive MIMO work include the following:
* Raw compute requirements and compute precision, especially in the radio to enable signal processing from a large number of antennas.
* System scalability
* Power consumption associated with the above.
* Time and frequency synchronization between all the antenna elements.
**C-(as in Centralized) Radio Acess Network**
A C-RAN system can be implemented with the same/similar components as a traditional macro base station, just by increasing the amount of processing power targeting deployments in dense urban environments where there is not enough space to deploy individual macro cells

#### 5. Functional Splits
Given high product development costs and timelines, the challenge is now to define the appropriate split point in the 3GPP processing stack as well as interoperable physical and logical interfaces that allow a minimum set of physical products to target as broad as possible an O-RAN market.
3GPP standards started to define these functional splits in 38.801,2 to formalize potential protocol split options, without dictating an implementation. Functional splits are intended to allow functions to run in a central location (eg, the IT room in an enterprise deployment) versus distributed in the radio heads (the antenna units that are connected to the baseband unit)

The picture shows that 3GPP allows for any functional split. Practical implementations zoom in on specific use cases and involve trade-offs that center around the following four issues:
* Fronthaul interface throughput and latency requirements. As more functionality is pushed toward a central location (lower-level split), fronthaul throughput increases and latency requirements get tighter.
* Implementation complexity. There is a benefit to a low-complexity radio head (size. weight, power, and design efforts are low) which tends to be supported with a lower level (Option 7/Option 8) split.
* Feature support. Centralization of processing can allow for more advanced features to be implemented such as Coordinated Multipoint Processing.
* Resource sharing. As we discussed, one of the prime objectives of early C-RAN initiatives was resource pooling/sharing given the peak versus average use of RF resources.
**Split 8**, This is the traditional 3G/4G/5G macro base station split the only digital functionality left in the radio head is up/down sampling and DFE including signal conditioning and filtering which are simple.
even though CPRI and OBSAI standards are publicly available, their "optional features" effectively make them proprietary, blocking interoperability between base station and radio head vendors.
An alternative physical implementation for this interface is Ethernet through standards such asCPRI over Ethernet or eCPRI. Moving to Ethernet removes the proprietary aspects of the standard but does not fix the high bandwidth requirements associated with baseband interfacing.
**Split 7**, within the option 7 split, we define three subcategories of incremental offload to the radio head as shown in below:

Option 7-1, Incrementally, we can offload resource element mapping and beamforming components to the radio head to make Option 7-2. consider massive MIMO systems where the number of logical layers is (much) smaller (say, 8 layers) than the number of physical antennas , the downlink (transmit) chain only but assume the equivalent for the uplink. Compute and IQ sample 10 bandwidths scale with several layers before the beamforming operation and with several antennas after the beamforming operation. In an 10-constrained scenario where the number of physical antennas is higher than the number of logical layers.
Option 7-2, becomes an obvious partitioning candidate. we note that in the downlink (only!), operations of layer mapping and precoding are relatively of Low- Complexity and need low computational effort.
Option 7-3, takes advantage of this by sending unmodulated bits from the base station to the radio head, thus lowering 10 bandwidth even more. This option only downlink because, in the uplink direction, channel estimation/equalization is still done in the (centralized) base station.

Option 6 is a MAC/PHY split where messages between both stacks are exchanged over a standardized, network-based interface (nFAPI being a key candidate, see next). This removes any physical layer processing from the centralized location, thus making it very software and virtualization-friendly.
Options 5, 4, and 3 similarly split the upper stacks to offload more and more processing to the radio head. However, given that the 10 bandwidths within the Layer-2 stack are relatively similar (so little benefit to be had from a fronthaul capacity point of view) and that MAC/RLC stacks are typically developed in a tightly coupled manner, these options have not proven to be very popular in the industry.
#### 6. Coordinated Multipoint
Coordinated Multipoint (COMP) is intended to mitigate cell Interference and Improve network capacity, specifically for cell-edge UEs-hence improving system-level coverage. Instead of mitigating interference, multiple base stations (or technically: Transmit Receive Points (TRP)) could be operating to transmit/receive the same signal, at the same time to/from this single user, where the signals to/from both base stations are combined to create a better signal-to-noise (SNR) ratio to the user and hence improved coverage. This cis called COMP.

without centralization, many COMP techniques become tough or impossible to implement COMP may be the feature that drives the centralization of processing rather than ISC solutions.
**Open Radio Access Network Supported Functional Split**
Popular functional split options include:
* Centralized versus distributed and radio head processing along 3GPP Option 2 and Option 7 splits where the bulk of the physical, MAC, and upper layers are run in centralized locations, and the RUS implement only antenna-associated functions.
* Integrated small cell-most of the protocol stack is integrated into a single unit allowing for very fine granularity of deployment
**Central Unit/ Distributed Unit/ Radio Unit**

The CU serves as the primary function in the user plane (UP), specifically handling the PDCP function. This software-centric role operates on generic server platforms and supports IP/IPSec backhaul tunneling and GTP for packet transport across the network. Unlike the DU, the CU's functionality is not bound by real-time constraints or dependent on specific operating systems or hardware features, making it adaptable to server/software-centric solutions that scale performance through increased CPU cores and interfaces.
In contrast, the DU's scalability is directly tied to the number of deployed radios, requiring individual MAC/RLC and high physical layer stack implementations for each radio. The real-time demands of radio transmission and reception necessitate a more embedded and tightly coupled implementation, even in software-centric environments. This distinction from the CU allows the DU to operate in an environment less focused on cloud/virtualization-centric approaches, maintaining a closer link between functionality and the resources it utilizes.
To summarize, the CU, primarily responsible for PDCP in the user plane, is adaptable and scalable through software-centric solutions, while the DU, intricately linked to real-time requirements of deployed radios, operates in a more embedded environment, distinct from cloud-centric approaches.
**Option 7_2x**
The DU-RU split is a pivotal aspect, balancing the goal of minimizing RU complexity for power efficiency and cost-effectiveness against the need to reduce fronthaul bandwidth. The xRAN standard, later embraced by the O-RAN alliance, introduced the "7 2x" split, also known as the Lower Layer Split/CU plane ("lls-CU"). While closely resembling 3GPP Option 7-2, this split provides the flexibility to implement precoding/digital beamforming in either the DU or the RU, a choice denoted by RUs as "Category A" or "Category B," respectively. Category B is particularly suitable for systems with a higher antenna count than the logical layer count, as demonstrated in the earlier example of massive MIMO.
Implementing Category B RUs introduces complexities, notably in the transport of essential control information between the DU and the RU. This trade-off enables a tailored approach based on specific system requirements and priorities.
**nFAPI**
Functional split 6 establishes the connection between the base station and the radio head through an Ethernet network interface at the MAC/PHY boundary. While not defined by 3GPP or O-RAN, the nFAPI (Networked Femto Application Programming Interface) standard is noteworthy in this context. Originating from the femto API, a long-standing industry standard for connecting L2 and L1 stacks in different vendor environments, nFAPI facilitates interoperability among software vendors. This standard, introduced by the Small Cell Forum in the late 2000s for femtocells, extends the vendor-independent API concept to a networked version. It supports O-RAN and similar implementations with a centralized/virtualized MAC layer and a network-connected physical layer, applicable to both 4G (4G-nFAPI) and 5G (5G-nFAP!).
#### 7. A real-life example: enterprise 5G networking
The first thing is to establish requirements which is a process that covers the systems architecture team, marketing, and other customer-facing organizations as well as hardware and software teams.
Network installation and maintenance, who will run the network ?
* Self install versus professional install
* who is the system integrator ? when considering system integrator choice, consider what the target features of the system will be:
1). Network Services
2). Client Equipment
3). Indoor versus Outdoor deployment, which impacts both RF aspecs as well as form factor and other
4). Regulatory requirement location, transmit power, sensing, and registration are unique per geography as we disscussed
5). Sequrity requirements
6). system optimazation point, what do we pick as functional and performance minimum and maximum?
* Who are the user of the network ?
1). Internal only or visitors and guests? Internal use only implies that the test environment can be greatly simplified: the breadth of the connected device(s) (types) is very different as this changes the scope of feature development and testing.
2). What are the performance requirements? There is no need for wide bandwidth operation if the client does not support this. Sometimes, we need to optimize for latency rather than bandwidth, and so on.
* What are the applications running on the network and what are derived key performance indicators ?
1). Application definition.Do we need to support local (edge) computing or only provide a wireless network/pipe without concern for other application presence? Do we need to co-locate a core network or is this handled elsewhere? A well-defined application/use case allows the system architect to derive requirements from the elements discussed next rather than having to establish them individually.
2) .What are throughput and latency requirements? Throughput is defined as both single-user peak throughput and combined (network-level) aggregate performance of overall users. .
3) The target user count includes a definition of both connected users who are visible to the control plane of the system but are not transmitting or receiving data at all times (e.g., an idle phone) as well as active users who are defined as users that are actively transmitting and/or receiving data.
4) what are the coverage requirements?
* Total cost of ownership
Maybe the most important of all, this is plit between network cost, network maintenance, and end user equipment.
* RF aspects
The RF aspects that define the next level of dimensioning. Spectrum allocation needs to be matched to the throughput requirements and by implication, network planning needs to include an assessment of the required system throughput. The RF band selection. Other aspect required RF bandwith which define the peak throughput that system can archive for an individual user
#### 8. Summary and conclusions
The O-RAN standard evolved from SDN initiatives, extending from wireline to wireless. 5G's first enabler is the global availability of new spectrum in licensed and private spaces for industrial and enterprise use. Nontraditional 5G spectrum drives diverse deployment options, from ISCS to mmWave and massive MIMO, necessitating scalable implementations across various scales. This fuels a vendor ecosystem and standardized interfaces in the RAN domain.
The O-RAN Alliance, along with standards like 3GPP, IEEE, and others, defines functional splits and interfaces within the RAN. This introduces key concepts like central units, distributed units, radio units, and Integrated Small Cells, forming the core of O-RAN deployments. Understanding system design involves examining an example, such as an indoor, enterprise deployment catering to small and medium businesses. This example helps the system architect determine key aspects like building necessary components, establishing connectivity, setting performance targets, and more. We'll refer to this example throughout the tutorial to illustrate relevant dimensioning aspects.
#### 9. References
[1] O-RAN Alliance, available at https://www.o.ran.org
[2] Study on new radio access technology: Radio access architecture and interface. TR,38(801), 2016
[3] Small Cell Forum, Available at https://www.smallcellforum.org
#### 10. Further reading
"study on new radio access technology: radio access architecture and interfaces, V14.0.0 (2017-03)",3GPP, Sophia Antipolis, France, Rep. TR 38.801, 2017.
802.1CM Time sensitive networking for frounthaul (802.1CM). Available at https://1.ieee802.org/tsn/802-1cm/.
---