Kiến trúc Open RAN (mạng truy nhập vô tuyến mở) và trí tuệ hóa dựa trên RIC
1. Tổng quan
Định nghĩa: Open RAN (Open Radio Access Network) là kiến trúc RAN phân tách các chức năng của mạng truy nhập vô tuyến thành RU·DU·CU, áp dụng giao diện chuẩn mở, ảo hóa và điều khiển thông minh nhằm hướng tới khả năng tương tác đa nhà cung cấp và tự động hóa.
Mạng truy nhập vô tuyến (RAN) của thông tin di động là vùng cốt lõi nằm giữa thiết bị đầu cuối và mạng lõi, xử lý tín hiệu vô tuyến và điều khiển tài nguyên ô (cell), tính di động và chất lượng. Trạm gốc truyền thống thường có thiết bị vô tuyến, xử lý băng gốc và phần mềm điều khiển gắn chặt với thiết bị và giao diện của một nhà cung cấp cụ thể. Nếu sử dụng thiết bị của một nhà cung cấp trong thời gian dài thì việc tích hợp và vận hành có thể đơn giản, nhưng phạm vi lựa chọn khi thay thế thiết bị và đổi mới chức năng bị thu hẹp, đồng thời sự phụ thuộc nhà cung cấp và tính thiếu minh bạch của cơ cấu chi phí có thể gia tăng.
Open RAN không giải quyết vấn đề này đơn thuần theo cách "biến trạm gốc thành mã nguồn mở". Đây là sự thay đổi kiến trúc ngành: chuẩn hóa các điểm phân tách chức năng và giao diện của RAN, tăng khả năng kết hợp phần cứng và phần mềm, và tự động hóa điều khiển tập trung·phân tán bằng phần mềm. Do đó, dù giao diện được công bố, nếu không bảo đảm được kiểm thử tuân thủ, tối ưu hiệu năng, trách nhiệm vận hành và bảo mật thì tính mở trên thực tế vẫn bị hạn chế.
Thành phần cốt lõi gồm O-RU và O-DU, O-CU được kết nối qua fronthaul mở của O-RAN, cùng SMO (Service Management and Orchestration) quản lý·điều phối chúng. O-CU lại có thể được mô tả tách thành O-CU-CP phụ trách mặt phẳng điều khiển và O-CU-UP phụ trách mặt phẳng người dùng. Trí tuệ hóa được hiện thực bằng cách Non-RT RIC và Near-RT RIC phân chia thực hiện chính sách và điều khiển thời gian thực.
Khi thiết kế Open RAN cần xem xét đồng thời bốn mục tiêu. Thứ nhất, khả năng tương tác giữa các nhà cung cấp. Thứ hai, tính linh hoạt khi tận dụng máy chủ đa dụng và công nghệ đám mây. Thứ ba, tự động hóa·tối ưu hóa thông qua RIC và ứng dụng. Thứ tư, bảo mật·hiệu năng·khả năng vận hành với tiền đề là các điểm tiếp xúc mở và cấu hình đa nhà cung cấp. Nếu chỉ đạt một mục tiêu mà hy sinh các mục tiêu còn lại thì khó trở thành cấu trúc bền vững trên mạng thương mại.
Bài trả lời này trình bày dạng tự luận về bối cảnh ra đời của Open RAN, phân rã chức năng và giao diện, trí tuệ hóa RIC, quy trình triển khai, so sánh với RAN truyền thống·vRAN, các lưu ý về bảo mật và hiệu năng cùng chiến lược áp dụng từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer).
2. Bối cảnh ra đời và nguyên lý cơ bản
A. Giới hạn cấu trúc của RAN truyền thống
RAN truyền thống thường có cấu trúc trong đó thiết bị xử lý vô tuyến, thiết bị băng gốc và phần mềm điều khiển được cung cấp như một dòng sản phẩm duy nhất. Cấu trúc này có ưu điểm là một nhà cung cấp chịu trách nhiệm tích hợp về phần cứng·phần mềm·kiểm thử·sự cố. Ngược lại, muốn trộn thiết bị của nhà cung cấp khác vào cùng mạng vô tuyến thì phải điều chỉnh riêng giao diện độc quyền và điều kiện tương tác, khiến chi phí thay thế và gánh nặng kiểm chứng tăng lên.
Ngoài ra, dù nhu cầu lưu lượng và dịch vụ thay đổi theo thời gian·khu vực, rất khó phân bổ lại linh hoạt dung lượng của thiết bị chuyên dụng. Vào khung giờ nhất định ở đô thị có thể thiếu dung lượng, trong khi ở khu vực khác lại dư tài nguyên nhàn rỗi. Tận dụng chức năng dựa trên phần mềm và tài nguyên ảo hóa có thể giúp việc bố trí tài nguyên và cập nhật chức năng linh hoạt hơn, nhưng phải đồng thời thỏa mãn các ràng buộc về độ trễ·đồng bộ·thông lượng của lớp vật lý vô tuyến.
Từ 5G trở đi, xuất hiện nhiều yêu cầu đa dạng vượt ra ngoài kết nối thoại·dữ liệu đơn thuần như network slicing, dịch vụ siêu độ trễ thấp, mạng riêng công nghiệp, IoT quy mô lớn. RAN phải vượt qua cấu hình trạm gốc tĩnh để điều chỉnh tài nguyên dựa trên chính sách và dữ liệu quan sát. Khi thay đổi này kết hợp với giao diện mở, vận hành cloud native và tối ưu hóa dựa trên AI/ML, nhu cầu về Open RAN ngày càng lớn.
B. Nguyên lý cốt lõi của Open RAN
Thứ nhất là phân tách chức năng (disaggregation). Khi tách về mặt logic·vật lý RU thu phát tín hiệu vô tuyến, DU thực hiện chức năng xử lý băng gốc phân tán và CU thực hiện xử lý lớp trên cùng liên kết mạng lõi, ta có thể lựa chọn vị trí bố trí và cấu hình nhà cung cấp. Tuy nhiên, yêu cầu về lượng dữ liệu, độ trễ, đồng bộ và mạng truyền dẫn khác nhau theo từng điểm phân tách, nên bản thân việc tách chức năng không phải lúc nào cũng đồng nghĩa với tiết kiệm chi phí.
Thứ hai là giao diện mở (open interface). Giao diện mở làm rõ thông điệp, thủ tục, yêu cầu hiệu năng·bảo mật của tương tác giữa các chức năng để các hiện thực khác nhau có thể kết nối với nhau. Dù tài liệu giao diện được công bố, nếu tùy chọn, profile, phương pháp kiểm thử của các hiện thực khác nhau thì vấn đề tích hợp vẫn còn, vì vậy cần đồng thời kiểm thử tuân thủ·tương tác và khả năng quan sát vận hành.
Thứ ba là ảo hóa và đám mây hóa. Khi chạy chức năng DU·CU trên máy chủ đa dụng, bộ tăng tốc, container hoặc máy ảo, phạm vi lựa chọn trong mua sắm phần cứng và triển khai chức năng được mở rộng. Tuy nhiên, khác với tải công việc CNTT thông thường, xử lý vô tuyến đòi hỏi định thời và thông lượng nghiêm ngặt nên phải xem xét CPU pinning, bố trí NUMA, bộ tăng tốc, kernel thời gian thực, thiết kế đồng bộ độ chính xác cao.
Thứ tư là điều khiển thông minh (intelligence). Dữ liệu hiệu năng·sự cố·tải thu thập từ RAN được dùng để xây dựng chính sách, và ứng dụng hỗ trợ các điều khiển như chọn cell·cân bằng tải·tiết kiệm năng lượng. AI càng đi sâu vào vòng điều khiển thì chất lượng dữ liệu, kiểm chứng mô hình, xung đột chính sách, giá trị mặc định an toàn khi thất bại và rollback càng trở nên quan trọng.
3. Cấu trúc chức năng và giao diện của Open RAN
A. Cấu hình tổng thể
flowchart TB
UE[Thiết bị đầu cuối UE] <-->|Truy nhập vô tuyến| RU[O-RU<br/>Radio Unit]
RU <-->|Open Fronthaul<br/>7-2x·đồng bộ| DU[O-DU<br/>Distributed Unit]
DU -->|F1| CUCP[O-CU-CP<br/>Mặt phẳng điều khiển]
DU -->|F1| CUUP[O-CU-UP<br/>Mặt phẳng người dùng]
CUCP <-->|E1| CUUP
CUCP -->|NG-C| CORE[5G Core]
CUUP -->|NG-U| CORE
SMO[SMO<br/>Quản lý dịch vụ·điều phối] -->|O1| RU
SMO -->|O1| DU
SMO -->|O1| CUCP
SMO -->|O1| CUUP
SMO -->|O2| CLOUD[Hạ tầng đám mây·điều phối]
NRT[Non-RT RIC] -->|A1 chính sách·mô hình| NRTIC[Near-RT RIC]
NRTIC -->|E2 điều khiển·đo lường| DU
NRTIC -->|E2 điều khiển·đo lường| CUCP
NRTIC -->|E2 điều khiển·đo lường| CUUP
SMO --- NRT
O-RU xử lý tín hiệu vô tuyến số ở vị trí gần tần số vô tuyến và anten. Bố trí gần anten có thể rút ngắn khoảng cách truyền fronthaul, nhưng điều kiện điện năng·nhiệt độ·bảo trì của thiết bị hiện trường trở nên quan trọng. Chức năng và hiệu năng của O-RU phải phù hợp với điều kiện fronthaul mở với DU, và trong kiểm thử tương tác phải kiểm chứng đồng thời độ trễ và sai lệch đồng bộ.
O-DU xử lý tại vị trí phân tán các chức năng lớp dưới có ràng buộc thời gian lớn trong ngăn xếp giao thức RAN. Vì O-DU gần với tải cell và tài nguyên vô tuyến nên nhạy cảm với độ trễ, và ngay cả khi hiện thực bằng máy chủ đa dụng vẫn phải bảo đảm xử lý thời gian thực và tăng tốc. Thay vì tích hợp vô điều kiện vào đám mây trung tâm, vị trí bố trí được quyết định dựa trên độ trễ mạng truyền dẫn và phạm vi ảnh hưởng của sự cố.
O-CU cho phép bố trí các chức năng lớp trên tại đám mây trung tâm hoặc khu vực. Có thể tách để mặt phẳng điều khiển phụ trách điều khiển kết nối·di động, còn mặt phẳng người dùng phụ trách truyền dữ liệu người dùng. Sự phân tách này giúp tối ưu đường đi lưu lượng và mở rộng tài nguyên, nhưng phải đưa tính nhất quán trạng thái và chuyển đổi dự phòng bên trong CU cũng như giữa CU-DU vào thiết kế vận hành.
SMO là lớp quản lý điều phối việc triển khai·cấu hình·giám sát·vòng đời của tài nguyên RAN và tài nguyên đám mây. Không chỉ bố trí chức năng mạng mà còn phải quản lý nhất quán kiểm kê, sự cố, hiệu năng, phiên bản phần mềm, chính sách và chứng chỉ. Nếu SMO chỉ dừng ở tập hợp công cụ riêng của từng nhà cung cấp thì độ phức tạp vận hành của cấu trúc mở có thể còn tăng lên.
B. Vai trò của các giao diện chính
Open Fronthaul đảm nhận truyền dữ liệu·điều khiển·đồng bộ vô tuyến giữa O-RU và O-DU. Vì lượng dữ liệu giữa các thiết bị đã tách là lớn và ràng buộc định thời chặt chẽ, giao diện này đòi hỏi băng thông, độ trễ, jitter của mạng truyền dẫn và đồng bộ thời gian chính xác. Tại hiện trường, không chỉ kiểm tra tương thích thiết bị mà còn phải kiểm thử lưu lượng đỉnh và chuyển mạch bảo vệ khi sự cố.
Giao diện F1 cung cấp kết nối giữa DU và CU, cho phép phân tách chức năng phân tán·tập trung. E1 hỗ trợ quan hệ điều khiển giữa CU-CP và CU-UP. Phân lớp như vậy giúp mở rộng chức năng và tối ưu bố trí dễ dàng hơn, nhưng khi số giao diện tăng thì tầm quan trọng của phân tích nguyên nhân sự cố và quản lý tương thích phiên bản cũng tăng.
O1 là giao diện trao đổi thông tin quản lý·vận hành·bảo trì, dùng cho quản lý cấu hình·hiệu năng·sự cố·phần mềm. O2 là điểm tiếp xúc liên kết SMO với lớp hạ tầng đám mây·điều phối. Nếu mức tự động hóa của O1/O2 thấp, nhà mạng phải duy trì màn hình và thủ tục vận hành riêng cho thiết bị của từng nhà cung cấp.
A1 truyền chính sách, thông tin hỗ trợ trí tuệ hóa và thông tin liên quan mô hình giữa Non-RT RIC và Near-RT RIC. E2 kết nối đo lường và điều khiển giữa Near-RT RIC và các nút E2 là CU·DU. O-RAN Alliance định nghĩa các chức năng·giao diện này trong tài liệu kỹ thuật, và khi triển khai thực tế phải ghi rõ phiên bản tài liệu và profile được hỗ trợ.
| Phân loại | Đối tượng kết nối | Mục đích chính | Trọng tâm thiết kế |
|---|---|---|---|
| Open Fronthaul | O-RU–O-DU | Dữ liệu·điều khiển·đồng bộ vô tuyến | Băng thông·độ trễ·jitter·đồng bộ thời gian |
| F1 | O-DU–O-CU | Kết nối chức năng phân tán/tập trung | Quản lý trạng thái·tương thích phiên bản·chuyển mạch |
| E1 | O-CU-CP–O-CU-UP | Liên kết mặt phẳng điều khiển·người dùng của CU | Trạng thái phiên·chuyển đổi dự phòng |
| O1 | SMO–nút RAN | Quản lý cấu hình·sự cố·hiệu năng·phần mềm | Mô hình chuẩn·tự động hóa·bằng chứng |
| O2 | SMO–hạ tầng đám mây | Điều phối tài nguyên ảo | Tài nguyên·bố trí·vòng đời |
| A1 | Non-RT RIC–Near-RT RIC | Truyền chính sách·mô hình·ý định | Xung đột chính sách·quyền hạn·kiểm chứng |
| E2 | Near-RT RIC–nút E2 | Đo lường·điều khiển·tối ưu | Độ trễ·an toàn·cô lập ứng dụng |
Các giao diện trong bảng không thay thế nhau mà đảm nhận các mức trừu tượng và phạm vi thời gian khác nhau. Ví dụ, thay đổi cấu hình qua O1 được xử lý trong vòng đời quản lý, còn điều khiển qua E2 phản ánh trạng thái vận hành như tải cell và tài nguyên vô tuyến theo chu kỳ ngắn. Nếu cùng một tham số có thể được thay đổi từ nhiều điểm tiếp xúc thì phải quy định thứ tự ưu tiên quyền hạn và quy tắc giải quyết xung đột.
4. Trí tuệ hóa dựa trên RIC và quy trình vận hành
A. Non-RT RIC và Near-RT RIC
Non-RT RIC thực hiện điều khiển có chu kỳ tương đối dài như chính sách·phân tích·huấn luyện mô hình bên trong SMO. Nó có thể phân tích xu hướng hiệu năng dài hạn, mức sử dụng năng lượng, mô hình di chuyển thuê bao, lịch sử sự cố để tạo chính sách hoặc mô hình. Chính sách được tạo ở đây phải biểu diễn mục tiêu và ràng buộc của điều khiển hiện trường, không được chỉ đưa ra mục đích "tối đa hóa" đơn thuần.
Near-RT RIC nhận thông tin đo lường của nút E2 và thực hiện điều khiển có chu kỳ tương đối ngắn. Các chức năng cần tính thời gian thực như cân bằng tải, tối ưu kết nối kép, hỗ trợ di động, giảm nhiễu có thể được hiện thực dưới dạng ứng dụng xApp. Nếu nhiều xApp cùng điều khiển một tài nguyên thì mục tiêu có thể xung đột, vì vậy phải quản lý thứ tự ưu tiên thực thi, phạm vi chính sách và các biến điều khiển được phê duyệt.
sequenceDiagram
participant N as Non-RT RIC
participant A as A1 chính sách·mô hình
participant R as Near-RT RIC
participant E as Nút E2 (DU/CU)
participant X as xApp
participant M as SMO/O1
E->>M: Dữ liệu hiệu năng·sự cố·cấu hình
M->>N: Dữ liệu quan sát dài hạn
N->>N: Phân tích·huấn luyện mô hình·kiểm chứng chính sách
N->>A: Truyền chính sách·mô hình
A->>R: Áp dụng chính sách
E->>R: Giá trị đo·sự kiện (E2)
R->>X: Cung cấp đầu vào đã phê duyệt
X->>R: Quyết định điều khiển
R->>E: Lệnh điều khiển đã kiểm chứng (E2)
E-->>R: Kết quả·lỗi·phép đo mới
R-->>N: Báo cáo hiệu quả·drift
Trong cấu trúc này, mô hình AI không phải mô-đun vạn năng trực tiếp kiểm soát mạng. Phải giám sát độ trễ·thiếu sót·thiên lệch của đầu vào mô hình, và chỉ chuyển đổi thành lệnh điều khiển sau khi bộ máy chính sách kiểm tra đầu ra nằm trong phạm vi cho phép. Khi mô hình không chắc chắn hoặc phân phối dữ liệu thay đổi, nên chuyển sang chính sách mặc định an toàn dựa trên quy tắc, và các lệnh có ảnh hưởng lớn cần yêu cầu con người phê duyệt.
B. Quy trình từng bước của điều khiển thông minh
Bước đầu tiên là định nghĩa mục đích và ràng buộc. Nếu chỉ đặt mục tiêu "tối thiểu hóa mức sử dụng năng lượng" thì chất lượng dịch vụ hoặc ưu tiên của liên lạc khẩn cấp có thể bị tổn hại. Do đó, lượng hóa đồng thời các mục đích·ràng buộc như vùng phủ, thông lượng, độ trễ, SLA theo slice, dịch vụ khẩn cấp và điện năng.
Thứ hai là thu thập dữ liệu và kiểm chứng chất lượng. Kiểm tra căn chỉnh thời gian, giá trị thiếu, ngoại lai, tính nhất quán nhãn của giá trị đo theo cell·thiết bị·nhóm thuê bao. Nếu không quản lý nguồn gốc, thời hạn lưu trữ và việc có chứa thông tin cá nhân của dữ liệu đo, trí tuệ hóa có thể làm tăng rủi ro bảo mật·thông tin cá nhân.
Thứ ba là đánh giá ngoại tuyến và kiểm chứng trực tuyến có giới hạn. Sau khi đánh giá khả năng tái lập và mô phỏng bằng dữ liệu quá khứ, chính sách chỉ được áp dụng cho một số cell·khung giờ để so sánh với nhóm đối chứng. Dù hiệu quả trung bình có vẻ tốt, nó vẫn có thể bất lợi cho khu vực·thiết bị·nhóm dịch vụ cụ thể, nên phải xác nhận tính an toàn và công bằng theo từng phân khúc.
Thứ tư là triển khai·giám sát·thu hồi. Đăng ký phiên bản mô hình và chính sách vào registry, ghi lại người phê duyệt·dữ liệu huấn luyện·kết quả đánh giá·phạm vi áp dụng. Trong vận hành, giám sát không chỉ chỉ số mục tiêu mà cả tỷ lệ thất bại lệnh điều khiển, số lần rollback, ngoại lệ phát sinh, data drift; khi vượt ngưỡng thì tự động quay về phiên bản trước hoặc chính sách mặc định.
| Bước | Hoạt động chính | Sản phẩm kiểm soát |
|---|---|---|
| Định nghĩa mục đích | Thiết lập mục tiêu·ràng buộc·phạm vi ảnh hưởng | Đặc tả ý định, KPI/SLO, mức chấp nhận rủi ro |
| Chuẩn bị dữ liệu | Thu thập·nhất quán·phi định danh·kiểm tra chất lượng | Dòng dõi dữ liệu, báo cáo chất lượng |
| Đánh giá | Mô phỏng·nhóm đối chứng·kiểm thử ngoại lệ | Kết quả đánh giá, hồ sơ phê duyệt |
| Triển khai giới hạn | Cell canary·mở rộng dần | Kế hoạch triển khai, điều kiện rollback |
| Vận hành | Quan sát hiệu quả·drift·sự cố | Dashboard, nhật ký kiểm toán |
| Cải tiến·thu hồi | Huấn luyện lại·điều chỉnh chính sách·chuyển đổi khẩn cấp | Hồ sơ thay đổi, rà soát sau sự cố |
C. SMO và quản lý vòng đời tự động
Tự động hóa của SMO không dừng ở việc triển khai thiết bị nhanh mà phải kết nối toàn bộ vòng đời ý định·cấu hình·quan sát·thay đổi·loại bỏ. Ví dụ, khi triển khai phần mềm DU mới, kiểm chứng phiên bản RU·bộ tăng tốc·kernel tương thích, và chỉ đưa lưu lượng vào sau khi vượt qua trạng thái đồng bộ fronthaul và tiêu chí hiệu năng.
Quản lý cấu hình phải cho thấy chênh lệch giữa trạng thái mong muốn (desired state) và trạng thái thực tế (actual state). Nếu trạng thái thực tế khác với khai báo thì có thể tự động hiệu chỉnh, nhưng ghi đè vô điều kiện có nguy cơ đảo ngược sự cố hiện trường hoặc biện pháp khẩn cấp. Ghi lại nguyên nhân và phê duyệt thay đổi, phạm vi áp dụng, phương pháp rollback, và kiểm soát thay đổi khẩn cấp bằng rà soát sau sự việc.
Người vận hành phải có khả năng xác nhận sự phụ thuộc giữa cell·RU·DU·CU·ứng dụng RIC·tài nguyên đám mây trong danh mục dịch vụ. Khi sự cố xảy ra, cần nhanh chóng phân định đó là vấn đề thiết bị của một nhà cung cấp cụ thể, mạng truyền dẫn fronthaul, đồng bộ thời gian hay chính sách RIC. Khả năng quan sát này là căn cứ để phán định trách nhiệm SLA trong môi trường đa nhà cung cấp.
5. Chiến lược triển khai và thiết kế hiệu năng
A. Triển khai theo giai đoạn
Giai đoạn đầu xác định mục tiêu kinh doanh và phạm vi dịch vụ. Thay vì mở toàn bộ mạng toàn quốc một lần, chọn vùng có phạm vi ảnh hưởng giới hạn như mạng riêng mới, một thành phố cụ thể, mạng chuyên dụng doanh nghiệp, cell thử nghiệm để kiểm chứng khả năng tương tác và thủ tục vận hành. Điểm liên kết với mạng hiện hữu, đường quay về khi sự cố, điều kiện tần số·quy định được đưa vào thiết kế ban đầu.
Thứ hai là kiểm thử đa nhà cung cấp. Các tổ hợp RU·DU·CU·SMO·RIC được kiểm chứng tách thành kiểm thử chức năng, hiệu năng, sự cố và bảo mật. Không dừng ở việc xác nhận thiết bị kết nối được mà phải kiểm thử di chuyển qua biên cell, tải đỉnh, mất gói, lệch đồng bộ thời gian, nâng cấp phần mềm và thay thế nhà cung cấp.
Thứ ba là thí điểm thương mại có giới hạn. Không chỉ xem hiệu năng trung bình 24 giờ mà quan sát đỉnh giờ đi làm, lưu lượng sự kiện, điều kiện môi trường như mưa·nhiệt độ cao, chất lượng theo nhóm thiết bị và dịch vụ cụ thể. Tiêu chí thành công của thí điểm không phải là tăng throughput đơn thuần mà phải bao gồm thời gian khôi phục sự cố, thời gian xử lý của người vận hành, tỷ lệ thất bại tự động hóa và tổng chi phí.
Thứ tư là mở rộng và chuẩn hóa. Chuẩn hóa cấu hình tham chiếu đã kiểm chứng, tiêu chí đủ điều kiện nhà cung cấp, bảng tương thích phiên bản, runbook vận hành, tiêu chuẩn bảo mật. Khi mở rộng khu vực·dịch vụ, xây dựng kiểm thử tuân thủ tự động và pipeline triển khai để không phải tích hợp tạm thời mỗi tổ hợp mới.
B. Lưu ý về hiệu năng·đồng bộ·bộ tăng tốc
Hiệu năng của Open RAN không được bảo đảm chỉ bởi việc giao diện đã được mở. Băng thông và độ trễ fronthaul, thông lượng DU, số người dùng, số anten, hiện thực bộ lập lịch, chi phí mã hóa và việc sử dụng bộ tăng tốc cùng tạo nên kết quả. Ngay cả cùng một thiết bị, mức sử dụng CPU và phân phối độ trễ cũng khác nhau theo profile và mẫu lưu lượng, nên phải xem cả giá trị trung bình và độ trễ đuôi (tail latency).
Đồng bộ thời gian là bắt buộc đối với phân tách chức năng vô tuyến. Phân biệt đồng bộ tần số với đồng bộ pha·thời gian, thiết kế các nguồn như GNSS·PTP·SyncE và hành vi holdover khi sự cố. Cũng phải xác định trước chính sách khi chất lượng đồng bộ suy giảm: ngừng dịch vụ vô điều kiện hay duy trì với hiệu năng hạ thấp.
Tận dụng máy chủ đa dụng có thể nâng cao hiệu quả tài nguyên, nhưng cạnh tranh CPU và bộ nhớ có thể làm dao động độ trễ xử lý vô tuyến. Đánh giá theo từng tải công việc tổ hợp cô lập lõi CPU, bố trí nhận biết NUMA, xử lý gói họ DPDK, FPGA·GPU·bộ tăng tốc chuyên dụng, lập lịch thời gian thực. Nếu phụ thuộc vào một bộ tăng tốc cụ thể thì phải xem xét lại lợi ích của tính mở và cơ cấu chi phí.
6. So sánh RAN truyền thống·vRAN·Open RAN
RAN truyền thống là sản phẩm tích hợp nên ranh giới kiểm thử và trách nhiệm tương đối đơn giản, nhưng tính linh hoạt trong lựa chọn nhà cung cấp và thay thế chức năng có thể thấp. vRAN là cách tiếp cận ảo hóa·phần mềm hóa chức năng RAN để chạy trên nền điện toán đa dụng, còn Open RAN có thể hiểu là bổ sung thêm góc nhìn phân tách chức năng, giao diện mở, tương tác đa nhà cung cấp và trí tuệ hóa RIC. Trong sản phẩm và mô hình kinh doanh thực tế, phạm vi của ba thuật ngữ có thể chồng lấn nên cần xác nhận giao diện được áp dụng và phạm vi vận hành hơn là thuật ngữ.
| Phân loại | RAN tích hợp truyền thống | vRAN | Open RAN |
|---|---|---|---|
| Liên kết chức năng | Gắn chặt với thiết bị nhà cung cấp | Trọng tâm phần mềm hóa | Phân tách chức năng·giao diện mở |
| Phần cứng | Tỷ trọng thiết bị chuyên dụng cao | Tận dụng máy chủ đa dụng | Tổ hợp đa dụng·bộ tăng tốc·chuyên dụng |
| Cấu hình nhà cung cấp | Trọng tâm một nhà cung cấp | Tùy hiện thực | Hướng tới tương tác đa nhà cung cấp |
| Trí tuệ hóa | Quản lý·tối ưu theo từng thiết bị | Có thể quản lý tập trung | Tự động hóa dựa trên RIC·ứng dụng·chính sách |
| Ưu điểm | Trách nhiệm tích hợp·kiểm chứng đơn giản | Linh hoạt tài nguyên·triển khai phần mềm | Quyền lựa chọn·đổi mới·tự động hóa |
| Rủi ro chính | Phụ thuộc·chi phí thay thế | Hiệu năng·chi phí ảo hóa | Độ phức tạp tích hợp·vận hành·bảo mật |
Không nên đánh giá sự khác biệt đơn thuần qua mức độ mở nhiều hay ít. Cấu trúc một nhà cung cấp có thể có ranh giới rõ ràng về nguyên nhân sự cố và trách nhiệm, còn Open RAN tăng quyền lựa chọn nhà cung cấp nhưng một sự cố có thể trải trên nhiều lớp·nhà cung cấp. Do đó, quyết định áp dụng phải so sánh bằng TCO bao gồm không chỉ giá thiết bị mà cả kiểm thử tích hợp, nhân lực vận hành, nền tảng quan sát, vòng đời linh kiện·phần mềm và chi phí chuyển đổi.
Hơn nữa, Open RAN không phù hợp như nhau với mọi khu vực và dịch vụ. Ở vùng lưu lượng biến động lớn và giá trị của tự động hóa·lựa chọn nhà cung cấp cao thì hiệu quả có thể lớn, nhưng trong môi trường mạng truyền dẫn hạn chế hoặc dư địa hiệu năng thời gian thực nhỏ thì phải thận trọng chọn điểm phân tách và vị trí bố trí. Chiến lược lai liên kết từng bước với RAN hiện hữu cũng là phương án hợp lý.
7. Tình huống: áp dụng Open RAN cho mạng 5G riêng của doanh nghiệp sản xuất
Giả sử một doanh nghiệp sản xuất xây dựng mạng 5G riêng cho AGV, kiểm tra bằng hình ảnh và thiết bị đầu cuối của công nhân trong nhà máy. AGV nhạy cảm với di động và độ trễ, kiểm tra bằng hình ảnh đòi hỏi thông lượng uplink cao, còn thiết bị của công nhân coi trọng vùng phủ và sự tiện lợi khi xác thực. Nếu đánh giá ba dịch vụ bằng một KPI duy nhất, cải thiện cho một dịch vụ có thể làm tổn hại chất lượng dịch vụ khác.
Trước hết định nghĩa SLA và thứ tự ưu tiên theo dịch vụ. Gán cho AGV giới hạn trên độ trễ·thời gian chuyển mạch·tính sẵn sàng; cho kiểm tra hình ảnh thông lượng uplink·mất gói·liên kết lưu trữ; cho thiết bị công nhân tỷ lệ xác thực thành công·vùng phủ·thời gian khôi phục. Chính sách này được phản ánh vào ứng dụng RIC và template cấu hình của SMO, nhưng các điều khiển liên quan an toàn không được thay đổi chỉ bằng quyết định tự chủ của AI.
RU được bố trí gần dây chuyền sản xuất và DU đặt tại edge của nhà máy để giảm độ trễ fronthaul và điều khiển vô tuyến. CU và SMO được bố trí phân chia vai trò giữa cụm edge trong nhà máy và trung tâm vận hành trung ương. Tách sự phụ thuộc giữa điều khiển cục bộ và quản lý trung tâm để dù mạng nhà máy bị ngắt, vận hành an toàn và liên lạc tối thiểu vẫn được duy trì.
Near-RT RIC áp dụng chính sách hỗ trợ handover dựa trên tải cell và lộ trình di chuyển của AGV, còn Non-RT RIC phân tích kế hoạch sản xuất theo khung giờ·lịch sử sự cố·dữ liệu điện năng để tạo chính sách tài nguyên dài hạn. Trước khi áp dụng chính sách, thực hiện thử canary trên một dây chuyền sản xuất cụ thể, và nếu AGV dừng·mất gói·handover thất bại vượt ngưỡng thì tự động quay về chính sách trước.
Hiệu quả vận hành không được đánh giá chỉ bằng throughput. Đo đồng thời độ trễ phân vị 99 theo dịch vụ, tỷ lệ handover thất bại, thời gian phát hiện·khôi phục sự cố, mức sử dụng năng lượng, tỷ lệ thay đổi thất bại, thời gian công việc tích hợp đa nhà cung cấp, tỷ lệ tuân thủ vá bảo mật. Có như vậy mới xác nhận được việc áp dụng Open RAN có thực sự nâng cao năng suất và khả năng phục hồi hay không.
8. Lưu ý về bảo mật·độ tin cậy·vận hành
Open RAN tăng số giao diện và thành phần phần mềm nên bề mặt tấn công cũng có thể mở rộng. Đưa O-RU·O-DU·O-CU·SMO·RIC·xApp và hạ tầng đám mây, môi trường phát triển·triển khai của nhà cung cấp vào danh mục tài sản và mô hình mối đe dọa. Đặc biệt, nếu giao diện quản lý và đường điều khiển RIC bị xâm phạm thì hậu quả vượt quá rò rỉ thông tin đơn thuần: tài nguyên vô tuyến và chất lượng dịch vụ có thể bị thao túng.
Thứ nhất, áp dụng xác thực lẫn nhau và bảo vệ truyền thông. Cấp danh tính theo thiết bị·nền tảng·ứng dụng, tự động hóa vòng đời chứng chỉ và thủ tục thu hồi·thay thế. Không lấy niềm tin mạng phẳng làm tiền đề mà áp dụng đặc quyền tối thiểu cho giao diện·lệnh·dữ liệu.
Thứ hai, kiểm soát chuỗi cung ứng của xApp và rApp. Đưa ký mã, SBOM, quét lỗ hổng, nguồn gốc image, quyền thực thi, phạm vi truy cập API, kiểm chứng cập nhật vào cổng triển khai. Tách dữ liệu đo mà ứng dụng được đọc với lệnh điều khiển được thực thi, và lệnh nguy hiểm phải qua bộ máy chính sách và thủ tục phê duyệt.
Thứ ba, xác nhận tính toàn vẹn của phần mềm và cấu hình. Quản lý chuỗi khởi động, chữ ký image, toàn vẹn runtime, lịch sử thay đổi, vá lỗ hổng và rollback. Trong môi trường đa nhà cung cấp, thông báo bảo mật của mỗi nhà cung cấp đến với định dạng và thời điểm khác nhau, nên ghi rõ trong hợp đồng mức nghiêm trọng·thời hạn xử lý·tiêu chí kiểm chứng chung.
Thứ tư, thiết kế cô lập sự cố và khôi phục. Dù RIC ngừng hoạt động, chức năng RAN cơ bản vẫn phải hoạt động an toàn, và dù SMO unavailable thì cấu hình đã phê duyệt vẫn phải được duy trì. Không phụ thuộc vào một cụm·một nguồn thời gian·một mạng quản lý duy nhất, và định nghĩa timeout cùng hành vi mặc định cho từng vòng điều khiển.
| Lĩnh vực | Rủi ro tiêu biểu | Hướng ứng phó |
|---|---|---|
| Giao diện | Giả mạo·sửa đổi, phát lại, từ chối dịch vụ | Xác thực lẫn nhau·mã hóa·chống phát lại·giới hạn tốc độ |
| RIC/xApp | Chính sách độc hại·quyền quá mức·lỗi mô hình | Đặc quyền tối thiểu·kiểm chứng chính sách·sandbox·rollback |
| Đám mây | Chiếm đoạt tài nguyên ảo·cô lập thất bại | Cô lập tải công việc·kiểm chứng image·quan sát runtime |
| Chuỗi cung ứng | Thành phần có lỗ hổng·giả mạo cập nhật | SBOM·chữ ký·SLA lỗ hổng·kiểm chứng nguồn gốc |
| Vận hành | Khoảng trống trách nhiệm đa nhà cung cấp | Runbook chung·bằng chứng·SLA·leo thang |
| Tính sẵn sàng | Sự cố đồng bộ·mạng truyền dẫn·SMO | Tự chủ cục bộ·dự phòng kép·holdover·diễn tập khôi phục |
Kiểm soát bảo mật không được chỉ để lại dưới dạng tài liệu thẩm định riêng. Phải nhúng kiểm soát vào luồng vận hành như triển khai thông thường, phê duyệt chính sách, ứng phó sự cố, thay đổi nhà cung cấp, và phân tích tương quan log để truy vết lệnh điều khiển thực tế và kết quả. Kỹ sư chuyên nghiệp phải giải thích sự đánh đổi giữa bảo mật·hiệu năng·tính sẵn sàng và rủi ro tồn dư bằng các chỉ số mà ban lãnh đạo có thể hiểu.
9. Chuyên sâu: chuẩn hóa Open RAN và các vấn đề tranh luận trong áp dụng công nghiệp
O-RAN Alliance phát triển tài liệu kỹ thuật với mục tiêu RAN mở, thông minh, ảo hóa và có khả năng tương tác, xử lý chức năng·giao diện·quy trình trong nhiều nhóm công tác. Vì tài liệu tiêu chuẩn liên tục được cập nhật, phải ghi rõ trong đề xuất và hợp đồng việc hỗ trợ chức năng của phiên bản cụ thể và phạm vi kiểm thử tương tác. Không được hiểu rằng chỉ riêng cụm từ "tuân thủ O-RAN" đã bảo đảm tương thích của mọi giao diện và profile.
Vấn đề cốt lõi của áp dụng công nghiệp là hiệu năng và chi phí tích hợp. Phải kiểm chứng xem tối ưu hóa mà thiết bị chuyên dụng từng mang lại có đạt được tương tự trên tổ hợp máy chủ đa dụng và đa nhà cung cấp hay không, nhà cung cấp nào phân tích và giải quyết sự cố, ai bảo đảm tương thích khi nâng cấp phần mềm. Để lượng hóa lợi ích kỳ vọng của tính mở, so sánh các chỉ số như thời gian thay nhà cung cấp, chu kỳ ra mắt chức năng, tỷ lệ tự động hóa vận hành, thời gian khôi phục sự cố trung bình với đường cơ sở.
Một vấn đề khác là trách nhiệm của điều khiển thông minh. Dù chính sách dựa trên AI cải thiện hiệu năng, có thể khó giải thích vì sao mô hình điều chỉnh một cell cụ thể, hoặc mô hình có thể đưa ra lệnh nguy hiểm trong tình huống hiếm gặp. Do đó, đưa model card và lịch sử thay đổi, mô phỏng·thử canary, điều kiện phê duyệt·thu hồi, đường can thiệp của con người vào quản trị vận hành.
Trong tương lai, Open RAN có khả năng kết hợp với 5G riêng, điện toán biên, API mạng, tối ưu năng lượng, mạng phi mặt đất. Tuy nhiên, càng kết hợp nhiều chức năng thì độ phức tạp của dữ liệu·chính sách·ranh giới tin cậy càng tăng. Kỹ sư chuyên nghiệp phải xác định phạm vi áp dụng dựa trên mục đích kinh doanh, chất lượng dịch vụ, chuỗi cung ứng và quy định, chế độ thất bại an toàn thay vì chạy theo trào lưu công nghệ.
10. Lưu ý và hàm ý
A. Thiết kế đồng thời tính mở và trách nhiệm tích hợp
Mở giao diện làm tăng quyền lựa chọn nhà cung cấp nhưng không làm biến mất trách nhiệm tích hợp. Ghi rõ trách nhiệm và phạm vi kiểm thử chung của nhà tích hợp hệ thống RAN, nhà cung cấp thiết bị, nhà cung cấp đám mây, nhà vận hành mạng truyền dẫn trong hợp đồng·RACI·SLA. Diễn tập leo thang để khi xảy ra sự cố, người thông báo đầu tiên và người chịu trách nhiệm giải quyết cuối cùng không bị lệch nhau.
B. Kiểm chứng hiệu năng đến điều kiện xấu nhất chứ không chỉ trung bình
Chỉ riêng throughput trung bình hay độ trễ trung bình không thể giải thích chất lượng mạng vô tuyến. Lập ngân sách hiệu năng bao gồm tải đỉnh, độ trễ phân vị 99, lệch đồng bộ, mất gói, di động, chuyển mạch sự cố và điều kiện nâng cấp phần mềm. Đánh giá bằng TCO xem tính linh hoạt thu được từ phân tách chức năng có lớn hơn chi phí mở rộng fronthaul và chi phí xử lý hay không.
C. Đặt giá trị mặc định an toàn cho tự động hóa của RIC
Tự động hóa dựa trên AI·chính sách giảm công việc lặp lại của người vận hành nhưng có thể lan truyền nhanh điều khiển sai. Giới hạn phạm vi điều khiển, tốc độ thay đổi, số cell áp dụng, giới hạn ảnh hưởng theo dịch vụ, và tự động thu hồi khi phát hiện data drift·suy giảm hiệu quả·lệnh bất thường. Bản thân tỷ lệ tự động hóa không phải là thành quả; thành quả phải là tỷ lệ công việc được tự động hóa một cách an toàn.
D. Quản lý bảo mật đa nhà cung cấp và chuỗi cung ứng trong toàn bộ vòng đời
Thành phần của Open RAN mở rộng ra phần cứng·phần mềm·đám mây·ứng dụng·mã nguồn mở·công cụ vận hành. Đưa SBOM, chữ ký, công bố lỗ hổng, vá·kết thúc hỗ trợ, thuê lại bên thứ ba, truy cập dữ liệu, cập nhật khẩn cấp vào điều kiện mua sắm và tiêu chuẩn vận hành. Để có thể thay nhà cung cấp, cũng cần điều khoản chuyển giao nhận lại dữ liệu·cấu hình·log ở định dạng chuẩn.
E. Bảo đảm đường cùng tồn tại·thu hồi với mạng hiện hữu
Không chuyển đổi toàn bộ mạng thương mại một lần mà kiểm chứng từng bước ở vùng mới và cell giới hạn. Chuẩn bị đường quay về mạng hiện hữu hoặc chức năng cơ bản cục bộ khi Open RAN sự cố, sao lưu cấu hình, tính liên tục tần số·xác thực, đào tạo người vận hành. Nếu khả năng chuyển đổi không có trong thiết kế thì ngay cả cấu trúc mở cũng có thể biến thành sự phụ thuộc mới.
F. Đo lường đồng thời giá trị kinh doanh và mục tiêu quy định·an toàn
Số nhà cung cấp hay số giao diện mở không phải là thành quả cuối cùng. So sánh với đường cơ sở sự thay đổi của chất lượng theo dịch vụ, vùng phủ, chi phí, năng lượng, tự động hóa, khả năng khôi phục, sự cố bảo mật và tuân thủ quy định, thời gian thay nhà cung cấp. Trong môi trường có ảnh hưởng an toàn như sản xuất·y tế·giao thông, thất bại an toàn và trách nhiệm có thể kiểm chứng có thể được ưu tiên hơn cải thiện hiệu năng.
Tài liệu tham khảo
- O-RAN Alliance, “O-RAN Specifications” — https://www.o-ran.org/specifications
- O-RAN Alliance, “60 New or Updated O-RAN Technical Documents Released since March 2025” — https://www.o-ran.org/blog/60-new-or-updated-o-ran-technical-documents-released-since-march-2025
- NTT DOCOMO, “Initiatives toward Intelligent RAN” — https://ssw.web.docomo.ne.jp/orex/en/technical/vol30_1_005en/
- O-RAN Alliance, “O-RAN Software Community” — https://www.o-ran.org/o-ran-software-community
- 3GPP, “3GPP Specifications” — https://www.3gpp.org/dynareport/SpecList.htm
Tóm tắt một câu: Open RAN là kiến trúc kết hợp phân tách RU·DU·CU với giao diện mở, ảo hóa và trí tuệ hóa RIC để nâng cao quyền lựa chọn nhà cung cấp và tự động hóa của RAN, và để thành công thực sự cần thiết kế đồng thời kiểm thử tương tác·đồng bộ thời gian·hiệu năng·bảo mật·trách nhiệm vận hành đa nhà cung cấp.