Analysera nyckelkonfigurationstekniken för IPTV end-to-end multicast push-nätverk

Som en ny multimedietjänst med hög bandbredd och hög kvalitet ställer IPTV högre krav på teleoperatörernas IP-storstadsnät. Jämfört med den traditionella unicast-tekniken har multicast-tekniken fördelen att nätverksbandbredden inte ökar linjärt med antalet användare på grundval av motsvarande överföringseffektivitet och effektivt kan spara belastningen på videoservern och bärarnätverket. Därför rekommenderas att telekomoperatörer distribuerar och implementerar IPTV-tjänster effektivt och ekonomiskt att använda multicast-push från slut till slut, och konfigurationen av IP multicast-nätverket är nyckeln.

För närvarande består IP-storstadsnätet av teleoperatörer huvudsakligen av huvudstadsregionnät och bredbandsaccessnät, och IPTV-servicedata skjuts till användaränden genom storstadsregionnät och bredbandsaccessnät i sin tur. Metro-stamnätverket består huvudsakligen av nätverkslager (lager 3) -enheter, som kan göra det möjligt för multicast-routningsprotokoll som PIM-SM att få tillgång till multicast-källor (dvs. IPTV-head-end-enheter) för dirigering och vidarebefordran av multicast-paket. Bredbandsaccessnätverket består huvudsakligen av datalänklager (lager 2) -utrustning och tekniker som IGMP Proxy eller IGMP Snooping kan användas för Layer 2 multicast-vidarebefordran för att få tillgång till IPTV-terminalutrustning (dvs. IPTV-digitalboxar). Figur 1 är ett schematiskt diagram av en IPTV end-to-end multicast push-modell.

Den här artikeln beskriver de viktigaste konfigurationsteknikerna för IPTV end-to-end multicast push-nätverk från två olika nätverksnivåer: tunnelbana-nätverket och bredbandsaccessnätverket.

Huvudskillnaden mellan ett multicast-meddelande och ett unicast-meddelande är identifieringen av meddelandets destinationsadress. Multicast-meddelandets destinationsadress är multicast-gruppadressen (IP-adress av klass D som börjar med "1110") och unicast-meddelandet baseras på destinationsvärdens IP. Adressen används som destinationsadress. Eftersom det inte finns någon en-till-en-korrespondens mellan multicast-gruppadressen och destinationsvärden kan multicast-routern endast använda det unika med källadressen för meddelandet för att fatta routningsbeslut. Med andra ord skickar multicastroutern meddelandet i riktning bort från multicastkällan baserat på källadressen till meddelandet istället för destinationsadressen. Denna teknik kallas reverse path forwarding (RPF förkortat).

För att undvika problem som dirigering av slingor föreskriver RPF att multicast-paket måste nå routern från den angivna uppströmsnoden, och multicast-paket som vidarebefordras av andra angränsande noder kasseras. När det finns ett problem med multicast-dirigering kanske multicast-paket inte kan nå andra vägar som unicast-paket, IPTV-direktsändningssignaler kommer att avbrytas i stamnätet och unicast-applikationer som webbläsning och e-postsändning och -mottagning är normala hinder. Vid den här tiden, längs multicast-distributionsvägen, kontrollera RPF-routningstabellen för multicast-routern och dess uppströms angränsande noder.

Multicast-distributionsträdet i PIM-SM-protokollet kan delas in i två kategorier: källträd och delat träd. Källträdet använder multicast-källan som roten till trädet, även känt som trädet för kortaste sökvägen, vilket kan minimera end-to-end multicast-fördröjningen, men routern måste lagra en stor mängd routningsinformation, vilket förbrukar mycket av systemresurser; det delade trädet använder RP (PIM-SM) En viktig router i protokollet, som används för routing och konvergering mellan multicast-källor och multicast-routrar) Som den gemensamma rotnoden för alla multicast-distributionsträd måste multicast-källtrafik först nå RP innan den är levereras, och multicast-vägen är vanligtvis inte optimal, det kommer att införa ytterligare nätverksfördröjning, men routningsinformationen som routern behöver behålla kan vara mycket liten.

