Guiding Principles and Challenges for ML in 5G and Future Networks

1. Guiding Principles and Challenges for ML in 5G and Future Networks Vishnu Ram OV Independent Research Consultant, Bangalore, India

2. Thank you for invitation! Introduction • Worked for Motorola/Nokia/Siemens in research teams for 21 years • IETF/3GPP/ITU experience • holds 12 International Granted Patents (and several pending applications) • have several publications and IETF drafts • currently working as an Independent Researcher (closely with ITU FG ML5G).

3. Aim: To make new colleagues in China! Scope/Agenda • perspective of various groups regarding ML in 5G • trends in ML for future networks • principles for architecture for ML • Open issues and opportunities for China colleagues • References Email: vishnu.n@ieee.org WeChat ID: Vishnu-Ram-OV

4. Perspective of various groups regarding ML in 5G 3GPP: • AI and Automation is big deal for operator network • Verticals are important! May own wireless networks • Automotive, IoT/Factory automation, mission critical • Flexible and modular RAN architecture • New Access Technologies: e.g. Fixed Networks, Satellite • CN = Service, Open, Flexible, “Enabler” • Native end-to-end support for Network Slicing • Multiple stakeholders in a network • On demand resources + orchestration. • Exposure APIs are important (even in User Plane) • Harmonized Protocols & Access Agnostic – generic solutions

5. Perspective of various groups regarding ML in 5G ETSI:

6. Perspective of various groups regarding ML in 5G ONAP:

7. Perspective of various groups regarding ML in 5G IETF: SUPA WG: The SUPA (Simplified Use of Policy Abstractions) working group defines • a data model, • to be used to represent high-level, possibly network-wide policies, • which can be input to a network management function (within a controller, an orchestrator, or a network element). TM FORUM • open api is defined from TMF to SO for creation of services. • ONAP is discussing these interfaces.

8. Perspective of various groups regarding ML in 5G Acumos • Integration to ONAP was on the cards. • Some e.g models hosted: face detection, Real-estate value prediction, breast cancer prediction.

9. Trends in ML for future networks Open, Interoperable, adaptive frameworks adaptive frameworks Performance Performance fixed frameworks Closed, proprietary, static frameworks Granularity of Data in the network Level of meta data in the network

10. Trends in ML for future networks SO level collaborative interface Inter-domain e.g. resource orchestration Percolation of Intelligence Resource level Data-Boundaries Platform Level SO level Intra-domain, APIs, Interfaces. Standards Coordination (ITU, 3GPP, MEF, ETSI..) Level of Intelligence in the network

11. FG ML5G principles for architecture for ML (towards such future networks) Rule #1: declarative, percolative approach: intent, ML-ML • Network operators should be able to rapidly add ML services. • 3rd party providers or vendors should be able to rapidly provision ML services. • Interoperability of ML mechanisms is a must, • NOP should not worry about underlying network (e.g. 3GPP or WLAN) Use case (Service) Provisioning ML Overlay Standard interface Network Underlay

12. FG ML5G principles for architecture for ML (towards such future networks) Rule #2: technology agnostic overlay: ML Pipeline nodes • ML mechanisms must evolve independant of underlying networks. • ML must plug-in using a standard framework • ML mechanism should be solving the problem, selection of ML mechanism should use the description of the use case to select the best possible model. Model selection ML Overlay v3 Data handling Network Underlay R17

13. FG ML5G principles for architecture for ML (towards such future networks) Inter domain interface Rule #3: disaggregation and distribution: “Interface 8” • Need: Inter-domain, Inter-vendor, Inter-technology, standard interface (by ITU) • between ML mechanisms hosted in different domains (e.g. Edge, Core, RAN, WiFi AP) ML Overlay ML Overlay Data handling Data handling Network Underlay R17 Network Underlay WiFi

14. FG ML5G principles for architecture for ML (towards such future networks) Rule #4: Invisible ML, with automation, adaptation, monitoring: MLFO • Related to Rule #1, Middle man needed between Platform, Infra, Software, and ML. • By providing a simulator+trial-sandbox. • Agnostic but "opportunistically-aware": e.g. Resource status, scaling decisions, accelerator availability. • effect of ML on the network has to be monitored for impacts on E2E service. ML Overlay MLFO Network Resources

