Analyser nøkkelkonfigurasjonsteknologien til IPTV end-to-end multicast push-nettverk

Som en ny høykvalitets internett-multimedietjeneste med høy båndbredde stiller IPTV høyere krav til teleoperatørers IP-bynett. Sammenlignet med den tradisjonelle unicast-teknologien har multicast-teknologien den fordelen at nettverksbåndbredden ikke øker lineært med antall brukere på grunnlag av tilsvarende overføringseffektivitet, og effektivt kan spare belastningen på videoserveren og bærernettverket. Derfor, for teleoperatører å distribuere og implementere IPTV-tjenester effektivt og økonomisk, anbefales det å bruke end-to-end multicast push, og konfigurasjonen av IP multicast-nettverket er nøkkelen.

For tiden består IP-hovedstadsnettverket av teleoperatører hovedsakelig av hovedstadsregionnett og bredbåndstilgangsnettverk, og IPTV-tjenestedata blir presset til brukerens slutt gjennom hovedstadsregionenettverk og bredbåndstilgangsnettverk i sin tur. Metro-backbone-nettverket består hovedsakelig av nettverkslagsenheter (lag 3), som kan gi multicast-rutingsprotokoller som PIM-SM tilgang til multicast-kilder (dvs. IPTV-headend-enheter) for ruting og videresending av multicast-pakker. Bredbåndsnettverket er hovedsakelig sammensatt av utstyr for datalinklag (lag 2), og teknologier som IGMP Proxy eller IGMP Snooping kan brukes til Layer 2 multicast-videresending for å få tilgang til IPTV-terminalutstyr (dvs. IPTV-dekoder). Figur 1 er et skjematisk diagram av en IPTV end-to-end multicast push-modell.

Denne artikkelen beskriver nøkkelkonfigurasjonsteknologiene til IPTV end-to-end multicast push-nettverk fra to forskjellige nettverksnivåer: metro-stamnettet og bredbåndstilgangsnettverket.

Hovedforskjellen mellom en multicast-melding og en unicast-melding er identifikasjonen av destinasjonsadressen til meldingen. Destinasjonsadressen til multicast-meldingen er multicast-gruppeadressen (klasse D IP-adresse som begynner med "1110"), og unicast-meldingen er basert på destinasjonens verts-IP. Adressen brukes som destinasjonsadresse. Siden det ikke er en en-til-en korrespondanse mellom multicast-gruppeadressen og destinasjonsverten, kan multicast-ruteren bare bruke det unike ved kildeadressen til meldingen for å ta rutingsbeslutninger. Med andre ord sender multicast-ruteren meldingen i retning bort fra multicast-kilden basert på kildeadressen til meldingen i stedet for destinasjonsadressen. Denne teknologien kalles reverse path forwarding (forkortet RPF).

For å unngå problemer som ruting av sløyfer, bestemmer RPF at multicast-pakker må nå ruteren fra den angitte oppstrømsnærnoden, og multicast-pakker som videresendes av andre nabo-noder kastes. Når det er et problem med multicast-ruting, kan det hende at multicast-pakker ikke kan nå gjennom andre baner som unicast-pakker, IPTV-direktesendingssignaler vil bli avbrutt i ryggradenettverket, og unicast-applikasjoner som surfing og sending og mottak av e-post er normale hindringer. På dette tidspunktet, langs multicast-distribusjonsstien, sjekk RPF-rutetabellen til multicast-ruteren og dens oppstrøms naboenoder.

Multicast-distribusjonstreet i PIM-SM-protokollen kan deles inn i to kategorier: kildetre og delt tre. Kildetreet bruker multicast-kilden som roten til treet, også kjent som det korteste banetreet, noe som kan minimere end-to-end multicast-forsinkelsen, men ruteren må lagre en stor mengde rutingsinformasjon, som bruker mye av systemressurser; det delte treet bruker RP (PIM-SM) En viktig ruter i protokollen, brukt til ruting og konvertering mellom multicast-kilder og multicast-rutere) Som vanlig rotnode for alle multicast-distribusjonstrær, må multicast-kildetrafikk først nå RP før den blir leveres, og multicast-banen er vanligvis ikke optimal. Det vil innføre ytterligere nettverksforsinkelse, men rutingsinformasjonen som ruteren trenger å beholde, kan være veldig liten.

