5G տրանսպորտի երթուղիչը գալիս է «5G ready» բնութագրով՝ 100G պորտեր, հիերարխիկ QoS, PTP boundary clock։ Օպերատորին այլ թվեր են պետք։ Արդյո՞ք URLLC դասը մնում է իր ուշացման բյուջեի մեջ, երբ backhaul-ը լի է վիդեոյով։ Քանի՞ միլիվայրկյան են կորցնում թունելները, երբ օղակի կապուղին խզվում է։ Արդյո՞ք սարքը պահում է համաժամեցումը, մինչ այս ամենը կատարվում է։ Այդ թվերն ենք մենք չափում։
Ստենդը
Փորձարկվող սարքը (DUT) կայանի երթուղիչ է, ագրեգացիայի երթուղիչ կամ fronthaul կոմուտատոր՝ 8-ից 32 պորտով, 10G և 100G, 400G և ավելի արագ՝ ըստ նախագծի։ Ռադիո ստենդում չկա՝ ոչ ռադիոբլոկներ, ոչ եթեր։ Երկու ծայրը խաղում է գեներատորը։ RAN-ի կողմից այն էմուլյացնում է gNB-ներ GTP-U թունելներով և Ձեր բջիջների սեսիաների խառնուրդով՝ N3-ով և F1-U-ով, որտեղ RAN-ը բաժանված է, իսկ միջուկի կողմից ընդունում է յուրաքանչյուր թունել և չափում յուրաքանչյուր հոսք։ Երկու ծայրը նույն գեներատորի վրա են, ուստի միակողմանի ուշացումը չափվում է մեկ ժամացույցով։ Սա 5G-ի և բջջային միջուկի էջի տրանսպորտային դասն է։
Fronthaul-ն առանձին դեպք է՝ ռադիոազդանշանը eCPRI-ով, մեկ ուղղությամբ մոտ 100 մկվ բյուջեով։ Հոսքերի պրոֆիլը վերցնում ենք Ձեր դիզայնից, իսկ հիմնական թիվն այստեղ միակողմանի ուշացումն է այդ բյուջեի դեմ։ QoS-ի, երթուղավորման, պաշտպանության և համաժամեցման կարգավորումները Ձերն են։
Ինչ ենք ստուգում
- GTP-U throughput. թունելներ էմուլյացված gNB-ներից՝ 10G-100G պորտի վրա, թունելի վերնագրերով և Ձեր կադրերի չափերով
- Ուշացում և jitter ըստ դասերի. URLLC, ձայն, eMBB, ազդանշանում և համաժամեցում, յուրաքանչյուրն իր հերթում, բեռի աստիճաններում, օրինակ՝ 30, 70 և 90%, հատվածի բյուջեի դեմ
- QoS ծայրից ծայր. յուրաքանչյուր թունելի արտաքին DSCP-ն ճիշտ հերթ է ընկնում յուրաքանչյուր hop-ում, վերանշում այնտեղ, որտեղ դիզայնն է պահանջում
- Բեռի բաշխում. հազարավոր թունելներ մի քանի gNB և UPF հասցեների միջև՝ ECMP ուղիներով և LAG-ի անդամներով, անհավասարակշռությունն ըստ կապուղու
- Կորստի պատուհան. օղակի կապուղին անջատված է, հանգույցը վերագործարկված է, տրաֆիկն անցել է պահուստային ուղու վրա, ընդհատումն ըստ դասի և հոսքի՝ միլիվայրկյաններով
- Համաժամեցում. PTP-ն էմուլյացնում ենք մեր գեներատորներով և ստուգում, թե արդյոք սարքը լրիվ բեռի տակ համաժամեցման դասը պահում է օգտատիրական տրաֆիկից առաջ և չի կորցնում կապը խափանման ժամանակ
- Soak. 24 ժամ չափված հզորության 80%-ով՝ բոլոր դասերով
Ինչ դեռ չենք չափում. time error-ը նանովայրկյաններով՝ սարքի ժամացույցի դասի դեմ։ Դրա համար պետք է առանձին համաժամեցման անալիզատոր, որը ստենդում դեռ չկա, ուստի ամբողջական վերլուծությունը կազմակերպում ենք ըստ նախագծի, և այժմ նման նախագծեր ենք հավաքում։ Դասերով ընդունումը կարելի է անցկացնել Y.1564-ով։
Ինչն է սովորաբար խափանվում
QoS նշումը։ gNB-ն նշում է ներքին փաթեթը և արտաքին վերնագիրը թողնում զրոյով, իսկ տրանսպորտի երթուղիչները կարդում են միայն արտաքինը։ Բոլոր դասերը, URLLC-ն էլ, գնում են best effort-ով։ 90%-ի դեպքում ցածր ուշացման դասն իրեն պահում է վիդեոյի պես։
Երկրորդ դեպք. բեռի բաշխումը։ Մեկ gNB-ի և մեկ UPF-ի միջև թունելներն ունեն ընդհանուր արտաքին հասցեներ և հաճախ ընդհանուր UDP պորտեր, ուստի երթուղիչը, որը hash է անում այդ դաշտերով, բոլորին դնում է մեկ կապուղու վրա։ Օրինակ. LAG-ի մեկ 100G անդամը բեռնված է 95%-ով, երեքը գրեթե դատարկ են, և քառորդով լցված ցանցում կորուստներ կան։ Օգնում է hash-ը թունելի ID-ով, եթե սարքը դա կարողանում է։
Երրորդ դեպք. համաժամեցումը բեռի տակ։ PTP հաղորդագրությունները նույն հերթում են օգտատիրական տրաֆիկի հետ, և լրիվ բեռի դեպքում դրանց ուշացումն այնքան է տատանվում, որ սարքը կորցնում է կապը։ Ստենդում դա վիճակի փոփոխություն է բեռի հայտնի աստիճանում։ Ցանցում այն հասնում է TDD ռադիոներին որպես բջիջների միջև ինտերֆերենցիա, և այդ խնդիրը դժվար է կապել հերթի հետ։
Ինչ կա հաշվետվության մեջ
Throughput ըստ պորտերի և խառնուրդների։ Ուշացում և jitter ըստ դասերի բեռի յուրաքանչյուր աստիճանում՝ հատվածի բյուջեի կողքին։ Կորստի պատուհանն աղյուսակով՝ իրադարձություն, դաս, ընդհատում միլիվայրկյաններով, ամենավատ և միջին հոսք։ Բեռի բաշխումն ըստ կապուղիների։ Համաժամեցման բաժինը՝ կապի վիճակով ըստ սցենարների և նշումով, որ ստուգումն արվել է էմուլյացված PTP-ով։ Սարքի կոնֆիգուրացիան, էմուլյացված gNB-ների և թունելների կարգավորումները, firmware-ը և պորտերը, որպեսզի վենդորը կարողանա կրկնել ցանկացած կետ։ Նույն երթուղիչների վրա անցնում են նաև երթուղավորման և կոմուտացիայի BGP, IS-IS և segment routing թեստերը։
Որտեղից սկսել
Ուղարկեք մեզ երթուղիչի կամ կոմուտատորի մոդելը, firmware-ի տարբերակը, որով նախատեսում եք աշխատել, և տրանսպորտի դիզայնը՝ հատվածները, QoS mapping-ը, պաշտպանության սխեման և համաժամեցման պլանը։ Մենք պատասխանում ենք պլանի նախագծով՝ ինչ ենք ստուգում, ինչպես ենք հավաքում ստենդը և ժամկետները։ Հաշվետվությունը մնում է Ձեզ, և Դուք կարող եք այն ցույց տալ վենդորին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։