Skip to content

Các mô hình triển khai RAN

Cùng một kiến trúc logic gồm RU, DU và CU có thể được triển khai vật lý theo nhiều cách. Các tên gọi thường gặp như Distributed RAN, Centralized RAN, vRAN, Cloud RAN hay Open RAN thực ra trả lời những câu hỏi khác nhau, và một mạng thực tế là tổ hợp của nhiều lựa chọn. Trang này trình bày theo thứ tự: ba trục độc lập để phân loại một mô hình triển khai, các mô hình đặt baseband (D-RAN, C-RAN và mô hình lai), yêu cầu đối với fronthaul và midhaul ở từng mô hình, các cách hiện thực baseband (thiết bị chuyên dụng, vRAN, Cloud RAN) cùng hạ tầng và thách thức của Cloud RAN, bảng so sánh, rồi một số ví dụ triển khai. Các khối và functional split nằm ở RAN Architecture & Splits; phần cứng của DU và CU nằm ở Kiến trúc DU và CU.

Ba trục phân loại

Trục Câu hỏi Các lựa chọn
Vị trí đặt baseband DU và CU đặt ở đâu so với RU? Distributed RAN, Centralized RAN, mô hình lai
Cách hiện thực baseband DU và CU chạy trên phần cứng và phần mềm gì? Thiết bị chuyên dụng, vRAN, Cloud RAN
Mức độ mở của giao diện Các khối có thể đến từ nhiều nhà cung cấp không? Đơn nhà cung cấp, Open RAN (ví dụ theo đặc tả O-RAN)

Ba trục này độc lập với nhau. Một mạng có thể là C-RAN chạy trên thiết bị chuyên dụng của một nhà cung cấp; một mạng khác có thể là D-RAN với DU phần mềm (vRAN) và RU của nhà cung cấp khác (Open RAN). Chữ viết tắt "C-RAN" cũng dễ gây nhầm vì được dùng cho cả Centralized RAN lẫn Cloud RAN; trang này chỉ dùng C-RAN theo nghĩa Centralized RAN. Phân biệt giữa Open RAN, O-RAN và vRAN về mặt tổ chức và thị trường nằm ở O-RAN Alliance.

Vị trí đặt baseband

Ba mô hình đặt baseband: D-RAN, C-RAN và mô hình lai

D-RAN đặt đủ các khối tại mỗi site. C-RAN gom DU của nhiều site về một hub qua fronthaul. Mô hình lai giữ DU tại site và gom CU về điểm tập trung qua midhaul.

Distributed RAN

Ở Distributed RAN (D-RAN), mỗi site có đủ RU và phần baseband (DU và CU, hoặc BBU ở LTE). Site chỉ cần kết nối backhaul IP tới mạng lõi. Đây là mô hình phổ biến của 4G: BBU đặt trong tủ ở chân cột, nối với RRU trên cột bằng cáp quang CPRI ngắn. D-RAN đơn giản về truyền dẫn và không phụ thuộc vào cáp quang fronthaul đường dài, nhưng mỗi site phải có tủ, nguồn và làm mát cho baseband, và tài nguyên baseband của site này không dùng được cho site khác.

Centralized RAN

Ở Centralized RAN (C-RAN), site chỉ còn RU; DU của nhiều site được gom về một điểm tập trung (hub, đôi khi gọi là baseband hotel hoặc far edge), nối với RU qua fronthaul. Khái niệm này được China Mobile đưa ra trong white paper "C-RAN: The Road Towards Green RAN" (2011), dựa trên ba ý: xử lý tập trung, vô tuyến phối hợp và hạ tầng cloud thời gian thực, với mục tiêu giảm điện năng của mạng truy nhập.

Lợi ích của C-RAN:

  • Gom tài nguyên (pooling). Tải của các cell không đạt đỉnh cùng lúc, nên một pool DU dùng chung cần ít tài nguyên hơn tổng tài nguyên của các DU riêng lẻ định cỡ theo tải đỉnh của từng site.
  • Phối hợp giữa các cell. DU của các cell lân cận nằm chung một chỗ, nên các kỹ thuật cần trao đổi nhanh giữa cell như phối hợp nhiễu, carrier aggregation giữa các site hoặc truyền phối hợp nhiều điểm (CoMP) dễ hiện thực hơn.
  • Site đơn giản hơn. Site chỉ cần RU và nguồn cho RU, giảm diện tích thuê, điện năng làm mát và việc bảo trì tại chỗ.

