C-RAN

C-RAN

C-RAN (Cloud-RAN), also referred to as Centralized-RAN, is an architecture for cellular networks. C-RAN is a centralized, cloud computing-based architecture for radio access networks that supports 2G, 3G, 4G, 5G and future wireless communication standards. Its name comes from the four 'C's in the main characteristics of C-RAN system, "Clean, Centralized processing, Collaborative radio, and a real-time Cloud Radio Access Network". == Background == Traditional cellular, or Radio Access Networks (RAN), consist of many stand-alone base stations (BTS). Each BTS covers a small area, whereas a group BTS provides coverage over a continuous area. Each BTS processes and transmits its own signal to and from the mobile terminal, and forwards the data payload to and from the mobile terminal and out to the core network via the backhaul. Each BTS has its own cooling, back haul transportation, backup battery, monitoring system, and so on. Because of limited spectral resources, network operators 'reuse' the frequency among different base stations, which can cause interference between neighboring cells. There are several limitations in the traditional cellular architecture. First, each BTS is costly to build and operate. Moore's law helps reduce the size and power of an electrical system, but the supporting facilities of the BTS are not improved quite as well. Second, when more BTS are added to a system to improve its capacity, interference among BTS is more severe as BTS are closer to each other and more of them are using the same frequency. Third, because users are mobile, the traffic of each BTS fluctuates (called 'tide effect'), and as a result, the average utilization rate of individual BTS is pretty low. However, these processing resources cannot be shared with other BTS. Therefore, all BTS are designed to handle the maximum traffic, not average traffic, resulting in a waste of processing resources and power at idle times. == Evolution of base station architecture == === All-in-one macro base station === In the 1G and 2G cellular networks, base stations had an all-in-one architecture. Analog, digital, and power functions were housed in a single cabinet as large as a refrigerator. Usually the base station cabinet was placed in a dedicated room along with all necessary supporting facilitates such as power, backup battery, air conditioning, environment surveillance, and backhaul transmission equipment. The RF signal is generated by the base station RF unit and propagates through pairs of RF cables up to the antennas on the top of a base station tower or other mounting points. This all-in-one architecture was mostly found in macro cell deployments. === Distributed base station === For 3G, a distributed base station architecture was introduced by Ericsson, Nokia, Huawei, and other leading telecom equipment vendors. In this architecture the radio function unit, also known as the remote radio head (RRH), is separated from the digital function unit, or baseband unit (BBU) by fiber. Digital baseband signals are carried over fiber, using the Open Base Station Architecture Initiative (OBSAI) or Common Public Radio Interface (CPRI) standard. The RRH can be installed on the top of tower close to the antenna, reducing the loss compared to the traditional base station where the RF signal has to travel through a long cable from the base station cabinet to the antenna at the top of the tower. The fiber link between RRH and BBU also allows more flexibility in network planning and deployment as they can be placed a few hundred meters or a few kilometers away. Most modern base stations now use this decoupled architecture. === C-RAN/Cloud-RAN === C-RAN may be viewed as an architectural evolution of the above distributed base station system. It takes advantage of many technological advances in wireless, optical and IT communications systems. For example, it uses the latest CPRI standard, low cost Coarse or Dense Wavelength Division Multiplexing (CWDM/ DWDM) technology, and mmWave to allow transmission of baseband signal over long distance thus achieving large scale centralised base station deployment. It applies recent Data Centre Network technology to allow a low cost, high reliability, low latency and high bandwidth interconnect network in the BBU pool. It utilizes open platforms and real-time virtualization technology rooted in cloud computing to achieve dynamic shared resource allocation and support multi-vendor, multi-technology environments. == Architecture overview == C-RAN architecture has the following characteristics that are distinct from other cellular architectures: Large scale centralized deployment: Allows many RRHs to connect to a centralized BBU pool. The maximum distance can be 20km in fiber link for 4G (LTE/LTE-A) systems, and even longer distances (40~80km) for 3G (WCDMA/TD-SCDMA) and 2G (GSM/CDMA) systems. Native support to Collaborative Radio technologies: Any BBU can talk with any other BBU within the BBU pool with very high bandwidth (10 Gbit/s and above) and low latency (10 μs level). This is enabled by the interconnection of BBUs in the pool. This is one major difference from BBU Hotelling, or base station Hotelling; in the latter case, the BBUs of different base stations are simply stacked together and have no direct link between them to allow physical layer co-ordination. Real-time virtualization capability based on open platform: This is different from traditional base stations built on proprietary hardware, where the software and hardware are close-sourced and provided by single vendors. In contrast, a C-RAN BBU pool is built on open hardware, like x86/ARM CPU based servers, and interface cards that handle fiber links to RRHs and inter-connections in the pool. Real-time virtualization ensures that resources in the pool can be allocated dynamically to base station software stacks, say 4G/3G/2G function modules from different vendors, according to network load. However, to satisfy the strict timing requirements of wireless communication systems, the real-time performance for C-RAN is at the level of tens of microseconds, which is two orders of magnitude better than the millisecond level 'real-time' performance usually seen in Cloud Computing environments. == Similar architecture and systems == KT, a telecom operator in the Republic of Korea, introduced a Cloud Computing Center (CCC) system in their 3G (WCDMA/HSPA) and 4G (LTE/LTE-A) network in 2011 and 2012. The concept of CCC is basically the same as C-RAN. SK Telecom has also deployed Smart Cloud Access Network (SCAN) and Advanced-SCAN in their 4G (LTE/LTE-A) network in Korea no later than 2012. In 2014, Airvana (now CommScope) introduced OneCell, a C-RAN-based small cell system designed for enterprises and public spaces. == Competing architectures in cellular network evolution == === All-in-one BTS === One major alternative solution that is addressing similar challenges of RAN, is the small size, all-in-one outdoor BTS. Thanks to the achievements in the semiconductor industry, all the functionality of a BTS, including RF, baseband processing, MAC processing and package level processing, can now be implemented in a volume of <50 liters. This makes the system small and weatherproof, reduces the difficulty of BTS site choice and construction, eliminates the air conditioning requirement, and thus reduces operational costs. However, because each BTS is still working on its own, it cannot readily make use of the collaboration algorithms to reduce the interference between neighboring BTSs. It is also relatively hard to upgrade or repair because the all-in-one BTS units are usually mounted near the antenna. More processing units in less-protected environments also implies a higher failure rate compared to C-RAN, which only has the RRU deployed outdoors. The advantage of Cloud RAN lies in its ability to implement LTE-Advanced features such as Coordinated MultiPoint (CoMP) with very low latency between multiple radio heads. However, the economic benefit of improvements such as CoMP can be negated by the higher backhaul costs for some operators. === Small cell === The main competition between small cell and C-RAN occurs in two deployment scenarios: outdoor hotspot coverage and indoor coverage. == Academic research and publications == As one of the promising evolution paths for future cellular network architecture, C-RAN has attracted high academic research interest. Meanwhile, because the native support of cooperative radio capability built into the C-RAN architecture, it also enables many advanced algorithms that were hard to implement in cellular networks, including Cooperative Multi-Point Transmission/Receiving, Network Coding, etc. In October 2011, Wireless World Research Forum 27 was hosted in Germany, when China Mobile was invited to give a C-RAN presentation. In August 2012, IEEE C-RAN 2012 workshop was hosted in Kunming, China. CRC Press published a book, "Green Communications: Theore

