TELECOM

TTC 66553
UL 2100 RF SHARING

Description of the modifications required in x:akta in order

to implement the sharing of RF units for UL 2100

Oscar J. Díez Velasco

27/03/2018
 HISTORY OF CHANGES

Version Changes Author Date

0.9 Initial version. Oscar J. Díez 27.03.2018
1.0 First version after review with the users. Oscar J. Díez 28.03.2018
1.1 Extended description for the VISIO REPORT to be Oscar J. Díez 12.04.2018
modified.
Extended description for the changes in the excel patching
report.
1.2 Added information about the NETSITE interface Oscar J. Díez 20.04.2018

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

1
HISTORY OF CHANGES ......................................................................................... 1
INTRODUCTION ....................................................................................................... 3
HARDWARE MODEL ............................................................................................... 4
1.1 NODEB ............................................................................................................ 4
1.2 NODEB_IF_CARD ......................................................................................... 5
1.3 ETHERNET_PORT ......................................................................................... 6
1.4 RESOURCE TEMPLATES ............................................................................. 6
1.5 ENODEB.......................................................................................................... 8
1.6 ENODEB_IF_CARD ....................................................................................... 9
1.7 ETHERNET_PORT ....................................................................................... 10
1.8 RESOURCE TEMPLATES ........................................................................... 10
1.9 NODEB_SYSTEM_MODULE ..................................................................... 11
1.9.1 FSMF MODULE ..................................................................................... 11
1.9.2 FSME MODULE ..................................................................................... 11
1.10 ENODEB_SYSTEM_MODULE ............................................................... 12
ROUTING MODEL .................................................................................................. 13
2.1 CARDS_IN_SYNCHRO_REC ..................................................................... 15
2.2 CUSTOM SEARCH FOR RF CONNECTIVITY ......................................... 15
2.2.1 CONFIGURATION TABLE..................................................................... 16
NETSITE INTERFACE ........................................................................................... 18
REPORTING ............................................................................................................. 19

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

3.1 IUB_NODEB_HUPAFLOW ......................................................................... 19
3.2 IUB_NODEB_TRANS_IP_REPORT ........................................................... 19
3.3 IUB_NODEB_IPCLKLNK ........................................................................... 19
3.4 03_FTM_TRANS_IP_REPORT.................................................................... 19
3.5 03_01_FTM_TRANS_REPORT_IP_Flexilite .............................................. 19
3.6 EXCEL PATCHING REPORT ..................................................................... 19
CONSISTENCY_CHECK........................................................................................ 21
VISIO REPORTS ...................................................................................................... 22

2
 INTRODUCTION
This document describes the changes required in x:akta in order to enable the planning of
UL 2100 synchronization with sharing of RF between 3G and 4G.

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

3
 HARDWARE MODEL
This section describes the modifications to be implemented in the x:akta data model. It
includes the addition of some fields to existing types together with the logic behind them.

1.1 NODEB
The type NODEB shall be extended with 3 new attributes to be located below the existing
attribute “Configuration *” as depicted in the image below

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

The new attributes are named:

 RF_SHARING of type text and length 5 having possible values “true” and “false”
configured in LIST VALUES. The attribute will be set as read only and have the
description “RF Sharing*”.

 RF_SHARING_PARENT of type text and length 50. The attribute will be set as read
only and have the description “RF Sharing Parent*”.

 SYNC_MASTER of type text and length 5 having possible values “true” and “false”
configured in LIST VALUES. The attribute will be set as read only and have the
description “(RF) Sync Master*”.

The value of the fields are set automatically with the values exported by Netsite in a new
interface to be implemented and cannot be edited from the console.

The trigger TR_NODEB_NE_TYPE shall be extended to fire also on the update of

RF_SHARING. In case the value of RF_SHARING is “true” the trigger must set the value of
SYNC_MASTER to “false” in any other case it sets the value to “n/a”.
4
 A new set of associated records have to be configured in the NODEB with the name “RF
Sharing” and it must display, in case it exists, the eNodeB that is connected sharing the RF to
this NODEB. The record association must be based on a PLSQL function that looks at the
attribute RF_SHARING_PARENT and finds an eNodeB with the same basekey stored in this
attribute.

1.2 NODEB_IF_CARD
The following actions are required for the type NODEB_IF_CARD:

1. Edit the list values configured in the attribute CARD_NAME to make the following
changes:

a. Rename the value “UMPTa1” to “UMPT” and check that the list rule over
the attribute PRODUCT_CODE is still there. The corresponding value on
the attribute PRODUCT_CODE has to be edited as well.

b. Remove the following values:

i. “UTRPd1”

ii. “AXCC”

iii. “AXCF”

iv. “FTPB”

v. “FTIA”

vi. “IFU3S”

vii. “IFUG”

viii. “IFUH”

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

ix. “FQTrs”

x. “Unknown EPlus”

The corresponding LIST_RULEs over the PRODUCT_CODE and

UNIT_TYPE shall be removed as well.

The values existing in the table NODEB_IF_CARD_REC shall not be

removed. They will keep the values if any exists.

2. Add a new hidden attribute VENDOR to NODEB_IF_CARD and a trigger fired on

insertion that takes the from the VENDOR attribute of the parent node.

This attribute shall have a configured LIST VALUES for ‘NOKIA’, ‘Huawei’ and
‘ZTE’.

3. Add a new LIST RULE set in the attribute VENDOR over the attribute CARD_NAME
according to the following rules:

a. NOKIA -> “FTIB”, “FTLB”, “FTIF”, “IFU8P1”, “IFU-A”

b. Huawei -> “UMPT”, “WMPT”, “BASE BOARD”

c. ZTE -> “CC Board”, “CC16”

5
 4. Remove the existing LIST VALUEs in the field HARDWARE_VERSION and set the
new values: “a1”, “a2”,”a6”, “b1” and “b2”. A new LIST RULE shall be configured in
the CARD_NAME so the values listed before for the HARDWARE_VERSION are
only available for the CARD_NAME ‘UMPT’.

Set the default value in designer for “b1”.

5. Add a new trigger to NODEB_IF_CARD to be fired after insertion or update of

CARD_NAME or HARDWARE_VERSION. This trigger, in case VENDOR is
‘Huawei’ must set the value of the PRODUCT_CODE to

PRODUCT CODE = CARD NAME+HARDWARE VERSION

e.g. UMPTb1

6. The updates on CARD_NAME, HARDWARE_VERSION and PRODUCT_CODE

shall be propagated to all the NODEB_IF_CARDs in the network including
equipment libraries. And to the resource templates.

Note that when updating in the existing records the CARD_NAME from ‘UMPTxxx’
to ‘UMPT’, the suffix of the PRODUCT_CODE shall be used as
HARDWARE_VERSION.

This includes the population of the new attribute VENDOR.

1.3 ETHERNET_PORT
The ETHERNET_PORTs located below a NODEB_IF_CARD with CARD_NAME set to
UMPT must have the following configuration:

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

The attributes marked in yellow in the image shall be updated in all the existing records as
well as in the resource templates. This includes the records in the equipment library since they
are later used to create new resource templates (see next section).

1.4 RESOURCE TEMPLATES

The existing resource templates for Huawei shall be renamed according to the following
rules:

 BTS 320 2E Huawei eNodeB Huawei BTS 3202E

 BTS 380 3E Huawei NodeB Huawei BTS 380E

 BTS 3900 GSM BS Huawei BTS3900

 BTS 3900A GSM BS Huawei BTS3900A

6
  DBS 3900 GSM BS Huawei BBS 3900

A new set of resource templates shall be created from the elements in the equipment library
as described in the image below. Additionally the records in the equipment library shall be
moved to a new folder “Do not use”

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

The templates were initially created by Piotr within the context of a previous CS, so they
only need to be updated with the attribute updates mentioned in the previous sections and
activated as they are initially deactivated. The names are currently:

 NodeB Huawei DBS 3900 UMPT

 NodeB Huawei BTS 3900 WMPT

 NodeB Huawei DBS 3900 WMPT

 NodeB Huawei BTS 3900 UMPT

So a rename is required:

 BTS 3902E Huawei -> NodeB Huawei BTS3902E

7
1.5 ENODEB
The type ENODEB shall be extended with 3 new attributes to be located below the existing
attribute “Accept Clock Quality” as depicted in the image below

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

The new attributes are named:

 RF_SHARING of type text and length 5 having possible values “true” and “false”
configured in LIST VALUES. The attribute will be set as read only and have the
description “RF Sharing*”.

 RF_SHARING_PARENT of type text and length 50. The attribute will be set as read
only and have the description “RF Sharing Parent*”.

 SYNC_MASTER of type text and length 5 having possible values “true” and “false”
configured in LIST VALUES. The attribute will be set as read only and have the
description “(RF) Sync Master*”.

The value of the fields are set automatically with the values exported by Netsite in a new
interface to be implemented and cannot be edited from the console.

The trigger TR_ENODEB_ID_BIU shall be extended. In case the value of RF_SHARING is

“true” the trigger must set the value of SYNC_MASTER to “true” in any other case it sets the
value to “n/a”.
8
 A new set of associated records have to be configured in the ENODEB with the name “RF
Sharing” and it must display, in case it exists, the NodeB that is connected sharing the RF to
this ENODEB. The record association must be based on a PLSQL function that looks at the
attribute RF_SHARING_PARENT of the NODEBs and finds a NodeB having in the attribute the
basekey of the eNodeB.

1.6 ENODEB_IF_CARD
The following actions are required for the type ENODEB_IF_CARD:

1. Edit the list values configured in the attribute CARD_NAME to make the following
changes:

a. Rename the value “UMPTa2” to “UMPT” and check that the list rule over
the attribute PRODUCT_CODE is still there. The corresponding value on
the attribute PRODUCT_CODE has to be edited as well.

b. Remove the following values:

i. “FTIB”

ii. “FTLB”

iii. “FTIF”

iv. “LMPT”

v. “Unknown_Eplus”

vi. “Gbe-LTE-NodeB”

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

vii. “Gbe-LTE-Core”

viii. “DUL”

ix. “NTP-Router Ethernet”

x. “FSMF”

The corresponding LIST_RULEs over the PRODUCT_CODE and

UNIT_TYPE shall be removed as well.

The values existing in the table ENODEB_IF_CARD_REC shall not be

removed. They will keep the values if any exists.

2. Add a new hidden attribute VENDOR to ENODEB_IF_CARD and a trigger fired on

insertion that takes the from the VENDOR attribute of the parent node.

This attribute shall have a configured LIST VALUES for ‘NOKIA’, ‘Huawei’ and
‘ZTE’.

3. Add a new LIST RULE set in the attribute VENDOR over the attribute CARD_NAME
according to the following rules:

a. Huawei -> “UMPT”, “BASE BOARD”

9
 b. ZTE -> “CC Board”

4. Remove the existing LIST VALUEs in the field HARDWARE_VERSION and set the
new values: “a1”, “a2”,”a6”, “b1” and “b2”. A new LIST RULE shall be configured in
the CARD_NAME so the values listed before for the HARDWARE_VERSION are
only available for the CARD_NAME ‘UMPT’.

Set the default value in designer for “b1”

5. Add a new trigger to ENODEB_IF_CARD to be fired after insertion or update of

CARD_NAME or HARDWARE_VERSION. This trigger, in case VENDOR is
‘Huawei’ must set the value of the PRODUCT_CODE to

PRODUCT CODE = CARD NAME+HARDWARE VERSION

e.g. UMPTb1

6. The updates on CARD_NAME, HARDWARE_VERSION and PRODUCT_CODE

shall be propagated to all the NODEB_IF_CARDs in the network including
equipment libraries. And to the resource templates.

Note that when updating in the existing records the CARD_NAME from ‘UMPTxxx’
to ‘UMPT’, the suffix of the PRODUCT_CODE shall be used as
HARDWARE_VERSION.

This includes the population of the new attribute VENDOR.

1.7 ETHERNET_PORT
The ETHERNET_PORTs located below an ENODEB_IF_CARD with CARD_NAME set to
UMPT must have the following configuration:

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

The attributes marked in yellow in the image shall be updated in all the existing records as
well as in the resource templates. This includes the records in the equipment library since they
are later used to create new resource templates (see next section).

1.8 RESOURCE TEMPLATES

The existing resource templates for Huawei shall be renamed according to the following
rules:

10
  BTS 320 2E Huawei eNodeB Huawei BTS 3202E

Additionally the template with name “eNodeB Huawei UMPT” shall be extended with the
attributes for the ports described in the previous section.

1.9 NODEB_SYSTEM_MODULE
The NODEB_SYSTEM_MODULE objects invoked in the Nokia NODEB’s used within this
CR are those having PRODUCT_CODE set to ‘FSM’ and MODULE_NAMEs ‘FSMF’ and
‘FSME’. The NODEB_SYSTEM_MODULE itself does not require any adaptation. The changes
are located in the ports below them and as usual need to be propagated to the resource
template and to the existing records in the database.

1.9.1 FSMF MODULE

The ETHERNET_PORT in the position 001.002.002 has to be modified according to the
image below. The changes are highlighted in yellow.

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

1.9.2 FSME MODULE
The image below summarizes the changes to be done in the ports below the FSME module.

The CLOCK_PORT “Sync out-2.8” is new and shall be created.

11
 The ETHERNET_PORTs do already exist but need adaptations on the yellow marked
attributes.

The resource template with name “NodeB Nokia Felxi HW2” is the one containing FSME
modules and needs to be adapted accordingly as mentioned before. Update of the instantiated
records in the database is also required.

1.10 ENODEB_SYSTEM_MODULE
The ENODEB_SYSTEM_MODULE objects invoked in the Nokia eNodeB’s used within this
CR are those having PRODUCT_CODE set to ‘FSM’ and MODULE_NAMEs ‘FSMF’ and
‘FSME’. The ENODEB_SYSTEM_MODULE itself does not require any adaptation. The
changes are located in the ports below them and as usual need to be propagated to the
resource template and to the existing records in the database.

Below the module FSMF one of the ETHERNET_PORTs requires changes in its attributes.
The image below depicts the changes marked in yellow.

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

As usual, the changes must be propagated to the instantiated records and to the resource
templates.

12
 ROUTING MODEL
At the routing model, the main issue related to this ticket is the new synchronization model
in case of RF sharing. The eNodeB and the NodeB will be interconnected in order to get the
NodeB taking the synchronization from the eNodeB.

The final scenario is the eNodeB connected to the Clock Group as depicted in the image
below

And a second connection between the NodeB and the eNodeB where the NodeB acts as
Slave and the eNodeB as master. With this constellation the synchronization signal is taken by
the eNodeB from the Clock Group and propagated to the NodeB.

The required extra routing configuration is a new path of type SYNCHRO between the
NodeB and the eNodeB as depicted in the image below for the Huawei model

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

Note that there is only one IP_SERVICE that ends in the eNodeB. Between the NodeB and
the eNodeB there is only a SYNCHRO path.

In case of Nokia hardware, the configuration is similar but we have to distinguish two
possible scenarios depending on the module used: FSME or FSMF

For FSME modules the scenario is

13
 And for the FSME it is

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

Note that the module is FSMF on the eNodeB in both cases and the only difference is the
module used in the NodeB side. Depending on the module used on the NodeB, the ports to be
used in the NodeB are different. That is the only difference between both scenarios.

In case of Nokia we have so called COMBO Ports below the

(e)NODEB_SYSTEM_MODULE and the Module and (e)NODEB_IF_CARD. The trigger
checks that combo ports can be used only once in a TRUNK. In case of RF- Sharing the
EIF2 Port below the (e)NODEB_SYSTEM_MODULE is on it. But this port can be used for

14
tow Function TRANSPORT (EIF2) or sync (RP3-01). The Trigger is only relevant if the EIF
Port is a Transport port.

So we need an adaptation of the existing trigger:

IF the TRUNK will be saved and is between BS / NB/ eNB and the attribute of the
ETHERNET_PORT is RP3-01 the Trunk can be saved. In all other cases the Trunk cannot
be saved as it is already implemented.

2.1 CARDS_IN_SYNCHRO_REC
The product code FSM shall be inserted into the table CARDS_IN_SYNCHRO_REC in
order to enable the creation of the SYNCHRO path for the Nokia scenario with POS_LOW set
to 2 and POS_HIGH set to 4.

2.2 CUSTOM SEARCH FOR RF CONNECTIVITY

A new custom search named “Create RF Connectivity” shall be implemented.

The custom search shall be available at the type ENODEB.

It shall execute the following steps:

 Validate that the eNodeB has the attribute RF_SHARING set to “true” and
SYNC_MASTER also set to “true”, if not raise an error.

 Validate that NodeB and eNodeB exist on the same SITE, if not raise an error.

 Validate that the NodeB has the attribute RF_SHARING set to “true” and
SYNC_MASTER set to “false”, if not raise an error.

 Validate that the Basekey of the eNodeB is configured in the NodeB as

RF_SHARING_PARENT.

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

 Validate that the NodeB and eNodeB can be connected using one of the scenarios
in the images above, which means the vendors are compatible and the required
cards and ports exist. This scenarios shall be configurable in a database table as
described below.

 Find the relevant ports in the eNodeB and NodeB according to the models defined
in the images above which basically depends on the vendor of both elements and
in the Nokia case in the module type.

 Connect the ports using a CONNECTION_CABLE.

 Create a TRUNK over the CONNECTION_CABLE. The TRUNK requires a new

basekey which shall be created with the first three digits of the BASEKEY of the
master plus the type of the TRUNK (value 57) plus the placeholder ‘L’ which will
trigger the appropriate new value. If the range is full, try with adding 20 to the first 3
digits. The logic is already handled in the package NAMING.

 Create a SYNCHRO path over the TRUNK.

 Find if any IP_SERVICE of type ‘IUB-SYNC’ is terminated on the NodeB and in case
it exists, delete it. The deletion of the service must include resetting the value of the
attributes on the slave to null for the following attributes:

o Primary Clock Source

15
 o Secondary Clock Source

o Clock Prio 1

o Clock Prio 2

o Primary Master Clock IP

o Secondary Master Clock IP

o Sync Message Rate

o PTP Profile

If not done automatically, shall be done manually in the custom search.

As a general remark, a future scenario where connections between NodeB (Master) and BS
(slave) can be expected, so the implementation shall be as flexible as possible using the RPA
functions to get attribute values instead of direct selects to the REC tables where possible.

The implementation shall be reentrant. So in each step where anything shall be created, it
must be verified before any creation if the object is already there and in case it is, the step is
skip and the algorithm proceeds with the next step.

In case of any validation is not passed or any error occurs, the error must be raised and all
actions rolled back.

2.2.1 CONFIGURATION TABLE

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

A new configuration table shall be created to summarize the existing scenarios. The idea is
to reuse this table in case future scenarios are designed.

The table shall be named RF_SHARING_SCENARIO_REC and shall be implemented as

an x:akta node to enable adding new scenarios from the x:akta console.

It must have the following fields

FIELD DESCRIPTION
TYPE_MASTER Node type of the MASTER
TYPE_VENDOR Node type of the SLAVE
MASTER_VENDOR Value to be present in the attribute VENDOR of the MASTER
SLAVE_VENDOR Value to be present in the attribute VENDOR of the SLAVE
TYPE_CARD_MASTER Node type of the card in the MASTER
TYPE_CARD_SLAVE Node type of the card in the SLAVE
ATTRIBUTE_CARD_MASTER Attribute name of the CARD to be checked in the MASTER
ATTRIBUTE_CARD_SLAVE Attribute name of the CARD to be checked in the SLAVE
CARD_MASTER_VALUE Attribute value of the CARD to be checked in the MASTER
CARD_SLAVE_VALUE Attribute value of the CARD to be checked in the SLAVE
TYPE_PORT_MASTER Node type of the port in the MASTER
TYPE_PORT_SLAVE Node type of the port in the SLAVE
PORT_POS_MASTER Value of the attribute POS in the port of the MASTER
PORT_POS_SLAVE Value of the attribute POS in the port of the SLAVE
ATTRIBUTE_PORT_MASTER Attribute name of the PORT to be checked in the MASTER
ATTRIBUTE_PORT_SLAVE Attribute name of the PORT to be checked in the SLAVE
PORT_MASTER_VALUE Attribute value of the PORT to be checked in the MASTER
PORT_SLAVE_VALUE Attribute value of the PORT to be checked in the SLAVE
16
 The table shall be filled with the values required for the existing scenarios and consider
during the validations mentioned before and during the creation of the CONNECTION_CABLE,
TRUNK and SYNCHRO paths. In case 2 parallel connections are needed, as in the Nokia
scenario, 2 records will be present in the table.

The attached excel includes the initial values

RF_SHARING_SCEN
ARIO_REC values.xlsx

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

17
 NETSITE INTERFACE
The interface to Netsite needs to be extended to import he information for the attributes
RF_SHARING and RF_SHARING_PARENT.

The needed information is provided by Netsite in a new view named V_NE_ATTR_PLAN. It

is supposed to contain several attributes for each network element and the relevant information
for our case is encoded in the attribute "sharing_UL2100".

Therefore the SQL to retrieve any value is

SELECT NE.STANDORTNAME NE_BASEKEY, ATTR.ATTRIBUT_WERT RF_PARTNER
FROM V_NE_ATTR_PLAN@NPDB ATTR, V_NETZELEMENTE@NPDB NE
WHERE NE.NESO_ID = ATTR.NESO_ID
AND ATTR.ATTRIBUT_CODE='sharing_UL2100';

Where NE_BASEKEY is the basekey of the element which information we want to retrieve
and RF_PARTNER is the value of the RF partner.

The required functions/procedures shall be integrated in the current package containing the
interface to Netsite (package PK_IMPORT_NETSITE).

The execution of the interface shall be scheduled for one execution daily during the night in
one single procedure together with the interface update describes in the TTC ticket 65821.
Additionally an execution for a specific eNodeB or NodeB shall be possible from a custom
search on the eNodeB or NodeB, again both TTC tickets in one single procedure.

The procedure shall act in 2 steps:

1. Use the previous SQL (or a view hiding it in order to avoid compilation errors in case
the DB link is down) to get all the NodeB/eNodeB having an RF partner and update
the attribute RF_SHARING to “true” and RF_PARTNER to the value returned by
the SQL.

2. Make an SQL over all NodeB/eNodeB in x:akta having RF_SHARING set to “true”

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

or null MINUS the content of the previous SQL. That shall least all the elements
where the attribute RF_SHARING must be set to “false” and RF_PARTNER to null

18
 REPORTING
The following modifications in the reporting shall be implemented.

3.1 IUB_NODEB_HUPAFLOW
This report requires no change since the product codes hardcoded in the report have not
changed.

3.2 IUB_NODEB_TRANS_IP_REPORT
This report requires the following changes in its implementation:

PARAMETER VALUE
RF_SHARING NEW COLUMN if new attribute RF SHARING* of NB=true report "1" else "0"
after
SYNC_MESSA
GE_RATE

3.3 IUB_NODEB_IPCLKLNK
This report will only be filled in case an IP_SERVICE of type IUB_SYNC in status TOC ends
at the NodeB. This mean the report is empty if RF SHARING is used.

3.4 03_FTM_TRANS_IP_REPORT
This report requires the following changes in its implementation:

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

PARAMETER VALUE
RF_SHARING NEW COLUMN if new attribute RF SHARING* of NB=true report "1" else "0"
after
PTP_PROFILE

3.5 03_01_FTM_TRANS_REPORT_IP_Flexilite
This report requires the following changes in its implementation:

PARAMETER VALUE
RF_SHARING NEW COLUMN if new attribute RF SHARING* of NB=true report "1" else "0"
after
PTP_PROFILE

3.6 EXCEL PATCHING REPORT

The excel patching report must be extended to report the new connection between eNodeB
and NodeB as well as to provide information of the RF sharing situation in the first tab.

The first tab with name “Logical Parameters” shall be extended with 2 new rows “RF Sharing
Master” and “RF Sharing Partner” which shall be filled with the following information:

 RF Sharing Master: set to the content of the attribute SYNC_MASTER of the

eNodeB/NodeB. In case it is null, set the value to “false”.

19
  RF Sharing Partner: set to the content of the attribute RF_SHARING_PARENT of
the eNodeB/NodeB. In case it is null, set the value to “false”.

A possible implementation should use the function RPA_N.GetAttributeNonAutonomous to

get the attribute from the node, and set it to “false” in case it is null or “ERROR”. With this
approach there is no need to check for the type of the object either NodeB or eNodeB and could
work without changes in case the sharing is later implemented for BSs.

The picture below describes how the result should look like.

The rows are displayed in yellow only with the purpose of highlighting the changes. They
should be displayed in the same colors as the rest of the rows.

The tabs “TRUNKs Before Changes” and “TRUNKs After Changes” shall include the
TRUNK connecting the eNodeB and the NodeB with the value “SYNCHRO” for the column
“Planning domain”. The lines for the SYNCHRO routing and for the normal routing shall be
separated with one empty row.

The following embedded files are two examples. Again, the coloring is used only for
highlighting the changes. Should not be there in the final implementation.

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

306315025A_with_R
F_Sharing_example.xls

306320236A_with_R
F_Sharing_example.xls

20
 CONSISTENCY_CHECK
The check implemented in the procedure DIAGNOSTIC_CHECKS.CHECK_09 must be
updated:

 If there is no path of type SYNCHRO ending on the NODEB, the current

implementation applies validating that 2 IP_SERVICEs exist.

 If there is one path of type SYNCHRO ending on the NODEB, the check shall
validate that only one IP_SERVICE exists on the NODEB of type ‘NSN Iub’.

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

21
 VISIO REPORTS
The following reports shall be extended to include the new SYNCHRO path between
eNodeB and NodeB in case it exists:

 Router Concentrator (e)NodeB BS Prearranged.

Change the procedure RPA_VISIO_O2_MIN.RouterConcentratorENodeB in order

to include for every NodeB/eNodeB reported, the TRUNK in the SYNCHRO path
connecting the NODEB and eNODEB in case it exists.

For each port used in those additional TRUNKs, include following attributes in the
plan: Port Display

TTC 67061 – NEW LOGIC FOR CALCULATED REGION IN WDM

22