Why we cannot query OSNR from NMS by OPM8 board?

This post is about the issue that Impossible to query OSNR from NMS by Huawei OPM8 board. Do have a look below for more information on the topic.

 

Issue Description

Networking Topology:

 

 

Fault Symptom:

Failed to query OSNR by OPM8 board on site B.

 

Handling Process

1. In 100G system, the OSNR is calculated by EMCA module in the system control board. Even though, query the OSNR by OPM8 board, but it's not calculated by OPM8 direclty.

2. The EMCA module in the system control board performs modeling for each board and fiber type in an OMS trail. During calculation, the EMCA module obtains the input and output multiplexed-wavelength optical power of each OA on the OMS trail, and the single-wavelength signal and noise power scanned by the OPM8 board to calculate the single-wavelength OSNR.

3. So the OSNR calculation depends on the OMS OD route configuration. 

4. Check the "OD Route Configuration" of the OMS between site A and site B, the status is "Partially Created". Try to create once again by clicking "New", it reported "Not Supported Board Type (Error code: 38664)".

 

5. Check all the boards on the OMS trail, in Site B, there are 15OAU, 52WSMD9, 55OPM8. Those boards can't be supported by Site A(OptiX OSN8800 UPS V100R012C10SPC300).

6. The Site B is new implemented, some new boards are not supported by Site A. So can't create the "OD Route Configuration". Finally, failed to calculate the OSNR.

Root Cause

The Site B is new implemented, some new boards are not supported by Site A. So can't create the "OD Route Configuration". Finally, failed to calculate the OSNR.

 

Solution

1. Upgrade Site A to R13C10SPC700 or later version, so Site A can support 15OAU, 52WSMD9, 55OPM8.

2. Create the 15OAU, 52WSMD9, 55OPM8 as logic board with the lower version, so Site A can support.

 

Suggestions

1. The OSNR of 100G system is calculated by EMCA module in the system control board, it depend on the OMS and "OD Route Configuration".

2. In the implementation phase, should consider the board can be supported, not only the current device, also should be supported by the peer device of OMS. 

How to convert between common E1 services and E1 SNCP services?

This post will share how to convert between common E1 services and E1 SNCP services. 

Scenario Description

The network topology consists of four OptiX OSN 3500 and one virtual NE.

 

 

Carries two common E1 services.

 

 

Video

This video will show how to convert between common E1 services and E1 SNCP services， and how to implement conversion on virtual NEs after topology changes.

 

 

Text description

 

Converting common E1 services to E1 SNCP services

1. Confirm the existing E1 services.

2. Configure dual-fed and selective receiving on NE1.

A. Expanding bidirectional services into unidirectional services

B. Convert the unidirectional service whose signal source is a line board and whose signal sink is a tributary board to an SNCP service. The two services need to be configured separately.

C. Create the unidirectional service in the reverse direction by referring to the generated protection service. The two services can be configured at the same time.

3. Configure two bidirectional pass-throughs on NE3.

4. Configure the dual-fed and selective receiving service on NE4.

A. Expand bidirectional services as unidirectional services.

B. For the services forwarded to the virtual NE, convert the unidirectional services whose signal source is a dual-fed line board and whose signal sink is a selective-receiving line board into SNCP services. For the services dropped locally, select the unidirectional service whose signal source is a line board and the signal sink is a tributary board to convert the services to SNCP services.

C. Configure unidirectional services in the reverse direction according to the generated protection services.

5. Search for new SDH trails. 

Searching for new SDH trails = Refreshing SDH trails

Results:

 

 

Please note:

1. On NE1 and NE4, the signal source is dual-transmit end and the signal sink is selective receive end, and the unidirectional service is converted into SNCP services. If the selection is incorrect, the conversion fails.

2. During the configuration, the timeslots occupied by the E1 services in each place must be correct. Otherwise, E1 SNCP trails cannot be searched out in the last step.

 

Converting E1 SNCP services to common E1 services

1. Operations on NE1

A. Expand a bidirectional path into a unidirectional path.

B. Restore the SNCP service to an unprotected service. When you select a unidirectional working service, the protection service is automatically selected.

Another simpler method is to select the protection service between, right-click, and choose Convert to Non-Protection Service from the shortcut menu. This does not require step A.

 

 

C. Delete unnecessary unidirectional services.

 

2. Delete the pass-through service from NE3.

 

3. On NE4, convert the SNCP service to the non-protection service. The operation method is the same as that of step 1.

 

4. Search for SDH trails again.

 

Service conversion on virtual NE

After NE6 is added to the topology, the virtual NE service can be used as the node of the SNCP service. Therefore, the first E1 service can be converted again. When two SNCP nodes are at both ends of an E1 path, the protection capability is the best.

1. Configure services on NE1, NE3, and NE6.

The configuration method is the same as above.

 

2. Configure SNCP services for virtual NEs.

Common E1 services cannot be converted to SNCP E1 services on virtual NEs.

Solution:

A. In the NE Explorer of the virtual NE, delete the original E1 service,

B. Create an SNCP service. The working timeslot must be the same as the deleted timeslot.

After the configuration is complete, the unidirectional service in the reverse direction is automatically created. It no needs to manually create the service again.

 

3. Search for SDH trails again.

Results:

 

 

Please note:

1. When converting an E1 SNCP service to a common E1 service, it needs to delete the entire E1 SNCP service on the virtual NE and then create the common E1 service.

2. Creating, deleting, or modifying services on virtual NEs does not affect services.

E224 not Working with BD_fILE_NOT_Active Alarm

 Description

A new 1G ethernet port in TNV3E224 installed in OSN 9800 U32E didn’t work after being configured and show no traffic in the transmit or receive direction.

 

Procedures of Check 

The first thing is checking the optical power and after checking, I found that the optical power is in the optimal range.

  

After that I wanted to confirm whether the port has configured services or not, so there should be a traffic in it, and it was already configured with several PWs in a correct way.

Then I come to check alarms and found that there is a Major Alarm in the board named (BD_fILE_NOT_Active ).

 

From the alarm details, the parameters of the alarm are 0x03 0x00 0x03 

The Solution

referring to the NCE help with the alarm parameters, the causes are a file missed.

The details of this file are as follow:-

• 0x01: board software (BDSOFT).
• 0x03: control logic (FPGA).
• 0x04: CPLD.
• 0x05: configuration file (ne.ini).
• 0x07: service logic 1 (FPGA).
• 0x08: service logic 2 (FPGA).
• 0x09: service logic 3 (FPGA).

As the parameter was 0X03 so the FPGA is the missed file, the possible cause is that, The logic or CPLD in the file system where the board is located is updated during package loading. The CPLD or FPGA file of the board can be activated only after the board undergoes a cold reset or power failure. This alarm is reported when the CPLD or FPGA file of the board is not activated.

 

As explained the board needs a cold reset or unplug then plug it, to activate the FPGA file after a software update, and after I made a cold reset for it, the alarm cleared and the board worked normally.

 

Note:-Usually boards bought long time before deployment need a upgrade for the soft, and if not follow all the procedures of the upgrade a total or partial failure happens to the board.

 

Introduction to xPON Type C Protection

Introduction to xPON Type C Protection

Type C provides redundancy for OLT (dual homing), ONU's PON ports, backbone fibers, optical splitters, and distribution optical fibers. When a fault occurs, services can be automatically switched to the functional link. After the fault is rectified, services are automatically switched back to the original link.

xPON type C protection can be deployed in two networking scenarios: single homing and dual homing.

Figure 1 shows the xPON type C protection single homing network.

Figure 1 xPON type C protection network (single homing)

Networking Mode	Advantage	Disadvantage	Scenario
Single homing	The networking mode is simple, and OLT and ONU can be managed easily.	When the OLT becomes faulty, services are interrupted. Optical fibers are deployed on the same channel and therefore two optical fibers may be broken at the same time.	This mode is used to protect important services, such as Enterprise private line services and base station services.

Figure 2 shows the xPON type C protection dual homing network.

Figure 2 xPON type C protection network (dual homing)

 

Networking Mode	Advantage	Disadvantage	Scenario
Dual homing	When the active OLT or its uplink fails, services can be switched to the standby OLT.	The networking mode is complicated and costly, and the ONU management is difficult.	This mode is used to protect a power system or Enterprise private line services and base station services.

 

On a single homing network, one ONU such as Huawei MA5626 is connected to two PON ports on an OLT, one working as the active port and the other as standby. The two ports on the OLT cannot forward packets at the same time. An automatic switching can be triggered by any of the following conditions:

• Loss of signal (LOS) occurs in the input direction.
• The ONU is offline.
• The OLT or ONU hardware is faulty.

 

On a dual homing network, two PON lines, one working as the active line and one as standby, between an ONU and two OLTs cannot forward packets at the same time. An automatic switchover can be triggered by any of the following conditions:

• Loss of signal (LOS) occurs in the input direction.
• The ONU is offline.
• The OLT or ONU hardware is faulty.
• The OLT's uplink is faulty (this condition triggers automatic switching only in the associated protection switching scenario).

 

If you want to know more information about xPON type C protection, you can contact Thunder-link.com.