System integrity

In telecommunications, the term system integrity has the following meanings: That condition of a system wherein its mandated operational and technical parameters are within the prescribed limits. The quality of an AIS when it performs its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorized manipulation of the system. The state that exists when there is complete assurance that under all conditions an IT system is based on the logical correctness and reliability of the operating system, the logical completeness of the hardware and software that implement the protection mechanisms, and data integrity.

Gcore

Gcore is an edge AI, cloud, network, and security company headquartered in Luxembourg. Founded in 2014, the company provides low-latency services to industries including finance, healthcare, manufacturing, gaming, media and telecommunications internationally. As of March 2024, its global network includes over 180 Points of Presence (PoPs) across six continents. == History == Gcore was founded in 2014 in Luxembourg. The company built its own content delivery network, originally designed for the needs of the gaming industry. In 2016, Gcore's infrastructure expanded to multiple regions that were underserved by hyperscale cloud providers. In 2020, the company formed partnerships with Intel and Equinix. In 2022, Gcore launched the European AI Cloud, providing access to infrastructure for machine learning tasks. In March 2024, Gcore announced the acquisition of a web application and API protection (WAAP) solution from StackPath. In April 2024, Gcore received a commendation in the Industry Innovation category at the NVIDIA Partner Network Awards EMEA for developing the first speech-to-text technology for Luxembourgish, using the LuxemBERT AI model. In May 2024, Philipp Rösler, former vice-chancellor of Germany and federal minister of health joined the Gcore board. In July 2024, Gcore raised $60 million in a Series A funding round, marking the company's first external investment since its founding. In August 2024, Gcore was recognized as a Major Player in the IDC MarketScape report for European public cloud Infrastructure (IaaS) 2024 by IDC, the global market intelligence firm. In May 2025, Feiyu Xu became a member of the Gcore advisory board. == Network infrastructure == According to the company's website, Gcore has network locations in six continents: Europe, North America, Asia, South America, Africa, and Australia with over 14,000 peering partners and a network capacity exceeding 200 Tbps. According to a 2025 review by Geekflare, Gcore's CDN achieved an average global response time of around 30 milliseconds. Gcore offers AI cloud clusters, including a generative AI cluster with Nvidia GPUs in Luxembourg and additional sites in the Netherlands and Wales, as part of its European AI infrastructure. == Products and services == Gcore offers a range of services, including content delivery network (CDN), cloud computing,virtual machines, bare-metal servers, object storage AI infrastructure and inference, Kubernetes, video streaming, DDoS mitigation, web application and API protection (WAAP), Domain Name System (DNS). Gcore provides AI services and GPU cloud infrastructure to support model development, training, fine-tuning, and inference. In January 2025, the company introduced Everywhere Inference, a serverless inference solution that enables AI model deployment. == Controversies == Correctiv and Tageszeitung reported that Gcore supported the distribution of the TV network RT until April 2023, which has been under sanctions by the EU since March 2022. However, Gcore denies these allegations. == Collaborations == In 2024, Gcore and Qareeb Data Centres, a data center provider in the Middle East, launched a collaboration to integrate Gcore's AI, cloud and edge services across data centers in multiple Middle Eastern countries. In June 2025, Gcore joined the SmartSpires initiative, a €3.1 million smart city project co-funded by the Connecting Europe Facility. The three-year programme is coordinated by a public–private consortium including 5SKYE, the Luxembourg Institute of Science and Technology (LIST), Orange Luxembourg, and Gcore. The project aims to transform the Belval campus into a smart city by deploying 5G-enabled smart towers that integrate edge computing, artificial intelligence and IoT services. Within the consortium, Gcore acts as project coordinator and is responsible for the deployment of the edge infrastructure.

