通信ネットワークにおいてネットワーク要素のソフトウエアを更新する方法
第１タイプの複数のネットワーク要素の動作が第２タイプのネットワーク要素の動作に依存する通信ネットワークのネットワーク要素におけるソフトウエアの更新方法。この方法は、第２タイプのネットワーク要素と第１タイプのネットワーク要素の少なくとも一部により更新パッケージを受信する（１０２）。第１タイプのネットワーク要素の少なくとも一部が待機状態（１１０）に入り、第２タイプのネットワーク要素の更新を検出すると前記少なくとも一部が更新を開始する（１０６）。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は一般の通信ネットワークに関し、特に通信ネットワークのネットワーク要素においてソフトウエアを更新することに関する。
【背景技術】
【０００２】
現在のところ、通信オペレータは無線ネットワークサブシステム（ＲＮＳ）、すなわち、無線ネットワークコントローラ（ＲＮＣ）や無線基地局（ＲＢＳ）を別の時間に更新する。そしてそれは普通は異なった保守の期間、多くは夜間に行われる。ＲＮＣが更新しているときはどのような呼も扱えない。同様に、ＲＢＳが更新しているときはどのような呼も扱えない。
【０００３】
ネットワークでの運用上このようなソフトウエアの更新の影響を最小限にするために、ＲＢＳはバッチ処理で更新される。更新のためのＲＢＳのバッチを選択する方法は多くある。普通に使われるのは、同じような更新の時期であるＲＢＳのタイプに基づく方法である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明の目的は、上記の短所の少なくともいくつかを取り除き通信ネットワークのネットワーク要素におけるソフトウエアの更新を改善する方法を提供することである。
【課題を解決するための手段】
【０００５】
本発明の第１の側面は、第１タイプの複数のネットワーク要素の動作が第２タイプのネットワーク要素の動作に依存する通信ネットワークのネットワーク要素のソフトウエアを更新する方法である。この方法は、第２タイプのネットワーク要素と少なくとも一部の第１タイプのネットワーク要素とにより更新パッケージを受信するステップを含む。少なくとも一部の前記第１タイプのネットワーク要素が待機状態に入り、前記第２タイプのネットワーク要素の更新が検出されると（１０６）、更新が開始される。
【０００６】
本発明の第２の側面は、更新パッケージが受信された後に待機状態に入るように構成された通信ネットワークに用いられる第１タイプのネットワーク要素を備える。第１タイプのネットワーク要素は、第２タイプのネットワーク要素の更新が開始されたことを検出した後に更新を開始するように構成され，第１タイプのネットワーク要素の動作は第２タイプのネットワーク要素の動作に依存する。
【０００７】
本発明の第３の側面は、第１タイプの複数のネットワーク要素と少なくとも一つの第２タイプのネットワーク要素を含む通信ネットワークを備え、前記第１タイプのネットワーク要素の動作が前記第２タイプのネットワーク要素の動作に依存する。両タイプのネットワーク要素は更新パッケージを受信するよう構成される。少なくとも一部の第１タイプのネットワーク要素は前記更新パッケージを受信した後に待機状態に入るよう構成されている。第１タイプのネットワーク要素は、第２タイプのネットワーク要素の更新が検出されると、更新を開始するように構成されている。
【０００８】
さらに本発明の特徴が独立項としてクレームされている。
【発明の効果】
【０００９】
この発明は、ＷＣＤＭＡ ＲＮＳが更新する間の通信の混乱を減らし、ＲＢＳが更新するための保守の機会の数を制限する利点を提供する。これは、ＲＮＣがＲＢＳよりも多くのモジュールを更新するためにＲＮＣの更新はＲＢＳを更新するよりもかなり多くの時間がかかるから、多くのＲＢＳが同時に更新可能にできることによる。
【図面の簡単な説明】
【００１０】
この発明は、図とともに以下の詳細な説明によって十分に理解されるだろう。
【図１】本発明の一実施例におけるネットワーク要素のソフトウエアの更新方法。
【図２】本発明の他の実施例におけるネットワーク要素のソフトウエアの更新方法。
【図３】本発明の他の実施例におけるネットワーク要素のソフトウエアの更新方法。
【図４】本発明の一実施例における通信ネットワーク。
【図５】本発明の一実施例における第１タイプのネットワーク要素。
【発明を実施するための形態】
【００１１】
この発明の実施例は以下に示される地域無線ネットワーク（ＷＲＡＮ）に関するが、他のタイプの無線通信ネットワークにも適用することができる。
【００１２】
多くのＲＢＳオペレーションと保守の通信が、通常Ｍｕｂといわれるインターフェイスを介してＲＮＣと行われる。もしネットワークオペレータがＲＮＣとＲＢＳを同時に更新したいとしても、ＲＢＳに影響をしながら部分的なＲＮＣを扱う通信の更新を同期して行う方法はないだろう。もしＭｕｂがＲＮＣを通過しようとすれば、Ｍｕｂの通信はＲＮＣのリスタート（あるいはＲＢＳを制御するＲＮＣのモジュールのリスタート）により割り込まれるから、同期して行うことはこの分野で知られている方法においては不可能である。さらにＭｕｒリンクは、ＲＢＳの更新がＯＳＳによって調整されないそのタイミングではＲＮＣの更新の間は中断される。
【００１３】
図１を参照すると、通信ネットワークの通信装置においてソフトウエアを更新する方法の一実施例が示されている。この発明は少なくとも２つのタイプのネットワークノード（２つのタイプとは、ネットワークで２つの異なる役割を有することをいう。）を有し、複数の第１タイプのネットワーク要素が第２タイプのネットワーク要素の動作に依存する無線通信ネットワークへ適用できる。一実施例において、第１タイプのノードは図４の４０２−４０８に示す無線基地局であり、第２タイプのノードは４１０に示す無線ネットワークコントローラである。
【００１４】
ネットワーク４００のＲＮＣ４１０とＲＢＳ４０２−４０６は、ＲＮＳのタイプの更新のため、ＯＳＳ４２０によって選択される。ＲＢＳ４０２−４０６とＲＮＣ４１０は適切な更新パッケージ１０２を受信する。その際にこの技術分野で必要とされかつ知られている更新前検査が実行される。一実施例では、更新パッケージを受信して、必要とされるＲＢＳの検査を実行した後で、更新パッケージを受信したＲＢＳは待機状態１０４になる。
【００１５】
ＯＳＳ４２０がＲＢＳをＲＮＳのタイプの更新をしようとするとき、図２に示すように、ＲＢＳはＲＮＣからのトリガ待ちのために、待機状態でフラグ２０２をセットすることが好ましい。
【００１６】
第２タイプのネットワーク要素の更新開始が検出されると、ＲＢＳの更新１１０が開始する。ＲＮＣ４１０が更新されると通信の処理に影響する。この状態で、ＲＮＣ４１０はＲＢＳ４０２−４０８へメッセージを送信することにより、ＲＮＣ４１０はどんな通信の処理もできないこととＲＢＳ４０２−４０８は余計な通信の混乱なしに更新できることを知らせる信号を送る。無線基地局（ＲＢＳ）は、ＲＮＣ４１０からのトリガのメッセージを待ち受ける２０６−１０８。ＲＮＣ４１０からの信号はＲＢＳ４０２−４０８の更新をトリガし、更新は、ＯＳＳ４２０から更新確認手順が送信されるまで続く。更新確認手順は、ノードがＯＳＳへ準備完了を知らせる更新の終了のときに送られるメッセージを参照する。ＯＳＳ（オペレータ）は新しい更新パッケージが有ることをＲＢＳへ確認する信号を送信することによって、更新を確認する（全てがうまくいったとき）。もしＲＢＳがこの信号を受信しなかったときは、ＲＢＳは前のソフトウエアに戻る。
【００１７】
実際の通信ネットワークではいろいろなタイプの無線基地局が配置されている。これらは同じ業者の異なるバージョンや型であったり、異なる業者からのものであったりする。特定のＲＮＣ４１０により制御されないＲＢＳも、更新が一つのタイプのＲＢＳだけに適用されるように、更新されなければならないだろう。この場合には、ソフトウエアの更新を選択されていない、すなわち、更新パッケージを受信できないし、結果的にフラグをセットできない無線基地局は、ＲＮＣのトリガになるメッセージが分からずＲＮＣの信号を何のためにも使用しない。
【００１８】
この発明の好ましい実施例では、ＲＮＣ４１０が通信を処理することができずかつＲＢＳ４０２−４０８がなんらかの余計な通信の混乱なしに更新できるように、ＮＢＡＰ（Ｎｏｄｅ Ｂ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）のセル再構成要求（ＣＥＬＬ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージがＲＮＣ４１０によってＲＢＳ４０２−４０８へ信号を送信するのに使用される。ＮＢＡＰは、ＲＮＣによりノードＢ（無線基地局）の制御に対する応答を可能にするＵＭＴＳ陸上無線アクセスネットワーク信号方式プロトコルである。
【００１９】
セル再構成要求メッセージは３ＧＰＰ２５．４３３標準規格と関連し、以下の表に記載される。
【００２０】
【表１】
【００２１】
Ｍ＝必須
Ｏ＝オプション
新しい「更新トリガ」情報要素（９．２．１．ｘｘ）は以下の表に記載される。更新トリガはＲＮＣがノードＢを更新するようトリガするかどうかを示すパラメータであり、別の言い方によれば、ＲＢＳの更新を開始するための前記メッセージにおいて受信される指示である。
【００２２】
【表２】
【００２３】
別の実施例において、更新をトリガする信号はＲＮＣ４１０からＲＢＳによって受信されたウイルティング命令（ｗｉｌｔｉｎｇ ｏｒｄｅｒ）である。ウイルティング命令とは、ＲＮＣから１以上のＲＢＳへの送信電力を減らす命令である。ＲＢＳのセル内での送信電力の減少はユーザ端末に対して他のセルか同じエリアのＧＳＭネットワークのような他のネットワークへのハンドオーバを強いる。
【００２４】
両者の更新は同じ時期に実行されるから時間が節約され、通信は１回しか妨害されない。
【００２５】
他の実施例において、このＲＮＣ更新はテストベッド状態でのＲＢＳの緊急更新（ＥＵ）試験の方法として使用される。最初に、ＥＵはＲＢＳ４０２−４０８に実装され、ＲＮＣモジュールがリスタートされる。リスタートしたＲＮＣ４１０は、前記モジュールが定義されるＩｕｂにてＲＢＳの更新を開始する。こうして他のモジュールに対して特定なモジュールの静的検査が可能である。
【００２６】
図３に示す本発明の他の実施例によれば、無線ネットワークコントローラ４１０は更新パッケージを受信する無線基地局４０２−４０８の更新をトリガするためのどのような特定のメッセージ２０６も送信しなくてもよい。この実施例では、ＲＢＳ４０２−４０８は前記ＲＮＣから少なくとも一部のＲＢＳへの通信３０６を検査し、所定の期間にもしも通信が検出されなかったらＲＮＣ４１０は更新を開始したためにサイレント状態であると想定され、前記選択されたＲＢＳにおいてもソフトウエアの更新が開始される。
【００２７】
好ましい実施例では、待機状態１０４、２０２になった後でタイマ５０８をスタートし３０２、タイマ５０８が終了３０４する迄、ＲＮＣ４１０からのトリガのメッセージ２０６を待つ。もしもタイマ５０８が終了する前にトリガメッセージが到着すると、無線基地局４０２−４０８は更新を開始１１０する。しかし、もしＲＮＣがタイマが終了する前になにもトリガメッセージを送信しなかったときは、ＲＢＳ４０２はＲＮＣ４１０から前記ＲＢＳ４０２への通信があるかどうか検査する。図５に示すようにＲＢＳは、無線ネットワークコントローラと通信をするためのインターフェイスとして動作する受信ユニット５０２と送信ユニット５０４を含む。ＷＣＤＭＡネットワークの場合、Ｉｕｂインターフェイスが参照される。もしも通信がなかったら、ＲＮＣが動作していないことを示し、ＲＢＳ１１０が更新を開始する。同じ動作が更新をするよう選択された全てのＲＢＳによって個々に実行される。この動作はＲＢＳ個々により、中心となるトリガメッセージなしに行われ、選択されたＲＢＳが更新を開始する状態になっているかどうか検査して、回答がイエスであれば、更新１１０が開始する。
【００２８】
もし何か通信が検出３０６されたら、それはＲＮＣがアクティブであり手続きが停止していること３０８を意味する。手続きが停止していることに代わる他の実施例は、タイマ５０８が再度開始して手続きがリスタートされることである。図５に示される実施例では、タイマ５０８、受信機５０２、送信機５０４（Ｉｕｂインターフェイス）が制御ユニット５０６（例えばプロセッサ）によって制御される。
【００２９】
ネットワーク４００で動作する無線通信コントローラ４１０は多数のモジュールを含み、それぞれのモジュールは無線基地局４０２−４０４のグループを制御する。それゆえに好ましい実施例では少なくとも一部の無線基地局４０２−４０４の更新１１０は、前記無線基地局４０２と４０４を制御するＲＮＣ４１０のモジュールが更新を開始したことを検出したときにスタートされる。この実施例ではＲＮＣ４１０のモジュールの一部が更新される。このことは、ＲＢＳの一部の保守運用が更新されないモジュールにより制御されることを求める。こうしてＲＮＣ４１０は一部が動作し、その結果、ネットワークでの更新による影響は減少される。
【００３０】
他の実施例では、無線ネットワークコントローラ以外のノードによって無線基地局が制御されてもよい。例えば、３Ｇネットワークで知られているＲＢＳ−ＲＮＣとは異なるアークテクチャの下では、無線基地局の異なった機能は異なったノードにより制御されてもよい。しかし、このことは本発明の課題を変更するものではない。コントロールノード（あるいはそのモジュール）の更新処理が被コントロールノード（例えばＲＢＳ）で検出されると、コントロールノードはＲＢＳからのどのような通信も処理できない、そしてこのことがＲＢＳの更新をトリガする。
【００３１】
図４は本発明に関連する通信ネットワーク４００の実施例を示す。ネットワーク４００はユーザ端末４１２，４１４にアクセスを提供する複数の基地局４０２−４０８を含む。簡単のために２台のユーザ端末が図示されている。ネットワーク４００はさらにネットワークコントローラ４１０を含んでいる。このような配置のネットワークにおいて、無線基地局４０２−４０８の動作は前記無線ネットワークコントローラ４１０の動作に依存する。少なくとも一部の無線基地局で無線ネットワークサブシステムの更新が計画されると、無線ネットワークコントローラ４１０は更新パッケージを受信する。ＲＢＳ４０２−４０８の一部のみが更新パッケージを受信する理由は、ＲＢＳは異なった製造者から供給されることがあり、更新はそのいくつかのためのみであってよく、しかし、全てのタイプのＲＢＳがネットワーク４００に配置されていないからである。しかし、全てのＲＢＳが同じタイプかあるいは更新が全てのＲＢＳへ適用できるかもしれない。これら更新パッケージを受信するＲＢＳ４０２−４０８は、更新パッケージを受信した後で待機状態に入る。少なくとも一部のＲＢＳ４０２−４０８の更新はＲＮＣ４１０の更新の開始が検出されたときに開始する。
【００３２】
一つの実施例では、無線ネットワークコントローラ４１０の更新の開始は、無線基地局によりＲＮＣ４１０からの更新開始を無線基地局へ指示するメッセージを受信することにより検出される。このメッセージは前記ＲＮＣ４１０の更新の開始に関連してＲＮＣ４１０により送信される。この実施例のメッセージは、無線ネットワークコントローラ４１０がどんな通信も処理できず、ＲＢＳ４０２−４０８はこのメッセージを自身の更新のトリガに使うことを示す。
【００３３】
また他の実施例では、ＲＢＳは受信機５０２を含み、受信機経由でＲＮＣ４１０から通信を受信し、所定時間内に受信機で通信が検出できないときはＲＢＳが更新を開始する。好ましくは、ＲＢＳはタイマ５０８を含み、このタイマは待機状態になった後で動作を開始する。ＲＮＣ４１０からＲＢＳ４２０への通信は監視され、タイマが動作終了する前にメッセージが受信されなかったときは、ＲＢＳ４０２の更新がスタートする。同じことは、更新のために選択された、言い換えれば、更新パッケージが受信された他のＲＢＳ、４０４−４０８に対しても適用できる。
【００３４】
本発明は、ＷＲＡＮ通信ネットワークだけではなく、一組のネットワークノードタイプが他のネットワークノードに依存する（機能が異なっている）ネットワークで使用できる。依存的な信号伝送は、依存するノードが停止中や保守中に、更新をトリガするのに使われる。この方法により全ネットワークの停止期間は減少する。
【技術分野】
【０００１】
この発明は一般の通信ネットワークに関し、特に通信ネットワークのネットワーク要素においてソフトウエアを更新することに関する。
【背景技術】
【０００２】
現在のところ、通信オペレータは無線ネットワークサブシステム（ＲＮＳ）、すなわち、無線ネットワークコントローラ（ＲＮＣ）や無線基地局（ＲＢＳ）を別の時間に更新する。そしてそれは普通は異なった保守の期間、多くは夜間に行われる。ＲＮＣが更新しているときはどのような呼も扱えない。同様に、ＲＢＳが更新しているときはどのような呼も扱えない。
【０００３】
ネットワークでの運用上このようなソフトウエアの更新の影響を最小限にするために、ＲＢＳはバッチ処理で更新される。更新のためのＲＢＳのバッチを選択する方法は多くある。普通に使われるのは、同じような更新の時期であるＲＢＳのタイプに基づく方法である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明の目的は、上記の短所の少なくともいくつかを取り除き通信ネットワークのネットワーク要素におけるソフトウエアの更新を改善する方法を提供することである。
【課題を解決するための手段】
【０００５】
本発明の第１の側面は、第１タイプの複数のネットワーク要素の動作が第２タイプのネットワーク要素の動作に依存する通信ネットワークのネットワーク要素のソフトウエアを更新する方法である。この方法は、第２タイプのネットワーク要素と少なくとも一部の第１タイプのネットワーク要素とにより更新パッケージを受信するステップを含む。少なくとも一部の前記第１タイプのネットワーク要素が待機状態に入り、前記第２タイプのネットワーク要素の更新が検出されると（１０６）、更新が開始される。
【０００６】
本発明の第２の側面は、更新パッケージが受信された後に待機状態に入るように構成された通信ネットワークに用いられる第１タイプのネットワーク要素を備える。第１タイプのネットワーク要素は、第２タイプのネットワーク要素の更新が開始されたことを検出した後に更新を開始するように構成され，第１タイプのネットワーク要素の動作は第２タイプのネットワーク要素の動作に依存する。
【０００７】
本発明の第３の側面は、第１タイプの複数のネットワーク要素と少なくとも一つの第２タイプのネットワーク要素を含む通信ネットワークを備え、前記第１タイプのネットワーク要素の動作が前記第２タイプのネットワーク要素の動作に依存する。両タイプのネットワーク要素は更新パッケージを受信するよう構成される。少なくとも一部の第１タイプのネットワーク要素は前記更新パッケージを受信した後に待機状態に入るよう構成されている。第１タイプのネットワーク要素は、第２タイプのネットワーク要素の更新が検出されると、更新を開始するように構成されている。
【０００８】
さらに本発明の特徴が独立項としてクレームされている。
【発明の効果】
【０００９】
この発明は、ＷＣＤＭＡ ＲＮＳが更新する間の通信の混乱を減らし、ＲＢＳが更新するための保守の機会の数を制限する利点を提供する。これは、ＲＮＣがＲＢＳよりも多くのモジュールを更新するためにＲＮＣの更新はＲＢＳを更新するよりもかなり多くの時間がかかるから、多くのＲＢＳが同時に更新可能にできることによる。
【図面の簡単な説明】
【００１０】
この発明は、図とともに以下の詳細な説明によって十分に理解されるだろう。
【図１】本発明の一実施例におけるネットワーク要素のソフトウエアの更新方法。
【図２】本発明の他の実施例におけるネットワーク要素のソフトウエアの更新方法。
【図３】本発明の他の実施例におけるネットワーク要素のソフトウエアの更新方法。
【図４】本発明の一実施例における通信ネットワーク。
【図５】本発明の一実施例における第１タイプのネットワーク要素。
【発明を実施するための形態】
【００１１】
この発明の実施例は以下に示される地域無線ネットワーク（ＷＲＡＮ）に関するが、他のタイプの無線通信ネットワークにも適用することができる。
【００１２】
多くのＲＢＳオペレーションと保守の通信が、通常Ｍｕｂといわれるインターフェイスを介してＲＮＣと行われる。もしネットワークオペレータがＲＮＣとＲＢＳを同時に更新したいとしても、ＲＢＳに影響をしながら部分的なＲＮＣを扱う通信の更新を同期して行う方法はないだろう。もしＭｕｂがＲＮＣを通過しようとすれば、Ｍｕｂの通信はＲＮＣのリスタート（あるいはＲＢＳを制御するＲＮＣのモジュールのリスタート）により割り込まれるから、同期して行うことはこの分野で知られている方法においては不可能である。さらにＭｕｒリンクは、ＲＢＳの更新がＯＳＳによって調整されないそのタイミングではＲＮＣの更新の間は中断される。
【００１３】
図１を参照すると、通信ネットワークの通信装置においてソフトウエアを更新する方法の一実施例が示されている。この発明は少なくとも２つのタイプのネットワークノード（２つのタイプとは、ネットワークで２つの異なる役割を有することをいう。）を有し、複数の第１タイプのネットワーク要素が第２タイプのネットワーク要素の動作に依存する無線通信ネットワークへ適用できる。一実施例において、第１タイプのノードは図４の４０２−４０８に示す無線基地局であり、第２タイプのノードは４１０に示す無線ネットワークコントローラである。
【００１４】
ネットワーク４００のＲＮＣ４１０とＲＢＳ４０２−４０６は、ＲＮＳのタイプの更新のため、ＯＳＳ４２０によって選択される。ＲＢＳ４０２−４０６とＲＮＣ４１０は適切な更新パッケージ１０２を受信する。その際にこの技術分野で必要とされかつ知られている更新前検査が実行される。一実施例では、更新パッケージを受信して、必要とされるＲＢＳの検査を実行した後で、更新パッケージを受信したＲＢＳは待機状態１０４になる。
【００１５】
ＯＳＳ４２０がＲＢＳをＲＮＳのタイプの更新をしようとするとき、図２に示すように、ＲＢＳはＲＮＣからのトリガ待ちのために、待機状態でフラグ２０２をセットすることが好ましい。
【００１６】
第２タイプのネットワーク要素の更新開始が検出されると、ＲＢＳの更新１１０が開始する。ＲＮＣ４１０が更新されると通信の処理に影響する。この状態で、ＲＮＣ４１０はＲＢＳ４０２−４０８へメッセージを送信することにより、ＲＮＣ４１０はどんな通信の処理もできないこととＲＢＳ４０２−４０８は余計な通信の混乱なしに更新できることを知らせる信号を送る。無線基地局（ＲＢＳ）は、ＲＮＣ４１０からのトリガのメッセージを待ち受ける２０６−１０８。ＲＮＣ４１０からの信号はＲＢＳ４０２−４０８の更新をトリガし、更新は、ＯＳＳ４２０から更新確認手順が送信されるまで続く。更新確認手順は、ノードがＯＳＳへ準備完了を知らせる更新の終了のときに送られるメッセージを参照する。ＯＳＳ（オペレータ）は新しい更新パッケージが有ることをＲＢＳへ確認する信号を送信することによって、更新を確認する（全てがうまくいったとき）。もしＲＢＳがこの信号を受信しなかったときは、ＲＢＳは前のソフトウエアに戻る。
【００１７】
実際の通信ネットワークではいろいろなタイプの無線基地局が配置されている。これらは同じ業者の異なるバージョンや型であったり、異なる業者からのものであったりする。特定のＲＮＣ４１０により制御されないＲＢＳも、更新が一つのタイプのＲＢＳだけに適用されるように、更新されなければならないだろう。この場合には、ソフトウエアの更新を選択されていない、すなわち、更新パッケージを受信できないし、結果的にフラグをセットできない無線基地局は、ＲＮＣのトリガになるメッセージが分からずＲＮＣの信号を何のためにも使用しない。
【００１８】
この発明の好ましい実施例では、ＲＮＣ４１０が通信を処理することができずかつＲＢＳ４０２−４０８がなんらかの余計な通信の混乱なしに更新できるように、ＮＢＡＰ（Ｎｏｄｅ Ｂ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）のセル再構成要求（ＣＥＬＬ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージがＲＮＣ４１０によってＲＢＳ４０２−４０８へ信号を送信するのに使用される。ＮＢＡＰは、ＲＮＣによりノードＢ（無線基地局）の制御に対する応答を可能にするＵＭＴＳ陸上無線アクセスネットワーク信号方式プロトコルである。
【００１９】
セル再構成要求メッセージは３ＧＰＰ２５．４３３標準規格と関連し、以下の表に記載される。
【００２０】
【表１】
【００２１】
Ｍ＝必須
Ｏ＝オプション
新しい「更新トリガ」情報要素（９．２．１．ｘｘ）は以下の表に記載される。更新トリガはＲＮＣがノードＢを更新するようトリガするかどうかを示すパラメータであり、別の言い方によれば、ＲＢＳの更新を開始するための前記メッセージにおいて受信される指示である。
【００２２】
【表２】
【００２３】
別の実施例において、更新をトリガする信号はＲＮＣ４１０からＲＢＳによって受信されたウイルティング命令（ｗｉｌｔｉｎｇ ｏｒｄｅｒ）である。ウイルティング命令とは、ＲＮＣから１以上のＲＢＳへの送信電力を減らす命令である。ＲＢＳのセル内での送信電力の減少はユーザ端末に対して他のセルか同じエリアのＧＳＭネットワークのような他のネットワークへのハンドオーバを強いる。
【００２４】
両者の更新は同じ時期に実行されるから時間が節約され、通信は１回しか妨害されない。
【００２５】
他の実施例において、このＲＮＣ更新はテストベッド状態でのＲＢＳの緊急更新（ＥＵ）試験の方法として使用される。最初に、ＥＵはＲＢＳ４０２−４０８に実装され、ＲＮＣモジュールがリスタートされる。リスタートしたＲＮＣ４１０は、前記モジュールが定義されるＩｕｂにてＲＢＳの更新を開始する。こうして他のモジュールに対して特定なモジュールの静的検査が可能である。
【００２６】
図３に示す本発明の他の実施例によれば、無線ネットワークコントローラ４１０は更新パッケージを受信する無線基地局４０２−４０８の更新をトリガするためのどのような特定のメッセージ２０６も送信しなくてもよい。この実施例では、ＲＢＳ４０２−４０８は前記ＲＮＣから少なくとも一部のＲＢＳへの通信３０６を検査し、所定の期間にもしも通信が検出されなかったらＲＮＣ４１０は更新を開始したためにサイレント状態であると想定され、前記選択されたＲＢＳにおいてもソフトウエアの更新が開始される。
【００２７】
好ましい実施例では、待機状態１０４、２０２になった後でタイマ５０８をスタートし３０２、タイマ５０８が終了３０４する迄、ＲＮＣ４１０からのトリガのメッセージ２０６を待つ。もしもタイマ５０８が終了する前にトリガメッセージが到着すると、無線基地局４０２−４０８は更新を開始１１０する。しかし、もしＲＮＣがタイマが終了する前になにもトリガメッセージを送信しなかったときは、ＲＢＳ４０２はＲＮＣ４１０から前記ＲＢＳ４０２への通信があるかどうか検査する。図５に示すようにＲＢＳは、無線ネットワークコントローラと通信をするためのインターフェイスとして動作する受信ユニット５０２と送信ユニット５０４を含む。ＷＣＤＭＡネットワークの場合、Ｉｕｂインターフェイスが参照される。もしも通信がなかったら、ＲＮＣが動作していないことを示し、ＲＢＳ１１０が更新を開始する。同じ動作が更新をするよう選択された全てのＲＢＳによって個々に実行される。この動作はＲＢＳ個々により、中心となるトリガメッセージなしに行われ、選択されたＲＢＳが更新を開始する状態になっているかどうか検査して、回答がイエスであれば、更新１１０が開始する。
【００２８】
もし何か通信が検出３０６されたら、それはＲＮＣがアクティブであり手続きが停止していること３０８を意味する。手続きが停止していることに代わる他の実施例は、タイマ５０８が再度開始して手続きがリスタートされることである。図５に示される実施例では、タイマ５０８、受信機５０２、送信機５０４（Ｉｕｂインターフェイス）が制御ユニット５０６（例えばプロセッサ）によって制御される。
【００２９】
ネットワーク４００で動作する無線通信コントローラ４１０は多数のモジュールを含み、それぞれのモジュールは無線基地局４０２−４０４のグループを制御する。それゆえに好ましい実施例では少なくとも一部の無線基地局４０２−４０４の更新１１０は、前記無線基地局４０２と４０４を制御するＲＮＣ４１０のモジュールが更新を開始したことを検出したときにスタートされる。この実施例ではＲＮＣ４１０のモジュールの一部が更新される。このことは、ＲＢＳの一部の保守運用が更新されないモジュールにより制御されることを求める。こうしてＲＮＣ４１０は一部が動作し、その結果、ネットワークでの更新による影響は減少される。
【００３０】
他の実施例では、無線ネットワークコントローラ以外のノードによって無線基地局が制御されてもよい。例えば、３Ｇネットワークで知られているＲＢＳ−ＲＮＣとは異なるアークテクチャの下では、無線基地局の異なった機能は異なったノードにより制御されてもよい。しかし、このことは本発明の課題を変更するものではない。コントロールノード（あるいはそのモジュール）の更新処理が被コントロールノード（例えばＲＢＳ）で検出されると、コントロールノードはＲＢＳからのどのような通信も処理できない、そしてこのことがＲＢＳの更新をトリガする。
【００３１】
図４は本発明に関連する通信ネットワーク４００の実施例を示す。ネットワーク４００はユーザ端末４１２，４１４にアクセスを提供する複数の基地局４０２−４０８を含む。簡単のために２台のユーザ端末が図示されている。ネットワーク４００はさらにネットワークコントローラ４１０を含んでいる。このような配置のネットワークにおいて、無線基地局４０２−４０８の動作は前記無線ネットワークコントローラ４１０の動作に依存する。少なくとも一部の無線基地局で無線ネットワークサブシステムの更新が計画されると、無線ネットワークコントローラ４１０は更新パッケージを受信する。ＲＢＳ４０２−４０８の一部のみが更新パッケージを受信する理由は、ＲＢＳは異なった製造者から供給されることがあり、更新はそのいくつかのためのみであってよく、しかし、全てのタイプのＲＢＳがネットワーク４００に配置されていないからである。しかし、全てのＲＢＳが同じタイプかあるいは更新が全てのＲＢＳへ適用できるかもしれない。これら更新パッケージを受信するＲＢＳ４０２−４０８は、更新パッケージを受信した後で待機状態に入る。少なくとも一部のＲＢＳ４０２−４０８の更新はＲＮＣ４１０の更新の開始が検出されたときに開始する。
【００３２】
一つの実施例では、無線ネットワークコントローラ４１０の更新の開始は、無線基地局によりＲＮＣ４１０からの更新開始を無線基地局へ指示するメッセージを受信することにより検出される。このメッセージは前記ＲＮＣ４１０の更新の開始に関連してＲＮＣ４１０により送信される。この実施例のメッセージは、無線ネットワークコントローラ４１０がどんな通信も処理できず、ＲＢＳ４０２−４０８はこのメッセージを自身の更新のトリガに使うことを示す。
【００３３】
また他の実施例では、ＲＢＳは受信機５０２を含み、受信機経由でＲＮＣ４１０から通信を受信し、所定時間内に受信機で通信が検出できないときはＲＢＳが更新を開始する。好ましくは、ＲＢＳはタイマ５０８を含み、このタイマは待機状態になった後で動作を開始する。ＲＮＣ４１０からＲＢＳ４２０への通信は監視され、タイマが動作終了する前にメッセージが受信されなかったときは、ＲＢＳ４０２の更新がスタートする。同じことは、更新のために選択された、言い換えれば、更新パッケージが受信された他のＲＢＳ、４０４−４０８に対しても適用できる。
【００３４】
本発明は、ＷＲＡＮ通信ネットワークだけではなく、一組のネットワークノードタイプが他のネットワークノードに依存する（機能が異なっている）ネットワークで使用できる。依存的な信号伝送は、依存するノードが停止中や保守中に、更新をトリガするのに使われる。この方法により全ネットワークの停止期間は減少する。
【特許請求の範囲】
【請求項１】
第１タイプの複数のネットワーク要素の動作が第２タイプのネットワーク要素の動作に依存する通信ネットワークのネットワーク要素のソフトウエアを更新する方法であって、
第２タイプのネットワーク要素と少なくとも一部の第１タイプのネットワーク要素とにより更新パッケージを受信するステップと（１０２）、
前記少なくとも一部の前記第１タイプのネットワーク要素の前記少なくとも一部が待機状態に入るステップと（１０４）、
前記第２タイプのネットワーク要素の更新が検出されると（１０６）、前記少なくとも一部の前記第１タイプのネットワーク要素の更新を開始するステップと（１１０）、
を含む方法。
【請求項２】
前記待機状態（１０４）において前記少なくとも一部の前記第１タイプのネットワーク要素において前記第２タイプのネットワーク要素からの信号を待ち受けるフラグがセットされることを特徴とする請求項１に記載の方法。
【請求項３】
前記少なくとも一部の第１タイプのネットワーク要素が、前記第２タイプのネットワーク要素から、前記更新を開始（１１０）することを命じるメッセージ（２０６）を受信することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記第１タイプのネットワーク要素は前記第２タイプのネットワーク要素から、前記第２タイプのネットワーク要素が通信処理をすることができないことを知らせるメッセージ（２０６）を受信し、前記少なくとも一部の前記第１タイプのネットワーク要素は前記メッセージを前記更新開始（１１０）のトリガとして使うことを特徴とする請求項１又は２に記載の方法。
【請求項５】
前記第１タイプのネットワーク要素は前記第２タイプのネットワーク要素から前記第１タイプのネットワーク要素の前記少なくとも一部への通信を検査し（３０６）、所定時間内に通信が検出されなかったときに更新を開始（１１０）することを特徴とする請求項１又は２に記載の方法。
【請求項６】
前記待機状態（１０４、２０２）に入った後でタイマを開始（３０２）するステップと、
前記タイマが終了するまで（３０４）第２タイプのネットワーク要素からのメッセージを待ち受けるステップ（２０６）と、
前記タイマが終了する前にメッセージが受信されていないか、前記第２タイプのネットワーク要素から前記少なくとも一部の前記第１タイプのネットワーク要素への通信を検査するステップ（３０６）と、
所定時間の間に通信がないことを検出すると前記更新を開始する（１１０）ことを含むことを特徴とする、
請求項３又は４に記載の方法。
【請求項７】
前記第１タイプのネットワーク要素は無線基地局を含み、前記第２タイプのネットワーク要素は無線ネットワークコントローラを含むことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記第１タイプのネットワーク要素の前記少なくとも一部を制御する前記第２タイプのネットワーク要素の少なくとも一部のモジュールの更新が検出されたとき（１０６）、前記第１タイプのネットワーク要素の前記少なくとも一部が更新を開始（１１０）することを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
通信ネットワーク４００において使用され、更新パッケージを受信した後に待機状態に入り、第２タイプのネットワーク要素（４１０）が更新を開始したことを検出した後で更新を開始するようにされた第１タイプのネットワーク要素であって、前記第１タイプのネットワーク要素（４０２−４０８）の動作が前記第２タイプのネットワーク要素（４１０）の動作に依存することを特徴とする第１タイプのネットワーク要素（４０２−４０８）。
【請求項１０】
前記待機状態を知らせるフラグをセットするように構成された請求項９に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１１】
前記第２タイプのネットワーク要素（４１０）からメッセージを受信し、前記メッセージ中に受信された指示に従って更新を開始することを特徴とする請求項９又は１０に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１２】
前記第２タイプのネットワーク要素（４１０）から、前記第２タイプのネットワーク要素（４１０）が通信処理をすることができないことを知らせるメッセージを受信し、さらに前記更新開始のトリガとして前記メッセージを使うように構成されたことを特徴とする請求項９又は１０に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１３】
前記第２タイプのネットワーク要素（４１０）から通信を受信し所定時間受信機（５０２）で通信が検出できなかったときに更新を開始するよう構成された受信機（５０２）を含むことを特徴とする請求項９に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１４】
前記待機状態に入った後でタイマ（５０８）がスタートされ、前記第２タイプのネットワーク要素（４１０）から受信される通信を検査し、前記タイマが終了する前にメッセージが受信されなかったときに更新を開始するように構成されたタイマ（５０８）を含むことを特徴とする請求項１３に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１５】
無線基地局（４０２−４０８）を含むことを特徴とする請求項８乃至１４のいずれか１項に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１６】
前記第１タイプのネットワーク要素を制御する前記第２タイプのネットワーク要素のモジュールの更新が検出（１０６）されると、前記第１タイプのネットワーク要素の更新が開始されるように構成された請求項９乃至１５のいずれか１項に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１７】
複数の第１タイプのネットワーク要素（４０２−４０８）と少なくとも一つの第２タイプのネットワーク要素（４１０）を含み、
前記第１タイプのネットワーク要素（４０２−４０８）の動作が前記第２タイプのネットワーク要素（４１０）の動作に依存し、両タイプのネットワーク要素は更新パッケージを受信するように構成され、前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）は前記更新パッケージを受信した後に待機状態に入り、前記第２タイプのネットワーク要素（４１０）の更新が検出されると前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）の更新が開始される通信ネットワーク（４００）。
【請求項１８】
前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）が前記第２タイプのネットワーク要素（４１０）から更新を開始するためのメッセージを受信することを特徴とする請求項１７に記載の通信ネットワーク（４００）。
【請求項１９】
前記第１タイプのネットワーク要素（４０２−４０８）が前記第２タイプのネットワーク要素（４１０）から、前記第２タイプのネットワーク要素（４１０）が通信処理をすることができないことを知らせるメッセージを受信し、前記メッセージを前記第１タイプのネットワーク要素の前記更新開始のトリガとして使うよう構成されたことを特徴とする請求項１７に記載の通信ネットワーク（４００）
【請求項２０】
前記第１タイプのネットワーク要素（４０２−４０８）は、前記第２タイプのネットワーク要素（４１０）からの通信を受信する受信機（５０２）を含み、所定時間通信が前記受信機で検出されないときに前記更新を開始するように構成されたことを特徴とする請求項１７に記載の通信ネットワーク（４００）。
【請求項２１】
前記第１タイプのネットワーク要素（４０２−４０８）がタイマ（５０８）を含み、前記待機状態になった後で前記タイマ（５０８）を開始し、前記第２タイプのネットワーク要素（４１０）から前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）への通信を検査し、タイマが終了する前にメッセージが受信されなかったときには更新が開始されるよう構成されていることを特徴とする請求項２０に記載の通信ネットワーク（４００）。
【請求項２２】
前記第１タイプのネットワーク要素（４０２−４０８）が無線基地局（４０２−４０８）を含み、前記第２タイプのネットワーク要素が無線ネットワークコントローラ（４１０）を含むことを特徴とする請求項１７乃至２１のいずれか１項に記載の通信ネットワーク（４００）。
【請求項２３】
前記第１タイプのネットワーク要素を制御する前記第２タイプのネットワーク要素のモジュールの更新が検出（１０６）されると、前記第１タイプのネットワーク要素が更新を開始するよう構成されたことを特徴とする請求項１７乃至２２のいずれか１項に記載の通信ネットワーク（４００）。
【請求項１】
第１タイプの複数のネットワーク要素の動作が第２タイプのネットワーク要素の動作に依存する通信ネットワークのネットワーク要素のソフトウエアを更新する方法であって、
第２タイプのネットワーク要素と少なくとも一部の第１タイプのネットワーク要素とにより更新パッケージを受信するステップと（１０２）、
前記少なくとも一部の前記第１タイプのネットワーク要素の前記少なくとも一部が待機状態に入るステップと（１０４）、
前記第２タイプのネットワーク要素の更新が検出されると（１０６）、前記少なくとも一部の前記第１タイプのネットワーク要素の更新を開始するステップと（１１０）、
を含む方法。
【請求項２】
前記待機状態（１０４）において前記少なくとも一部の前記第１タイプのネットワーク要素において前記第２タイプのネットワーク要素からの信号を待ち受けるフラグがセットされることを特徴とする請求項１に記載の方法。
【請求項３】
前記少なくとも一部の第１タイプのネットワーク要素が、前記第２タイプのネットワーク要素から、前記更新を開始（１１０）することを命じるメッセージ（２０６）を受信することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記第１タイプのネットワーク要素は前記第２タイプのネットワーク要素から、前記第２タイプのネットワーク要素が通信処理をすることができないことを知らせるメッセージ（２０６）を受信し、前記少なくとも一部の前記第１タイプのネットワーク要素は前記メッセージを前記更新開始（１１０）のトリガとして使うことを特徴とする請求項１又は２に記載の方法。
【請求項５】
前記第１タイプのネットワーク要素は前記第２タイプのネットワーク要素から前記第１タイプのネットワーク要素の前記少なくとも一部への通信を検査し（３０６）、所定時間内に通信が検出されなかったときに更新を開始（１１０）することを特徴とする請求項１又は２に記載の方法。
【請求項６】
前記待機状態（１０４、２０２）に入った後でタイマを開始（３０２）するステップと、
前記タイマが終了するまで（３０４）第２タイプのネットワーク要素からのメッセージを待ち受けるステップ（２０６）と、
前記タイマが終了する前にメッセージが受信されていないか、前記第２タイプのネットワーク要素から前記少なくとも一部の前記第１タイプのネットワーク要素への通信を検査するステップ（３０６）と、
所定時間の間に通信がないことを検出すると前記更新を開始する（１１０）ことを含むことを特徴とする、
請求項３又は４に記載の方法。
【請求項７】
前記第１タイプのネットワーク要素は無線基地局を含み、前記第２タイプのネットワーク要素は無線ネットワークコントローラを含むことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記第１タイプのネットワーク要素の前記少なくとも一部を制御する前記第２タイプのネットワーク要素の少なくとも一部のモジュールの更新が検出されたとき（１０６）、前記第１タイプのネットワーク要素の前記少なくとも一部が更新を開始（１１０）することを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
通信ネットワーク４００において使用され、更新パッケージを受信した後に待機状態に入り、第２タイプのネットワーク要素（４１０）が更新を開始したことを検出した後で更新を開始するようにされた第１タイプのネットワーク要素であって、前記第１タイプのネットワーク要素（４０２−４０８）の動作が前記第２タイプのネットワーク要素（４１０）の動作に依存することを特徴とする第１タイプのネットワーク要素（４０２−４０８）。
【請求項１０】
前記待機状態を知らせるフラグをセットするように構成された請求項９に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１１】
前記第２タイプのネットワーク要素（４１０）からメッセージを受信し、前記メッセージ中に受信された指示に従って更新を開始することを特徴とする請求項９又は１０に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１２】
前記第２タイプのネットワーク要素（４１０）から、前記第２タイプのネットワーク要素（４１０）が通信処理をすることができないことを知らせるメッセージを受信し、さらに前記更新開始のトリガとして前記メッセージを使うように構成されたことを特徴とする請求項９又は１０に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１３】
前記第２タイプのネットワーク要素（４１０）から通信を受信し所定時間受信機（５０２）で通信が検出できなかったときに更新を開始するよう構成された受信機（５０２）を含むことを特徴とする請求項９に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１４】
前記待機状態に入った後でタイマ（５０８）がスタートされ、前記第２タイプのネットワーク要素（４１０）から受信される通信を検査し、前記タイマが終了する前にメッセージが受信されなかったときに更新を開始するように構成されたタイマ（５０８）を含むことを特徴とする請求項１３に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１５】
無線基地局（４０２−４０８）を含むことを特徴とする請求項８乃至１４のいずれか１項に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１６】
前記第１タイプのネットワーク要素を制御する前記第２タイプのネットワーク要素のモジュールの更新が検出（１０６）されると、前記第１タイプのネットワーク要素の更新が開始されるように構成された請求項９乃至１５のいずれか１項に記載の第１タイプのネットワーク要素（４０２−４０８）。
【請求項１７】
複数の第１タイプのネットワーク要素（４０２−４０８）と少なくとも一つの第２タイプのネットワーク要素（４１０）を含み、
前記第１タイプのネットワーク要素（４０２−４０８）の動作が前記第２タイプのネットワーク要素（４１０）の動作に依存し、両タイプのネットワーク要素は更新パッケージを受信するように構成され、前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）は前記更新パッケージを受信した後に待機状態に入り、前記第２タイプのネットワーク要素（４１０）の更新が検出されると前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）の更新が開始される通信ネットワーク（４００）。
【請求項１８】
前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）が前記第２タイプのネットワーク要素（４１０）から更新を開始するためのメッセージを受信することを特徴とする請求項１７に記載の通信ネットワーク（４００）。
【請求項１９】
前記第１タイプのネットワーク要素（４０２−４０８）が前記第２タイプのネットワーク要素（４１０）から、前記第２タイプのネットワーク要素（４１０）が通信処理をすることができないことを知らせるメッセージを受信し、前記メッセージを前記第１タイプのネットワーク要素の前記更新開始のトリガとして使うよう構成されたことを特徴とする請求項１７に記載の通信ネットワーク（４００）
【請求項２０】
前記第１タイプのネットワーク要素（４０２−４０８）は、前記第２タイプのネットワーク要素（４１０）からの通信を受信する受信機（５０２）を含み、所定時間通信が前記受信機で検出されないときに前記更新を開始するように構成されたことを特徴とする請求項１７に記載の通信ネットワーク（４００）。
【請求項２１】
前記第１タイプのネットワーク要素（４０２−４０８）がタイマ（５０８）を含み、前記待機状態になった後で前記タイマ（５０８）を開始し、前記第２タイプのネットワーク要素（４１０）から前記少なくとも一部の第１タイプのネットワーク要素（４０２−４０８）への通信を検査し、タイマが終了する前にメッセージが受信されなかったときには更新が開始されるよう構成されていることを特徴とする請求項２０に記載の通信ネットワーク（４００）。
【請求項２２】
前記第１タイプのネットワーク要素（４０２−４０８）が無線基地局（４０２−４０８）を含み、前記第２タイプのネットワーク要素が無線ネットワークコントローラ（４１０）を含むことを特徴とする請求項１７乃至２１のいずれか１項に記載の通信ネットワーク（４００）。
【請求項２３】
前記第１タイプのネットワーク要素を制御する前記第２タイプのネットワーク要素のモジュールの更新が検出（１０６）されると、前記第１タイプのネットワーク要素が更新を開始するよう構成されたことを特徴とする請求項１７乃至２２のいずれか１項に記載の通信ネットワーク（４００）。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１２−５１３１３３（Ｐ２０１２−５１３１３３Ａ）
【公表日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【出願番号】特願２０１１−５４１１１４（Ｐ２０１１−５４１１１４）
【出願日】平成２０年１２月２２日（２００８．１２．２２）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０６８１９５
【国際公開番号】ＷＯ２０１０／０７２２５３
【国際公開日】平成２２年７月１日（２０１０．７．１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【出願日】平成２０年１２月２２日（２００８．１２．２２）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０６８１９５
【国際公開番号】ＷＯ２０１０／０７２２５３
【国際公開日】平成２２年７月１日（２０１０．７．１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]