PIM-SM-protokollet utnyttjar fördelarna med de två multicast-distributionsträdarna till fullo. I det inledande skedet av multicast kan multicast-routern inte använda källträdet eftersom det inte kan veta platsen för multicast-källan, men det kan få de första få multicast-paketen som skickas av multicast-källan genom den kända RP-noden och dess delade träd. Känn platsen för multicastkällan och växla från det delade trädet till källträdet för att minska nätverksfördröjningen och undvika nätverksflaskhalsar som kan orsakas av RP-noder.

Metro-stamnätverket består vanligtvis huvudsakligen av Cisco-routrar. Routrar som Cisco implementerar omkopplingen av multicast-distributionsträdet genom den förinställda tröskeln SPT-tröskel för flödeshastigheten. När det detekteras att multicast-flödeshastigheten för en multicast-källa överstiger SPT-tröskel, kommer dess multicast-routing att växla från det delade trädet till källträdet; på samma sätt, om multicastflödet är lägre än SPT-Threshold, dess multicast-routing. Du kan också växla tillbaka från källträdet till det delade trädet. SPT-tröskel är vanligtvis konfigurerad som 0, så att routern byter från det delade trädet till källan efter att ha fått det första multicast-paketet.

Som rotnod för det delade trädet spelar RP en roll som länkande upp och ner i multicast-processen. Med tanke på att PIM-SM-protokollet har egenskaperna för multicast-distributionsträdväxling används RP vanligtvis för att upprätta den initiala anslutningen mellan multicast-källan och multicast-routern. När multicast-routningen av routern har bytts från det delade trädet till källträdet kommer det inte att RP och dess delade träd behövs igen. Därför är platsen för RP i multicast-nätverket inte särskilt viktig. Nyckeln är dess tillförlitlighet och stabilitet.

För att förbättra tillförlitligheten och stabiliteten hos RP kan flera multicast-routrar väljas för att dela funktionen för RP (det vill säga Anycast RP-teknik), och loopback-gränssnittet för varje RP-nod tilldelas samma IP-adress och bildar därmed lastdelning och felskydd.

RP-konfigurationsproblemet i multicast-nätverket är inte bara relaterat till konfigurationen och distributionen av RP-noden i sig utan involverar också problemet med hur andra multicast-routrar lär sig om RP-noden. I det inledande skedet av multicast kanske multicast-routern inte vet platsen för multicast-källan, men RP-adressen måste vara känd. Det finns två huvudsakliga sätt för en multicast-router att få en RP-adress, det vill säga den statiska konfigurations-RP-metoden och den automatiska upptäckten RP-metoden. Den statiska konfigurationen av RP är säkrare och kan effektivt förhindra bedrägliga aktiviteter som smide RP, men arbetsbelastningen för nätverkskonfiguration är stor och det bidrar inte till dynamisk justering av RP och andra noder; den automatiska upptäckten av RP kan minska arbetsbelastningen för konfigurationen och underlätta nätverksändringar och kontrollstrategier. Justering, men det finns vissa säkerhetsrisker. För ett småskaligt huvudstadsregionnät kan du använda metoden för statisk konfigurering av RP på varje multicast-router; för ett storskaligt huvudstadsnätverk med strikt säkerhetspolicy, rekommenderas att man använder metoden för att automatiskt upptäcka RP.

I det inledande skedet av multicast, får multicast-routrar i allmänhet trafik- och platsinformation för IPTV-huvudändning (dvs. multicast-källa) genom kända RP-noder och deras delade träd. För att RP ska lära sig om multicast-källan är multicast-routern direkt ansluten till multicast-källan ansvarig för att inkapsla de första få multicast-paketen som skickas av multicast-källan i ett separat PIM-registermeddelande och initierar multicast till RP i unicast läge. Källregistreringsprocess. Genom detta meddelande kan RP inte bara erhålla paketen för multicast-gruppen av intresse utan också IP-adressen för multicast-källan. Därefter vidarebefordrar RP multicast-källinformationen till andra multicast-routrar och avslutar registreringsprocessen för multicast-källan med ett PIM Registe-Stop-meddelande.

