Hi Mattia, Yes, I think there is a plan to push the training (at least the presentation parts) up to the site https://gitlab.eurecom.fr/oai/trainings The Teams meeting was recorded, but there might be some post processing required. There is a lot of other good information in the other sessions, but I think the one last week was the first focused on the O-RAN 7.2 fronthaul. Cheers, Lincoln On Mon, Jun 3, 2024 at 2:36 AM Mattia Milani wrote: > Hi Lincoln, > > Thank you very much for the feedback, I'll look into the documentation you > provided. > In the meanwhile may I ask if there is a publicly available recording of > the training session you mentioned? (or similar training sessions done in > the past). > > Thank you, > Mattia > On 31/05/2024 14:40, Lincoln Lavoie wrote: > > > You don't often get email from lylavoie@iol.unh.edu. Learn why this is > important > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > Hi Mattia, > > The code is being used, and there are some patches in flight, but are > currently coming from Open Air Interface folks. There's a lot of > documentation here: > https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/doc/ORAN_FHI7.2_Tutorial.md?ref_type=heads > > We are actually running this in the lab and even hosted a training session > on the O-RAN aspects of the setup yesterday with Northeastern and the OAI / > VIAVI teams. Point is, it's not really completely dead, just not a lot of > movement in that one repo. > > On the hardware, it has been run on both Nvidia and Intel NICs, but there > are some requirements on things like PTP time stamping, but that comes with > the O-RAN fronthaul requirements. > > For the VLAN header, that is handled with the VFs are creates and "handed" > to the xran processes that get embedded into the DU (at least in the OAI > implementation). > > Cheers, > Lincoln > > > On Wed, May 29, 2024 at 4:04 AM Mattia Milani > wrote: > >> Dear Lincoln, >> >> Thank you very much for providing this reference. >> >> I've to admit that I didn't know about this library but I'm looking into >> it >> but I have some questions/concerns. >> >> This library seems to be abandoned since 2 years, at least this is what I >> see from both the documentation and also their version control system: >> https://gerrit.o-ran-sc.org/r/gitweb?p=o-du%2Fphy.git;a=summary >> Do you think it's still reliable? >> >> The assumptions seems to be quite restrictive on the HW requirements of >> this library listed here: >> https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/Assumptions_Dependencies.html#requirements >> With my experiments I'm just exploring using virtual interfaces and my HW, >> I would like to avoid those constraints. >> >> From what I can see some of the data structures already provided by DPDK >> are re-defined by this library, like the eth header data structure and >> the eCPRI header. >> I don't know if this is due to implementation reasons or because it has >> been >> built with an old version of DPDK. >> But without taking in consideration the endianess like rte_ecpri.h >> already does in DPDK >> and without supporting some msg types (line 94 file xran_pkt.h). >> >> Digging into the source code a bit I found some of the data structures >> I'm referring to >> in my original message, i.e. the ecpri Seq. ID. The following code >> puzzles me, source file at: >> >> https://gerrit.o-ran-sc.org/r/gitweb?p=o-du/phy.git;a=blob;f=fhi_lib/lib/api/xran_pkt.h;h=314b8d6b7d08f153369de5ad535702f50a574a35;hb=HEAD >> line 228: >> struct xran_ecpri_hdr >> { >> union xran_ecpri_cmn_hdr cmnhdr; >> rte_be16_t ecpri_xtc_id; /**< 3.1.3.1.6 real time control >> data / IQ data transfer message series identifier */ >> union ecpri_seq_id ecpri_seq_id; /**< 3.1.3.1.7 message identifier >> */ >> } __rte_packed; >> >> Seems strange to me that ecpri_xtc_id is not a data structure on it's >> own, providing access to DU port, Band Sector etc. >> Also, the 'xran_pkt_comm_hdr' data structure at line 336 assumes that the >> packet doesn't have a VLAN header, but, >> I don't know if this is managed elsewhere. >> >> Given all that, I'm still of the idea that could be useful to have those >> kind of headers directly in DPDK >> but I'm open to reconsider my statement, please let me know if you have >> more information regarding >> this library. >> >> Best regards, >> Mattia >> >> >> On 28/05/2024 16:37, Lincoln Lavoie wrote: >> >> >> You don't often get email from lylavoie@iol.unh.edu. Learn why this is >> important >> >> >> CAUTION: This is an external email. Please be very careful when clicking >> links or opening attachments. See the URL nok.it/ext for additional >> information. >> >> >> Hi Mattia, >> >> Have you looked into the O-RAN OSC open fronthaul phy implementation? >> >> https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/Architecture-Overview_fh.html >> >> Cheers, >> Lincoln >> >> On Tue, May 28, 2024 at 10:31 AM Mattia Milani >> wrote: >> >>> Dear DPDK Dev community, >>> >>> I hope this is the correct mailing list for my questions, otherwise >>> please excuse me and let me know where my questions should be posted. >>> >>> I was looking for a data structure capable to manage O-RAN Fronthaul >>> CUS-U headers (attached a screenshot of the header structure form a >>> packet analyzed with Wireshark) >>> but I couldn't find one. >>> >>> I would like to be capable to identify the different port ids but also >>> the number of PRBs in the section part. >>> >>> I wrote my own implementation for a simple use case (I don't take in >>> consideration different versions and or data directions) >>> but it's enough for me at the moment. >>> >>> What I wanted to ask is the following: >>> - Does a data structure for this kind of header already exists? >>> - If it doesn't exists is it planned? >>> - If it's not planned could it be of some interest? >>> >>> If there is interest I would be happy to share what I developed up to >>> now to receive comments and/or assistance on how to make it fully >>> functioning. >>> >>> Best regards, >>> Mattia >>> >> >> >> -- >> *Lincoln Lavoie* >> Principal Engineer, Broadband Technologies >> 21 Madbury Rd., Ste. 100, Durham, NH 03824 >> lylavoie@iol.unh.edu >> https://www.iol.unh.edu >> +1-603-674-2755 (m) >> >> >> > > -- > *Lincoln Lavoie* > Principal Engineer, Broadband Technologies > 21 Madbury Rd., Ste. 100, Durham, NH 03824 > lylavoie@iol.unh.edu > https://www.iol.unh.edu > +1-603-674-2755 (m) > > > -- *Lincoln Lavoie* Principal Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m)