Det behövs nya arkitekturer för radio- och åtkomstnätverk eftersom nätverksspecifikationerna för 5G New Radio (NR) hela tiden utvecklas, skriver Awanish Verma, chefsarkitekt, gruppen för trådbundet och trådlöst på Xilinx.

Även om 5G NR-arkitekturen innefattar ett nytt spektrum och massiva MIMO-antenner (mMIMO), måste motsvarande åtkomstnätverksarkitektur också utvecklas för att implementera de tjänster som definieras av 5G. Det handlar bland annat om bättre mobilt bredband, extremt tillförlitlig kommunikation med låg latens och massiv maskintypskommunikation.

Det krävs nätverksskivning på olika nivåer av nätverksaggregeringsnoder för att implementera dessa tjänster. Programvarulösningar kan dock inte hantera den ökade efterfrågan på latens och genomflöde, vilket skapar ett enormt behov av acceleration som bäst kan hanteras av anpassningsbar/programmerbar maskinvara. Låt oss utforska den första nivån av 5G-åtkomstnätverksaggregering som accelererats med adaptiva RF-SoCer (radiofrekvens).

3GPP-organisationen för standarder har definierat olika delade arkitekturer mellan 5G-radioenheter (RU) och 5G-basstationer. För att hantera dessa nya krav spelar olika delade arkitekturer som definierats av 3GPP en avgörande roll i att besluta om gNodeB-implementeringen. De högre lagerdelningarna definierar funktionalitetspartitionen mellan den centraliserade enheten (CU) och den distribuerade enheten (DU), medan den nedre lagerdelningen definierar den funktionella partitionen mellan RU och DU. Den nedre lagerdelningen (RU–DU) är mer kritisk och känslig vad gäller tid och latens och är inte standardiserad.

Figur 1: Det finns flera alternativ för nedre lagerdelning (klicka för större bild)

Split-8 är vanligare för traditionella 4G-LTE-nätverk medan Split-7.2 är vanligare för 5G-nätverk. Det finns flera varianter av 7.2-delning, så det kallas även alternativ 7–2x eftersom den kan flyttas till vänster eller höger baserat på distributionsscenarier. Se bilden ovan. Delningsalternativen är flexibla och gränssnittet mellan DU och RU är inte heller strikt definierat vad gäller gränssnittsprotokoll, bandbredd, latens och tid. Därför är oftast de anpassningsbara processorerna för gränssnitts- och funktionalitetsimplementering i både RU och DU lämpliga.

Kommersiellt tillgängliga nätverksgränssnittskort (NIC) kan användas för att avsluta fronthaul i DU:er på 5G-basstationer. ASIC-baserade kort kan dock bara bearbeta L2-L3-trafiken och är beroende av programvara för O-RAN-bearbetning. Dessutom är tidssynkroniseringsfunktionen inte tillgänglig i de flesta NIC:er för allmän användning.

Eftersom DU:er behöver strikt tidssynkronisering med radioenheter och angränsande basstationer måste de stödja original-, slav- och gränsklocklägen från en central GPS-klockkälla. En annan viktig tidsfunktion är klockkretsar som implementeras på basstationens maskinvara och som behövs för att upprätthålla klocksynkroniseringen vid förlust av referensklockan.

När radio-IQ-data från RU är tillgängliga för bearbetning måste de klassificeras som användarplan-, kontrollplan-, hanteringsplan- och synkroniseringsplandata i både upplänks- och nedlänksriktning. Genomflödet för protokollmeddelanden till synkroniserings- och hanteringsplan är betydligt lägre än U-Plane- och C-Plane-meddelanden, så för det mesta hanteras synkroniserings- och hanteringsmeddelanden i programvaran, med program som körs i användarutrymme.

3GPP-alternativet 7-2-delning definierar också en tydlig delning mellan funktioner med hög PHY och låg PHY. De med låg PHY, till exempel förhandskodning, FFT/IFFT och mappnings-/avmappningsfunktioner för resurselement (RE), implementeras antingen på fjärrradioenheten (RRU) eller i fronthaul gateway-nätverksnoden som aggregerar trafiken från Rus mellan RU och DU. Funktionerna med hög PHY, som huvudsakligen omfattar kodning/avkodning, skramling och modulering/demodulering, utförs i DU.

Figur 2: Implementering av 5G-alternativet 7-2-delning med adaptiv RFSoC från Xilinx (klicka för större bild)

Funktionerna med hög PHY i gNodeB (DU) kan utföras antingen helt i programvara eller i en kombination av programvara och anpassningsbar maskinvara. Uppdelningen mellan programvara och maskinvara för funktioner med hög PHY beror på många faktorer såsom:

* Övergripande prestandabegränsningar för programvara (eller maskinvara), dvs. programvara bör inte begränsa prestandan för maskinvara och vice versa.

* Latensöverväganden: Eftersom 5G-specifikationer innebär ett starkt latenskrav på olika klasser av tjänster bör uppdelningen inte påverka latensen negativt.

* Kompatibilitet med programvaru-API:er av branschstandard: Vissa av funktionerna med hög PHY har en standarddefinition av API:er för användarutrymme, så alla maskinvaruimplementeringar bör upprätthålla kompatibiliteten med standard-API:er för sömlös övergång.

Beskrivningen ovan förklarar vilken funktionalitet som krävs för programmerbara maskinvarubaserade acceleratorer från företag som Xilinx. Den perfekta acceleratorarkitekturen kan kräva fullständig implementering av 5G med hög PHY i maskinvaran, vilket möjliggör högsta prestanda och lägsta latens samtidigt som den skalas över flera mMIMO-baserade RRU-konfigurationer.

Med de framväxande 5G- och O-RAN-standarderna och -funktionaliteten har Xilinx börjat med O-RAN-bearbetning och implementering av lookaside-kanalkodning/-avkodning på programmerbara acceleratorkort. Kanalkodning är en av lager-1-funktionerna med hög Phy, som är mest lämplig för anpassningsbar maskinvara (ASOCs) på grund av dess beräkningsintensiva egenskaper. Den kan även kombineras med funktioner för automatisk återkommande hybridbegäran (HARQ) för att ytterligare förbättra prestandan och sänka latensen.

5G L1-funktioner med hög PHY kan accelereras med hjälp av den anpassningsbara och programmerbara Xilinx T-serien, Telco-acceleratorkort. Dessa kort har adaptiv RFSoC som härdar SD FEC-blocken (Soft Decision based Forward Error Correction) och implementerar HARQ-funktioner med inbyggt DRAM-minne för högre och skalbara prestanda.

Awanish Verma, chefsarkitekt, gruppen för trådbundet och trådlöst på Xilinx

Filed under: FPGA