Optical signal level and other parameters in Test procedure
Previously, I have described how Optical Signal Level is received from ONT - using OMCI GET message type and AniG (ME263) managed entity.
Reading Optical Signal Level from AniG has some disadvantages. All depends on OMCI stack implementation, but from known code AniG values are updated after GET operation, so data received by OLT are "old". More - AniG is quite limited, as we can check only RX signal level with GET message. What about other values? Like temperature or voltage? Or TX signal level?
For that purpose, TEST action message is the most proper, and it is specified by ITU-T standard method.
It is worth mentioning, that via OMCI, several actions can be performed:
- CREATE
- DELETE
- SET
- GET
- ALARM
- REBOOT
- ...
- TEST (action code = 18)
TEST - as mentioned above - is action type requested from OLT to ONT. OLT is expecting to get response to test message followed by TEST report.
AniG - Access Network Interface - GPON - managed entity should have been able to handle Test message.
Let's take a look - what does the AniG TEST procedure look like
Below is an output from Dasan OLT, that supports both AniG regular readouts as well as AniG Test:
From the OMCI perspective:
0x002a Anig Test(0x8001)
0x002a Anig TestRsp(0x8001,Result=0x0)
0x002a Anig TestResult(0x8001)
Well, the built-in parser is not showing all the values, however RAW version (all in HEX) shows more:
00 2a 52 0a 01 07 80 01 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 3a ae ef a2
00 2a 32 0a 01 07 80 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 aa f4 da 1e
00 2a 1b 0a 01 07 80 01 01 00 a6 03 15 a0 05 3f 3b 09 13 86 0c 1b 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 cb 4c 58 d2
Now, from the Dasan OLT output we can observe parameters like:
- Temperature
- VCC
- TX Bias
- TX Power
- RX Power
These values come from the laser driver chip via I2C. Realtek's diagnostics command example below (dump below is done a bit later than OMCI logs, so values may be bit different):
# diag
RTK.0> pon get transceiver temperature
Temperature: 27.105469 C
RTK.0> pon get transceiver voltage
Voltage: 3.321600 V
RTK.0> pon get transceiver bias-current
Bias Current: 10.404000 mA
RTK.0> pon get transceiver tx-power
Tx Power: 2.296064 dBm
RTK.0> pon get transceiver rx-power
Rx Power: -18.927680 dBm
RTK.0>
Temperature - if you ask yourself, why temperature differs so much between different ONT models, it is also quite important to mention, that temperature values come from silicon surface sensor. It is often very high value, and when ONT is calibrated in factory, this temperature is compared with temperature measured on:
- Laser driver outer enclosure
- Metal shield of optical circuits (some models have it)
- PCB near laser driver
- In case of integrated optical module (not so called BOSA on Board) - on enclosure of such module
The difference (average, samples from several units) - may be loaded to specific registry of laser driver chip (LDD) - as correction value. By default, this value is 0 (no correction) - so temperature shown is quite high.
It is up to hardware vendor to decide if to use temperature correction or not. And if yes - how to measure correction value. I don't mind to see pure silicon temperature measurement, as at least it shows how close we are to critical values. For example - such laser driver can be destroyed around 120-125 degrees Celsius.
In general, Temperature value can be used to predict if ONT is located in preheated or conductive to overheating locations - to inform subscriber to move ONT or just to remove ventilation obstacles before it fails.
Let's go back to our OMCI dump
00 2a 1b 0a 01 07 80 01 01 00 a6 03 15 a0 05 3f 3b 09 13 86 0c 1b 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 cb 4c 58 d2
Let's split message hex into parameters.
Tail - removing all zeros.
Parameters use 16-bit values, and there is value code byte before:
- 00 2a 1b 0a 01 07 80 01 - 07 is ANI test type - Self Test
- 00 2a 1b 0a 01 07 80 01 - 80 01 is AniG interface EntityID
- 01 00 a6 - 01 - Voltage
- 03 15 a0 - 03 - RX Optical Power
- 05 3f 3b - 05 - TX Optical Power
- 09 13 86 - 09 - Laser Bias Current
- 0c 1b 1b - 0c (12) - Temperature
If in OMCI message:
Voltage = 0x00a6 = 166 decimal, and voltage resolution is 20mV, it means that 166 x 0.02 = 3.32V
Laser Bias Current = 0x1386 = 4998 decimal, and current resolution is 2uA, it means that 4998 x 0.002 = 9.996mA
Temperature = 0x1b1b = 6939 decimal, and temperature resolution is 1/256, it means that 6939 / 256 = 27.105 degrees Celsius
So, these values are the same as on output from OLT.
This is how it works.
Is it possible to customize Ani Self Test a bit?
Yes, and some OLT vendors do it for different purposes - quite often to broke interoperability (greetings to Huawei)..
Can this object be used to get CATV 1550nm Optical Signal level? Yes, and I will try to describe CATV Optical signal level operations in one of the next blog entries, so stay tuned!
Other topics to be discussed in other chapters - does AniG has to use EntityID 0x8001?
- Nokia doesn't use AniG regular GET to receive RX Optical Signal Level from ONT. It uses only TEST message;
- Dasan OLT periodically GETs AniG values, but you can request it to make a TEST;
- Huawei uses TEST;
- Calix - uses AniG regular GET, however, it might be possible to trigger TEST operation;
- Ericsson BLM1500 (old, almost unused today) - it uses neither AniG GET nor TEST - it does own, private Managed Entity (ME250).
Interesting additional facts:
Method used by OLT and - implementation of it in ONT OMCI stack is a part of interoperability state between OLT and ONT.
And this is what we fix!
If you are looking for FTTx/xPON experts community to join, check out our - LinkedIn group, founded to exchange knowledge and connect people in ICT industry.
Author: Marcin Kuczera
Follow us on LinkedIn to stay up to date with our latest posts!
.png)