Lte pdf overview

Japan: Softbank 4. Uzbekistan: MTS Sweden: 1. South Korea: SK Tel 2. USA: Mosaic 2. Hungary: T- TeliaSonera Uzbekistan: Ucell 3. Canada: Rogers 6. Puerto Rico: Claro Mobile 1. Brazil: Sky 7. Uruguay: Antel 8. South Korea: KT 1. Germany: Vodafone 4. Saudi Arabia: Mobily 2. Norway: NetCom 5. UAE: Etisalat 1. Germany: T-Mobile 3. Fixed line replacem ent, data card and M obile WiFi w ith 3G dual m ode w ould be popular types at service launch.

M obile Phone in 3. The customized version needs a detailed discussion Operating System: with operator. Xiang Chen May, commercial network Jul, Nov. UK Dec. Canada Dec.

Poland Aug. Hong Sep. Japan Nov. Values for Areo2 n GL refarm ing satisfied Areo2 challenge and needs. LTE designed with a scalable carrier bandwidth from 1.

All interfaces between network nodes in LTE are now IP based, including the backhaul connection to the radio base stations. Quality of Service QoS mechanism have been standardized on all interfaces to ensure that the requirement of voice calls for a constant delay and bandwidth, can still be met when capacity limits are reached. Supports hand-over and roaming to existing mobile networks. High throughput: High data rates can be achieved in both downlink as well as uplink.

This causes high throughput. Low latency: Time required to connect to the network is in range of a few hundred milliseconds and power saving states can now be entered and exited very quickly.

Superior end-user experience: Optimized signaling for connection establishment and other air interface and mobility management procedures have further improved the user experience. Reduced latency to 10 ms for better user experience. Plug and play: The user does not have to manually install drivers for the device.

Instead system automatically recognizes the device, loads new drivers for the hardware if needed, and begins to work with the newly connected device. Just as Ethernet and the internet have different types of QoS, for example, various levels of QoS can be applied to LTE traffic for different applications.

It is therefore of outmost importance that when introducing LTE, which will be a new sub network, the operational impact is very limited. Smart Simplicity. It supports concepts such as Self Organizing Network and Automation. There will be significantly less parameters to set. Only the absolute necessary that cannot be set by the system will be required to set at provisioning.

Default values for parameters are either preset by the system or controlled by the operator through policies. There will also be support for simplifying processes where operator intervention is required. Fewer steps and faster execution will limit the required time the operator spend on a certain process.

Certain Smart Simplicity function can be decided to be implemented in either or both thus enabling implementation that are node efficient and have network knowledge. SON and Smart Simplicity. When deciding where to implement a certain function, consideration of reaction time and availability of information are important. This way of deciding where simplicity solution gives the best effect is one of the core features of our smart simplicity concept.

Navigator is a key component in the creation and reporting of service assurance or service level agreements SLAs.

Ericsson Mobile OSS portfolio. By correlating network resource usage data with individual system services, it will be possible to improve the operating margin due higher utilization of available resources, and better capacity planning.

Complex ad-hoc queries can be carried out in seconds without data explosion or collapsed data loading seen in performance management system based on traditional databases. As part of every network release, Ericsson verifies, synchronizes and validates OSS-RC functionality, capacity, quality and security.

Mul Interface. Typical actions are to turn supervision on or off, synchronize alarm lists with the network element, acknowledge alarms and search the alarm log. When an alarm is received in OSS-RC, the alarm severity can be changed or alarm information like proposed repair actions may be added before the alarms are stored. It should also be mentioned that it is possible to generate alarms based on statistics from the nodes requires storage of statistics in OSS-RC statistical database thus enabling supervision of negative statistical trends for example.

The initiation of measurements, collection, storage and presentation of counters from the different versions of network elements is verified, thus ensuring correct statistical data from day one both for new installations and at upgrades.