Đổi lại, C-RAN cần cáp quang fronthaul có độ trễ thấp và băng thông lớn từ mỗi site về hub, và hub trở thành điểm hỏng chung của nhiều site.

Mô hình lai

Ở 5G, việc tách DU và CU tạo thêm một lựa chọn: DU đặt tại site hoặc ở hub gần site, CU (đặc biệt là CU-CP) gom về một điểm tập trung xa hơn, nối với DU qua midhaul F1. Vì F1 chịu được độ trễ lớn hơn nhiều so với fronthaul, CU có thể đặt ở trung tâm dữ liệu khu vực và phục vụ rất nhiều DU. CU-UP có thể đặt gần người dùng hoặc gần UPF tùy yêu cầu độ trễ của dịch vụ. Các vị trí đặt O-CU và O-DU trên hạ tầng cloud (cell site, edge cloud, regional cloud) được O-RAN WG6 mô tả thành các kịch bản triển khai, xem WG6.

Ngoài ba mô hình trên còn có trường hợp gNB tích hợp, trong đó RU, DU và CU nằm chung một thiết bị, thường gặp ở small cell trong nhà và mạng riêng quy mô nhỏ.

Yêu cầu đối với fronthaul và midhaul

Mô hình triển khai quyết định đoạn truyền dẫn nào dài và yêu cầu gì ở đoạn đó:

Đoạn Có ở mô hình Yêu cầu chính
Fronthaul (RU và DU) C-RAN (đường dài); D-RAN và lai (ngắn, trong site) Độ trễ một chiều cỡ 100 µs, jitter thấp, băng thông phụ thuộc split và số anten, đồng bộ thời gian chính xác
Midhaul F1 (DU và CU) Mô hình lai, C-RAN khi CU tách khỏi hub Độ trễ cỡ ms, băng thông bám theo lưu lượng người dùng
Backhaul (CU và mạng lõi) Mọi mô hình Mạng IP thông thường

Giới hạn khoảng cách của fronthaul đến từ ngân sách độ trễ. Ánh sáng trong sợi quang đi chậm hơn trong chân không theo chiết suất của sợi (khoảng 1,47), tức mất khoảng 5 µs cho mỗi km. Với lớp độ trễ High100 của eCPRI (100 µs một chiều cho hiệu năng NR đầy đủ, xem RAN Architecture & Splits), nếu dành toàn bộ ngân sách cho sợi quang thì khoảng cách tối đa vào khoảng 20 km; thực tế ngắn hơn vì còn độ trễ của switch, bộ ghép và xử lý ở hai đầu. Midhaul ở option 2 có giá trị độ trễ ví dụ 1,5 đến 10 ms theo TR 38.801, tương ứng với khoảng cách từ hàng chục tới hàng trăm km sau khi trừ độ trễ của thiết bị truyền dẫn.

Băng thông fronthaul là yếu tố thứ hai. Với split 8 (CPRI), băng thông tăng theo số anten và băng thông sóng mang, không phụ thuộc lưu lượng, nên C-RAN với massive MIMO qua CPRI gần như không khả thi. Split 7.2x của O-RAN giảm đáng kể băng thông fronthaul, là điều kiện để C-RAN khả thi ở 5G, xem Giới hạn băng thông của split 8. Ngoài ra, mạng fronthaul phải mang PTP và SyncE với độ chính xác thời gian theo các cấu hình LLS, xem Đồng bộ trong RAN.

Cách hiện thực baseband

