olves mapping the application (say, a centralized unit (CU), a distributed unit (DU) or a radio unit (RU)) to the available hardware, or other way around, defining the required hardware to satisfy application requirements. Application mapping is done for multiple reasons. First, it builds confidence that the use-case can be met by deter- mining the technical feasibility of the use-case to within certain margins of uncertainty or error. Second, it defines early in the process where focus areas of performance are. Identifying potential performance bottlenecks early on allows us to dedicate internal or sup- plier resources to these areas and to track performance for key topics during the implemen- tation cycle SO that support can be brought in on-time, or hardware modifications are identified early as possible in the project. System mapping is about identifying which tasks need to be executed on each available hardware resource. Once we establish this mapping, we can define communication require- ments (message rates, sizes, etc.) between components, utilization of each component, and so on. Some level of basic automation can be useful, this can be as simple as a spreadsheet calculator or as complex as a fully automated system model in a dedicated tool. Centralized/distributed unit use-case dimensioning for throughput Per the Federal Communications Commission (FCC), an information transfer rate (in either uplink or downlink) of 768Kbps or more defines a connection as "broadband" in the United States. Even though the definition is somewhat ambiguous (is this a theoretical or Open Radio Access Network (O-RAN) Systems Architecture and Design. DOI: https://doi.org/10.1016/B978-0-323-91923-4.00011-2 © 2022 Elsevier Inc. All rights reserved. 104 Open Radio Access Network (O-RAN) Systems Architecture and Design measurable throughput?), it sets the first definition of what the expected consumer behavior of a broadband connection is. Most broadband systems-be it wired or wireless-make use of a shared medium (wireline: consid