專利名稱：設(shè)置通信網(wǎng)絡(luò)中的實時時鐘的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信網(wǎng)絡(luò)，具體地說，涉及這類網(wǎng)絡(luò)中的實時時鐘的設(shè)置。
許多網(wǎng)絡(luò)包括用來控制及配置網(wǎng)絡(luò)單元的管理層。這種網(wǎng)絡(luò)的一個示例是同步數(shù)字序列(SDH)傳輸網(wǎng)。

圖1說明這種網(wǎng)絡(luò)中的一種典型情況。管理系統(tǒng)10和網(wǎng)元12、14通過數(shù)據(jù)通信網(wǎng)絡(luò)(DCN)16互相通信。管理系統(tǒng)執(zhí)行多個功能，其中包括配置、性能量度的收集以及告警狀態(tài)的收集。為了實現(xiàn)穩(wěn)固的通信以及允許正確地路由數(shù)據(jù)，在整個網(wǎng)絡(luò)上采用標(biāo)準(zhǔn)協(xié)議，例如OSI(開放式系統(tǒng)互連)和TCP/IP(傳輸控制協(xié)議/因特網(wǎng)協(xié)議)。傳送管理層的網(wǎng)絡(luò)可完全獨立于網(wǎng)元，稱之為帶外，或者管理層在網(wǎng)元處理的業(yè)務(wù)中傳送，稱作帶內(nèi)。在SDH的示例中，它通常在SDH標(biāo)準(zhǔn)定義的業(yè)務(wù)段開銷(SOH)中的數(shù)據(jù)通信信道(DCC)中傳送。
在管理系統(tǒng)正收集性能及告警狀態(tài)數(shù)據(jù)的情況下，重要的是知道在什么時期收集數(shù)據(jù)和/或給定事件發(fā)生的精確時間。這在檢驗交付給客戶的業(yè)務(wù)質(zhì)量以及網(wǎng)絡(luò)中故障定位時極為重要。
在告警情況下，重要的是準(zhǔn)確地使各告警關(guān)聯(lián)以協(xié)助故障定位，從而快速確立對特定客戶的任何業(yè)務(wù)損失影響。
管理系統(tǒng)通常具有全球定位系統(tǒng)(GPS)鏈路18(參見圖1)，以提供高精度的時間基準(zhǔn)。它使得能夠?qū)r間作為實時時鐘設(shè)置到網(wǎng)元中，以便能夠精確地指明收集性能數(shù)據(jù)或告警的時間。一旦從GPS中獲得時間，管理系統(tǒng)立即通過DCN將該時間分配給所有網(wǎng)元。根據(jù)網(wǎng)元中的實時時鐘(RTC)的運行精確度，管理系統(tǒng)可以定期間隔更新網(wǎng)元RTC，所述定期間隔通?？蓮臄?shù)小時到數(shù)天不等。
本領(lǐng)域的技術(shù)人員非常了解，在網(wǎng)元中精確地設(shè)置實時時鐘存在一些相關(guān)的問題。這些問題之所以出現(xiàn)是因為以下三個主要原因數(shù)據(jù)通信網(wǎng)絡(luò)中的傳輸延時；當(dāng)在給定網(wǎng)元處收到時間時的設(shè)置延時；以及數(shù)據(jù)通信網(wǎng)絡(luò)協(xié)議重傳。
這些原因中的第一個原因，即傳輸延時是因為要通過DCN對消息進行路由。在大型網(wǎng)絡(luò)中，消息可能經(jīng)過若干分別用于存儲、處理以及轉(zhuǎn)發(fā)消息的單元。傳輸延時通常很小，數(shù)量級為5ms。由于傳輸延時是相當(dāng)穩(wěn)定且可預(yù)測的，因此可通過簡單減法加以補償。
設(shè)置延時僅適用于接收網(wǎng)元，它是端接接收消息和設(shè)置內(nèi)部RTC所花費的時間。如同傳輸延時一樣，它是可控的，且可通過為RTC設(shè)置提供高軟件優(yōu)先級來減少到數(shù)百ms。
最難于解決的延時源在于DCN協(xié)議重傳。DCN網(wǎng)絡(luò)是穩(wěn)固的，照顧到消息傳輸失敗。通常傳輸層所用的協(xié)議考慮到失敗檢測以及消息重傳。由于失敗可能是由DCN網(wǎng)絡(luò)中的暫時過負(fù)荷引起的，故重傳協(xié)議具有后退機制，即重傳之前要等待一段時間。這可以參考圖2來理解，圖2是表示管理系統(tǒng)、數(shù)據(jù)通信網(wǎng)絡(luò)以及網(wǎng)元的事件序列的示意時序圖，消息20由管理系統(tǒng)經(jīng)DCN發(fā)送給網(wǎng)元。DCN試圖將接收自管理系統(tǒng)的消息發(fā)送給網(wǎng)元的頭三次嘗試失敗，第四次嘗試消息才得以發(fā)送。增加相繼嘗試之間的延時，以增加成功率。因此，第一次和第二次嘗試之間的延時為四秒；第二次和第三次嘗試之間的延時為八秒；以及第三次和第四次嘗試之間的延時為16秒，產(chǎn)生總計為28秒的延時。
這種延時引起的最主要的問題在于由于重傳由DCN中的協(xié)議來處理，故管理系統(tǒng)或者網(wǎng)元均不了解它。而且，DCN協(xié)議重傳的消息始終與管理系統(tǒng)提供的消息相同。因此，在本給出的示例中，在網(wǎng)元處接收的時間值相對實時慢28秒。
由于這種延時積累，大型網(wǎng)絡(luò)中網(wǎng)元的時間值會在很大范圍內(nèi)變化。取決于為DCN協(xié)議設(shè)定的重傳時間，它可能高達64秒。
為解決上述問題，已經(jīng)進行了許多嘗試。但是，所提出的解決方案沒有令人滿意的。解決這個問題的現(xiàn)有嘗試依靠管理或主控系統(tǒng)不斷請求以及比較網(wǎng)絡(luò)上的時間。計算差值并根據(jù)需要對發(fā)送的時間進行調(diào)整。這種方法適用于合理受控的網(wǎng)絡(luò)，但可靠性在大型網(wǎng)絡(luò)中會降低，因為其中可能經(jīng)常發(fā)生重傳。其在大型網(wǎng)絡(luò)上的運行也很復(fù)雜。
所提出的其它解決方案依靠通過網(wǎng)元傳送的業(yè)務(wù)量發(fā)出某種形式的RTC指示。它迅速在網(wǎng)絡(luò)上傳播，以允許精確的RTC設(shè)置。但是，這種方法耗費寶貴的業(yè)務(wù)帶寬，并要求業(yè)務(wù)量的復(fù)雜互連以確保網(wǎng)絡(luò)中的所有網(wǎng)元均可接收到它。
因此，本發(fā)明的目的是提供一種設(shè)置實時時鐘的改進方法，它克服或減輕上述缺點。
在最廣義方面，本發(fā)明通過從網(wǎng)元向RTC源發(fā)送RTC請求消息，至少部分克服了上述問題。這使得能夠監(jiān)測往返時間。如果不在預(yù)定范圍之內(nèi)，則拒絕所接收的RTC值并發(fā)出新的請求。
更具體地說，提供一種方法，用于設(shè)置具有與網(wǎng)絡(luò)中的網(wǎng)元進行通信的管理系統(tǒng)的數(shù)據(jù)通信網(wǎng)絡(luò)的網(wǎng)元中的實時時鐘，該方法的特征在于將消息從網(wǎng)元發(fā)送給管理系統(tǒng)，以請求實時時鐘(RTC)值；在網(wǎng)元處接收RTC值；測量發(fā)送RTC請求消息和接收RTC值之間所耗費的時間；將測量時間與預(yù)定可接受的時間進行比較；以及如果測量值是可接受的則用接收值來設(shè)置網(wǎng)元實時時鐘。
本發(fā)明還為具有與網(wǎng)絡(luò)中網(wǎng)元進行通信的管理系統(tǒng)的數(shù)據(jù)通信網(wǎng)絡(luò)提供一種網(wǎng)元，該網(wǎng)元包括實時時鐘；消息發(fā)生器，用于生成并向管理系統(tǒng)發(fā)送RTC值請求；消息接收器，用于從管理系統(tǒng)接收所請求的RTC值；定時器，用于測量發(fā)送RTC請求消息和接收RTC值之間的時間；比較器，用于將測量時間與預(yù)定可接受時間進行比較；以及在該值可接受時用所接收的RTC值來設(shè)置網(wǎng)元實時時鐘的裝置。
本發(fā)明還提供一種數(shù)據(jù)通信系統(tǒng)，其包括至少一個網(wǎng)元和管理系統(tǒng)，網(wǎng)元和管理系統(tǒng)通過通信網(wǎng)絡(luò)進行通信；其特征在于，該系統(tǒng)在網(wǎng)元處包括實時時鐘，由管理系統(tǒng)設(shè)置；消息發(fā)生器，用于生成并向管理系統(tǒng)發(fā)送RTC值請求；消息接收器，用于從管理系統(tǒng)接收所請求的RTC值；定時器，用于測量發(fā)送RTC請求消息和接收RTC值之間的時間；比較器，用于將測量時間與預(yù)定可接受時間進行比較；以及在該值可接受時用接收的RTC值來設(shè)置網(wǎng)元實時時鐘的裝置；而在管理系統(tǒng)處包括從網(wǎng)元接收RTC值請求消息并對其作出響應(yīng)而向網(wǎng)元發(fā)送RTC值的裝置。
本發(fā)明還提供一種方法，用于設(shè)置數(shù)據(jù)通信網(wǎng)絡(luò)的網(wǎng)元中的實時時鐘，其包括向遠(yuǎn)程RTC源請求實時時鐘值RTC；測量RTC請求和接收RTC值之間的時間長度；以及在測量時間長度處于預(yù)定可接受范圍之內(nèi)時更新網(wǎng)絡(luò)值的實時時鐘。
本發(fā)明的實施例的優(yōu)點在于通過脫離在不了解網(wǎng)元的情況下發(fā)出請求的現(xiàn)有技術(shù)的管理系統(tǒng)方案，可測量接收RTC值所耗用的時間。如果該RTC值過高，則可將其丟棄。
如果丟棄的RTC值的數(shù)量超過預(yù)定數(shù)量，則最好是向管理系統(tǒng)發(fā)送告警。其優(yōu)點在于就持續(xù)故障或問題向管理系統(tǒng)發(fā)出警告。
最好是修改可接受的RTC值，以將管理系統(tǒng)的傳輸時間納入考慮。在一個最佳實施例中，這是通過減去最小傳輸時間來實現(xiàn)的，而在另一個最佳實施例中，這是通過減去一半測量的傳輸時間來實現(xiàn)的。其優(yōu)點在于所設(shè)置的網(wǎng)元實時時鐘更為精確。
現(xiàn)在將參照附圖，僅作為示例來描述本發(fā)明的實施例，附圖包括前面所述的圖1是典型網(wǎng)絡(luò)配置的示意圖；前面所述的圖2說明從管理系統(tǒng)發(fā)送到網(wǎng)元的消息如何能夠積累相當(dāng)大的延時；圖3用管理系統(tǒng)和網(wǎng)元之間的消息流來說明本發(fā)明的原理；圖4說明在消息從網(wǎng)元向管理系統(tǒng)重傳的情況下，圖3所示示例是如何工作的；圖5類似于圖4，但消息從網(wǎng)元向管理系統(tǒng)重傳；圖6是說明網(wǎng)元處進行的步驟的流程圖；圖7是說明校正接收RTC的第一方法的流程圖；以及圖8是說明校正接收RTC的第二方法的流程圖。
本發(fā)明人理解，由于管理系統(tǒng)和網(wǎng)元不了解DCN網(wǎng)絡(luò)中的重傳，因此出現(xiàn)上述現(xiàn)有技術(shù)系統(tǒng)中的問題。這是因為消息通過DCN發(fā)送到網(wǎng)元要等待應(yīng)答。這確?？煽康膫鬏?，但在DCN中出現(xiàn)的延時是不可檢測的。
在將要描述的實施例中，過程正好相反。不是在某個預(yù)定時間從管理系統(tǒng)發(fā)送RTC設(shè)置，而是響應(yīng)網(wǎng)元的特定請求而發(fā)送RTC。網(wǎng)元可測量發(fā)出響應(yīng)和接收RTC之間的時間長度，并通過將測量時間長度與網(wǎng)元中所要求的精度進行比較來確定RTC值的有效性。
因此，序列控制位于網(wǎng)元中，其可控制并監(jiān)測整個過程。作為附加的好處，與所涉及的額外工作相關(guān)的處理問題分布在網(wǎng)絡(luò)中，而不是由例如管理系統(tǒng)中的一個進程來處理。
網(wǎng)元向管理系統(tǒng)請求RTC值，并對直到接收時的時間長度計時。這是相對時間，不涉及當(dāng)前RTC設(shè)置的任何固有精度，而只涉及給定時間長度的定時。
因此可確定RTC時間值的有效性。如果響應(yīng)所耗時間超過最大可接受值，則網(wǎng)元在允許DCN清除的后退期之后發(fā)出另一個請求。
圖3說明對于沒有重傳的成功請求而言，這是如何工作的。為了便于說明，可假設(shè)RTC的可接受精度在5秒之內(nèi)。也就是說，網(wǎng)元向管理系統(tǒng)發(fā)出RTC請求和網(wǎng)元接收該RTC之間所耗時間不得超過5秒。
各傳播分支均具有一個可預(yù)測的延時?？杉僭O(shè)網(wǎng)元和管理系統(tǒng)之間的傳輸時間在兩個方向上均為300ms，以及管理系統(tǒng)具有500ms的響應(yīng)時間。
因此，在圖3中的30處，網(wǎng)元啟動定時器并向數(shù)據(jù)通信網(wǎng)絡(luò)中的管理系統(tǒng)發(fā)送RTC請求。發(fā)送消息的第一次嘗試成功，正如從管理系統(tǒng)到網(wǎng)元的響應(yīng)一樣。當(dāng)標(biāo)號32處的網(wǎng)元接收到RTC時，就停止定時器。在這種情況下，測量時間為300ms+500ms+300ms＝1.1秒。它在5秒的可接受精度之內(nèi)，因此網(wǎng)元會接受它。
圖4和圖5中給出了存在重傳的序列。在圖4中，重傳是從網(wǎng)元到管理系統(tǒng)。在所示示例中，第一次嘗試失敗，4秒之后的第二次嘗試成功。RTC到達管理系統(tǒng)的總時間為(300×2ms)+4000ms＝4600ms(4.6秒)。第一次嘗試時，從管理系統(tǒng)起的返回路徑是成功的，結(jié)果啟動和停止定時器之間的總時間為4600ms+500ms管理響應(yīng)時間+300ms管理系統(tǒng)到網(wǎng)元的傳輸時間。于是總時間為5.4秒。這個時間是不可接受的，因此網(wǎng)元會拒絕該RTC值并發(fā)送新的請求。
應(yīng)理解，在圖4所示示例中，所接收的RTC是精確的，因為管理系統(tǒng)和網(wǎng)元之間不存在超過正常的300ms的延時。但是，網(wǎng)元只能測量往返的總時間而不能確定發(fā)生延時的位置。因此，網(wǎng)元必需拒絕接收的RTC值。
圖5與圖4的不同之處僅在于第一次嘗試時從網(wǎng)元發(fā)送到管理系統(tǒng)的RTC請求是成功的，但回送到網(wǎng)元的RTC消息僅在第二次嘗試時才是成功的，插入了4秒的額外延時。于是網(wǎng)元定時器記錄的總時間為5.4秒，必需拒絕該RTC值。應(yīng)理解，在本例中，RTC值實際上是不精確的，因為在它由管理系統(tǒng)發(fā)送之后，已經(jīng)產(chǎn)生相當(dāng)大的延時。
在拒絕接受接收到的RTC的情況下，網(wǎng)元繼續(xù)使用其現(xiàn)有的RTC，直到在可接受的時間長度內(nèi)RTC請求得到應(yīng)答。
在網(wǎng)元已經(jīng)拒絕接受預(yù)定數(shù)量的連續(xù)RTC值之后，將會出現(xiàn)超時，并且網(wǎng)元會向管理系統(tǒng)發(fā)出告警，允許管理系統(tǒng)進行干預(yù)。
圖6是說明網(wǎng)元處處理步驟的流程圖。在步驟100，網(wǎng)元向管理系統(tǒng)發(fā)送RTC值并啟動定時器。在步驟102，網(wǎng)元記錄RTC值并停止定時器。在步驟104，網(wǎng)元比較所經(jīng)過的時間。如果它等于預(yù)定最大值或在其范圍之內(nèi)，則在106，網(wǎng)元重置其RTC。如果所經(jīng)過的時間大于預(yù)定最大值，則在108，系統(tǒng)拒絕該RTC值，處理返回到開始，發(fā)送新的RTC請求。在RTC的拒絕之后，在110，拒絕計數(shù)器加1，以及在112，該計數(shù)器的值與預(yù)定數(shù)量進行比較。如果該計數(shù)值等于該數(shù)量，則在114，向管理系統(tǒng)發(fā)送告警。
網(wǎng)元知道從管理系統(tǒng)接收RTC消息耗費的時間。這種知識可用來校正實時時鐘。
第一種方法用于定義可取得的最小響應(yīng)時間。在上述示例中，它可能約為1秒。網(wǎng)元接著讓接收的時間增加1秒，以補償接收消息所耗費的時間。
第二個方法使校正基于接收消息所耗費的時間長度。網(wǎng)元增加接收響應(yīng)所耗費的總時間的一半，以降低網(wǎng)絡(luò)中傳輸所引起的任何誤差。如果延時出現(xiàn)在返回支路上(如圖5所示示例)，但總時間處于可接受的最大值范圍內(nèi)，則誤差可能會輕微增加，但仍處于可接受的限度之內(nèi)。
圖7和圖8所示流程圖中說明這樣兩個備選方案它們擴展了圖6所示的重置網(wǎng)元步驟106。圖7中，在步驟200，接收可接受RTC。在210，減去最小響應(yīng)時間，在212，更新網(wǎng)元RTC。圖8中，在步驟300，接收可接受RTC。在302，使時間計數(shù)器減半，在304，從接收的RTC中減去時間計數(shù)器值。在306，用新的值來更新RTC。
在不脫離所附權(quán)利要求限定的本發(fā)明的范圍的情況下，存在許多可能的針對所述實施例的變化和修改，并且它們是本領(lǐng)域的技術(shù)人員將會想到的。
權(quán)利要求
1.一種用于設(shè)置數(shù)據(jù)通信網(wǎng)絡(luò)的網(wǎng)元中的實時時鐘的方法，所述數(shù)據(jù)通信網(wǎng)絡(luò)具有與所述網(wǎng)絡(luò)中的所述網(wǎng)元進行通信的管理系統(tǒng)，所述方法的特征在于將消息從所述網(wǎng)元發(fā)送到所述管理系統(tǒng)，以請求實時時鐘(RTC)值；在所述網(wǎng)元處接收所述RTC值；測量發(fā)送所述RTC請求消息和接收所述RTC值之間耗費的時間；將所述測量時間與預(yù)定可接受時間進行比較；以及如果所述測量值是可接受的則用所述接收值來為所述網(wǎng)元設(shè)置實時時鐘。
2.如權(quán)利要求1所述的方法，其特征在于如果所述測量值和所述可接受值的比較表明所述測量值是不可接受的，則拒絕接受所述接收RTC值，并由所述網(wǎng)絡(luò)向所述管理系統(tǒng)發(fā)送另一個RTC值請求消息。
3.如權(quán)利要求2所述的方法，其特征在于在確定接收RTC值是不可接受的時，所述網(wǎng)元將所接收的不可接受值的數(shù)量與允許的最大數(shù)量進行比較，如果接收的不可接受值的數(shù)量等于所述允許的最大數(shù)量，則向所述管理系統(tǒng)發(fā)送告警。
4.如以上權(quán)利要求其中任一項所述的方法，其特征在于采用可接受的接收值來設(shè)置所述網(wǎng)元實時時鐘的所述步驟包括校正所述接收值以補償傳輸時間。
5.如權(quán)利要求4所述的方法，其特征在于校正所述接收RTC值的所述步驟包括從所述接收值中減去最小傳輸時間。
6.如權(quán)利要求4所述的方法，其特征在于校正所述接收RTC值的所述步驟包括減去發(fā)送所述RTC請求消息和接收所述RTC值之間耗費的所述測量時間的一半。
7.一種用于數(shù)據(jù)通信網(wǎng)絡(luò)的網(wǎng)元，所述數(shù)據(jù)通信網(wǎng)絡(luò)具有與所述網(wǎng)絡(luò)中的所述網(wǎng)元進行通信的管理系統(tǒng)，所述網(wǎng)元包括實時時鐘；消息發(fā)生器，用于生成并向所述管理系統(tǒng)發(fā)送RTC值請求；消息接收器，用于從所述管理系統(tǒng)接收所請求的RTC值；定時器，用于測量發(fā)送RTC請求消息和接收所述RTC值之間的所述時間；比較器，用于將所述測量時間與預(yù)定可接受時間進行比較；以及在所述值可接受時用所述接收RTC值來設(shè)置所述網(wǎng)元實時時鐘的裝置。
8.一種數(shù)據(jù)通信系統(tǒng)，其包括至少一個網(wǎng)元和管理系統(tǒng)，所述網(wǎng)元和所述管理系統(tǒng)通過所述通信網(wǎng)絡(luò)進行通信；所述系統(tǒng)在所述網(wǎng)元處包括實時時鐘，由所述管理系統(tǒng)設(shè)置；消息發(fā)生器，用于生成并向所述管理系統(tǒng)發(fā)送RTC值請求；消息接收器，用于從所述管理系統(tǒng)接收所請求的RTC值；定時器，用于測量發(fā)送RTC請求消息和接收所述RTC值之間的所述時間；比較器，用于將所述測量時間與預(yù)定可接受時間進行比較；以及在所述值可接受時用所述接收RTC值來設(shè)置所述網(wǎng)元實時時鐘的裝置；以及在所述管理系統(tǒng)處包括從所述網(wǎng)元接收RTC值請求消息以及對其作出響應(yīng)而向所述網(wǎng)元發(fā)送RTC值的裝置。
9.如權(quán)利要求7或8所述的網(wǎng)元或數(shù)據(jù)通信系統(tǒng)，其特征在于還包括在所述測量時間不可接受時拒絕接受所述接收RTC值的裝置。
10.如權(quán)利要求9所述的網(wǎng)元或數(shù)據(jù)通信系統(tǒng)，其特征在于所述網(wǎng)元包括另一個比較器，用于將不可接受的接收RTC值的數(shù)量與預(yù)定最大值進行比較；以及告警發(fā)生器，用在達到不可接受的值的所述預(yù)定最大數(shù)量時，生成告警并發(fā)送給所述管理系統(tǒng)。
11.如權(quán)利要求7至10其中任一項所述的網(wǎng)元或數(shù)據(jù)通信系統(tǒng)，其特征在于所述網(wǎng)元包括實時時鐘值校正器，用于校正接收的可接受實時時鐘值，以補償所述管理系統(tǒng)的傳輸時間。
12.如權(quán)利要求11所述的網(wǎng)元或數(shù)據(jù)通信系統(tǒng)，其特征在于所述實時時鐘值校正器包括減法器，用于從所述可接受RTC值中減去發(fā)送所述RTC值請求消息和接收所述RTC值之間的所述最小時間。
13.如權(quán)利要求11所述的網(wǎng)元或數(shù)據(jù)通信系統(tǒng)，其特征在于所述實時時鐘值校正器包括減法器，用于減去發(fā)送所述RTC請求消息和接收所述RTC值之間耗費的所述測量時間的一半。
14.一種用于設(shè)置數(shù)據(jù)通信網(wǎng)絡(luò)的網(wǎng)元中的實時時鐘的方法，其包括向遠(yuǎn)程RTC源請求實時時鐘值RTC；測量所述RTC請求和接收RTC值之間的所述時間長度；以及在所述測量時間長度處于預(yù)定可接受范圍之內(nèi)時更新所述網(wǎng)絡(luò)值的所述實時時鐘。
全文摘要
通信網(wǎng)絡(luò)中的實時時鐘請求經(jīng)數(shù)據(jù)通信網(wǎng)絡(luò)從網(wǎng)元發(fā)送給管理系統(tǒng)。將從發(fā)送請求到接收RTC所耗費的時間與預(yù)定最大值進行比較，如果它小于或等于最大值，則更新網(wǎng)元RTC。如果超過最大值，則丟棄該值，并發(fā)送新的請求。接收的可接受RTC可通過減去最小傳輸時間或減去實際傳輸時間的一半來加以校正。
文檔編號H04J3/06GK1496618SQ02806521
公開日2004年5月12日 申請日期2002年1月17日 優(yōu)先權(quán)日2001年1月17日
發(fā)明者A·J·巴克, A J 巴克 申請人:馬科尼英國知識產(chǎn)權(quán)有限公司