Cách hiện thực Mô tả Hệ quả
Thiết bị chuyên dụng Baseband là phần cứng và phần mềm riêng của nhà cung cấp, dùng SoC hoặc ASIC thiết kế cho RAN Tối ưu điện năng và dung lượng; phần cứng và phần mềm gắn liền một nhà cung cấp
vRAN (virtualized RAN) Phần mềm DU, CU chạy trên server thông dụng (COTS), thường trong máy ảo, kèm accelerator Tách phần cứng khỏi phần mềm, dùng chung hạ tầng server; cần tinh chỉnh real-time cho DU
Cloud RAN vRAN theo kiểu cloud-native: chức năng RAN chia thành các thành phần chạy trong container, quản lý bằng nền tảng điều phối như Kubernetes Triển khai, mở rộng và cập nhật tự động như ứng dụng cloud; yêu cầu nền tảng cloud hỗ trợ real-time

Cách hiện thực độc lập với vị trí: vRAN có thể đặt tại site (D-RAN) hoặc ở hub (C-RAN). Tuy vậy, hai hướng thường đi cùng nhau, vì hub tập trung là nơi phù hợp để đặt cụm server và tận dụng khả năng gom tài nguyên của phần mềm. Cấu trúc server DU và các nền tảng phần cứng được trình bày ở Kiến trúc DU và CU.

vRAN và Cloud RAN

Ranh giới giữa vRAN và Cloud RAN không được định nghĩa chặt trong đặc tả; hai tên gọi thường được dùng lẫn cho nhau. Theo cách dùng phổ biến, vRAN nhấn mạnh việc ảo hóa chức năng RAN để chạy trên server thông dụng, còn Cloud RAN nhấn mạnh thêm cách xây dựng và vận hành phần mềm theo kiểu cloud-native:

vRAN (dạng máy ảo) Cloud RAN (cloud-native)
Đơn vị đóng gói Máy ảo, mỗi máy ảo có hệ điều hành riêng Container dùng chung kernel của host
Kiến trúc phần mềm Một hoặc vài khối lớn cho mỗi network function Chia thành nhiều thành phần nhỏ (microservice) có thể mở rộng riêng
Điều phối Hệ thống quản lý theo chuẩn ETSI NFV Kubernetes và các công cụ trong hệ sinh thái của nó
Cập nhật Thay cả máy ảo, thường cần dừng dịch vụ Cập nhật từng phần (rolling update), tự động hóa qua quy trình CI/CD
Giao diện O2dms của O-RAN Profile ETSI NFV Profile Kubernetes

Trong thực tế, một mạng có thể dùng cả hai: theo một số tài liệu triển khai, vRAN thường kết hợp máy ảo và container vì mức độ trưởng thành của cơ chế tăng tốc và cách ly real-time ở hai môi trường khác nhau. Với CU, vốn không có ràng buộc theo slot, chuyển sang cloud-native tương đối thuận lợi; với DU, các ràng buộc real-time ở mục dưới là thách thức chính.

Các thành phần nền

O-RAN WG6 đặc tả hạ tầng chung cho các network function của RAN chạy trên cloud:

Thành phần Vai trò
O-Cloud Hạ tầng gồm server, switch, accelerator và phần mềm quản lý, chạy O-CU, O-DU, Near-RT RIC
IMS và DMS Dịch vụ quản lý hạ tầng (kiểm kê, giám sát, cấp phát) và dịch vụ triển khai, quản lý vòng đời network function
Giao diện O2 Giữa SMO và O-Cloud: O2ims cho hạ tầng, O2dms cho triển khai network function
Acceleration Abstraction Layer (AAL) Giao diện chuẩn để phần mềm O-DU dùng accelerator mà không phụ thuộc nhà cung cấp
O-Cloud Notification API Cho O-DU đăng ký nhận sự kiện của hạ tầng, quan trọng nhất là trạng thái đồng bộ PTP

Chi tiết nằm ở WG6: Cloudification and Orchestration.

Thách thức khi chạy DU trên nền cloud-native

