Sikring af mobile tjenester med assisteret delvis timing
Støtte hvidbog

Indledning

Microchip er en anerkendt leder inden for innovation af timing-teknologier, der muliggør højtilgængelige netværkstjenester. Dette er tydeligt med APTS (Assisted Partial Timing Support) og Automatic Asymmetry Compensation (AAC), to kraftfulde værktøjer, der sikrer avanceret 4G- og 5G-mobilnetværksdrift. Kritiske applikationer, såsom nødtjenester og tilsluttede køretøjer, kræver altid tilgængelig tilgængelighed til mobilnetværket. En sådan garanteret adgang kræver tætning af radioadgangspunkter, kompleks antenneinfrastruktur og sofistikerede interferenskontrolteknikker, der er afhængige af stringent fasejustering mellem radioenhederne (RU). Indtil for nylig stolede operatører udelukkende på GNSS til fasebaseret timing for at understøtte Time Division Duplex (TDD) operationer, men GNSS er ikke altid tilgængelig. GNSS kan også være sårbar over for jamming eller spoofing. For at reducere eksponeringen for sådanne hændelser og bevare kontrollen over timingtjenester, bruger operatører Precision Time Protocol (PTP) til at levere faseinformation og garanterer derfor mobiltjenesten. Imidlertid er asymmetrier, der alvorligt påvirker PTP-driften, iboende i transportnettet. APTS og AAC afbøder disse netværkseffekter og er grundlæggende for fortsat drift af 4G/5G-mobilnetværk.

Synkronisering driver mobilapplikationer

For at sikre grundlæggende overdragelse mellem basestationer og levere kontinuerlige højkvalitets mobile tjenester, skal frekvensen og fasen af ​​radiobasisstations ure synkroniseres omhyggeligt.
Denne synkroniseringsproces er specifik for den anvendte radioteknologi. For LTE FDD-baserede mobilnetværk skal frekvensjusteringen mellem celler ved luftgrænsefladen mellem nabobasestationer være inden for ±50 ppb fra en fælles reference. For at opfylde dette krav skal frekvenssignalet til basestationen være inden for ±16 ppb tilladt fejl. LTE-TDD fasebaserede netværk er specificeret med et maksimum på ±1.5 µs Time Error (TE) mellem radiogrænsefladerne og den maksimalt tilladte ende-til-ende tidsfejl fra UTC (det globalt specificerede referenceur) til jernbanevirksomheden er ± 1.1 µs. Dette tidsfejlbudget inkluderer unøjagtigheder i referenceuret og tilfældige netværksforsinkelser på grund af transportknude- eller linkstøj, som alle kan forårsage netværksasymmetri. Transportnetværket tildeles ±1 µs af den samlede tilladte tidsfejl. Transportnetværk er imidlertid heterogene og dynamiske; de udvikler sig i overensstemmelse med ændringer i de anvendte teknologier, demografien og brugsmønstrene. Dette tilføjer et yderligere lag af kompleksitet, når man designer clocking-arkitekturen, fordi en synkroniseringsplan for et moderne mobilnetværk skal være både stramt konstrueret og fleksibel.

Synkroniseringsarkitekturer

