Unusual cases of AniG

Unusual cases of AniG

For most of the ONTs, there is just one ANI-G (ME263) object.
Its EntityID is 0x8001.
Now, let's split 0x8001 into 2 bytes:
  • 0x80 - this is so-called slot number. For ANI part - it is commonly used value of 0x80 = 128
  • 0x01 - this is the interface number within a slot.. but is it really the first possible option?

Interesting case number 1 - NOKIA

Once upon a time, while migrating from Ericsson BLM1500 to Nokia ISAM7360 we were trying if it is possible to make interoperability of T063G (Ericsson) ONT with Nokia OLT... this ONT was detected by OLT, but there was no way to get anything more...
The most difficult on an unknown (from a development point of view) device is to get to the console and enable some dumps, later on - to understand the output.
In general, when ONT is connected to OLT and added to OLT config (let's say, authentication by GPON SN is specified) - OLT starts querying ONT about all it needs.
Usually, it also asks about ANI-G.
It looks like:
OLT->ONT: "ok, tell me more about ME263 now".
ONT->OLT: "I have ANI-G on EntityID 0x8001"
OLT->ONT: "GET ME263 EntityID 0x8001"
Now, OLT knows that ONT has ANI-G on EntityID 0x8001, and this is how it commonly proceeds...
Commonly... but, I have noticed, that Nokia OLT is doing a direct GET:
OLT->ONT "GET ME263 EntityID 0x8001" - without previous rendez-vous...
And - the problem is, that T063G ONT ANI-G EntityID is.... 0x8000!
So, the response (ONT->OLT) is - I don't have ME263 EntityID 0x8001.
Below example of a log from T063G ONT:
[0000663055] omcirecv: 'Get attribute AR' ANIG-8001 (len 48) tid 9 data c0 00
[0000663055] upget: parameter error ANIG-8001
[0000663055] omcirecv: reply 'Get attribute AK' ANIG-8001
As a result, Nokia understands that this device has no ANI-G and - GAME OVER, all mib sync is stopped and ONT is not authenticated.
T063G ONT is very old, based on Broadlight chipset, without access to source code there is no way to fix it.
And as you can imagine, we don't have access to Nokia's source code too…
That was an unsuccessful interoperability try…

Interesting case number 2 - UBIQUITI

Have you ever been considering Ubiquiti Fiber OLT? Please, just forget about it as soon as possible... that is wrong, wrong way, no matter how nice it looks and how sweet is the smile of the Ubiquiti rep…
However, we have some experience in that field...
Ok, it started with questions from some ISPs, if our devices can work with Ubiquiti OLT.
The first versions of Ubiquiti OLTs were quite open for 3rd party ONTs. Some functions were not working, but the transmission was ok. After one of the upgrades, it ended up.
Status for now - if you don't modify vendor ID to UBNT, ONT will not even be listed on detected ONT's list…(dropped on PLOAM level)
So - OLT upgraded to the latest firmware, ONT with modified VendorID to UBNT - aaaand we can see each other. We are not authenticated, as this is another issue to be solved, but let's focus on the Optical Signal Level readout…
Looks like, UBNT OLT asks for AniG ME263, but... the EntityID is 0x0000. I could understand 0x8000, but 0x0000 means that the slot number is 0x00. The slot number is just a number, but OMCI stacks are quite complicated, that change of AniG from 0x80 to 0x00 as a slot, has a lot of implications like problems with alarms and interoperability with other OLTs…
This is how it looks before modification:
0x005f Anig Get(0x0000,OpticalSignalLevel,TranOpticLevel)
0x005f Anig GetRsp(0x0000,Result=0x0)
0x0062 Anig Test(0x0000)
0x0062 Anig TestRsp(0x0000,Result=0x0)
Btw, we respond ok (Result=0x0) as such parameter simplifies interoperability processes, but – the response object is empty...
And this is how we look from the OLT perspective:
After breaking the code... our ONT finally reported AniG at 0x0000 "properly" to what UBNT OLT expects, and - OpticalSignalLevel readout is ok.
Now, from OLT perspective:
The other issue (last column on the right) - related to authentication required a lot of engineering, and we could say - we are the only vendor with 3PP interoperability with UBNT OLT - but we strongly recommend using it for migration scenarios to other OLTs than UBNT...


To summarize - most of modern OMCI implementations of AniG use 0x8001 as EntityID, but some older and some others may not.
Well designed OLT OMCI stack should be able to work with other EntityIDs of AniG. However, for wide interoperability, we recommend to stick with 0x8001 on ONT side.
Follow us on LinkedIn to stay up to date with our latest posts!