Slide 1

Slide 1 text

[email protected] The Development and Prospect of AI/ML O-RAN Cloud-Native Automation

Slide 2

Slide 2 text

興趣:O-RAN、行動通訊技術、講幹話、 腦科學、單口喜劇、科普教育。 • O-RAN SC • Nephio (nephio-dev) Google Developer Student Clubs ČVUT Lead Google Developer Student Clubs NYCU Lead 「教學、研究、服務」 受國家之栽培,當國家有需要的時候,我樂於 回饋自己的能力與專長。

Slide 3

Slide 3 text

一般來說,用來實現 RAN 的自動化和優化的 AI/ML,在使用範例上我們主要會分為三種 第一種是 SON (Self-Organizing Networks),自組織網路,就是相鄰的基站可以互相溝通協調,讓基站可以自動進行自身 PCI 的動態配置,來確保基站 PCI 不會有衝突,確保資訊可以成功的傳輸到 UE 上。不過這個我們今天也不會談到。 第二種是 RAN 的智慧控制器 RIC 它的 Use Cases,什麼是 RIC 的 Use Case 呢? 就是透過 Non-RT RIC 和 Near-RT RIC 的 AI/ML workflow 來實現 Network Slicing、Traffic steering、或是 QoS、QoE 的優化。 如果你今天點入這支影片是希望了解有關 O-RAN RIC AI/ML workflow 的應用 ,那這部影片不會有你想要的資訊,您可以退出全螢幕離開這支影片了。 但是在離開之前可以幫我訂閱一下我的頻道,因為這個 RIC AI/ML workflow 的講解,其實我 PPT 已經做好了,也都已經公布在網路上了,只是都沒有時間做影片。 那我們今天要講的重點呢,就是第三種的 RAN Automation,RAN Automation 意思就是使用者只要聲明 RAN 的使用意圖, Network Function 的編排系統就可以藉由這個意圖來驅動 O-RAN Closed-loop 進行 NF 的自動配置以及部屬, 像是NF LCM 或是 NF 的 Scale out、Scale in 來實現 RAN Automation。

Slide 4

Slide 4 text

那麼很高興你沒有離開這隻影片,那接下來我快速講一下我們今天議程的部分啦~ 首先第一個部分,我會提及,我們應該要開始以全雲原生來重新構想 RAN 那第二部分,我會介紹用來實現 RAN Automation 相關的介面 第三個部分 我會介紹下世代的 雲原生 RAN 的自動化如何實現 最後做一個總結與勉勵,那們就讓我們開始今天重點啦~

Slide 5

Slide 5 text

各位親愛的觀眾朋友呀~ 我們應該要開始以全雲原生來重新定義未來的 RAN,因為電信網路架構向雲的過渡已經開始! 在過去 4G 時代之前,RAN 通常都是採用 PNF (Physical network function) 來進行搭建。 而採用 PNF 來進行搭建的優點,就是可以依照需求,專門為特定使用場景 (Scenario) 或是應用程式,量身訂製硬體設備打造一套完整的電信基站。 但是 PNF 的缺點就是,當我們今天要進行升級部署新功能時,通常就會需要把整個 PNF 換掉,換成新的硬體設備。

Slide 6

Slide 6 text

而後進入 4G 時代,虛擬化 vRAN 的技術出現,但是由於 vRAN 是採用通用型伺服器來部屬,無法因應不同場景提供最高效能,同時 4G 時期還有延遲問題。 因此 vRAN 架構只有被應用在少數場域,

Slide 7

Slide 7 text

如今隨著新世代行動通訊技術標準的更新時程不斷縮短,萬物聯網的概念興起,4G 出現了 NB-IOT,3GPP R17 出現了 Redcap 標準。 電信業者勢必需要投資在網路設備上,來實現更快的網路速度、更大的網路容量,適應更複雜的使用場景, (台語)你想看看,電信業者若是用 PNF ,逐次新的標準,可能 3年5年 制定出來,我毋ㄗㄨㄣ阿每3年都攏要花一條大條, 把我全台灣的設備換新的,我跟你說,你若是開公司的人,你不堪這樣搞,公司法第一條就寫說,公司以營利為目的。 所以電信業者在實現上述目標的同時,也要兼顧設備成本、APRU 和 敏捷性部屬以及管理,因此行動通訊技術的演進,也引入了DevOps 概念。 一路從 核心網路(Core Network;CN) 開始著手(像是 free5GC),緊接著是 無線電接取網路(Radio Access Network;RAN), 行動通訊技術的演進 開始了一連串的 Open source 開放原始碼、虛擬化,甚至是全雲原生(Cloud-Native) 的轉型之旅。

