IBM Cloud-mønstre: Privat trådløst netværk på IBM Cloud Satellite – IBM Blog

Udbydere af kommunikationstjenester (CSP'er) slår sig sammen med hyperskalere for at tilbyde private trådløse netværk, der ejes og administreres fuldt ud af den, der bygger dem. Et privat trådløst netværk (PWN) giver den samme form for tilslutning som offentlige trådløse netværk, og virksomheder skal afveje fordele og ulemper ved private trådløse netværk, der bruger 5G-teknologi. Det er vigtigt at forstå nogle af de almindelige mønstre såvel som ledelsesaspekterne af sådanne netværk, herunder de komponenter, der er nødvendige for at skabe PWN'er og deres arkitektur.  

Komponenter af et privat trådløst netværk 

Der er mange komponenter, der udgør et privat trådløst netværk, men disse er de vigtigste nødvendige elementer: 

• Spektrum refererer til de radiofrekvenser, der bruges til kommunikation (og er allokeret af staten). Valget af et licenseret eller ikke-licenseret radiospektrum afhænger af dækningskrav, interferensforhold og lovoverholdelse. 

• Netværkskerne er kontrolcenteret, der leverer pakkeskift, politikkontrol, autentificering, sessionsstyring, adgangs- og mobilitetsfunktion, routing og netværksstyring. 

• Radio Access Network (RAN) inkluderer Open RAN-baseret virtuel centraliseret enhed (vCU), virtuel distributionsenhed (vDU), radioenhed (RU), gateway og andet udstyr, der muliggør trådløs kommunikation mellem slutbrugerenheder og netværkskernen, der er pålidelig, effektiv og problemfri. 

Ved opbygning af et privat trådløst netværk er der behov for supplerende elementer som orkestrering, servicesikring, styring, overvågning og sikkerhed. Disse komponenter spiller en central rolle i at sikre problemfri drift, optimering og sikkerhed af det private trådløse netværk, hvilket bidrager til dets modstandsdygtighed og højtydende muligheder. 

Der er grundlæggende tre typer virksomheder, der er involveret i at bygge disse løsninger: 

• Telekommunikation (telco) leverandører som Nokia, Ericsson, Samsung og Mavenir 
• Hyperscalere som IBM, AWS, Azure og GCP 

• Kommunikationstjenesteudbydere som AT&T, Verizon og TELUS 

Telekommunikationsleverandører samarbejder med cloud-udbydere for at levere private trådløse netværk til virksomheder enten direkte eller gennem kommunikationstjenesteudbydere eller systemintegrator (SI) partnere. 

Figur 1. Netværksrelaterede komponenter i privat trådløst netværk 

Figur 1 viser de netværkskomponenter, som en CSP vil kræve, så de kan hjælpe kunder med at konfigurere et privat trådløst netværk. Disse er standard netværksrelaterede komponenter, som CSP'er er vant til at implementere. Historisk set blev mange af disse elementer konstrueret ved hjælp af dedikeret hardware. Der er imidlertid sket et væsentligt skift, hvor et stigende antal af disse komponenter er overgået til et cloud-native, softwarebaseret paradigme: det virtualiserede (i de fleste tilfælde containeriserede) radioadgangsnetværk, der inkluderer relaterede komponenter som en vCU, en vDU og virtualiseret netværkskerne. 

En repræsentativ containerbaseret vDU-arkitektur er vist som et eksempel i figur 2 for at give læseren en idé om, hvordan software har erstattet dedikeret specialbygget hardware i netværkskomponenter. Figur 2 viser også komponenterne i 5G-kernetjenestebaseret arkitektur. Alle komponenter er enten virtualiserede eller containeriserede. Dette er vigtigt, fordi det har givet hyperscalere en enorm mulighed i et rum domineret af teleselskaber. 

Figur 2 vDU-arkitektur , 5G kernekomponenter  

Den anden halvdel af løsningen er relateret til softwarekomponenter, som cloud-udbydere bringer for at udvide og fuldende løsningen. De kan spænde fra automatiseringsscripts til orkestrering, til servicegaranti og endda overvågning og logning. Det vigtigste aspekt er, at hyperscaleren leverer cloud-platformen til at hoste løsningen og de tilsvarende cloud-tjenester. Disse er vist i figur 3 som beigefarvede kasser.  

Figur 3. Software-relaterede støttefunktioner i privat trådløst netværk 

Fordele ved private trådløse netværk 

Disse selvstændige netværk kan implementeres i industrielle omgivelser, såsom produktionsgulve, logistiske varehuse, store hospitaler, sportsstadioner og virksomhedscampusser. Virksomheder behøver ikke at tage højde for begrænsningerne i et offentligt netværk. I stedet kan de implementere og have kontrol over et privat netværk, der opfylder deres nøjagtige behov. 

Figur 4 viser en eksemplarisk arkitektur, hvor det private trådløse netværk, der omfatter 5G RAN- og 5G-kernen, sammen med edge-applikationerne, er implementeret på en hyperscaler-platform. Et af hovedkravene er, at PWN'en skal installeres på stedet. Den topologi passer til IBM Cloud Satellite®-paradigme, hvor den lokale placering kan være en IBM Cloud Satellite-placering, der er forbundet til en IBM Cloud® region via et sikkert IBM Cloud Satellite-link. Dette design kan tjene virksomhedskunder, der ser på nærhed til påkrævede 5G-netværkskomponenter, som tilbyder lav latens- og højkapacitetskapacitet.  

Figur 4. Blokdiagram over et privat trådløst netværk  

Dette arkitekturmønster opfylder kravet om at betjene slutbrugerne, enheder og applikationer tættere på, hvor de er. For at understøtte missionskritiske brugssager i realtid placeres brugerplanapplikationer på IBM Cloud Satellite-lokationen. Disse satellitplaceringer kunne være et on-prem edge datacenter eller enhver offentlig skylokation.  

Arkitektering af privat trådløst netværk i IBM Cloud 

Ved at implementere et privat 5G-netværk kan store virksomheder bringe et tilpasset 5G-netværk til deres facilitet og holde det sikkert, mens de bruger dets højhastigheds-, højbåndbredde- og lav-latency-funktioner. Som de fleste netværksløsninger er der to dele af dette: "administreret fra" komponenterne og "administreret til" komponenterne. Komponenterne "administreret fra" hostes i partnering-hyperscalers-skyen, og "administreret til"-komponenterne er typisk i virksomhedens lokaler med sikker højhastighedsforbindelse mellem disse to lokationer. I vores eksempel er IBM Cloud vært for komponenterne "administreret fra", mens satellitplaceringen kører "administreret til"-komponenterne.  

Figur 5 viser et mønster, hvor det private trådløse netværk er installeret på stedet til venstre (på en "fjern" IBM Cloud Satellite-placering). De arbejdsbelastninger, der kører på denne satellitplacering, kan få adgang til understøttende tjenester, der er hostet i IBM Cloud til højre. Netværkskomponenterne leveret af et teleselskab er vist med blåt. De fleste af dem er installeret i satellitplaceringen, men nogle telekommunikationsstyringssystemer kan køre i skyen og kan potentielt tilbyde multitenancy-kapacitet til at understøtte flere virksomheder. 

Figur 5. Privat trådløst netværksarkitektur i IBM Cloud Satellite on-premises placering 

Forestil dig en produktionsfabrik, der har forskellige slags bevægelige og stationære robotter og andre programmerbare enheder, der opererer i anlægget. Virksomheden kunne vælge at anvende et privat trådløst netværk, fordi det vil fremskynde den inter-kommunikation, der er nødvendig for at betjene enhederne, samtidig med at tingene holdes sikre.  

I et sådant scenarie kunne produktionsanlægget konfigureres som en ekstern IBM Cloud Satellite-placering, der kører de nødvendige arbejdsbelastninger og cloud-relaterede komponenter på stedet. Endnu vigtigere er, at den netværksforbindelse, der kræves på stedet, vil blive leveret af PWN. Denne opsætning kan duplikeres i virksomhedens andre produktionsenheder eller deres partnerleverandører på tværs af staten eller landet. Hver enhed ville have sit eget PWN og være konfigureret som en IBM Cloud Satellite-placering. Alle disse satellitplaceringer vil blive administreret fra en IBM Cloud-region. 

Der kører et hovedkontrolplan i IBM Cloud, der overvåger alle satellitplaceringer og leverer centraliseret logning og sikkerhedstjenester som en del af de administrerede tjenester. IBM Cloud Site Reliability Engineers tager sig af alle systemopgraderinger og patching. Vi nævnte, at satellitforbindelsen mellem IBM Cloud Satellite-lokationen og IBM Cloud er en sikkerhedsrig TLS 1.3-tunnel. Virksomheder kunne også gøre brug af IBMs Direct Link-tjeneste til at oprette forbindelse. Du vil bemærke, at alle netværksforbindelser beskrevet i denne topologi er sikre.   

IBMs Cloud Pak for Network Automation (CP4NA) ville sammen med et Element Management System fra et teleselskab levere serviceorkestrerings- og servicegarantifunktioner. IBM Cloud ville levere overvågnings- og logningstjenester sammen med identitetsadgangsstyring for at få adgang til skymiljøet. Yderligere netværksovervågningstjenester kunne leveres af CSP'en. Dette understreger behovet for, at cloud-udbyderen arbejder tæt sammen med teleselskabet. Fra et virksomhedsperspektiv tjener virksomhedens brugergrænseflade til at maskere kompleksiteten og tilbyder en samlet grænseflade til strømlinet styring, levering af tjenester og omfattende overvågning og logning. Denne brugergrænseflade fungerer som en enestående kontrolhub, der forenkler driften og forbedrer den samlede effektivitet. 

Virksomheder, der ønsker at oprette et privat trådløst netværk, kan gøre det på egen hånd eller outsource det til en hyperscaler som IBM. Hyperscalere ender med at samarbejde med en CSP for at bygge og administrere disse netværk. Det er meget vigtigt at sikre sig, at netværket er bygget på en fleksibel platform og kan skaleres i fremtiden. Selvom virksomheder bør være opmærksomme på omkostningerne, vælger flere virksomheder PWN'er, fordi de giver et sikkert og pålideligt alternativ til et offentligt netværk. 

Få mere at vide om IBM Cloud Pak til netværksautomatisering