2. Introduction
This document provides step by step guide for RF engineers to
use Atoll for LTE network design using NSN parameter
settings. It it assumed that these settings will be available in
file xxx.mdb.
• Create the project in Atoll using NSN parameter settings
• Perform coverage prediction studies
• Perform Monte Carlo simulation
4. Inputs
As in any RF tool, the following information is needed to create
a project in Atoll.
• Geodata
• FDD or TDD
• Spectrum: frequency band and channel
bandwidth
• Propagation Model
• Site, Cell, Transmitter info
• Bearer info
• Other LTE Parameters
6. Create Project
The 1st step is to create a project by importing the default NSN parameter settings.
Click File -> New -> From an Existing Database to open the xxx.mdb file with NSN
settings
8. Import Clutter Data
Click File->Import, open the index.txt file for
clutter data, select Clutter Classes, click OK.
9. Import Clutter Data
If the clutter data is not shown on the window, click Geo tab -> Clutter Classes ->
Clutter -> Centre in the Map Window to display the map.
10. Import DTM Data
Click File->Import, open the index.txt file for
DTM data, select Altitudes, click OK.
11. Import DTM Data
Clear the check box for Clutter Classes, the DTM data should be displayed
Remember to save the project from time to time
12. Import Vector Data
Click File->Import, select the wanted vector
files, select New folder in ‘Geo’ to create a
Vector folder if it is not available, ensure the
coordinate system is correct, then click Import.
13. Import Vector Data
Clear the check marks for all layers above, the vector data should be displayed
15. Propagation Models
Propagation models can be imported into Atoll, or manually added. Check the
Atoll user guide for details. Copy&Paste can also be used.
16. Transmitter Global Parameters
The Global Parameters for Transmitters should use the default NSN settings which
are imported when the project was created.
The Global Parameters can be accessed by clicking Data tab -> Transmitters ->
Properties
NSN setting may be
different from the displayed
values
17. Define Frequency Band
Under Data tab, click Transmitters->Network Settings->Frequencies->Band to
open the table for band and channel definition.
Make sure the required spectrum is defined correctly. If it is not defined, It can be
added in the table manually, or imported using the template below.
To import, click Actions at bottom and Import
18. LTE Bearers
Under Data tab, click Transmitters->Network Settings->LTE Bearers to open the
table for Bearer definition.
This definition is applicable to both UL and DL. However, 64QAM is not supported
in UL currently.
Don’t change this table.
It should be imported from xxx.mdb file
19. Quality Indicators
Under Data tab, click Transmitters->Network Settings->Quality Indicators to open
the table for Quality Indicators definition.
This definition is applicable to both UL and DL.
Don’t change this table. It should be imported from xxx.mdb file.
20. Schedulers
Under Data tab, click Transmitters->Network Settings->Schedulers to open the
table for Schedulers definition.
Note: this scheduler is implemented by Atoll algorithms, which may be different
from scheduler algorithms in NSN eNodeB even if they are called the same
names.
Don’t change this table. It should be imported from xxx.mdb file and might be
different from the table below.
21. TMA
Under Data tab, click Transmitters->Equipment->TMA Equipment to open the table
for TMA definition.
All TMAs used in the project should be defined here.
22. Feeders
Under Data tab, click Transmitters->Equipment->Feeder Equipment to open the
table for feeder definition.
All feeders used in the project should be defined here.
23. eNodeB
Under Data tab, click Transmitters->Equipment->BTS Equipment to open the table
for eNodeB definition.
All types of eNodeB used in the project should be defined here.
24. LTE Equipment
Under Data tab, click Transmitters->Equipment->LTE Equipment to open the table
for LTE Equipment definition.
All types of Cell and UE equipment used in the project should be defined here.
• The parameters in Cell Equipment are for UL ONLY!!!
• The parameters in UE Equipment are for DL ONLY!!!
Don’t change this table. It should be imported from xxx.mdb file and might be
different from the table below.
25. Cell Equipment
Move the mouse pointer to the left edge of a row, when the pointer changes to an
arrow pointing to the right, double click to access the table for the relevant cell
equipment.
Don’t change this table. It should be imported from xxx.mdb file and might be
different from the table below.
Double click
26. Cell Equipment – Bearer Selection Thresholds
The C/(I+N) table gives the CINR thresholds for MCS selection in the UL link
adaptation for a given mobility. Bearers 18 – 29 are not supported in UL currently.
Don’t change this table. It should be imported from xxx.mdb file and might be
different from the table below.
Click one of them to
access the selection
thresholds
27. Cell Equipment – Quality Graphs
The quality graph table gives the block error rates for CINR thresholds in a given
MCS for a mobility type.
Don’t change this table. It should be imported from xxx.mdb file and might be
different from the table below.
Click one of them to
access the selection
thresholds
28. Cell Equipment – MIMO
This table specify the diversity gain and MIMO gain (MU-MIMO) in UL for a mobility
environment.
• Currently MU-MIMO is not supported, hence the MIMO gain is one
• The UL diversity gain has been integrated into Bearer Selection Thresholds table,
hence the gain is 0 dB. Don’t change this table. It
should be imported from
xxx.mdb file and might be
different from the table
below.
Click one of them to
access the selection
thresholds
Number of UE Tx
antenna ports
Number of cell Rx
antenna ports
29. UE Equipment - Bearer Selection Thresholds
Similarly, double click to access the table for the relevant UE equipment. Again, all
parameters for UE Equipment are for DL only.
Don’t change this table. It should be imported from xxx.mdb file and might be
different from the table below.
30. UE Equipment – Quality Graphs
The quality graph table gives the block error rates for CINR thresholds in a given
MCS for a mobility environment.
Don’t change this table. It should be imported from xxx.mdb file and might be
different from the table below.
31. UE Equipment – MIMO
This table specify the diversity gain and MIMO gain (SU-MIMO) in DL, depending on the UE
operation mode.
• The MIMO gain may be dependent on CINR
• In case of Tx diversity mode, part of DL diversity gain has been integrated into Bearer
Selection Thresholds table, the remains gain is entered in Diversity Gain column.
Don’t change this table. It should
be imported from xxx.mdb file
and might be different from the
table below.
Number of Cell Tx
antenna ports
Number of UE Rx
antenna ports
MIMO capacity gain is
1 in Tx Diversity
32. Sites Table
In Atoll, for each eNodeB a site and transmitters are defined. The site info refers to
the physical location of the site, and transmitter info refers to cell configuration
including antenna.
In Sites table, the site name, longitude and latitude are given. The following is a
site template in .csv format.
• use this template to enter site information for each market
• Make sure the column for Altitude is blank. When the file is imported into Atoll, the site
altitude info will be updated automatically based on DTM data.
Keep Altitude column blank
33. Import Sites Table
The Sites table can be open in 2 ways
• double click the Sites folder in Data tab, or
• click Sites -> Open Table
Before importing the sites, delete any unwanted sites in the site table. This can be done by
selecting the entire rows for the corresponding sites, and then press Delete in the keyboard.
34. Import Sites Table
Move mouse on the Sites table, right click and select Import.
Ensure for each column, the title in Source and
Destination matches.
Click Import button at
bottom to import the site
table
35. Import Sites Table
To add a site, we can also enter the info directly in the site table on the last row.
Note: in Atoll, we can do copy&paste between any Atoll table and excel sheet just
like between two excel sheets.
36. Transmitters Table
The following is a Transmitters table template in .csv format.
• use this template to enter transmitter information for each market.
37. Import Transmitters Table
The transmitters for a site can be added only after the site info is available in Atoll.
The Transmitters table can be open in 2 ways
• double click the Transmitter folder in Data tab, or
• click Transmitters -> Open Table
Before importing the sites, delete any unwanted transmitters in the Transmitter table. Note
when a site is deleted, all of the associated transmitters are deleted too.
Move mouse on the Transmitters table, right click and select Import to open the
Transmitters file.
38. Import Transmitters Table
Ensure for each column, the title in Source and Destination matches. Click Import
button at bottom to import the transmitter table
39. Import Transmitters Table
The imported transmitters should be visible. New transmitters can also be added,
deleted, or edited manually.
40. Cells Table
The following is a Cells table template in .csv format.
• use this template to enter cell information for each market.
41. Import Cells Table
The cells for a site can be added only after the transmitter info is available in Atoll.
The Cells table can be opened by clicking Transmitters ->Cells-> Open Table.
Move mouse pointer to anywhere on the Cells table, right click and select Import to
open the Cells file.
Ensure for each column, the title in Source and Destination matches. Click Import
button at bottom to import the Cells table
42. Import Cells Table
Clear and check the box for Transmitters to refresh, the transmitter icon becomes
solid red after the Cells table is filled for the relevant cell.
43. Individual Cell Parameters
If you double click a transmitter under Data tab->Transmitters folder, all settings
can also be accessed and edited.
44. LTE Parameters
The following parameters must be defined for Monte Carlo
simulation and some types of coverage predictions.
• Services: the types of services and traffic profiles
considered for prediction and MC simulation.
• Mobility Types: the types of mobility considered for
prediction and MC simulation.
• Terminals: the types of terminals considered for prediction
and MC simulation.
• User Profiles: the types of users considered for prediction
and MC simulation.
• Environments: the types of environments for traffic
distribution in MC simulation. Note: each defined
environment can be given any name, and it is not relevant
to the clutter types of Geo Data.
45. LTE Parameters - Services
Define traffic profile for each service type.
46. LTE Parameters – Mobility Types
Define the mobility environment
It may need to define multiple mobility types for same speed. For instance,
the SINR thresholds for a given MCS are different for a UE in Tx diversity
mode and spatial multiplexing mode. See slide for UE Equipment - Bearer
Selection Thresholds.
47. LTE Parameters - Terminals
Multiple terminals can be defined depending on its capability and number of
antenna ports, etc.
48. LTE Parameters – User Profiles
Define how a user would use different type services in the busy hour.
49. LTE Parameters – Environments
The environments are purely defined for traffic distribution purpose. It specify the
user density for each type of users if the corresponding environment is used to
define an area for traffic distribution. The weighting for clutter type and indoor are
also specified.
50. Summary
So far, the LTE project for a market should be created. Now it is ready to perform
RF analysis and Monte Carlo simulation.
52. Define Zones
Multiple zones can be defined and used for different purposes in
prediction and MC simulation
• Filtering Zone: The filtering zone is a graphical filter that restricts the objects
displayed on the map and on the Data tab of the Explorer window to the objects
inside the filtering zone. It also restricts which objects are used in calculations
such as coverage predictions, etc.
• Computation Zone: The computation zone is used to define which base stations
are to be taken into consideration in calculations and the area where Atoll
calculates path loss matrices, coverage studies, etc.
• Focus Zone and Hot Spot Zones: With the focus zone and hot spot zones, you
can select the areas of coverage predictions or other calculations on which you
want to generate reports and results.
• Printing Zone: The printing zone allows you to define the area to be printed.
• Coverage Export Zone: The coverage export zone is used to define part of the
coverage prediction to be exported as a bitmap.
53. Define Zones
To define a zone, click the zone->Draw, an draw the polygon on the
maps. It can also be imported. The defined zone can be deleted, edited,
and exported if desired.
54. Predictions
The following predictions are recommended
• Coverage by DL best RS signal level
• Coverage by DL best server (based on RS signal level)
• Coverage by number of servers
• Coverage by DL PDSCH & PDCCH C/(I+N)
• Coverage by UL PUSCH & PUCCH C/(I+N)
• Coverage by DL Peak RLC Channel Throughput
• Coverage by UL Peak RLC Allocated Bandwidth Throughput
• Coverage by UL Peak RLC Cell Capacity
• Coverage by Best Bearer (DL)
• Coverage by Best Bearer (UL)
• Coverage by DL PDSCH & PDCCH Signal Level
• Coverage by UL PUSCH & PUCCH Signal Level
55. Create New Prediction
To create a new prediction, click Predictions->New, select the desired
prediction study and click OK.
The new study is added in the Predictions folder. Click the new study->
Calculate, the prediction should be performed. Check the box on the left of
the study to show the results.
56. Coverage by DL Best Signal Level
Click Predictions->New->Coverage by
Signal Level. Select Best Signal Level
in Field of Display tab.
Shadowing and indoor
coverage can be set
57. DL Signal Level and RSRP
In Atoll, the signal level is the total
instantaneous power of RS signal when
RS is transmitted. In case the power
offset is 0 between RS RE and other
RE, this signal level is 7.8 dB
(10*log(12/2)) lower than total carrier
power.
In LTE, RSRP is used, which is defined
as the average of power levels received
across all Reference Signal symbols
within the considered measurement
frequency bandwidth. Since in 10Mhz
bandwidth there are 100 REs ( 2 RE/FB
* 50 FBs) used for RS. Hence, the
RSRP is 10*log(100) = 20 dB lower
than the signal level.
S-Syn P-Syn
Ref. DTX S-Syn P-Syn
S-Syn P-Syn
S-Syn P-Syn
DTX Ref. S-Syn P-Syn
S-Syn P-Syn
S-Syn P-Syn
Ref. DTX S-Syn P-Syn
S-Syn P-Syn
S-Syn P-Syn
DTX Ref. S-Syn P-Syn
S-Syn P-Syn
The signal level is calculated
only during RS active time
1 Frequency Block (FB)
includes 12 subcarriers
2 Res used for RS per
FB during RS active time
58. Settings
Name the prediction study,
define the resolution
Define display type and
field
Depending on the prediction,
settings on terminal, mobility
service, and MC simulation
results may be needed.
59. Settings
To customize the display legend, you can work on the window manually, or click
Actions->Shading to re-define it automatically.
61. Coverage by Best Server (based on RS signal
level)
Click Predictions->New->Coverage by Transmitter.
Margin is changed here
62. Coverage by Number of Servers (based on RS
signal level)
Click Predictions->New->Coverage by Transmitter. Since there is no SHO in LTE,
the areas with 3 or more servers may subject to strong interference.
LTE does not support SHO, any
locations with 3 or more servers
indicates potential interferences
64. Coverage by UL PUSCH & PUCCH C/(I+N)
Atoll practices power control such that
the max SINR is equal to the required
SINR for highest MCS plus a margin.
65. Reference Signal C/(I+N) and RSRQ
In Atoll, the coverage by RS C/(I+N) can also be calculated. If the power offset
between RS and PDSCH is 0 dB, it is found that the RS C/(I+N) is always 3 dB
lower than the PDSCH C/(I+N) since there is no Tx diversity for RS.
In LTE,
RSRQ = N*RSRP/RSSI,
where N is the number of FBs. Since the RS CINR is calculated only on symbol
duration when RS is active, we have
RS CINR = RSRP/(I+N of one subcarrier) = RSRP/RSSI*(N*12).
By comparing these 2 formulas, we have
RSRQ = RS CINR/12 = RS CINR (dB) – 10.8 dB.
67. Coverage by UL Peak RLC Allocated Bandwidth
Throughput
Note: the allocated bandwidth
throughput is the max throughput for
a UE in UL if there is sufficient
frequency blocks.
Due to the limited power at UE, one
UE does not use all UL RBs typically.
Hence, the allocated BW throughput
is different from the cell capacity.
68. Share Prediction Studies in Projects
It might be necessary to run same coverage prediction studies (such as RS signal
level, CINR) and use the same settings (such as required cell edge probability,
service for the prediction, legend) for different markets. In this case, the
predictions can be shared so save time and maintain the consistence cross
markets.
The following is an example list of pre-defined coverage prediction studies (*.cfg)
for Tx diversity and EPA05 mobility. We show how to import this list into a project
in next page.
69. Import Prediction Studies into Project
Click Tools->User Configuration->Import and select the *.cfg file (in previous page
for instance). Enable the 1st check box if you want to remove all of the existing
predictions.
Click OK and the list is imported.
70. Run Imported Predictions
The imported predictions are empty and locked. To run the predictions, we have 2
options
• Click each prediction ->Calculate to run individual prediction
• Click Predictions->Unlock Studies to unlock all predictions, and then click Predictions-
>Calculate to run all predictions
A key indicates a
prediction is
locked
72. Define Traffic Maps
MC simulation needs traffic maps. The following types of traffic maps can
be used in Atoll.
• Traffic maps per sector. It can be used if you have live traffic data from the OMC
(Operation and Maintenance Centre). The OMC collects data from all cells in a
network. This includes, for example, the number of users or the throughput in
each cell and the traffic characteristics related to different services. Traffic is
spread over the best server coverage area of each transmitter and each
coverage area is assigned either the throughputs in the uplink and in the
downlink or the number of users per activity status.
• Traffic map per user profile. This can be used if you have marketing-based
traffic data. Traffic maps per density of user profiles, where each vector (polygon,
line or point) describes subscriber densities (or numbers of subscribers for points)
with user profiles and mobility types, and traffic maps per environment of user
profiles, where each pixel has an assigned environment class.
• Traffic maps per density (number of users per km2). This can be used if you
have population-based traffic data, or 2G network statistics. Each pixel has an
actual user density assigned.
73. Create Traffic Maps Per Density
Here a traffic map is created using the method for Traffic maps per density. This traffic map
will be used in the following MC simulation example. Check the Atoll LTE User Manual for
how to create different types of traffic maps.
Define an environment for traffic called Type 1 in Geo->LTE Parameters->Environments
Double click Type 1 to open the table for its properties
User type density
Weighting on clutter
type and indoor
Business User Profile defined
in LTE Parameters
74. Create Traffic Maps Per Density
In Geo tab, click Traffic->New Map, and choose based on environments of user profiles,
click Create button.
In the new window, select Type 1, press the button for Polygon, and then draw a polygon
for the map areas where the traffic needs to be distributed.
75. Perform MC Simulations
Multiple simulations can be defined at one time.
Click Data tab->LTE Simulations->New, in the pop-up window
• General tab
• Specify a name for the simulation studies
• Specify the number of simulations. Multiple simulations result in better statitics.
• Specify the max allowed UL and DL traffic load constraints in cell level
76. Perform MC Simulations
• Source Traffic tab
• Global Scaling Factor is used to scale the traffic based on the selected traffic map
• Select the desired traffic map for simulation
• Advanced tab
• Specify the requirements for simulation convergence and the seed for random
number generation.
Click OK in any tab to
start simultion
78. Individual Simulation Results
Double click Simulation 4 to access the simulation
results.
• Statistics tab: statistics of the simulation results
• Sites tab: simulation results on eNodeB level
• Cells tab: simulation results on cell level
• Mobiles tab: simulation results for each active
mobile
• Initial Conditions tab: summary of the simulation
conditions
79. Average Simulation Results
To access the average simulation results of
all simulation under one group, click the
Group Name->Average Simulation
Double click Simulation 4 to access the
simulation results.
In this case, the Mobiles tab is not
available
80. Simulation Results on Cell Level
The cell level simulation results may be most interesting in both individual simulation or group of
simulation. The information such as cell UL and DL load, UL noise rise, throughput per service
or cell capacity on different layers can be found in this table.
Note: the average cell results render better statistics than individual simulation.
81. Use Simulation Results for Prediction
In coverage prediction studies, many needs
assumption about DL traffic load and UL noise
rise.
The assumption can be given in the Cells table
discussed earlier. However, how do we know if
the assumption makes sense for a given traffic
profile?
By selecting the Load Conditions for a
prediction, we can use either the assumption
from Cells table, or the desired simulation
results as the DL load and UL noise rise for
prediction
Cells table
Simulation
results
82. Update Cells Table Using Simulation Results
Likewise, if we want to update the Cells Table by simulation results, click Commit Results button
at the bottom.
84. Atoll ACP
The ACP (automatic cell planning) module has been integrated into Atoll. There is no need to
perform import and export between RF planning tool and the ACP module. However, a
separated license for ACP is required.
ACP enables network reconfiguration through two mechanisms:
• Parameter reconfiguration: ACP enables the reconfiguration of different network parameters to
improve network quality, such as the antenna model, the azimuth and tilt of the antenna,
the antenna height, the Tx power, RRM parameters, etc.
• Site selection capabilities: ACP can perform site and sector selection. Two main methods
are supported:
• Selecting which sites and/or sectors to suppress among existing sites in the
network.
• Selecting which sites to use among many candidates sites. Groups of
candidate sites can also be defined, which provides the possibility of selecting
a minimum and maximum number of sites to add within each group
By minimizing the global cost function, the ACP tries to optimize the network.
85. Launch ACP
Click ACP – Automatic Cell Planning->New to launch the ACP setup window, where all
constraints and conditions can be configured.
86. ACP Optimization Results
After the ACP optimization, the results can be accessed.
Summary of
improvement
The suggested changes
are ranked based on
improvement
Improvement up to the
number of changes
89. MIMO Modes in Atoll
Atoll supports 3 MIMO modes in DL
• Transmit diversity
• Spatial multiplexing
• AMS (automatic mode switch): a threshold is set for AMS. If the calculated SISO
CINR (before TxDiv gain is applied) is lower than the threshold, the UE is in
TxDiv mode, otherwise in SM mode.
90. C/(I+N) Calculation in Atoll
In Atoll, the CINR at each pixel is calculated based on SISO (1 BTS Tx
antenna and 1 UE Rx antenna). When more than 1 Tx and/or Rx antenna
are used, if UE is in TxDiv mode, the corresponding diversity gain is
added on the calculated CINR. If UE is in SM mode, then there is no
diversity gain for CINR. Instead, the capacity gain will be considered due
to 2 code streams.
• In Atoll, the Max Power per cell is corresponding to one Tx antenna port. That
is, if it is 30W (44.8 dBm), then the power is 30W+30W in case of 2 Tx antennas.
• Hence, for SM, the calculated CINR based on SISO could be 3 dB higher than
the real one since the interference will be doubled when 2 Tx antennas are used
in all neighbor cells.
• In case of TxDiv, both the interference and Tx power will be doubled. However,
since the signal is combined coherently and the interference is not, we still should
see about 3 dB gain.
91. AMS Not Working Directly for NSN Parameters
Though AMR is supported in Atoll, it does not work
correctly at Atoll 2.8.0 because
• The AMS threshold at 2.8.0 is based on RS C/N, not PDSCH
C/(I+N)
• 2 independent slow fading and standard deviations are used
for RS CNR and PDSCH CINR calculation. We saw examples
that a bearer is switched to SM at very low PDSCH CINR since
the RS CNR happened to be higher than the threshold.
Even if Atoll fix the problem in next release, the AMS
function cannot be used due to the special MCS vs
SINR tables obtained in NSN link level simulation.
• In case of TxDiv, the diversity gain has been built into the
table
• for a given UE, only 1 table can be used in Atoll. Hence, AMS
is possible only if we can find a way to combine the 2 tables
• if the SINR difference for each MCS is fixed, then it is possible
to use the table for SM and put the difference as part of the
diversity gain. Unfortunately, this is not true.
• Two work around methods will be presented later.
EPA05, SM EPA05, TxDiv
MCS SINR MCS SINR
1 -0.09 1 -6.09
2 1.41 2 -4.92
3 2.29 3 -4.29
4 3.63 4 -3.15
5 4.78 5 -2.46
6 5.74 6 -1.6
7 7.64 7 -0.63
8 8.9 8 0.44
9 9.75 9 1.33
10 11.51 10 2.16
11 11.71 11 2.38
12 12.55 12 3.11
13 13.79 13 4.09
14 14.92 14 4.97
15 16.18 15 6.06
16 17.42 16 7.12
17 17.95 17 7.46
18 18.61 18 8.26
19 19.22 19 8.69
20 20.55 20 9.86
21 21.52 21 10.69
22 22.63 22 11.58
23 23.5 23 12.5
24 24.82 24 13.47
25 25.97 25 14.68
26 27.61 26 15.79
27 27.86 27 16.42
28 28.97 28 17.17
29 30.78 29 18.64
92. Determine Best AMS Threshold
The AMS threshold should be recommended by global team. Here the best threshold is
derived based on the 2 MCS vs SINR tables for TxDiv and SM.
• For a given SINR, we can use SM to send 2 data streams on a lower MCS, or use TxDiv to improve the
SINR such that a higher MCS can be used for one data stream.
• The best threshold should be corresponding to the point below which TxDiv results in higher and above
which SM has higher throughput
• In case of EPA05, it is found that the threshold is 22.63 dB (based on the default MIMO gain table in Atoll).
EPA05, SM EPA05, TxDiv
3 dB gain
for SINR
MCS SINR CodeRate MCS SINR
If this
MCS for
SM
Then this
SINR for
TxDiv
Then This
MCS for
TxDiv
Corresponding
TxDiv CodeRate
Corresponding
SM CodeRate
SM/TxDiv
throughput
ratio
1 -0.09 0.21 1 -6.09 1 2.91 11 1.20 0.24 0.20
2 1.41 0.27 2 -4.92 2 4.41 13 1.55 0.33 0.21
3 2.29 0.33 3 -4.29 3 5.29 14 1.76 0.41 0.23
4 3.63 0.44 4 -3.15 4 6.63 15 2.00 0.55 0.28
5 4.78 0.54 5 -2.46 5 7.78 17 2.33 0.70 0.30
6 5.74 0.66 6 -1.6 6 8.74 19 2.50 0.88 0.35
7 7.64 0.79 7 -0.63 7 10.64 20 2.83 1.10 0.39
8 8.9 0.95 8 0.44 8 11.9 22 3.32 1.37 0.41
9 9.75 1.08 9 1.33 9 12.75 23 3.57 1.58 0.44
10 11.51 1.20 10 2.16 10 14.51 24 3.86 1.83 0.47
11 11.71 1.20 11 2.38 11 14.71 25 4.16 1.83 0.44
12 12.55 1.35 12 3.11 12 15.55 25 4.16 2.08 0.50
13 13.79 1.55 13 4.09 13 16.79 27 4.65 2.44 0.52
14 14.92 1.76 14 4.97 14 17.92 28 4.82 2.81 0.58
15 16.18 2.00 15 6.06 15 19.18 29 5.64 3.29 0.58
16 17.42 2.25 16 7.12 16 20.42 29 5.64 3.73 0.66
17 17.95 2.33 17 7.46 17 20.95 29 5.64 3.87 0.69
18 18.61 2.33 18 8.26 18 21.61 29 5.64 3.91 0.69
19 19.22 2.50 19 8.69 19 22.22 29 5.64 4.22 0.75
20 20.55 2.83 20 9.86 20 23.55 29 5.64 4.82 0.85
21 21.52 3.08 21 10.69 21 24.52 29 5.64 5.28 0.94
22 22.63 3.32 22 11.58 22 25.63 29 5.64 5.75 1.02
23 23.5 3.57 23 12.5 23 26.5 29 5.64 6.22 1.10
24 24.82 3.86 24 13.47 24 27.82 29 5.64 6.76 1.20
25 25.97 4.16 25 14.68 25 28.97 29 5.64 7.32 1.30
26 27.61 4.49 26 15.79 26 30.61 29 5.64 7.98 1.41
27 27.86 4.65 27 16.42 27 30.86 29 5.64 8.27 1.47
28 28.97 4.82 28 17.17 28 31.97 29 5.64 8.60 1.52
29 30.78 5.64 29 18.64 29 33.78 29 5.64 10.16 1.80
C/(I+N)
(dB)
Max SU-
MIMO
Gain
10 1.49444
11 1.52313
12 1.54998
13 1.57497
14 1.59813
15 1.61954
16 1.63928
17 1.65747
18 1.67423
19 1.68966
20 1.70389
21 1.71701
22 1.72914
23 1.74036
24 1.75075
25 1.7604
26 1.76937
27 1.77773
28 1.78552
29 1.79281
30 1.79963
31 1.80603
32 1.81204
33 1.8177
34 1.82303
35 1.82807
93. Determine Best AMS Threshold
Another way is to draw the code efficiency (bits/symbol) vs SINR curves for SM and TxDiv
(diversity gain should be applied in the SINR). The best threshold is the cross point of the
2 curves, which is 22.63 dB.
Code Efficiency
0
2
4
6
8
10
12
-10 0 10 20 30 40
SINR (dB)
Bits/Symbol
SM
TxDiv
C/(I+N)
(dB)
Max SU-
MIMO
Gain
10 1.49444
11 1.52313
12 1.54998
13 1.57497
14 1.59813
15 1.61954
16 1.63928
17 1.65747
18 1.67423
19 1.68966
20 1.70389
21 1.71701
22 1.72914
23 1.74036
24 1.75075
25 1.7604
26 1.76937
27 1.77773
28 1.78552
29 1.79281
30 1.79963
31 1.80603
32 1.81204
33 1.8177
34 1.82303
35 1.82807
94. AMS Work Around
To use AMS, we need combine the 2 MCS vs SINR tables for SM and
TxDiv into one. Simply combining 2 tables based on the AMS threshold
does not work.
In the following, we show 2 methods for AMS work around by examples.
• Method 1: work around in TxDiv mode. This method works fine if the MIMO gain is
independent of the mobility.
• Method 2: work around in SM mode. This method always works. However, more
MCS bearers need to be defined.
Though the best AMS threshold is found to be 22.63 dB for EPA05, we use
different thresholds in the examples for Method 1 and 2.
Note the best AMS threshold is based on radio channel or mobility
environment. For instance, the best AMS threshold for ETU70 is 21.59 dB.
• For prediction studies, each study involves a UE for a single mobility, hence we
can always use the best AMS threshold
• For MC simulation, each simulation may include UEs in different mobility
environments. However, only one threshold is defined in each cell. In this case, it is
better to use the minimum of the best AMS thresholds for all mobility environments.
95. AMS Work Around 1
The method 1 is presented using an example with
AMS threshold 21.52 dB.
The MCS vs SINR table for AMS is created based
on the 2 tables as follows
• Keep the tables for TxDiv.
• Add new MCS 30 – 38, which correspond to SM MCS 21
– 29, respectively.
• For each new MCS (say MCS 30), the required SINR is
equal to the required SINR for corresponding SM MCS
(say SM MCS 21) plus 3 dB, in order to cancel the 3 dB
diversity gain which is not available to SM MCSs.
Now, the table is combined. When SINR is lower than the
threshold, UE is operating in normal TxDiv mode (using
MCS 1-29). However, if the threshold is exceeded, one of
the MCS 30 – 38 will be assigned to UE (in SM).
EPA05, SM EPA05, TxDiv
MCS SINR MCS SINR
1 -0.09 1 -6.09
2 1.41 2 -4.92
3 2.29 3 -4.29
4 3.63 4 -3.15
5 4.78 5 -2.46
6 5.74 6 -1.6
7 7.64 7 -0.63
8 8.9 8 0.44
9 9.75 9 1.33
10 11.51 10 2.16
11 11.71 11 2.38
12 12.55 12 3.11
13 13.79 13 4.09
14 14.92 14 4.97
15 16.18 15 6.06
16 17.42 16 7.12
17 17.95 17 7.46
18 18.61 18 8.26
19 19.22 19 8.69
20 20.55 20 9.86
21 21.52 21 10.69
22 22.63 22 11.58
23 23.5 23 12.5
24 24.82 24 13.47
25 25.97 25 14.68
26 27.61 26 15.79
27 27.86 27 16.42
28 28.97 28 17.17
29 30.78 29 18.64
30 24.52
31 25.63
32 26.5
33 27.82
34 28.97
35 30.61
36 30.86
37 31.97
38 33.78
+3 dB
TxDivSM
96. AMS Work Around 1
Since MCS 30 – 38 are for SM, the
corresponding bits/symbol needs to
be defined in LTE Bearers.
We use MIMO SM gain 1.84 as an
example. Since MCS 30 is
corresponding to SM MCS 21.
bits/symbol = 3.077 (for MCS 21)
Bits/symbol = 3.077*1.84 = 5.66 (for MCS
30)
In reality, the MIMO gain varies with the
SINR. Hence, different MIMO gain needs
to be used for different MCS bearers.
Obviously, this can be done easily.
Note the MIMO gain for a MCS is different
in different mobilities since the required
SINR is different. If the MIMO gain
difference is ignorable, Method 1 works
fine. Otherwise, we have to use Method 2.
97. AMS Work Around 1
Update the Bearer Selection Thresholds table
98. AMS Work Around 1
Update the Quality Graphs
table and MIMO table
For consistence,
3 dB is given
99. AMS Work Around 1
Finally, update the Highest Bearer
to 38 for each desired service.
• If you want to simulate Tx Diversity
only, set this to 29, and MCS 30 – 38
will not be available.
• If you want to simulate AMS, set this
to 38, and all MCSs will be available.
Don’t forget to make sure that the
cell is set as TxDiv mode.
100. EPA05, AMS
MCS SINR
1 -9.09
2 -7.92
3 -7.29
4 -6.15
5 -5.46
6 -4.6
7 -3.63
8 -2.56
9 -1.67
10 -0.84
11 -0.62
12 0.11
13 1.09
14 1.97
15 3.06
16 4.12
17 4.46
18 5.26
19 5.69
20 6.86
21 7.69
22 8.58
23 9.5
24 10.47
25 11.68
26 12.79
27 13.42
28 14.17
29 15.64
32 22.63
33 23.5
34 24.82
35 25.97
36 27.61
37 27.86
38 28.97
39 30.78
AMS Work Around 2
The method 2 is presented using
an example with AMS threshold
22.63 dB.
The MCS vs SINR table for AMS
is created based on the 2 tables
as follows
• For MCS 1 – 29, using the tables
for TxDiv but put all diversity gain
into SINR table.
• Add new MCS 30 – 38, which
correspond to SM MCS 21 – 29,
respectively.
Now, the table is combined. Cell is
set to SM mode. When SINR is
higher than the threshold, UE is
operating in normal SM mode (using
MCS 32 – 39). However, if the
threshold is lower, one of the MCS 1
– 29 will be assigned to UE (in
TxDiv).
-3 dB
TxDivSM
EPA05, TxDiv
MCS SINR
1 -6.09
2 -4.92
3 -4.29
4 -3.15
5 -2.46
6 -1.6
7 -0.63
8 0.44
9 1.33
10 2.16
11 2.38
12 3.11
13 4.09
14 4.97
15 6.06
16 7.12
17 7.46
18 8.26
19 8.69
20 9.86
21 10.69
22 11.58
23 12.5
24 13.47
25 14.68
26 15.79
27 16.42
28 17.17
29 18.64
EPA05, SM
MCS SINR
1 -0.09
2 1.41
3 2.29
4 3.63
5 4.78
6 5.74
7 7.64
8 8.9
9 9.75
10 11.51
11 11.71
12 12.55
13 13.79
14 14.92
15 16.18
16 17.42
17 17.95
18 18.61
19 19.22
20 20.55
21 21.52
22 22.63
23 23.5
24 24.82
25 25.97
26 27.61
27 27.86
28 28.97
29 30.78
101. AMS Work Around 2
The bearer efficiency for MCS 32 – 39
is same as that for MCS 22 – 29,
respectively. However, we define no
MIMO gain for MCS 1 – 29 (TxDiv),
and normal MIMO gain is applied to
MCS 32 – 39 (SM).
Method 2 can work with any MIMO gain
table.
102. AMS Work Around 2
Define a new mobility type for AMS (called MIMO_AMS_EPA05 here). Use the
combined MCS vs SINR table for Bearer Selection threshold definition.
103. AMS Work Around 2
Update the Quality Graphs table and MIMO table accordingly.
• MCS 1 – 29, 0 for MIMO gain, 0 for Diversity gain (diversity gain included in SINR table)
• MCS 32 – 39, MIMO gain based on SINR, 0 dB diversity gain.
104. AMS Work Around 2
Finally, update the Highest Bearer to
39 for each desired service.
• If the highest bearer is set this to 29,
MCS 32 – 39 will not be available. That
is, we can use this as a work around for
Tx Diversity
• If we want to simulate AMS, set this to
39, and all MCSs will be available.
Don’t forget to make sure that the cell is
set to SM mode!
105. AMS Work Around 2
In concept, Method 2 also works well if cell is set to AMS mode and the AMS
threshold is set to any value lower than the target threshold (22.63 dB in the
example) if the AMS function works properly. This is because even if cell is switched
to AMS for a bearer in MCS 1-29, the bearer is actually still in TxDiv due to the work
around. However, setting cell in AMS should not be performed since
• if the AMS threshold is set to a value higher than the threshold by mistake, the
results would be incorrect
• A bug is found in current version of Atoll 2.8.0. When cells are set to AMS mode in
Monte Carlo simulation, it is found that MCS bearers cannot be selected correctly
since:
• According to Forsk, the AMS threshold is not based on PDSCH CINR, but on
Reference Signal CNR
• There are slow fading standard deviations used separately for PDSCH CINR
and RS CNR calculation. Consequently, we saw bearers with high CINR in
TxDiv mode and that with low CINR in SM mode due to the relevant RS CNR.
Fortunately we need a work around method for AMS from beginning. Hence, the
AMS issue in Atoll has no impact on us!
108. Physical Cell ID Planning
Physical cell ID can be allocated manually or automatically. To perform
automatic physical cell ID planning, click Transmitters->Cells->Physical
Cell IDs->Automatic Allocation.
110. Existing Issues
The following issues are identified in Atoll v2.8.0 Build 2912.
• C/(I+N) calculation
• Setting C/I Standard Deviation in the table for Clutter Class Properties: to
saving computation time, the shadowing is not applied to each interference.
Instead, in CINR calculation, Atoll calculate CINR firstly without considering any
shadowing, and then apply a shadowing based on C/I standard deviation to the
calculated CINR. In UMTS, according to Forsk, C/I standard deviation is typically
3 dB lower than the model standard deviation. In LTE, Forsk recommends to use
the same for model and C/I standard deviation, but this recommendation is not
verified by simulation or other analysis.
111. NSN Link Budget and Dimensioning Tool
Many parameters for Atoll settings can be found in the file below:
Where the SINR thresholds for MCS are from the NSN Dim tool below. Check
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/380069775 for latest
version.
112. LTE Project Template
The following is the xxx.mdb files with NSN parameter settings for Atoll, where v1.0 and v2.0
use method 1 and 2 for AMS work around, respectively. The pre-defined prediction studies for
Tx diversity and EPA05 are also given.
Another way to create a project with NSN parameter settings is open an existing project with
the correct settings (possibly for different market), and then remove the unwanted geo data,
sites, coverage predictions and Monte Carlo simulation results, etc in the existing project, and
save it as a new project. Then the same procedures discussed in this document can be used to
create the project for the new market.
In the attached zip file below, the file v1.0 and v2.0 use method 1 and 2 for AMS work around,
respectively.
Comparing with xxx.mdb, the xxx.ATL not only keep all the parameter settings, but
also the pre-defined coverage predictions and Monte Carlo simulations.
NSN parameters and Prediction list may be
updated!!! Try to get the latest one before creating
the project.
113. References
1. Atoll_2.8.0_User_Manual_Radio_E3.pdf: the user guide for using Atoll for LTE
design.
2. Atoll_2.8.0_Technical_Reference_Guide_E3.pdf: provide the formulas used in
Atoll for calculation and explains how Atoll works.
3. ATOLL_acp-technical-notes.pdf: manual for ACP module in Atoll
4. Atoll_LTE_Planning_Guide.doc: a NSN document about using Atoll for LTE.
5. LTE Coverage planning with Atoll. https://sharenet-
ims.inside.nokiasiemensnetworks.com/Download/408254821
6. 09_-_LTE_Planning_Tool-ATOLL.ppt, https://sharenet-
ims.inside.nokiasiemensnetworks.com/Download/406923098
Notas del editor
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.
ASN.1( Abstract Syntax Notation) is the specification used to define the coding of the information elements within RRC messages, e.g. it defines the content of the RRC Connection reconfiguration message .The freezing just means that a specific version has been agreed and then does not change. This allows all of the vendors to implement a common set of rules so everything is compatible. When changes are made in future releases then they are done such that they are backwards compatible to the previous versions.