BSS B11 Feature Description (New Features)

BSS B11 Feature Description (New Features)
BSS Release B11 Feature Description (New Features)
Alcatel-Lucent confidential 2011

All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization.
15 02 92: TRX dynamic power saving

The principle of the feature is to switch-off the Power Amplifier (PA) bias of a given TRX, as soon as at least two consecutive TS are not transmitting. Indeed 2 TS are enough for the TRX to switch off then switch on its PA bias. It uses an On the flight principle, whereby the TRX detects whether data has to be transmitted over the air in the next two radio timeslots. The great advantages of this implementation are: Applicability to all kinds of traffic: Voice, packet, signaling, Independence from the BTS configuration, Immediate reaction, providing gains 7 days a week 24 hours a day, No blocking, Easy O&M: No need to specify TRX de-activation periods.
Thanks to this feature, the power consumption per TRX is reduced by around 25W when there is no traffic to be transmitted. At a BTS level, the association of TRX dynamic power saving, Power Control and Discontinuous Transmission in downlink brings around 25% saving on the global energy bill.
15 02 44: Support of two SUM boards per cabinet

The MBI5/MBO2 cabinets can host two logical GSM BTS inside one cabinet as shared solution with standard modules, thereby allowing a very cost-effective introduction of 2GSM BTS in one MBI5/MBO2 existing cabinet. All common cabinet parts are managed by the 1st BTS via OMC reporting (e.g. External alarms etc.). Please find below an example for MBI5 case.

15 04 85: Antenna hopping

The feature provides enhanced coverage. Its principle is that a sequence of bursts of a given call is transmitted alternatively over 2 antennas. This brings diversity to the downlink path, which can be particularly useful in case of no hopping or hopping with few frequencies. Gains are expected to be between 2 and 3 dB. Based on Antenna hopping principles, Alcatel-Lucent implements BCCH hopping in its TWIN TRX, in order to re-align BCCH performances with already hopping TCH.

Configuration management algorithms have been reviewed in order to ensure that the BCCH TRX is not mapped on a TRX belonging to a TWIN module shared by 2 sectors.
15 06 04: Support of STM-1 in the BSC

Up to 4 protected optical 155 Mbit/s STM-1 links are available on the BSC Evolution equipped with TP STM1 boards. The STM-1 links can be configured independently for A-bis and A-ter. Each TP STM1 board being equipped with 4 STM-1 ports, 1+1 link redundancy is provided. Compared to an external STM-1 connectivity, STM-1 in the BSC allows simplifying BSC cabling and reducing transmission CAPEX.
15 13 22: A Signaling over IP

A signaling over IP has been standardized in 3GPP Rel-7. Legacy transport of A interface signaling using SS7 principles is replaced by SIGTRAN protocols. Transmission over TDM (E1 timeslots or full E1 in case of High Speed Link (HSL)) is replaced by transmission over an IP network thanks to the Ether net connectivity of the BSC Evolution. The architecture of a BSS using A Signaling over IP is depicted in the figure below.
A itf
User Plane
SCCP M3UA
TC
TDM
TDM
MGW
Eth. Eth. M3UA MSC server
BSC
Eth.
Control Plane
IP
Benefits for the Operator are reduced transmission OPEX and easier A Signaling link configuration,

the later point being all the more true with A Flex. To be noted that SIGTRAN protocols are already used inside the NGN core. Therefore limited interoperability issues between BSS and MSC Servers are expected. Then, and together with Gb over IP, A Signaling over IP can be considered as a relatively straightforward step towards IP transformation in the BSS. The following figure shows the different layers of the protocol stack.
BSC
MSC Server
BSSAP SCCP M3UA SCTP IP Ethernet
BSSAP SCCP M3UA SCTP IP Ethernet
IP IP
15 13 24: A Flex
A Flex has been introduced in 3GPP Rel-5. The main principle is that a BSC can be connected to several MSC. To be noted that this concerns only the Control Plane (Signaling on A interface) and not the User Plane. Indeed if we take the example of an NGN network, it is already possible to connect a BSC to several MGW even without A Flex. The MSC connected to a same BSC belong to a CS pool area.