IPTV-klienten (set-top box) kommunicerar med multicast-routern (vanligtvis utförs av tjänstroutern eller bredbandsaccesservern) på tunnelbanan nätverkstjänståtkomstkontrollskikt genom IGMP-protokollet via bredbandsaccessnätverket för att gå med eller avsluta ett specifikt Multicast-grupp (dvs. IPTV live-kanal).

När en digitalbox skickar ett multicast-gruppanslutningsförfrågningsmeddelande till en multicast-router är destinations-MAC-adressen för meddelandet MAC-adressen för multicast-gruppen istället för multicast-routern, vilket skiljer sig från unicast-metoden. Det bör noteras att en multicast-grupp MAC-adress faktiskt motsvarar 32 olika multicast-grupp-IP-adresser. Detta beror på att MAC-adressen för multicast-gruppen är 01: 00: 5E: 00: 00: 00 ～ 01: 00: 5E: 7F: FF: FF, det vill säga det effektiva adressutrymmet är bara 23 bitar och det effektiva adress för multicast-gruppen IP Det finns 28 mellanslag.

Kartläggningsförhållandet mellan de två är att jämföra de nedre 23 bitarna i MACC-adressen med de nedre 23 bitarna i IP-adressen, vilket resulterar i förlust av de övre 5 bitarna i multicast-gruppens IP-adress. Till exempel, om tre olika IPTV-livekanaler använder 224.0.0.1, 224.128.0.1 och 239.128.0.1 som multicast-gruppens IP-adresser, är deras motsvarande multicast-grupp MAC-adresser alla 01: 00: 5E: 00: 00:01, vilket kommer att orsaka att digitalboxen och den andra nivån i bredbandsaccessnätet inte kan skilja på de tre signalerna. Var därför uppmärksam på sådana frågor när du planerar multicast-IP-adresser.

Bredbandsaccessnätverket består av ett stort antal nätverkselementenheter såsom Layer 2-switchar och DSLAM som körs vid datalänkskiktet. Funktionen i Layer 2-utrustning är att den utbyter / vidarebefordrar dataramar baserat på MAC-adresser mellan enhetsportar och har dåliga parsnings- och routningsfunktioner för det tredje lagret (nätverkslager) av IP-paket, så det kan inte direkt stödja IGMP som arbetar med tredje lagret. Och andra multicast-protokoll. När en typisk Layer 2-enhet, såsom en switch, bearbetar IPTV-multicast-trafik, sänder den multicast-dataramar till alla sina portar enligt okända destinationsadresser eller sändningsmetoder, vilket sannolikt kommer att orsaka problem som broadcast-stormar.

För att lösa problemet med översvämning av multicast-paket måste Layer 2 multicast-vidarebefordransteknik, såsom IGMP Snooping och IGMP Proxy-teknik, antas. IGMP Snooping-tekniken övervakar IGMP-meddelandet mellan digitalboxen och multicast-routern för att förstå enhetsportens vidarebefordran till multicast-dataramen; medan IGMP Proxy-tekniken avlyssnar IGMP-meddelandet mellan digitalboxen och multicast-routern Filtrering och proxy-vidarebefordran kan spara multicast-trafik mellan multicast-routern och Layer 2-enheten, men det kräver höga prestandaindikatorer som bearbetningskapacitet och minne nätverkselementenheten. När du konfigurerar Layer 2-enheter kan du välja beroende på nätverkselementenhetens faktiska prestanda och graden av stöd för IGMP Snooping / Proxy-teknik.

Ta en IPTV live-kanal med en bandbredd på 2 Mbit / s som ett exempel. Om Layer 2-enheten inte använder Layer 2-vidarebefordransteknik vidarebefordras multicast-paketen som skickas till alla IPTV-användare till alla portar, även om användarporten har 10 Mbit / s. s Åtkomst till bandbredd kan multicast-paketen med 5 IPTV live-kanaler blockeras. efter att ha antagit Layer 2-vidarebefordransteknik vidarebefordras multicast-paketen endast till portarna med användningsförfrågan, och om varje port är högst endast ansluten För en IPTV-digitalbox, högst bara ett multicast-paket (det vill säga 2 Mbit / s trafik) av en livekanal vidarebefordras till motsvarande port.