Slide 8

Slide 8 text

Related Interfaces for RAN Automation Related Interfaces for RAN Automation 學習目標 : 了解與 組件:SMO(ONAP)、O-Cloud、OAM 介面:O1、O2、O-Cloud notification 學習目標 : 了解與 組件:SMO(ONAP)、O-Cloud、OAM 介面:O1、O2、O-Cloud notification

Slide 9

Slide 9 text

9 ONAP as an O-RAN SMO (OAM Architecture) A1:REST Service Management and Orchestration Management-Service (MnS) Non-RT-RIC (A1 and O1) Infrastructure Management Framework VIM Near-Real-Time RAN Intelligent Controller (RIC) Infrastructure COTS / White Box / Peripheral Hardware & Virtualization layer ~NfVi O1* E2 O1:NetConf/YANG/CM E1 O-CU-CP O-CU-UP O-RU Open Fronthaul F1-c F1-u O-DU VES Collector (FCAPS) Message bus (e.g DMaaP) Data Analytics Portal Inventory SO Policy Opt AAF LOG O1:REST/VES/CM, FM, others HV-VES Collector (FCAPS) ConfigDB O1*: Interface between Service Management and Orchestration Framework and Infrastructure Management Framework supporting O-RAN virtual network functions. 2019-08: will be available later in document “O- RAN Orchestration”. CDS O1:REST/VES/PM

Slide 10

Slide 10 text

High Level Architecture of O-RAN

Slide 11

Slide 11 text

O1 O2 A1 O1 O1 O1 O1 O-Cloud (SMO) O-CU-CP O-RU Near-RT RIC Near-RT RIC O-CU-UP Non-RT RIC O1 rAPP R1 O-DU SMO

Slide 12

Slide 12 text

SMO O2 A1 O1 O1 O1 O1 O-Cloud (SMO) O-CU-CP O-RU Near-RT RIC Near-RT RIC O-CU-UP Non-RT RIC O1 rAPP R1 O-DU O1 • RU 它就是很 Physical 的東西, 目前還沒辦法雲原生。 • RU 會往 ARM 架構設計來發展, 因為 B5G bandwidth 很大, 用 傳統的 x86 架構來做 Massive MIMO ,效率比較低又耗電

Slide 13

Slide 13 text

O1 O2 A1 O1 O1 O1 O1 O-Cloud (SMO) O-CU-CP O-RU Near-RT RIC Near-RT RIC O-CU-UP Non-RT RIC O1 rAPP R1 O-DU SMO (O1 Interface)

Slide 14

Slide 14 text

14 SMO Interacts with the NFs Via O1 Interface O1 Interface NF NETCONF Server RIC, O-CU, O-DU, O-RU SMO NETCONF Client • • https://wiki.o-ran-sc.org/display/OAM/OAM+Architecture

Slide 15

Slide 15 text

15 O1 Component Architecture • NETCONF Client • • NETCONF Server • MnS Provider https://wiki.o-ran-sc.org/display/OAM/OAM+Architecture

Slide 16

Slide 16 text

O1/VES Interface 16 https://wiki.o-ran-sc.org/display/OAM/OAM+Architecture

Slide 17

Slide 17 text

O1/VES Interface 17 https://wiki.o-ran-sc.org/display/OAM/OAM+Architecture

Slide 18

Slide 18 text

O1 O2 A1 O1 O1 O1 O1 O-Cloud (SMO) O-CU-CP O-RU Near-RT RIC Near-RT RIC O-CU-UP Non-RT RIC O1 rAPP R1 O-DU SMO (O2 Interface)

Slide 19

Slide 19 text

Introducing the Emerging O2 Interface OAM Architecture SMO NFs O-Cloud O2

Slide 20

Slide 20 text

• O-Cloud infrastructure Discovery and administration • O-Cloud infrastructure Scale-In, Scale-Out • O-Cloud infrastructure FCAPS (PM, CM, FM, Communication Surveillance) • O-Cloud infrastructure Platform Software Management • Creation, Scale-In, Scale-Out of abstracted assigned O-Cloud infrastructure resources • Deployment FCAPS (PM, FM) for abstracted O-Cloud infrastructure resources • Deployment DMS (Creation, Deletion and Lease of O-Cloud infrastructure) Infrastructure Mgmt Abstracted Resources and DMSes Mgmt • Deployment Software Management • Deployment, Termination, Scaling, and Healing of NF & Services deployment resources • FCAPS (PM, FM) for NF & Services deployment resources NF & Services Deployment Orchestration O2 Interfaces Perform Functions: OAM Architecture Functions: O-RAN.WG6.O2-GA&P-R003-v04.00