15. FG ML5G principles for architecture for ML (towards such future networks) Rule #5: building blocks + standard chaining mechanisms: Chaining • Collection + Preprocessing + classification + Prediction mechanism => Today's chain. • Collection (in multiple Edges) + PP (in Central DC) + Model training + compression (in Sandbox) + Model deployment + decompress (in multiple Edges) + discovery => future chain. Model ML Overlay ML Overlay Data handling Data handling Network Underlay R17 Network Underlay WiFi Collector Collector

16. FG ML5G principles for architecture for ML (towards such future networks) Rule #6: capability discovery/evaluation/evolution/mutation: intelligence levels • Intelligence is provisioned in NF. Separate from its functionality but with clear interfaces (need for standard). • It can be queried, updated and managed at each level. Separate from its functionality, but related. • The NF may evolve and expose unstructured/new data. Model ML Overlay MLFO Data handling NF-1 NF-2 src sink Management Service

17. FG ML5G architecture for ML

18. Paradoxes? • Secure (but with data/control exposure for ML) • Platform-aware (but agnostic ML) • Zero Touch, auto-training, etc (but with monitoring and controls) • Uniform ML operations (but delegated cross-domain) • Audit trail (but no compromise in performance and its invisible) • Underlay evolves, overlay evolves (but end-user experience is smooth)

19. Future Work Data handling and model mechanisms for ML • what are the datasets needed for each use case? • Are there operator-hosted datasets? (e.g. using probes in the network). • What kind of models can be / should be matched with such datasets? • what kind of simulation can generate (if at all) such data? • Does the data need pre-processing? Open source integration for ML Pipeline architecture (e.g. Acumos) • Influence open source community in the border between 5G and ML • Propose ML pipeline architecture via feature proposals or architecture reviews. • Guide the community and create mindshare for interoperable mechanisms. • Investigate the touch points for open frameworks like ONAP+Acumos+Akraino to FG architecture. • Use it for data handling, training, model LCM, deployment to be applicable to various underlays (e.g. 3GPP, Automotive, IoT, Enterprise, packet Transport)

20. Future Work E2E Service Intelligence (e.g. verticals, slicing, FMC, IoT) • Each domain (e.g. RAN, Core, OAM, Edge, Transport, OSS/BSS) may build its own ML mechanism • But E2E service for end-user involves all these together. • Individual SDOs working on pieces (e.g. 3GPP on RAN/Core, ETSI on virtualization and platforms, IETF on protocols and transport, TM Forum on OSS/BSS) • A uniform ML mechanism which correlates data from multiple domains is needed for E2E Service intelligence. Orchestration and Intelligence (e.g. MLFO) • Re-using the existing mechanisms to understand the use case recipe (intent) • Utilize the hooks from the platform to take placing decisions • Monitoring, evaluation and optimization of ML

21. Participation from China Colleagues Shenzhen meeting on March 5th 2019. • Use cases document will be baselined • 20+ use cases in various domains: network operation automation, QoE optimization, • Mobility Pattern Prediction, Application-Specific Network Slicing, • channel modeling and channel prediction and many others described in this document. • WG3 arch deliverable will be baselined. • By March 2019, a mechanism for evaluating ML Intelligence level in the network would be added to the architecture. • WG2 deliverable will be baselined. • Data in terms of measurement and context information, its representation and dimensions are studied in this document. • How to make Contributions?

22. Acknowledgement CAICT, ITU FG ML5G, all the colleagues here! References • https://extranet.itu.int/sites/itu-t/focusgroups/ML5G/SitePages/Home.aspx • ML5G-I-117-R3: architecture document • ML5G-I-118-R4: usecases document • ML5G-I-086-R3: data mechanisms (WG2) document • ML5G-I-095-R1: standards gaps and liaisons Contact - email: vishnu.n@ieee.org - WeChat ID: Vishnu-Ram-OV Thank you!