PIM-SM-protokollen bruker full fordel av fordelene med de to multicast-distribusjonstrærne. I den innledende fasen av multicast kan multicast-ruteren ikke bruke kildetreet fordi det ikke kan vite plasseringen til multicast-kilden, men det kan oppnå de første få multicast-pakkene som sendes av multicast-kilden gjennom den kjente RP-noden og dens delte tre. Kjenn plasseringen til multicast-kilden og bytt fra det delte treet til kildetreet for å redusere nettverksforsinkelse og unngå nettverksflaskehalser som kan være forårsaket av RP-noder.

Metro-stamnettet er vanligvis hovedsakelig sammensatt av Cisco-rutere. Rutere som Cisco implementerer byttingen av multicast-distribusjonstreet gjennom den forhåndsinnstilte terskelen SPT-terskel for strømningshastigheten. Når det oppdages at multicast-strømningshastigheten til en multicast-kilde overstiger SPT-terskel, vil multicast-rutingen bytte fra det delte treet til kildetreet; på samme måte, hvis multicast-strømningshastigheten er lavere enn SPT-terskel, er multicast-rutingen. Du kan også bytte tilbake fra kildetreet til det delte treet. SPT-Threshold er vanligvis konfigurert som 0, slik at ruteren vil bytte fra det delte treet til kilden etter å ha mottatt den første multicast-pakken.

Som rotknutepunkt for det delte treet, spiller RP en rolle som kobling opp og ned i multicast-prosessen. Med tanke på at PIM-SM-protokollen har egenskapene til bytte av multicast-distribusjonstreet, brukes RP vanligvis til å etablere den innledende forbindelsen mellom multicast-kilden og multicast-ruteren. Når multicast-rutingen til ruteren er byttet fra det delte treet til kildetreet, vil det ikke RP og det delte treet er nødvendig igjen. Derfor er ikke plasseringen av RP i multicast-nettverket veldig viktig. Nøkkelen er dens pålitelighet og stabilitet.

For å forbedre påliteligheten og stabiliteten til RP, kan flere multicast-rutere velges for å dele funksjonen til RP (det vil si Anycast RP-teknologi), og loopback-grensesnittet til hver RP-node tildeles samme IP-adresse, og danner derved lastdeling og feilbeskyttelse.

RP-konfigurasjonsproblemet i multicast-nettverket er ikke bare relatert til konfigurasjonen og distribusjonen av selve RP-noden, men involverer også problemet med hvordan andre multicast-rutere lærer om RP-noden. I den innledende fasen av multicast kan det hende at multicast-ruteren ikke vet plasseringen til multicast-kilden, men RP-adressen må være kjent. Det er to hovedmåter for en multicast-ruter å skaffe seg en RP-adresse, det vil si den statiske konfigurasjons-RP-metoden og den automatiske oppdagelses-RP-metoden. Den statiske konfigurasjonen av RP er sikrere og kan effektivt forhindre falske aktiviteter som smiing av RP, men arbeidsmengden til nettverkskonfigurasjonen er stor, og den bidrar ikke til dynamisk justering av RP og andre noder; den automatiske oppdagelsen av RP kan redusere arbeidsmengden ved konfigurasjonen og legge til rette for nettverksendringer og kontrollstrategier. Justering, men det er visse sikkerhetsrisikoer. For et småskala hovedstadsnett, kan du bruke metoden for statisk konfigurering av RP på hver multicast-ruter; for et storstilet hovedstadsnettverk med streng sikkerhetsforsvarspolitikk, anbefales det å bruke metoden for automatisk å oppdage RP.

I den innledende fasen av multicast, får multicast-rutere vanligvis IPTV-headend (dvs. multicast-kilde) trafikk- og lokaliseringsinformasjon gjennom kjente RP-noder og deres delte trær. For at RP skal lære om multicast-kilden, er multicast-ruteren som er direkte koblet til multicast-kilden ansvarlig for å kapsle inn de første få multicast-pakkene som sendes av multicast-kilden i en egen PIM-registermelding, og initierer multicast til RP i unicast modus. Kildereegistreringsprosess. Gjennom denne meldingen kan RP ikke bare skaffe pakkene til multicast-gruppen av interesse, men også IP-adressen til multicast-kilden. Deretter videresender RP multicast-kildeinformasjonen til andre multicast-rutere, og avslutter multicast-kilderegistreringsprosessen med en PIM Registe-Stop-melding.

