1 Bevezetés
Új nagy sávszélességű, kiváló minőségű internetes multimédiás szolgáltatásként az IPTV magasabb követelményeket támaszt a távközlési szolgáltatók IP nagyvárosi hálózatával szemben. A hagyományos unicast technológiával összehasonlítva a multicast technológiának megvan az az előnye, hogy a hálózati sávszélesség nem növekszik lineárisan a felhasználók számával az egyenértékű átviteli hatékonyság alapján, és hatékonyan képes megtakarítani a video szerver és a hordozó hálózat terhelését. Ezért a távközlési szolgáltatók számára, hogy hatékonyan és gazdaságosan telepítsék és valósítsák meg az IPTV szolgáltatásokat, ajánlott az end-to-end multicast push használatát, és a kulcs az IP multicast hálózat konfigurálása.
Jelenleg a távközlési szolgáltatók IP nagyvárosi területeinek hálózata főként a nagyvárosi gerinchálózatból és a szélessávú hozzáférési hálózatból áll, az IPTV szolgáltatási adatok pedig a nagyvárosi gerinchálózaton és a szélessávú hozzáférési hálózaton keresztül kerülnek a felhasználó végéhez. A metró gerinchálózata főként hálózati réteg (3. réteg) eszközökből áll, amelyek lehetővé teszik a multicast útválasztási protokollok, például a PIM-SM számára, hogy hozzáférjenek a multicast forrásokhoz (azaz IPTV head-end eszközökhöz) a multicast csomagok továbbításához és továbbításához. A szélessávú hozzáférési hálózat főként adatkapcsolati réteg (2. réteg) berendezésekből áll, és olyan technológiák, mint az IGMP Proxy vagy az IGMP Snooping használhatók a 2. réteg multicast továbbításához az IPTV végberendezések (azaz IPTV set-top boxok) eléréséhez. Az 1. ábra egy IPTV vég-vég multicast push modell vázlatos rajza.
pIYBAGBkThGAZmOzAAMHVeXKfuE734.png
1. ábra IPTV vég-vég multicast push hálózati modell
Ez a cikk az IPTV end-to-end multicast push hálózat kulcsfontosságú konfigurációs technológiáit írja le két különböző hálózati szintről: a metró gerinchálózatáról és a szélessávú hozzáférési hálózatról.
2. Kulcsfontosságú multicast konfigurációs technológia a metró gerinchálózatához
2.1 Multicast útválasztási technológia
A multicast üzenet és az unicast üzenet között a fő különbség az üzenet rendeltetési címének azonosítása. A multicast üzenet célcíme a multicast csoport címe (D osztályú "1110" -nel kezdődő IP-cím), az unicast üzenet pedig a cél host IP-n alapul. A címet rendeltetési címként használják. Mivel a csoportos küldés csoport címe és a célállomás között nincs egy az egyben megfelelés, a csoportos küldési útválasztó csak az üzenet forráscímének egyediségét használhatja az útválasztási döntések meghozatalához. Más szóval, a multicast útválasztó az üzenetet a multicast forrástól eltérõ irányba küldi az üzenet forrás címe alapján, a cél cím helyett. Ezt a technológiát fordított útirányú továbbításnak nevezzük (röviden RPF).
Az olyan problémák elkerülése érdekében, mint az útválasztó hurkok, az RPF előírja, hogy a multicast csomagoknak el kell jutniuk az útválasztóhoz a kijelölt upstream szomszédos csomópontból, és a többi szomszédos csomópont által továbbított csoportos csomagok eldobásra kerülnek. Ha probléma van a multicast útválasztással, előfordulhat, hogy a multicast csomagok nem képesek elérni más utakat, például unicast csomagokat, az IPTV élő közvetítési jelek megszakadnak a gerinchálózaton, és az unicast alkalmazások, például a webböngészés, valamint az e-mail küldése és fogadása normálisak akadályokat. Ekkor a csoportos küldés terjesztési útvonalán ellenőrizze a csoportos küldésű útválasztó és annak felfelé eső szomszédos csomópontjainak RPF-útválasztási tábláját.
2.2 Multicast útválasztás kapcsolási technológia
A PIM-SM protokoll multicast terjesztési fája két kategóriába sorolható: forrásfa és megosztott fa. A forrásfa a multicast forrást használja a fa gyökereként, más néven a legrövidebb útfát, amely minimalizálhatja a végpontok közötti csoportos küldés késleltetését, de az útválasztónak nagy mennyiségű útválasztási információt kell tárolnia, ami sokat fogyaszt. a rendszer erőforrásainak; a megosztott fa RP-t (PIM-SM) használ. A protokoll fontos útválasztója, amelyet a multicast források és a multicast routerek közötti átirányításra és konvergenciára használnak. Mivel az összes multicast terjesztési fa közös gyökércsomópontja, a multicast forrás forgalomnak először el kell érnie az RP-t, mielőtt kézbesítve, és a csoportos küldés útvonala általában nem optimális. További hálózati késleltetést fog bevezetni, de az útválasztási információk, amelyeket az útválasztónak meg kell tartania, nagyon kicsiek lehetnek.
A PIM-SM protokoll teljes mértékben kihasználja a két multicast terjesztési fa előnyeit. A multicast kezdeti szakaszában a multicast útválasztó nem tudja használni a forrásfát, mert nem tudja a multicast forrás helyét, de megszerezheti az első néhány multicast csomagot, amelyet a multicast forrás küldött az ismert RP csomóponton és annak megosztott fáján keresztül. Ismerje meg a multicast forrás helyét, és váltson a megosztott fáról a forrás fára a hálózati késleltetés csökkentése és az RP csomópontok által okozott hálózati szűk keresztmetszetek elkerülése érdekében.
A metró gerinchálózata általában főleg Cisco útválasztókból áll. Az olyan útválasztók, mint a Cisco, a multicast elosztási fa kapcsolását hajtják végre az áramlási sebesség előre beállított SPT-küszöbén keresztül. Amikor azt észlelik, hogy a multicast forrás csoportos küldésének áramlási sebessége meghaladja az SPT-küszöbértéket, annak multicast útvonala a megosztott fáról a forrás fára vált; Hasonlóképpen, ha a csoportos küldés áramlási sebessége alacsonyabb, mint az SPT-küszöbérték, annak multicast útvonala Visszaléphet a forrásfáról a megosztott fára is. Az SPT-küszöb általában 0-nak van konfigurálva, így az útválasztó az első csoportos csomag csomag vétele után a megosztott fáról a forrásra vált.
2.3RP konfigurációs technológia
A megosztott fa gyökércsomópontjaként az RP szerepet játszik a fel és le összekapcsolásban a csoportos küldés folyamatában. Figyelembe véve, hogy a PIM-SM protokoll rendelkezik a multicast terjesztési fa kapcsolásának jellemzőivel, az RP-t általában a kezdeti kapcsolat létrehozására használják a multicast forrás és a multicast router között. Miután az útválasztó multicast útválasztását a megosztott fáról a forrás fára váltotta, az nem fog RP-re váltani, és a megosztott fára újra szükség van. Ezért az RP helye a multicast hálózatban nem túl fontos. A legfontosabb megbízhatósága és stabilitása.
Az RP megbízhatóságának és stabilitásának javítása érdekében több multicast útválasztó választható ki, hogy megosszák az RP funkcióját (vagyis az Anycast RP technológiát), és az egyes RP csomópontok visszacsatoló interfészei ugyanazt az IP címet kapják, így képezik az terhelésmegosztás és hibavédelem.
A multicast hálózat RP konfigurációs problémája nemcsak magának az RP csomópontnak a konfigurálásához és telepítéséhez kapcsolódik, hanem azzal a problémával is jár, hogy más multicast útválasztók hogyan ismerik meg az RP csomópontot. A multicast kezdeti szakaszában előfordulhat, hogy a multicast útválasztó nem tudja a multicast forrás helyét, de az RP címet ismerni kell. A multicast útválasztónak két fő módja van RP cím megszerzésére, vagyis a statikus konfigurációs RP módszer és az automatikus felfedezés RP módszere. Az RP statikus konfigurációja biztonságosabb, és hatékonyan megakadályozhatja a csalárd tevékenységeket, például az RP hamisítását, de a hálózati konfiguráció terhelése nagy, és nem kedvez az RP és más csomópontok dinamikus beállításának; az RP automatikus felfedezése csökkentheti a konfiguráció terhelését, és megkönnyítheti a hálózati változásokat és az irányítási stratégiákat. Kiigazítás, de vannak bizonyos biztonsági kockázatok. Kis méretű nagyvárosi gerinchálózathoz használhatja az RP statikus konfigurálásának módszerét minden egyes multicast útválasztón; szigorú biztonsági védelmi politikával rendelkező nagyszabású nagyvárosi gerinchálózat esetén ajánlott az RP automatikus felfedezésének módszerét használni.
2.4 IPTV head-end multicast join technológia
A multicast kezdeti szakaszában a multicast útválasztók általában ismert RP csomópontokon és megosztott fáikon keresztül szerzik be az IPTV fejállomás (azaz multicast forrás) forgalmi és helyinformációit. Annak érdekében, hogy az RP megismerje a multicast forrást, a közvetlenül a multicast forráshoz kapcsolt multicast útválasztó felelős azért, hogy a multicast forrás által küldött első néhány multicast csomagot külön PIM Register üzenetbe tömörítse, és unicast kezdeményezze az RP számára a multicast kezdeményezést. mód. Forrás regisztráció folyamata. Ezen az üzeneten keresztül az RP nemcsak az érdeklődésű csoportos küldés csoportjának csomagjait szerezheti meg, hanem a csoportos küldési forrás IP címét is. Ezt követően az RP továbbítja a multicast forrásinformációt más multicast útválasztóknak, és a multicast forrás regisztrációs folyamatát PIM Registe-Stop üzenettel fejezi be.
3. A szélessávú hozzáférési hálózat multicast kulcs konfigurációs technológiája
3.1 IPTV felhasználói multicast csatlakozási technológia
Az IPTV kliens (set-top box) az IGMP protokollon keresztül a szélessávú hozzáférési hálózaton keresztül kommunikál a metró gerinchálózati szolgáltatás-hozzáférés-vezérlő réteg multicast útválasztóval (általában a szolgáltató útválasztó vagy a szélessávú hozzáférési szerver végzi) a szélessávú hozzáférési hálózaton keresztül, hogy csatlakozzon vagy kilépjen egy adott hálózatból Multicast csoport (azaz IPTV élő csatorna).
Amikor egy set-top box multicast csoport csatlakozási kérelem üzenetet küld egy multicast útválasztónak, az üzenet cél MAC címe a multicast csoport MAC címe a multicast router helyett, amely eltér az unicast módszertől. Meg kell jegyezni, hogy a multicast csoport MAC-címe valójában 32 különböző multicast csoport IP-címének felel meg. Ennek oka, hogy a multicast csoport MAC címe 01: 00: 5E: 00: 00: 00: 01: 00: 5E: 7F: FF: FF, vagyis a tényleges címtér csak 23 bit, és az effektív címtér a multicast csoport IP címe 28 szóköz van.
A kettő közötti leképezési kapcsolatnak meg kell felelnie a MACC-cím alsó 23 bitjének és az IP-cím alsó 23 bitjének az egyenlőségét, ami a multicast csoport IP-címének felső 5 bitjének elvesztését eredményezi. Például, ha három különböző IPTV élő csatorna a 224.0.0.1, a 224.128.0.1 és a 239.128.0.1 kódot használja a multicast csoport IP-címeiként, a megfelelő multicast csoportos MAC-címek mind 01: 00: 5E: 00: 00:01, amelyek a szélessávú hozzáférési hálózat set-top boxja és másodlagos berendezései képtelenek lesznek megkülönböztetni a három jelet. Ezért figyeljen az ilyen kérdésekre a multicast IP-címek tervezésénél.
3.2. 2. réteg multicast továbbítási technológia
A szélessávú hozzáférési hálózat nagyszámú hálózati elemkészülékből áll, mint például az adatkapcsolati rétegben futó 2. réteg kapcsolókból és DSLAM-okból. A Layer 2 berendezés jellemzője, hogy MAC címek alapján cserél / továbbít adatkereteket az eszközportok között, és gyenge elemzési és útválasztási funkciói vannak az IP csomagok harmadik rétegéhez (hálózati réteg), ezért nem tudja közvetlenül támogatni az IGMP-t, harmadik réteg. És más multicast protokollok. Amikor egy tipikus 2. rétegű eszköz, például egy kapcsoló, feldolgozza az IPTV multicast forgalmat, ismeretlen rendeltetési címek vagy sugárzási módszerek szerint sugározza az összes portjára a multicast adatkereteket, ami valószínűleg problémákat okozhat, mint például a viharok.
A multicast csomagok elárasztásának problémájának megoldásához a 2. réteg multicast továbbítási technológiáit, például az IGMP Snooping és az IGMP Proxy technológiákat kell elfogadni. Az IGMP Snooping technológia figyeli az IGMP üzenetet a set-top box és a multicast router között, hogy megragadja az eszközport továbbítási kapcsolatát a multicast adatkerettel; míg az IGMP Proxy technológia elfogja az IGMP üzenetet a set-top box és a multicast útválasztó között. A szűrés és a proxy továbbítás megtakaríthatja a multicast forgalmat a multicast router és a Layer 2 eszköz között, de ehhez nagy teljesítménymutatókra van szükség, mint például a feldolgozási kapacitás és a memória a hálózati elem eszközének. A 2. rétegbeli eszközök konfigurálásakor a hálózati elem eszköz tényleges teljesítménye és az IGMP Snooping / Proxy technológia támogatásának mértéke szerint választhat.
Vegyünk példaként egy 2 Mbit / s sávszélességű IPTV élő csatornát. Ha a Layer 2 eszköz nem használja a 2. réteg multicast továbbítási technológiáját, akkor az összes IPTV felhasználónak elküldött csoportos küldés csomagokat továbbítják az összes portra, még akkor is, ha a felhasználói port 10 Mbit / s sebességgel rendelkezik. s Hozzáférés a sávszélességhez, 5 IPTV élő csatorna multicast csomagja blokkolható; a 2. réteg multicast továbbítási technológiájának elfogadása után a multicast csomagokat csak a felhasználási kéréssel továbbítják a portokra, és ha minden port legfeljebb csak csatlakozik. IPTV set-top box esetén legfeljebb csak egy multicast csomag (azaz 2 Mbit / s forgalom) egy élő csatornát továbbítunk a megfelelő portra.
3.3 VLAN konfigurációs technológia
A 2. réteg multicast által továbbított forgalma csak IPTV multicast szolgáltatásokat foglal magában, és más szélessávú szolgáltatásokat nem tartalmaz. Ezért a szélessávú hozzáférési hálózatban az olyan technológiákat, mint a VLAN-ok, általában használják az IPTV multicast forgalom elkülönítésére a többi szolgáltatástól és a felhasználói forgalomtól. Az általánosan használt VLAN technológiák magukban foglalják a kereszt-VLAN multicast replikációs technológiát a multicast VLAN-tól az egyes felhasználói VLAN-okig, és a QinQ-t, amely elégtelen számú VLAN-azonosítót old meg
3.4 Statikus multicast és dinamikus multicast technológia
Az IPTV élő program az IP hordozó hálózaton keresztül érkezik a felhasználói terminálhoz, és főleg két csoportos küldés mód van, nevezetesen a dinamikus multicast mód és a statikus multicast mód. Dinamikus multicast módban a kapcsolók, a DSLAM-ok és más eszközök csak akkor fogadják és küldik el a csatornaprogramot, ha megkapják az első felhasználói kérést egy csatornához (multicast csoport) csatlakozáshoz; és amikor a csatorna (multicast csoport) tart. Amikor egy felhasználó kijelentkezik, a hálózati elem eszköze leállítja a multicast adatfolyam fogadását. A statikus multicast mód az, hogy statikusan konfigurálja a kapcsolóberendezés minden egyes IPTV csatornájának (multicast csoport) MAC multicast továbbítási bejegyzéseit, függetlenül attól, hogy a továbbfelhasználók figyelik-e vagy sem, a multicast adatfolyamot eljuttatták a hálózati elem berendezéséhez.
A statikus multicast forgalomnak semmi köze nincs az IPTV-felhasználók számához, csak a csatornák számához és csatornánként a sávszélességhez. Ha a felhasználók száma kevesebb, mint a csatornák száma, akkor a forgalom nagyobb lesz, mint az egyedi küldési forgalom; a dinamikus multicast maximális forgalma az, amikor az egyidejű IPTV felhasználók száma kevesebb, mint a csatornák száma. Ha az IPTV egyidejű felhasználók száma nagyobb, mint a csatornák száma, ez egyenértékű a statikus multicast forgalommal. Statikus multicast módban a felhasználó csatornaváltási sebessége gyors és a szolgáltatás észlelése jó, de a hálózati sávszélesség igény nagyobb; A dinamikus csoportos küldés minden körülmények között minimalizálhatja a hálózati forgalmat, de amikor a felhasználó új csatornát (Multicast csoport) kap, akkor bizonyos hálózati késés léphet fel.
Amikor a hálózati berendezéshez csatlakoztatott IPTV-felhasználók száma nagyon kicsi, a multicast előnyei nem nyilvánvalóak. Ezért az IPTV-szolgáltatások fejlesztésének kezdeti szakaszában nincs sok IPTV-felhasználó, vagy a szélessávú hozzáférési hálózatot nem rekonstruálták. Az IPTV élő jelek továbbításához dinamikus csoportos vagy akár egyedi küldést is használhat. Amikor egy hálózati eszközhöz csatlakoztatott felhasználók száma messze meghaladja az IPTV-csatornák számát, a hálózati forgalom sávszélességének megmentése érdekében a multicasting jellemzői egyre jelentősebbé válnak. Ebben az időben, vagyis amikor az IPTV szolgáltatást kiforrottan fejlesztették és a szélessávú hozzáférési hálózat átalakítása megtörtént, a statikus multicast mód használható az IPTV élő jel továbbítására az IPTV szolgáltatás minőségének további javítása érdekében. Ezért az üzemeltetők eldönthetik, hogy a hozzáférési hálózati berendezéseket dinamikus vagy statikus csoportos küldés módban konfigurálják-e a tényleges feltételeknek, például a hálózati minőségnek és az IPTV szolgáltatás behatolásának megfelelően.
Következtetés 4
A távközlési szolgáltatók meglévő IP nagyvárosi területeinek hálózatát ötvözve ez a tanulmány szisztematikusan bemutatja az IPTV end-to-end multicast push hálózati konfigurációjának kulcsfontosságú technológiáit, amelyek jó referencia jelentőséggel bírnak a távközlési szolgáltatók számára az IPTV-szolgáltatások hatékony és gazdaságos telepítésében és megvalósításában.
|
|
|
|
Milyen messze (hosszú) a távadó fedelét?
A hatótávolság számos tényezőtől függ. Az igazi távolságot alapul az antenna telepítéséhez magasság, antennanyereség használva környezetben, mint épület és egyéb akadály, érzékenysége a vevő, antenna a vevő. Telepítése antenna több magas és használata vidéken, a távolság sokkal messzebb.
Példa 5W FM Transmitter használja a városban és a szülővárosa:
Van egy magyar ügyfél használja 5W fm transmitter GP antenna szülővárosában, s kipróbálni egy autót, akkor terjed 10km (6.21mile).
Tesztelem a 5W fm transmitter GP antenna szülővárosomban, ez fedezésére mintegy 2km (1.24mile).
Tesztelem a 5W fm transmitter GP antenna Guangzhou város, akkor terjed csak körülbelül 300meter (984ft).
Az alábbiakban a hozzávetőleges sor különböző teljesítmény FM adó. (A tartomány átmérő)
0.1W ~ 5W FM adó: 100M ~ 1KM
5W ~ 15W FM Ttransmitter: 1KM ~ 3KM
15W ~ 80W FM adó: 3KM ~ 10KM
80W ~ 500W FM adó: 10KM ~ 30KM
500W ~ 1000W FM adó: 30KM ~ 50KM
1KW ~ 2KW FM adó: 50KM ~ 100KM
2KW ~ 5KW FM adó: 100KM ~ 150KM
5KW ~ 10KW FM adó: 150KM ~ 200KM
Hogyan léphet kapcsolatba velünk az adó?
Hívjon + 8618078869184 OR
Küldj e-mailt [e-mail védett]
1.How messze szeretné fedezni átmérőjű?
2.How magas közületek torony?
3.Where vagy?
És akkor kapsz több szakmai tanácsot.
Rólunk
Az FMUSER.ORG egy olyan rendszerintegrációs cég, amely az RF vezeték nélküli átvitelre / stúdió-videó hangberendezésre / streamingre és adatfeldolgozásra összpontosít.
FM adó, analóg TV adó, digitális TV adó, VHF UHF adó, antennák, koaxiális kábelcsatlakozók, STL, levegő feldolgozás, műsorszórási termékek a stúdióhoz, RF jel felügyelet, RDS kódolók, audio processzorok és távoli webhelyvezérlő egységek, IPTV termékek, Video / Audio Encoder / Decoder, úgy tervezték, hogy megfeleljenek mind a nagy nemzetközi műsorszóró hálózatok, mind a kis magánállomások igényeinek.
Megoldásunk FM rádióállomás / analóg tévéállomás / digitális tévéállomás / audio-video stúdió berendezés / stúdió adó-összeköttetés / adó-telemetria rendszer / szálloda TV-rendszer / IPTV élő közvetítés / élő közvetítés / videokonferencia / CATV műsorszóró rendszer.
Az összes rendszerhez fejlett technológiai termékeket használunk, mert tudjuk, hogy a nagy megbízhatóság és a nagy teljesítmény olyan fontos a rendszer és a megoldás szempontjából. Ugyanakkor meg kell győződnünk arról, hogy termékrendszerünk nagyon kedvező áron van.
A közszolgálati és kereskedelmi műsorszolgáltatók, a távközlési szolgáltatók és a szabályozó hatóságok ügyfelei vannak, és megoldásokat és termékeket is kínálunk több száz kisebb, helyi és közösségi műsorszolgáltatónak.
Az FMUSER.ORG több mint 15 éve exportál, és ügyfelei vannak a világ minden tájáról. 13 éves tapasztalattal rendelkezik ezen a területen, van egy profi csapatunk, hogy megoldjuk az ügyfelek mindenféle problémáját. Elkötelezettek vagyunk a professzionális termékek és szolgáltatások rendkívül elfogadható árainak biztosításában. Kapcsolattartó e-mail : [e-mail védett]
a Factory
Nekünk van korszerűsítés a gyár. Szeretettel várjuk, hogy látogassa meg a gyár, ha jön Kínába.
Jelenleg már vannak 1095 ügyfelek világszerte látogatott el Guangzhou Tianhe irodában. Ha jön Kína, szívesen látogasson el hozzánk.
Fair
Ez a mi részvétel 2012 Global Sources Hong Kong Electronics Fair . Az ügyfelek a világ minden tájáról végre van egy esélyt, hogy együtt legyünk.
Hol van Fmuser?
Kereshet ezekben a számokban " 23.127460034623816,113.33224654197693 "a google térképen, akkor megtalálhatja fmuser irodánkat.
FMUSER Guangzhou irodája Tianhe District, amely a központja a Canton . Nagyon közel hoz Canton Fair , Guangzhou vasútállomás, Xiaobei közúti és dashatou , Csak be kell 10 perc ha figyelembe TAXI . Üdvözöljük barátok a világ minden tájáról, hogy látogassa meg, és tárgyaljon.
Kapcsolat: Sky Blue
Mobil: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
Email: [e-mail védett]
QQ: 727926717
Skype: sky198710021
Cím: No.305 szoba Huilan Building No.273 Huanpu Road Guangzhou Kína Zip: 510620
|
|
|
|
Angol: Minden fizetést elfogadunk, például PayPal, Hitelkártya, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Ha bármilyen kérdése van, kérjük, vegye fel velem a kapcsolatot [e-mail védett] vagy a WhatsApp + 8618078869184
-
PayPal.  www.paypal.com
Azt javasoljuk, hogy a Paypal vásárolni a terméket, a Paypal biztonságos módon vásárolni az interneten.
Minden a mi elem lista oldal alján tetején van egy paypal logóra fizetni.
Hitelkártya.Ha nincs paypal, de van, hitelkártya, akkor is kattints a sárga gombra PayPal fizetni a hitelkártya.
-------------------------------------------------- -------------------
De ha nem egy hitelkártya, és nem egy paypal számla, vagy nehezen kapott egy paypal fiókot állíthat, használhatja a következő:
Western Union.  www.westernunion.com
Fizessen Western Union nekem:
Keresztnév / Keresztnév: Yingfeng
Vezetéknév / Vezetéknév / Családnév: Zhang
Teljes név: Yingfeng Zhang
Ország: Kína
Város: Guangzhou
|
-------------------------------------------------- -------------------
T / T. Fizessen T / T (átutalás / banki átutalás / banki átutalás)
Első BANKINFORMÁCIÓ (VÁLLALATI SZÁMLA):
SWIFT BIC: BKCHHKHHXXX
Bank neve: BANK OF CHINA (HONG KONG) LIMITED, HONGKONG
Bank címe: BANK OF CHINA TOWER, 1 GARDEN ÚT, CENTRAL, HONG KONG
BANKKÓD: 012
Számla neve: FMUSER INTERNATIONAL GROUP LIMITED
Számlaszám. : 012-676-2-007855-0
-------------------------------------------------- -------------------
Második BANK-INFORMÁCIÓ (VÁLLALATI SZÁMLA):
Kedvezményezett: Fmuser International Group Inc.
Fiókszám: 44050158090900000337
Kedvezményezett bankja: China Construction Bank Guangdong Branch
SWIFT kód: PCBCCNBJGDX
Cím: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, Kína
** Megjegyzés: Ha pénzt utal át bankszámlánkra, kérjük, NE írjon semmit a megjegyzés területére, különben a nemzetközi kereskedelemre vonatkozó kormányzati politika miatt nem tudjuk megkapni a befizetést.
|
|
|
|
* Ez lesz elküldve 1-2 munkanap, amikor a fizetési világos.
* Mi elküldjük azt a paypal címét. Ha meg akarjuk változtatni a címet, kérjük, küldje el a megfelelő címet és telefonszámot az email [e-mail védett]
* Ha a csomagok alatt 2kg fogjuk szállítani postai légiposta, akkor körülbelül 15-25days a kezedbe.
Ha ez a csomag több, mint 2kg, akkor a hajó keresztül EMS, DHL, UPS, Fedex gyors expressz szállítás, akkor körülbelül 7 ~ 15days a kezedbe.
Ha a csomag több, mint 100kg küldünk keresztül DHL vagy a légi áruszállítás. Ez körülbelül 3 ~ 7days a kezedbe.
Minden csomag formájában Kína Guangzhou.
* A csomagot "ajándékként" küldjük el, és a lehető legkevesebbet nyilatkozunk, a vevőnek nem kell fizetnie az "adóért".
* Miután a hajó, küldünk Önnek egy e-mailt, és adja meg a nyomon követési számot.
|
|
|
A jótállásért.
Lépjen kapcsolatba velünk --- >> Tegye vissza nekünk a terméket --- >> Fogadás és újabb csere küldése.
Név: Liu Xiaoxia
Cím: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Kína.
Postai irányítószám: 510620
Telefon: + 8618078869184
Kérjük, térjen vissza erre a címre, és írja meg a paypal címét, nevét, probléma megjegyzés: |
|