Nền tảng cloud được thiết kế cho ứng dụng chịu được trễ và chia sẻ tài nguyên linh hoạt, trong khi DU cần độ trễ ổn định ở mức µs và phần cứng đặc thù. Các điểm phải xử lý:

  • Cách ly CPU và real-time. Core chạy L1 và L2 phải được cấp riêng cho container của DU, cô lập khỏi tải khác và khỏi ngắt, trên kernel real-time, với bộ nhớ huge page và đặt đúng NUMA node.
  • Packet I/O cho fronthaul. Container của DU cần truy cập trực tiếp NIC qua SR-IOV và xử lý gói bằng DPDK, không qua network stack thông thường của container.
  • Đồng bộ thời gian. PTP chạy ở host phải được phân phối tới DU, và DU phải biết trạng thái khóa đồng bộ để ngừng phát khi mất đồng bộ, qua O-Cloud Notification API.
  • Accelerator. Card FEC hoặc GPU phải được cấp cho đúng container, và phần mềm DU nên dùng giao diện trừu tượng (AAL, DPDK BBDev) để không bị gắn với một loại phần cứng.
  • Cập nhật không gián đoạn. Cập nhật phần mềm DU làm mất các cell nó phục vụ; muốn cập nhật từng phần như ứng dụng cloud cần cơ chế chuyển cell hoặc chạy song song phiên bản cũ và mới.

Các nền tảng container cho Cloud RAN cung cấp các thành phần tự động hóa những cấu hình này, ví dụ quản lý PTP, SR-IOV và cô lập CPU dưới dạng operator của Kubernetes. Cách cấu hình cụ thể (cô lập CPU, SR-IOV, DPDK, PTP trong môi trường ảo hóa) thuộc tab Virtualization, xem vRAN trên VM, Real-time KVM tuning và isolcpus.

RAN trên cloud công cộng

Một biến thể của Cloud RAN là chạy chức năng RAN trên hạ tầng của nhà cung cấp cloud công cộng thay vì cloud riêng của nhà mạng. Ví dụ được nhắc tới nhiều nhất là DISH Wireless (Mỹ), công bố hợp tác với AWS năm 2021: theo kế hoạch công bố, CU và một phần mạng lõi chạy ở AWS Local Zones (cụm hạ tầng AWS ở các đô thị lớn), DU chạy trên AWS Outposts (phần cứng AWS đặt tại địa điểm của nhà mạng), workload dạng container được quản lý bằng Amazon EKS, và một phần xử lý DU chạy trên CPU Arm Graviton2. Cách bố trí này khớp với mô hình lai ở trên: DU ở far edge gần site, CU ở edge của cloud. Các thay đổi sau đó của DISH về phổ tần và mô hình kinh doanh được ghi ở O-RAN Alliance.

So sánh các mô hình đặt baseband

D-RAN C-RAN Lai (DU tại site, CU tập trung)
Thiết bị tại site RU, DU, CU Chỉ RU RU, DU
Truyền dẫn từ site Backhaul IP Fronthaul cáp quang độ trễ thấp Midhaul IP
Phụ thuộc cáp quang Thấp Cao: mỗi site cần fronthaul về hub trong phạm vi khoảng 20 km Trung bình
Gom tài nguyên baseband Không Có, ở mức DU và CU Có, ở mức CU
Phối hợp giữa các cell Qua giao diện X2/Xn Dễ nhất, DU chung một chỗ Ở mức CU
Điểm hỏng chung Từng site Hub phục vụ nhiều site Điểm tập trung CU
Thường gặp ở Mạng 4G truyền thống, vùng thiếu cáp quang Đô thị có sẵn hạ tầng cáp quang, một số nhà mạng châu Á Nhiều triển khai 5G vRAN và Open RAN

Lựa chọn thực tế phụ thuộc nhiều vào hạ tầng cáp quang sẵn có và chi phí thuê site, hơn là vào ưu thế kỹ thuật thuần túy. Một nhà mạng có thể dùng nhiều mô hình trong cùng một mạng: C-RAN ở đô thị có cáp quang, D-RAN ở vùng nông thôn.

Ví dụ triển khai

  • China Mobile đề xuất C-RAN từ 2010 và dẫn dắt C-RAN Alliance, tổ chức sau này hợp nhất với xRAN Forum thành O-RAN Alliance năm 2018.
  • Rakuten Mobile (Nhật Bản) triển khai mạng mới theo hướng vRAN cloud-native từ đầu; Verizon (Mỹ) triển khai vRAN quy mô lớn với Samsung. Chi tiết và nguồn nằm ở O-RAN Alliance.

Liên quan

Tài liệu tham khảo