EN-DC là chế độ gì của 5G
ChatGPT đã nói:
EN-DC (E-UTRAN New Radio - Dual Connectivity) là một chế độ trong mạng 5G, cụ thể là chế
độ triển khai non-standalone (NSA). Đây là một bước chuyển tiếp từ 4G sang 5G, cho phép
thiết bị tận dụng đồng thời cả mạng 4G LTE và 5G NR để cải thiện tốc độ và độ ổn định kết nối.
Cụ thể hơn:
EN-DC cho phép thiết bị kết nối cùng lúc tới một trạm gốc LTE (eNodeB) và một
trạm gốc 5G NR (gNodeB).
Thiết bị dùng LTE làm kênh điều khiển chính, còn 5G NR được dùng để truyền dữ
liệu với tốc độ cao hơn.
Đây là một phần của tiêu chuẩn 3GPP Release 15.
Ưu điểm của EN-DC:
Giúp các nhà mạng triển khai 5G nhanh hơn, tận dụng hạ tầng 4G hiện có.
Tăng tốc độ tải xuống cho người dùng nhờ dùng cả 4G và 5G cùng lúc.
Hữu ích trong giai đoạn đầu khi vùng phủ sóng 5G chưa đầy đủ.
Hạn chế:
Vì vẫn dựa vào mạng 4G nên chưa khai thác hết tiềm năng của 5G, như độ trễ thấp và
kết nối số lượng thiết bị lớn (như trong chế độ SA – Standalone).
Nếu bạn đang dùng điện thoại 5G và thấy báo hiệu "5G NSA" hoặc "EN-DC", thì tức là bạn
đang sử dụng kiểu kết nối này.
Bạn cần thêm thông tin kỹ thuật sâu hơn hay là đang muốn biết nó có ảnh hưởng gì đến trải
nghiệm sử dụng thực tế?
Bạn đã nói:
cái này tôi thấy không đúng một chỗ là tôi triển khau thì truyền dẫn backbone vẫn là của 4G thì
làm sao đạt tootcs độ cho 5g được
ChatGPT đã nói:
Bạn nói đúng một điểm rất quan trọng và thực tế – nếu truyền dẫn (transport/backhaul) vẫn là
của 4G thì EN-DC khó đạt được tốc độ tối ưu của 5G, và thậm chí hiệu năng tổng thể có thể
bị bottleneck (nghẽn cổ chai) tại phần backbone. Mình làm rõ thêm để bạn thấy bức tranh đầy
đủ hơn:
⚙️ EN-DC hoạt động thế nào?
Trong mô hình EN-DC:
LTE eNodeB là Master Node (MN) – điều khiển kết nối.
5G NR gNodeB là Secondary Node (SN) – dùng để truyền dữ liệu tốc độ cao.
Dữ liệu người dùng có thể đi qua cả 2 đường:
o Option 3x: Dữ liệu từ Core → LTE eNB → NR gNB → thiết bị.
o Option 3a: Dữ liệu đi riêng đến cả eNB và gNB (song song).
o Nhưng thường dùng Option 3x, tức là NR gNodeB phụ thuộc vào backbone của
eNodeB.
📉 Vấn đề khi backbone vẫn là 4G
Nếu backhaul từ LTE eNB không đủ băng thông, thì dữ liệu đổ về từ Core đến 5G
gNB cũng bị hạn chế theo băng thông của 4G, nhất là khi dùng Option 3x.
Trong thực tế triển khai (ở Việt Nam và nhiều nước đang phát triển):
o eNodeB dùng truyền dẫn cáp quang cũ (hoặc microwave) với giới hạn khoảng
1Gbps hoặc thấp hơn.
o Điều này trở thành nút thắt cổ chai, nên dù radio 5G NR có thể hỗ trợ tốc độ
hàng Gbps, nhưng dữ liệu vẫn bị giới hạn bởi năng lực truyền dẫn của
eNodeB.
Kết quả: Người dùng không cảm nhận được tốc độ 5G thực sự (dù icon hiện 5G), và
thực tế chỉ nhỉnh hơn 4G một chút.
✅ Giải pháp để tối ưu EN-DC
1. Nâng cấp truyền dẫn từ eNodeB:
o Chuyển sang cáp quang tốc độ cao (10G trở lên).
o Giảm phụ thuộc vào Option 3x, dùng Option 3a nếu có thể.
2. Triển khai 5G Standalone (SA):
o Loại bỏ phụ thuộc vào 4G.
o Thiết bị kết nối trực tiếp đến gNodeB và 5G Core (5GC).
o Tối ưu hóa latency, throughput, và dịch vụ mạng ảo hoá (network slicing).
Nếu bạn đang làm triển khai thực tế thì mình đoán bạn đang thấy rõ chuyện này rất đau đầu khi
nhà mạng kỳ vọng "có 5G" nhưng hạ tầng truyền dẫn thì chưa đủ tầm. Bạn đang triển khai ở khu
vực nào? Có gặp tình trạng nghẽn hoặc không đạt throughput kỳ vọng nhiều không? Mình có thể
hỗ trợ tư vấn kỹ thuật sâu hơn nếu bạn cần.
Bạn đã nói:
làm sao để biets nghẽn được nhỉ
ChatGPT đã nói:
Câu hỏi rất hay luôn! Để xác định có bị nghẽn ở truyền dẫn không (bottleneck ở backhaul),
bạn có thể dùng một số cách từ cả phía hệ thống (OSS/KPI) và thực địa (field test). Dưới đây là
các cách phổ biến mà anh em kỹ thuật mạng hay dùng:
� 1. Phân tích từ hệ thống – KPI & OSS
🔍 Nhìn vào các chỉ số từ eNodeB/gNodeB:
Throughput tại Cell vs Throughput tại UE:
o Nếu tổng DL throughput trên eNodeB thấp hơn khả năng radio, nhưng lại sát
với khả năng backhaul (ví dụ: chỉ khoảng 900 Mbps với link 1Gbps) ⇒ dấu hiệu
nghẽn.
o UE bắt sóng tốt, SINR tốt mà tốc độ tải thấp ⇒ nghi ngờ nghẽn backhaul.
🔍 Một số KPI cần theo dõi:
KPI
Average Cell
Throughput
PDCP vs MAC
Throughput
Buffer Occupancy
Packet Delay
Packet Drop Rate
Ý nghĩa
Dấu hiệu nghẽn
Nếu cao sát trần backhaul thì có thể bị
Tổng throughput trung bình
nghẽn
So sánh giữa tầng cao và
Nếu PDCP cao mà MAC thấp → nghẽn
tầng thấp
truyền dẫn
Buffer cao thường xuyên → truyền dẫn
Mức độ đầy của buffer
không xả kịp
Độ trễ gói tin giữa Core –
Độ trễ tăng bất thường ở giờ cao điểm
eNB/gNB
Nếu không do radio → nghi do nghẽn
Tỷ lệ rớt gói
transport
� 2. Kiểm tra thực địa (Field Test)
Dùng công cụ đo (VD: TEMS, Nemo, hoặc điện thoại test với app chuyên dụng):
Đứng gần site, sóng khỏe (RSRP > -80 dBm, SINR > 20 dB) mà:
o Tốc độ tải xuống rất thấp (dưới 100 Mbps) → nghi ngờ nghẽn.
o Tốc độ không ổn định, giật lag, đặc biệt giờ cao điểm → rất có thể nghẽn
backhaul.
So sánh giữa nhiều site:
Nếu site A dùng cùng thiết bị, cùng tần số mà tốc độ cao hơn site B ⇒ có thể B bị nghẽn
truyền dẫn.
Đặc biệt các site dùng microwave hoặc chưa có truyền dẫn quang mạnh.
� 3. Kiểm tra truyền dẫn trực tiếp
Nếu có quyền truy cập vào phần truyền dẫn:
Ping hoặc traceroute từ eNodeB đến 4G/5G Core → kiểm tra độ trễ.
Đo throughput thực tế của link (bằng công cụ như iPerf).
Check lỗi trên port quang, jitter, packet loss.
📌 Kết luận
Muốn chắc chắn có nghẽn không, nên:
1. So sánh KPI giữa radio (RSRP, SINR) và dữ liệu.
2. Kết hợp đo thực tế ở hiện trường.
3. Kiểm tra tải trên đường truyền của eNodeB/gNodeB.
Nếu bạn đang triển khai ở hiện trường, mình có thể giúp bạn xây kịch bản test luôn – ví dụ: test
song song ở 4G và EN-DC để so sánh throughput, hay hướng dẫn phân tích log TEMS/Nemo
nếu bạn có file.
Bạn đang dùng hệ thống vendor nào vậy? Ericsson, Huawei, Nokia, ZTE? Vì mỗi vendor sẽ có
cách export KPI khác nhau.
Bạn đã nói:
hãy hưỡng dẫn phân tích log Tém
ChatGPT đã nói:
Ok! Mình hướng dẫn bạn cách phân tích log TEMS Investigation để xác định xem có bị nghẽn
truyền dẫn trong mạng EN-DC (NSA 5G) không nhé. Chủ yếu bạn sẽ quan tâm đến:
Tốc độ thực tế (Throughput)
Chất lượng sóng (RSRP, SINR)
Tầng truyền dẫn (PDCP, RLC, MAC)
Buffer, retransmission, delay
Kết nối EN-DC có được kích hoạt không
✅ BƯỚC 1: CHUẨN BỊ LOG TEMS
Sử dụng TEMS Investigation (thường từ bản 20.x trở lên có hỗ trợ 5G NSA).
Ghi log tại khu vực test:
o Nên dùng thiết bị hỗ trợ EN-DC (điện thoại test có 5G NSA).
o Bắt đầu ghi log từ lúc chưa có kết nối → bật dữ liệu → vào các app để tạo lưu
lượng tải xuống.
o Có thể dùng speedtest, FTP download, video streaming để tạo traffic.
✅ BƯỚC 2: MỞ LOG & XEM THÔNG SỐ CƠ BẢN
💡 Các tab chính bạn cần mở:
Tab
Mục đích
Serving + Neighbor Cells
Để xem chất lượng sóng LTE + 5G
NR Events
Kiểm tra có kích hoạt EN-DC không
Data Session Info / IP Throughput Xem tốc độ thật của download/upload
Layer Info
Đào sâu vào các tầng PDCP / RLC / MAC
Protocol Messages
Bắt message RRC nếu cần tra kỹ
✅ BƯỚC 3: PHÂN TÍCH CHI TIẾT
� 1. Kiểm tra kết nối EN-DC có kích hoạt không
Vào tab NR Events hoặc RRC Messages:
o Tìm sự kiện "NR Secondary Cell Added" hoặc "EN-DC Activated".
o Tìm xem có message RRC Reconfiguration với thông tin SCG Configuration.
➡️ Nếu không có => thiết bị chưa kết nối 5G NR (chỉ đang ở LTE).
� 2. Kiểm tra chất lượng sóng
LTE:
o
o
RSRP ≥ -90 dBm
SINR ≥ 10 dB
5G:
o
o
SS-RSRP ≥ -90 dBm
SS-SINR ≥ 5~10 dB
➡️ Nếu sóng tốt mà tốc độ thấp => nghi ngờ nghẽn phía sau (thường là truyền dẫn).
� 3. Xem Throughput ở các tầng
Vào Layer Info → Data throughput → chọn PDCP, RLC, MAC:
Tầng
Ý nghĩa
Dấu hiệu nghẽn
Nếu cao mà các tầng dưới thấp → nghẽn
PDCP Gần với ứng dụng
RLC Trung gian, kiểm soát lỗi Có thể nhìn thấy lượng retransmit
Thấp hơn nhiều so với PDCP → nghi truyền dẫn bị giới hạn
MAC Tầng vật lý
➡️ Nếu:
PDCP = 100 Mbps
MAC chỉ 20 Mbps → Bị nghẽn ở đâu đó (có thể do backhaul).
� 4. Xem retransmission và buffer
Tab Layer Info → RLC Statistics:
o Retransmission rate cao → có vấn đề.
o Buffer size cao liên tục → hệ thống không xả kịp data (nghẽn).
� 5. So sánh 4G Only vs EN-DC
Bạn có thể so sánh log ở cùng một vị trí:
o Một lần bật 5G → chạy test (EN-DC)
o Một lần tắt 5G → chỉ 4G
So sánh RSRP/SINR vs Throughput, giúp xác định 5G có thật sự mang lại lợi ích hay
không.
🎯 GỢI Ý NHẬN BIẾT NGHẼN TRUYỀN DẪN
RSRP/SINR tốt, nhưng Throughput thấp.
PDCP throughput cao, MAC thấp.
Retransmission nhiều ở tầng RLC.
Buffer tại UE hoặc gNodeB cao liên tục.
Tốc độ 5G không hơn 4G bao nhiêu dù sóng tốt.
Nếu bạn có sẵn log TEMS, bạn có thể gửi mình (dưới dạng export .log hoặc ảnh chụp màn hình
các chỉ số mình nói trên), mình giúp bạn phân tích chi tiết hơn. Bạn đang dùng TEMS bản bao
nhiêu vậy? Và log từ thiết bị nào (Samsung, Xiaomi, hoặc Qualcomm dongle)?
Bạn đã nói:
mình không có log file mình đang học phân tích 5G bạn có tài liệu nào hữu dụng cho RNO
engineer tối ưu 4G và 5G không
ChatGPT đã nói:
Nếu bạn đang học và muốn nâng cao kỹ năng phân tích và tối ưu hóa mạng 4G/5G, đặc biệt là
trong vai trò RNO Engineer, dưới đây là một số tài liệu và khóa học hữu ích giúp bạn hiểu sâu
hơn về lý thuyết, công cụ thực hành và kỹ thuật tối ưu hóa mạng.
📘 Tài liệu và khóa học hữu ích cho RNO Engineer
1. Khóa học trên Udemy: "Learn 5G (NR) NSA/EN-DC from basics to KPIs
optimization!"
Nội dung: Khóa học này cung cấp kiến thức cơ bản về kiến trúc Non-Standalone (NSA)
của 5G, cấu hình EN-DC, và tối ưu hóa các chỉ số hiệu suất mạng (KPIs) như tỷ lệ thành
công khi thiết lập EN-DC, tỷ lệ thành công RACH, và tốc độ truyền tải.
Phù hợp cho: Kỹ sư RAN, RF, và RNO đang chuyển sang hoặc làm việc với 5G NSA.
Link: Khóa học trên UdemyUdemy
2. Khóa học trên Udemy: "5G Optimization Basics"
Nội dung: Khóa học này bao gồm tối ưu hóa tham số chuyển giao (handover), mô hình
lan truyền, ngân sách liên kết (link budget), và các sự kiện đo lường NR trong mạng 5G.
Phù hợp cho: Những người chuyên về tối ưu hóa mạng và những ai muốn nâng cao kỹ
năng trong lĩnh vực này.
Link: Khóa học trên Udemy
3. Khóa học trên 5GWorldPro: "5G KPI, 5G Optimization & 5G
Troubleshooting Training"
Nội dung: Khóa học này cung cấp cái nhìn sâu sắc về các chỉ số hiệu suất mạng 5G, quy
trình gọi thực tế, các vấn đề tối ưu hóa 5G trong thực tế và kỹ thuật khắc phục sự cố.
Phù hợp cho: Những ai muốn nâng cao kiến thức và kỹ năng trong quản lý và tối ưu hóa
mạng 5G.
Link: Khóa học trên 5GWorldPro
4. Khóa học trên Apis Training: "5G RAN Optimization"
Nội dung: Khóa học này cung cấp cái nhìn tổng quan về giám sát hiệu suất RAN 5G và
tối ưu hóa mạng, bao gồm phân tích các lớp tín hiệu, tối ưu hóa thông số RACH, và tối
ưu hóa di động trong mạng 5G.
Phù hợp cho: Những ai muốn hiểu sâu hơn về tối ưu hóa mạng RAN 5G.
Link: Khóa học trên Apis Training
5. Khóa học trên Qualcomm Academy: "5G NR Technical Training"
Nội dung: Khóa học này cung cấp kiến thức về kiến trúc mạng 5G, mmWave,
beamforming, MIMO, lớp vật lý NR, và các lớp trên NR.
Phù hợp cho: Kỹ sư muốn làm việc với công nghệ 5G và nâng cao kỹ năng trong lĩnh
vực này.
Link: Khóa học trên Qualcomm Academyacademy.qualcomm.com
� Công cụ và tài liệu hỗ trợ phân tích mạng
TEMS Investigation: Công cụ mạnh mẽ để thu thập và phân tích dữ liệu từ mạng di
động, hỗ trợ việc phân tích log và tối ưu hóa mạng.
Nemo Outdoor: Công cụ đo lường và phân tích mạng di động, hỗ trợ việc thu thập dữ
liệu thực tế từ hiện trường.
Qualcomm QXDM/QCAT: Công cụ phân tích log và kiểm tra mạng, hữu ích trong việc
phân tích sâu về hiệu suất mạng.
Tài liệu 3GPP: Các tiêu chuẩn và tài liệu kỹ thuật từ 3GPP cung cấp cái nhìn chi tiết về
các công nghệ và giao thức trong mạng 5G.
Nếu bạn cần hỗ trợ thêm về cách sử dụng các công cụ trên hoặc muốn tìm hiểu sâu hơn về một
chủ đề cụ thể trong tối ưu hóa mạng 4G/5G, hãy cho mình biết nhé!
Nguồn
Bạn đã nói:
giải thích cho tôi mấy cái PDCP MAC với RLC nó là cái gì tôi chả hiểu gì cả
ChatGPT đã nói:
Chắc chắn rồi! Để giải thích về PDCP, MAC, và RLC, mình sẽ làm rõ từng cái và cách chúng
hoạt động trong mạng di động 4G/5G. Đây là những thành phần quan trọng trong lớp truyền
tải (Layer 2) và lớp ứng dụng (Layer 3) trong mô hình mạng LTE và 5G.
1. PDCP (Packet Data Convergence Protocol)
Chức năng: PDCP hoạt động ở tầng Lớp 2 và Lớp 3 trong mô hình OSI (Layer 2 - Data
Link Layer, Layer 3 - Network Layer).
Mục đích:
o Nén dữ liệu: PDCP nén dữ liệu để giảm băng thông khi truyền tải, giúp tiết kiệm
tài nguyên mạng.
o Mã hóa và giải mã: PDCP chịu trách nhiệm mã hóa và giải mã dữ liệu khi truyền
trong mạng để đảm bảo bảo mật.
o Quản lý chuyển tiếp gói tin: PDCP đảm bảo các gói tin có thể được chuyển tiếp
chính xác qua mạng, đặc biệt trong các mạng vô tuyến di động, giúp giảm thiểu
lỗi trong quá trình truyền.
Chức năng chính:
o Header Compression: Nén phần header của gói tin để tiết kiệm băng thông.
o Security: Mã hóa và giải mã dữ liệu.
o In-sequence delivery: Đảm bảo rằng các gói tin đến được đúng thứ tự.
2. RLC (Radio Link Control)
Chức năng: RLC hoạt động ở Layer 2 của mô hình OSI và được sử dụng trong các
mạng di động LTE và 5G.
Mục đích:
o Đảm bảo độ tin cậy trong việc truyền tải dữ liệu qua kênh vô tuyến.
o RLC đảm bảo rằng dữ liệu được truyền từ tầng cao (tầng PDCP) đến tầng MAC
mà không bị mất mát hoặc trễ.
Chức năng chính:
o
o
o
Segmentation & Reassembly: Chia nhỏ gói dữ liệu lớn từ tầng PDCP thành các
phần nhỏ để có thể truyền qua kênh vô tuyến (vì kênh vô tuyến có kích thước gói
tin giới hạn). Sau đó, RLC sẽ ghép các phần nhỏ này lại ở đầu cuối để phục hồi
gói dữ liệu ban đầu.
ARQ (Automatic Repeat Request): Nếu gói tin bị mất trong quá trình truyền tải,
RLC yêu cầu gửi lại gói tin đó để đảm bảo không có dữ liệu bị mất.
Buffering: Tạm thời lưu trữ dữ liệu để xử lý khi có sự cố hoặc điều kiện kênh
mạng thay đổi.
3. MAC (Medium Access Control)
Chức năng: MAC là tầng Lớp 2 trong mô hình OSI, và nó quản lý cách thức sử dụng
kênh vô tuyến để gửi và nhận dữ liệu.
Mục đích:
o Quản lý truy cập kênh: MAC chịu trách nhiệm điều khiển việc truy cập vào
kênh vô tuyến, tức là quyết định khi nào và ai sẽ truyền tải dữ liệu trên kênh vô
tuyến.
o Điều khiển luồng và chất lượng dịch vụ (QoS): MAC giúp đảm bảo rằng mạng
có thể cung cấp các dịch vụ có chất lượng khác nhau (ví dụ: truyền tải thoại,
video, hoặc dữ liệu).
Chức năng chính:
o Scheduling: Lên lịch cho các cuộc gọi hoặc kết nối dữ liệu, quyết định thời gian
và tài nguyên mạng nào sẽ được cấp cho từng người dùng.
o Multiplexing: Truyền tải nhiều dòng dữ liệu cùng lúc trên cùng một kênh vô
tuyến, giúp tận dụng tối đa băng thông.
o Error Control: Cung cấp kiểm tra lỗi cơ bản trong quá trình truyền tải và thông
báo cho các tầng cao hơn nếu có sự cố.
Tóm tắt mối quan hệ giữa PDCP, RLC và MAC:
1. PDCP:
o
o
o
Xử lý dữ liệu từ ứng dụng.
Mã hóa, giải mã và nén dữ liệu.
Chuyển dữ liệu xuống tầng RLC.
2. RLC:
o
o
o
Chia nhỏ dữ liệu thành các gói con để truyền qua kênh vô tuyến.
Đảm bảo truyền tải tin cậy với ARQ và điều khiển lưu lượng.
Chuyển dữ liệu xuống tầng MAC.
3. MAC:
o
o
o
Quản lý việc truy cập vào kênh vô tuyến.
Lên lịch và điều phối các gói dữ liệu cho các thiết bị.
Đảm bảo chất lượng dịch vụ (QoS) cho các loại dịch vụ khác nhau.
Cách hoạt động chung:
1. Dữ liệu từ ứng dụng (ví dụ: video, web) đi từ tầng ứng dụng lên tầng PDCP.
2. PDCP mã hóa, nén và gửi dữ liệu xuống tầng RLC.
3. RLC chia nhỏ dữ liệu nếu cần thiết, đảm bảo độ tin cậy và chuyển tiếp dữ liệu xuống
tầng MAC.
4. MAC lên lịch và truyền dữ liệu qua kênh vô tuyến tới người dùng.
Ví dụ thực tế:
Khi bạn xem video trực tuyến trên điện thoại:
o Dữ liệu video sẽ đi qua tầng PDCP (để mã hóa và nén).
o Sau đó, dữ liệu này sẽ được gửi qua tầng RLC (để chia nhỏ gói video và bảo đảm
độ tin cậy).
o Cuối cùng, MAC sẽ quyết định khi nào dữ liệu sẽ được gửi qua sóng di động để
bạn có thể xem video mượt mà.
Hy vọng mình đã giải thích rõ ràng hơn về các tầng PDCP, RLC và MAC! Nếu có bất kỳ câu hỏi
nào thêm về cơ chế hoạt động của chúng, hoặc bạn muốn tìm hiểu sâu hơn về một phần nào đó,
cứ thoải mái hỏi nhé!
Bạn đã nói:
vậy tầng nào thuộc truyền dẫn backhaul để biết nghẽn
ChatGPT đã nói:
Câu hỏi của bạn rất hay! Để xác định nghẽn truyền dẫn backhaul, ta cần phải hiểu rõ hơn về
các tầng truyền dẫn trong mạng di động và cách chúng hoạt động. Backhaul là phần của mạng
di động giúp kết nối các trạm phát sóng (eNodeB/gNodeB) với core network, và trong quá trình
truyền tải từ eNodeB/gNodeB về core network, có một số tầng có thể ảnh hưởng đến tốc độ và
chất lượng truyền tải.
🏗️ Các tầng liên quan đến truyền dẫn backhaul trong mạng di động:
1. Tầng PHY (Physical Layer)
Chức năng: Tầng này liên quan trực tiếp đến truyền dẫn dữ liệu qua sóng vô tuyến (radio
waves), và đây là tầng cuối cùng trước khi tín hiệu được gửi qua backhaul (truyền dẫn từ
trạm gốc đến core network).
Ảnh hưởng đến nghẽn:
o Nếu chất lượng sóng yếu (RSRP thấp, SINR thấp) trên link vô tuyến, sẽ dẫn đến
việc truyền dẫn dữ liệu qua backhaul không ổn định hoặc không đạt tốc độ tối
đa.
o Tầng PHY rất quan trọng, nhưng nếu tín hiệu vô tuyến ổn định và tốt rồi, nghẽn
truyền dẫn backhaul không phải do vấn đề ở PHY nữa.
2. Tầng MAC (Medium Access Control)
Chức năng: Tầng MAC quản lý việc truy cập vào kênh vô tuyến (cũng bao gồm cả cách
thức sử dụng backhaul), giúp tổ chức dữ liệu vào các gói và quyết định khi nào gói dữ
liệu sẽ được gửi.
Ảnh hưởng đến nghẽn:
o Nếu quá tải ở tầng MAC, có thể gây ra truyền tải không hiệu quả hoặc nghẽn
băng thông trên backhaul.
o MAC Scheduler sẽ phân phối tài nguyên cho các thiết bị theo lịch trình. Nếu
backhaul không đủ băng thông để tải tất cả lưu lượng, tầng MAC có thể là
nguyên nhân gây nghẽn, bởi vì nó là nơi quyết định có thể chặn hoặc điều chỉnh
dữ liệu.
3. Tầng RLC (Radio Link Control)
Chức năng: Tầng RLC chịu trách nhiệm đảm bảo việc truyền dữ liệu tin cậy, đặc biệt là
khi phải xử lý các lỗi trong quá trình truyền (như mất gói, trễ, hoặc lỗi truyền tải).
Ảnh hưởng đến nghẽn:
o Nếu có quá nhiều retransmission hoặc buffering trong tầng RLC, điều này có
thể chỉ ra rằng dữ liệu không thể được truyền đi kịp thời và dữ liệu không được
gửi qua backhaul hiệu quả.
o RLC Retransmissions có thể làm giảm tốc độ và làm chậm truyền tải qua
backhaul, gây nghẽn nếu backhaul không đủ mạnh để chịu tải.
4. Tầng PDCP (Packet Data Convergence Protocol)
Chức năng: Tầng PDCP xử lý các vấn đề như nén dữ liệu, mã hóa và giải mã, và đóng
vai trò trong việc tối ưu hóa dữ liệu trước khi nó được chuyển tiếp vào tầng RLC.
Ảnh hưởng đến nghẽn:
o Nếu tầng PDCP phải xử lý quá nhiều dữ liệu (đặc biệt là khi có mã hóa hoặc nén)
nhưng không có đủ tài nguyên backhaul để truyền tải, sẽ gây ra sự chậm trễ trong
việc truyền tải dữ liệu qua backhaul.
o
Tuy nhiên, PDCP không trực tiếp gây nghẽn backhaul mà chỉ làm tăng độ phức
tạp của dữ liệu trước khi truyền.
Backhaul (Truyền dẫn mạng) - Liên quan đến các tầng mạng ngoài eNB/gNB:
Truyền dẫn từ eNB/gNB đến core network:
o Backhaul là phần của mạng kết nối eNodeB/gNodeB với core network, có thể sử
dụng cáp quang, microwave, hoặc xử lý qua IP/MPLS.
o Backhaul hoạt động ở tầng Lớp 2 và Lớp 3 của OSI model (Data Link Layer và
Network Layer), nơi mà dữ liệu được chuyển tiếp từ trạm gốc (eNodeB/gNodeB)
về core network.
Các dấu hiệu nghẽn ở Backhaul
1. Tốc độ truyền tải giảm đột ngột:
Nếu bạn thấy tốc độ download/upload thấp mà chất lượng sóng (RSRP, SINR) ổn, có
thể backhaul không đủ băng thông để tải lưu lượng.
2. Lỗi mất gói tin:
Nếu có tỷ lệ mất gói tin cao hoặc trễ lớn trong quá trình truyền, có thể backhaul bị
nghẽn hoặc không thể xả dữ liệu kịp thời.
3. Mất kết nối hoặc gián đoạn dịch vụ:
Khi backhaul quá tải, dịch vụ mạng có thể gặp phải gián đoạn hoặc ngắt kết nối
thường xuyên.
4. Độ trễ cao:
Độ trễ cao trong quá trình truyền tải dữ liệu từ eNodeB/gNodeB đến core network có thể
chỉ ra rằng backhaul không đủ tốc độ để xử lý tất cả các gói dữ liệu.
Tóm lại:
Truyền dẫn backhaul ảnh hưởng đến tầng MAC, RLC và tầng PHY, với tầng MAC
có liên quan trực tiếp đến việc quản lý và lên lịch sử dụng tài nguyên cho backhaul.
Tầng RLC và PDCP có thể làm giảm hiệu suất của backhaul nếu có quá nhiều lỗi
retransmission hoặc xử lý dữ liệu phức tạp.
Nghẽn backhaul có thể được nhận diện qua tốc độ giảm, độ trễ cao, và mất kết nối.
Nếu bạn muốn kiểm tra chi tiết về nghẽn backhaul, bạn có thể phân tích log mạng để xem các
thông số như throughput, delay, retransmission, và tỷ lệ mất gói để xác định vấn đề nằm ở
đâu.
Hy vọng giúp bạn làm rõ được vấn đề! Nếu có thêm câu hỏi nào, cứ thoải mái hỏi nhé!
Bạn đã nói:
retranmission thế nào là nhiều
ChatGPT đã nói:
Retransmission (truyền lại) trong mạng di động là quá trình mà khi một gói tin bị mất hoặc
không được nhận đúng, nó sẽ được yêu cầu gửi lại từ nguồn (trong trường hợp của RLC hoặc
MAC). Sự retranstmission này có thể xảy ra vì nhiều lý do, ví dụ như sự can thiệp sóng
(interference), tín hiệu yếu hoặc lỗi kênh truyền.
Khi bạn nói đến retranstmission nhiều, có nghĩa là tỷ lệ retransmission này đang vượt mức
chấp nhận được và gây ảnh hưởng đến hiệu suất mạng. Tuy nhiên, việc xác định
retranstmission nhiều như thế nào phụ thuộc vào một số yếu tố cụ thể như loại dịch vụ, chất
lượng kênh truyền, và môi trường mạng.
Các yếu tố quyết định retranstmission nhiều:
1. Tỷ lệ retransmission (%):
o Tỷ lệ retransmission là tỷ lệ gói tin yêu cầu truyền lại so với tổng số gói tin được
gửi. Nếu tỷ lệ retransmission quá cao, điều đó có thể cho thấy có vấn đề trong
mạng hoặc kênh vô tuyến.
Ví dụ:
Tỷ lệ retransmission > 5%: Đây thường là mức mà các kỹ sư mạng sẽ xem là
cảnh báo. Nếu tỷ lệ retransmission vượt mức này, nó có thể gây ra độ trễ cao,
giảm hiệu suất và chất lượng dịch vụ.
o Tỷ lệ retransmission < 1%: Là mức tốt, không có nhiều gói tin bị mất hoặc cần
phải truyền lại.
2. Tầng nào xảy ra retransmission?
o Tầng RLC: Nếu tầng RLC phải thực hiện quá nhiều ARQ (Automatic Repeat
reQuest), có thể chỉ ra rằng tín hiệu vô tuyến không ổn định, dẫn đến việc mất
gói hoặc lỗi trong việc truyền tải.
o Tầng MAC: Retransmission ở tầng MAC thường do vấn đề trong việc chia sẻ tài
nguyên kênh, khi các thiết bị cạnh tranh tài nguyên để truyền dữ liệu.
3. Độ trễ và tải lượng mạng:
o
Retransmission nhiều có thể dẫn đến độ trễ tăng và băng thông giảm. Đặc biệt
trong các dịch vụ như video hoặc thoại, việc retransmission nhiều có thể làm giảm
trải nghiệm người dùng.
4. Điều kiện vô tuyến:
o Trong các điều kiện kênh vô tuyến yếu (RSRP thấp hoặc SINR thấp), việc
retransmission nhiều là một hiện tượng phổ biến. Khi có nhiều lỗi kênh, nhiều
gói tin không đến được đích, và phải yêu cầu truyền lại.
o
Khi nào được coi là "quá nhiều" retransmission?
Tỷ lệ retransmission của RLC:
o Mức bình thường: < 1% là mức tỷ lệ retransmission mà các mạng di động
thường mong muốn.
o Cảnh báo: 1% - 5% cho thấy có vấn đề trong việc truyền tải, có thể do nhiễu
sóng hoặc cấu hình mạng không tối ưu.
o Vấn đề nghiêm trọng: > 5%: Tỷ lệ retransmission vượt mức này có thể ảnh
hưởng nghiêm trọng đến hiệu suất mạng và trải nghiệm người dùng. Điều này cần
được kiểm tra và xử lý ngay lập tức.
Lỗi và retransmission ở MAC:
o Retransmission nhiều ở MAC có thể do việc sử dụng tài nguyên không hiệu quả
hoặc các vấn đề trong việc điều phối tài nguyên vô tuyến. Khi quá nhiều gói tin
bị mất và phải yêu cầu truyền lại, điều này có thể chỉ ra rằng có nghẽn ở tầng
MAC hoặc quá tải băng thông ở backhaul.
Cách kiểm tra retransmission trong mạng 4G/5G:
Để kiểm tra và xác định retransmission nhiều, bạn có thể sử dụng các công cụ giám sát và phân
tích log mạng như TEMS Investigation, Nemo Outdoor, hoặc Qualcomm QXDM/QCAT để
đo lường tỷ lệ retransmission trong các tầng khác nhau của mạng (RLC, MAC).
Thông số cần kiểm tra:
o RLC Retransmissions: Số lượng và tỷ lệ retransmission ở tầng RLC.
o MAC Retransmissions: Tỷ lệ retransmission ở tầng MAC và các gói tin bị mất.
o Trễ truyền tải: Kiểm tra độ trễ trong quá trình truyền dữ liệu và xem liệu có sự
trì hoãn do retransmission hay không.
Giảm thiểu retransmission:
1. Cải thiện chất lượng kênh vô tuyến: Đảm bảo rằng mức RSRP và SINR đủ mạnh để
truyền tải ổn định.
2. Điều chỉnh cấu hình mạng: Kiểm tra các tham số CQI (Channel Quality Indicator) và
MCS (Modulation and Coding Scheme) để tối ưu hóa việc sử dụng tài nguyên vô tuyến.
3. Điều chỉnh lại tài nguyên MAC: Lên lịch truyền tải hợp lý để tránh tình trạng tắc nghẽn
tài nguyên.
4. Kiểm tra backhaul: Đảm bảo rằng backhaul không bị nghẽn, vì việc nghẽn backhaul có
thể dẫn đến độ trễ và retransmission nhiều ở các tầng trên.
Tóm lại:
Retransmission nhiều là khi tỷ lệ retransmission vượt quá mức bình thường (thường > 1%), gây
ảnh hưởng đến hiệu suất mạng. Khi tỷ lệ retransmission tăng cao, bạn cần xác định nguyên nhân
(ví dụ: tín hiệu yếu, nghẽn tài nguyên mạng) và thực hiện các biện pháp cải thiện chất lượng
mạng để giảm thiểu vấn đề này.
Nếu bạn có thêm câu hỏi nào hoặc cần hỗ trợ về việc kiểm tra retransmission trong mạng của
bạn, cứ thoải mái hỏi nhé!
Bạn đã nói:
trong tối ưu 5G với 4G khi drive test và phân tích bằng tems discovery làm sao tôi biết nhiễu ở
khu vực nào và nguyên nhân do đâu
ChatGPT đã nói:
Khi tối ưu mạng 5G và 4G qua Drive Test và phân tích bằng TEMS Discovery, việc xác định
nhiễu (interference) trong khu vực và tìm nguyên nhân chính xác là một phần rất quan trọng
trong quá trình phân tích. Đây là cách bạn có thể thực hiện để xác định và giải quyết vấn đề
nhiễu:
1. Thu thập dữ liệu Drive Test bằng TEMS Discovery
Để phân tích nhiễu, bạn cần thu thập các thông số quan trọng trong quá trình drive test. Các
thông số này sẽ giúp bạn xác định các khu vực có vấn đề nhiễu.
RSRP (Reference Signal Received Power): Chỉ ra mức công suất của tín hiệu tham
chiếu. Một RSRP thấp có thể cho thấy tín hiệu yếu, và có thể là dấu hiệu của nhiễu
mạnh hoặc tín hiệu yếu trong khu vực đó.
SINR (Signal-to-Interference-plus-Noise Ratio): Chỉ số này giúp bạn đánh giá chất
lượng tín hiệu so với nhiễu và can thiệp. SINR thấp có thể chỉ ra rằng tín hiệu bị nhiễu
quá mức từ các nguồn khác.
RSRQ (Reference Signal Received Quality): Đo chất lượng tín hiệu. Một RSRQ thấp
có thể cho thấy nhiễu và tạp âm trong kênh truyền.
CQI (Channel Quality Indicator): Đánh giá chất lượng của kênh truyền. CQI thấp có
thể chỉ ra tín hiệu kém hoặc nhiễu.
PCI (Physical Cell Identity): PCI giúp xác định cell ID. Nếu bạn thấy các tế bào (cell)
có PCI trùng lặp hoặc bị can thiệp vào nhau, có thể đó là dấu hiệu của nhiễu.
2. Xác định khu vực có nhiễu từ dữ liệu Drive Test
Sau khi thu thập dữ liệu từ drive test, bạn sẽ bắt đầu phân tích những khu vực có dấu hiệu nhiễu.
Các bước sau đây giúp bạn nhận diện chính xác:
Phân tích SINR và RSRP
SINR thấp (thường < 10 dB): Nếu trong khu vực có SINR thấp, có thể có vấn đề với
nhiễu từ các tế bào khác hoặc nhiễu vô tuyến (co-channel interference). Bạn cần xem
liệu kênh tần số có bị trùng lặp với các tế bào khác không.
RSRP thấp: Nếu RSRP thấp, tín hiệu từ trạm gốc có thể yếu, có thể do khoảng cách xa,
hoặc môi trường bị chắn sóng (nhiễu do vật cản, như tòa nhà, cây cối, v.v.).
Phân tích RSRQ
RSRQ thấp: Nếu RSRQ thấp, đó là dấu hiệu của sự can thiệp mạnh từ các tín hiệu khác
(nhiễu). Khu vực có RSRQ thấp cần được kiểm tra để xác định nguồn nhiễu.
Vùng nhiễu từ PCI
Trùng PCI: Trong mạng LTE hoặc 5G, mỗi tế bào có một PCI (Physical Cell Identity)
duy nhất. Nếu bạn phát hiện PCI trùng lặp hoặc can thiệp giữa các cell ở khu vực bạn
đang đo, điều này có thể là một nguồn gây nhiễu.
Nhiễu giữa các cell gần nhau: Các cell gần nhau có thể gây ra nhiễu đồng kênh (Cochannel interference) nếu không được tối ưu đúng cách (ví dụ, các tần số được phân bổ
không hợp lý giữa các cell).
3. Phân tích các nguyên nhân gây nhiễu
Sau khi nhận diện khu vực nhiễu, bạn cần phải tìm hiểu nguyên nhân gây ra nhiễu. Các nguyên
nhân phổ biến có thể là:
Nhiễu đồng kênh (Co-channel interference)
Xảy ra khi các tế bào (cell) gần nhau sử dụng cùng một kênh tần số. Điều này có thể dẫn
đến việc nhiễu tín hiệu từ các cell khác. Bạn có thể kiểm tra các cell sử dụng cùng tần số
và tối ưu lại phân bổ tần số hoặc điều chỉnh power control để giảm can thiệp.
Nhiễu chéo kênh (Adjacent Channel Interference)
Xảy ra khi các kênh tần số gần nhau nhưng không hoàn toàn tách biệt. Nếu hai cell sử
dụng các kênh tần số gần nhau và có chênh lệch tần số không đủ (tần số xung đột), có
thể gây ra nhiễu. Điều chỉnh tần số giữa các cell có thể giảm bớt vấn đề này.
Nhiễu từ các nguồn ngoài (External Interference)
Interference từ các thiết bị không phải là mạng di động (ví dụ: thiết bị vô tuyến khác,
thiết bị không dây trong khu vực) cũng có thể gây nhiễu. Phân tích tầng vô tuyến và
tầng backhaul có thể giúp phát hiện các thiết bị bên ngoài đang tạo ra nhiễu không mong
muốn.
Môi trường vật lý (Fading)
Các yếu tố như các tòa nhà cao tầng, cây cối, hoặc vật cản khác có thể gây fading (suy
giảm tín hiệu) và dẫn đến nhiễu. Bạn có thể sử dụng thực hiện drive test ở nhiều điểm
khác nhau để xác định các khu vực có nhiễu do fading.
Các yếu tố thiết bị (Hardware-related issues)
Chất lượng thiết bị của trạm phát sóng (base station), hoặc các thiết bị di động có thể
ảnh hưởng đến tín hiệu và gây nhiễu nếu có cấu hình sai hoặc sự cố phần cứng.
4. Công cụ phân tích trong TEMS Discovery để xác định nhiễu
TEMS Discovery có một số công cụ mạnh mẽ giúp bạn phân tích nhiễu:
Drive Test Map: Cho phép bạn xem và phân tích các thông số như RSRP, SINR, CQI
trên bản đồ địa lý, từ đó xác định các khu vực có nhiễu.
Công cụ phân tích PCI: Giúp bạn tìm các cell có PCI trùng lặp hoặc can thiệp.
Graphical Tools: Cung cấp biểu đồ giúp so sánh tần số, tín hiệu, và nhiễu giữa các cell
khác nhau.
Phân tích thống kê: Cho phép bạn phân tích các dữ liệu lịch sử và xác định xu hướng
nhiễu trong khu vực theo thời gian.
5. Giải pháp và tối ưu hóa
Điều chỉnh phân bổ tần số để tránh nhiễu đồng kênh (co-channel interference) và nhiễu
chéo kênh (adjacent channel interference).
Tăng cường tín hiệu: Cải thiện chất lượng tín hiệu ở các khu vực có RSRP thấp hoặc
SINR thấp thông qua điều chỉnh power control hoặc sử dụng các trạm phát sóng bổ
sung (small cells, repeaters).
Cải thiện backhaul: Đảm bảo rằng backhaul có đủ băng thông để hỗ trợ các trạm phát
sóng và giảm thiểu độ trễ.
Tối ưu hóa tài nguyên vô tuyến (Radio Resource Management): Điều chỉnh các tham
số như CQI, MCS, và RB allocations để tối ưu hóa sử dụng tài nguyên.
Tóm lại:
Để xác định nhiễu khi tối ưu mạng 5G và 4G qua Drive Test với TEMS Discovery, bạn cần:
1. Thu thập dữ liệu tín hiệu (RSRP, SINR, RSRQ, CQI).
2. Xác định khu vực nhiễu qua các thông số này.
3. Phân tích nguyên nhân như nhiễu đồng kênh, nhiễu chéo kênh, fading, hoặc các vấn đề
phần cứng.
4. Áp dụng giải pháp tối ưu hóa để giảm thiểu nhiễu và cải thiện chất lượng mạng.
Nếu bạn gặp khó khăn trong quá trình phân tích hoặc cần thêm chi tiết, đừng ngần ngại hỏi thêm
nhé!
Bạn đã nói:
tôi không phân biệt được khi nào dùng SINR khi nào dùng RSRQ
ChatGPT đã nói:
Đây là một câu hỏi khá hay và rất quan trọng trong việc phân tích và tối ưu mạng di động (4G,
5G). SINR (Signal-to-Interference plus Noise Ratio) và RSRQ (Reference Signal Received
Quality) là hai thông số rất phổ biến trong mạng di động, nhưng chúng có những ứng dụng khác
nhau và giúp bạn đánh giá các yếu tố khác nhau của chất lượng tín hiệu.
1. SINR (Signal-to-Interference plus Noise Ratio)
SINR là tỷ lệ giữa công suất tín hiệu (signal) và nhiễu cộng với can thiệp (interference +
noise). Nó phản ánh chất lượng tín hiệu mà người dùng nhận được khi so với mức độ nhiễu và
can thiệp từ các tín hiệu khác.
Công thức SINR:
SINR=PsignalPinterference+Pnoise\text{SINR} =
\frac{P_{\text{signal}}}{P_{\text{interference}} +
P_{\text{noise}}}SINR=Pinterference+PnoisePsignal
Trong đó:
o
o
PsignalP_{\text{signal}}Psignal: Công suất của tín hiệu từ cell bạn đang kết nối.
PinterferenceP_{\text{interference}}Pinterference: Công suất của tín hiệu từ các
cell khác (can thiệp đồng kênh).
o
PnoiseP_{\text{noise}}Pnoise: Mức độ nhiễu nền trong kênh (thermal noise).
SINR cao có nghĩa là tín hiệu của bạn mạnh và ít bị can thiệp từ các nguồn khác, và điều này sẽ
dẫn đến một kết nối tốt và hiệu suất cao. SINR thấp có thể chỉ ra rằng tín hiệu bị can thiệp
nhiều từ các nguồn khác hoặc có quá nhiều nhiễu, dẫn đến hiệu suất thấp và độ trễ cao.
Khi nào sử dụng SINR?
SINR chủ yếu được sử dụng khi bạn muốn đánh giá chất lượng tín hiệu trong môi
trường có nhiễu và can thiệp từ các cell khác. Nó rất quan trọng trong việc quyết định
khả năng đảm bảo chất lượng kết nối cho các dịch vụ như data throughput, voice call
quality, và video streaming.
Ứng dụng: Kiểm tra xem các khu vực có nhiễu đồng kênh hay không (co-channel
interference), hoặc các vấn đề với tần số chia sẻ.
Ý nghĩa của SINR:
SINR cao (thường > 10 dB) cho thấy tín hiệu mạnh, ít bị nhiễu và can thiệp.
SINR thấp (thường < 10 dB) cho thấy tín hiệu yếu hoặc bị can thiệp nhiều, có thể ảnh
hưởng đến chất lượng kết nối.
2. RSRQ (Reference Signal Received Quality)
RSRQ là một chỉ số đo chất lượng tín hiệu tham chiếu (reference signal) từ trạm phát sóng. Nó
được tính bằng cách chia RSRP (Reference Signal Received Power) cho RSRQ và RS Noise.
Công thức tính RSRQ là: RSRQ=N×RSRPRSSI\text{RSRQ} = \frac{N \times
RSRP}{RSSI}RSRQ=RSSIN×RSRP
Trong đó:
RSRP (Reference Signal Received Power): Đo công suất tín hiệu tham chiếu từ trạm
gốc.
RSSI (Received Signal Strength Indicator): Đo tổng công suất tín hiệu nhận được (bao
gồm cả tín hiệu chính và nhiễu từ các tín hiệu khác).
RSRQ phản ánh chất lượng tổng thể của tín hiệu, bao gồm tín hiệu yếu và nhiễu. Nếu RSRQ
thấp, tức là tín hiệu không tốt và có nhiều nhiễu, điều này sẽ ảnh hưởng đến các dịch vụ như gọi
thoại, duyệt web, và video.
Khi nào sử dụng RSRQ?
RSRQ được sử dụng khi bạn cần đánh giá chất lượng tín hiệu tổng thể trong một khu
vực cụ thể, đặc biệt là trong các tình huống có nhiều nhiễu và các yếu tố gây ảnh
hưởng như can thiệp từ các cell khác hoặc điều kiện vô tuyến không lý tưởng.
Ứng dụng: Kiểm tra mức độ nhiễu và chất lượng tín hiệu tham chiếu trong quá trình
drive test hoặc khi bạn muốn đánh giá tổng thể hiệu suất của mạng.
Ý nghĩa của RSRQ:
RSRQ cao (thường > -10 dB) cho thấy tín hiệu khỏe và ít nhiễu.
RSRQ thấp (thường < -15 dB) cho thấy tín hiệu yếu và có thể bị nhiễu mạnh hoặc cạnh
tranh tần số.
So sánh và Sử dụng SINR vs RSRQ
SINR chủ yếu được sử dụng khi bạn quan tâm đến mối quan hệ giữa tín hiệu và nhiễu
(sự can thiệp) trong kết nối. Đây là chỉ số quan trọng để xác định hiệu suất dữ liệu (data
throughput) của người dùng và mức độ ổn định của kết nối.
RSRQ là chỉ số tổng thể về chất lượng tín hiệu, có tính đến cả tín hiệu và nhiễu.
RSRQ thấp có thể xảy ra ngay cả khi SINR cao, điều này có thể chỉ ra rằng tín hiệu
tham chiếu có thể bị suy giảm, nhưng không bị can thiệp nhiều.
Khi nào dùng SINR, khi nào dùng RSRQ?
Dùng SINR khi bạn muốn:
o Xác định chất lượng tín hiệu so với nhiễu và can thiệp.
o Đánh giá khả năng cung cấp throughput cao (tốc độ dữ liệu) cho người dùng.
o Tối ưu hóa băng thông và tốc độ dữ liệu trong mạng.
Dùng RSRQ khi bạn muốn:
o Đánh giá chất lượng tổng thể của tín hiệu trong một khu vực, đặc biệt khi có
nhiều nhiễu hoặc can thiệp từ các cell khác.
o Xác định vùng yếu trong mạng mà tín hiệu tham chiếu đang bị ảnh hưởng nhiều.
Tóm lại:
SINR là chỉ số bạn cần khi muốn đánh giá chất lượng tín hiệu so với nhiễu và can
thiệp, và nó rất quan trọng trong việc xác định hiệu suất mạng (data throughput).
RSRQ là chỉ số tổng thể về chất lượng tín hiệu từ trạm gốc, giúp bạn nhận diện các vấn
đề về nhiễu và sự suy giảm tín hiệu trong một khu vực.
Cả hai chỉ số đều quan trọng, và việc kết hợp cả SINR và RSRQ trong phân tích mạng sẽ giúp
bạn có cái nhìn đầy đủ hơn về hiệu suất mạng và xác định các khu vực cần tối ưu hóa.
Bạn đã nói:
bạn thử ví dụ 1 case phân tích thực tế dùng hai cái này cho tôi được không
ChatGPT đã nói:
Tuyệt vời! Mình sẽ đưa ra 1 ví dụ thực tế về một case phân tích Drive Test trong quá trình tối
ưu mạng 4G/5G, sử dụng cả SINR và RSRQ để phân tích. Case này thường xảy ra trong thực
tế khi bạn đi kiểm tra vùng phủ sóng có phản ánh phản hồi xấu từ người dùng (rớt cuộc gọi,
mạng yếu, chậm...).
✅ Case thực tế – Phân tích vùng có phản ánh “tốc độ mạng
chậm”
🗺️ Bối cảnh:
Khu vực: Khu dân cư đông đúc, có nhiều nhà cao tầng, gần trung tâm thương mại.
Phản ánh người dùng: Mạng 4G/5G chậm bất thường vào giờ cao điểm (5h chiều – 8h
tối), dù cột sóng vẫn đủ (3–4 vạch).
Thiết bị Drive Test: Sử dụng TEMS Investigation để thu log và dùng TEMS Discovery
để phân tích.
📊 Dữ liệu thu được trong Drive Test:
A (gần trạm)
RSRP
(dBm)
-85
RSRQ
(dB)
-7
SINR
(dB)
20
Tốc độ DL
(Mbps)
100
B (cách trạm 200m)
-90
-12
10
50
-92
-16
14
15
Chậm bất thường
-88
-10
4
8
Rớt tốc độ nghiêm
trọng
Vị trí đo
C (góc khu phố, nhiều
tòa nhà)
D (gần trung tâm
thương mại)
� Phân tích theo từng chỉ số:
Ghi chú
Rất tốt
Bắt đầu có dấu
hiệu yếu
✅ Vị trí C (RSRQ thấp - nhiễu cao, SINR vẫn ổn):
RSRQ = -16 dB là rất thấp → thể hiện chất lượng tín hiệu tổng thể kém.
Tuy nhiên SINR = 14 dB vẫn khá tốt → tín hiệu chính vẫn mạnh hơn nhiễu một cách
tương đối.
💡 Kết luận:
o Đây là khu vực có nhiều tín hiệu phụ từ cell khác, gây nhiễu tham chiếu làm
RSRQ giảm.
o Không phải nhiễu vô tuyến nặng, nhưng các tín hiệu nhỏ xung quanh làm
méo tín hiệu tham chiếu.
o Giải pháp: Xem lại phân bổ PCI/tần số, có thể do PCI trùng hoặc neighbor cell
xung đột → Tối ưu lại handover/neighbor list.
❌ Vị trí D (SINR thấp - can nhiễu mạnh):
SINR = 4 dB là rất thấp → rõ ràng đang bị nhiễu vô tuyến nặng, có thể từ cell khác
cùng tần số.
RSRQ = -10 dB vẫn còn tạm được, nhưng không đáng tin vì SINR quá thấp, làm cho
dữ liệu không được truyền hiệu quả.
💡 Kết luận:
o Đây là khu vực có co-channel interference (nhiễu đồng kênh).
o Có thể là do 2 trạm phát sóng gần nhau đang dùng chung tần số, không tối ưu
beam hoặc hướng anten gây đè sóng.
o Giải pháp:
Xem lại tần số reuse, phân chia lại tần số giữa các site gần đó.
Nếu là 5G: Kiểm tra beamforming sai hướng, hoặc lobe bị tràn sang
khu vực không mong muốn.
📌 Tóm gọn theo vị trí:
Vị trí Dùng SINR hay RSRQ?
Lý do chính
C
RSRQ thấp dù SINR ổn → do nhiễu nhẹ từ nhiều tín hiệu phụ
RSRQ
D
SINR quá thấp → do nhiễu mạnh từ các cell khác
SINR
🔧 Giải pháp tổng thể sau phân tích:
1. Tối ưu lại neighbor list – Tránh các cell có PCI trùng/tần số trùng đè nhau.
2. Tối ưu hướng anten/beamforming – Đảm bảo không tạo chùm sóng "tràn" gây nhiễu
không mong muốn.
3. Cân bằng tải và tắt một số cell micro gây nhiễu nhẹ (nếu có femtocell gây đè sóng).
4. Theo dõi lại sau khi tối ưu để xác thực cải thiện SINR và RSRQ.
Nếu bạn đang học hoặc chuẩn bị làm RNO/Optimization engineer, thì việc học kết hợp nhìn
RSRQ + SINR + PCI + Throughput như trên sẽ giúp bạn phân tích mạng cực kỳ nhanh và hiệu
quả.
Muốn mình chia sẻ thêm 1 file log mẫu để bạn luyện phân tích không? Hay cần làm thêm vài
case nữa cho quen?
Bạn đã nói:
thêm vài case kết hợp cả PCI RSRQ SNR và throuput đi
ChatGPT đã nói:
Rất hay! Mình sẽ chia sẻ thêm 2 case thực tế sử dụng kết hợp các chỉ số: PCI, RSRQ, SINR, và
Throughput, giúp bạn nắm vững cách tư duy như một RNO engineer chuyên nghiệp khi phân
tích mạng từ log Drive Test.
✅ CASE 1: KHU CÔNG NGHIỆP – THẤP SINR, PCI
TRÙNG, THROUGHPUT KÉM
🗺️ Bối cảnh:
Khu công nghiệp có nhiều nhà máy thép và container, mạng chập chờn, tốc độ mạng
chậm vào giờ cao điểm.
Dữ liệu log Drive Test thu tại thời điểm 16h chiều (có nhiều user active).
📊 Thông số tại một điểm đo cụ thể:
Thông số
Giá trị
RSRP
-92 dBm
RSRQ
SINR
PCI quan sát
được
-13 dB
2 dB
10, 10, 10 (3 sector lân
cận)
Ghi chú
Tín hiệu không mạnh, nhưng vẫn sử dụng
được
Chất lượng tín hiệu kém
Rất thấp → có nhiễu mạnh
⚠️ Trùng PCI
Thông số
Throughput DL
Giá trị
5 Mbps
Ghi chú
Rất thấp so với lý thuyết mạng
🔍 Phân tích:
PCI trùng (PCI Collision): Có ít nhất 3 cell xung quanh cùng dùng PCI 10 → thiết bị
không biết kết nối vào đâu → bị confusion trong quá trình handover và chọn cell → ảnh
hưởng truy cập.
SINR = 2 dB: Rất thấp → môi trường nhiễu cao → khả năng cao có co-channel
interference từ chính những cell PCI trùng.
RSRQ = -13 dB: Cũng xấu → phản ánh việc tín hiệu bị ảnh hưởng từ nhiều hướng.
Throughput thấp (5 Mbps): Mặc dù kết nối được, nhưng hiệu suất truyền tải kém →
người dùng thấy mạng chậm, giật lag.
✅ Giải pháp đề xuất:
Phân lại PCI cho các cell bị trùng → mỗi sector cần có PCI khác nhau (PCI Planning).
Tối ưu beam/hướng anten nếu là 5G → tránh beam chồng lên nhau gây nhiễu.
Kiểm tra lại phân bổ tần số → nếu đang dùng tần số giống nhau cho các cell gần nhau,
nên tách để tránh đè sóng.
✅ CASE 2: CHUNG CƯ CAO TẦNG – RSRQ KÉM,
SINR TỐT, THROUGH XẤU DO HANDOVER FAIL
🗺️ Bối cảnh:
Người dân trong tòa nhà cao tầng (25 tầng) phản ánh mạng 4G vẫn đủ sóng nhưng tải
video không nổi, mất mạng giữa chừng.
Đặc biệt tại tầng 17–20.
📊 Thông số tại tầng 18:
Thông số
RSRP
RSRQ
SINR
PCI
Giá trị
-85 dBm
-17 dB
16 dB
22
Ghi chú
Khá ổn
Rất kém
Rất tốt!
Duy nhất
Thông số
Giá trị
Ghi chú
23, 24
Có cấu hình nhưng không handover được
Neighbor PCI
Handover success rate Thấp (40%) Nhiều lần fail hoặc trễ
6 Mbps
Tệ với mức SINR cao như vậy
Throughput DL
🔍 Phân tích:
RSRQ kém (-17 dB) cho thấy môi trường tín hiệu bị "nhiễu nền" hoặc congested, dù
SINR cao.
SINR = 16 dB: Tín hiệu rất sạch → không có nhiễu vô tuyến từ cell khác.
Throughput thấp gây khó hiểu → nguyên nhân không đến từ nhiễu!
Phân tích thêm từ log cho thấy:
o Có PCI 22 là cell chính, nhưng neighbor PCI (23, 24) có RSRP rất tốt nhưng
không chuyển qua được.
o Handover fail nhiều lần → thiết bị không chuyển qua cell phụ tốt hơn → vẫn
giữ kết nối ở cell chính bị nghẽn.
✅ Giải pháp đề xuất:
Kiểm tra cấu hình neighbor cell trong RAN → có thể thiếu cấu hình handover hoặc có
blacklisting.
Tối ưu tham số A3/A5 event cho handover → để thiết bị có thể sớm rời cell nghẽn và
sang cell khỏe.
Có thể cần thêm small cell hoặc repeater trong tòa nhà để giảm tải cho cell chính.
� Bài học rút ra từ 2 case:
Chỉ số
Ý nghĩa khi phân tích
Kiểm tra trùng, xung đột, phân vùng
PCI
Phản ánh nhiễu nhẹ tổng thể từ nhiều nguồn hoặc tải cell
RSRQ
Đo mức độ can nhiễu vô tuyến – rất nhạy với co-channel
SINR
Throughput Chỉ tiêu người dùng cảm nhận – cần nhìn cả RLC, HARQ, load để hiểu sâu
Nếu bạn muốn, mình có thể giúp bạn dựng lại mô phỏng log drive test đơn giản hoặc gửi bạn
bảng template để luyện phân tích. Hoặc bạn muốn mình làm 1 bài hướng dẫn phân tích RSRP,
RSRQ, SINR, PCI qua bản đồ luôn cũng được! Cứ nói nhé!
Bạn đã nói:
trước tiên hãy gửi gửi bạn bảng template để luyện phân tích
ChatGPT đã nói:
Dưới đây là bảng template luyện phân tích log Drive Test cho 4G/5G, giúp bạn luyện tập và
ghi chú khi phân tích dữ liệu thực tế. Bạn có thể dùng bảng này khi xem log trong TEMS
Discovery, Actix, hoặc bất kỳ phần mềm phân tích nào khác.
📋 BẢNG TEMPLATE PHÂN TÍCH CHẤT LƯỢNG
MẠNG (4G/5G)
Vị trí đo
RSRP RSRQ SINR
Neighbor Throughput
STT (tên/khu
PCI
(dBm) (dB) (dB)
PCI
DL (Mbps)
vực)
Throughput
UL (Mbps)
1
2
3
4
5
🔍 Gợi ý phân tích từng cột:
RSRP:
o -80 dBm: Rất tốt
-80 đến -100 dBm: Trung bình
< -100 dBm: Yếu, cần chú ý khu vực này
RSRQ:
o -10 dB: Tốt
o -10 đến -14 dB: Trung bình
o < -14 dB: Kém → khả năng có nhiễu nền hoặc tải cell cao
SINR:
o 15 dB: Rất tốt
o 10–15 dB: Tốt
o 5–10 dB: Kém
o < 5 dB: Tệ → có thể có co-channel interference
PCI / Neighbor PCI:
o Kiểm tra trùng lặp PCI (collision), hoặc PCI confusions
o So sánh neighbor PCI có mạnh nhưng không chuyển HO được không
o
o
Ghi
chú
phân
tích
Throughput:
o DL < 10 Mbps trong vùng SINR cao: Cần điều tra thêm → nghẽn, cấu hình lỗi
hoặc HO fail
o UL yếu bất thường: Có thể là do cấu hình UL Power, góc khuất, hoặc
interference UL
Ghi chú phân tích:
Viết ngắn gọn theo hướng:
o "SINR thấp, có PCI trùng → khả năng nhiễu đồng kênh"
o "RSRP tốt, RSRQ xấu → tải cell cao hoặc có nhiễu nền"
o "Neighbor PCI mạnh nhưng không HO → lỗi cấu hình"
📌 Gợi ý cách sử dụng:
In ra nếu bạn đi thực tế.
Dùng Excel hoặc Google Sheets để điền nhanh sau mỗi chuyến Drive Test.
Dán ảnh bản đồ drive test vào từng khu bạn phân tích (nếu làm báo cáo).
Tập thói quen viết giải thích ngắn gọn vào cột “Ghi chú” để luyện tư duy phân tích
logic.
Nếu bạn cần, mình có thể tạo một bản Excel mẫu luôn (có công thức tô màu tự động theo mức
tín hiệu), hoặc giúp dựng luôn bài tập phân tích giả lập theo log mẫu. Bạn muốn mình gửi bản đó
không?
Bạn đã nói:
làm 1 bài hướng dẫn phân tích RSRP, RSRQ, SINR, PCI qua bản đồ luôn cũng được
ChatGPT đã nói:
Tuyệt vời luôn! Mình sẽ làm cho bạn một bài hướng dẫn chi tiết từng bước cách phân tích
RSRP, RSRQ, SINR, PCI qua bản đồ Drive Test (dùng với TEMS Discovery hoặc Actix –
cách phân tích đều tương tự).
Bài này sẽ giúp bạn hiểu nhìn vào bản đồ là đoán ra ngay khu nào nhiễu, khu nào yếu sóng,
khu nào lỗi PCI...
� HƯỚNG DẪN PHÂN TÍCH RSRP, RSRQ, SINR, PCI
QUA BẢN ĐỒ
✅ Bước 1: Chuẩn bị dữ liệu bản đồ Drive Test
File log đo từ thiết bị test (TEMS Investigation, Nemo, etc.)
Phần mềm phân tích (TEMS Discovery hoặc Actix)
Dữ liệu map nền (Google map hoặc GIS Layer)
✅ Bước 2: Bật hiển thị từng lớp dữ liệu (layer) quan trọng
Trong phần mềm, bạn bật hiển thị dạng color-coded map (theo vạch màu) cho các chỉ số sau:
Layer Màu đề xuất (theo chuẩn RNO)
Ý nghĩa
RSRP Xanh > -80, vàng -80~-100, đỏ < -100 Độ mạnh tín hiệu
RSRQ Xanh > -10, vàng -10~-14, đỏ < -14 Chất lượng tín hiệu
Nhiễu vô tuyến
SINR Xanh > 15, vàng 10~15, đỏ < 10
Dùng để phát hiện trùng PCI
PCI Mỗi PCI 1 màu khác nhau
📌 Mẹo nhỏ: Bạn nên hiển thị từng lớp một để dễ quan sát hơn. Đừng bật tất cả cùng lúc nếu
chưa quen mắt.
✅ Bước 3: Phân tích từng chỉ số theo bản đồ
🔸 A. Phân tích bản đồ RSRP (cường độ tín hiệu)
Khu vực màu đỏ đậm (RSRP < -100 dBm) → Tín hiệu yếu.
o Có thể do xa trạm, che khuất, hoặc beam không hướng tới đó.
o ❗ Nếu ngay gần site mà vẫn đỏ → vấn đề về hướng anten hoặc công suất.
Khu vực xanh lá > -80 dBm → Sóng tốt, ổn định.
💡 Ứng dụng: Dùng để xác định khu vực cần thêm site / small cell / beam tối ưu.
🔸 B. Phân tích bản đồ RSRQ (chất lượng tín hiệu)
Khu vực có RSRQ < -14 dB (màu đỏ):
Có thể có nhiễu nền cao, hoặc cell đang quá tải (người dùng nhiều).
RSRP có thể vẫn mạnh, nhưng RSRQ xấu → tín hiệu bị "dơ", khó decode.
Nếu RSRQ xấu ở khu gần site → nghi ngờ có cell khác phát sóng gần trùng tần số.
o
o
💡 Ứng dụng: Tìm vùng có thể cần tối ưu phân bổ tần số hoặc giảm tải cell.
🔸 C. Phân tích bản đồ SINR (mức độ nhiễu)
SINR < 5 dB (màu đỏ) → bị nhiễu nặng, có thể từ các cell khác.
o Cực kỳ quan trọng trong 5G, nơi beam dễ "đụng" nhau.
Nếu thấy RSRP mạnh, nhưng SINR vẫn thấp → chắc chắn là nhiễu vô tuyến đồng
kênh.
💡 Ứng dụng: Dùng để phát hiện vùng có co-channel interference → điều chỉnh tần số hoặc
hướng beam.
🔸 D. Phân tích bản đồ PCI (PCI map)
Dùng PCI Layer với mỗi PCI 1 màu để xác định:
o PCI Collision: 2 hoặc nhiều cell gần nhau có màu giống nhau (PCI giống nhau)
→ gây handover thất bại, thiết bị hoang mang.
o PCI Confusion: Cùng PCI nhưng RSRP mạnh ngang nhau, thiết bị không biết
chọn ai.
💡 Ứng dụng: Phát hiện lỗi phân bổ PCI, sửa lại PCI Planning.
✅ Bước 4: So sánh chéo các lớp với nhau
Đây là mẹo "pro" trong nghề:
Tình huống thực tế
Dấu hiệu
RSRP tốt + RSRQ xấu
Cell tải cao, hoặc tín hiệu bị méo
RSRP xấu + SINR xấu
Xa site + có nhiễu đồng kênh
SINR xấu + PCI trùng
Nhiễu đồng kênh do PCI Collision
RSRP tốt + SINR tốt + Throughput thấp Lỗi cấu hình, nghẽn backhaul hoặc HO lỗi
✅ Bước 5: Ghi chú trên bản đồ
Trong TEMS Discovery hoặc Actix, bạn có thể:
Vẽ vùng bị lỗi (polygon)
Đặt tag: “Zone nhiễu mạnh”, “RSRQ xấu”, “PCI trùng”
Xuất hình để đưa vào báo cáo PDF
🖼️ Hình ảnh minh họa ví dụ (mô phỏng)
(Bạn có thể tưởng tượng ví dụ sau):
Một đoạn đường phố:
o Bản đồ RSRP: Màu vàng nhạt → RSRP ~ -90 → Trung bình.
o Bản đồ RSRQ: Màu đỏ → -16 → Bị nhiễu.
o Bản đồ SINR: Màu vàng → 8 dB → Có nhiễu nhẹ.
o PCI map: Khu đó màu xanh lá giống nhau → PCI = 33 → Phát hiện trùng PCI
giữa 2 cell gần nhau.
👉 Kết luận: Vùng này bị nhiễu do PCI trùng + tín hiệu không quá mạnh → cần tối ưu cả
tần số và cấu hình neighbor.
✅ Kết luận:
Khi phân tích qua bản đồ, bạn nên:
1.
2.
3.
4.
Xem từng lớp một (RSRP → RSRQ → SINR → PCI)
Ghi chú vùng lỗi rõ ràng
So sánh chéo các chỉ số để xác định nguyên nhân gốc
Đưa ra đề xuất kỹ thuật rõ ràng: beam tối ưu, đổi PCI, chia tải...
📦 Mình có thể gửi bạn một bản mô phỏng bản đồ mẫu dạng ảnh nếu bạn muốn luyện nhìn
bản đồ hoặc một bài tập thực hành phân tích multi-layer. Bạn có muốn mình tạo giúp không?
Bạn đã nói:
tại sao biết RSRQ xấu do tải cao liên quan gì đến tải nhỉ
ChatGPT đã nói:
Câu hỏi này rất hay và thực tế, vì RSRQ xấu do tải cao là một vấn đề khó thấy bằng mắt
thường, nhưng lại rất phổ biến trong tối ưu mạng. Mình sẽ giải thích rõ từng bước, từ bản chất
kỹ thuật đến biểu hiện trên mạng thực tế nhé.
� 1. RSRQ là gì và liên quan gì đến tải (cell load)?
👉 RSRQ (Reference Signal Received Quality) = Chất lượng tín hiệu tham chiếu
RSRQ = (N × RSRP) / RSSI
Trong đó:
RSRP = Công suất tín hiệu tham chiếu từ cell (chỉ tính pilot)
RSSI = Tổng công suất tất cả tín hiệu nhận được (bao gồm:
o Tín hiệu pilot (RSRP),
o Các tín hiệu data từ user khác,
o Nhiễu nền,
o Can nhiễu từ cell khác...)
📉 2. Khi cell tải cao → RSRQ xấu vì sao?
Khi cell tải cao (nhiều user sử dụng dữ liệu), trạm phát sóng sẽ phát nhiều tín hiệu data hơn
(PDSCH), chứ không chỉ phát tín hiệu pilot (RSRP).
➡️ RSSI sẽ tăng mạnh, vì nó gồm tất cả công suất (data + pilot)
➡️ Trong khi RSRP vẫn giữ nguyên (chỉ là công suất pilot nhỏ và cố định)
➡️ Kết quả:
RSRQ=N×RSRPRSSI ta˘ng⇒RSRQ giảm\text{RSRQ} = \frac{N × RSRP}{\text{RSSI tăng}}
⇒ \text{RSRQ giảm}RSRQ=RSSI ta˘ngN×RSRP⇒RSRQ giảm
🔁 Hiểu đơn giản:
RSRQ không chỉ đo tín hiệu chính, mà đo tín hiệu chính trong một biển tín hiệu khác.
Khi nhiều user sử dụng mạng → trạm bắn nhiều data hơn → "nhiễu nền" do chính trạm
tạo ra tăng → RSRQ giảm.
📍 Ví dụ dễ hình dung:
Giống như bạn nghe nhạc trong một căn phòng:
o Nếu chỉ có bài nhạc bạn muốn nghe (RSRP), mọi thứ rõ ràng.
o Nếu phòng có nhiều người nói chuyện cùng lúc (data từ user khác) → dù nhạc
vẫn bật, bạn nghe không rõ nữa → RSRQ giảm.
📊 Trên thực tế đo Drive Test:
Vị trí đo
RSRP (dBm) RSRQ (dB) SINR (dB) Cell load
A (giờ thấp điểm) -85
-9
20
30%
B (giờ cao điểm) -85
19
-15
95%
➡️ Cùng RSRP, cùng SINR, nhưng RSRQ thấp ở giờ cao điểm → là do cell đang rất bận,
RSSI tăng lên nhiều → RSRQ giảm.
🛠️ Ứng dụng trong tối ưu mạng:
Nếu RSRQ thấp mà:
o RSRP tốt
o SINR tốt
o Nhưng lại nhiều phản ánh mạng chậm
=> Khả năng cao là do tải cao, không phải nhiễu hay vấn đề vô tuyến.
➡️ Giải pháp:
Tối ưu load balancing
Triển khai thêm small cell
Điều chỉnh tham số HO để offload user sang cell ít tải hơn
✅ Tóm gọn:
Nguyên nhân RSRQ xấu
Dấu hiệu
Cách xử lý
SINR tốt, RSRQ xấu Giảm tải cell
Tải cao (RSSI tăng)
Nhiễu từ ngoài (co-channel) RSRQ xấu + SINR xấu Điều chỉnh tần số, beam
Nhiều tín hiệu phụ (neighbor) RSRQ xấu, RSRP ổn Kiểm tra PCI trùng, xung đột
0
You can add this document to your study collection(s)
Sign in Available only to authorized usersYou can add this document to your saved list
Sign in Available only to authorized users(For complaints, use another form )