MSC server3
M SC server6 M SC server5 MSC server2 MSC server4
MSC server1
CS pool area 1 Area 1 Area 2
CS pool area 2
Area 3
9130 BSC1
9130 BSC2
9130 BSC3
Area 5
Area 6
Area 7
9130 BSC5
9130 BSC6
9130 BSC7
At the first access of the MS inside the CS pool area, the BSS decides which MSC of the CS pool area will handle the MS during its presence inside the CS pool area, according to a BSS supplier dependent load sharing algorithm. For the following accesses, the BSC routes MS signaling towards the MSC decided at first access. Out of this feature, the Operator can take the following benefits: Reduction of the signaling load: No inter-MSC handover and no LA Update take place as long as the MS stays inside the CS Pool Area. Better load balancing between the MSC. Easier Core network expansion: In case of traffic growth, MSC can be added without potential BSS splitting. Increased service availability: In case of MSC site disaster, telecom service is no more completely lost for all the BSC. Just the traffic capacity of the failed MSC is lost and this loss is spread among all the BSC.
Alcatel-Lucent implementation is based on A signaling over IP. This is needed in order to simplify the multiple signaling connections between BSC and MSC.

9 130 BSC1
IP Ba ckbone
si g na l in g Aov Fle er x IP
9 130 BSC2
MSC serve r2 M SC se rver1
913 0 BSC3
15 34 74: Repeated SACCH / FACCH

When AMR speech codecs were introduced, the same ACCH (Associated Control Channels) as those used for legacy codecs (FR, EFR, HR) were re-used: SACCH (Slow Associated Control Channel), which is used for non-urgent procedures (mainly for the transmission of the radio measurement data needed for handover decisions, power control), FACCH (Fast Associated Control Channel), which is involved in delay sensitive mechanisms such as handover command.
Therefore, in poor radio conditions, the more protected AMR speech codecs have better performance (in terms of error rate) than their associated control channels In addition to poor handover performance caused by the weak FACCH channel, measurements reports can be lost if SACCH repeatedly fails. This affects power control, timing advance updates and neighbor cell measurements. Also, since the RLT (Radio Link Timeout) is based on the bad frame indicator of the SACCH channel, it becomes unstable in poor radio conditions, which may result in a dropped call whereas the speech is still perfectly audible. This means that the Operator may not be able to realize the full capacity gains that the lower modes of the AMR can provide. A first attempt to solve this issue has been done in a previous BSS release (See 15 34 72: Differentiated Radio Link Timeout for AMR calls). This is a valid waiting solution, but increasing the RLT value does not prevent from loosing handover command on FACCH or measurement

reports on SACCH and can increase interferences (loss of power control messages on SACCH). This is to solve those issues that Repeated SACCH and Repeated FACCH features have been introduced in 3GPP Rel-6. They are both mandatory for Rel-6 MS. They rely on the repetition and combining of the downlink FACCH frames and the downlink and uplink SACCH frames, in order to decrease their average error rate.
15 34 82: TFO for NB-AMR

TFO for NB AMR has been introduced in 3GPP Rel-4. TFO for legacy codecs (FR, EFR; HR) and WBAMR have been introduced in previous BSS releases. With this feature, the Operator can benefit from the high voice quality gains provided by TFO on the whole range of GSM codecs. To be noted that being able to use TFO on all GSM codecs is all the more interesting with NGN Core Networks using compressed codecs over IP in their transmission backbone, in order to reduce the too high bandwidth consumption of G711 over IP. Indeed in that case, an additional transcoding stage is used inside the MGW, which may significantly reduce voice quality. This point can be solved by using TFO between the TC and the MGW, as depicted in the following figure.
BSC
MSC- S
IP
MSC- S
AMR
G711
G711 over IP
TC
AMR
MGW
AMR over IP
MGW
Other Network
TFO
TRFO
15 72 90: A5/3
GSM Association has already taken the decision not to allow A5/2 ciphering algorithm anymore. It was also decided that MS shall not support A5/2 anymore from 3GPP Rel-6 onward.

Also, hackers have been claiming that they would be able to break A5/1 with relatively limited means. Therefore it appeared necessary to use a more robust ciphering algorithm in GSM networks. This algorithm is A5/3, already used in UMTS, and standardized in 3GPP Rel-4. Up to now, only one encryption algorithm was used inside a BSS: A5/2 or A5/1 (+ A5/0 meaning no encryption). The BSS has now to decide which encryption algorithm to use on a per call basis, as not all MS support A5/3 as well as not all the TRX generations. A5/3 is supported by all EDGE capable TRX. For each cell, the Operator can decide the allowed list of encryption algorithms: A5/0, A5/0 + A5/1, A5/0 + A5/1 +A5/3.
15 72 95: Randomisation of L2 Filling Bits