Frekvensbaserede synkroniseringsnetværk, der bruger fysiske lagtidssignaler, er traditionelt opbygget som et centervægtet hierarkisk system. Et centraliseret kildeur genererer en frekvens, som forplantes hop-for-hop over transportnetværkselementerne til slutapplikationen, i dette tilfælde FDD-basisstationer.
I løbet af det seneste årti har mobilnetværk udviklet sig fra TDM til IP/Ethernet og erstattet fysisk lagsynkronisering med systemer, der bærer et timingsignal ved hjælp af Precision Time Protocol (PTP) på IP/Ethernet-lagene. Den første bølge af PTP-implementeringer var til FDD-applikationer, og PTP er nu blevet implementeret med succes med PPT Grandmaster-ure, såsom Microchip TP5000 og TP4100 implementeret i hundredvis af mobilnetværk verden over.
Indførelsen af ​​5G-tjenester driver i stigende grad næste generations mobilnetværk ved hjælp af fasebaserede applikationer, der er implementeret ved mobilaggregeringen og kanten af ​​mobilnetværk. Der er følgelig en migrering fra Grandmaster-ure, der er udviklet til frekvenslevering til Primary Reference Time Clocks (PRTC'er, G.8272), som kræver et GNSS- eller PTP-input, og som bruger fasespecifik PTP profiles.
Netværksarkitekturerne for disse fasebaserede applikationer er subtilt forskellige fra dem, der er udviklet til frekvens. PRTC'er, der er implementeret i en mere distribueret arkitektur tættere på kanten af ​​netværket, bør bakkes op af højpræcisions kerne PRTC/ePRTC (enhanced Primary Reference Time Clock), der kan generere og holde tid i længere perioder.

Synkroniseringsmuligheder for Mobile Edge i Phase Networks

Levering af frekvenstjenester ved hjælp af PTP implementeres ofte ved RAN-aggregationspunktet, flere hop fra jernbanevirksomheden. Frekvensoverførsel har en vis iboende elasticitet, der muliggør udbredelse over et asynkront netværk med tillid, så længe veletablerede tekniske retningslinjer følges.
Leveringen af ​​fasetjenester, der kan spores til absolut UTC (universal koordineret tid) er konstrueret i henhold til Time Error-budgetgrænserne pålagt af 3GPP (for radiogrænseflader) og ITU-T for netværksgrænseflader og referenceure. Men mens levering af frekvens ved hjælp af PTP er velforstået, er det samme ikke nødvendigvis tilfældet for overførsel af fasetiming ved hjælp af PTP. At sende en tidskode på tværs af et asynkront pakkenetværk med iboende støj og forsinkelse for at levere synkronisering inden for ±1.1 µs Tidsfejl i forhold til UTC kan være en betydelig udfordring.
Der er tre måder at løse dette problem på:

• Løsning A: GNSS
  – Operatøren kan implementere GNSS ved hver eNB.
  – Grænser: Hver eNB skal være udfyldt med GNSS, og GNSS-antennen skal have kontinuerlig sigte til satellitsignalet. Line of Sight (LoS) er ikke altid muligt, fordi view af satellitten kan blokeres, såsom af vegetation, af skygger forårsaget af højhuse (urban canyon), eller fordi eNB'en er installeret under jorden eller indendørs. Allestedsnærværende GNSS kan også være dyrt set fra et OPEX-perspektiv.
• Løsning B: Indlejrede tidsgrænseure (T-BC)
  – For denne arkitektur skal transportnetværket konstrueres med en hardwarebaseret de-jitter-funktion kendt som Time Boundary Clock (T-BC) indlejret i hver NE. Denne arkitektur inkluderer konceptet med et virtuelt primært referencetidsur (vPRTC), hvor GNSS-modtagerens kildeure er centraliserede.
  – Begrænsninger: T-BC-hardwaren og -softwaren skal implementeres på hver transportknude i urkæden, hvilket ofte kræver en besværlig netværksinvesteringscyklus. Selv når den er installeret på hver NE, garanterer BC ikke nødvendigvis, at timingsignalet vil være inden for den krævede specifikation, medmindre netværket er omhyggeligt konstrueret for at sikre, at der ikke er nogen hop-to-hop-asymmetri på linkene.
• Løsning C: Distribueret PRTC
  – Letvægts-PRTC kan flyttes til kanten af ​​netværket for at reducere hoptællingen mellem uret og eNB, således at fasebaseret timing ved hjælp af PTP kan nå eNB inden for de anbefalede ±1.1 µs tidsfejlgrænser.
  – Begrænsninger: Kræver investering i lette ure installeret rundt om kanten af ​​netværket
  — en ny distribueret timing-arkitektur.

Af de tre ovenstående løsninger kan placering af PRTC tættere på eNB muliggøre omkostningsreduktion sammenlignet med implementering af T-BC hardware på hver NE eller installation af GNSS på hver celleplads. Omkostninger vil blive en stadig vigtigere faktor, når man planlægger fortætning af eNB til LTE-A og 5G-tjenester.
Med anbefaling G.8275 anerkendte ITU-T, at de stringente Time Error timing-krav ved eNB gjorde det vanskeligt at implementere centraliserede PRTC-ure og samtidig garantere levedygtigheden af ​​fasesignalet til slutapplikationen. Flytning af PRTC tættere på slutapplikationen reducerer sandsynligheden for, at støj og asymmetri fra netværkstransporten vil påvirke PTP-flowet negativt, men har også en indvirkning på PRTC'ens formfaktor og kapacitetskrav.
Med anbefaling G.8275 anerkendte ITU-T, at de stringente tidsfejl-timingkrav ved eNB gjorde det vanskeligt at implementere centraliserede PRTC-ure og samtidig garantere levedygtigheden af ​​fasesignalet til slutapplikationen. Flytning af PRTC tættere på slutapplikationen reducerer sandsynligheden for, at støj og asymmetri fra netværkstransporten vil påvirke PTP-flowet negativt, men har også en indvirkning på formfaktoren og kapacitetskravene for PRTC'en.
I kernen af ​​netværket, hvor ekstremt nøjagtig tid og omfattende holdover er påkrævet, kan clocking-infrastrukturen omfatte højtydende ePRTC med høj kapacitet med flere rubidium- og ePRC-cæsium-enheder, der ikke er egnede til udrulning på kanten af ​​netværket.
Distributed edge PRTC på den anden side kan være meget mindre og meget lavere omkostninger.
Figur 3-1. ITU-T-anbefaling G.8275 – PRTC installeret på netværkskanten Primær sti/backup sti
Optinal Frequency Reference bruges til at sikre GNSS-fejl
Note: T-GM er forbundet til PRTC i denne arkitektur
Imidlertid er små PRTC fordelt på kanten af ​​netværket som selvstændige systemer uden en timingforbindelse til kernen isoleret fra de opstrøms centraliserede ure. Dette kan være et problem for fortsat drift, hvis enheden mister GNSS-forbindelse, da oscillatorerne, der bruges i så lille PRTC, normalt ikke vil være i stand til at give omfattende holdover ved ±100 ns nøjagtighedsniveau.
At holde ±100 ns i længere perioder er domænet for højtydende oscillatorer, der ikke hører til den billige OCXO eller TCXO, der typisk findes i edge-enheder. Når først et GNSS-input er tabt, vil PRTC befolket med sådanne oscillatorer hurtigt drive uden for ±100 ns-specifikationen. Dette er vist i de følgende to diagrammer.

• Hvis oscillatoren vandrer, mister PTP-outputtet hurtigt tidsreferencen

Under normale omstændigheder, når GNSS er tabt, som vist ovenfor, signalerer PRTC øjeblikkeligt tabet af GNSS-forbindelse til de tilsluttede klienter. Dette har konsekvenser for eNB. I nogle klientimplementeringer, så snart PRTC-signalets GNSS-forbindelse går tabt (ved at sende et clockClass7-flag, f.eks.ample), vil klienten straks diskvalificere PTP-inputflowet og gå i holdover baseret på den interne oscillator i radioenheden.
I denne situation, hvis oscillatoren i RU er befolket med en lavprisoscillator, vil den ikke være i stand til at forblive inden for ±1.1 µs af UTC i mere end et par minutter. Alle RU, der diskvalificerer det indkommende PTP-signal, vil drive uafhængigt. De vil hurtigt vandre fra hinanden, fordi oscillatorerne i hver eNB vil reagere forskelligt på de individuelle miljømæssige begrænsninger, og hastigheden, retningen og stabiliteten af ​​den akkumulerende tidsfejl vil være forskellig for hver RU. Desuden vil disse radioer fortsætte med at generere RF, og dette vil bidrage til at øge og mindre kontrolleret interferens for andre aktive jernbanevirksomheder i nærheden fra samme eller andre operatører.

Assisteret Partial Timing Support

For at undgå en situation, hvor edge-PRTC'en er isoleret og i tilfælde af en GNSS-fejl ikke længere kan levere fasetjenester, udviklede Microchip ideen om at forbinde edge-PRTC'en til de centraliserede core-ure ved hjælp af et PTP-flow. Denne idé blev vedtaget af ITU-T og godkendt som anbefaling G.8273.4 – Assisted Partial Timing Support.
I denne arkitektur er det indkommende PTP-flow tidsmæssigtamped af GNSS, der bruges af kerne PRTC.
PTP-flowet fra kerne-PRTC til kant-PRTC er konfigureret som en unicast-protokol, G.8265.1 eller G.8275.2. PTP-inputtet er kalibreret til tidsfejl ved hjælp af den lokale kant PRTC GNSS. Denne GNSS har samme reference (UTC) som opstrøms GNSS. Det indkommende PTP-flow kan betragtes som et effektivt proxy-GNSS-signal fra kernen med sporbarhed til UTC.
Hvis edge-systemet GNSS nu går ud af drift af en eller anden grund, kan edge-PRTC falde tilbage på det indkommende kalibrerede PTP-flow som timingreference og fortsætte med at generere udgående PTP-tidsst.amps, der er justeret med GNSS.
Det kan vi tydeligere se i den følgende figur.
Figur 4-1. PTP APTS Flows som en backup til Edge PTRTC

1. Begge GNSS har samme tidsreference (til)
2. PTP-output bruger Edge PRTC GNSS til PTP-output

ITU-T's formelle erklæring om G.8273.4-arkitekturen er vist i følgende figur.
Figur 4-2. ITU-T G.8273.4 Assisted Partial Timing Support Architecture

APTS-drift i detaljer

APTS-betjening er en ret simpel idé:

• Både kerne-PRTC og kant-PRTC har et GNSS-input refereret til UTC-tid.
• Kerne PRTC T-GM leverer PTP timetamps til nedstrøms kant PRTC/GM ur ved hjælp af en multicast eller unicast PTP profile.
• Edge-PRTC sammenligner PTP-tidenamp til den lokale GNSS-tid.
• Edge-PRTC akkumulerer information om PTP-flowet fra PTP-tidspunktetamps og fra beskedudvekslinger med kerne PRTC. Den forstår således den overordnede forsinkelse og tidsfejl på den specifikke input-PTP-sti.
• Kanten kalibrerer det indkommende PTP-flow ved at kompensere for den akkumulerede tidsfejl, så den nu svarer til den lokale GNSS-tid.

Denne proces er vist i den følgende figur. Dette viser, at den lokale GNSS er på "tid 0". Tidsfejlen på det indkommende PTP-flow fjernes ved hjælp af GNSS-referencen og er derfor ikke på "tid 0".
Figur 5-1. APTS G.8273.4: Et PTP-inputflow er kalibreret for tidsfejlNår APTS-algoritmen er i drift, kan det indkommende PTP-flow bruges som en proxy for opstrøms GNSS. Hvis GNSS på den lokale PRTC går tabt, vil systemet bruge det kalibrerede indgående APTS flow som referenceur. Dette er vist på følgende figur.
Figur 5-2. APTS/G.8273.4: Hvis GNSS går tabt, kan den kalibrerede PTP-input bruges til at vedligeholde referencetidenSelv med APTS, men hvis GNSS'en forbliver afbrudt, vil systemoscillatoren til sidst drive væk fra ±100 ns PRTC-kravet, hvis en asymmetri profile ikke tidligere kalibreret introduceres i PTP APTS-timingstien.
En væsentlig svaghed ved standard APTS-implementeringen (G.8273.4) er, at hvis PTP-stien omdirigeres, mens GNSS'en er offline, vil systemet ikke have kendskab til tidsfejlen på den nye sti.
Med andre ord, i ITU-T-standarden er APTS ikke modstandsdygtig over for en netværksomlægning, der påvirker det indkommende PTP-flow. Men moderne OTN- eller MPLS-baserede kernenetværk kan være meget dynamiske med intermitterende omarrangering af netværksstierne. Dette kan helt klart være et problem for PTP-flows, der er optimeret til en enkelt statisk sti.

Teknisk modstandsdygtighed – Beskyttelse mod PTP-indgangsstiomlægning

Et ende-til-ende PTP-system kan gøres mere modstandsdygtigt ved at kalibrere mere end én PTP-sti ind i kant-PRTC.
G.8273.4-anbefalingen kræver dog kun, at yderligere PTP-input skal frekvenskorrigeres, ikke kalibreres for tidsfejl.
Selvom kalibrering for frekvens kan hjælpe med at stabilisere kant-PRTC-oscillatoren, er det ikke en sand repræsentation af opstrøms PRTC, der kræver en reference til UTC. Uden en Time Error-korrektion på mere end én PTP-input-flow er PTP-clocking-systemet sårbart over for de dynamiske netværksændringer, der er typiske for et moderne routet netværk. Efterhånden som netværket omarrangerer PTP-stierne, vil edge-systemet miste evnen til at spore Time Error og kompensere i overensstemmelse hermed. Som et resultat vil PRTC bevæge sig hurtigere væk fra ±100 ns grænsen med et input, der kun er kompenseret for frekvens, end det vil med et PTP flow, der er velkalibreret Tidsfejl.
Dette er vist i de følgende to figurer.
Figur 6-1. G.8273.4: Det andet PTP-flow er kun frekvensFigur 6-2. En rent frekvensdisciplineret oscillator vil drive hurtigt væk fra den accepterede PRTC TE-grænse på ±100 nsSom det kan ses ovenfor, antager standardimplementeringen, at netværket er statisk, og at PRTC'en altid vil være i stand til at stole på det indkommende PTP-flow til at levere et referenceur. Moderne asynkrone pakkenetværk er dog dynamiske; netværksomlægninger er ret almindelige, og PTP-stier kan og ændrer sig. En af de primære fordele ved et MPLS- eller OTN-netværk er faktisk sømløse omdirigeringer uden at skulle reservere alternative stier eller sørge for ekstra båndbredde i netværket. For frekvensapplikationer er dette muligvis ikke et stort problem, afhængigt af antallet af hop PTP-pakkerne skal gennemløbe. For en faseapplikation, der er afhængig af velkonstrueret tidsfejl, kan en stiændring for PTP-flowets bæretidsinformation være problematisk. Dette skyldes, at den nye sti næsten helt sikkert vil have en anden tidsfejl end den oprindelige sti.
Microchip har løst dette problem ved at forbedre G.8273.4-standarden med Automatic Asymmetry Compensation (AAC), en patenteret metode, der tillader Time Error-kompensation på op til 32 PTP-stier pr. kilde PRTC-ur.

 Automatisk asymmetrikompensation (AAC)

Automatisk asymmetrikompensation som implementeret af Microchip forbedrer den standardiserede APTS-algoritme markant. Følgende figur viser en simpel repræsentation af AAC.
Figur 7-1. APTS + AAC (automatisk asymmetrikompensation)Som vi har diskuteret ovenfor, kalibrerer systemet med G.8273.4 kun én PTP-inputsti. Under disse omstændigheder er en Time Error-kalibrering kun levedygtig, hvis den kalibrerede sti er levedygtig. Hvis stien mellem kernen og kanten PRTC skulle ændre sig under omarrangering, vil den iboende tidsfejl ændre sig, og vejkompensationen eller kalibreringen er ikke længere levedygtig.
Med automatisk asymmetrikompensation fra Microchip vedligeholdes en PTP-inputsti-tidsfejlstabel af edge-PRTC-systemet for op til 32 input-PTP-flows. Hver sti er knyttet til den PTP-master, der leverer det aktive flow. I tilfælde af Microchip edge PRTC og gateway-ure kan flere klienter desuden operere på det samme system, hver med potentialet til at kalibrere op til 32 inputstier for Time Error.

Asymmetrikorrektion er altid tændt og dynamisk

Bare fordi PTP-flowet er kalibreret, betyder det ikke, at det giver korrektion til PTP-outputtet.
Hvis GNSS driver fase/tidsudgangene, så drives outputtet af GNSS'en og ikke det indkommende PTP flow. Et vigtigt punkt her er, at evnen til at generere asymmetritabelposter og have en kalibreret sti er fuldstændig uafhængig af, om den aktuelle PTP-sti driver outputtet eller ej. Med andre ord er APTS + AAC altid aktiv, uanset tilstanden af ​​det lokale system, inklusive GNSS.
Bemærk: At have indtastet stier i TE-tabellen garanterer ikke nødvendigvis, at kant-PRTC i øjeblikket (“på dette tidspunkt”) er i stand til at give asymmetrikompensation. Evnen til at give asymmetrikompensation er ganske enkelt angivet som: "Hvis (og kun hvis) det aktuelle PTP-flow er blevet signaturmatchet med en tabelindgang, så (og kun da) er vi i øjeblikket i stand til at kompensere for asymmetri."
Da den konstant er i drift, opbygger AAC-funktionen dynamisk en historie, der gør det muligt for systemet at genkalde det, der tidligere er blevet set. Tabelposterne for asymmetrikorrektion udgør en database, der gemmer information om de PTP-stier, der er forbundet med det unikke ur-ID for kilde-PRTC. Desuden har hver post en signatur, der bruges til den sti, når GNSS ikke er tilgængelig. Når først den er identificeret, anvendes den lagrede asymmetri og offset (tidsfejl), der er knyttet til den sti, hver gang den specifikke signatur ses.
Netværksomlægning kan påvirke PTP-inputtet, da det kan forårsage betydelige ændringer i PTP-flowkarakteristika, såsom et fuldstændigt tab af flow, ændring i støjkarakteristika eller en ændring af rundturstid. Når en så væsentlig ændring sker i det indkommende PTP-flow, skal det revurderes, og hvis de rigtige kriterier er opfyldt, kan det blive en kalibreret sti. Naturligvis kan nye asymmetristiposter ikke oprettes uden GNSS tilgængelighed (som giver kalibreringsreferencen).
Figur 8-1. Mikrochip APTS + AAC – Alle PTP-stier er kalibreret 

Opførsel, når stien ikke er kalibreret for tidsfejl

Hvis PTP-inputtet driver PTP-fase/tidsoutputtet, vil fasejustering til UTC-reference ske, hvis (og kun hvis) inputtet er en kalibreret sti. Hvis PTP-stien ikke er blevet kalibreret til tidsfejl ved hjælp af GNSS, vil kun frekvensjusteringer blive anvendt.
Denne adfærd beskytter fase/tidsoutput mod at blive påvirket af ukendt PTP-asymmetri, hvilket ville opstå, hvis fase/tidsjusteringer var afhængige af en PTP-sti, der ikke var blevet kalibreret til tidsfejl.

Example af APTS AAC Drift

Overvej følgende scenarie:
Systemet kører i første omgang med GNSS og PTP, med Microchip AAC aktiveres asymmetrifunktionen automatisk. GNSS driver PTP-udgangene. Alle udgange er på t0 (tid nul).
Antag, at den aktuelle PTP-sti har en offset-korrektion (tidsfejl på grund af asymmetri) på +3 µs. Dette bliver den kalibrerede vej.
Stien er kalibreret, fordi asymmetrijusteringen (tidsfejlkompensation) anvendes automatisk, mens GNSS er aktiv.
GNSS går så tabt, så PTP-inputstien med en kalibreret offset-korrektion på +3 µs er den primære input og driver faseoutputtet.
Antag nu, at der er en ændring i PTP-inputstien forårsaget af et netværksomlægningsfænomen, såsom et fiberafskæring. I dette tilfælde vises en helt anden ny PTP-signatur (f.eksample, en ændring i tur-retur tid).
Der er nu to mulige scenarier:

1. Hvis systemet bruger G,8273.4 i henhold til standarden.
   en. Da GNSS ikke er tilgængelig til at etablere asymmetrien forbundet med den nye sti, kan den ikke kalibreres til TE. Det vil dog være underlagt frekvenskorrektion i henhold til standarden. Resultatet er, at faseoutputtet hurtigt vil blive påvirket af GNSS-tab.
2. Hvis systemet bruger AAC-forbedret G.8273.4.
   en. Da GNSS ikke er tilgængelig til at etablere asymmetrien forbundet med den nye sti, kan den ikke kalibreres til TE. Men hvis denne nye sti er blevet set tidligere, vil den have en TE-signatur, der gør det muligt for systemet at tilpasse sig den nye sti. Resultatet er, at faseoutputtet ikke vil blive påvirket af GNSS-tab.

Der er nu to hovedbegivenhedsmuligheder:

1. Den oprindelige PTP-sti vender tilbage. Dette vil medføre yderligere systemomlægning. Detektering af den kendte signatur vil resultere i brugen af ​​den allerede kalibrerede PTP-input. Aktiv fasekontrol genoptages.
2. GNSS vender tilbage. Systemet vil fungere som normalt. Som vi allerede har nævnt, for at AAC skal fungere, skal den lokale GNSS være kvalificeret og operationel, fordi GNSS-inputtet bruges som kalibreringsværdien; PTP-inputstier sammenlignes og valideres mod denne værdi. Men når mindst én tabelindtastning har fundet sted, kan asymmetrifunktionen fungere uden GNSS.

Manuel indgriben af ​​begrænset værdi

AAC implementeret af Microchip muliggør brugerjustering af fasejusterede udgange, når PTP er den valgte inputreference. Dette giver mulighed for brugerkompensation af kendt, statisk asymmetri i PTP-inputstien.
Der er nogle brugstilfælde, hvor det er muligt at korrigere for en kendt fast eller konstant tidsfejl.
F.eksample, i et scenarie, hvor stien mellem kilde-PRTC og edge-PRTC vides at have en fast rate-konvertering fra 1GE til 100BASE-T. Denne hastighedskonvertering skaber kendt asymmetri på ca. 6 µs, hvilket ville resultere i 3 µs fasefejl (fejl på grund af asymmetri er altid halvdelen af ​​forskellen i vejlængderne).
For at kompensere manuelt skal brugeren kende asymmetrien på stien, og dette vil kræve måling. Denne konfigurationsmulighed er således kun levedygtig, når asymmetrien i PTP-stien er både kendt og konstant. Hvis der er en dynamisk skiftende asymmetri i stien, er denne funktion ikke nyttig, fordi den ikke kan tilpasse sig.
Styrken ved Microchip AAC på den anden side er, at den automatisk detekterer og kompenserer for asymmetri uden at skulle implementere en separat måling og injicere en værdi manuelt.

Konklusion

Figur 12-1. Oversigt over APTS AAC-driftEfterhånden som mobilnetværk udvikler sig fra frekvensbaserede netværk til tætte, højt distribuerede radiohoveder, der kræver fasejustering for at levere avancerede 5G-tjenester, bliver det i stigende grad nødvendigt at implementere PRTC'er rundt om kanten af ​​netværket. Disse PRTC'er kan beskyttes ved at implementere Assisted Partial Timing Support, G.8273.4, et ingeniørværktøj, der kan bruges til at sikkerhedskopiere PRTC'en ved kanten fra en kerne PRTC.
Standard APTS-algoritmen er imidlertid begrænset til at give tidsfejlskorrektion for én PTP-input-flow og mangler derfor en grundlæggende modstandsdygtighed; det vil sige evnen til at kalibrere og bruge mere end én PTP-inputsti, der er blevet korrigeret for tidsfejl.
Microchip har udviklet Automatic Asymmetry Compensation, en kraftig forbedring af standard APTS-implementeringen, der gør det muligt for Edge-PRTC at kalibrere op til 96 forskellige PTP-inputveje og derfor forblive i drift selv med betydelige og hyppige ændringer i transportnetværket.
Microchip er fokuseret på at levere ensartede, pålidelige værktøjer, der muliggør problemfri drift af næste generations clocking-systemer. APTS + AAC er endnu et væsentligt bidrag i denne lange rekord af innovation.

Revisionshistorie

Revisionshistorikken beskriver de ændringer, der blev implementeret i dokumentet. Ændringerne er listet efter revision, startende med den seneste publikation.

Revision	Dato	Beskrivelse
A	08/2024	Indledende revision

Mikrochip information
Mikrochippen Webwebsted
Microchip yder online support via vores website kl www.microchip.com/. Denne website bruges til at lave files og information let tilgængelig for kunderne. Noget af det tilgængelige indhold inkluderer:

• Produktsupport – Datablade og errata, applikationsnoter og sample-programmer, designressourcer, brugervejledninger og hardwaresupportdokumenter, seneste softwareudgivelser og arkiveret software
• Generel teknisk support – ofte stillede spørgsmål (ofte stillede spørgsmål), anmodninger om teknisk support, online diskussionsgrupper, medlemsliste for Microchip-designpartnerprogram
• Business of Microchip – Produktvælger- og bestillingsvejledninger, seneste Microchip-pressemeddelelser, oversigt over seminarer og arrangementer, lister over Microchip salgskontorer, distributører og fabriksrepræsentanter

Produktændringsmeddelelsesservice
Microchips underretningstjeneste for produktændringer hjælper med at holde kunderne opdateret på Microchip-produkter. Abonnenter vil modtage e-mail-meddelelser, når der er ændringer, opdateringer, revisioner eller fejl relateret til en specificeret produktfamilie eller udviklingsværktøj af interesse.
For at registrere, gå til www.microchip.com/pcn og følg registreringsvejledningen.

Kundesupport
Brugere af Microchip-produkter kan modtage assistance gennem flere kanaler:

• Distributør eller repræsentant
• Lokalt salgskontor
• Embedded Solutions Engineer (ESE)
• Teknisk support

Kunder bør kontakte deres distributør, repræsentant eller ESE for at få support. Lokale salgskontorer er også tilgængelige for at hjælpe kunder. En liste over salgskontorer og lokationer er inkluderet i dette dokument.
Teknisk support er tilgængelig via webwebsted på: www.microchip.com/support

Mikrochip-enheder kodebeskyttelsesfunktion
Bemærk følgende detaljer om kodebeskyttelsesfunktionen på Microchip-produkter:

• Microchip-produkter opfylder specifikationerne i deres særlige Microchip-datablad.
• Microchip mener, at dens familie af produkter er sikre, når de bruges på den tilsigtede måde, inden for driftsspecifikationerne og under normale forhold.
• Microchip værdsætter og beskytter aggressivt sine intellektuelle ejendomsrettigheder. Forsøg på at bryde kodebeskyttelsesfunktionerne i Microchip-produktet er strengt forbudt og kan være i strid med Digital Millennium Copyright Act.
• Hverken Microchip eller nogen anden halvlederproducent kan garantere sikkerheden af ​​deres kode. Kodebeskyttelse betyder ikke, at vi garanterer, at produktet er "ubrydeligt". Kodebeskyttelse er i konstant udvikling. Microchip er forpligtet til løbende at forbedre kodebeskyttelsesfunktionerne i vores produkter.

Juridisk meddelelse
Denne publikation og oplysningerne heri må kun bruges med Microchip-produkter, herunder til at designe, teste og integrere Microchip-produkter med din applikation. Brug af disse oplysninger på anden måde overtræder disse vilkår. Oplysninger om enhedsapplikationer gives kun for din bekvemmelighed og kan blive afløst af opdateringer. Det er dit ansvar at sikre, at din ansøgning lever op til dine specifikationer. Kontakt dit lokale Microchip salgskontor for yderligere support, eller få yderligere support på www.microchip.com/en-us/support/design-help/client-support-services.

DISSE OPLYSNINGER LEVERES AF MICROCHIP "SOM DE ER". MICROCHIP GIVER INGEN REPRÆSENTATIONER ELLER GARANTIER AF NOGEN ART, HVERKEN UDTRYKKELIGE ELLER UNDERFORSTÅEDE, SKRIFTLIGE ELLER mundtlige, LOVBESTEMMET ELLER ANDEN MÅDE, RELATET TIL OPLYSNINGERNE, INKLUSIVE MEN IKKE BEGRÆNSET TIL NOGEN STILTIENDE GARANTIER, GARANTIER OG GARANTIER. EGNETHED TIL ET BESTEMT FORMÅL ELLER GARANTIER RELATET TIL DETS TILSTAND, KVALITET ELLER YDELSE.
MICROCHIP VIL UNDER INGEN OMSTÆNDIGHEDER VÆRE ANSVARLIG FOR NOGEN INDIREKTE, SÆRLIGE, STRAFFENDE, TILFÆLDELIGE ELLER FØLGETAB, SKADER, OMKOSTNINGER ELLER UDGIFTER AF NOGEN ART, SOM ER RELATET TIL OPLYSNINGERNE ELLER DERES ANVENDELSE, UNDER ANDET ELLER ARGANG. MULIGHEDEN ELLER SKADERNE ER FORUDSIGELIGE. I DET FULDSTÆNDE OMFANG, DET ER TILLADT AF LOVEN, VIL MICROCHIPS SAMLEDE ANSVAR PÅ ALLE KRAV PÅ NOGEN MÅDE RELATET TIL INFORMATIONEN ELLER DERES ANVENDELSE IKKE OVERstige BELØBET, HVIS NOGET, SOM DU HAR BETALT DIREKTE TIL MICRATIONOCHIP.
Brug af Microchip-enheder i livsstøtte- og/eller sikkerhedsapplikationer er helt på købers risiko, og køberen indvilliger i at forsvare, skadesløsholde og holde Microchip skadesløs fra enhver skade, krav, sager eller udgifter som følge af sådan brug. Ingen licenser videregives, implicit eller på anden måde, under nogen af ​​Microchips intellektuelle ejendomsrettigheder, medmindre andet er angivet.

Varemærker
Mikrochipnavnet og logoet, mikrochiplogoet, Adaptec, AVR, AVR-logoet, AVR Freaks, BesTime, BitCloud, CryptoMemory, CryptoRF, dsPIC, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi logo, MOST, MOST logo, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logo, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom , SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron og XMEGA er registrerede varemærker tilhørende Microchip Technology Incorporated i USA og andre lande.
AgileSwitch, ClockWorks, The Embedded Control Solutions Company, EtherSynch, Flashtec, Hyper Speed ​​Control, HyperLight Load, Libero, motorBench, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus logo, Quiet-Wire, SmartFusion, SyncWorld, TimeCesium, TimeHub, TimePictra, TimeProvider og ZL er registrerede varemærker tilhørende Microchip Technology Incorporated i USA
Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, Clockstudio, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Dynamic Average Matching. , DAM, ECAN, Espresso T1S, EtherGREEN, EyeOpen, GridTime, IdealBridge, IgaT, In-Circuit Serial Programmering, ICSP, INICnet, Intelligent Paralleling, IntelliMOS, Inter-Chip Connectivity, JitterBlocker, Knob-on-Display, MarginLinko, maxCrypto maxView, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Certified logo, MPLIB, MPLINK, mSiC, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, Power MOS IV, Power MOS 7, PowerSmart, PureSilicon , QMatrix, REAL ICE, Ripple Blocker, RTAX, RTG4, SAM-ICE, Serial Quad I/O, simpleMAP, SimpliPHY, SmartBuffer, SmartHLS, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Endurance , Trusted Time, TSHARC, Turing, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect og ZENA er varemærker tilhørende Microchip Technology Incorporated i USA og andre lande.
SQTP er et servicemærke tilhørende Microchip Technology Incorporated i USA
Adaptec-logoet, Frequency on Demand, Silicon Storage Technology og Symmcom er registrerede varemærker tilhørende Microchip Technology Inc. i andre lande.
GestIC er et registreret varemærke tilhørende Microchip Technology Germany II GmbH & Co. KG, et datterselskab af Microchip Technology Inc., i andre lande.

Alle andre varemærker nævnt heri tilhører deres respektive virksomheder.
© 2024, Microchip Technology Incorporated og dets datterselskaber. Alle rettigheder forbeholdes.
ISBN: 978-1-6683-0120-3
Kvalitetsstyringssystem
For information om Microchips kvalitetsstyringssystemer, besøg venligst www.microchip.com/quality.

Verdensomspændende salg og service

AMERIKA	ASIEN/PACIFIK	ASIEN/PACIFIK	EUROPA
Virksomhedskontor 2355 West Chandler Blvd. Chandler, AZ 85224-6199 Tlf.: 480-792-7200 Fax: 480-792-7277 Teknisk support: www.microchip.com/support Web Adresse: www.microchip.com Atlanta Duluth, GA Tlf.: 678-957-9614 Fax: 678-957-1455 Austin, TX Tlf.: 512-257-3370 Boston Westborough, MA Tlf.: 774-760-0087 Fax: 774-760-0088 Chicago Itasca, IL Tlf.: 630-285-0071 Fax: 630-285-0075 Dallas Addison, TX Tlf.: 972-818-7423 Fax: 972-818-2924 Detroit Novi, MI Tlf.: 248-848-4000 Houston, TX Tlf.: 281-894-5983 Indianapolis Noblesville, IN Tlf.: 317-773-8323 Fax: 317-773-5453 Tlf.: 317-536-2380 Los Angeles Mission Viejo, CA Tlf.: 949-462-9523 Fax: 949-462-9608 Tlf.: 951-273-7800 Raleigh, NC Tlf.: 919-844-7510 New York, NY Tlf.: 631-435-6000 San Jose, CA Tlf.: 408-735-9110 Tlf.: 408-436-4270 Canada – Toronto Tlf.: 905-695-1980 Fax: 905-695-2078	Australien – Sydney Tlf.: 61-2-9868-6733 Kina – Beijing Tlf.: 86-10-8569-7000 Kina – Chengdu Tlf.: 86-28-8665-5511 Kina – Chongqing Tlf.: 86-23-8980-9588 Kina – Dongguan Tlf.: 86-769-8702-9880 Kina – Guangzhou Tlf.: 86-20-8755-8029 Kina – Hangzhou Tlf.: 86-571-8792-8115 Kina – Hong Kong SAR Tlf.: 852-2943-5100 Kina – Nanjing Tlf.: 86-25-8473-2460 Kina – Qingdao Tlf.: 86-532-8502-7355 Kina – Shanghai Tlf.: 86-21-3326-8000 Kina – Shenyang Tlf.: 86-24-2334-2829 Kina – Shenzhen Tlf.: 86-755-8864-2200 Kina – Suzhou Tlf.: 86-186-6233-1526 Kina – Wuhan Tlf.: 86-27-5980-5300 Kina – Xian Tlf.: 86-29-8833-7252 Kina – Xiamen Tlf.: 86-592-2388138 Kina – Zhuhai Tlf.: 86-756-3210040	Indien – Bangalore Tlf.: 91-80-3090-4444 Indien – New Delhi Tlf.: 91-11-4160-8631 Indien - Pune Tlf.: 91-20-4121-0141 Japan – Osaka Tlf.: 81-6-6152-7160 Japan – Tokyo Tlf.: 81-3-6880- 3770 Korea – Daegu Tlf.: 82-53-744-4301 Korea – Seoul Tlf.: 82-2-554-7200 Malaysia - Kuala Lumpur Tlf.: 60-3-7651-7906 Malaysia – Penang Tlf.: 60-4-227-8870 Filippinerne – Manila Tlf.: 63-2-634-9065 Singapore Tlf.: 65-6334-8870 Taiwan – Hsin Chu Tlf.: 886-3-577-8366 Taiwan – Kaohsiung Tlf.: 886-7-213-7830 Taiwan - Taipei Tlf.: 886-2-2508-8600 Thailand – Bangkok Tlf.: 66-2-694-1351 Vietnam – Ho Chi Minh Tlf.: 84-28-5448-2100	Østrig – Wels Tlf.: 43-7242-2244-39 Fax: 43-7242-2244-393 Danmark – København Tlf.: 45-4485-5910 Fax: 45-4485-2829 Finland – Espoo Tlf.: 358-9-4520-820 Frankrig – Paris Tel: 33-1-69-53-63-20 Fax: 33-1-69-30-90-79 Tyskland – Garching Tlf.: 49-8931-9700 Tyskland – Haan Tlf.: 49-2129-3766400 Tyskland – Heilbronn Tlf.: 49-7131-72400 Tyskland – Karlsruhe Tlf.: 49-721-625370 Tyskland – München Tel: 49-89-627-144-0 Fax: 49-89-627-144-44 Tyskland – Rosenheim Tlf.: 49-8031-354-560 Israel – Hod Hasharon Tlf.: 972-9-775-5100 Italien – Milano Tlf.: 39-0331-742611 Fax: 39-0331-466781 Italien – Padova Tlf.: 39-049-7625286 Holland – Drunen Tlf.: 31-416-690399 Fax: 31-416-690340 Norge – Trondheim Tlf.: 47-72884388 Polen – Warszawa Tlf.: 48-22-3325737 Rumænien – Bukarest Tel: 40-21-407-87-50 Spanien - Madrid Tel: 34-91-708-08-90 Fax: 34-91-708-08-91 Sverige – Göteborg Tel: 46-31-704-60-40 Sverige – Stockholm Tlf.: 46-8-5090-4654 Storbritannien – Wokingham Tlf.: 44-118-921-5800 Fax: 44-118-921-5820

 Hvidbog
© 2024 Microchip Technology Inc. og dets datterselskaber
DS00005550A

Dokumenter/ressourcer

MICROCHIP Assuring Mobile Services with Assisted Partial Timing Support White Paper [pdf] Instruktioner DS00005550A, Assuring Mobile Services with Assisted Partial Timing Support White Paper, Mobile Services with Assisted Partial Timing Support White Paper, Services with Assisted Partial Timing Support White Paper, Assisted Partial Timing Support White Paper, Partial Timing Support White Paper, Timing Support White Paper, Støtte hvidbog, papir

Referencer

• Brugermanual