The collected data can be handled in different ways depending on how it will be used. A complete set of interfaces enables integration into the operators existing performance management environment. The PM files can also be transferred directly to another system via ftp. OSS-RC provides support for both loading new software on the network element, and activating the new functionality through function change procedure. It includes everything from small upgrades or error corrections, to complete function changes when introducing for example new software releases.

The operator has tool support for all steps involved and the progress and result can be monitored. Besides speeding up the introduction of new functionality in the network, this support increases reliability of the process. OSS-RC also supports centralized node backup administration including backup creation, backup transfer to storage and restore of configuration from backup. The network inventory solution enables a user to retrieve up to date hardware and software inventory information from nodes and present it in OSS-RC or export it to an external network management system for inventory.

Since both software and hardware information is accessed within the same tool, it is easy to inspect both HW and SW levels in a node before performing an upgrade or correction.

It makes it possible to from the same application conduct all necessary diagnostic analysis for determining the cause for problems in the radio network. NSD will simplify the operation to access needed information and data for analysis purpose, which will both reduce the down time and thereby improve ISP and increase the utilization of radio engineers. OSS-RC supports the configuration of the radio access network all network elements and radio network resources.

The configuration support reduces the time for network configuration and enhances the quality by providing operator guidance in the radio network configuration process. For cell, channel and RBS configuration, a database retrieves parameters from the network to mirror the actual radio network.

The user has a possibility to work off-line in a planned area, without interaction with the network elements of the real network, when planning the introduction of new cells for example. New radio network plans can also be imported to a planned area from an external planning system and it is possible to export the radio network data as well. The consistency and the accuracy of the parameters in the planned area can be checked in order not to jeopardize network quality with inconsistent or corrupt data.

The update function with time scheduling makes it possible to implement a new radio network configuration of a planned area at a time when the changing procedure causes little or no impact on the traffic.

ARW makes it possible to reduce configuration lead times and decrease the amount of configuration errors when configuring new radio base stations. The wizard provides the operator with support for the most commonly identified deployment scenarios. ARW guides the user through the configuration by suggesting defaults and automatically generate values based on standard settings and naming conventions. The data the operator needs to enter is limited to a minimum.

The configuration data can also be exported to an external system. There are numerous node and network level consistency checks to make sure the Packet Core services are performing properly and without loss of quality or reliability due to any configuration faults. Extensive consistency checks ensure all data is correct in the system. It is possible to define the rating information only static in case of any problems with rating engine or communication.

It is also possible to configure the service filters and packet inspection. Real time charging configuration parameters is also supported. It can ensure consistency of data by running node and network checks before applying a configuration change to the network.

IMS-CM also provides single northbound interface for a multiple IMS network elements and platforms for import and export of configuration data. Taking a new RBS into service. They are mostly done before any RBS is ordered. The planning of a new LTE network is based on capacity and coverage maps.

In a first step a grid for a cost optimized deployment is determined. Different solutions are provided depending on aspects such as available space at site and RBS type to co-site with. Two alternative ways of configuring new RBSs are possible; a simplified and an ordinary. It is sufficient when building a new network and the ambition is to first enable traffic and later optimal performance, when more traffic is generated or when performance issues require action.

Alternative 2 The ordinary alternative is based on that a complete plan is created in the same way as for existing systems. A planning tool automatically calculates from a user defined template optimal initial parameter values for new RBSs. Only the absolute necessary radio parameters will need planning in LTE. The defaults are defined based on field performance, which warrants for optimal settings.

They can be optimized later in order to maximize performance. ANR will automatically maintain neighbour relation lists and setup X2 interfaces without any need for planning or configuration. This enables global settings of parameters on network level rather than on individual RBS or cell level.

APR — Sufficient when building new networks. Optimisation can be done manually or automatically e. RBS Configuration. The transmission bandwidth needed at the RBS site depends on traffic model, number of served users and "targeted end-user experience".

Examples of parameters impacting the latter are "peak rate to single user", delay and delay variation. Very few transport related parameters for the individual RBSs have to be planned ahead of the deployment.