Before A5/1 ciphering activation during voice call establishment, there is an exchange of Layer2 messages between Mobile Station and BSS. Some predefined sequence of bits in Layer 2 messages could lead to eavesdropping on Air interface using advanced techniques for reverse engineering. Randomisation of filling bits in Layer 2 messages is a way to decrease the risks of hacking on the Air interface by replacing the fixed sequences of Layer 2 messages with random sequence of bits. By randomisation of Layer 2 filling bits, operator will have the possibility to increase the security of voice calls without impact on Mobile Station or BTS. The feature is supported on all Evolium BTS generations and is compatible with all generation of Mobile Stations.
62 60 42: Fast measurement mode for BSC investigation

PM counters are very useful to investigate a problem occurring in the network. Existing solution based on ODMC is adapted to deep analysis of a problem. But ODMC doesn't satisfy all the needs because:

it requires some time to create the appropriate ODMC campaign it requires knowing which among the several possible PM types are the best candidates for investigating the current problem it doesn't provide an overall view of the problem because PM types that can be included into an ODMC campaign are focusing on specific areas of the system.
Consequently, in B11, it is possible to accelerate the PM type 110 (overview measurement type) to a granularity of 15' for one BSC during 2h max. Remark: It is not possible to accelerate reporting period for another PM type. As the acceleration of the reporting period is triggered for investigating a particular problem, it is not allowed to keep the accelerated reporting period for more than 2 hours. Limitation to 1 BSC only is due to 2 main reasons: limit processing power required by management of the higher number of PM files for OMC-R and for NPO. avoid to degrade OMC-R response time for other users that would also like to access PM viewer.
Once configured by the operator, activation of this acceleration occurs automatically, after a leadtime of 5. Whatever the initial reporting period configured for type 110 (30 or 1h), if acceleration is triggered between 8h and 8h10. With 5 activation lead-time, acceleration is taken into account before 8h15. Therefore the first result for accelerated PM 110 will be received at 8h15. If acceleration is triggered between 8h11 and 8h25, then first results will be received at 8h30. And so on
Remark: As it is possible to define a Permanent Measurement Campaign running every day during only a part of the day (thanks to definition of a start time and a stop time), for such PMC, it will be allowed to accelerate the reporting period only inside the time interval defined by the start and stop times.

For the cases when the PMC runs for the whole day, the acceleration of the reporting period will be possible at any time of the day. This feature only applies to BSC Evolution.
62 61 04: Load indicators for OMC

If Performance Indicators are available for most Network Elements of the BSS, only few information are provided by the OMC-R on the usage of its resources. In addition to the CPU and Memory load provided by the Multi Router Traffic Grapher (MRTG), the set of Load indicators is extended by integrating the Orca solution. This tool displays a very large number of indicators inside HTML interface. This is very practical for System Administrator for accessing the indicators just by using a web browser. This tool complies with the following requirements: Ability to monitor multi-server systems such like X-Large or XX-Large systems and associated HMI servers Measure and display short (daily/weekly) and long-term (monthly/quaterly/yearly) trends Allow easy viewing of all system measurements on different time scales Plots are always up to date and always available Minimum impact on system in order not to affect the normal operations of the OMC-R
The screenshots showed below illustrate the comprehensiveness of the indicators provided by the tool: Overview of system resources, Graphical view of CPU consumption daily, weekly, monthly, quaterly, Disk usage Network interface usage

Figure 1: Orca system overview
Figure 2: Orca disk usage

Figure 3: Orca CPU usage
Figure 4: Orca network interface
64 00 82: Multi-edition of cell adjacencies

On the same principle as Edit n cells, B11 release offers now the facility to modify one or more adjacency parameters on several adjacencies in one shot and also to modify several adjacencies possibly related to several selected cells.

A "Edit n adjacencies" button is provided in the adjacencies window. From the adjacencies windows, OMC-R users are allowed to select one/more/all adjacencies. The Edit n adjacencies button allows the user to modify the parameters for all the selected adjacencies. The feature is currently available only for the edition of GSM-GSM adjacencies. In the future, if new parameters are defined for the GSM-UMTS adjacencies, the edition of GSM-UMTS adjacencies will also be possible. Like edit n cells, the new edit n adjacencies facility are offered only in the PRC scope.
64 01 74: SEC Command line interface for external user management

The integration of different management systems raises the need to consolidate the management of heterogeneous user accounts in one place, to better control and propagate user credentials. Such centralization is generally made possible through the use of LDAP databases, synchronized to a reference and central database. OMC-R user account management at Unix level can be centralized because OMC-R has already implemented in previous releases compatibility with such central LDAP database (with automatic regular synchronization mechanisms). But management of the specific OMC-R user profiles as well as OAD/NAD remained up to now managed locally at OMC-R level only. With B11, SEC module provides a comprehensive Command Line Interface. OMC-R administrator can create scripts that allow him: Managing the user profiles (creation/modification/deletion/), Mapping of the profiles to user accounts Managing Object Access Domains (OAD)/Network Access Domains (NAD).
Together with LDAP compatibility, the SEC Command Line Interface allows a complete centralized user management for all OMC-Rs of your network. This is of a great benefit in terms of administration cost (OPEX reduction) as well as in terms of security because password management for user account is also centralized.