Trafiken som vidarebefordras av Layer 2 multicast involverar endast IPTV multicast-tjänster och omfattar inte andra bredbandstjänster. Därför används i bredbandsaccessnätet vanligtvis tekniker som VLAN för att isolera IPTV multicast-trafik från andra tjänster och användartrafik. Vanligt använda VLAN-tekniker inkluderar cross-VLAN multicast replikeringsteknik från multicast VLAN till varje användares VLAN och QinQ, som löser otillräckligt antal VLAN ID

IPTV live-programmet levereras till användarterminalen via IP-bärarnätverket, och det finns huvudsakligen två multicast-lägen, nämligen dynamiskt multicast-läge och statiskt multicast-läge. I dynamiskt multicast-läge kommer switchar, DSLAM och andra enheter att ta emot och leverera kanalprogrammet först efter att ha mottagit den första användarförfrågan om att gå med i en kanal (multicast-grupp); och när kanalen (multicast-gruppen) varar När en användare loggar ut kommer nätverkselementenheten att sluta ta emot multicast-strömmen. Det statiska multicast-läget är att statiskt konfigurera MAC-multicast-vidarebefordringsposterna för varje IPTV-kanal (multicast-grupp) på växlingsutrustningen, oavsett om nedströmsanvändarna tittar på den eller inte, multicast-strömmen har levererats till nätverkselementutrustningen.

Statisk multicast-trafik har inget att göra med antalet IPTV-användare, bara antalet kanaler och bandbredd per kanal. När antalet användare är mindre än antalet kanaler kommer trafiken att vara större än unicast-trafiken. den maximala trafiken för dynamisk multicast är när antalet samtidiga IPTV-användare är mindre än antalet kanaler När antalet IPTV-samtidiga användare är större än antalet kanaler motsvarar det statisk multicast-trafik. I det statiska multicast-läget är användarens kanalomkopplingshastighet snabb och tjänsteuppfattningen bra, men efterfrågan på nätverksbandbredden är större; dynamisk multicast kan under alla omständigheter minimera nätverkstrafiken, men när användaren tar emot en ny kanal (Multicast-grupp) kan det finnas en viss nätverksfördröjning.

När antalet IPTV-användare som är anslutna till nätverksutrustningen är mycket litet är fördelarna med multicast inte uppenbara. I det inledande skedet av utvecklingen av IPTV-tjänster finns det därför inte många IPTV-användare eller så har bredbandsaccessnätet inte rekonstruerats på plats. Du kan använda dynamisk multicast eller till och med unicast för att sända IPTV live-signaler. När antalet användare som är anslutna till en nätverksenhet långt överstiger antalet IPTV-kanaler, blir egenskaperna hos multicasting för att spara nätverkstrafikbredd mer och mer betydelsefulla. Vid denna tidpunkt, det vill säga när IPTV-tjänsten har utvecklats till ett moget stadium och transformationen av bredbandsaccessnätverket har varit på plats, kan det statiska multicast-läget användas för att sända IPTV-live-signalen för att ytterligare förbättra IPTV-tjänstens kvalitet. Därför kan operatörer bestämma om de ska konfigurera åtkomstnätverksutrustningen i ett dynamiskt eller statiskt multicast-läge enligt faktiska förhållanden såsom nätverkskvalitet och IPTV-tjänstens penetration.

I det här dokumentet kombineras det befintliga IP-storstadsnätet för teleoperatörer och systematiskt de viktigaste teknologierna för IPTV end-to-end multicast push-nätverkskonfiguration, vilket har en god referensbetydelse för teleoperatörer att distribuera och implementera IPTV-tjänster effektivt och ekonomiskt.

Hur långt (lång) mätarens hölje?