These parameters may be IP addresses, QoS classes, bandwidth and triggers. These parameters can be entered into OSS-RC which calculates and uses predefined profiles to complete the configuration. In case the transport nodes need to be configured, the OSS Navigator will be in command of the procedure by interfacing OSS-RC as well as the management system of the Transport network.

Any IP based solution meeting the latency, throughput and availability performance requirements set by the mobile operator and the service mix the operator intends to offer can be used. Hardware supports plug and play. After the equipment is installed power, transmission and antenna cables are connected , the field technician only need to power on the RBS, check HW status from the LEDs on the HW units, and connect a PC to enter the node name and security credentials. After this the provisioning and integration of the RBS can be automated.

The RBS also supports other ways to be configured, which involves loading and configuring the RBS locally at site by bringing necessary files.

This method could be useful if for instance the RBS is configured before brought to site. To allow for optimal efficiency when integrating new RBSs all required data should be prepared in advance and stored in temporary location that can be reach by the RBS. Network data changes surrounding resources to adapt to the new resources.

Local data needs to be downloaded to site before the RBS can be configured. It can either be configured manually at site or automatically with APR. Below the optimal way of provisioning is described. The figure outlines the dataflow. Ad-hoc queries can be carried out in seconds without data explosion or collapsed data loading seen in performance management system based on traditional databases.

LTE will from start have high level of automation. Only the absolute necessary that cannot be set by the system will be required at provisioning.

Parameters are either preset with defaults by the system or controlled by the operator through policies. This data will be real-time synchronized always consistent with the data in the eNodeB using notifications from the eNodeBs and delta synchronizations where contact has temporarily been lost with the node All data that is synchronized into OSS-RC will be available to the operator via the 3GPP Bulk CM interface and also through the User Interfaces.

All network configuration data is continuously synchronized with the OSS-RC CM database, which allows the GUI applications to contain real-time status information and configuration data. Manual input for frequent tasks such as adding, removing and expanding an eNodeB is minimized e g profiles are used for default values and the profiles themselves are easy to maintain.

The X2 interfaces will be setup automatically between neighbouring RBSs without any extra configuration. New cells are automatically put in the list when detected by the UE and non used neighbour relations are removed from the list after a specified period of time. The operator has the possibility to complement the ANR function by defining which cells that are allowed and not in the list.

Option 2 Planned Neighbour Relation If the ANR function is not used the neighbor relation data need to be planned in a traditional way in a cell planning tool. Planned data can be used as a complement to ANR. Neighbor Cell Optimization. This is due to that a loss of a core network node can be mitigated through that the base stations will be connecting to other core network nodes.

The Pool Management application provides the customer with a consolidated view of the Pool and the nodes within this pool and allows the customer to have a central control to ensure consistent configuration, fault handling and observability of the performance of the pool and its members. The application supports overlapping pools i. The pool manager will make it possible to handle the complex use cases that are needed when a MME or RBS is connected or disconnected from a pool.

It will also have support to move mobiles between MME nodes in a pool to make it possible to do maintenance operation on a node without any service downtime. The customers can also get performance reports on a pool level. The fault handling is incorporated with the FM feature while the performance management is incorporated with the Ericsson Network IQ product.

It provides support for on- site work and remote RBS unique work. It is mainly used for managing hardware and RBS resources. There is generic support for managing all resources including transport and radio resources. They are both generic i. Initial deployment and managing hardware are such tasks. Rules included are for instance how recovery shall be done in case of a certain faults. For instance which self test to run and which level of restart stairs shall be used.

There are also rules defining correlation between different fault indications. It also contains rules regarding blocking hierarchy for mitigation of the fault. The rules are predefined and included in the RBS software. They are updated with the release of new versions of the RBS software.

In case of a fault condition the RBS will first try to correct it by itself before any notification is issued i. It will correlate the different fault indications to assure that any reported fault is really a concrete fault that requires action from the operator. This will remove the risk of multiple alarms for the same fault and toggling alarms due to intermittent faults. When the fault is determined it will mitigate the consequence of the fault to a minimum by for instance disable a faulty unit.