IPTV-klienten (set-top box) kommuniserer med multicast-ruteren (vanligvis utført av tjenesteruteren eller bredbåndstilgangsserveren) på metroen backbone nettverkstjenestetilgangskontrolllag gjennom IGMP-protokollen via bredbåndstilgangsnettverket for å bli med eller avslutte et bestemt Multicast-gruppe (dvs. live IPTV-kanal).

Når en digitalbox sender en multicast-gruppeforespørselmelding til en multicast-ruter, er destinasjonens MAC-adresse for meldingen MAC-adressen til multicast-gruppen i stedet for multicast-ruteren, som er forskjellig fra unicast-metoden. Det skal bemerkes at en MAC-adresse for multicast-gruppen faktisk tilsvarer 32 forskjellige IP-adresser for multicast-gruppen. Dette er fordi MAC-adressen til multicast-gruppen er 01: 00: 5E: 00: 00: 00 ～ 01: 00: 5E: 7F: FF: FF, det vil si at den effektive adresseplassen bare er 23 bits, og den effektive adresse til multicast-gruppen IP Det er 28 mellomrom.

Kartleggingsforholdet mellom de to er å likestille de nedre 23 bitene i MACC-adressen med de nedre 23 bitene i IP-adressen, noe som resulterer i tap av de øvre 5 bitene i multicast-gruppens IP-adresse. For eksempel, hvis tre forskjellige IPTV live-kanaler bruker 224.0.0.1, 224.128.0.1 og 239.128.0.1 som multicast-gruppens IP-adresser, er deres tilhørende multicast-gruppe MAC-adresser alle 01: 00: 5E: 00: 00:01, som vil føre til at set-top-boksen og det andre trinns utstyr i bredbåndstilgangsnettverket ikke klarer å skille mellom de tre signalene. Vær derfor oppmerksom på slike problemer når du planlegger multicast-IP-adresser.

Bredbåndstilgangsnettverket består av et stort antall nettverkselementenheter som Layer 2-brytere og DSLAM-er som kjører på datalinklaget. Funksjonen til Layer 2-utstyr er at den utveksler / videresender datarammer basert på MAC-adresser mellom enhetsporter, og har dårlige parsings- og rutefunksjoner for det tredje laget (nettverkslag) av IP-pakker, så det kan ikke direkte støtte IGMP som arbeider med tredje lag. Og andre multicast-protokoller. Når en typisk Layer 2-enhet som en bryter behandler IPTV multicast-trafikk, sender den multicast-datarammer til alle portene i henhold til ukjente destinasjonsadresser eller kringkastingsmetoder, noe som sannsynligvis vil forårsake problemer som kringkastingsstormer.

For å løse problemet med multicast-pakkeflom, må Layer 2 multicast-videresendingsteknologier, som IGMP Snooping og IGMP Proxy-teknologier, vedtas. IGMP Snooping-teknologien overvåker IGMP-meldingen mellom set-top-boksen og multicast-ruteren for å forstå videresendingsforholdet til enhetsporten til multicast-datarammen; mens IGMP Proxy-teknologi avlytter IGMP-meldingen mellom set-top-boksen og multicast-ruteren. Filtrering og proxy-videresending kan spare multicast-trafikk mellom multicast-ruteren og Layer 2-enheten, men det krever høye ytelsesindikatorer som prosesseringskapasitet og minne av nettverkselementenheten. Når du konfigurerer Layer 2-enheter, kan du velge i henhold til den faktiske ytelsen til nettverkselementenheten og graden av støtte for IGMP Snooping / Proxy-teknologi.

Ta en IPTV live-kanal med en båndbredde på 2 Mbit / s som et eksempel. Hvis Layer 2-enheten ikke bruker Layer 2 multicast-videresendingsteknologi, vil multicast-pakkene som sendes til alle IPTV-brukere videresendes til alle porter, selv om brukerporten har 10 Mbit / s. s Få tilgang til båndbredde, multicast-pakkene med 5 IPTV live-kanaler kan blokkeres; etter å ha tatt i bruk Layer 2 multicast-videresendingsteknologien, blir multicast-pakkene bare videresendt til portene med bruksforespørselen, og hvis hver port maksimalt bare er koblet til. For en IPTV-mottakerboks, maksimalt bare en multicast-pakke (det vil si 2 Mbit / s trafikk) av en live kanal blir videresendt til den tilsvarende porten.

Trafikken videresendt av Layer 2 multicast involverer bare IPTV multicast-tjenester og involverer ikke andre bredbåndstjenester. Derfor brukes teknologier som VLAN i bredbåndstilgangsnettverket vanligvis til å isolere IPTV multicast-trafikk fra andre tjenester og brukertrafikk. Vanlig brukte VLAN-teknologier inkluderer cross-VLAN multicast replikeringsteknologi fra multicast VLAN til hver bruker VLAN, og QinQ, som løser utilstrekkelig antall VLAN IDer

IPTV live-programmet leveres til brukerterminalen via IP-bærernettverket, og det er hovedsakelig to multicast-modus, nemlig dynamisk multicast-modus og statisk multicast-modus. I dynamisk multicast-modus vil brytere, DSLAM og andre enheter motta og levere kanalprogrammet først etter å ha mottatt den første brukerforespørselen om å bli med i en kanal (multicast-gruppe); og når kanalen (multicast-gruppen) varer Når en bruker logger av, vil nettverkselementenheten slutte å motta multicast-strømmen. Den statiske multicast-modusen er å statisk konfigurere MAC multicast-videresendingsoppføringene til hver IPTV-kanal (multicast-gruppe) på bytteutstyret, uavhengig av om nedstrømsbrukerne ser det eller ikke, multicast-strømmen har blitt levert til nettverkselementutstyret.

Statisk multicast-trafikk har ikke noe med antall IPTV-brukere å gjøre, bare antall kanaler og båndbredde per kanal. Når antall brukere er mindre enn antall kanaler, vil trafikken være større enn unicast-trafikken; maksimal trafikk for dynamisk multicast er når antall samtidige IPTV-brukere er mindre enn antall kanaler. Når antall IPTV-samtidige brukere er større enn antall kanaler, tilsvarer det statisk multicast-trafikk. I statisk multicast-modus er brukerens kanalomkoblingshastighet rask og tjenestens oppfatning er god, men behovet for båndbredde i nettverket er større; dynamisk multicast kan under alle omstendigheter minimere nettverkstrafikken, men når brukeren mottar en ny kanal (Multicast-gruppe), kan det være en viss nettverksforsinkelse.

Når antallet IPTV-brukere som er koblet til nettverksutstyret er veldig lite, er ikke fordelene med multicast åpenbare. I den innledende fasen av utviklingen av IPTV-tjenester er det derfor ikke mange IPTV-brukere, eller bredbåndstilgangsnettverket har ikke blitt rekonstruert på plass. Du kan bruke dynamisk multicast eller til og med unicast til å overføre IPTV live-signaler. Når antall brukere som er koblet til en nettverksenhet langt overstiger antall IPTV-kanaler, blir egenskapene til multicasting for å spare nettverkstrafikkbåndbredde mer og mer betydelig. På dette tidspunktet, det vil si når IPTV-tjenesten er utviklet til et modent stadium og transformasjonen av bredbåndstilgangsnettverket har vært på plass, kan den statiske multicast-modusen brukes til å overføre IPTV-live-signalet for ytterligere å forbedre IPTV-tjenestekvaliteten. Derfor kan operatører bestemme om de skal konfigurere tilgangsnettverksutstyret i en dynamisk eller statisk multicast-modus i henhold til faktiske forhold som nettverkskvalitet og IPTV-tjenestepenetrering.

Ved å kombinere det eksisterende IP-hovedstadsnettverket av teleoperatører, forklarer denne artikkelen systematisk nøkkelteknologiene for IPTV end-to-end multicast push-nettverkskonfigurasjon, som har en god referansebetydning for teleoperatører å distribuere og implementere IPTV-tjenester effektivt og økonomisk.

Hvor langt (lang) senderen dekke?

Rekkevidden avhenger av mange faktorer. Den virkelige avstand er basert på antennen installeres høyde, antenneforsterkning, ved hjelp miljø som bygning og andre hindringer, følsomheten til mottakeren, antennen til mottakeren. Installere antennen mer høy og bruke på landsbygda, avstanden vil mye mer langt.

Eksempel 5W FM-sender bruke i byen og hjemby:

Jeg har en USA kundens bruk 5W FM-sender med GP-antenne i hjembyen, og han teste den med en bil, det dekker 10km (6.21mile).

Jeg teste 5W FM-sender med GP-antenne i hjembyen min, det dekker ca 2km (1.24mile).

Jeg teste 5W FM-sender med GP-antenne i byen Guangzhou, det dekker omtrent bare 300meter (984ft).

Nedenfor er det tilnærmede område av forskjellige kraft FM-sendere. (Utvalget er diameter)

0.1W ~ 5W FM-sender: 100M ~ 1KM

5W ~ 15W FM Ttransmitter: 1KM ~ 3KM

15W ~ 80W FM-sender: 3KM ~ 10KM

80W ~ 500W FM-sender: 10KM ~ 30KM

500W ~ 1000W FM-sender: 30KM ~ 50KM

1KW ~ 2KW FM-sender: 50KM ~ 100KM

2KW ~ 5KW FM-sender: 100KM ~ 150KM

5KW ~ 10KW FM-sender: 150KM ~ 200KM

Hvordan kontakte oss for senderen?

Ring meg + 8618078869184 ELLER
Email meg [e-postbeskyttet]
1.How langt du ønsker å dekke i diameter?
2.How høyt av dere Tower?
3.Where er du fra?
Og vi vil gi deg mer faglige råd.

Om Oss

FMUSER.ORG er et systemintegrasjonsfirma som fokuserer på RF trådløs overføring / studio video lydutstyr / streaming og databehandling. Vi leverer alt fra råd og rådgivning gjennom rackintegrasjon til installasjon, igangkjøring og opplæring.

Vi tilbyr FM-sender, Analog TV-sender, Digital-TV-sender, VHF UHF-sender, Antenner, Koaksialkabelkontakter, STL, On Air-behandling, Broadcast-produkter for Studio, RF Signal Monitoring, RDS-kodere, Lydprosessorer og Remote Site Control Units, IPTV-produkter, Video / Audio Encoder / dekoder, designet for å møte behovene til både store internasjonale kringkastingsnettverk og små private stasjoner.

Vår løsning har FM-radiostasjon / Analog TV-stasjon / Digital TV-stasjon / Audio Video Studio-utstyr / Studio Transmitter Link / Transmitter Telemetry System / Hotel TV System / IPTV Live Broadcasting / Streaming Live Broadcast / Video Conference / CATV Broadcasting system.

Vi bruker avanserte teknologiprodukter til alle systemene, fordi vi vet at høy pålitelighet og høy ytelse er så viktige for systemet og løsningen. Samtidig må vi også sørge for at vårt produktsystem har en svært rimelig pris.

Vi har kunder fra offentlige og kommersielle kringkastingstjenester, telekomoperatører og reguleringsmyndigheter, og vi tilbyr også løsninger og produkter til mange hundre mindre, lokale og lokale kringkastere.

FMUSER.ORG har eksportert mer enn 15 år og har kunder over hele verden. Med 13 års erfaring innen dette feltet har vi et profesjonelt team for å løse kundens alle slags problemer. Vi er dedikert til å levere den ekstremt rimelige prisen på profesjonelle produkter og tjenester. Kontakt Epost : [e-postbeskyttet]

vår fabrikk

Vi har modernisering av fabrikken. Du er velkommen til å besøke vår fabrikk når du kommer til Kina.

I dag er det allerede 1095 kunder hele verden besøkt våre Guangzhou Tianhe kontor. Hvis du kommer til Kina, er du velkommen til å besøke oss.

på Fair

Dette er vår deltakelse i 2012 Global Sources Hong Kong Electronics Fair . Kunder fra hele verden endelig har en sjanse til å komme sammen.

Hvor er Fmuser?

Du kan søke i disse tallene " 23.127460034623816,113.33224654197693 "på google map, så finner du vårt fmuser-kontor.

FMUSER Guangzhou Kontoret ligger i Tianhe District, som er den midten av Canton . Veldig nær til Canton Fair , Guangzhou jernbanestasjon, Xiaobei veien og dashatou , Trenger bare 10 minutter hvis ta TAXI . Velkommen venner over hele verden til å besøke og forhandle.

Kontakt: Sky Blå
Mobil: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
E-post: [e-postbeskyttet]
QQ: 727926717
Skype: sky198710021
Adresse: No.305 Room Huilan Building No.273 Huanpu Road Guangzhou Kina Postnummer: 510620

Engelsk: Vi aksepterer alle betalinger, for eksempel PayPal, kredittkort, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Hvis du har spørsmål, kan du kontakte meg [e-postbeskyttet] eller WhatsApp + 8618078869184

PayPal.  www.paypal.com

Vi anbefaler at du bruker Paypal til å kjøpe våre produkter, er The Paypal en sikker måte å kjøpe på internett.

Hver av våre element liste siden bunnen på toppen har en paypal logo for å betale.

Kredittkort.Hvis du ikke har paypal, men du har kredittkort, kan du også klikke Yellow PayPal knappen for å betale med kredittkort.

-------------------------------------------------- -------------------

Men hvis du ikke har et kredittkort og ikke har en PayPal-konto eller vanskelig å fikk en paypal Kontoinnstillinger, kan du bruke følgende:
Western Union.  www.westernunion.com

Betal med Western Union til meg:

Fornavn / Fornavn: Yingfeng
Etternavn / etternavn / etternavn: Zhang
Fullt navn: Yingfeng Zhang
Land: Kina
By: Guangzhou

-------------------------------------------------- -------------------

T / T.  betal med T / T (wire transfer / telegrafisk overføring / Bank Transfer)
Første BANKINFORMASJON (SELSKAPSKONTO):

SWIFT BIC: BKCHHKHHXXX
Bank navn: BANK OF CHINA (HONG KONG) LIMITED, HONG KONG
Bankadresse: BANKEN AV KINA TOREN, 1 GARDEN ROAD, CENTRAL, HONG KONG
BANK KODE: 012
Kontonavn: FMUSER INTERNATIONAL GROUP LIMITED
Kontonr. : 012-676-2-007855-0

-------------------------------------------------- -------------------
Andre BANKINFORMASJON (SELSKAPSKONTO):
Mottaker: Fmuser International Group Inc.
Kontonummer: 44050158090900000337
Mottakerens bank: China Construction Bank Guangdong Branch
SWIFT-kode: PCBCCNBJGDX
Adresse: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, Kina
** Merk: Når du overfører penger til bankkontoen vår, vennligst IKKE skriv noe i kommentarområdet, ellers vil vi ikke kunne motta betalingen på grunn av myndighetens policy for internasjonal handel.

* Det vil bli sendt i 1-2 arbeidsdager når betaling klart.

* Vi vil sende den til din paypal adresse. Hvis du ønsker å endre adresse, send riktig adresse og telefonnummer til min e-post [e-postbeskyttet]

* Hvis pakkene er under 2kg, vil vi bli sendt via post luftpost, vil det ta ca 15-25days til hånden din.

Hvis pakken er mer enn 2kg, vil vi sende via EMS, DHL, UPS, Fedex rask ekspresslevering, vil det ta ca 7 ~ 15days til hånden din.

Hvis pakken mer enn 100kg, vil vi sende via DHL eller flyfrakt. Det vil ta om 3 ~ 7days til hånden din.

Alle pakkene er skjema Kina Guangzhou.

* Pakken sendes som en "gave" og avvises så lite som mulig, kjøper trenger ikke betale for "TAX".

* Etter skip, vil vi sende deg en e-post og gi deg sporingsnummeret.

For garanti.
Kontakt oss --- >> Returner varen til oss --- >> Motta og send en ny erstatning.

Navn: Liu Xiaoxia
Adresse: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Kina.
ZIP: 510620
Telefon: + 8618078869184

Vennligst gå tilbake til denne adressen og skriv din paypal adresse, navn, problem på merknad: