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

Kommunikasjonstjenesteleverandører (CSP-er) slår seg sammen med hyperskalere for å tilby private trådløse nettverk som eies og administreres fullt ut av den som bygger dem. Et privat trådløst nettverk (PWN) gir samme type tilkobling som offentlige trådløse nettverk, og bedrifter må veie fordeler og ulemper med private trådløse nettverk som bruker 5G-teknologi. Det er viktig å forstå noen av de vanlige mønstrene, så vel som administrasjonsaspektene ved slike nettverk, inkludert komponentene som trengs for å lage PWN-er og deres arkitektur.  

Komponenter i et privat trådløst nettverk 

Det er mange komponenter som utgjør et privat trådløst nettverk, men dette er de viktigste nødvendige elementene: 

• Spektrum refererer til radiofrekvensene som brukes til kommunikasjon (og er tildelt av staten). Valg av et lisensiert eller ulisensiert radiospektrum avhenger av dekningskrav, interferensforhold og overholdelse av forskrifter. 

• Nettverkskjernen er kontrollsenteret som gir pakkesvitsjing, policykontroll, autentisering, øktadministrasjon, tilgangs- og mobilitetsfunksjon, ruting og nettverksadministrasjon. 

• Radio Access Network (RAN) inkluderer Open RAN-basert virtuell sentralisert enhet (vCU), virtuell distribusjonsenhet (vDU), radioenhet (RU), gateway og annet utstyr som muliggjør trådløs kommunikasjon mellom sluttbrukerenheter og nettverkskjernen som er pålitelig, effektiv og sømløs. 

Ved utbygging av et privat trådløst nettverk er det behov for tilleggselementer som orkestrering, servicesikring, styring, overvåking og sikkerhet. Disse komponentene spiller en sentral rolle i å sikre sømløs drift, optimalisering og sikkerhet til det private trådløse nettverket, og bidrar til dets motstandskraft og høyytelsesevner. 

Det er i hovedsak tre typer selskaper som er involvert i å bygge disse løsningene: 

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

• Kommunikasjonstjenesteleverandører som AT&T, Verizon og TELUS 

Telekommunikasjonsleverandører samarbeider med skyleverandører for å levere private trådløse nettverk for bedrifter enten direkte eller gjennom kommunikasjonstjenesteleverandører eller systemintegrator (SI) partnere. 

Figur 1. Nettverksrelaterte komponenter i privat trådløst nettverk 

Figur 1 viser nettverkskomponentene som en CSP vil kreve slik at de kan hjelpe kunder med å konfigurere et privat trådløst nettverk. Dette er standard nettverksrelaterte komponenter som CSP-er er vant til å distribuere. Historisk sett ble mange av disse elementene konstruert ved hjelp av dedikert maskinvare. Imidlertid har det skjedd et betydelig skifte, med et økende antall av disse komponentene som går over til et skybasert, programvarebasert paradigme: det virtualiserte (i de fleste tilfeller containeriserte) radioaksessnettverk som inkluderer relaterte komponenter som en vCU, en vDU og virtualisert nettverkskjerne. 

En representativ containerbasert vDU-arkitektur er vist som et eksempel i figur 2 for å gi leseren en idé om hvordan programvare har erstattet dedikert spesialbygd maskinvare i nettverkskomponenter. Figur 2 viser også komponentene i 5G-kjernetjenestebasert arkitektur. Alle komponenter er enten virtualiserte eller containeriserte. Dette er viktig fordi det har gitt hyperskalere en enorm mulighet i et område dominert av teleselskaper. 

Figur 2 vDU-arkitektur og 5G kjernekomponenter  

Den andre halvparten av løsningen er knyttet til programvarekomponenter, som skyleverandører tar med for å utvide og komplettere løsningen. De kan variere fra automatiseringsskript, til orkestrering, til serviceforsikring og til og med overvåking og logging. Det viktigste aspektet er at hyperscaleren gir skyplattformen for å være vert for løsningen og de tilhørende skytjenestene. Disse er vist i figur 3 som beigefargede bokser.  

Figur 3. Programvarerelaterte støttefunksjoner for privat trådløst nettverk 

Fordeler med private trådløse nettverk 

Disse frittstående nettverkene kan distribueres i industrielle omgivelser som produksjonsbutikkgulv, logistikklager, store sykehus, sportsstadioner og bedriftscampus. Bedrifter trenger ikke å imøtekomme begrensningene til et offentlig nettverk. I stedet kan de distribuere og ha kontroll over et privat nettverk som dekker deres eksakte behov. 

Figur 4 viser en eksemplarisk arkitektur der det private trådløse nettverket som består av 5G RAN og 5G-kjernen, sammen med edge-applikasjonene, er distribuert på en hyperscaler-plattform. Et av hovedkravene er at PWN skal distribueres på stedet. Den topologien passer til IBM Cloud Satellite®-paradigme der den lokale plasseringen kan være en IBM Cloud Satellite-plassering som er koblet til en IBM Cloud® region via en sikker IBM Cloud Satellite-kobling. Denne utformingen kan tjene bedriftskunder som ser på nærhet til nødvendige 5G-nettverkskomponenter, som tilbyr lav latens og høy gjennomstrømningskapasitet.  

Figur 4. Blokkdiagram over et privat trådløst nettverk  

Dette arkitekturmønsteret oppfyller kravet om å betjene sluttbrukere, enheter og applikasjoner nærmere der de er. For å støtte oppdragskritiske brukssaker i sanntid, plasseres brukerplanapplikasjoner på IBM Cloud Satellite-lokasjonen. Disse satellittplasseringene kan være et lokalt datasenter eller en hvilken som helst offentlig skylokasjon.  

Arkitektering av privat trådløst nettverk i IBM Cloud 

Ved å implementere et privat 5G-nettverk kan store bedrifter bringe et tilpasset 5G-nettverk til anlegget sitt og holde det sikkert mens de bruker funksjonene med høy hastighet, høy båndbredde og lav latens. Som de fleste nettverksløsninger er det to deler av dette: "administrert fra"-komponentene og "administrert til"-komponentene. De "administrerte fra"-komponentene er vert i samarbeidende hyperscalers-skyen, og de "administrerte til"-komponentene er vanligvis på bedriftens lokaler med sikker høyhastighetstilkobling mellom disse to lokasjonene. I vårt eksempel er IBM Cloud vert for "administrert fra"-komponentene mens satellittposisjonen kjører "administrert til"-komponentene.  

Figur 5 viser et mønster der det private trådløse nettverket er distribuert lokalt til venstre (på et "eksternt" IBM Cloud Satellite-sted). Arbeidsbelastningene som kjører på den satellittposisjonen kan få tilgang til støttetjenester som er vert i IBM Cloud til høyre. Nettverkskomponentene levert av et teleselskap er vist i blått. De fleste av disse er utplassert på satellittstedet, men noen telekommunikasjonssystemer kan kjøres i skyen og kan potensielt tilby multitenancy-kapasitet for å støtte flere bedrifter. 

Figur 5. Privat trådløs nettverksarkitektur i IBM Cloud Satellite lokalt 

Se for deg et produksjonsanlegg som har forskjellige typer bevegelige og stasjonære roboter og andre programmerbare enheter som opererer i anlegget. Selskapet kan velge å bruke et privat trådløst nettverk fordi det vil øke hastigheten på interkommunikasjonen som er nødvendig for å betjene enhetene samtidig som det holder ting sikkert.  

I et slikt scenario kan produksjonsanlegget konfigureres som et eksternt IBM Cloud Satellite-sted som kjører de nødvendige arbeidsbelastningene og skyrelaterte komponenter på stedet. Enda viktigere er at nettverkstilkoblingen som kreves på stedet, blir levert av PWN. Dette oppsettet kan dupliseres i selskapets andre produksjonsenheter eller deres partnerleverandører, på tvers av staten eller landet. Hver enhet vil ha sin egen PWN og være konfigurert som en IBM Cloud Satellite-plassering. Alle disse satellittposisjonene vil bli administrert fra en IBM Cloud-region. 

Det er et hovedkontrollfly som kjører i IBM Cloud som overvåker alle satellittplasseringer og tilbyr sentraliserte logg- og sikkerhetstjenester som en del av de administrerte tjenestene. IBM Cloud Site Reliability Engineers tar seg av alle systemoppgraderinger og oppdateringer. Vi nevnte at satellittforbindelsen mellom IBM Cloud Satellite-lokasjonen og IBM Cloud er en sikkerhetsrik TLS 1.3-tunnel. Bedrifter kan også bruke IBMs Direct Link-tjeneste for å koble til. Du vil legge merke til at alle nettverkstilkoblingene beskrevet i denne topologien er sikre.   

IBMs Cloud Pak for Network Automation (CP4NA), sammen med et Element Management System fra en telekommunikasjon, vil gi funksjoner for orkestrering og servicesikring. IBM Cloud vil tilby overvåkings- og loggingstjenester sammen med administrasjon av identitetstilgang for tilgang til skymiljøet. Ytterligere nettverksovervåkingstjenester kan leveres av CSP. Dette understreker behovet for at skyleverandøren jobber tett med teleleverandøren. Fra et bedriftsperspektiv tjener bedriftsbrukergrensesnittet til å maskere kompleksiteten, og tilbyr et enhetlig grensesnitt for strømlinjeformet administrasjon, levering av tjenester og omfattende overvåking og logging. Dette brukergrensesnittet fungerer som et enkelt kontrollsenter, som forenkler operasjoner og forbedrer den generelle effektiviteten. 

Bedrifter som ønsker å sette opp et privat trådløst nettverk kan gjøre det på egen hånd eller sette det ut til en hyperscaler som IBM. Hyperscalere ender opp med å samarbeide med en CSP for å bygge og administrere disse nettverkene. Det er svært viktig å sørge for at nettverket er bygget på en fleksibel plattform og kan skaleres i fremtiden. Selv om bedrifter bør være klar over kostnadene, velger flere bedrifter PWN-er fordi de gir et sikkert og pålitelig alternativ til et offentlig nettverk. 

Lær mer om IBM Cloud Pak for Network Automation