Brandon, Alexandre (Nokia - FR/Nozay) From: Sent: To: Subject: Brandon, Alexandre (Nokia - FR/Nozay) mardi 20 juin 2017 15:18 Chabbouh, Slim (Nokia - FR/Nozay); Moisy, Patrick (Nokia - FR/Nozay); Mihon, Gabriel-Ioan (Nokia - FR/Nozay); Favier, Christian (Nokia - FR/Nozay); Dey, Magalie (Nokia - FR/Nozay); Pugniere, Eric (Nokia - FR/Nozay); Thebeaud, Isabelle (Nokia - FR/Nozay); Lavignas, Pascal (Nokia - FR/Nozay); Morette, Michael (Nokia - FR/Nozay); Guigui, Daniel (Nokia - FR/Nozay) MoM W25: Weekly AirPhone System Engineering Synchro Meeting Dear All, Please find below the minutes from the weekly Airphone SE Synchro meeting from W25: Attendees : To list Agenda for the regular meeting: - Terminology: o AirPhone-RAC and AirPhone-RAU to be used. AirPhone Product architecture open items o System components: What system components or sub-components should we address in 425 feature for the User Plane? (Point to close) • They should address the system components as defined today (which are target architecture for AirPhone). • System components will be aligned by archi team to agreements by Jussi & Subra • Specs of 425 will use those system components to define interfaces between system components • At implementation stage, AirPhone team will combine some of those interfaces in order to align to the actual SW architecture that will be implemented by the time 425 feature is implemented and delivered at early stages of integration (and while we wait for the full alignment of AirPhone SW to provided system components). Same question for the Control Plane • Issue : C-Plane architecture on C-Plane is high level view, deeper view required to study new C-plane architecture on Airphone context. Several options: o CP-CEN from 5G17A could be valid approach for Airphone 5G18A if C&P fit with L2RT on Airframe Real Time module o If C&P issue, then CP-CEN split into CP-CELL, CP-IF, & CP-NB could help to increase C&P • Not possible to go into deeper details than the system components agreed with Subramanya (a fact today). • Subramanya to confirm 2 people allocation to follow CPlane technical architecture for Airphone (AI: Slim to contact Subramanya) • This is blocking specification for AirPhone. o HW strategy for AirPhone – see attached slides o Deployment and dimensioning Next time define dimensioning and proposed core mapping for 5G18A replicating gNB core mapping and also we need to finalize that L1EMU has to go to a “cheap” board (ideally ABIK). • 18A Architecture config D – assumption is we use 2 x 12 cores AirFrame – we need to do handover: [Numéro de page] Traffic Generator = Needs to be added to the system components, needs to be dimensioned. Likely 1 could be enough (say for 5 gbps). o UEC = 1 Core / Cardinality = (1 UEC for N x L3 / 1 L3 per L2 NRT). Small. o L3 = Today in AirPhone (1 L3 = 1 Core). 1 L3 = 20 Calls. On gNB side one UE VM spans 2 cores + trsw 1000 UEs per UE VM. Very likely for nb UE < 500 Only one core for CPlane. o L2-HI = In gNB : 5 cores / not really dimensioned per UE / rather dimensioned per total User Plane throughput 6 Gbps (PDCP + RLC” = L2HI). 5 Cores on AirPhone minimum to achieve 4.9 Gbps. o L2-LO = 4 cores / cardinality = 64 connected UE / 8 Grants per TTI (dimensioning with L2-LO on AirFrame). o L2-SM: 1 core for SM / cardinality = 4 subcell groups + 1 for synchro. o TRSW = If we go to a 2 AirFrame, for 5 L2-HI cores we need an additional 2 cores for TRSW (one of them for IPSEC) to communicate between the 2 AirFrames. Otherwise no cores need to be reserved. Two cores short to fit one socket to achieve 64 Connected, 8 Grants per TTI, 4 Subcell groups, 5 Gbps aggregated throughput o This deployment will depend on the configuration chosen, Patrick, Gabriel and Daniel (please include Eric/Isabelle to those discussions) to agree on one config, freeze it and the we go back discussing core mapping. o Based on 3GPP mapping, not on 5GTF. We assume a 1 AirFrame configuration. We need to do this exercise also with L1EMU o Include L1EMU to existing AirFrame for this dimensioning Capacity will be lower with L1EMU. New proposal from Gabriel shared today: o Everything could be deployed on 1 compute node, 2 configurations proposed: First configuration based on 1 processor hosting L2-LO, L2-HI, SM and SM tmr, 1 processor hosting L1 emul instances (2) + TG (Traffic Generator) + CP + OAM + UEC • 7.2Gbps by subcellGroup • L1 Emulator reduces L2 capacity (24 subcells max that could be allocated as we want, 3 subcellgroups max could be addressed) Second configuration doesn’t include L1 Emul instances on the RT module. • 1 processor hosting L2RT + L2NRT instances (2/3), 1 processor hosting L2RT + L2NRT instances (1/3) • Configuration for real L1, will provide higher capacity o AI : Proposal to review by Airphone team (Daniel/Pascal), offline meeting to handle if necessary (before CV meeting this Friday). By default current proposal is the view to present to CV. o • • • • CPU measurements • Measurements from current Airphone code are required to tune 5G18A Airphone C&P capabilities (AI: Daniel) • Some measurements have been done, however not relevant because not based on RCP environment. • If measurements cannot be done right now on Airphone side, then we have to do it directly on 5GNB side. [Numéro de page] o Feature set to be supported by all AirPhone Full 5G18A release features need to be supported on AirPhone Missing dependency diagram for implementing features on AirPhone • Should be exactly the same as gNB • No sense to work on this until CFAM for 5GC000425 is good enough. • Isabelle and Eric to make a pre-analysis of 5G18A features to try to identify the biggest “AirPhone” impacting features. Identify features with a tag (small / medium / large) in terms of spec effort. • Started based on FP review Re-Architecture of AirPhone How to move from Current to final architecture • First subject being worked by FT is Scheduler Manager in 5G17A. 5G-SM has interfaces in 5G17A that are a little bit different from what is currently being defined in 5G18A. Patrick to review with Daniel the differences. • Weekly working session with AirPhone archis on SM Daniel to set the meeting (pure technical weekly meeting every Wednesday started). Where does the UEC component description go? Which DOORS module? • UEC handles the T-Plane, specified today in Manilla, spec of this component found below: https://sharenetims.int.net.nokia.com/livelink/livelink?func=ll&objId=553372673&objAction=browse&viewType =1 UEC requirements should be linked to the requirements of L2-SM and all other system components of AirPhone that is done via 5GC000425 this will set the starting point for spec where UEC and other System components are aligned o Configuration of AirPhone is done through static settings and also dynamic settings coming from test scripts, question is whether both of these are managed by UEC “system component”. In all cases this needs to be aligned to CFAM. o There needs to be a specific workgroup to align UEC requirements to 5GC000425 feature content. Understand how the current UEC specs are written Understand if that is aligned to CFAM Understand how to align both specs (I am suspecting some level of disconnect). When UEC and AirPhone CFAM are aligned, every feature CFAM (with help from SME) define UEC requirements as part of feature work. L3/L2 NRT interface gNB implementation and reuse on AirPhone AirPhone testability o Emulation of beam tracking in AirPhone (Patrick lead this topic, Patrick has to check with Christian CQI reporting issue) o Discussion opened including L3/L2 & L1 Feature discussions: o 5GC00425: feature definition starts from gNB system components. Adherence to current SW to be defined. o NSA Features: Big impact on AirPhone Discussions on-going with DCM. DCM would like to test with UE emulator. • 5GNB emulator • Real 5GNB in the testing configuration • Whatever the configuration, we need to emulate 4G & 5G UE for DC. o - - [Numéro de page] o - - eLLF: Dependency on Airphone & 5GNB, including DCM dependency eLLF introduction plan not currently consolidated eLLF integration to define (strong feedback from L1 expected to build consistency plan). ELLF plan has also to consider OTA scenario (Impact on L1 and Airphone RU configuration) Counters/Traces on AirPhone: o How do we reuse the framework from gNB? o C++ class exists for PM counters. Every 1 sec, the counters are logged. o Risk of interaction between R&D counters and PM counters. OAM doesn’t exist for PM management on Airphone. PM manager from 5GNB could be reused. o Proposal will be provided by Pascal, to review with SE o Open Point : who is responsible to provide the counters. “Cloudification” of AirPhone (Low priority topic on 5G18A) o Split definition between Cloud and DU to agree, from this definition Airphone team could provide more detailed plan Open Items: - OTA story, need to get started on this Which SE will be allocated to this feature 5GC000633 (AI: Slim ??) ? - - What is the supported interface between AirPhone RAU to AirPhone RU? (eLLF split) o Do we do it in time domain or frequency domain? How do we do channel emulation? (beam tracking topic) o Do we use radio? Test plane of the AirPhone (scenario and ITF to handle the UE on Airphone) o How do we deal with it? T-Plane has no sens on 5GNB side, how to drive this domain on DOORS ? Blind decoding approach for AirPhone (linked on the 425 feature TBC). Action Items: - Mike : send documents on L1EMU current architecture. Slim : check with Subbra whether a CP-CEN would make sense for AirPhone? Isabelle/Eric : draw a slide with dimensioning as seen today (long term action) Slim: Check no dependency on 5G17A (meaning that we do not assume that some features are implemented in 5G17A to build 5G18A release). Daniel: UEC requirements alignment with CFAM requirements for 5GC000425. Who is who : - Isabelle: AirPhone SE – Product architecture for AirPhone Eric : AirPhone SE – Product Architecture for AirPhone Gabriel: SE 5GC000425 Pascal: SME Re-architecture. Slim: Acting Chief Engineer for AirPhone Patrick: SE 5GC000632 Mike/Daniel: SME architecture UPlane Alexandre: SE Product Architecture Magalie: Line Manager for AirPhone Scrum team. AirPhone archi coordinator. Christian: Testability AirPhone (starting with Beam tracking). Misc: [Numéro de page] - 1 people from OAM and CPlane? Best regards. Alexandre [Numéro de page]