Räckvidden beror på många faktorer. Den sanna avståndet baseras på antennen installera höjd, antennförstärkning, med användning av miljö som byggnad och andra hinder, känsligheten hos mottagaren, antennen hos mottagaren. Installera antennen mer hög och att använda på landsbygden, avståndet kommer mycket mer långt.

EXEMPEL 5W FM-sändare användning i staden och hemstad:

Jag har en USA kund användning 5W fm-sändare med GP-antenn i sin hemstad, och han testa den med en bil, det täcker 10km (6.21mile).

Jag testar 5W FM-sändare med GP-antenn i min hemstad, det täcker om 2km (1.24mile).

Jag testar 5W FM-sändare med GP-antenn i Guangzhou, det täcker ungefär endast 300meter (984ft).

Nedan är den ungefärliga mängd olika effekt FM-sändare. (Intervallet är diameter)

0.1W ~ 5W FM-sändare: 100M ~ 1KM

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

15W ~ 80W FM-sändare: 3KM ~ 10KM

80W ~ 500W FM-sändare: 10KM ~ 30KM

500W ~ 1000W FM-sändare: 30KM ~ 50KM

1KW ~ 2KW FM-sändare: 50KM ~ 100KM

2KW ~ 5KW FM-sändare: 100KM ~ 150KM

5KW ~ 10KW FM-sändare: 150KM ~ 200KM

Hur man kontaktar oss för sändaren?

Ring mig + 8618078869184 ELLER
Maila mig [e-postskyddad]
1.How långt du vill täcka i diameter?
2.How tall av er torn?
3.Where kommer du ifrån?
Och vi kommer att ge dig mer professionell rådgivning.

Om Oss

FMUSER.ORG är ett systemintegreringsföretag med inriktning på RF-trådlös överföring / studio video ljudutrustning / streaming och databehandling. Vi tillhandahåller allt från rådgivning och konsultation genom rackintegration till installation, idrifttagning och träning.

Vi erbjuder FM-sändare, analoga tv-sändare, digital-tv-sändare, VHF UHF-sändare, antenner, koaxialkabelkontakter, STL, luftbehandlingssystem, broadcast-produkter för studien, RF-signalövervakning, RDS-kodare, ljudprocessorer och fjärrkontrollenheter, IPTV Products, Video / Audio Encoder / Decoder, utformad för att möta behoven hos både stora internationella broadcast-nät och små privata stationer.

Vår lösning har FM Radio Station / Analog TV Station / Digital TV Station / Audio Video Studio Equipment / Studio Transmitter Link / Transmitter Telemetry System / Hotel TV System / IPTV Live Broadcasting / Streaming Live Broadcast / Video Conference / CATV Broadcasting system.

Vi använder avancerade teknologiprodukter för alla system, eftersom vi vet att hög tillförlitlighet och hög prestanda är så viktiga för systemet och lösningen. Samtidigt måste vi också se till att våra produkter är till ett mycket rimligt pris.

Vi har kunder från offentliga och kommersiella programföretag, teleoperatörer och regleringsmyndigheter, och vi erbjuder även lösningar och produkter till många hundra mindre, lokala och lokala programföretag.

FMUSER.ORG har exporterat mer än 15 år och har kunder över hela världen. Med 13 års erfarenhet inom detta område har vi ett professionellt team för att lösa kundens alla slags problem. Vi strävar efter att leverera den extremt rimliga prissättningen av professionella produkter och tjänster. Kontakta email: [e-postskyddad]

vår fabrik

Vi har modernisering av fabriken. Du är välkommen att besöka vår fabrik när du kommer till Kina.

För närvarande finns det redan 1095 kunder runt om i världen besökte vår Guangzhou kontor. Om du kommer till Kina, är du välkommen att besöka oss.

på mässan

Detta är vårt deltagande i 2012 Global Sources Hong Kong Electronics Fair . Kunder från hela världen äntligen har en chans att träffas.

Var är Fmuser?

Du kan söka i dessa siffror " 23.127460034623816,113.33224654197693 "på google map, då hittar du vårt fmuser-kontor.

FMUSER Guangzhou kontor i Tianhe District, som är mitten av Canton . Mycket nära till Canton Fair , Guangzhou järnvägsstation, Xiaobei väg och dashatou , behöver bara 10 minuter om ta TAXI . Välkommen vänner runt om i världen att besöka och förhandla.

Kontakt: Sky Blue
Mobil: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
E-post: [e-postskyddad]
QQ: 727926717
Skype: sky198710021
Adress: No.305 Room Huilan Building No.273 Huanpu Road Guangzhou Postnummer: 510620

Engelska: Vi accepterar alla betalningar, såsom PayPal, kreditkort, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer, Om du har några frågor, vänligen kontakta mig [e-postskyddad] eller WhatsApp + 8618078869184

PayPal.  www.paypal.com

Vi rekommenderar att du använder Paypal för att köpa våra produkter, är det Paypal ett säkert sätt att köpa på internet.

Varje av våra objekt listsidan botten på toppen har en paypal logotyp för att betala.

Kreditkort.Om du inte har paypal, men du har kreditkort, kan du också klicka på den gula PayPal för att betala med ditt kreditkort.

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

Men om du inte har ett kreditkort och inte har ett PayPal-konto eller svårt att fick en paypal Kontoinställningar, kan du använda följande:
Western Union.  www.westernunion.com

Betala med Western Union till mig:

Förnamn / Förnamn: Yingfeng
Efternamn / Efternamn / Efternamn: Zhang
Fullständigt namn: Yingfeng Zhang
Land: Kina
Stad: Guangzhou

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

T / T.  Betala med T / T (banköverföring / Telegraphic Transfer / banköverföring)
Första BANKINFORMATIONEN (FÖRETAGSKONTO):

SWIFT BIC: BKCHHKHHXXX
Banknamn: BANKEN AV KINA (HONG KONG) LIMITED, HONG KONG
Bankadress: BANKEN AV KINA TOREN, 1 GARDEN ROAD, CENTRAL, HONG KONG
BANK KOD: 012
Kontonamn: FMUSER INTERNATIONAL GROUP LIMITED
Konto Nej. : 012-676-2-007855-0

-------------------------------------------------- -------------------
Andra BANKINFORMATIONEN (FÖRETAGSKONTO):
Mottagare: Fmuser International Group Inc.
Kontonummer: 44050158090900000337
Mottagarens bank: China Construction Bank Guangdong Branch
SWIFT-kod: PCBCCNBJGDX
Adress: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, Kina
** Obs: När du överför pengar till vårt bankkonto, skriv INTE något i kommentarområdet, annars kommer vi inte att kunna ta emot betalningen på grund av regeringens policy för internationell handel.

* Det kommer att sändas i 1-2 arbetsdagar när betalning klar.

* Vi kommer att skicka det till ditt paypal tilltalar. Om du vill ändra adress, skicka din rätt adress och telefonnummer till min e [e-postskyddad]

* Om förpackningarna är under 2kg kommer vi att skickas via post flygpost, tar det ungefär 15-25days till din hand.

Om paketet är mer än 2kg kommer vi sänder via EMS, DHL, UPS, Fedex snabb expressleverans, kommer det att ta ungefär 7 ~ 15days till din hand.

Om paketet mer än 100kg, kommer vi att skicka via DHL eller flygfrakt. Det tar ca 3 ~ 7days till din hand.

Alla paket är formen Kina Guangzhou.

* Paketet kommer att skickas som en "gåva" och avvisas så mindre som möjligt, köparen behöver inte betala för "TAX".

* Efter fartyg, kommer vi att skicka en e-post och ger dig som spårningen numrerar.

För garanti.
Kontakta oss --- >> Returnera artikeln till oss --- >> Ta emot och skicka en ny ersättare.

Namn: Liu Xiaoxia
Adress: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Kina.
ZIP: 510620
Tel: + 8618078869184

Återvänd till denna adress och skriva din paypal adress, namn problem på Obs: