Details
-
Type:
Task
-
Status:
Closed
(View Workflow)
-
Priority:
Normal
-
Resolution: Fixed
-
Labels:
-
Customer:Ooreedo Tunisia
Description
Dear @Driss Chibane,
Could you please confirm the following points that I observed during data validation in the staging-DB for Nokia RAN:
1. On checking randomly across some tables for nodes like BSC/RNC/SRAN/BTS/NodeB/eNodeB, I found:
o Only the RNC table exists, but its data is blank (While data is available in CSV-Output).
o BTS is available under the table “Element_Node”.
My question is: since we validated all the CSVs earlier, under which table names and locations in the staging-DB should each dataset be available?
It would be very helpful if you could share a mapping/list that clearly describes which CSV data corresponds to which tables in S-DB.
(Element_Node snippet)
(RNC snippet)
Thank you
Indrasan
-
- OT_NSN-RAN_FRS_4G_Logical.docx
- 2.17 MB
- Indrasan Yadav
-
- Table Comparison_24-10-2025.xlsx
- 13 kB
- Indrasan Yadav
-
- Table Comparison_24-10-2025.xlsx
- 13 kB
- Indrasan Yadav
-
- Table Comparison.xlsx
- 13 kB
- Sandya Sharma
-
- Table Comparison.xlsx
- 13 kB
- Indrasan Yadav
-
- (Element_Node snippet).png
- 278 kB
-
- (RNC snippet).png
- 146 kB
-
- Snippet-1_26-12-2025.png
- 102 kB
-
- Snippet-2_26-12-2025.png
- 65 kB
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
- Transitions
- Trace
Dear @Sandya Sharma,
Please review my comments below and confirm. You may add your inputs against each question mark for clarification. (List attached)
Note: I have considered all CSV files for Huawei and Nokia RAN.
Best regards,
Indrasan
Dear @Sandya Sharma,
As discussed, I reviewed the CSV-Output files you shared with me yesterday and found a few points that require your confirmation:
1. Duplicate Headers in CSV-Output Tables
I noticed that several files contain duplicate headers, as listed below:
Sr. No. CSV-Output File Name Duplicate Duplicate headers name
1 ElementRanBs Yes id/name/elementName/external/importerConnector/internalOssId/netStatus/site/status/type/supplier/dumpsPath/versionid/importerId
2 ElementRnc Yes (same as above)
3 Role2G Yes (same as above)
4 Role3G Yes (same as above)
5 Role4G Yes (same as above)
6 Role5G Yes (same as above)
7 ElementBs Yes (same as above)
8 ElementBsc Yes (same as above)
9 ElementENodeB Yes (same as above)
10 ElementGNodeB Yes (same as above)
11 ElementNb Yes (same as above)
2- Missing Node/Parent Mapping in IPData File
In the CSV-Output IPData file, only IP/Mask/Gateway information is available. There is no node ID or parent detail mapping provided. Could you please confirm how we should validate the data against the respective node details and interfaces?
Thank you
Indrasan
WIP by Sandya and to provide her feedback by 6-10
Data to be validated only in SD not in CSV
Dear @Sandya Sharma,
Please find below the S-DB XML data validation feedback based on the parsed tables. Kindly review and share your comments or clarifications.
There are three categories under which the validation feedback has been summarized:
A. Data should be parsed – please verify and fix, as corresponding rules are already available in FRS.
B. Parameters requiring clarification – please confirm their purpose and intended usage.
C. Additional headers – please confirm if these are used for NEP mapping or any other purpose or we can ignore for now?.
1- Site:
The nodes which are parsing with “Default Site” seems blank for example the SRAN node: MRBTS-10999.
2- Addinfo:
(I) In table “addinfo” the serial is parsing with duplicate. (Example: “00014CN1013323641” for node MRBTS-15006)
However, the data of addinfo seems not updated as importer id is not updated for this table.
(II) For pending nodes which are not parsing in addinfo against adjacent/association node, I have added one more class in FRS as discussed, please check & fix the same.
(III) Could you please confirm about below headers and its purpose (This is only for NEP mapping purpose or data should parse here) as these are containing blank data however some should have data:
ID (should be parse)
NET Status (??)
Provisioned date
Insert date
External code
Insert by
Changed by
Changed date
3- BTS:
(I) Below headers are containing blank data.
BTS (should be parse)
NET Status (??)
Status (??)
4- BSC:
(I) Below headers are containing blank data.
Parent MSC
Parent SGSN
Operator (should be parse)
IP Data
MCC/MNC (should be parse)
NET Status (??)
Status (??)
5- 2G Cell:
(I) Below headers are containing blank data.
Element name (Should be parse)
6- 3G Cell:
(I) Below headers are containing blank data.
Element name (Should be parse)
NET Status (??)
7- 4G Cell:
(I) Below headers are containing blank data.
Element name (should be parse)
MCC/MNC (should be parse)
NET Status (??)
External (should be parse)
Site (should be parse)
Status (??)
Type (??)
Supplier (should be parse)
8- 5G Cell:
(I) MIMO Configuration/RET Tilt header is NULL (should be parse)
(II) The headers are missing:
Cell status/Uplink-Downlink ARFCN/UP-DN link Bandwidth/TAC/Cell Duplex Mode/MCC-MNC/External code/Site/Node/Object ID/Supplier
9- NodeB:
(I) Below headers are containing blank data.
LAC (should be parse)
RAC (should be parse)
Operator (should be parse)
IP Address
NET Status (??)
Status (??)
Dumps Path (should be parse)
Parent RNC Element (should be parse)
VLAN
CE (??)
NB Cell
Pool (??)
Element Name (should be parse)
External (should be parse)
Internal OSS ID (??)
Name (should be parse)
Site (should be parse)
Supplier (should be parse)
Type (Should be parse)
10- Board:
(I) Below headers are containing blank data.
Change date
Change by
Insert date
Insert by
Provision date
NET Status (??)
Description
Information source
Manufacturing date
Related node board (Should be parse)
TXN Direction
Protection board id
Merged board id
Caption
Terminal id
Far end
Power consumption
Dimension and weight
Additional information
Frequency grid
Attenuation
Zero dispersion slope
Chromatic dispersion slope
Bandwidth
Nose figure
Output power
Max RX Sensitivity
Min RX Sensitivity
Receiver Sensitivity
OSNR Tolerance
Wavelength
Amplifier gain
NE Mode (Should be parse)l
Node ID (Should be parse)
Dumps path (Blank somewhere Example: MRBTS-12112_1_1_19_0)
11- SRAN:
(I) Below headers are containing blank data.
External code (Should be parse)
NET Status (??)
Status (??)
12- RNC
(I) Below headers are containing blank data.
Operator (Should be parse)
IP Address
MCC-MNC (Should be parse)
Connection ID
NET Status (??)
Status (??)
13- Error alarm:
(I) Below headers are containing blank data.
Element ID (Should be parse)
Additional info
14- IP Data:
(I) Below headers are containing blank data.
Network interface name
Indix (Should be parse)
Node ID (Should be parse)
IP Status
Description (Should be parse)
Change date
Change by
Insert by
Insert date
External code (Should be parse)
Provision date
NET Status (??)
Rout domain
Dumps path (Blank somewhere)
15- Logical Interface: (Table is not updated based on importer ID)
16- Cabinet:
(I) Below headers are containing blank data.
Site (Should be parse)
Power consumption
Additional info
Dimension & weight
17- Node interface:
(I) Description values are parsing under header dumps path.
(II) Below headers are containing blank data.
Route map
Link piece
Traffic source
Level1linkid
Transmission direction
Possible level
External state description
Lambda name
Port direction
Is OSPF cost
External code (Should be parse)
Interface type (Should be parse)
NET Status (??)
18- Shelf:
(I) Below headers are containing blank data.
Manufacturer name (Should be parse)
Cabinet index (Should be parse)
Node id (Should be parse)
Additional info
Dimension & weight
19- Slot:
(I) Below headers are containing blank data.
Serial version UID
Change date
Change by
Insert date
Insert by
Provision date
NET Status (??)
Dumps patch blank somewhere
20- Antenna:
(I) Below headers are containing blank data.
Element node id (Should be parse)
Band
21- Sub interface:
(I) In dumps paths the value of description is parsing & description has blank data.
(II) Below headers are containing blank data.
Route map
Time slot
Change date
Change by
Insert date
Insert by
External code
Provision date
NET Status (??)
Status (??)
22- Cell radio bandwidths/eNodeB Bandwidths/ Cell tracking area:
Dumps path (Blank)
23- Role2G:
(I) Below headers are containing blank data.
BTS (Should be parse)
NET Status (??)
Status (??)
Operator (Header is missing it should be parse)
24- Role3G:
(I) Below headers are containing blank data.
LAC (Should be parse)
RAC (Should be parse)
Pool
Operator (Should be parse)
IP Address
NET Status (??)
Status (??)
Parent RNC Element (Should be parse)
VLAN
NB Cells
25- Role4G:
(I) Below headers are containing blank data.
IP Address
Pool
VLAN
MCC-MNC (Should be parse)
NET Status (??)
Status (??)
Operator (Should be parse)
26- Role5G:
(I) Below headers are containing blank data.
IP Address
Pool
VLAN
MCC-MNC (Should be parse)
NET Status (??)
Status (??)
Duld
Culd
Operator (Should be parse)
Dumps path (Should be parse)
Thank you
Indrasan
Dear Bassem Sabbagh
As discussed, I have attached the updated sheet "Table Comparison". The items highlighted in yellow still require clarification, while those marked in green have already been clarified by #Sandya.
Sandya Sharma please do the following as discussed:
1- the attached excel sheet should be finalized with Indrasan and all cells in column F should be filled with SD DB table name
2- in general, if any table or field not in use by connector (as per FRS or auto-filled by the connector) then this table or field should be removed from the code and dropped from the DB schema by integration. hence , sandya to advise about all above fields and to confirm with Driss. if they are not in use then to remove them from the code and to inform integration to drop them from the Db schema (one table to be shared eventually with integration with the names of all tables/fields to be dropped)
WL is 1.5 day.
as discussed with driss sir for this point where extra headers are coming and it is having no value in it , we can not remove them because may be they can use in other connectors so we can not remove them.
To be completed by today
delayed and to be delivered by 17-10 as Sandya is off the next week
shared the data to basant for upload on staging db.
Dear @Basant Kumar,
Please confirmed here once CSV Output upload is complete which is shared by @Sandya Sharma.
Still CSV Output is not uploaded on staging-DB.
Thank you
Indrasan
Table remarks:
I am sharing my feedback regarding the doubts mentioned in the attached table. The points highlighted in yellow are still pending, while the remaining items have been cleared.
__________________________________________
I have validated the data in the staging database based on the CSV output uploaded by @Basant Kumar, which you shared on 17-10-2025 here on same email (Importer ID: 20251024091640_2025-10-24-09.16.40).
Please find my validation remarks below:
1. As we discussed you confirmed with Driss, the extra header will be retained as it is.
2. The issue where I had commented “Should be parse” is still not fully resolved in some places. Please refer to my first email in this thread — I have highlighted in yellow the areas where it has been fixed.
To be started on 28-10
will fix it by today.
csv output shared to integartion.
Hi Sandya,
As discussed, I will validate the CSV output uploaded by Integration yesterday for the pending issues which were highlighted earlier and share feedback for same once done.
In the meantime, please address the below points:
1) Duplicate Cell ID & Name conflict with Huawei RAN (Reference JIRA: LS-755)
There are 6 Cell IDs and Names which are duplicated with Huawei RAN, therefore these records are not getting imported into NEP.
The below condition needs to be applied:
Append “_1” for the first cell’s ID and Name, and increment +1 subsequently for the next duplicates.
2) BSC IP not imported due to incorrect parsing of BSC Name instead of BSC ID in loopback interface (Reference JIRA: LS-756)
10 BSC IPs are not imported because BSC Name is currently being parsed instead of BSC ID.
Example:
Name objectId
BSCMNB06 BSC-415338
BSCMGH03 BSC-415383
will fix by today.
WIP and to be delivered by 4-11
Hi @Sandya Sharma,
Please find the validation remarks based on Importer ID “20251103115411_2025-11-03-11.54.11”.
In the first email of this thread, the items highlighted in yellow indicate the issues that have been fixed, while the items highlighted in blue indicate the issues that are still pending / not yet fixed.
Note: As discussed with #Driss, items except in blue and yellow can be ignored for now, based on your confirmation.
Thank you
Indrasan
for the upper comment which having import issue , xml has been shared.
WL to be defined by Sandya ..to be started on 5-11
will fix this and OT-83 by today.
Hi Sandya,
I will review the data in S-DB for OT-83 and OT-84. Could you please confirm, in this email thread, where you shared the CSV output with the Integration team, and whether it has been uploaded or not?
Additionally, please provide an update on the following points I highlighted with you last week:
1- Logical table not updated (Did you checked with Driss or not? if checked please update on same)
2- Fewer IPs present in the XML compared to those available in S-DB
hi indrasan please check the mail on 7-11 for the above issues.
Hi @Sandya Sharma,
As discussed, I have reviewed the latest data uploaded by @Basant Kumar on the S-DB for Nokia RAN. Please refer to my latest comment, highlighted in green with today’s date, in the initial thread email and below as well. These items are still unresolved and need to be fixed.
Consider Importer ID: 20251107090325_2025-11-07-09.03.25
8. 5G Cell: :
(I) MIMO Configuration (Fixed)/RET Tilt header is NULL (should be parse) 04-11: Table is not updated 11-11: Still same
(II) The headers are missing:
Cell status/Uplink-Downlink ARFCN/UP-DN link Bandwidth/TAC/Cell Duplex Mode/MCC-MNC/External code/Site/Node/Object ID/Supplier Tab 04-11: Table is not updated 11-11: Still same
15. Logical Interface: (Table is not updated based on importer ID) Not Fixed 11-11: Still same
17. Node interface:
(I) Description values are parsing under header dumps path. Not Fixed 11-11: Still same
19. Slot:
Dumps patch blank somewhere (Should be fixed) Not Fixed 11-11: Still same
21. Sub interface:
(I) In dumps paths the value of description is parsing & description has blank data. Not Fixed (Both headers should have correct data) 11-11: Still same
22. Cell radio bandwidths/eNodeB Bandwidths/ Cell tracking area:
Dumps path (Blank) Not Fixed 11-11: Still same
23. Role2G:
Operator (Header is missing it should be parse) Not Fixed 11-11: Still same
New Issues:
1- Total boards are 30589 and now 30083 are updating only which was Ok in previous Importer ID.
2- Total IP are 10079 and now 10015 are updating only which was Ok in previous Importer ID.
WIP and to be fixed by 13-11
XML shared.
Please find below the validation feedback based on the latest CSV output that was shared earlier for validation. The validation could not be completed at that time due to my involvement in another internal DEMO task.
Importer ID: 20251114121417_2025-11-14-12.14.17
8. 5G Cell
(I) MIMO Configuration / RET Tilt are partial parsing.
The MIMO Configuration and RET Tilt headers are currently NULL/None, whereas they should be parsed correctly for all where it is available in dump.
A reference snippet is attached for clarity.
Snippet-1_26-12-2025
Snippet-2_26-12-2025
(II) Missing Headers:
The following headers are missing or not populated correctly:
UP–DN Link Bandwidth (Not Fixed)
TAC (Not Fixed)
Site (Not Fixed)
Node (Not Fixed)
Supplier (Manufacturer – connector name is appearing instead)
Please review and address the above points.
WL = 1 mday ... to be started on 29-12 the second half
to be delivered by 30-12 the first half
code committed , after patch release integration will generate the xml for nsn and then validate the data in SD.
Hi Sandya,
After the latest patch was deployed, the integration team generated and uploaded the CSV output to the staging DB with the importer ID 20251231121137_2025-12-31-12.11.37.
I have validated this output, and my observations are as follows:
Validation Findings
1- The Operator field is blank in BTS.
2- The Manufacturer field is blank in 5G Cell.
3- MIMO Configuration is still parsing as “None” for MAX nodes (e.g., 315250 and MRBTS-212018). A snippet is attached for reference (MIMO Snippet_05-01-2026).
4- The eNodeB bandwidth count has changed from 13,826 previously to 2,938 currently.
5- The Loopback count has changed from 9,843 previously to 9,833 currently.
6- The header "elementNodeId" & it's value is missing in XML while available in CSV output in table "radioantenna"
to be started on 6-1
for the loopback interface issue dump is missing on server.
Only point # 4 is pending and to be concluded after we conclude the use of static files
Point no. 6 is still pending. Additionally, radio antenna details are now missing in the XML. In the previous version, radio antenna data was available, and only the elementNodeId header was missing.
Sandya to add more logs as the issue is not reproducible on DEV laptop
added logs , after patch release will check the logs and will fix then issue.
Logs are added as per Driss email
added the logs as per suggested by driss sir , but still they are not coming on server , mailed about it to driss sir.
now radio anteena data is coming in xml, xml shared on mail already , working on the second issue..
done some changes in the code for enodebbandwidth data , check the data in csv and confirm then will check the data on sd.
now enodbandwidth data is coming fine in the csv , please check and confirm.
A separate JIRA (OT-138) has been created for this activity, as the static sheets have been updated and the rules have been changed to parse frequency band, channel bandwidth, and DL/UL EARFCN.
Validation for all these changes will be performed under JIRA OT-138.
Currently, uplink/downlink channel bandwidth and uplink/downlink EARFCN are still not importing into NEP due to the following error:
“The parent EnodeB LNBTS-515143 of LTE Cell (515143_22) has no supported TDD bands.” under "4G Cell".
Although TDD band information is available in the XML, this issue is not being raised to the DEV team at this stage, as it will be validated based on the latest rules and parsing logic under OT-138.
Therefore, closing JIRA OT-84, as all issues under this ticket have been fixed, except the above, which is now tracked and validated separately under OT-138.
From: Bassem Sabbagh <bassem.sabbagh@mobinets.com>
Sent: 29 September 2025 18:04
To: Indrasan Yadav <Indrasan.Yadav@nuiva.com>; Driss Chibane <driss.chibane@mobinets.com>
Cc: Sandya Sharma <Sandya.Sharma@nuiva.com>
Subject: Re: Clarification On CSV Data Availability In Staging-DB
Dear Indrasan,
It should be the other way around. You need to share with Driss or Sandya the list of all CSVs that you are unable to map them with staging DB tables and they will share the tables name.
Thanks