It will try to maintain traffic as much as possible. The fault condition is indicated with an alarm and if a board is faulty also with a LED on the board. The alarm contains the necessary information for fast identification of actions to take, including unit to replace.

All alarms are logged, for historical reference purposes. In addition to the built in self-test used for fault mitigation it is possible to manually order tests. The tests verify all essential functions and report back the result to the operator. Fault Correlation. Through the cabinet viewer it is possible to view actual status of the hardware remotely.

It will present on a graphical layout the status for each unit. It will also execute any subscription for forwarding the alarm to an NMS. The user at the NOC can utilize a range of different tools for remote trouble-shooting and actions on the fault. The GUIs of these different applications are tightly integrated. No manual intervention other than the actual HW replacement is required.

No node restart is needed and there is thus no node downtime, but the cells served by the replaced unit may be down s during the configuration. Replacement of the digital unit is different compared to replacement of other units. It requires human interaction, as this unit contains the configuration data of the RBS and this data need to be restored. Only one of the logical RBSs will supervise the common hardware. A site manager in OSS-RC will provide extensive support for site management including managing the common hardware.

There are two kind of data; local RBS data that configures the RBS and network data that configures transport and radio networks. It can either be configured manually at site or automatically through this feature. The license key file is generated in a central tool and loaded on the SMRS server.

It has support for templates and automated calculation of configuration data in order to limit the amount of input required for each individual RBS. It also supports bulk generation of data for up to RBSs in one batch. Necessary data can be entered either using graphical user interface or via the file interface. RBS data entered at site. It contains all necessary information regarding where to fetch data i.

Some or all of this data may be included in the DHCP instead of a file implementation not settled yet.

Optionally, other radio network related parameters can also be imported this way otherwise the RBS will use default values. Data prepared in advance. Work Flow The field technician needs to enter minimal of data at site. The RA responds with the signed certificate. The name and address of the cells is also stored in the DNS server as this is needed for the automatic setup of X2 connections to the neighbour RBSs. Optionally, neighbour cell parameters can be configured in both the new and existing RBSs.

Activation of new cells The RBS cells are unlocked radio is activated. The ANR function is enabled and starts automatic neighbour relation discovery.

A backup of the RBS configuration is taken. As the last activity a new Configuration Version CV i. Optionally the operator can decide to upgrade the software in beforehand. The time is distributed on the different deployment activities according to the table below. Different figures may therefore be valid to other operators. The table should mainly be used as a reference for better understanding of what is included in the measured time.

The standard is not yet finalized, which opens for potential changes. It is for instance not decided how the black and white listing shall be done. We assume that the list will have white and black lists and otherwise work similar as the list in WCDMA i.

The Automated Neighbour Relations ANR feature eliminates the need for initial configuration of neighbour relation lists and greatly simplifies the optimization of them. The X2 interfaces will be setup automatically with neighbour RBS if missing. Automated Neighbour Relations ANR automatically builds up and maintains a list of the best neighbours to be used for handover.

The feature can be controlled if preferred but not necessary by defining LTE cells that are mandatory for the list and cells that are not allowed. If a cell relation has not been used for a user-defined time it will be removed from the list. ANR reuses the ordinary handover evaluation procedure, which includes identifying cells reported by the UE.

Since virtually all cellular networks deploy more than cells, the PCIs will have to be reused within a network. The UE detects and reports the received quality i. The neighbouring relation list is used for this. Automated Neighbor Relations. It is then possible to proceed with the handover. This identification requires additional signaling between ANR i. ANR is executed as part of the handover procedure during a call.

It will add an extra time to the handover of not more than ms. This time is estimated to be short enough to not jeopardize the success of the handover. However in case the handover fails due to the time, the RBS will still setup the neighbour relation in preparation for the next handover. The failed handover will be registered in the same way as if the handover relation was not present, which was the case. Parameters: It is possible to control and evaluate ANR. The neighbour list can be configured to include cells that always shall be available and cells that are barred from the list.

