g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

LTE terminalleri, RB kaynakları ve karşılaştıkları gerçek sorunlar için nasıl geçerlidir?

Yazar hakkında: Cao Gaijian, ekran adı Amir C, yılların LTE / GSM protokol geliştirme deneyimi, UE tarafı ve eNB tarafı protokol geliştirme sürecine aşina. Bir dizi tanınmış iletişim / yarı iletken şirketinde çalıştı ve ekibin 3GPP protokolünü okumadan başlayarak tüm eNB MAC katmanının kod tasarımını ve yazımını tamamlamasına öncülük etti. 2008 yılında Güneydoğu Üniversitesi'nden navigasyon rehberliği ve kontrolü alanında yüksek lisans derecesi ile mezun oldu.

Sorumlu editör: Jia Weidi (jiawd@csdn.net

1. LTE terminalleri neden RB kaynakları için geçerli?

LTE sistemi, terminaller ve ağ ekipmanından oluşur Terminal genellikle UE (Kullanıcı Ekipmanı) ile temsil edilir En yaygın UE bir cep telefonudur Ağ ekipmanı eNB (Evrimleşmiş Düğüm B), çekirdek ağ ve diğer düğüm birimlerini içerir. UE ile eNB arasında, genellikle hava arayüz iletimi olarak adlandırılan kablosuz iletim vardır ve eNB ve çekirdek ağ, kablolu bir bağlantı yoluyla bağlanır.

Şekil 1-1 UE-eNB-Core ağ bağlantı şeması

Yalnızca bir hizmet hücresinde normal olarak bulunan UE'ler, dosya gönderme ve alma veya arama yapma gibi hizmetleri gerçekleştirebilir. Her hizmet veren hücre, bir eNB düğümüne karşılık gelir ve eNB düğümü, RB (Kaynak Bloğu, kaynak bloğu) kaynaklarının hücredeki tüm UE'lere tahsis edilmesinden sorumludur. Protokolün katmanlı uygulamasında, dosya gönderme ve alma veya uygulama katmanında çağrı yapma gibi hizmet verilerinin, sonunda karşılık gelen fiziksel paylaşılan kanala eşlenmesi gerekir ve fiziksel paylaşımlı kanaldaki RB, hava arayüzü kablosuz iletimini taşımak ve gerçekleştirmek için kullanılır.

UE'nin yüklenecek dosyaları varsa, eNB'nin fiziksel yer-uydu bağı paylaşılan kanalı PUSCH'da UE'ye RB kaynaklarını tahsis etmesi gerekir ve UE'nin indirilecek dosyaları varsa, eNB'nin fiziksel aşağı bağlantı paylaşımlı kanalı PDSCH'ye tahsis etmesi gerekir. ENB, hücrede belirli bir UE için paylaşılan kanalda RB kaynaklarını tahsis etmezse, UE karşılık gelen hizmetleri gerçekleştiremez.

2. LTE terminalleri için kaynak başvurusunda bulunmanın üç yolu

UE rastgele erişimi tamamladığında ve kullanıcı verilerini ağ tarafına yüklemeye ihtiyaç duyduğunda, PUSCH kanalında yer-uydu hattı RB kaynaklarına sahip olmalıdır, RB kaynağı yoksa, önceden ağ tarafından RB kaynakları için başvurması gerekir. LTE protokol spesifikasyonu, UE'nin ağ tarafından PUSCH kanalındaki RB kaynaklarına başvurması için üç yol sağlar:

Yukarı bağlantı RB kaynaklarına başvurmak için BSR'yi ağ tarafına gönderin

BSR'nin tam adı Tampon Durum Raporu, yani tampon durum raporudur. UE, ağ tarafına şunları söylemek için MAC katmanının PDU'suna bir BSR kontrol birimi ekleyebilir: benim bir veya birkaç mantıksal kanal grubumda şu anda kaç bayt veri gönderilmesi gerektiğini, umarım siz (ağ) bazı yukarı bağlantı RB kaynaklarını tahsis edebilirsiniz Ver bana (UE).

BSR kontrol biriminin bu şekilde gönderilmesi, ağ tarafının UE'nin göndermesi gereken veri miktarının yaklaşık aralığını bilmesini sağlayabilir ve ağ tarafı, hedeflenen bir şekilde UE için yukarı bağlantı RB kaynaklarının sayısını tahsis edebilir. Bununla birlikte, UE tarafından gönderilen BSR kontrol biriminin eyleminin kendisi PUSCH kanalında iletilir ve PUSCH kanalındaki RB'nin kullanılması gerekir. UE şu anda PUSCH kanalındaki RB kaynaklarına tahsis edilmemişse, BSR bilgisini ağ tarafına göndermenin bir yolu yoktur Bu zamanda, UE'nin aşağıdaki şekilde ağ tarafına bir kaynak talebi göndermesi gerekir.

Yukarı bağlantı RB kaynaklarına başvurmak için ağ tarafına SR'yi gönderin

SR'nin tam adı Planlama Talebi, yani planlama talebidir. UE, normal bir BSR'yi (bir tür BSR) tetiklerse ve UE'nin şu anda PUSCH kanalında yukarı bağlantı RB yetkilendirmesini elde etmediğini ve yukarı bağlantı SPS ile kısıtlanmadığını tespit ederse, UE, PUCCH kanalında SR sinyalini gönderebilir. Yukarı bağlantı RB kaynaklarına başvurmanın yolu.

BSR yöntemi ile karşılaştırıldığında, SR aracılığıyla bu uygulama yönteminin bir dezavantajı vardır, yani ağ tarafı sadece bir SR sinyali alır ve UE'nin kaç baytlık veri yüklemesi gerektiğini bilmez ve ne kadar kaynak tahsis edildiğini belirlemek imkansızdır. nın-nin.

Ağ tarafı UE'den SR talebini aldıktan sonra, kaç tane RB kaynağının tahsis edileceği ekipman üreticisinin algoritması tarafından belirlenir. Genel olarak, ağ tarafı SR sinyalini aldıktan sonra, tahsis edilen RB kaynakları, en azından UE'nin BSR üzerinden bir kez yukarı bağlantı RB kaynakları için başvurmasına izin verebilir.

Tüm UE'ler SR sinyallerini gönderemez. SR, PUCCH kontrol kanalında iletilir ve PUCCH kanalının kendisinin kaynakları da sınırlıdır. Ağ tarafındaki RRC katmanı, gerçek ihtiyaçlara göre yalnızca belirli UE'ler için SR kaynaklarını konfigüre edecektir. Yalnızca SR kaynakları ile yapılandırılmış bir UE ağ tarafına bir SR talebi gönderebilirken, yapılandırılmış SR kaynakları olmayan bir UE ağ tarafına bir SR talebi gönderemez.

Bir UE normal bir BSR'yi tetikler, ancak bir BSR kontrol birimini gönderemezse ve bir SR gönderemezse, UE'nin yukarı bağlantı RB kaynaklarına başvurmak için rekabetçi bir rasgele erişim sürecini başlatması gerekir.

Yer-uydu hattı RB kaynaklarına başvurmak için rekabetçi bir rastgele erişim sürecini başlatın

Rekabetçi bir rasgele erişim sürecini başlatmanın iki ana amacı vardır, yani yukarı bağlantı RB kaynakları elde etmek ve yukarı bağlantı TA senkronizasyonunu elde etmek.

Bu kaynak uygulama yönteminde, UE, ağ tarafına yaklaşık olarak kaç bayt verinin yüklenmesi gerektiğini söylemek için MSG3'e bir BSR kontrol birimi ekleyecektir. Kaynaklar için bu şekilde başvurmanın zaman gecikmesi en büyük olduğu için, bu UE'nin yalnızca son seçimidir.

Elbette, UE ağa ilk kez erişiyorsa, birinci kaynak uygulaması yalnızca rekabetçi bir rasgele erişim işlemi yoluyla tamamlanabilir ve daha sonra yer-uydu hattı RB kaynağı, SR ve BSR aracılığıyla uygulanabilir.

Yukarıdaki açıklamayı özetleyerek: UE rastgele erişim sürecini tamamladıktan sonra, yukarı bağlantı kaynakları için başvururken BSR yöntemi tercih edilecektir BSR gönderilemiyorsa, SR yöntemi kullanılabilir Son olarak rekabetçi rasgele erişim yöntemi dikkate alınacaktır. Aşağıdaki Şekil 2-1'de gösterildiği gibi.

Şekil 2-1 UE'nin kaynaklara başvurmasının üç yolu

BSR, SR veya rekabetçi rasgele erişim yoluyla uygulanıp uygulanmadığına dikkat edilmelidir, ağ tarafı tarafından tahsis edilen gerçek RB kaynakları, UE'nin bir kerede iletilecek tüm verileri iletmesi için yeterli olmayabilir ve UE'nin devam etmesi gerekir. Ağ tarafındaki kaynaklar için başvurun.

3. BSR aracılığıyla kaynaklar için başvurun

BSR'yi aldıktan sonra, ağ tarafı BSR'de taşınan içeriğe göre uygun kaynakları UE'ye tahsis eder. Burada bir sorun var: UE tarafından iletilecek veri miktarı dinamik ve rastgele değişiyor Örneğin, UE'nin belirli bir anda 999 bayt veri göndermesi gerekiyor ve sonraki saniyede 10001 bayt veri göndermesi gerekebilir. Belirsiz, UE bu talep bilgisini ağ tarafına nasıl ifade ediyor? Elbette en basit yöntem, UE'nin belirli bir sayıyı (10001 numarası gibi) BSR bilgisine kodlamasıdır, ancak bu durumda, hava arayüzünde iletilen bit sayısı daha fazladır. Buradaki protokol, BSR bilgilerini kodlamak için başka bir yöntem kullanır: 0'dan 63'e kadar 64 dizin kullanılır ve her bir dizin değeri farklı bir bayt aralığını temsil eder. Bu şekilde, UE'nin ne kadar veri göndermesi gerektiğine bakılmaksızın, BSR yalnızca 6 bitlik alana ihtiyaç duyar, bu da hava arayüzü iletimi için bit sayısını azaltır. Ayrıca, hava arayüzünde UE tarafından gönderilen belirli bayt sayısı da anlamsızdır Sonuçta, eNB, UE için kaynakları programladığında, UE tarafındaki BSR bilgisinin diğer değerlere güncellenme olasılığı yüksektir.

UE tarafından bildirilen BSR kontrol elemanı (kontrol elemanı) iki formata sahiptir:

BSR, Kısa BSR (kısa BSR) veya Kesilmiş BSR (kesilmiş BSR) tipinde olduğunda, BSR kontrol birimi sabit bir baytı işgal eder ve yalnızca bir mantıksal kanal grubunun BSR bilgisini taşıyabilir. BSR bilgisine karşılık gelen mantıksal kanal grubu kimliği, 0 ila 3 arasında değişen sabit olarak 2 bit kaplar ve BSR alanı, 0 ila 63 arasında değişen 6 bit sabit olarak kaplar.

BSR, Uzun BSR (Uzun BSR) tipine ait olduğunda, BSR kontrol birimi sabit 3 baytlık bir uzunlukta yer alır ve tüm mantıksal kanal gruplarının BSR bilgilerini taşıyabilir. Protokol sadece 4 tip mantıksal kanal grubunu belirttiğinden, LCG ID değerini taşımaya gerek yoktur. LCG ID0'dan LCG ID3'e 6 bitlik BSR alanı sırayla kodlanır: Arabellek Boyutu # 0, LCGID0'ın BSR değerine karşılık gelir ve Arabellek Boyutu # 1, LCGID1'in BSR değeri, Arabellek Boyutu # 2, LCGID2'nin BSR değerine karşılık gelir ve Arabellek Boyutu # 3, LCGID3'ün BSR değerine karşılık gelir.

İki format aşağıdaki Şekil 3-1'de gösterilmektedir.

Şekil 3-1-1 Kısa BSR ve kesilmiş BSR'nin MAC kontrol ünitesi

Şekil 3-1-2 Uzun BSR'nin MAC kontrol ünitesi

Her MAC kontrol ünitesi bir MAC alt başlığına karşılık gelir Bu alt başlıktaki LCID alanı kontrol ünitesi tipini belirtmek için kullanılır. Yukarıda bahsedilen üç tip BSR, Kısa BSR, Kesilmiş BSR ve Uzun BSR, aşağıdaki Tablo 3-1'de gösterildiği gibi alt başlıktaki LCID değeriyle belirlenir.

Tablo 3-1 LCID değeri ve yukarı bağlantı MAC PDU alt başlığındaki karşılık gelen anlam

Protokol, bu üç BSR türü için farklı LCID değerlerini tanımlar: Kontrol birimine karşılık gelen alt başlığın LCID değeri 28 ise (yani ikili 11100), bu, UE'nin Kesilmiş bir BSR yüklediği anlamına gelir.Bu zamanda, ağ tarafı MAC katmanı Mantıksal kanal grubu kimlik numarası ve BSR değerinin ayrıştırılabildiği kontrol birimi kod akışının yalnızca 1 baytının çıkarılması gerekir; benzer şekilde, kontrol birimine karşılık gelen alt başlığın LCID değeri 30 ise, bu UE'nin yüklendiği anlamına gelir Bu bir Uzun BSR'dir ve ağ tarafının 3 baytlık bir kontrol birimi kod akışını alması ve tüm mantıksal kanal gruplarının BSR değerini ondan ayrıştırması gerekir.

4. BSR'yi tetiklemenin çeşitli yolları

Aşağıdaki olaylardan biri meydana geldiğinde, UE bir BSR'yi tetikleyecektir.UE ayrıca BSR kontrol birimini taşıyabilen yeterli PUSCH yer-uydu hattı RB kaynağına sahipse, UE, BSR kontrol birimini taşıyan bir MAC PDU kuracaktır. , ENB'ye gönderildi.

(1) Belirli bir mantıksal kanal grubuna ait olan belirli bir mantıksal kanal, iletilecek yukarı bağlantı verilerine sahip olduğunda ve bu mantıksal kanalın önceliği, herhangi bir geçerli mantıksal kanal grubundaki herhangi bir mantıksal kanalın önceliğinden veya şu anda aynı mantıksal kanaldan daha yüksek olduğunda Gruptaki diğer tüm mantıksal kanalların iletilecek hiçbir verisi yoktur Bu zamanda, bir BSR tetiklenecek ve bu BSR'ye Düzenli BSR (Normal BSR) adı verilir. Örneğin, aşağıdaki üç senaryo normal BSR'yi tetikler:

sahne 1

Sahne 2

Sahne 3

UE, normal bir BSR'yi tetiklediğinde ve mevcut TTI'da PUSCH üzerinde mevcut bir yukarı bağlantı RB olmadığında, BSR'yi eNB'ye göndermenin bir yolu yoktur. Ağ tarafı şu anda UE için SR kaynaklarını yapılandırmışsa, SR göndererek kaynaklar için başvurmaya devam edip edemeyeceği aşağıdaki iki duruma bağlıdır: Yalnızca bunlardan biri karşılandığında, kaynak talebi SR aracılığıyla gönderilecektir:

(A) Yapılandırılmış bir yukarı bağlantı yetkisi yok. UL SPS ağ tarafında etkinleştirilirse, UE'nin yer-uydu bağı yetkisinin yapılandırılmış olduğu kabul edilir.

(B) Mevcut normal BSR, iletilebilen yukarı bağlantı verileriyle belirli bir mantıksal kanal tarafından tetiklenir, ancak RRC mantıksal kanalın mantıksal Kanal SR-Maske parametresini konfigüre etmez. Diğer bir deyişle, UE normal bir BSR'yi tetiklediyse ve yukarı bağlantı yetkilendirmesini yapılandırdıysa, ağ tarafı mantıksal KanalSR-Maskesini true olarak ayarlarsa, SR tetiklenmeyecektir. LogicalChannelSR-Mask parametresi, mantıksal kanalın parametresine aittir ve logicalChannelConfig hücresinde yapılandırılır.

(A) ve (B) 'yi birleştirmek, UE normal bir BSR'yi tetiklediğinde ve yer-uydu hattı yetkilendirmesini konfigüre ettiğinde ve mantıksal kanalın mantıksal Kanal SR-Maskesi doğru olduğunda, bir SR göndererek kaynaklara başvurmak mümkün değildir (ve gereksizdir).

(2) UE, yer-uydu hattı kaynaklarına tahsis edilmiştir ve doldurma bitlerinin sayısı, BSR kontrol birimi ve onun MAC alt başlığının bit sayısının toplamına eşit veya ondan büyüktür Bu zamanda, bir BSR tetiklenecek ve bu BSR'ye bir dolgu BSR'si (Dolgu BSR) adı verilmektedir. Bu mekanizmanın eklenmesinin nedeni esas olarak kaynakların etkin kullanımının dikkate alınmasına dayanmaktadır. Şematik diyagram için aşağıdaki Şekil 4-2'ye bakın.

Şekil 4-2 BSR doldurma montaj süreci

(3) Periyodik zamanlayıcı periyodik BSR-Zamanlayıcısının süresi sona erer Bu zamanda, UE bir BSR'yi tetikleyecektir ve BSR'ye periyodik BSR (Periyodik BSR) adı verilir.

(4) Yeniden iletim zamanlayıcı retxBSR-Zamanlayıcısının süresi dolar ve UE, mantıksal bir kanal grubundaki herhangi bir mantıksal kanal üzerinde iletmek için verilere sahiptir Bu zamanda, UE bir BSR'yi tetikleyecektir ve bu BSR'ye normal bir BSR de denir.

RetxBSR ve periodicBSR zamanlayıcıları RRC tarafından konfigüre edilir ve radioResourceConfigDedicated hücresinin mac-MainConfig alanında UE'ye getirilir Periyodik zamanlayıcının ve yeniden iletim zamanlayıcısının parametre listesi aşağıda gösterilmektedir. Birim, alt çerçeve veya ms'dir ve sf320, 320ms anlamına gelir.

MAC-MainConfig :: = SEKANS {ul-SCH-Yapılandırma SIRASI {... periodicBSR-Zamanlayıcı SIRALANDIRILMIŞ {sf5, sf10, sf16, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf320, sf640, sf25601280, sf2560 , sonsuz, yedek1} İSTEĞE BAĞLI, - GEREKLİ retxBSR-Zamanlayıcı SIRALAMALI {sf320, sf640, sf1280, sf2560, sf5120, sf10240, yedek2, yedek1}, ...

Ağ tarafı tarafından alınan sadece üç tip BSR kontrol ünitesi vardır: uzun BSR, kısa BSR ve kesilmiş BSR Bunlar BSR uzunluğu açısından sınıflandırılırken, normal BSR, dolgu BSR ve periyodik BSR BSR tarafından tetiklenir. Sınıflandırma açısı. Bu iki sınıflandırma arasında belirli bir ilişki vardır Örneğin, geleneksel bir BSR için, uzun bir BSR veya kısa bir BSR olabilir Aşağıdakiler, bu iki sınıflandırma arasındaki ilişkiyi spesifik olarak açıklamaktadır.

Düzenli BSR

UE normal bir BSR gönderiyorsa ve bu TTI'da veri iletebilen birden fazla mantıksal kanal grubu varsa, uzun BSR rapor edilir, aksi takdirde kısa BSR rapor edilir. Yukarıdaki Şekil 4-1'deki senaryo 1'de, aktarılacak veriye sahip 4 mantıksal kanal grubu vardır ve bu zamanda uzun BSR rapor edilir; senaryo 2'de, yalnızca bir mantıksal kanal grubu iletilecek veriye sahiptir ve bu sefer kısa BSR rapor edilir; 3 Tetikleme nedeni senaryo 2 ile aynıdır. Bunun nedeni ayrıca LCG-ID1'de veri iletebilen yalnızca bir mantıksal kanal 5 olması, ancak LCG-ID0'daki mantıksal kanal 1'in de iletilecek veriye sahip olması nedeniyle uzun BSR rapor edilir.

BSR'yi doldurun

(A) Dolgu bitlerinin sayısı kısa BSR ve onun MAC alt başlığının toplamından büyük veya ona eşitse, ancak uzun BSR ve onun MAC alt başlığının toplamından azsa, o zaman:

Bildirilen BSR'nin TTI'sinde aktarım için birden fazla mantıksal kanal grubu verisi mevcutsa, en yüksek öncelikli mantıksal kanala sahip mantıksal kanal grubunun kesilmiş BSR'si rapor edilir. Kesilmiş BSR olarak adlandırılmasının nedeni, şu anda birden fazla mantıksal kanal grubu verisinin iletilebilmesidir, uzun BSR'nin bildirilmesi makuldür, ancak mevcut sınırlı doldurma kaynakları ile sınırlıdır, yalnızca bir mantıksal kanal grubu BSR gönderilebilir. Bu nedenle, bu "kesilmiş BSR", bir baytlık kısa BSR'yi ayırt etmek için tanımlanır.
Aksi takdirde, kısa BSR'yi bildirin.

(B) Aksi takdirde, doldurma bitlerinin sayısı uzun BSR ve onun MAC alt başlığındaki bit sayısının toplamına eşit veya bundan büyükse, uzun BSR bildirilir.

BSR dönemi

UE, periyodik bir BSR gönderir ve TTI'da verileri iletebilen birden fazla mantıksal kanal grubu varsa, uzun BSR rapor edilir, aksi takdirde kısa BSR rapor edilir ve kesilmiş BSR bildirilmez. Normal BSR'yi, periyodik BSR'yi ve doldurma BSR'yi tartıştığımızda, değiştiricisi genellikle "tetikleyicidir" ve uzun BSR'yi, kısa BSR'yi ve kesilmiş BSR'yi tanımlarken, değiştiricisi genellikle " "(Rapor) gönderin, buradaki farka dikkat edin.

5. Mevcut trafik düşüşü sorunları ve çözümleri

Fiili test sürecinde, bazen UE yukarı bağlantı veri iletimini gerçekleştirirken, trafiğin, örneğin Şekil 5-1'de gösterildiği gibi kararlı bir 10Mbps'den 8Mbps'ye aniden belirli bir süre için azaldığını görebiliriz. Bu neden?

Şekil 5-1 Yukarı akış trafiği "düşer"

Bu sorun genellikle UE'nin hava arayüzünde DCI0'ı algılamamasından kaynaklanır. UE, BSR veya SR aracılığıyla eNB'ye bir yer-uydu bağı RB kaynak uygulamasını gönderdikten sonra, eNB, DCIO aracılığıyla UE'ye UE için tahsis edilen RB'nin konumunu ve boyutunu söyleyecektir, ancak UE, DCIO'yu kaçırırsa, UE bu RB kaynaklarını kullanamaz. .

Protokol bir yeniden iletim zamanlayıcısı sunsa da, yine de bazı sorunlar vardır. Şekil 4-3'te gösterildiği gibi, yeniden iletim zamanlayıcısının minimum süresi 320 ms olduğundan, bu, Şekil 5-1'de gösterilen senaryoda, UE'nin eNB'den PUSCH kaynakları için başvurmadan önce 320 ms beklemesi gerekebileceği anlamına gelir. Süreç aşağıdaki gibidir. Şekil 5-2'de gösterildiği gibi.

Şekil 5-2 DCI0 kaçırılmış algılamanın neden olduğu akış düşüşü

Yukarı bağlantı paket doldurma hizmetini gerçekleştiren UE için, verilerin 320 ms içinde yüklenememesi, tıpkı 5-1'de gösterilen eğri gibi birkaç M'lik bir trafik kaybına neden olabilir.

Şekil 5-1'deki kırmızı çubuklu grafikte veriler 320 ms'de yüklenemez, bu da trafiğin 1 saniye içinde "boşluk bırakmasına" neden olur. Mevcut anlaşmaya göre, bu sorun temelden çözülemez. Ancak bu tür bir "düşme" fenomeni olasılığından kaçınmak için bazı işlemler yapabiliriz.

Örneğin, DCIO'nun kaçırılmış tespitinin neden olduğu bir çukur düşmesi ise, eNB, Şekil 5-3'te gösterildiği gibi, uyarlamalı yeniden iletimi gerçekleştirmeye ve yeni iletimin MCS değerini kullanmaya devam edebilir. Gerçek test sonuçlarından yola çıkarak, bu işleme yöntemi yukarı akış trafiğinin "düşme" olasılığını etkili bir şekilde azaltabilir ve sistemin yukarı akış verimini iyileştirebilir.