Slide 21

Slide 21 text

Functions: O-RAN.WG6.O2-GA&P-R003-v04.00

Slide 22

Slide 22 text

◆ ◆ O2ims ◆ ◆ ◆ O2dms O-RAN.WG6.O2-GA&P-R003-v04.00

Slide 23

Slide 23 text

• • NF Deployment(Workload)

Slide 24

Slide 24 text

Infrastructure Management Services (IMS) Deployment Management Services (DMS) • • • • • • O-Cloud Functional blocks 簡介(有兩個功能塊) O-RAN.WG6.O2-GA&P-R003-v04.00

Slide 25

Slide 25 text

NFO SMO Functional blocks OAM Functions • • FOCOM • • • • • • • O-RAN.WG6.O2-GA&P-R003-v04.00

Slide 26

Slide 26 text

Cloud Stack (Containers/VMs, OS, Mgmt.) O-RU O-CU O-DU AAL AAL AAL PDCP/ SDAP RRC RLC MAC Low- PHY RF High- PHY FPGA x86 ASIC GPU O-Cloud Major Components of O-Cloud

Slide 27

Slide 27 text

⚫ Deploy ⚫ Terminate ⚫ Scale ⚫ Health Check (For Further Study;FFS) ⚫ Heal (For Further Study;FFS) ⚫ Diagnostic (For Further Study;FFS) 2023 June O-RAN.WG6.O2-GA&P-R003-v04.00 LCM (Life Cycle Management)

Slide 28

Slide 28 text

DevOps

Slide 29

Slide 29 text

CNF DevOps

Slide 30

Slide 30 text

CNF DevOps

Slide 31

Slide 31 text

Close loop Control (RAN Automation)

Slide 32

Slide 32 text

1

Slide 33

Slide 33 text

Telco challenges to Cloud native evolution VNF to CNF Centralized to Highly Distributed Network

Slide 34

Slide 34 text

True Cloud-Native: K8s automation all the way down to Cloud infrastructure & NFs MANO (NFVO/VNFM) VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VIM Past 4 years Compute Storage Networking MANO (NFVO/VNFM/CNFM) VM VM VM VM VM VM VM VM VM VM VM VM VIM Today C C C C C C C C C C C C C C C C CaaS CaaS/Infra Mgmt Kubernetes-based Cloud Native Automation with KRM VM VM VM VM VM VM VM VM Nephio C C C C C C C C C C C C C C C C C C C C C C C C Public Private Edge Compute Storage Networking Compute Storage Networking Non-Container Era Traditional methods: K8s with out-of- band automation Transition to Cloud Native Automation

Slide 35

Slide 35 text

轉型到全雲原生遇到的挑戰 (Lack of Right Technology) ● ● ● ● ○ ○ ○ ○ ○

Slide 36

Slide 36 text

(IaC) O-RAN 5

Slide 37

Slide 37 text

Cloud Native Automation - How do we get there? ● ● ● ● ● ● ● ● ● 01 02

Slide 38

Slide 38 text

7 Configuration-as-Data is Declarative (Not Imperative) I’m thirsty… I want soda in my blue cup. Sure! Thanks for trusting me to figure out how to get you a soda. Declarative: User Friendly Imperative : Hardship to user I’m thirsty… Go to the kitchen Open the fridge Reach in the back to get the soda Close the fridge Grab a blue cup from the left cupboard Pour out the soda in the cup Bring the cup back to me Ummm… okay thanks for telling me exactly what to do...sheesh!

Slide 39

Slide 39 text

● ●

Slide 40

Slide 40 text

● ● ●

Slide 41

Slide 41 text

O2dms O2ims

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

Cloud Native Automation - all the way! Scope of the Nephio ● ● ● ● Nephio: K8s based Telecom Domain Automation (s) Cloud Infra Resources Automation (Public & Private) End-to-End Service Orchestration + End-to-End Slice Management Workload Resource Automation (NFs) Workload Configuration (NFs) K8s Operator K8s Operator K8s Operator CRD CRD CRD CNF CNF Kubernetes Cloud Infrastructure Open APIs O2-M Anuket/ETSI O2-D O1, 3GPP Infra & K8s Cluster LCM NF Cloud Config K8s APIs Netconf 1 2 3

Slide 45

Slide 45 text

