Uploaded image for project: 'VOLTHA'
  1. VOLTHA
  2. VOL-2879

OMCI message transfer to OpenOmci Adapter (tested with BBSIM)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Low
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Future
    • Component/s: bbsim
    • Labels:
    • Environment:

      Voltha robot testcase using kubernetes/docker and bbsim.

      Description

      Remark: I choose bbsim component, but I did not make sure that the problem is really in there!

       

      The issue concerns the transfer of OMCI messages from BBSIM via OLT Adapter towards the ONU Adapter.

      Finally, with the versions we currently test with, in the ONU Adapter the OMCI message is received as (BaseFormat) 48 byte message, where the OMCI trailer is completely set to 0.

      This obviously has not been a problem with the existing py ONU Adapter. But when we build on the (CBowling) OMCI lib in our GoAdapter the library refuses to decode these frames. This library requires to have the OMCI trailer length correctly set to 40 (0x28), which in my point of view is legitimate and needs to be accepted. The FCS of the OMCI trailer instead is not required (I did not check if its presence would be accepted - short lookup at fragments seems FCS is expected to be 0, which also make sense as FCS is mostly handled within hardware front-end receiver/transmitter).

       

      In our traces we can see that the OMCI frames are already handled without the OMCI trailer length in the OLT Adapter device handler, we receive them the same way on the ONU adapter.

      E.g. the OLT Adapter log entry looks like this:

      {"level":"debug","ts":"2020-03-31T13:56:47.120Z","caller":"core/device_handler.go:844","msg":"recv-omci-msg","instanceId":"adapter-open-olt-75bf8d5f48-4vtrh","pkg":"core","intfID":0,"onuID":1,"omciTransactionID":2,"omciMsg":"00022f0a0002000000000000000000000000000000000000000000000000000000000000000000000000*0000*00000000"}

      According to standard and the needs of our adapter code the frame as example has to look like this:

      "omciMsg":"00022f0a0002000000000000000000000000000000000000000000000000000000000000000000000000*0028*00000000"

       

      Meanwhile I provided an autocorrection for the frames in our OnuAdapter code, but I would expect, that the issue should be solved on the origin.

        Attachments

        # Subject Branch Project Status CR V

          Activity

            People

            Assignee:
            teone Matteo Scandolo
            Reporter:
            michaelpag Michael Pagenkopf
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes