CLOUD RAN1 Cloud RANCLOUD RANAbstractMobile broadband is immensely important globally as a key socio-economic enabler, as evidenced by the continuing growth of data trafc on mobile networks. To meet this unabated growth in demand, cellular operators must increase their network capacity by using advanced wireless technologies like adding more network elements like cell sites, controllers, etc.According to growth estimation data, data trafc increases by 131 percent every year, while air interface grows 55 percent yearly. At the same time, ARPU is constantly decreasing.Per UMTS Forum Report 44, the total worldwide mobile trafc will reach more than 127 Exabytes in 2020, which is 33 times more than the 2010 gure.Signicantly, at least 80 percent of the trafc volume remains generated by users, leading to large variations in the total mobile trafc, in terms of time and space variations of trafc. Future mobile networks must be designed to cope with such variation of trafc and uneven trafc distribution, while at the same time maintainingpermanent and extensive geographical coverage in order to provide continuity of service to customers. In 2020, daily traffic per Mobile Broadband subscription in the representative Western European country will stand at 294 MB, and at 503 MB for dongles (67 times greater than in 2010).The cost of acquiring a new spectrum, deploying new wireless carriers, and evolving network technologies (e.g., from GSM to W-CDMA to LTE), while adding more processing capacity, new radios, and antennasand managing the resulting heterogeneous networkis becoming economically unsustainable and leads to a vicious cycle of demand.An increase in the number of base stations is resulting in more power consumption, higher interference, and reduced coverage and capacity due to interference. This also requires more radio network controllers.Radio Access Network (RAN) architecture requires solutions in the following areas:>Additional base stations and radio antennas without increasing the number of cell sites>Reconfigurable BSs to support multiple technologies>Resource aggregation and dynamic allocation >Cooperative radio technology for coordinated multi point transmission and reception>More capacity and coverage with reduced interference>Distributed antenna technology for increased coverage>Controller software enhancement to run on virtualization environment for lower costs and elastic capacity>Summarily reduce Capex and Opex, and overall TCOThis white paper provides an overview of the distributed RAN architecture called Cloud RAN, which addresses solutions for the different areas mentioned previously. It also provides a more detailed analysis of the Cloud radio network controller architecture.IntroductionIn a conventional cellular network, the antenna, RF equipment, digital processor, and baseband unit (BTS) sit in the cell site as shown in the Conventional Cellular Network diagram on the next page. This requires more power and real estate space, and additional directional antennas and big cell towers to support multi-frequency bands and new air interface technologies like LTE. Enhancing a conventional network to support data trafc demand in a current wireless network is economically unsustainable. 2 Cloud RANActive Antenna ArrayIn order to support increasing bandwidth demand, operators need to enhance their network to support multiple technologies, multiple frequency bands, and new air interface technologies. This requires new antennas to be installed, multiple directional antennas to support MIMO, beam forming, Rx diversity, etc.This also increases the number of antennas in an already dense network, which in turn increases interference between diferent cells and reduces the capacity of the cell. The end result is increases site costs. In the Active Antenna array solution, each element supports a connection to a separate transceiver element. The antenna array can support multiple transceivers, which addresses the problem of installing multiple antennas to support multiple air interface technologies, MIMO, beam forming, Rx diversity, etc.Each active antenna array has the transceivers (RF and digital components) hardware embedded with each antenna element inside the antenna array, rather than outside in a separate RF box called RRH or in a conventional TRDU/TMA. This reduces loss due to the RF connection between the antenna and external RF. With the built-in transceivers, the individual signals can be fed into diferent antenna elements to create focused vertical beams per each user, carrier, technology, etc., which can control the interference and increase cell capacity and coverage.Multi-band Radio Remote HeadsIn conventional networks, BTS/NodeB contains radio (RF and digital components) and baseband units connected to an antenna using coaxial cables.The Open Base Station Architecture Initiative (OBSAI) and the Common Public Radio Interface (CPRI) standards introduced standardized interfaces separating the server and the radio There is an immediate need to identify a solution that reduces the number of cell sites, efectively reuses resources, and employs recongurable basebands, multi-band radios, and distributed wideband antennas to support diferent air interface technologies.Cloud RAN architecture is based on distributed radio access network architecture consisting of the following network elements:>Active antenna arrays>Multi-band radio remote heads>Centralized baseband units>Metro cells >Radio network controllers on cloud>Common management server>SON server for seamless management and optimal network usageRural ZoneUrban ZoneConventional Cellular NetworkBase Station (BTS)MSCBSC(BTS)(BTS)Internet(BTS)Figure 1: CRAN Access Technology CloudCommonManagementServerIMS/OperatorServicesActive Antenna SystemSONServerCentralizedBasebandBank> 2G/2.5GRAN Servers> GSM/GPRS> UMTS> UMTS Femto GW> HeNBGW> WiFi Access GatewayControllers onCloudCoreNetwork> UMTS> HSPA> LTEeNB> LTE-ARemoteRadio HeadCoaxIPIPOpticalMacroSiteFemtoCells/WiFiInternetIP3 Cloud RANpart of the base station, the latter of which is supported by the Remote Radio Heads (RRH). A separate RRH is required for each frequency band to support multiple frequency bands and multiple sectors in a given geographical area. The number of RRH required proportionally increases, and in many of the macrocell deployments, RRH is in the top of the cell tower with the antenna to reduce the RF loss. In denser network deployments, increasing the number of RRH may not be feasible in all deployments, so RRH may have to be deployed on high-rise buildings, etc. This increases the overall cost, RF loss, and maintenance costs.Multi-band RRH (MB-RRH) are supported by multiple vendors for addressing the issues mentioned above. It can support multiple frequency bands and multiple technologies like GSM, WCDMA, and LTE in combination with the RRH units. This reduces the number RRH required to support multiple frequency bands and diferent technologies, while reducing the cell site costs, power consumption, and complexity.Centralized Baseband UnitsIn typical macrocell deployments, the baseband unit is located at the base of the cell tower along with the radio and other digital equipment. The cost of deploying new baseband units along with radios, antennas, etc. to support additional carriers, spectral bandwidth, different technologies, etc. and managing the heterogeneous network is becoming economically challenging and unsustainable.The centralized baseband is built on the concept of Software Defined Radio (SDR) with use of distributed radio signal processing and baseband processing units, which are software congurable and reduce the complexity of deploying BBU at the location of the cell site. The increase in additional carriers, spectral bandwidth, new technologies, etc. can be seamlessly supported by stacking a number of baseband units in the baseband pool and deploying remote MB-RRH and AAA with comparatively less cost and easy maintenance. The baseband and radio signal processing is distributed using the CPRI interface between BBU and remote radio equipment. The Common Public Radio Interface (CPRI) is an industry cooperation aimed at dening a publicly available specication for interface between the Radio Equipment Control (REC) and the Radio Equipment (RE), which in our case is the BBU and Remote Radio Head respectively. The scope of the CPRI specication is restricted to the link interface only (layer 1 and layer 2), which is basically a point-to-point interface. The Open Base Station Architecture Initiative (OBSAI) was introduced to standardize interfaces separating the Base-Station server and the radio part of the base station. Figure 2 depicts a CRAN architecture utilizing CPRI or OBSAI interface.Key features of this architecture (Architecture A) are:>Cells are distributed across processors and exibly connected to radio unit through high bandwidth (order of Gbps) optical ber links>Board level, link level redundancy could be provided>High-speed communication across sectors for efficient inter-cell information sharing for cooperative/coordinated Figure 2: CRAN Architecture A: Utilizing CPRI/OBSAI LinkUnitCloud RAN Unit High SpeedCPRI/OBSAI link over FiberUnit MRRC, S1-AP, X2-AP, RRM, SONCPRI/OBSAI EngineLayer 2- Cell 1Layer 2- Cell nLayer 2- Cell 1Layer 2- Cell 2Layer 1 -Layer 1 - Layer 1 -RRC, S1-AP, X2-AP, RRM, SONCPRI/OBSAI EngineLayer 2- Cell 1Layer 2- Cell nLayer 2- Cell 2Layer 1 -Layer 1 - Layer 1 -4 Cloud RANradio resource management, scheduling, and power control to optimize cell throughput and interference reduction >Reduced need for hardware at antenna sites>Utilizes optical links where already available to avoid laying new links, which may make infrastructure expensiveThe main disadvantage of this approach is the high-bandwidth link required between radio equipment and the central unit. For example, CPRI supports diferent line-bit-rate options ranging from 614 Mbps to 6.14 Gbps. Overlaying such high-bandwidth connections is a costly prerequisite and can be a big barrier to this solution becoming popular. To overcome this problem, if the split between radio equipment and control unit can be moved higher up the network stack (i.e., from below Layer 1 to between Layer 1 and Layer 2), then instead of sharing IQ samples, only the demodulated and decoded data and protocol information need to be shared over an IP-based link between the remote unit and the central unit. This considerably reduces the bandwidth requirement to approximately 200 Mbps for a 2x2 MIMO, 20 MHz cell. Figure 3 depicts CRAN Architecture utilizing IP link between radio unit and the central unit.Key features of Architecture Option B are:>Cloud RAN unit is connected with relatively low-bandwidth (order of 100 Mbps) IP links to Radio equipment siteIP connectivity should be through operator-managed network so that there is strict control over latency and jitter>Antenna site terminates IP links and carries out Layer 1 processing according to air Interface timing >Layer 3 and Layer 2 located in Cloud RAN unit. To handle impact of latency of IP link on 1ms, strict scheduling of LTE and modication in MAC will be required. A portion of MAC should also run in the baseband unit in the antenna site to control the time-critical L1 interface and relay messages between Cloud MAC and antenna Layer 1.>High-speed communication across sectors for efficient inter-cell information sharing for cooperative/coordinated radio resource management, scheduling, and power control to optimize cell throughput and interference reduction The main advantage of option B is it requires cheaper and lower bandwidth IP links between the cell site and central unit. However, the cell site will require more hardware compared with option A because Layer 1 and some part of Layer 2 are being executed in the cell site. In addition, the end-to-end latency increases due to IP link delay and variance characteristics.BBU POOLING:The pooling of processing resources for multiple cell sites at a central location (utilizing architecture option A or B) has many benets. Based on the capacity, coverage, and number of air interface technologies to support, additional BBU can be easily added and remotely managed. The cell sites need to have only RRH and antennas; this reduces the huge space, power consumption, and management overheads of the cell site. KEY BENEFITS OF BBU POOLINGCapex and Opex reductionThe hardware can be pooled across multiple cell sites in order to reduce the initial capital costs, as well as regular running (electricity, site rental, etc.) and maintenance costs.Figure 3: CRAN Architecture B: IP Link between Cloud RAN Unit and Antenna Site EquipmentCloud RAN Unit 1Cloud RAN Unit MHigh SpeedDelayIP LinkRRC, S1-AP, X2-AP, RRM, SONIP LinkLayer 2- Cell 1Layer 2- Cell nLayer 2- Cell 2Antenna Site 1Antenna Site NLayer 2- Cell 1Site ManagementIP LinkMAC(partial)MAC(partial)MAC(partial)Layer 1 -Layer 1 - Layer 1 -5 Cloud RANLoad Aggregation and Balancing:Baseband processing for multiple cell sites is aggregated based on the bandwidth requirement not increasing the number of cell sites. The BBU units can be dynamically distributed to diferent cell sites based on the usage patterns. Multiple Technologies Support The BBU units can be dynamically congured to support diferent air interface technologies based on network load and service requirements.High AvailabilityThe BBU pool has number of BBU units. During the failure of any single BBU, other active BBUs can share the load of the failed BBU, so that it can seamlessly recover. During multiple BBU failures, the active BBU units can be dynamically congured to share trafc loads from a number of cell sites supported by the BBU pool.Cooperative Multi-point Operation (CoMP)The BBUs connected to different cell sites are located in a centralized location, allowing the cell site information related to signaling, trafc data, resource allocation, channel status, etc. can be easily shared between BBUs. This information can be used to optimize the allocation of resources, handovers, call handling, scheduling for Inter Cell Interference Control (ICIC) and improve spectral efciency. The CoMP and ICIC are the key requirements of the LTE-A in the 3gpp Rel-11 specifications. Because the BBUs support macrocells and small cells, the coordinated multi-site processing helps optimize the mobility and ICIC between heterogeneous networks. SON SupportThe shared information of BBUs can be used for advanced SON features to optimize the various services. The SON can dynamically configure resources to be used for the cell site processing, optimize the handover between cells, manage inter-RAT handovers, conduct cell-load balancing, and efciently use HW resources. During very low load conditions, some of the BBUs can be switched of to save energy and help achieve green BTS.MetrocellsAs mentioned before, adding more macro cells to support increased capacity and coverage is not an optimal solution. In an efort to reduce the load on the macrocells, and to provide higher capacity and greater coverage, operators are deploying offloading solutions where the macrocells are offloaded to lowcapacity, lowpower small cells called metrocells. The metrocells can be deployed on lamp posts, buildings, etc. and are connected to the operator core network through the IP backhaul. These cells can be deployed in both indoor and outdoor environments.This provides an economically viable solution for the operator to increase cell density with less cost, efcient spectrum usage, and less time taken to extend capacity and coverage.Radio Network Controllers on CloudAs dened by NIST, cloud computing is a model for enabling ubiquitous, convenient, on demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management efort and service provider interaction. The radio network controllers in the cloud RAN solution are built using this cloud-computing model to support GSM BSC, UMTS RNC, HeNB-GW, MME, WiFi-GW functions with increased capacity, in addition to multiple technologies. This cloud computing model can also be extended to CN elements for supporting flexible open architecture to increase capacity, different technologies, efective reuse of resources, and high availability.Traditionally, radio access network controllers like BSC, RNC, H(e)NB-GW, etc. are built on specific hardware with customization. The controller application can only run on specic hardware and software solutions, and are built for supporting estimated capacity. The available resources are never used to their full capacity, which increases the TCO, time to market, and dependency on specific hardware and software vendor solutions.Software as Service (SaaS)Platform asService (PaaS)Infrastructureas ServiceCloud Computing Service ModelsEnd Application likecontroller applicationsApplication platform ormiddleware as a serviceCloud HW, CPU, Core,Disks, FabricFigure 4: Cloud Computing Service Models6 Cloud RANCloud computing architecture denes three diferent service models, as shown in the Figure 5 below, where COTS solutions can be used in diferent service layers to avoid using customized hardware and software solutions from specic vendors.The radio network controller applications in the cloud computing environment still need all the software and hardware layers as in the traditional telecom equipment. But hardware virtualization, OS abstraction layers, and middle layers are provided to the application through virtual service layers so that it can remain independent of underlying hardware and software components.Cloud computing is in the very early stages of adaption in the telecom controller space. Using controller applications as SaaS on the diferent vendor PaaS and IaaS is still a common interface supported by multiple vendors that is still evolving. The standard bodies like NIST and ETSI are working to define a standard interface for the diferent service layers. Per NIST, generally, interoperability and portability of customer workloads is more achievable in the IaaS service model because the building blocks of IaaS oferings are relatively well-dened (e.g., network protocols, CPU instruction sets, legacy device interfaces, etc.).The IaaS layer is supported by multiple vendors through their COTS virtualization solutions.A hypervisor called the virtual machine manager provides hardware virtualization so that multiple operating systems are able to run concurrently on a host computer. The virtual hardware is called a virtual machine and the operating system it runs is called the guest. Each guest OS instance running on VM acts as an individual server for the application. The diagram below shows the overview of the virtual servers.A virtual machine (VM) is a software implementation (i.e., a computer) that executes programs like a physical machine. Virtual machines are separated into two major categories based on their use and degree of correspondence to any real machine. A system virtual machine provides a complete system platform that supports the execution of a complete operating system (OS), while a process virtual machine is designed to run a single program and support a single process.A system virtual machine (virtual hardware), which provides an abstraction of a simple x86 PC with private CPU, memory, network interface (NIC), and le system, is used for controller virtualization. Each VM is independent of the VMM and other VMs.When the number of VMs increases complexity of I/O trafc, and hardware handling in VMM increases, application handling signicantly slows down compared with a non-virtualization environment.The PCI-SIG has dened a standard for how to virtualize SR-IOV (Single Root I/O Virtualization) where a physical device implements hundreds of images of itself, one for each VM.Each VM communicates with its own set of I/O queues, which can directly use the device without the performance cost of going through a VMM while ensuring isolation between the VMs. Figure 5: Virtual ServersBefore: 3 diferent servers for 3 operating systems and servicesAfter: Only 1 server required for 3diferent operating systems and servicesHardwareOS OSApp AppDOM UOS OSApp AppHardwareOS OSApp AppDOM UOS OSApp AppHardwareOS OSApp AppDOM UOS OSApp AppHardwareHardwareHardwareHardware7 Cloud RANVMware supports this technology with its ESXi VMM called the VMDirectPath. The VMDirectPath I/O allows a guest operating system on a virtual machine to directly access physical PCI and PCIe devices connected to a host. Each virtual machine can be connected to up to two PCI devices. PCI devices connected to a host can be marked as available for pass-through from the hardware advanced settings in the conguration for the host. Intel and AMD support hardware-based assistance for I/O virtualization processes and complement single-root I/O virtualization. Intels name for this technology is VT-d, while AMDs version is ADM-Vi.The controller applications in the cloud environment are based on third-party IaaS layer interfacing with guest OS/virtual machine or IaaS in the service-layer hierarchy. All software layers like guest Os, middle layers, controller-specic OAM, controller application, etc. which are above IaaS are provided by TEMs. The guest OS can be any standard OS like Linux, VxWorks, Solaris, etc. depending on the application architecture.The virtual server/cluster management is part of third-party IaaS solutions. This provides the mechanism to manage the virtualization environment, control the execution of the virtual machine, and loading the associated applications. Some of the key functionalities supported by virtual machine management are:>Centralized control and deep visibility into virtual infrastructure (create, edit, start, stop VM)>Proactive management to track physical resource availability, conguration, and usage by VMs>Distributed resource optimization>High availability>Scalable and extensible management platform>SecurityThere are multiple vendors supporting centralized control at the diferent levels in the virtualization environment. The VMware vCenter is one such solution that supports scalable and extensible management platforms as shown in the diagram on the next page.The operator can host the controller application software on the operators own private cloud or on a service providers cloud (community or public).Using a cloud computing environment for radio network controllers has the following advantages:Hardware IndependenceController software can run on COTS hardware available from different HW vendors, hence no binding with customized hardware solutions. Diferent applications can run on the same hardware so that available resources can be used on demand.Software IndependenceApplication software can run on COTS virtual machines available from diferent vendors as IaaS. The application is independent of the actual hardware used, so it can run on diferent hardwares with no application software changes. There is also no proprietary software supporting hardware independence.Resource PoolingThe different hardware types can be pooled to run multiple instances of application software to support increased capacity. The resources can be dynamically allocated, with different applications running on the same hardware. High AvailabilityUsing pooled resource to run controller applications takes care of single or multiple units failing within a pool of resources, while providing geo-redundancy, multi-tenancy, and elasticity.Reduced CAPEXUsage of the COTS hardware and software reduces TCO and time to market. Reuse of available resources with dynamic allocation helps use the full capacity of the resources, thus reducing the number of resources required. Reduced OPEXUse of common hardware and software reduces the cost of managing diferent customized solutions. The resource can be afectively used depending on the load conditions. Based on demand, some of the resources can be switched of in order to reduce electricity and other infrastructure costs (e.g., cooling, etc.).Elasticity, Best of Class PerformanceThe capacity of the system can change quickly according to need. The controller applications (RNC, BSC, etc.) run in virtual machines independent of the physical hardware. Third-party virtualization technology from diferent vendors can be used to host the application-specic OS, middleware, and applications. There are multiple vendors providing the virtualization IaaS layer. Some of the key solutions are VMware, KVM, and WR hypervisor.8 Cloud RANMultiple applications can run on the single platform with diferent VMs running different OSs using a multi-tenant model. In a multi-core environment, different applications can run on a diferent core with associated VM, guest OS, middle layer, and applications. The diferent controller applications allow common cloud computing architecture to dynamically use available resources.Common Management ServerAs previously mentioned, operators use more than one RAT to support wireless data trafc demand. The converged solutions AAA, RRH, multi-standard BBUs, and radio network controllers are used to support multiple technologies. Management of these converged network elements requires a common management server capable of supporting the FCAPS features for GSM, UMTS, and LTE network nodes. SON FunctionsIn cloud RAN network architecture, each network element is capable of supporting self-configuration, optimization, and autonomous recovery. SON, in this architecture, is based on decentralized algorithms as applicable at each individual network element. The operator may support multiple technologies like GSM, WCDMA, and LTE in the cloud RAN deployment. This requires network-level self-optimization to support automatic updates of network topology changes between E-UTRAN/UTRAN/GERAN networks.Information related to network load, performance, etc. of the diferent wireless technologies is used by the centralized function to dynamically allocate shared resources to diferent network elements in the cloud RAN and support load balancing. For example, when the GSM load is less but the UMTS is in the peak, the shared NEs like AAA and RRH can be congured to support additional cells, frequency bands, etc. When the network load is low, the set of network elements can be switched of wherever the load can be handled by a minimum set of network elements.Conclusion and Aricent Value PropositionAs discussed in the previous sections, the complexity of enhancing traditional networks to support increasing broadband capacity and coverage is not economically viable. There is immediate need to deploy distributed networks with centralized Figure 6: Controller Application Over IaaS layerDiferent Applications, middle layer, OAM, etc.An example of radio controller application on cloud environment is shown in the following diagram:VMMBSC RNCM/W M/WGuest OS Guest OS Guest OSH(e)NB-GWM/WCOTS VM ManagerCOTS SW/HWVM V-10Guest OSVMVM DiskV-10VirtualHWHypervisorPhysical Hardware (Servers or ATCA)VirtualHWVirtualHWGuest OS VM DiskVM V-10Guest OSVMVM DiskV-10Guest OSCore OS DiskFabric HW IO HWDisk DiskCPUCPUVM Disk9 Cloud RANbaseband units, RRHs, AAA, and radio network controllers on the cloud to reduce the complexity of introducing addition cell sites and adding additional antennas and radio components. The Radio network controllers on the cloud environment using virtualization technology reduce the infrastructure cost to support both multiple technologies and the complexity of managing multiple network elements.In the 3rd Generation Partnership Project (3GPP) international standardization group meeting held in June, 2012, energy saving, cost efciency, and support for diverse application and trafc types were identied as priority areas for Release 12. Deploying a cloud RAN architecture-based network can address these requirements. The NGMN group also initiated a CENTRALISED PROCESSING, COLLABORATIVE RADIO, REAL-TIME CLOUD COMPUTING, CLEAN RAN SYSTEM (P-CRAN) [11] project to address these issues.Implementation of a cloud RAN solution can save CAPEX up to 15 percent and OPEX up to 50 percent over five to seven compared with traditional RAN deployment, per the China Mobile report [1]. According to the Alcatel-Lucent Light Radio Economics analysis [2], these disruptive RAN architecture designs and innovative features can reduce overall TCO by at least 20 percent over ve years for an existing high-capacity site in an urban area with at least 28 percent reduction for new sites.Aricent is actively participating in and following emerging C-RAN architecture initiatives. Aricent eNodeB, EPC, and HeNB-GW IPRs are ready for CRAN architecture. eNodeB Framework>RAN on the cloud must cater to variable capacity requirements and host multiple cells. Aricent Layer 3 and Layer 2 including Scheduler, MAC, RLC, PDCP, GTPU, are scalable for multi-core architectures, support multiple form factors (femto, pico, micro) and different capacity requirements based on deployment.>Single instance of Aricent Layer 3 can handle multiple cells/sectors hosted on cloud RAN equipment and can interface with cells/sectors hosted on other cloud RAN equipment on the X2 link.> Aricent Layer 2 can handle one cell/sector per instance and multiple instances of Layer 2 can be utilized to handle multiple cells/sectors. >eNodeB software is modied to handle IP link (architecture option B described previously) interface between cell site unit and the central unit.Enhanced Packet Core Modules >RAN on the cloud must cater to variable capacity requirements and host multiple cells. Aricent Layer 3 and Layer 2 including Scheduler, MAC, RLC, PDCP, GTPU, are scalable for multi-core architectures, support multiple form factors (femto, pico, micro) and different capacity requirements based on deployment.>Single instance of Aricent Layer 3 can handle multiple cells/sectors hosted on cloud RAN equipment and can interface with cells/sectors hosted on other cloud RAN equipment on the X2 link.>Aricent Layer 2 can handle one cell/sector per instance and multiple instances of Layer 2 can be utilized to handle multiple cells/sectors. >eNodeB software is modied to handle IP link (architecture option B described previously) interface between cell site unit and the central unit.Universal SON Server (UniSON)>RAN on the cloud must cater to variable capacity requirements and host multiple cells. Aricent Layer 3 and Layer 2 including Scheduler, MAC, RLC, PDCP, GTPU, are scalable for multi-core architectures, support multiple form factors (femto, pico, micro) and different capacity requirements based on deployment.>Single instance of Aricent Layer 3 can handle multiple cells/sectors hosted on cloud RAN equipment and can interface with cells/sectors hosted on other cloud RAN equipment on the X2 link.>Aricent Layer 2 can handle one cell/sector per instance and multiple instances of Layer 2 can be utilized to handle multiple cells/sectors. >eNodeB software is modied to handle IP link (architecture option B described previously) interface between cell site unit and the central unit.10 Cloud RANAdditionally, Aricent is involved multiple services projects related to solution architecture, implementation, and eld support of C-RAN solutions. This includes Tier 1 OEMs in the area of multi-RAT BTS, virtual common hardware for RNC/BSC solutions, etc. Aricent is well-equipped to provide software frameworks, (eNodeB, EPC etc.), necessary resources, management framework and a strong delivery process to assist our customers for their own C-RAN solution. REFERENCES(1) http://www.google.com/url?sa=t&rct=j&q=china+mobile+c-ran&source=web&cd=1&ved=0CE0QFjAA&url=http%3A%2F%2Flabs.chinamobile.com%2Farticle_download.php%3Fid%3D63069&ei=ebXyT6uBAc7LrQfRnK2rCQ&usg=AFQjCNFDC6S_4Oth6_0vLobNzvfvrlouHw(2) http://www.alcatel-lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Resource_Ctr&LMSG_CONTENT_FILE=White_Papers%2FlightRadio_WhitePaper_EconomicAnalysis.pdf&REFERRER=j2ee.www%20%7C%20%2Ffeatures%2Flight_radio%2Findex.html%20%7C%20lightRadio%3A%20Evolve%20your%20wireless%20broadband%20network%20%7C%20Alcatel-Lucent(3) http://www.vmware.com/products/vcenter-server/overview.html(4) http://www.vmware.com/products/vsphere/mid-size-and-enterprise-business/overview.html(5) http://www.obsai.com/obsai/content/download/4977/41793/le/OBSAI_System_Spec_V2.0.pdf(6) http://www.cpri.info/downloads/CPRI_v_5_0_2011-09-21.pdf(7) http://csrc.nist.gov/publications/drafts/800-146/Draft-NIST-SP800-146.pdf(8) http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/RoadmapVolumeIIIWorkingDraft/NIST_cloud_roadmap_VIII_draft_110311.pdf(9) http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf(10) http://www.umts-forum.org/component/option,com_docman/task,doc_download/gid,2545/Itemid,213/(11)http://www.ngmn.org/workprogramme/centralisedran.htmlUniversal SON ServerSON ClientEMSENODEBTR69,aricent.com 2013 Aricent Group. All rights reserved.All Aricent brand and product names are service marks, trademarks, or registered marks of Aricent Inc. in the United States and other countries.