Dominant resource fairness

Dominant resource fairness (DRF) is a rule for fair division. It is particularly useful for dividing computing resources in among users in cloud computing environments, where each user may require a different combination of resources. DRF was presented by Ali Ghodsi, Matei Zaharia, Benjamin Hindman, Andy Konwinski, Scott Shenker and Ion Stoica in 2011. == Motivation == In an environment with a single resource, a widely used criterion is max-min fairness, which aims to maximize the minimum amount of resource given to a user. But in cloud computing, it is required to share different types of resource, such as: memory, CPU, bandwidth and disk-space. Previous fair schedulers, such as in Apache Hadoop, reduced the multi-resource setting to a single-resource setting by defining nodes with a fixed amount of each resource (e.g. 4 CPU, 32 MB memory, etc.), and dividing slots which are fractions of nodes. But this method is inefficient, since not all users need the same ratio of resources. For example, some users need more CPU whereas other users need more memory. As a result, most tasks either under-utilize or over-utilize their resources. DRF solves the problem by maximizing the minimum amount of the dominant resource given to a user (then the second-minimum etc., in a leximin order). The dominant resource may be different for different users. For example, if user A runs CPU-heavy tasks and user B runs memory-heavy tasks, DRF will try to equalize the CPU share given to user A and the memory share given to user B. == Definition == There are m resources. The total capacities of the resources are r1,...,rm. There are n users. Each users runs individual tasks. Each task has a demand-vector (d1,..,dm), representing the amount it needs of each resource. It is implicitly assumed that the utility of a user equals the number of tasks he can perform. For example, if user A runs tasks with demand-vector [1 CPU, 4 GB RAM], and receives 3 CPU and 8 GB RAM, then his utility is 2, since he can perform only 2 tasks. More generally, the utility of a user receiving x1,...,xm resources is minj(xj/dj), that is, the users have Leontief utilities. The demand-vectors are normalized to fractions of the capacities. For example, if the system has 9 CPUs and 18 GB RAM, then the above demand-vector is normalized to [1/9 CPU, 2/9 GB]. For each user, the resource with the highest demand-fraction is called the dominant resource. In the above example, the dominant resource is memory, as 2/9 is the largest fraction. If user B runs a task with demand-vector [3 CPU, 1 GB], which is normalized to [1/3 CPU, 1/18 GB], then his dominant resource is CPU. DRF aims to find the maximum x such that all agents can receive at least x of their dominant resource. In the above example, this maximum x is 2/3: User A gets 3 tasks, which require 3/9 CPU and 2/3 GB. User B gets 2 tasks, which require 2/3 CPU and 1/9 GB. The maximum x can be found by solving a linear program; see Lexicographic max-min optimization. Alternatively, the DRF can be computed sequentially. The algorithm tracks the amount of dominant resource used by each user. At each round, it finds a user with the smallest allocated dominant resource so far, and allocates the next task of this user. Note that this procedure allows the same user to run tasks with different demand vectors. == Properties == DRF has several advantages over other policies for resource allocation. Proportionality: each user receives at least as much resources as they could get in a system in which all resources are partitioned equally among users (the authors call this condition "sharing incentive"). Strategyproofness: a user cannot get a larger allocation by lying about his needs. Strategyproofness is important, as evidence from cloud operators show that users try to manipulate the servers in order to get better allocations. Envy-freeness: no user would prefer the allocation of another user. Pareto efficiency: no other allocation is better for some users and not worse for anyone. Population monotonicity: when a user leaves the system, the allocations of remaining users do not decrease. When there is a single resource that is a bottleneck resource (highly demanded by all users), DRF reduces to max-min fairness. However, DRF violates resource monotonicity: when resources are added to the system, some allocations might decrease. == Extensions == Weighted DRF is an extension of DRF to settings in which different users have different weights (representing their different entitlements). Parkes, Procaccia and Shah formally extend weighted DRF to a setting in which some users do not need all resources (that is, they may have demand 0 to some resource). They prove that the extended version still satisfies proportionality, Pareto-efficiency, envy-freeness, strategyproofness, and even Group strategyproofness. On the other hand, they show that DRF may yield poor utilitarian social welfare, that is, the sum of utilities may be only 1/m of the optimum. However, they prove that any mechanism satisfying one of proportionality, envy-freeness or strategyproofness may suffers from the same low utilitarian welfare. They also extend DRF to the setting in which the users' demands are indivisible (as in fair item allocation). For the indivisible setting, they relax envy-freeness to EF1. They show that strategyproofness is incompatible with PO+EF1 or with PO+proportionality. However, a mechanism called SequentialMinMax satisfies efficiency, proportionality and EF1. Wang, Li and Liang present DRFH - an extension of DRF to a system with several heterogeneous servers. == Implementation == DRF was first implemented in Apache Mesos - a cluster resource manager, and it led to better throughput and fairness than previously used fair-sharing schemes.

Griffon (framework)

Griffon is an open source rich client platform framework which uses the Java, Apache Groovy, and/or Kotlin programming languages. Griffon is intended to be a high-productivity framework by rewarding use of the Model-View-Controller paradigm, providing a stand-alone development environment and hiding much of the configuration detail from the developer. The first release is the fruit of the effort by the Groovy Swing team and an attempt to take the best of rapid application development, as indicated by its Grails-like structure, the agility of Groovy, and the availability of components for Swing. The framework was redesign from scratch for version 2, allowing different JVM programming languages to be used either in isolation or in conjunction. Supported UI toolkits are Java Swing JavaFX Apache Pivot Lanterna == Overview == Griffon aims to reduce the typical confusion that occurs with traditional Java UI development. Due to the MVC structure of Griffon, developers never have to go searching for files or be confused on how to start a new project. Everything begins with: lazybones create The generated project follows this structure: %PROJECT_HOME% + griffon-app + conf ---> location of configuration artifacts like builder configuration + controllers ---> location of controller classes + i18n ---> location of message bundles for i18n + lifecycle ---> location of lifecycle scripts + models ---> location of model classes + resources ---> location of non code resources (images, etc) + views ---> location of view classes + src + main ---> optional; location for Groovy and Java source files (of types other than those in griffon-app/) The builder infrastructure enables seamless integration of different widget libraries such as Swing, JIDE, and SwingX. In the first release, three sample applications are included : Greet, a Groovy Twitter client featured in the JavaOne 2009 Script Bowl, FontPicker, an application to view the available fonts on one's machine, SwingPad, a lightweight designer application for Griffon user interfaces. == Plugins == Griffon can be extended with the use of plugins. Plugins provide run-time access to testing libraries such as Easyb and FEST, and all widget libraries besides core Swing are provided as plugins. The plugin system allows for a wide range of additions, for example Polyglot Programming with Java, Apache Groovy, Kotlin. SQL and NoSQL datastores like Berkleydb, CouchDB, Db4O, Neo4j, NeoDatis, Memcached and Riak. == Publications == === Books === Features that would eventually become integral parts of Griffon (UI builders) were featured in these books: Groovy In Action (published by Manning) Beginning Groovy and Grails Books that cover Griffon: Griffon In Action (published by Manning) Beginning Groovy, Grails and Griffon === Magazine === GroovyMag for Groovy and Grails developers

Information space analysis

Within the field of information science, information space analysis is a deterministic method, enhanced by machine intelligence, for locating and assessing resources for team-centric efforts. Organizations need to be able to quickly assemble teams backed by the support services, information, and material to do the job. To do so, these teams need to find and assess sources of services that are potential participants in the team effort. To support this initial team and resource development, information needs to be developed via analysis tools that help make sense of sets of data sources in an Intranet or Internet. Part of the process is to characterize them, partition them, and sort and filter them. These tools focus on three key issues in forming a collaborative team: Help individuals responsible for forming the team understand what is available. Assist team members in identifying the structure and categorize the information available to them in a manner specifically suited to the task at hand. Aid team members to understand the mappings of their information between their organization and that used by others who might participate. Information space analysis tools combine multiple methods to assist in this task. This causes the tools to be particularly well-suited to integrating additional technologies in order to create specialized systems.

System requirements specification

A System Requirements Specification (SysRS) (abbreviated SysRS to be distinct from a software requirements specification (SRS)) is a structured collection of information that embodies the requirements of a system. A business analyst (BA), sometimes titled system analyst, is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers.