Details
-
Type:
Task
-
Status:
Closed
(View Workflow)
-
Priority:
Normal
-
Resolution: Done
-
Labels:
-
Customer:Ooreedo Tunisia
-
- Consolidated Huawei Dump-Including BARF011.rar
- 18.99 MB
- Indrasan Yadav
-
- Ooredoo Tunisia Sample XML Validation_Huawei __ OT-17 __.msg
- 964 kB
- Indrasan Yadav
-
- OT_Huawei_RAN_2G_Logical_Inventory & Interfaces.docx
- 923 kB
- Indrasan Yadav
-
- OT_Huawei_RAN_3G_Logical_Inventory & Interfaces.docx
- 1.70 MB
- Indrasan Yadav
-
- OT_Huawei_RAN_4G_Logical_Inventory & Interfaces.docx
- 333 kB
- Indrasan Yadav
-
- OT_Huawei_RAN_All Nodes_Physical_Inventory.docx
- 1.75 MB
- Indrasan Yadav
-
- Radio antenna issues_22-09-2025.xlsx
- 2.91 MB
- Indrasan Yadav
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
- Transitions
- Trace
added missing code for cellduplex.
the code was not synchronized by sandya before the revision 135391 .. Sandya now to compare the two revisions 135390 & 135391
to identify the gap and rectify it
Hi Jharna,
In the earlier XML you shared (before the recent code commit), the CSV file for "ltecell" contained the header "Duplexing Mode", and it was successfully imported in NEP.
However, in the latest XML you provided, this header is missing.
Could you please check, fix the issue, and share the updated XML?
code committed
Hi Jharna,
Please commit the code for same.
xml shared
Dear Jharna Thakur,
As discussed, please address the issue identified under "Radio Antenna":
1- In cases where duplicate names are found, each subsequent duplicate must be made unique after the first data is parsed.
2- To achieve this, a special character \1 should be appended to the duplicate name, with the number incremented by +1 for each occurrence.
Example: (Attached)
Code committed
Dear Jharna Thakur,
Please commit the code for all issues that have been fixed so far. Once the pending issues listed below are resolved, I will request an additional code commit.
Pending Items
Huawei RAN:
1. IP Data – As discussed with @Jharna Thakur, I will review and confirm during data validation in NEP. No issues are expected, but if any arise, I should be raised it to her & she will take support from #Driss.
Due to LS-639 still xml import is not completed.
Hi Jharna Thakur,
As discussed, the issue has been fixed, except for the IP data part, which I will confirm after importing the XML. Currently, a single IP data CSV is being generated, whereas normally two IP data CSV files are expected.
xml shared
it will be delivered by today EOD
WIP and to be delivered by today EOD (without manufacture name)
WL-2 days
Dear @Jharna Thakur,
Please find the below XML validation feedback as described below:
XML File: 2025-09-02-04.57.45_Ooredoo
1- In csv “npsran-bs” why radio antenna id is parsing somewhere and somewhere not? under header element node id? Radio antenna id should be not parsed here.
2- In csv “radio antenna” name is coming blank for around 720 antennas below is snippet for your reference.
And, antenna id is also not correct, for example I am sharing below for node N_MenzelBouzelfa_NAB1027 which is parsing as role2g, in dump antenna is blank so no need to parse it.
and the same node which is with MBTS should be parse here in antenna as antenna data is available in dump.
3- Radio antenna is not parsing for many nodes in which below example is sharing for your reference. (antenna list attached where it is parsing incorrect)
Site id is also not defined against this above radio antenna id.
4- Header manufacturer is missing in nodecabinet.
5- In node boards double header regarding serial is again appearing which was fixed in earlier xml.
6- Under csv “addinfo” ADJ/ASSOCIATION is not making for RNC node RNCSOS53 while logical dump is available.
7- BTS is not defined in XML against cell in csv “npscell”
8- NodeB is not defined in XML in csv “npsthreegcell”
9- eNodeB is not defined in XML under csv “ltecell” & “enodebbandwidths”.
10- In csv “IP Data” duplicate values are parsing, below is an example for your reference.
11- In CSV "nodeboard" please check for sample node "MBTS-RTE_MEDNINIE_BG_MED1132" where 3 PSU board name are available in dump but only 2 are parsing in xml. (Total boards in dump are 70 where 43 are with unique serial 24 are with duplicate serial and 3 PSU are without serial so finally 43+12+3=58 boards should be parse as 12 duplicate will be removed)
Please check email where i have shared all feedback with required snippet.
Thank you
Indrasan
xml shared
Hi Jharna Thakur,
During the initial validation at node level, I found that 110 "GSMBTS" nodes are not parsing in role2g as per the defined rules. However, the duplicate MBTS SRAN nodes are parsing correctly. I have shared the detailed list with you over Teams—please review and confirm.
For the remaining data validation, I am continuing with the XML validation and will confirm once it is complete.
xml shared
XML to be delivered by today EOD
Hi Jharna Thakur,
as discussed please fix the issue as details shared over an email, and I will confirm once full Huawei RAN XML validation will be completed.
xml shared
XML to be shared shortly on 25-8
delayed and to be delivered on 25-8 the first half
WIP and might be delivered by 22-8
WIP and started on 20-8
WL: 3-4 Days
WIP and WL to be added by Jharna
Hi Jharna,
XML validation has been completed & remarks shared over an email.
Please check and fix the same.
xml shared
XML generation in progress ..
As discussed please generate XML for Huawei_RAN based on dump which I have attached here.
XML is ok for eNodeB
some values are hard coded and should be configurable ,,,, the WL is 1 day
xml shared
Driss support is required for one issue (maybe related to common code)
Hi Jharna, as discussed please check the highlighted issue which I shared over an email in details.
File name: Ooredoo Tunisia Sample XML Validation_Huawei __ OT-17 __
xml shared yesterday
XML to be shared on 29-5 with new FRS change
No rule in FRS to parse StartRU and Indrasan has to update the FRS
Indrasan Yadav as discussed kindly add the rule for attribute value StartRU in nodeshelf csv.
During our analysis, it has been observed that the existing Huawei RAN connector does not parse the board type "Fmodule" specifically. Adding parsing logic specifically for the "Fmodule" board type may potentially impact existing functionalities of existing the connector. A similar concern applies to the "StartRu" value within the node shelf structure, where modifications might interfere with the current processing logic.
Wl-1.5 days
Jharna to check and advise about the WL
Validation Remarks (Based on One Sample Dump):
1- The value BoardType="FModule" is currently not being parsed. This issue may be related to the use of a connector for OmanTel. As a reference, we encountered a similar issue with OmanTel previously, but successfully parsed "FModule" in ZAIN-KSA. As confirmed with Bassem Sabbagh, we will ensure "FModule" is parsed correctly for Ooredoo Tunisia.
2- The value BoardType="WD2MUMDUa3" is also not being parsed and should be addressed.
3- The attribute ru="-1" is appearing under the nodeshelf element, which is incorrect, as the value should not be negative.
4- The npssite element contains an excessive amount of information, although only one sample node is utilizing it. This should be streamlined accordingly.
for available dump sample ... the XML has been shared and to be validated
xml shared, Indrasan Yadav kindly let me know the issues if found
Based on comment provided in JIRA OT-3, I created this JIRA OT-17 and assigning to Jharna Thakur for connector creation/update in S-DB.
(All require FRS is attaching here for reference)
Dear @Basant Kumar,
Please deploy this AI patch on Ooredoo test platform and after deployed please generate Huawei_RAN XML & upload the CSV to staging DB.
Release Version: 4.0.0.29
Thank you
Indrasan