Nephio: Infrastructure Orchestration Layer Telecom Automation layers & Nephio Scope External: Service Orchestration Layer ○ Accepts user requirements ○ Composes functions and supports end-to-end n/w slicing configuration ○ Pushes intent to domain orchestration layer ○ PNF orchestration Nephio: Domain Orchestration Layer ○ Accepts service composition ○ Calculates domain and cluster-specifics ○ Pushes Kubernetes manifests Nephio: Infra. Orchestration Layer ○ Applies per-cluster Kubernetes manifests ○ Actuates infrastructure resources ○ Results in running network functions ETE/ Service Orchestration Layer Nephio : Domain Automation Layer Business Support Systems End-to-End Service Orchestration User / Service Composition NF Intent OSS and Network Function Vendor CRDs KRM Build / CI Pipeline RAN Automation TN Automation Core Automation Kubernetes API Server Transport Per-Domain NF Intent Infra CRDs, K8s Resources Per-Domain NF Intent RAN/Core/TN CRDs, K8s Resources Kubernetes API Server Compute Storage Network Private / Public Cloud Compute Storage Network Private / Public Cloud

Slide 46

Slide 46 text

15 Nephio: Proposed working structure Linux Foundation Nephio Board (after 1st year) SIG 1: Network Architecture Specifications and Requirements SIG 2: Automation Machinery CRDs, Operators, and Related Tooling,Reference Implementation, and Packaging Nephio TSC SIG 4: Release CI/CD, Test Grids, Builds, Release Machinery, Project Administration

Slide 47

Slide 47 text

Project resources ● Website - https://nephio.org/ , https://nephio.org/about/ ● Blog Postings - https://nephio.org/blog/ ● Project Github - https://github.com/nephio-project (Please note “nephio-project is right one”) ● Project email distro ○ [email protected] (for TSC members) ○ [email protected] (for all) Create an Account: Follow LF Documentation at: https://docs.linuxfoundation.org/lfx/sso/create-an-account Please subscribe to the Nephio developers mailing list. You can do that by sending an email to this address: [email protected] You will receive an auto reply requesting subscription validation. The email content is not important. To join as Supporter: Again, there are no documents to sign or fees to join, just the form needs to be filled out with the requested information. You can fill out this Linux Foundation's simple form (https://forms.gle/Q4pXJdTykYfgziax9) - Contact [email protected] for more information 16

Slide 48

Slide 48 text

Summary Telcos Cloud providers Network function vendor An open, simple, widely adopted Kubernetes based cloud-native automation that enables multi-vendor support, faster onboarding, easier life- cycle management, embedded control- loop, active reconciliation and service assurance - reducing cost by efficiency and agility. A common cloud-based automation framework based on well-proven Kubernetes technology minimizes the levels of custom automation solutions needed for each application. Kubernetes based automation enables faster development with known technology and assures network functions will deploy and run reliably on top of the Cloud. A Kubernetes based cloud native automation enables easier multi-vendor integration with cloud providers, makes Network Function onboarding to cloud easier and improves the overall customer experience with simple and reliably integrated cloud-native automation. Join and be part of this industry effort to make the world a better place with Cloud native automation!

Slide 49

Slide 49 text

Legal Notices 1 8 The Linux Foundation, The Linux Foundation logos, and other marks that may be used herein are owned by The Linux Foundation or its affiliated entities, and are subject to The Linux Foundation’s Trademark Usage Policy at https://www.linuxfoundation.org/trademark-usage, as may be modified from time to time. Linux is a registered trademark of Linus Torvalds. Please see the Linux Mark Institute’s trademark usage page at https://lmi.linuxfoundation.org for details regarding use of this trademark. Some marks that may be used herein are owned by projects operating as separately incorporated entities managed by The Linux Foundation, and have their own trademarks, policies and usage guidelines. TWITTER, TWEET, RETWEET and the Twitter logo are trademarks of Twitter, Inc. or its affiliates. Facebook and the “f” logo are trademarks of Facebook or its affiliates. LinkedIn, the LinkedIn logo, the IN logo and InMail are registered trademarks or trademarks of LinkedIn Corporation and its affiliates in the United States and/or other countries. YouTube and the YouTube icon are trademarks of YouTube or its affiliates. All other trademarks are the property of their respective owners. Use of such marks herein does not represent affiliation with or authorization, sponsorship or approval by such owners unless otherwise expressly specified. The Linux Foundation is subject to other policies, including without limitation its Privacy Policy at https://www.linuxfoundation.org/privacy and its Antitrust Policy at https://www.linuxfoundation.org/antitrust-policy. each as may be modified from time to time. More information about The Linux Foundation’s policies is available at https://www.linuxfoundation.org. Please email [email protected] with any questions about The Linux Foundation’s policies or the notices set forth on this slide.

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

Thank you! 20