78 17 00: Web publishing of reports

This feature allows displaying computed views and reports in a web browser. This makes accessible views and reports from any PC without having to use the complete NPO client (also called analysis desktop). All published views and reports are stored in a web file repository and can be available through a web page for any declared user like non-technical persons in a light web environment. While requesting the generation of a view or report, the operator can choose whether he wants to publish the execution result or not. When published, any operator can then have access to the generated view or report through the web viewer. The proposed user interface also allows to the operator to export the results to MS-Excel. A typical use case of this feature is to automatically publish reports generated by scheduling (see also feature 78 12 40: QoS reports generation scheduling) making them available to many people when they begin their working day. The published views and reports can be re-executed with a modification of the execution context: different start and stop time and/or with a subset of concerned topologic objects.

78 17 30: Quality of Service alerters

Operators having to follow the quality of service of the network need facilities to be warned about problems without having to check thousands of cells by themselves. NPO allows defining alerters to detect quality of service problems. An alerter defines the conditions met by indicators for a given list of network objects (cells, BSC, or any object with defined indicators). Alerts resulting from defined alerters are displayed to the NPO operator in a dedicated window of the Analysis desktop. Three types of alerters are defined: Standard alerter: the alert is raised when the indicator value exceeds the indicators thresholds or a user-defined threshold Variation alerter: the alert is raised following the variation of an indicator along the time. A smoothing period can be defined in order to take into account several reporting periods (based on an average, min, max or sum algorithm) Complex alerter: the alert is based on the computation of indicators formula (the formula can use simple arithmetical and logical operators)
The definition of an alerter contains the time scope (hours during which alerters shall be evaluated), predicates, validity and stability conditions. At the end of each performance measurement-reporting period, NPO tests the thresholds and validity conditions to detect the appearance or removal of an alert. A different severity (minor to critical) can be assigned to the alert depending on the crossed threshold. All parameters defining the alerters can be easily set and changed by using a dedicated alerters editor. Alerts can be redirected to an external alarm management via SNMP traps.
78 17 60: Evolution trends

While executing a view or a report, it is possible to compute and display the temporal evolution trend for scalar indicators present in the view/report. This feature is useful for prediction: it allows extracting a general trend from complex evolution data and forecasting threshold crossing (in combination with highlighting feature detailed in 78 29 80: View manager: spreadsheet facilities and graphical display). This evolution trend is available on the whole observation period and the prediction period (period on which measurements are not yet available).

78 19 40: Operator network reference values

In the same way NPO manages the set of operational values, NPO is able to handle another set of parameters values per object instance called ORV (Operator network Reference Values). These set of values are the ones the operator considers as reference for the network or a part of the network. The operator is able to use these values for comparison, for restoring and, more generally, for reference (e.g. at a given time, the network is running well and the parameters values can then be considered as a reference). The administrator is able to define the ORV scope i.e. which parameters and which topologic objects are concerned: only the parameters of interest for the operator can be considered. This definition is set either through a file import/export interface allowing exchanging this ORV scope between several NPO instances or through a web GUI for The values for each instance can be set by two different means: either by selecting some (or all) network objects in the topology tree and then saving operational values as operator reference values or by importing values from external files in CSV format. Those values can also be exported in order to backup them or to make them available for an external tool. These Operator Reference Values can be displayed as other parameter sets in executed views and reports (like operational, reference, min reference, max reference or planned values). In this view, the operator is able to highlight parameters for which operational value is different from the ORV one. When these operator network reference values are defined, the comparison between operational values and ORV is calculated every night. The result is a tuning session: this permits to use the capabilities of the tuning session management (see feature 78 26 80: Massive realignment tuning sessions): displaying differences, realigning operational values to those operator reference values by applying the tuning session, editing and for instance removing some changes before applying, These capabilities make NPO able to be the central reference database for parameters of the radio network.
78 23 00: Comparison of the network configuration with reference values

This feature allows the NPO operator to get the differences between the operational parameter values and the recommended ones (reference values). Differences are provided in an Excel file: in this file, there is one line per operational parameter value different from the reference one. Moreover, operational parameter values that are outside of the reference boundaries (lower than the minimum reference values and greater than the maximum reference value) are highlighted in the EXCEL file.

This feature is complementary to the feature 78 22 90: Parameters value checking that provides such services in a graphical way in the NPO analysis desktop. This feature provides a way to have a global checking of all parameters of the whole network while the other one is more adapted to be used for a limited number of objects and parameters during the QoS analysis.
78 23 10: Comparison of the network configuration between two dates

This feature allows the NPO operator to get the differences between operational parameter values between two different dates. Differences are provided in an Excel file: in this file, there is one line per parameter value different between the two dates. This permits to get in a single file all changes in the network between two dates with a reference date.
78 25 50: Assisted tuning in diagnosis scenarios

Having diagnosis scenarios recommending tuning some parameters to solve Quality of Service problems is interesting, but being able to quickly applying those recommended changes is quite better. This feature intends to provide easy means to generate the recommended tuning session corresponding to the recommendations of an executed diagnosis scenario (executed in detailed mode: see feature 78 25 20: QoS decrease detailed diagnosis). For this purpose, the diagnosis scenario grammar is enriched with primitives allowing adding tuning operations inside a tuning session: to modify parameters or frequencies, to create adjacencies relations, to create advice

tuning The detailed report resulting from the execution of the scenario contains a link. A simple click on this link opens the tuning browser on a session that contains all the tuning operations generated during the diagnosis scenario execution. As any other tuning session, the generated tuning session can still be modified after having been generated in order to possibly remove some changes or add other ones before being provided to the OMC for activation. Another kind of use case of such diagnosis scenario is the activation of a new BSS feature in a massive way (the whole or a important part of the network).
78 29 90: Multiple network element types in a single view or report

Views and reports are usually composed of one network element type (cell, BSC, ). However, it is very useful to be able to have in the same view (either tabular or graphical view) objects of different types. This allows an easy visual comparison between objects: for instance, displaying cells with bad call drop rate and their associated BSCs in the same view. In the same way, the operator can request to add an object of the same type with its associated indicators values to an already executed view (Ctrl Drag & Drop), he is able to add some objects of another type into this view: for instance, having a view in which some BSC indicators are displayed, the operator can select some cells or TRXs of these BSCs and add them to the view in order to display in the same table/graph the same indicators at different topologic levels. In order to ease the analysis of several objects of different topologic levels, NPO also includes a dedicated mode allowing the operator to put objects of different types in the same basket. The MultiNET mode is a pseudo mode that enables the execution of views, indicators and reports on a selection composed of objects of various network element types and object zones. The MultiNET mode Basket tab main area is a tree where the objects are simply classified/grouped per object type. The operator can populate a basket by a simple drag and drop of objects from other modes. The operator can also easily remove objects from these baskets. These basket facilities allow the operator to work more efficiently with a set of selected objects (i.e. working on a set of cells/BTS/BSC in this basket, there is no need to search for them in various modes).

Baskets can then be used for requesting the display of indicators, parameters, views or reports for all those objects of different types. A tabular view of an executed view with multiple element types displaying parameters is shown in the figure below.
78 30 00: 3D views
This feature enables the operator to execute views and reports in which the 3 dimensions are present in the same table: several indicators or parameters for several network objects at several dates. The display of these 3D tables is done through nested tables. A nested table is a standard table in which each column (or a row) contains a table in which the 3rd dimension is provided. The 3rd dimension can be dynamically added when adding it by a drag and drop operation to an already executed view. This means that nested tables are automatically displayed when necessary. For example, when looking at Call Drop and Call Success rates evolution along the day for a given BSC, drilling down to the Cell level will automatically build a nested table with the evolutions cell per cell.

Each dimension can be in abscissa or ordinate depending on the operator choice. He can easily modify the table presentation by choosing how to group data, which data to be displayed as rows or columns, and so on. The operator can change the default configuration by setting the corresponding user preference.
78 32 30: Web-based NPO client

The web client application allows the operator to browse network objects and functions and to execute views and reports without running the complete NPO HMI (analysis desktop). Simplified views including scalar indicators, parameters or counters can be defined through the web client. Various ways of selecting topology elements are offered. This includes browsing the topologic tree of the network elements. The operator can select the function type: parameters, indicators, views or reports and then submit the request to the NPO server. The results are displayed in the same way as for the feature 78 17 00: Web publishing of reports. Export to MS-Excel and management of favorites (topology objects and functions) are available from this web application. Advanced functions like temporal and spatial roll-up and drill-down are also available through this interface.

End of Document


BSS B11 Feature Description (New Features)

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

BSS B11 Feature Description (New Features)

Caricato da

Copyright:

Formati disponibili

BSS B11 Feature Description (New Features)

BSS Release B11 Feature Description (New Features)

Alcatel-Lucent confidential 2011