Passing On and Copying of This Document, Use and Communication of Its Contents Not Permitted Without Written Authorization From Alcatel-Lucent

Passing on and copying of this document, use and communication of its contents
not permitted without written authorization from Alcatel-Lucent

Copyright 2012 Alcatel-Lucent. All Rights Reserved.
TMO18075_V2.0-SG-B11-B12-Ed1 Module 1.1 Edition N/A
Section 1 Module 1 Page 1
TERMS OF USE AND LEGAL NOTICE
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training course
and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms of Use and
Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from time to time
without prior notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment constitutes your
acceptance of and agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to wear
conductive jewelry while working on the products. Equipment referred to or used during this course may be electrostatic sensitive.
Please observe correct anti-static precautions.
PERMISSION TO USE CONTENT

The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided in this
training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other authorized
participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable permission to access
and use the Content solely for your personal training and non-commercial use. This permission may be terminated by Alcatel-
Lucent at any time for any reason or no reason, with or without notice. You must immediately cease use of the Content upon such
termination.
COPYRIGHTS AND TRADEMARKS

The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and Alcatel-
Lucents corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws, including but not
limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights laws (collectively, "IP
Rights"). In addition to Alcatel-Lucents IP Rights in the Content, in part and in whole, Alcatel-Lucent, and any of the third parties
who have licensed and/or contributed to the Content, owns a copyright in the formatting and presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these Terms of
Use and Legal Notice. All other use of Content from this training course, including, but not limited to, modification, publication,
transmission, participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative works from,
distribution, performance, display, incorporation into another training course or presentation, or in any other way exploiting any of
the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited and shall not be made
without Alcatel-Lucent
Alcatel Lucentss prior written consent.
consent All characters appearing in this training course are fictitious
fictitious. Any resemblance to real
persons, living or dead, is purely coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the Content. Alcatel,
Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks are the property of their
respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos, marks, trademarks, slogans and
product designations in any fashion. Granting of the right to access and use the Content for training purposes does not confer
upon you any license under any of Alcatel-Lucents or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM, DAMAGE, OR ANY
SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING WITHOUT
LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT LIABILITY OR OTHERWISE,
THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE CONTENT OR THE TRAINING
COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS, DIRECTORS, AGENTS OR EMPLOYEES IN
CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING, WITHOUT LIMITATION, THE USE OF OR
INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT
SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR
LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of Use
and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute or a court
of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision that reflects the
intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal Notice shall remain in
full force and effect. You may not assign these Terms of Use or any permission granted hereunder without Alcatel-Lucents prior
written consent. Nothing herein shall be deemed an employment agreement or an offer of employment or an alteration in any
way of a users terms of employment with or within Alcatel-Lucent.
Copyright 2011 Alcatel-Lucent. All Rights Reserved

Your feedback is appreciated!
Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:

TMO18075_V2.0-SG Edition 1
Thank you!

Document History
Edition Date Author Remarks
01 2012/10/10 Cosmin, Duna First edition

Page
1 IP transport on Abis interface 7

1.1 BSS transport configurations 8
1.2 Abis connection options 9
1.3 Abis group 10
1.4 Abis topology declaration 11
1.5 Abis group/IP chain creation 12
1.6 Abis bandwidth parameters 13
1.7 Abis bandwidth usage estimation 16
1.8 TDM VS IP Abis dimensioning 17
1.9 BTS IP configuration overview 18
1.10 IP configuration for IPoE1 BTS 19
1.11 IP configuration for IPoEth BTS 21
1.12 Switch BTS transmission mode 26
1 IP transport on Atermux interface 36
2.1 Mixed mode CS Atermux transport 37
2.2 Atermux related SBLS 39
2.3 Atermux topology 40
2.4 TCSL 41
2.5 Mixed mode PS Atermux transport 42
2.6 BSC-MFS IP links 44
2.7 BSC-MFS TDM links 45
1 BTS transmission capacity increase 48
3.1 BTS capacity increase 49
3.2 GNC daughter board 50
3.3 Attach extra Abis links 51
3.4 Detach extra Abis links 53
1 IMT evolution 56
4.1 Boosted GP management 57
4.2 Spare management mechanism 58
4.4 IP transport management 60

Page

Section @@SECTION Module @@MODULE Page 7
After migrating an existing BSC to B12, if the operator decides to activate the IP transport, the target transport
configuration will be mixed mode as long as TDM BTSs are still connected to that BSC. The migration to a full
IP BSS is performed smoothly as the existing TDM BTSs are upgraded to IP transport.
Prior to switching to IP transport mode, one must set first all the IP parameters for BSC, MFS and TC.

For IPoEth BTSs, the chain or ring configurations make no sense anymore and , therefore, the only available
topology is the Abis group, as a group of BTSs sharing the same last mile bottleneck.
Since the TDM transport can coexist with the IP transport in mixed configurations, the classical TDM chains or
rings can still be used if some sites cannot be easily upgraded to IP transport (old BTSs equipped with
SUMP/SUMA, remote sites with TDM infrastructure).
IPoE1 transport, which will be available in B12.2, allows the encapsulation of IP packets in PPP or MLPPP frames,
so the already existing E1 transport network can be reused allowing the operator to take benefits of the IP
transport efficiency with minimum investments. For this type of transport configurations, only the chain topology
is allowed.

An IP chain can us one or two Abis links. In the later case, only one BTS is supported in the chain due to HDLC
capacity limitation in the BTS. Nevertheless, four Abis links are available on SUMX only (equipped with GNC) and
a multiple BTS chain would not give great efficiency since SUMA is the main candidate for IPoE transport
configurations.
If two Abis links are connected to the BTS, the BSC automatically reevaluates the Abis bandwidth in case of
singe Abis failure.

The operator should compute a mean RSL bandwidth at group level based on the logical configuration of all the
BTSs in the group instead of configuring complex multiplexing rules at BTS level or sometimes sector level. Given
the dynamic nature of the IP transport, low traffic RSLs will compensate those with very high signaling load (HR
or VAMOS enabled TRXs).
The OML has one of the lowest priorities amongst the BTS IP communication links, therefore, its bandwidth is
assumed neglijable.

Modifying the configuration of one Abis chain/ring required complex calculations for evaluating the possibility of
BTS/TRE addition. Within an IP environment, the OMC-R offers the automatic bandwidth estimation option, so
that the operator can check, with a single click, the amount of available bandwidth in the group making the
extension/reduction operations much easier.

BTS get their IP address (and other necessary IP network access configuration, e.g. subnet mask and gateway
address) via:
- DHCP in case of Ethernet BTS
- or DHCP over PPP for E1 links
-or are (optionally) manually configured in case of Ethernet BTS
Concerning the DHCP visibility in the network, there are two possibilities:
-DHCP function is in the same LAN as the requesting BTS: nothing to be done in that case, the DHCP discover
will be broadcasted in the subnet.
-DHCP function is not in the same LAN as the requesting BTS: the DHCP discover cannot be broadcasted
towards the server, so DHCP relay must be enabled in all routers in the BTS DHCP network path.

The usage of IPoE1 transport requires the presence of a TPV3i4 in the BSC which plays a very important role:
IP/MLPPP to IP/Ethernet packet routing,
DHCP relay for the OMC-R embedded DHCP server.
The only allowed IP configuration for an IPoE1 BTS is dynamic address allocation by a DHCP server which is
always the OMC-R, so no external DHCP server can be used. Given the fact that an IPoE1 BTS can never be in
the same L2 network with the OMC-R, DHCP relay is mandatory and it is implemented by default in the TPGSM
board of the BSC (which is one of the routers in the BTS-DHCP network path).
The operator defines a BTS IP identifier at BTS creation which will be used as a DHCP client ID by the BTS
during the DHCP procedure. The same identifier must also be defined locally in the BTS at commissioning.
The OMC-R gets a starting IP address and a network mask from the BSC (Start_IPoE1IPAddress and IPoE1-IP-
Subnet-mask) and automatically configures the internal DHCP server with an IP address and client identifier. .

If a manual configuration is chosen, the OMC-R only needs to know the BTS IP identifier (still mandatory) and
the IP address. The same parameters will be also configured locally at the BTS during commissioning.
The other IP parameters like network mask and gateway must be configured in the BTS alone since they are
relevant in the BTS network segment only.

The OMC-R DHCP server can also be used for BTS IP address allocation.
In this case, the user must configure a BTS IP identifier in the BTS at commissioning and a group of parameters
at the OMC-R during BTS creation:
z An identical BTS IP identifier,
z The IP address (the same address will be allocated to that BTS all the times)
z The network mask,
z The broadcast address,
z The default gateway.
The additional IP configuration like network mask and gateway must be defined in the OMC-R since it will
configure the internal DHCP server accordingly. The mask and gateway together with the BTS IP address will be
sent to the BTS during the DHCP procedure.
In order to reduce the operator workload, routing subgroups can be defined at the OMC-R containing additional
IP parameters (e.g. mask, gateway) so that whenever a new BTS is created, according to the chosen IP address,
the OMC-R can propose to the operator the other IP parameters (provided that a group containing that IP
address was already created).

Only the BTS IP identifier and a hostname must be defined at the OMC-R upon BTS creation if the operator
chooses to use an external DHCP server.
The DHCP server is configured independently by the network administrator with a BTS hostname address and
DHCP client identifier identical to the one configured in the BTS at commissioning.
Whenever a BTS gets its IP address, the DHCP will update the DNS so that the OMC-R can always retrieve the
BTS IP address with a DNS lookup.

Overview of the required IP parameter:
z IPoE1:
Qmux address
BTS IP identifier
z IPoEth with manual configuration
Qmux address
BTS IP identifier
BTS IP address
z IPoEth with internal DHCP
Qmux address
BTS IP identifier
BTS IP address
Network mask
Gateway address
z IPoEth with external DHCP
Qmux address
BTS IP identifier
BTS hostname

IP transmission settings to be performed locally with the BTS
NEM:
Parameter Configuration
Transmission SetittoIP
Abis connectedinterface E1 forIPoE1

Ethernet forIPoEth
FramingforIPoE1 Set thenumberof
subsequentusable
timeslotsstartingfroma
certainposition
IPoEth parameters IfDHCPisused(OMCR
orexternal),setthe
DHCPusagetoUSED,
otherwisemanually set
theIPaddress,maskand
gateway
DHCPclientID Setitaccordingtothe
OMCRconfiguration
(BTSIPIdentifier)
IPoE1parameters DHCPusagemandatory

The DHCPMGR application offers a user friendly interface for managing the embedded OMC-R configuration.
For every routing subgroup created, one must see an entry in the Network list.
For every BTS created one must see an entry within the corresponding network.

The BTS placeholder holds the pre provisioned IP configuration of the BTS to be moved. After preloading the IP
software into the BTS, one can simply cut/paste the TDM BTS over the placeholder ->the BTS will take over the
placeholders IP configuration, but the operator can still change some IP parameters if required.
When using a placeholder for an IPoE1 BTS it is important to create it on the right TP since the IP address
reserved by the internal DHCP is automatically computed as a function of IP chain number and BTS position in
the chain.

This page is left blank intentionally

The MT120 board listens to both traffic sides (IP and TDM) and reacts according to the current traffic path.
Since the MSC is the NE in charge of A interface resource allocation, it is not aware of the BTS transport type.
If the traffic comes from a TDM BTS, the call is carried over a TDM Atermux chosen by BSC. The is no fixed
relation anymore between the A and Atermux interfaces thanks to the TCIF internal switch which is controlled by
the BSC through the TCSL link.
If the traffic comes from an IP BTS, the call reaches the TCIF subsystem through an IP transport network. From
here it is routed towards the proper MT120 board over the HIS interface.

Prior to changing the BSS transport mode, one must configure the TCSL parameters in the BSC and TC using the
local NEM (TCSL IP address BSC, TCSL IP address TC and TCSL port numbers. After the transport mode switch,
the TCSL becomes active and all TDM Atermuxes (if they exist) are managed by BSC through TCSL.
Due to the concentration function performed in the TCIF subsystem, the fixed relationship between A/Ater and
Atermux interfaces is removed, a call can reach a specific MT120 board over any Atermux since it is routed
through the TCIFS TDM switch.
The BSC keeps track of used Atermux resources in an Atermux pool which is managed over the TCSL link. The
same link is used for the overall TC O&M.

CS-ATERMUX - Represents the CS Atermux capacity for TDM BTS of IP BSS, its state depends on both MT120
and Atermux alarms.
TRAU-CP Represents the MT120 board.
Ater-HWAY-TP have the same meaning as before and are kept even for a full IP configuration. It is
recommended to disable them if the corresponding TDM links are disconnected.
ATR becomes mostly logical representing the BSC view of the A interface, Any Atermux related alarm will not
propagate to the ATR due to the TCIF concentration function.

The MFS can receive PS traffic from two different sources:
z TDM traffic directly from the BTS, for IPoEth BTSs,
z IP traffic from BSC, for IPoE1 BTSs,
z And TDM traffic from BSC, for TDM BTSs.
According to the traffic originator, the GP board will process the data in different ways:
z RLC/MAC layers and above, for TDM GCHtraffic,
z LLC layer and above, for IPGCH traffic.

In mixed transport configurations, some TDM Atermuxes must be kept until all BTSs switched to IP transport.
Their number shall be evaluated by the operator according to the number of TDM and it can be reduced to a
minimum.
In order to simplify the network configuration only fully dedicated PS Atermuxes can be defined, so no routing
through TC is possible anymore.

A new tab in the links configuration window allows the operator to declare the IP connectivity between a BSC
and a specific GP board. Once done, the IPGSL is created taking its IP configuration from the already provision
data.

Even if the two TDM and IP GSL SBLs are exclusive, the equipment can be pre-provisioned with both of them for
easy switching between IP and TDM transport.
When the BSS is configured in TDM mode, the operator firstly configures the IPGSL related parameters in BSC
and MFS (IP addresses). When triggering the transport mode switch, the IP GSL takes over and the GSL SBL
becomes not equipped.
The other way around, if TDM GSL is still present in the configuration, switching back from IP to TDM transport
can be faster without the need of GSL reconfiguration.

One of the important limitations of the BTS is the BSII internal bus which was limited to 4Mbps in both UL and
DL. B12 brings an improvement from this point of view allowing a 6Mbps throughput in DL, thus opening the
path towards higher capacity BTSs.
The BTS can take advantage of the higher traffic capacity even in TDM transport mode thanks to the two
additional Abis links.
The maximum achievable number of TRXs depends a lot on the type of hardware module fitted in the BTS
cabinet.
12 for TRA modules
24 for TWIN TRM modules
36 for MC-TRX modules (as well as for MC-RRH in the distributed BTS)

The GSM New Class daughter board can be fitted on any SUMX or SUMX19 module and brings additional
features such as:
z Optical Ethernet interfaces for Mc-RRH connections
z Opticaland/or electrical interfaces for Abis transmission (electrical transmission is already provisioned on
the SUMX motherboard)
z Third and fourth Abis links for TDM BTS with up to 36TRX

Needless to say, the only accepted topology for a high capacity BTS with four Abis links is the chain.
However, the second, third and fourth Abis links can be shared with other BTSs as well.
P OML BTS 1
S
2
1 T
3
F
4 5
BSC

The detach procedure follows the same procedure as the attach one - configure extra links and set the
corresponding port to a blank value.

Page 57
The MX-MFS currently implements a floating spare GP board: one GP board per MFS is identified as spare, and in
case a GP board fails, a GP switch-over takes place, and this spare GP board takes over the role of the failed GP
board. The failed GP board then becomes the new spare GP board. With this mechanism, the spare GP board is
floating, i.e. the spare GP board is not always mapped on the same physical GP board.
With the introduction of the Boosted GP Board, it is possible to mix in the same MFS normal GP Boards and
Boosted GP Boards. A normal GP Board will not have the capacity to support the same traffic as a Boosted GP
Board, which means that it cannot be used to secure a Boosted GP Board. However, in case of mix, because of
the floating spare mechanism, a normal GP Board may become the spare board. This means that with the
floating spare mechanism, it is not possible to get benefit of the additional capacity of the Boosted GP Board,
except if all GP boards are Boosted GP Boards.

The fix spare management approach follows the principle used by the 9135 MFS. When a switchover is
performed, the faulty board does not become spare after the fault removal and no redundancy is available for
the GP boards. Therefore, the operator must manually switch back and the GP board in slot 5 becomes spare
again.

In this example the GB is configured in TDM mode and therefore no IP address is configured.
As it can be seen in the configuration window, here both GSL and IPGCH addresses are part of the same
subnetwork because common tagging is used. So a single external router will carry O&M, GSL and IPGCH traffic.
Special care must be taken to avoid overlapping the IPGSL and IPGCH address sets (here there is a 40
addresses gap between the starting GSL address and the starting IPGCH address)

Page 63
Page 64
Page 65
This page is left blank intentionally

All rights reserved Alcatel-Lucent
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent


Passing On and Copying of This Document, Use and Communication of Its Contents Not Permitted Without Written Authorization From Alcatel-Lucent

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Passing On and Copying of This Document, Use and Communication of Its Contents Not Permitted Without Written Authorization From Alcatel-Lucent

Uploaded by

Copyright:

Available Formats

Passing on and copying of this document, use and communication of its contents

not permitted without written authorization from Alcatel-Lucent

PERMISSION TO USE CONTENT

COPYRIGHTS AND TRADEMARKS

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Please include the following training reference in your email:

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

01 2012/10/10 Cosmin, Duna First edition

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

1 IP transport on Abis interface 7

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Abis connectedinterface E1 forIPoE1

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

Copyright 2012 Alcatel-Lucent. All Rights Reserved.

You might also like