It will be possible to monitor which cells that are added and removed from the list. The operator has the possibility to complement the ANR function by setting up allowed and forbidden lists of neighbours. This is mainly due to requirements on time, automation, need to know basis local or holistic knowledge and implementation efficiency minimization of parameter duplication etc.

The NMS level supports multi-vendor. The RBS is designed in accordance to these requirements. RRM functions are implemented as close to source as possible to minimize the number of parameters at the same time as they provide sufficient parameters for supporting multi-technology and multi-vendor environments.

Collected statistics can be up to two hours old before it is available. Current data provides a snapshot of current status. It enables counters and KPI data to be available now when needed.

The LTE Explorer is adaptable to each users need. The user interface can be adjusted regarding content and structure of presented information. It also contains powerful scope and filtering functions enabling efficient organization of the presentation of resources and their status.

It is possible in a flexible way to define own reports that combines KPIs from different sources such as different networks from different vendors. Operators should solve this through organizing a separate unit responsible for the shared RAN. From an operations perspective it puts some extra requirements that should be solved with a multi-vendor management system that connects to the different vendors OSSs.

For most parameters default values are available that provides best practice for setting. Any input is validated towards allowed value ranges. There are also advanced features, for reconfigurations and expansions of the network.

Manual input for frequent tasks such as adding, removing and expanding a RBS is minimized e g profiles are used for default values and the profiles themselves are easy to maintain. OSS-RC keeps a mirrored information base of the actual configuration data of all managed network elements in a data base referred to as Configuration Store.

This mirrored base is during normal operation continuously kept up to date - synchronized - with the actual network through notifications from the network elements sent for all applicable configuration changes. Should OSS-RC loose contact with one or more network elements for a longer period e g physical network problem or OSS-RC software upgrade , then a complete resynchronization of these network elements is made reading the complete configuration data anew.

Release and maintenance upgrades are done in the same way. But they may take different time due to the size of the Upgrade Package UP. Release upgrades are always upgrades of complete software while maintenance upgrades contains only the changed software. A typical size of an UP for system upgrades is Mbyte.

Only new and changed software units are downloaded. This activity will not impact traffic and can be done at any time. Thus a software installation may be fast. This should be done to make sure that the RBSs to be upgraded can be upgraded. It checks for instance software versus configuration compatibility and RBS state, which increases the probability for successful upgrade. If the upgrade is unsuccessful or the upgrade is not made permanent then the node will automatically rollback to the latest made Configuration Version CV i.

This is the actual switch of software and includes also conversion of the configuration. The upgrade of an RBS will in most cases take less than 10 minutes, with less than 5 minutes of traffic impact. If the upgrade involves conversion of configuration data it may take little longer. This check is to make sure that the RBS operates with the same performance and quality as before the upgrade. Both the software installation and software upgrade can be managed from the element manager however this shall be seen as a fallback solution.

SMO provides full support for managing all five activities it also supports managing UPs and backups on the RBSs, including rollback order. It supports batch sizes of up to RBSs. To increase transmission efficiency they are compressed. There are two types of information types available; statistics KPIs and counters and Events with measurements.

These are used for long-term analysis of the network and service performance. Subscriptions define what shall be collected. Initially all RBSs will automatically start a predefined default subscription for collecting the most essential statistical counters.

It is possible to define additional subscriptions. It is also possible to stop the predefined and only use own defined. It can be used for collecting events for a particular cell or all cells in the RBS. It is possible to define which events to collect. It is also possible to set a fraction figure that determines the percentage of UEs to collect events from to reduce the load on the RBS. There can be 16 UETR active simultaneously.

Performance Management. Real-time database means that it is primary memory resident, i. This database also has possibility of storing data persistently in files. The transaction mechanism prevents two or more clients from updating the same data at the same time. Only one of them succeeds with the update and the other s fail. All transactions are done in sequence, i.