JP5828892B2 - エアインターフェースキーの更新、生成方法及び無線アクセスシステム - Google Patents

エアインターフェースキーの更新、生成方法及び無線アクセスシステム Download PDF

Info

Publication number
JP5828892B2
JP5828892B2 JP2013513529A JP2013513529A JP5828892B2 JP 5828892 B2 JP5828892 B2 JP 5828892B2 JP 2013513529 A JP2013513529 A JP 2013513529A JP 2013513529 A JP2013513529 A JP 2013513529A JP 5828892 B2 JP5828892 B2 JP 5828892B2
Authority
JP
Japan
Prior art keywords
key
rnc
target rnc
extended
transfer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013513529A
Other languages
English (en)
Other versions
JP2013529447A (ja
Inventor
フェン・チェンジァン
ヘ・フェン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of JP2013529447A publication Critical patent/JP2013529447A/ja
Application granted granted Critical
Publication of JP5828892B2 publication Critical patent/JP5828892B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/10—Reselecting an access point controller
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/12—Access point controller devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は通信分野に関し、特にエアインターフェースキーの更新、生成方法及び無線アクセスシステムに関する。
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ，第３世代移動体通信システムの標準化プロジェクト）がＲｅｌｅａｓｅ７では直交周波数分割多重（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅxｉｎｇ、「ＯＦＤＭ」と略称）及び多入力多出力（Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ，「ＭＩＭＯ」と略称）技術を用いてＨＳＤＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ、高速ダウンリンクパケットアクセス）及びＨＳＵＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ、高速アップリンクパケットアクセス）の未来発展道路ＨＳＰＡ＋を完了する。ＨＳＰＡ＋は３ＧＰＰ ＨＳＰＡ（ＨＳＤＰＡとＨＳＵＰＡを含む）の拡張技術であり、ＨＳＰＡ事業者に複雑度の低い、低コストのＨＳＰＡからＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、長期的発展）への円滑な発展の経路を提供する。
図１に示すように、システム枠組では、ＨＳＰＡ、ＨＳＰＡ＋が無線ネットワークコントローラ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ、「ＲＮＣ」と略称）の機能を基地局ノードＢ（Ｎｏｄｅ Ｂ）に移動させ、完全にフラット化の無線アクセスネットワーク枠組を形成する。この時、完全ＲＮＣ機能を統合したＮｏｄｅ ＢをＥｖｏｌｖｅｄ ＨＳＰＡ Ｎｏｄｅ Ｂと称し、又は拡張ノードＢ（Ｎｏｄｅ Ｂ＋）と略称する。ＳＧＳＮ＋はグレードアップされた、ＨＳＰＡ＋機能を支援できるＳＧＳＮ（ＳＥＲＶＩＣＥ ＧＰＲＳ ＳＵＰＰＯＲＴ ＮＯＤＥ、サービスＧＰＲＳ（ＧＰＲＳ：Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｙｓｔｅｍ、汎用パケット無線システム）支援ノード）である。ＭＥ＋はＨＳＰＡ＋機能を支援できるユーザ端末設備である。発展型ＨＳＰＡシステムは３ＧＰＰ Ｒｅｌ−５及びその後のエアインターフェースバージョンが使用でき、エアインターフェースのＨＳＰＡサービスについて如何なる修正も施さない。このようなスキームを用いた後、各Ｎｏｄｅ Ｂ＋はいずれもＲＮＣに相当するノードになり、Ｉｕ−ＰＳインターフェースを有し、ＰＳ ＣＮ（Ｃｏｒｅ Ｎｅｔｗｏｒｋ、コアネットワーク）（図１のＳＧＳＮ＋とＧＧＳＮ＋）と直接に接続でき、Ｉｕ−ＰＳユーザインターフェースがＳＧＳＮで終結し、ここで、ネットワークが直接接続トンネル機能を支援すれば、Ｉｕ−ＰＳユーザインターフェースはＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ、ゲートウェイＧＰＲＳ支援ノード）で終結してもよい。発展型ＨＳＰＡ Ｎｏｄｅ Ｂの間の通信はＩｕｒインターフェースを介して実行される。Ｎｏｄｅ Ｂ＋は独立ネットワーク構築の能力を有し、且つ、システム間とシステム内でのハンドオーバーを含む完全な移動性機能を支援する。
フラット化した後、ユーザインターフェースデータがＲＮＣを通さず、ＧＧＳＮまでそのまま到達でき、つまり、ユーザ平面の暗号化と完全性保護機能がＮｏｄｅ Ｂ＋までに移動しなければならないことをいう。現在定義されているＨＳＰＡ＋の拡張されたセキュリティキー階層の構成が図２に示すとおりである。ここで、Ｋ（Ｋｅｙ，ルートキー）、ＣＫ（Ｃｉｐｈｅｒｉｎｇ Ｋｅｙ、暗号化キー）及びＩＫ（Ｉｎｔｅｇｒｉｔｙ Ｋｅｙ、完全性キー）の定義は伝統的なＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ、汎用移動通信システム）においての定義とは完全に一致している。即ち、ＫはＡｕＣ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｅｎｔｅｒ、認証センター）及びＵＳＩＭ（ＵＮＩＶＥＲＳＡＬ ＳＵＢＳＣＲＩＢＥＲ ＩＤＥＮＴＩＴＹ ＭＯＤＵＬＥ、汎用加入者識別モジュール）に保存されるルートキーであり、本発明では、ＣＫとＩＫを伝統的なキーと称し、伝統的なキーＣＫとＩＫはユーザ設備がＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ、帰属ユーザサーバー）とＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ、認証とキー協定）を行う場合にＫにより算出された暗号化キーと完全性キーである。ＵＭＴＳでは、ＲＮＣは伝統的なエアインターフェースキーＣＫとＩＫを用いてデータに対して暗号化と完全性保護を行う。ＨＳＰＡ＋枠組では、ＲＮＣの全部機能を基地局Ｎｏｄｅ Ｂ＋に移動させるため、暗号化・復号化ともＮｏｄｅ Ｂ＋で行われるが、Ｎｏｄｅ Ｂ＋が安全性の低い環境に位置され、安全性が高くない。この故、ＨＳＰＡ＋がＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ、発展型汎用陸地無線アクセスネットワーク）に類似するキー階層を導入し、即ち、ＵＴＲＡＮキー階層（ＵＴＲＡＮ Ｋｅｙ Ｈｉｅｒａｒｃｈｙ）。ＵＴＲＡＮキー階層構成では、中間キーＫRNC（ＫASMEUとも称する）はＨＳＰＡ＋が新たに導入されたキーであり、ＣＫとＩＫによりＭＥ＋とコアネットワークノード（ＳＧＳＮ＋又はＭＳＣ＋）でそれぞれ推定・生成される。更に、コアネットワークノードがＫRNCをＲＮＣ＋に送信する。ＭＥ＋とＲＮＣ＋がそれぞれ中間キーＫRNCに応じてエアインターフェースキーＣＫUとＩＫUを生成し、拡張キーと称する。ここで、拡張キーＣＫUがユーザインターフェースデータと制御インターフェースシグナルの暗号化に用いられ、拡張キーＩＫUが制御面シグナルに対して完全性保護を行うに用いられる。
現在、また図３に示すような拡張されたセキュリティキー階層構成が見られる。このようなキー枠組では、拡張キーＣＫUとＩＫUが伝統的なキーＣＫ、ＩＫによりＭＥ＋とコアネットワークノード（ＳＧＳＮ＋又はＭＳＣ＋）でそれぞれ直接生成される。コアネットワークノードが拡張キーＣＫUとＩＫUをＲＮＣ＋に送信する。
ＵＭＴＳシステムでは、Ｉｕｒインターフェースの導入のため、ＳＲＮＣ（Ｓｅｒｖｉｎｇ ＲＮＣ、サービスＲＮＣ）／ＤＲＮＣ（Ｄｒｉｆｔ ＲＮＣ、ドリフトＲＮＣ）の概念が生じた。ＳＲＮＣとＤＲＮＣともある具体的なＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ユーザ設備）に対するロジック概念である。簡単に言うと、あるＵＥにとって、それがＣＮ（Ｃｏｒｅ Ｎｅｔｗｏｒｋ、コアネットワーク）に直接接続され、且つ、ＵＥのすべてのリソースに対して制御を行うＲＮＣをＵＥのＳＲＮＣと言い、ＵＥがＣＮに接続されず、ＵＥにリソースを提供するだけのＲＮＣをこのＵＥのＤＲＮＣと言う。接続状態にあるＵＥが１つのみのＳＲＮＣを有さなければならず、ゼロ又は複数のＤＲＮＣを有してもよい。
ＵＭＴＳシステムでは、ＳＲＮＣ移転（ＳＲＮＣ Ｒｅｌｏｃａｔｉｏｎ）とはＵＥのＳＲＮＣが１つのＲＮＣからもう１つのＲＮＣに変わるプロセスである。移転が発生する前後のＵＥの位置する位置が異なるにつれ、静的移転と動的（同伴）移転との２種類の状況に分けられる。
動的移転とはＵＥがＳＲＮＣからターゲットＲＮＣにハードハンドオーバーされ、それとともにＩｕインターフェースが変化するプロセスであり、図４に示すとおりである。移転プロセスではＵＥの参与が必要となるため、ＵＥにかかる（ＵＥ Ｉｎｖｏｌｖｅｄ）移転とも称する。
静的移転を発生する条件はＵＥが１つのＤＲＮＣから、且つ１つのみのＤＲＮＣからアクセスする。移転プロセスではＵＥの参与が必要とならないため、ＵＥにかかわらない（ＵＥ Ｎｏｔ Ｉｎｖｏｌｖｅｄ）移転とも称する。図５に示すように、移転が発生した後、Ｉｕｒインターフェースの接続が解除されるため、Ｉｕインターフェースの移転が発生し、元ＤＲＮＣがＳＲＮＣに変わる。静的移転はソフトハンドオーバーの際に発生するものであり、Ｉｕｒインターフェースのため、すべての無線リンクがＤＲＮＣに接続された後に移転が開始される。
ＳＲＮＣ移転プロセスでは、ソースＲＮＣがＳＲＮＣ移転プロセスをトリガーすることを決定する場合に、ソースＲＮＣがターゲットＲＮＣが拡張されたセキュリティ機能を有するかを確定できない可能性がある。通常、ターゲットＲＮＣがＵＥに送信した第１のダウンリンクメッセージ（ソースＲＮＣを介して移転する可能性がある）では、ＵＥに自己のセキュリティ能力を通知する。ＵＥがターゲットＲＮＣに送信した第１のアップリンクメッセージで、ターゲットＲＮＣに自己のセキュリティ能力を知らせる。ソースＲＮＣが拡張されたセキュリティを支援すれば、ＳＲＮＣ移転準備段階では、ソースＲＮＣがＵＥの支援する拡張されたセキュリティ能力をターゲットＲＮＣに知らせる。これで、ターゲットＲＮＣが早めにＵＥのセキュリティ能力を知るようになり、拡張されたセキュリティメカニズム又は伝統的なセキュリティメカニズムを用いるかを判断することに有利である。
動的移転プロセスでは、ＵＥがＳＲＮＣ移転プロセス全体に参与し、ターゲットＲＮＣセキュリティ能力を持つダウンリンクメッセージがソースＲＮＣを介して移転されてＵＥに送信されるため、このメッセージがソースＲＮＣとＵＥとの間の暗号化キーを用いて保護を行う。ＵＥがこのメッセージを受信した後、どの暗号化キーを用いて解読を行うかを確定できる。しかしながら、静的移転プロセスでは、ターゲットＲＮＣセキュリティ能力を含むダウンリンクメッセージが直接にターゲットＲＮＣを介してＵＥに送信されるため、このメッセージがターゲットＲＮＣとＵＥとの間の暗号化キーを用いて保護を行う。しかしながら、ＵＥがこのメッセージを受信した後、ＵＥがターゲットＲＮＣのセキュリティ能力を知らないため、ＵＥが伝統的な暗号化キーか拡張した暗号化キーかを用いてこのメッセージに対して解読を行うことを確定できない。
従来のスキームでは、静的ＳＲＮＣ移転にとって、ソースＲＮＣがまず一回のＲＮＣ内部（Ｉｎｔｒａ−ＲＮＣ）のＳＲＮＣ移転を行い、即ちこの時ターゲットＲＮＣとソースＲＮＣとは同一のＳＲＮＣである。このプロセスにおいて、ＳＲＮＣが拡張されたキーの更新を行う。ターゲットＲＮＣは、即ちソースＲＮＣであるが、ＵＥがソースＲＮＣのセキュリティ能力を知るため、ＵＥがターゲットＲＮＣ（ここで、即ちソースＲＮＣ）が送信した第１のダウンリンクメッセージを受信した後、伝統的なエアインターフェースキーか拡張されたエアインターフェースキーのいずれかを用いてこのメッセージに対して解読を行うことを明確にする。その後、もう一回のＲＮＣの間（Ｉｎｔｅｒ−ＲＮＣ）の移転を行い、この移転プロセスにおいて、ＵＭＴＳのメカニズムに応じてエアインターフェースキーが更新せず、即ちソースＲＮＣが拡張キーＩＫU、ＣＫUをターゲットＲＮＣに直接送信する。このようにして、ＲＮＣ内部移転プロセスでは、ＩＫU、ＣＫUが既に更新されたため、静的ＳＲＮＣ移転時のエアインターフェースキーに対して更新する目的を達成する。
しかしながら、前記解決スキームでは、この静的移転はセル更新又はＵＲＡ（ＵＭＴＳ Ｒｅｇｉｓｔｒａｔｉｏｎ Ａｒｅａ，ＵＭＴＳ登録エリア）更新プロセスによりトリガーされれば、ＵＥの移動速度が速すぎると、Ｉｎｔｒａ−ＲＮＣ移転がまだ完了されず、ＵＥとソースＲＮＣの接続が既に断ち、これでＳＲＮＣ移転時間の延長となり、ＵＥ切断のリスクを増加した。
本発明の主な目的はエアインターフェースキーの更新、生成方法及び無線アクセスシステムを提供し、前記静的移転がセル更新又はＵＲＡ更新プロセスによりトリガーされる場合に、ＵＥの移動速度が速すぎることによるＳＲＮＣ移転時間の延長、ＵＥの通信中断のリスクが増える問題を解決する。
本発明の一態様によれば、エアインターフェースキーの更新方法を提供し、ソース無線ネットワークコントローラＲＮＣがターゲットＲＮＣへの静的移転を完了するステップと、ターゲットＲＮＣがサービス無線ネットワークコントローラＳＲＮＣ内部移転を行うステップと、ＳＲＮＣ内部移転プロセスでは、ターゲットＲＮＣがソースＲＮＣから又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップとを含み、ソースＲＮＣがターゲットＲＮＣへの静的移転を完了する前に、更に、ソースＲＮＣがターゲットＲＮＣへ静的移転を行うことと、静的移転プロセスでは、ソースＲＮＣが用いている現在キーをターゲットＲＮＣに直接送信し、ターゲットＲＮＣが現在キーを用いてユーザ設備ＵＥと通信することとを含み、ターゲットＲＮＣがＳＲＮＣ内部移転を行うステップは、ターゲットＲＮＣが第２ターゲットＲＮＣへＳＲＮＣ移転を行い、ここで、ターゲットＲＮＣと第２ターゲットＲＮＣが同一のＲＮＣであることを含む。
ターゲットＲＮＣがソースＲＮＣから受信したキーに応じて自身の拡張キーを更新するステップは、ターゲットＲＮＣがソースＲＮＣが送信した変形中間キーを用いて自身の拡張キーを推定更新し、この変形中間キーを、前回ＳＲＮＣ移転が無事に完了された後、コアネットワークノードが保存した伝統的なキーと現在変形中間キーを用いて生成してソースＲＮＣに送信することを含むことが好ましい。
ソースＲＮＣがターゲットＲＮＣへの静的移転を完了する前に、更に、ソースＲＮＣがコアネットワークノードに移転需要メッセージを送信し、この移転需要メッセージがソースＲＮＣの現在拡張キーを含み、現在拡張キーが現在拡張完全性キーＩＫU及び／又は現在拡張暗号化キーＣＫUを含むことと、コアネットワークノードがターゲットＲＮＣに移転要請メッセージを送信し、移転要請メッセージがソースＲＮＣの現在拡張キーを含むことを含むことが好ましい。
ソースＲＮＣがコアネットワークノードに移転需要メッセージを送信するステップは、ソースＲＮＣが現在拡張完全性キーＩＫUを移転需要メッセージのＩＫフィールドに置き、及び／又は現在拡張暗号化キーＣＫUを移転需要メッセージのＣＫフィールドに置き、コアネットワークノードに送信することを含み、コアネットワークノードがターゲットＲＮＣに移転要請メッセージを送信するステップは、コアネットワークノードがソースＲＮＣが送信した現在拡張完全性キーＩＫUを移転要請メッセージのＩＫフィールドに置き、及び／又は現在拡張暗号化キーＣＫUを移転要請メッセージのＣＫフィールドに置き、ターゲットＲＮＣに送信することを含むことが好ましい。
コアネットワークノードがターゲットＲＮＣに移転要請メッセージを送信するステップの後、更に、ターゲットＲＮＣが拡張したセキュリティモードを支援しないと、移転要請メッセージのＩＫフィールドの内容を伝統的な完全性キーＩＫとし、ＣＫフィールドの内容を伝統的な暗号化キーＣＫとして用いることと、ターゲットＲＮＣが拡張したセキュリティモードを支援すると、移転要請メッセージのＩＫフィールドの内容をＩＫUとし、ＣＫフィールドの内容をＣＫUとして用いることとを含むことが好ましい。
ソースＲＮＣがターゲットＲＮＣへの静的移転を完了する前、更に、ソースＲＮＣがターゲットＲＮＣに拡張した移転要請メッセージを送信し、拡張した移転要請メッセージがソースＲＮＣの現在拡張キーを含み、現在拡張キーが現在拡張完全性キーＩＫU及び／又は現在拡張暗号化キーＣＫUを含むことが好ましい。
ソースＲＮＣがターゲットＲＮＣに拡張した移転要請メッセージを送信するステップは、ソースＲＮＣが現在拡張完全性キーＩＫUを拡張した移転要請メッセージのＩＫフィールドに置き、及び／又は現在拡張暗号化キーＣＫUを拡張した移転要請メッセージのＣＫフィールドに置き、ターゲットＲＮＣに送信することを含むことが好ましい。
ソースＲＮＣがターゲットＲＮＣに拡張した移転要請メッセージを送信するステップの後、更に、ターゲットＲＮＣが拡張されたセキュリティモードを支援しないと、拡張された移転要請メッセージのＩＫフィールドの内容を伝統的な完全性キーＩＫとし、ＣＫフィールドの内容を伝統的な暗号化キーＣＫとして用いることと、ターゲットＲＮＣが拡張したセキュリティモードを支援すると、拡張した移転要請メッセージのＩＫフィールドの内容をＩＫUとし、ＣＫフィールドの内容をＣＫUとして用いることとを含むことが好ましい。
コアネットワークノードがターゲットＲＮＣに移転要請メッセージを送信するステップの後、更に、ターゲットＲＮＣがユーザ設備ＵＥに移転確認メッセージを送信し、移転確認メッセージがターゲットＲＮＣのセキュリティ能力指示情報を含むことと、ＵＥがターゲットＲＮＣに確認応答メッセージを送信し、確認応答メッセージがＵＥのセキュリティ能力指示情報を含むことを含むことが好ましい。
エアインターフェースキーの更新方法は更に、ターゲットＲＮＣがＵＥに移転確認メッセージを送信し、移転確認メッセージがコアネットワークノードのネクストホップカウンターネットワークＮＣＣを含むことと、ＵＥがネクストホップカウンター端末ＮＣＣがネットワークＮＣＣに等しいかを判断することと、YESであると、ＵＥが端末ＮＣＣに対応する予め保存された変形中間キーに応じて自身の拡張キーを更新することと、NOであると、ＵＥが変形中間キーを算出し、そして端末ＮＣＣがネットワークＮＣＣに等しくなるまでに、対応する端末ＮＣＣを段階的に増やし、そして変形中間キーに応じて自身の拡張キーを算出して更新することとを含むことが好ましい。
エアインターフェースキーの更新方法は更に、ターゲットＲＮＣがＳＲＮＣ内部移転を完了することと、保存された伝統的なキーと現在変形中間キーに応じて、コアネットワークノードがネクストホップ変形中間キーを算出し、ターゲットＲＮＣにネクストホップ変形中間キーを送信することとを含むことが好ましい。
コアネットワークノードが、保存された伝統的なキーと現在変形中間キーに応じ、ネクストホップ変形中間キーを算出するステップの前又は後、更に、コアネットワークノードがネットワークＮＣＣを段階的に増やすことを含むことが好ましい。
ターゲットＲＮＣがソースＲＮＣから受信したキーに応じて自身の拡張キーを更新するステップは、ターゲットＲＮＣが保存した現在の拡張キーを用いて自身の拡張キーを更新し、この現在の拡張キーがソースＲＮＣの現在の拡張キーであることを含むことが好ましい。
ターゲットＲＮＣが保存した現在の拡張キーを用いて自身の拡張キーを更新するステップは、ターゲットＲＮＣが以下の公式で保存したソースＲＮＣから受信した拡張キーを用いて自身の拡張キーを更新することを含む。ＩＫU＝Ｆ（ＩＫU＿ｏｌｄ、Ｐａｒａｍｅｔｅｒ）；ＣＫU＝Ｆ（ＣＫU＿ｏｌｄ、Ｐａｒａｍｅｔｅｒ）；又は、（ＩＫU、ＣＫU）＝Ｆ（ＩＫU＿ｏｌｄ||ＣＫU＿ｏｌｄ、Ｐａｒａｍｅｔｅｒ）；ここで、Ｆは任意のキー生成関数、Ｐａｒａｍｅｔｅｒはパラメーター、ＩＫU＿ｏｌｄとＣＫU＿ｏｌｄはターゲットＲＮＣ現在の拡張キー、ＩＫUとＣＫUはターゲットＲＮＣ更新後の拡張キー、“||”はカスケードであることが好ましい。
エアインターフェースキーの更新方法は更に、ターゲットＲＮＣがＵＥに移転確認メッセージを送信することと、ＵＥが移転確認メッセージを受信し、以下の公式で保存した現在の拡張キーを用いて自身の拡張キーを更新する。ここで、ＩＫU＝Ｆ（ＩＫU＿ｏｌｄ、Ｐａｒａｍｅｔｅｒ）；ＣＫU＝Ｆ（ＣＫU＿ｏｌｄ、Ｐａｒａｍｅｔｅｒ）；又は、（ＩＫU、ＣＫU）＝Ｆ（ＩＫU＿ｏｌｄ||ＣＫU＿ｏｌｄ、Ｐａｒａｍｅｔｅｒ）；ここで、Ｆは任意のキー生成関数、Ｐａｒａｍｅｔｅｒはパラメーター、ＩＫU＿ｏｌｄとＣＫU＿ｏｌｄはＵＥ現在の拡張キー、ＩＫUとＣＫUはＵＥ更新後の拡張キー、“||”はカスケードであることと、ＵＥがターゲットＲＮＣに確認応答メッセージを送信することとを含むことが好ましい。
ターゲットＲＮＣがソースＲＮＣから受信したキーに応じて自身の拡張キーを更新するステップは、ターゲットＲＮＣがソースＲＮＣが送信した拡張キーを用いて自身の拡張キーを更新し、ソースＲＮＣの拡張キーは、前回ＳＲＮＣ移転が無事に完了された後、コアネットワークノードが保存された伝統的なキーと現在の拡張キーを用いて生成してソースＲＮＣに送信することを含むことが好ましい。
エアインターフェースキーの更新方法は更に、ターゲットＲＮＣがＵＥに移転確認メッセージを送信し、移転確認メッセージがコアネットワークノードのネクストホップカウンターネットワークＮＣＣを含むことと、ＵＥがネクストホップカウンター端末ＮＣＣがネットワークＮＣＣに等しいかを判断することと、YESであると、ＵＥが端末ＮＣＣに対応する予め保存された拡張キーを用いることと、NOであると、ＵＥが拡張キーを算出し、端末ＮＣＣが前記ＮＣＣに等しくなるまでに、対応する端末ＮＣＣを増やすこととを含むことが好ましい。
エアインターフェースキーの更新方法は更に、ターゲットＲＮＣがＳＲＮＣ内部移転を完了するステップと、コアネットワークノードが保存された伝統的なキーと現在の拡張キーに応じて、ネクストホップ拡張キーを算出し、そしてターゲットＲＮＣにネクストホップ拡張キーを送信するステップとを含むことが好ましい。
コアネットワークノードが保存された伝統的なキーと現在の拡張キーに応じて、ネクストホップ拡張キーを算出するステップの前又は後、更に、コアネットワークノードが前記ネットワークＮＣＣを増やすことを含むことが好ましい。
ターゲットＲＮＣがコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップは、コアネットワークノードが自身の保存した伝統的なキーと現在の拡張キーを用いて、ネクストホップ拡張キーを算出してターゲットＲＮＣに送信することと、ターゲットＲＮＣがネクストホップ拡張キーを用いて自身の拡張キーを更新することとを含むことが好ましい。
エアインターフェースキーの更新方法において、ソースＲＮＣが拡張したセキュリティを支援するソースＲＮＣであり、及び／又は、ターゲットＲＮＣが拡張されたセキュリティを支援するターゲットＲＮＣであることが好ましい。
本発明のもう一態様によれば、更に無線アクセスシステムを提供し、ターゲットＲＮＣへ静的移転を行うように設置されるソースＲＮＣと、ここで、静的移転プロセスでは、ソースＲＮＣがその用いる現在キーをターゲットＲＮＣに直接送信し、ターゲットＲＮＣが現在キーを用いてユーザ設備ＵＥと通信し、ソースＲＮＣがターゲットＲＮＣへの静的移転を完了した後、ＳＲＮＣ内部移転を行い、内部移転プロセスでは、ターゲットＲＮＣがソースＲＮＣから又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するように設置されるターゲットＲＮＣとを含み、ターゲットＲＮＣがＳＲＮＣ内部移転を行うことが、ターゲットＲＮＣが第２ターゲットＲＮＣへＳＲＮＣ移転を行い、ここで、ターゲットＲＮＣと第２ターゲットＲＮＣが同一なＲＮＣであることを含む。
無線アクセスシステムは更に、保存された伝統的なキーと現在の変形中間キーを用いてネクストホップ変形中間キーを生成し、そしてターゲットＲＮＣに送信するように設置されるコアネットワークノード、又は、保存された伝統的なキーと現在の拡張キーを用いてネクストホップ拡張キーを生成し、そしてターゲットＲＮＣに送信するように設置されるコアネットワークノードを含むことが好ましい。
コアネットワークノードは更に、ネクストホップ変形中間キー又はネクストホップ拡張キーを生成する回数を数えるように設置されるネクストホップカウンターネットワークＮＣＣを含むことが好ましい。
無線アクセスシステムは更に、ネクストホップカウンター端末ＮＣＣを設置するユーザ設備ＵＥを含み、ＵＥが、ターゲットＲＮＣが送信した移転確認メッセージを受信し、移転確認メッセージがコアネットワークノードのネクストホップカウンターネットワークＮＣＣを含むように設置される受信モジュールと、端末ＮＣＣがネットワークＮＣＣに等しいかを判断するように設置される判断モジュールと、判断モジュールの判断結果がYESであると、端末ＮＣＣに対応する予め保存された変形中間キーに応じて自身の拡張キーを更新し、又は、端末ＮＣＣに対応する予め保存された拡張キーを用いるように設置される確定モジュールと、判断モジュールの判断結果がNOであると、変形中間キーを算出し、端末ＮＣＣがネットワークＮＣＣに等しくなるまでに、対応する端末ＮＣＣを増やし、そして変形中間キーに応じて自身の拡張キーを算出し更新し、又は、拡張キーを算出し、そして端末ＮＣＣがネットワークＮＣＣに等しくなるまでに、対応する端末ＮＣＣを増やすように設置される否定モジュールとを含むことが好ましい。
この無線アクセスシステムにおいて、ソースＲＮＣが拡張されたセキュリティを支援するソースＲＮＣであり、及び／又は、ターゲットＲＮＣが拡張されたセキュリティを支援するターゲットＲＮＣであることが好ましい。
本発明はまずソースＲＮＣからターゲットＲＮＣまでの移転を行い、そしてターゲットＲＮＣ内部移転を行い、ターゲットＲＮＣ内部移転のプロセスで、拡張されたエアインターフェースキーを更新する方法を用い、ＵＥの移動が速すぎることによって、セル更新又はＵＲＡ更新プロセスによりトリガーされる静的移転の場合にＳＲＮＣ移転時間が長く、ＵＥの通信中断のリスクが大きい問題を効果的に回避できる。この発明がＳＲＮＣ静的移転の場合に拡張されたエアインターフェースキーを更新する上、ＳＲＮＣ移転プロセスの遅延を増やさず、システムセキュリティ性と効率を向上させた。
それとともに、この発明は幅広く様々なＳＲＮＣ静的移転の場合に適用し、静的移転がセル更新又はＵＲＡ更新プロセスによりトリガーされる場合に、ＵＥの移動が速すぎることによるＳＲＮＣ移転時間の延長、ＵＥの通信中断のリスクが増える問題を解決できる上、その他の任意のＳＲＮＣ静的移転の場合にも適用し、ＳＲＮＣ静的移転の場合に拡張したエアインターフェースキーを更新するとともに、システムセキュリティ性と効率を向上させる。
ここで説明する図面は本発明を理解するためのもので、本発明の一部を構成し、本発明における模式的な実施例とその説明と共に本発明を解釈し、本発明を不当に限定するものではない。図面において、
関連技術によるＨＳＰＡ＋技術を用いる無線アクセスネットワークの構成の模式図である。 関連技術によるＨＳＰＡ＋セキュリティキーの階層構成の模式図である。 関連技術によるもう１種のＨＳＰＡ＋セキュリティキーの階層構成の模式図である。 関連技術によるＳＲＮＣ静的移転の模式図である。 関連技術によるＳＲＮＣ動的移転の模式図である。 本発明の実施例１によるエアインターフェースキーの更新方法のステップフローチャートである。 本発明の実施例２による無線通信システムにおけるエアインターフェースキーの更新のフローチャートである。 本発明の実施例３による無線通信システムにおけるエアインターフェースキーの更新のフローチャートである。 本発明の実施例４による無線通信システムにおけるエアインターフェースキーの更新のフローチャートである。 本発明の実施例５による無線通信システムにおけるエアインターフェースキーの更新のフローチャートである。 本発明の実施例６による無線通信システムにおけるエアインターフェースキーの更新のフローチャートである。 本発明の実施例７による無線通信システムにおけるエアインターフェースキーの更新のフローチャートである。 本発明の実施例８による無線通信システムにおけるエアインターフェースキーの更新のフローチャートである。 本発明の実施例９による無線アクセスシステムの構成のブロック図である。
以下、図面と実施例を参照しながら、本発明を詳しく説明する。また、矛盾しない場合には、本案における実施例及び実施例における特徴を相互に組み合せてもよい。
図６を参照し、本発明の実施例によるエアインターフェースキーの更新方法のステップのフローチャートを示し、以下のステップを含む。
ステップＳ６０２において、ソースＲＮＣがターゲットＲＮＣへの静的移転を完了する。
ここで、本実施例のソースＲＮＣとターゲットＲＮＣが拡張ＲＮＣ（ＲＮＣ＋）でよく、即ち、ソースＲＮＣがソースＲＮＣ＋、ターゲットＲＮＣがターゲットＲＮＣ＋である。
本ステップでは、ソースＲＮＣ（ソースＲＮＣ＋）がターゲットＲＮＣ（ターゲットＲＮＣ＋）への静的移転が伝統的なＵＭＴＳメカニズムに従い、このため、ソースＲＮＣ（ソースＲＮＣ＋）がＵＭＴＳに同一のＳＲＮＣ移転フローを実行し、即ちソースＲＮＣ（ソースＲＮＣ＋）が拡張されたエアインターフェースキーをターゲットＲＮＣ（ターゲットＲＮＣ＋）に直接送信する。このプロセスでは、拡張キーの更新をしない。
本ステップでは、ターゲットＲＮＣが拡張されたセキュリティを支援すると、ターゲットＲＮＣ（ターゲットＲＮＣ＋）がソースＲＮＣ（ソースＲＮＣ＋）から又はコアネットワークノードから受信したキーを拡張キーＩＫU及び／又はＣＫUとし、そして以下のステップを実行し続ける。ターゲットＲＮＣが拡張されたセキュリティを支援しないと、ターゲットＲＮＣがソースＲＮＣ（ソースＲＮＣ＋）から又はコアネットワークノードから受信したキーを伝統的なキーＩＫ及び／又はＣＫとし、そして伝統的なＵＭＴＳが定義した操作で実行する。異なるセキュリティモードを支援するターゲットＲＮＣに対して伝統的なキーと拡張キーと区分し、これで異なる移転需要に応える。
ステップＳ６０４において、ターゲットＲＮＣがＳＲＮＣ内部移転を行う。
ソースＲＮＣ（ソースＲＮＣ＋）からターゲットＲＮＣ（ターゲットＲＮＣ＋）までに移転した後、ターゲットＲＮＣ（ターゲットＲＮＣ＋）が内部移転を行い、即ちこの時ソースＲＮＣとターゲットＲＮＣが同一のＲＮＣである。
ステップＳ６０６において、ＳＲＮＣ内部移転のプロセスでは、ターゲットＲＮＣ（ターゲットＲＮＣ＋）がソースＲＮＣ（ソースＲＮＣ＋）から又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新する。
関連技術では、静的移転がセル更新又はＵＲＡ更新プロセスによりトリガーされる場合、ＵＥの移動速度が速すぎると、ＲＮＣ内部移転がまだ完了せず、ＵＥとソースＲＮＣの接続が既に断ち、これでＳＲＮＣ移転時間が長くなり、ＵＥの通信中断のリスクが増える。本実施例によれば、まずソースＲＮＣからターゲットＲＮＣまでの移転を行い、そしてターゲットＲＮＣ内部移転を行い、ターゲットＲＮＣ内部移転のプロセスで拡張キーを更新する方法によって、ＵＥ移動が速すぎることによって、セル更新又はＵＲＡ更新プロセスによりトリガーされて静的移転を行う場合のＳＲＮＣ移転時間が長く、ＵＥの通信中断のリスクが大きい問題を避け、ＳＲＮＣ静的移転の場合に拡張されたエアインターフェースキーに対して更新を行う上、ＳＲＮＣ移転プロセスの遅延を増加せず、システムセキュリティ性と効率を向上させた。
図７を参照し、本発明の実施例による無線通信システムにおいてエアインターフェースキーの更新のフローチャートを示す。本実施例が図２に示す拡張されたキーの構成に基づき、毎回完了されたＳＲＮＣ移転プロセスの後、コアネットワークノードが自己の保存した伝統的なキーＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に応じて、ネクストホップの変形中間キーＫRNC*を推定し、そしてネクストホップ変形中間キーＫRNC*をターゲットＲＮＣに送信して保存し、次回ＳＲＮＣ移転時の使用に用意しておく。次回ＳＲＮＣ移転の際、ソースＲＮＣ（即ち、前回ＳＲＮＣ移転プロセスにおけるターゲットＲＮＣ）が保存した変形中間キーＫRNC*をターゲットＲＮＣに送信し、ターゲットＲＮＣが受信した変形中間キーＫRNC*、及び／又は他のパラメーター（例えば、アルゴリズム識別子）に基づき、更新された拡張キーＩＫU／ＣＫUを推定する。
本実施例は、以下のステップを含む。
ステップＳ７０２において、ユーザ設備ＵＥがＵＴＲＡＮにＵＲＡ更新メッセージ、又はセル更新メッセージ、又は測定報告メッセージを送信する。
ステップＳ７０４において、ターゲットＲＮＣがこのＵＥのＵＲＡ更新メッセージ、又はセル更新メッセージ、又は測定報告メッセージを受信することによって、該ＵＥのソースＲＮＣにアップリンクシグナル伝送指示メッセージを送信する。
ステップＳ７０６において、ソースＲＮＣがＳＲＮＣ移転プロセスを開始すると決定する。
ステップＳ７０８において、ソースＲＮＣがトリガーしたのは静的ＳＲＮＣ移転であることを確定し、ソースＲＮＣが伝統的なＵＭＴＳと同一のＳＲＮＣ移転フローを実行する。即ち、ソースＲＮＣがコアネットワークノード（ＳＧＳＮ＋又はＭＳＣ＋）に移転需要メッセージを送信し、前記移転需要メッセージが拡張キーＩＫUとＣＫUというパラメーターを含む。
ステップＳ７１０において、コアネットワークノードがターゲットＲＮＣに移転要請メッセージを送信し、この移転要請メッセージが拡張キーＩＫU及び／又はＣＫUというパラメーターを含む。
ステップＳ７０８−Ｓ７１０では、ソースＲＮＣが拡張されたセキュリティを支援しないと、ソースＲＮＣがターゲットＲＮＣに送信したキーは、伝統的なエアインターフェースキーＩＫ及び／又はＣＫである。
ソースＲＮＣが拡張されたセキュリティを支援すると、ソースＲＮＣが拡張されたエアインターフェースキーＩＫU及び／又はＣＫUをターゲットＲＮＣに直接送信する。また、ソースＲＮＣが拡張されたエアインターフェースキーＩＫU及び／又はＣＫUをソースからターゲットまでの透明容器におけるＩＫ及び／又はＣＫフィールドの位置に置いて送信してもよい。
前記移転需要メッセージと移転要請メッセージは、ソースＲＮＣがターゲットＲＮＣを指示して伝統的なＵＭＴＳが定義したセキュリティ操作を行うようにさせる指示を持ち、ターゲットＲＮＣが拡張キーの更新を行わないように指示される。例えば、この実施例では、前記移転需要メッセージと移転要請メッセージにおいてＮＣＣフィールドがアイドル（idle）又はある特殊値でよい。
ソースＲＮＣとターゲットＲＮＣは異なるコアネットワークノード下に位置すると、前記移転需要メッセージと移転要請メッセージが複数のコアネットワークノードを介して移転される必要がある。
移転需要メッセージと移転要請メッセージによれば、需要キー及びその他のパラメーターを移転する有効な伝送を実現できた。
ステップＳ７１２において、ターゲットＲＮＣがソースＲＮＣが送信したキーを保存する。
ターゲットＲＮＣが受信したキーはコアネットワークノードが送信した移転要請メッセージのＩＫ及び／又はＣＫフィールドに位置すると、ターゲットＲＮＣがそれを拡張キーＩＫU及び／又はＣＫU（ターゲットＲＮＣが拡張されたセキュリティモードを支援する）と見なし、又は伝統的なキーＩＫ及び／又はＣＫ（ターゲットＲＮＣが拡張されたセキュリティモードを支援しない）と見なす。
ステップＳ７１４において、ターゲットＲＮＣがコアネットワークノードに移転要請確認メッセージを送信する。
ソースＲＮＣとターゲットＲＮＣが異なるコアネットワークノード下に位置すると、このメッセージが複数のコアネットワークノードを介しての移転が必要となる。
ステップＳ７１６において、コアネットワークノードがソースＲＮＣに移転コマンドメッセージを送信する。
ステップＳ７１８において、ソースＲＮＣがターゲットＲＮＣに移転提出メッセージを送信する。
ステップＳ７２０において、ターゲットＲＮＣがコアネットワークノードに移転検出のメッセージを送信する。
ステップＳ７２２において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。このメッセージがターゲットＲＮＣのセキュリティ能力の指示情報を含む。
ステップＳ７２４において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。このメッセージがＵＥセキュリティ能力の指示情報を含む。
ステップＳ７２２−Ｓ７２４によれば、ターゲットＲＮＣとＵＥがそれぞれ相手のセキュリティ能力を知る。
ステップＳ７２６において、ターゲットＲＮＣがコアネットワーク接点に移転完了メッセージを送信する。
ステップＳ７２８において、ソースＲＮＣがコアネットワークノードとの間のＩｕｒインターフェースを解除する。
このステップとステップＳ７３０は時間前後順を問わない。
ターゲットＲＮＣ及び／又はＵＥが拡張されたセキュリティを支援しないと、フローがここで終わる。ターゲットＲＮＣとＵＥとも拡張されたセキュリティを支援するが、ソースＲＮＣが拡張されたセキュリティを支援しないと、コアネットワークノードがＡＫＡとセキュリティモード構築プロセス、又はセキュリティモード構築プロセスのみを開始すると決定し、これで拡張したキーを設ける。ターゲットＲＮＣとＵＥとも拡張されたセキュリティを支援し、且つソースＲＮＣも拡張されたセキュリティを支援すると、ステップＳ７３０を続ける。
ステップＳ７３０において、コアネットワークノードがＳＲＮＣ移転が無事に完了したことを知った後、保存した伝統的なキーＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に基づいてネクストホップ変形中間キーＫRNC*を算出する。
好適なスキームとして、本実施例においてコアネットワークノードが１つのネクストホップカウンターネットワークＮＣＣを維持し、これで変形中間キーＫRNC*の算出回数を数える。コアネットワークノードがＳＲＮＣ移転を無事に完了したと知った後、ネットワークＮＣＣを段階的に増やし、そして増やした後のネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*を算出し、又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に基づいてネクストホップ変形中間キーＫRNC*を算出し、そしてネットワークＮＣＣを段階的に増やす。
ステップＳ７３２において、コアネットワークノードがターゲットＲＮＣに移転完了の応答メッセージを送信し、このメッセージには、ネットワークＮＣＣ、及びこのネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*のパラメーターを含む。
ステップＳ７３４において、ターゲットＲＮＣが受信したネットワークＮＣＣとネクストホップ変形中間キーＫRNC*を保存する。
ステップＳ７３６において、ターゲットＲＮＣがＲＮＣ内部移転を開始すると決定する。
ステップＳ７３８において、ターゲットＲＮＣがコアネットワークノードに移転需要メッセージを送信し、このメッセージには、変形中間キーＫRNC*、ネットワークＮＣＣのパラメーターを含む。
ステップＳ７４０において、コアネットワークノードがターゲットＲＮＣに移転要請メッセージを送信し、このメッセージには、変形中間キーＫRNC*、ネットワークＮＣＣのパラメーターを含む。
ステップＳ７４２において、ターゲットＲＮＣが変形中間キーＫRNC*に基づいて拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUを推定して算出する。
ターゲットＲＮＣが中間キーＫRNCを変形中間キーＫRNC*に等しくさせ、中間キーＫRNCに基づいて更新されたＩＫU及び／又はＣＫUを算出してもよい。
ステップＳ７４４において、ターゲットＲＮＣがコアネットワークノードに移転要請の確認メッセージを送信する。
ステップＳ７４６において、コアネットワークノードがターゲットＲＮＣに移転コマンドメッセージを送信する。
ステップＳ７４８において、ターゲットＲＮＣがコアネットワーク接点に移転検出のメッセージを送信する。
本実施例では、ステップＳ７３８−Ｓ７４８が選択可能なステップである。
ステップＳ７５０において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信し、メッセージにネットワークＮＣＣのパラメーターを含む。
ステップＳ７５２において、ＵＥが変形中間キーＫRNC*に基づいて完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。
ＵＥが中間キーＫRNCを変形中間キーＫRNC*に等しくさせ、更新されたＩＫU及び／又はＣＫUを中間キーＫRNCに基づいて算出してもよい。
本ステップでは、ＵＥが１つのネクストホップカウンター端末ＮＣＣを維持し、ネットワークＮＣＣを受信した場合に、ＵＥが現在のアクティブにした拡張キーに対応する端末ＮＣＣがネットワークＮＣＣに等しいかを判断し、端末ＮＣＣがネットワークＮＣＣに等しい場合、ＵＥが端末ＮＣＣに対応する自身の保存した変形中間キーＫRNC*に基づいて拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUを更新する。端末ＮＣＣがネットワークＮＣＣに等しくない場合、ＵＥが変形中間キーＫRNC*を算出し、端末ＮＣＣがネットワークＮＣＣに等しくなるまで、対応する端末ＮＣＣを段階的に増やし、変形中間キーＫRNC*に基づいて拡張した完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。ＵＥがネットワークＮＣＣと端末ＮＣＣを介して、ターゲットＲＮＣとキーの一致を保持する。
ステップＳ７５４において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報の確認メッセージ、又はＲＡＮ移動性情報の確認メッセージを送信する。
ステップＳ７５６において、ターゲットＲＮＣがコアネットワーク接点に移転完了メッセージを送信する。
ステップＳ７５８において、コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やす。コアネットワークノードがＩＫ、ＣＫ及び現在変形中間キーＫRNC*に基づいて段階的に増やした後のネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*を算出する。
ステップＳ７６０において、コアネットワークノードがターゲットＲＮＣに移転完了の応答メッセージを送信し、このメッセージには、ネットワークＮＣＣ、及びこのネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*のを含む。
ステップＳ７６２において、ターゲットＲＮＣが受信したＮＣＣ及びネクストホップ変形中間キーＫRNC*を保存する。
ここで、ステップＳ７５６−Ｓ７６２が選択可能なものである。
図８を参照し、本発明の実施例による無線通信システムにおけるエアインターフェースキーの更新のフローチャートを示す。本実施例が図２に示す拡張したキーの構成に基づいて、毎回成功したＳＲＮＣ移転プロセスの後、コアネットワークノードが自ら保存した伝統的なキーＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に応じ、ネクストホップの変形中間キーＫRNC*を推定し、そしてネクストホップ変形中間キーＫRNC*をターゲットＲＮＣに送信して保存し、次回のＳＲＮＣ移転の際のために用意しておく。次回ＳＲＮＣ移転の際、ソースＲＮＣ（即ち、前回ＳＲＮＣ移転プロセスにおけるターゲットＲＮＣ＋）が保存された変形中間キーＫRNC*をターゲットＲＮＣに送信し、ターゲットＲＮＣが受信した変形中間キーＫRNC*、及び／又はその他のパラメーター（例えば、アルゴリズム識別子）に基づき、更新の拡張キーＩＫU／ＣＫUを推定する。
本実施例は、以下のステップを含む。
ステップＳ８０２において、ユーザ設備ＵＥがＵＴＲＡＮにＵＲＡ更新メッセージ、又はセル更新メッセージ、又は測定報告メッセージを送信する。
ステップＳ８０４において、ターゲットＲＮＣがこのＵＥのＵＲＡ更新メッセージ、又はセル更新メッセージ、又は測定報告メッセージを受信することによって、このＵＥのソースＲＮＣにアップリンクシグナル伝送指示メッセージを送信する。
ステップＳ８０６において、ソースＲＮＣがＳＲＮＣ移転プロセスを開始すると決定する。
ステップＳ８０８において、ソースＲＮＣがトリガーしたのは静的ＳＲＮＣ移転であることを確定し、ソースＲＮＣが伝統的なＵＭＴＳと同一のＳＲＮＣ移転フローを実行する。即ち、ソースＲＮＣがターゲットＲＮＣに拡張した移転要請メッセージを送信し、このメッセージが拡張キーＩＫUとＣＫUを含む。
このステップでは、ソースＲＮＣが拡張したセキュリティを支援しない場合、ソースＲＮＣがターゲットＲＮＣに送信したキーは、伝統的なエアインターフェースキーＩＫ及び／又はＣＫである。
ソースＲＮＣが拡張したセキュリティを支援すると、ソースＲＮＣが拡張したエアインターフェースキーＩＫU及び／又はＣＫUをターゲットＲＮＣに直接送信する。ソースＲＮＣが拡張したエアインターフェースキーＩＫU及び／又はＣＫUをソースＲＮＣからターゲットＲＮＣまでの透明容器におけるＩＫ及び／又はＣＫフィールドの位置に置いて送信してもよい。
前記拡張した移転要請メッセージは、ソースＲＮＣがターゲットＲＮＣを指示して伝統的なＵＭＴＳが定義したセキュリティ操作を行うようにさせる指示を含み、ターゲットＲＮＣが拡張キーの更新を行わないように指示する。例えば、この実施例では、前記移転需要メッセージと移転要請メッセージにおいてＮＣＣフィールドがアイドル又はある特定値でもよい。
ステップＳ８１０において、ターゲットＲＮＣがソースＲＮＣの送信したキーを保存する。
ターゲットＲＮＣが受信したキーはコアネットワークノードが送信した移転要請メッセージのＩＫ及び／又はＣＫフィールドに位置すると、ターゲットＲＮＣがそれを拡張キーＩＫU及び／又はＣＫU（ターゲットＲＮＣが拡張したセキュリティモードを支援する）と見なし、又は伝統的なキーＩＫ及び／又はＣＫ（ターゲットＲＮＣが拡張したセキュリティモードを支援しない）と見なす。
ステップＳ８１２において、ターゲットＲＮＣがソースＲＮＣに拡張した移転応答メッセージを送信する。
ステップＳ８１４において、ソースＲＮＣがターゲットＲＮＣに移転提出メッセージを送信する。
ステップＳ８１６において、ターゲットＲＮＣがコアネットワークノードに移転検出メッセージを送信する。
ステップＳ８１８において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。このメッセージがターゲットＲＮＣのセキュリティ能力の指示情報を含む。
ステップＳ８２０において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。このメッセージがＵＥセキュリティ能力の指示情報を含む。
ステップＳ８１８とＳ８２０によれば、ターゲットＲＮＣとＵＥがそれぞれ相手のセキュリティ能力を知る。
ステップＳ８２２において、ターゲットＲＮＣがコアネットワークノードに拡張した移転完了要請メッセージを送信する。
ステップＳ８２４において、コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、保存した伝統的なキーＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に基づいてネクストホップ変形中間キーＫRNC*を算出する。
好適なスキームとして、本実施例においてコアネットワークノードが１つのネクストホップカウンターネットワークＮＣＣを維持し、これで変形中間キーＫRNC*の算出回数を数える。コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やし、そして増やした後のネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*を算出し、又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に基づいてネクストホップ変形中間キーＫRNC*を算出し、そしてネットワークＮＣＣを段階的に増やす。
ステップＳ８２６において、コアネットワークノードがターゲットＲＮＣに移転完了の応答メッセージを送信し、該メッセージには、ネットワークＮＣＣ、及び該ネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*を含む。
ステップＳ８２８において、ターゲットＲＮＣが受信したネットワークＮＣＣとネクストホップ変形中間キーＫRNC*を保存する。
ステップＳ８３０において、ソースＲＮＣがコアネットワークノードとの間のＩｕｒインターフェースを解除する。
該ステップとステップＳ８２８は時間の前後順を問わない。
ターゲットＲＮＣ及び／又はＵＥが拡張したセキュリティを支援しない場合、ステップＳ８２４とステップＳ８２８を行う必要がなく、フローはステップＳ８３０で終わる。ターゲットＲＮＣとＵＥとがいずれも拡張したセキュリティを支援するが、ソースＲＮＣが拡張したセキュリティを支援しない場合、コアネットワークノードがＡＫＡとセキュリティモード構築プロセス、又はセキュリティモード構築プロセスのみを開始すると決定し、これで拡張したキーを設立する。ターゲットＲＮＣとＵＥとがいずれも拡張したセキュリティを支援し、且つソースＲＮＣも拡張したセキュリティを支援すると、ステップＳ８３２を続ける。
ステップＳ８３２において、ターゲットＲＮＣがＲＮＣ内部の移転を開始すると決定する。
ステップＳ８３４において、ターゲットＲＮＣが変形中間キーＫRNC*に基づき、拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUを導き出して算出する。
ターゲットＲＮＣが中間キーＫRNCを変形中間キーＫRNC*に等しくし、中間キーＫRNCに基づいて更新されたＩＫU及び／又はＣＫUを算出してもよい。
ステップＳ８３６において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はネットワークＮＣＣを含むＲＡＮ移動性情報メッセージを送信する。
ステップＳ８３８において、ＵＥが変形中間キーＫRNC*に基づいて完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。
ＵＥが中間キーＫRNCを変形中間キーＫRNC*に等しくし、中間キーＫRNCに基づいて更新されたＩＫU及び／又はＣＫUを算出する。
本ステップでは、ＵＥが１つのネクストホップカウンター端末ＮＣＣを維持し、ネットワークＮＣＣを受信した場合に、ＵＥが現在アクティブにした拡張キーに対応する端末ＮＣＣがネットワークＮＣＣに等しいかを判断し、端末ＮＣＣがネットワークＮＣＣに等しい場合、ＵＥが端末ＮＣＣに対応する自身の保存した変形中間キーＫRNC*に基づいて拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUを更新する。端末ＮＣＣがネットワークＮＣＣに等しくない場合、ＵＥが変形中間キーＫRNC*を算出し、端末ＮＣＣがネットワークＮＣＣに等しくなるまでに、対応する端末ＮＣＣを段階的に増やし、変形中間キーＫRNC*に基づいて拡張した完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。ＵＥがネットワークＮＣＣと端末ＮＣＣを介して、ターゲットＲＮＣとキーの一致することを保持する。
ステップＳ８４０において、ＵＥがターゲットＲＮＣ＋にＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。
ステップＳ８４２において、ターゲットＲＮＣがコアネットワークノードに拡張された移転完了要請メッセージを送信する。
ステップＳ８４４において、コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やす。コアネットワークノードがＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に基づいて段階的に増やした後のネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*を算出する。
ステップＳ８４６において、コアネットワークノードがターゲットＲＮＣに、ネットワークＮＣＣ、及びこのネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*を含む移転完了応答メッセージを送信する。
ステップＳ８４８において、ターゲットＲＮＣが受信したＮＣＣ及びネクストホップ変形中間キーＫRNC*を保存する。
ここで、ステップＳ８４２−Ｓ８４８は選択可能なものである。
図９を参照し、本発明の実施例によるもう１種の無線通信システムにおいてエアインターフェースキーの更新のフロー図を示す。本実施例と図７に示す実施例との区別は、本実施例が図３に示す拡張キーの枠組に基づき、且つキー更新の方法が異なっている。本実施例では、ソースＲＮＣがエアインターフェースキーＩＫU及び／又はＣＫUを更新した後、ターゲットＲＮＣに送信し、ターゲットＲＮＣが受信した後、該更新されたキーを直接使用する。
本実施例は以下のステップを含む。
ステップＳ９０２−ステップＳ９２８は、図７に示す実施例におけるステップＳ７０２−ステップＳ７２８に対応する。
ターゲットＲＮＣ及び／又はＵＥが拡張したセキュリティを支援しないと、フローがここで終わる。ターゲットＲＮＣとＵＥとも拡張したセキュリティを支援するが、ソースＲＮＣが拡張したセキュリティを支援しないと、コアネットワークノードがＡＫＡとセキュリティモード構築プロセス、又はセキュリティモード構築プロセスのみを開始決定し、これで拡張したキーを設立する。ターゲットＲＮＣとＵＥとも拡張したセキュリティを支援し、且つソースＲＮＣも拡張したセキュリティを支援すると、ステップＳ８３０を続ける。
ステップＳ９３０において、ＵＥとターゲットＲＮＣとも拡張したセキュリティを支援する場合、ターゲットＲＮＣがＲＮＣ内部移転を開始すると決定する。
ステップＳ９３２において、ターゲットＲＮＣが拡張されたエアインターフェースキーＩＫU／ＣＫUを更新する。
ターゲットＲＮＣが自ら保存したＩＫU／ＣＫU、及び／又は他のパラメーターに基づき、ＩＫU／ＣＫUを更新する。
ここで、ＩＫU／ＣＫUの推定式が以下に示すとおりである。
ＩＫU＝Ｆ（ＩＫU＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）、ＣＫU＝Ｆ（ＣＫU＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
又は（ＩＫU、ＣＫU）＝Ｆ（ＩＫU||ＣＫU，Ｐａｒａｍｅｔｅｒ）。
ここで、Ｆは任意のキー生成関数であり、例えば、３ＧＰＰにおいて定義したＫＤＦ関数でもよい。Ｐａｒａｍｅｔｅｒは１つ又は複数のパラメーターであり、例えば、ＳＲＮＣが生成したＦＲＥＳＨパラメーター、及び／又はターゲットＲＮＣ識別子でもよい。ＩＫU＿ｏｌｄとＣＫU＿ｏｌｄはＳＲＮＣの現在の拡張キーである。ＳＲＮＣがＩＫU＿ｏｌｄとＣＫU＿ｏｌｄに基づき、ターゲットＲＮＣが用いた更新されたＩＫU和ＣＫUを算出する。符号“||”はカスケードである。
ここで、前記無作為数ＦＲＥＳＨはＵＭＴＳにおいて既に定義した１つのパラメーターである。この無作為数長さが３２ビットである。接続を立ち上げる場合に、ＲＮＣが各ユーザに１つの無作為数ＦＲＥＳＨを生成し、そしてセキュリティモードコマンドメッセージを介してユーザに送信する。全体の接続の持続時間において、ネットワークとユーザがこの無作為数を用いてメッセージ識別コード（ＭＡＣ−Ｉ）を算出し、ネットワークがユーザシグナルメッセージのリプレーアタックを受けないように保護される。
ターゲットＲＮＣが前回ＳＲＮＣ移転プロセスで受信したＩＫをＩＫU＿ｏｌｄとし、受信したＣＫをＣＫU＿ｏｌｄとしてもよい。
ステップＳ９３４において、ターゲットＲＮＣがコアネットワークノードに、更新後の拡張したエアインターフェースキーＩＫU、ＣＫUを含む移転需要メッセージを送信する。
ステップＳ９３６において、コアネットワークノードがターゲットＲＮＣに、更新後の拡張したエアインターフェースキーＩＫU、ＣＫUを含む移転要請メッセージを送信する。
ターゲットＲＮＣが更新後の拡張したエアインターフェースキーＩＫU／ＣＫUをソースからターゲットまでの透明容器におけるＩＫ／ＣＫフィールドに置いてもよい。
ステップＳ９３８において、ターゲットＲＮＣがコアネットワークノードに移転要請確認メッセージを送信する。
ステップＳ９４０において、コアネットワークノードがターゲットＲＮＣに移転コマンドメッセージを送信する。
ステップＳ９４２において、ターゲットＲＮＣがコアネットワークアクセスポイントに移転検出メッセージを送信する。
ここで、ステップＳ９３４−Ｓ９４２が選択可能なものである。
ステップＳ９４４において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。
ステップＳ９４６において、ＵＥがＳＲＮＣと同様なアルゴリズムによって、完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。
ＵＥが前回ＳＲＮＣ移転プロセスに用いたＩＫをＩＫU＿ｏｌｄとし、受信したＣＫをＣＫU＿ｏｌｄとする。
ステップＳ９４８において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。
ステップＳ９５０において、ターゲットＲＮＣがコアネットワーク接点に移転完了メッセージを送信する。
再度図９を参照すると、本発明の実施例によるもう１種の無線通信システムにおいてエアインターフェースキー更新のフローチャートを示す。本実施例と図７に示す実施例との区別は、本実施例が図３に示す拡張キーの枠組に基づき、且つキー更新の方法が異なっている。本実施例では、ソースＲＮＣがエアインターフェースキーＩＫU及び／又はＣＫUを更新した後、ターゲットＲＮＣに送信し、ターゲットＲＮＣが受信した後、該更新されたキーをそのまま使用する。また、本実施例が汎用ＳＲＮＳ移転フローを用い、即ち移転準備段階で、ソースＲＮＣとターゲットＲＮＣとの間のメッセージがコアネットワークノードの移転が必要となる。
本実施例は以下のステップを含む。
ステップＳ１００２〜ステップＳ１００６は、図７に示す実施例におけるステップＳ７０２〜ステップＳ７０６に対応する。
ステップＳ１００８において、ソースＲＮＣがトリガーしたのは静的ＳＲＮＣ移転であることを確定し、ソースＲＮＣが伝統的なＵＭＴＳに同一なＳＲＮＣ移転フローを実行する。即ち、ソースＲＮＣがコアネットワークノード（ＳＧＳＮ＋又はＭＳＣ＋）に拡張キーＩＫUとＣＫUを含む移転需要メッセージを送信前記する。
ステップＳ１０１０において、コアネットワークノードがターゲットＲＮＣに、拡張キーＩＫU及び／又はＣＫUを含む移転要請メッセージを送信する。
ステップＳ１００８−Ｓ１０１０では、ソースＲＮＣが拡張したセキュリティを支援しない場合、ソースＲＮＣがターゲットＲＮＣに送信したキーは、伝統的なエアインターフェースキーＩＫ及び／又はＣＫである。
ソースＲＮＣが拡張したセキュリティを支援すると、ソースＲＮＣが拡張したエアインターフェースキーＩＫU及び／又はＣＫUをそのままターゲットＲＮＣに送信する。ソースＲＮＣが拡張したエアインターフェースキーＩＫU及び／又はＣＫUをソースＲＮＣからターゲットＲＮＣまでの透明容器におけるＩＫ及び／又はＣＫフィールドの位置に置いて送信する。
前記移転需要メッセージと移転要請メッセージは、ソースＲＮＣがターゲットＲＮＣを指示して伝統的なＵＭＴＳが定義したセキュリティ操作を行うようにさせる指示を含み、ターゲットＲＮＣが拡張キーの更新を行わないように指示することが好ましい。例えば、この実施例では、前記移転需要メッセージと移転要請メッセージにおいてＮＣＣフィールドがアイドル（edle）又はある特定値でもよい。
ソースＲＮＣとターゲットＲＮＣが異なるコアネットワークノードの下に位置すると、前記移転需要メッセージと移転要請メッセージが複数のコアネットワークノードを介して移転される必要がある。
移転需要メッセージと移転要請メッセージによれば、需要キーの移転及び他のパラメーターの有効な伝送を実現した。
ステップＳ１０１２において、ターゲットＲＮＣがソースＲＮＣの送信したキーを保存する。
ターゲットＲＮＣが受信したキーがコアネットワークノードが送信した移転要請メッセージのＩＫ及び／又はＣＫフィールドに位置すると、ターゲットＲＮＣがそれを拡張キーＩＫU及び／又はＣＫU（ターゲットＲＮＣが拡張したセキュリティモードを支援する）と見なし、又は伝統的なキーＩＫ及び／又はＣＫ（ターゲットＲＮＣが拡張したセキュリティモードを支援しない）と見なす。
ステップＳ１０１４において、ターゲットＲＮＣがコアネットワークノードに移転要請確認メッセージを送信する。
ソースＲＮＣとターゲットＲＮＣが異なるコアネットワークノードの下に位置すると、該メッセージは複数のコアネットワークノードの中継が必要となる。
ステップＳ１０１６において、コアネットワークノードがソースＲＮＣに移転コマンドメッセージを送信する。
ステップＳ１０１８において、ソースＲＮＣがターゲットＲＮＣに移転提出メッセージを送信する。
ステップＳ１０２０において、ターゲットＲＮＣがコアネットワークノードに移転検出メッセージを送信する。
ステップＳ１０２２において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。該メッセージがターゲットＲＮＣのセキュリティ能力の指示情報を含む。
ステップＳ１０２４において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。該メッセージがＵＥセキュリティ能力の指示情報を含む。
ステップＳ１０２２−Ｓ１０２４によれば、ターゲットＲＮＣとＵＥがそれぞれ相手のセキュリティ能力を知る。
ステップＳ１０２６において、ターゲットＲＮＣがコアネットワーク接点に移転完了メッセージを送信する。
ステップＳ１０２８において、ソースＲＮＣがコアネットワークノードとの間のＩｕｒインターフェースを解除する。ターゲットＲＮＣ及び／又はＵＥが拡張したセキュリティを支援しないと、フローがここで終わる。ターゲットＲＮＣとＵＥとがいずれも拡張したセキュリティを支援するが、ソースＲＮＣが拡張したセキュリティを支援しないと、コアネットワークノードがＡＫＡとセキュリティモード構築プロセス、又はセキュリティモード構築プロセスのみを開始すると決定し、拡張したキーを設立する。ターゲットＲＮＣとＵＥとがいずれも拡張したセキュリティを支援し、且つソースＲＮＣも拡張したセキュリティを支援すると、ステップＳ８３０を続ける。
ステップＳ１０３０において、ＵＥとターゲットＲＮＣとも拡張したセキュリティを支援すると、ターゲットＲＮＣがＲＮＣ内部移転を開始すると決定する。
ステップＳ１０３２において、ターゲットＲＮＣが拡張したエアインターフェースキーＩＫU／ＣＫUを更新する。
ターゲットＲＮＣが自ら保存したＩＫU／ＣＫU、及び／又は他のパラメーターに応じて、ＩＫU／ＣＫUを更新する。
ここで、ＩＫU／ＣＫUの推定式が以下に示すとおりである。
ＩＫU＝Ｆ（ＩＫU＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）、ＣＫU＝Ｆ（ＣＫU＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
又は（ＩＫU、ＣＫU）＝Ｆ（ＩＫU||ＣＫU，Ｐａｒａｍｅｔｅｒ）。
ここで、Ｆは任意のキー生成関数であり、例えば、３ＧＰＰにおいて定義したＫＤＦ関数でもよい。Ｐａｒａｍｅｔｅｒは１つ又は複数のパラメーターであり、例えば、ＳＲＮＣが生成したＦＲＥＳＨパラメーター、及び／又はターゲットＲＮＣ識別子でもよい。ＩＫU＿ｏｌｄとＣＫU＿ｏｌｄはＳＲＮＣの現在の拡張キーである。ＳＲＮＣがＩＫU＿ｏｌｄとＣＫU＿ｏｌｄに基づき、ターゲットＲＮＣが用いる更新されたＩＫU和ＣＫUを算出する。符号“||”はカスケードである。
ここで、前記無作為数ＦＲＥＳＨはＵＭＴＳにおいて既に定義した１つのパラメーターである。この無作為数長さが３２ビットである。接続を構築する場合に、ＲＮＣが各ユーザに１つの無作為数ＦＲＥＳＨを生成し、そしてセキュリティモードコマンドメッセージを介してユーザに送信する。全体の接続の持続時間においては、ネットワークとユーザがこの無作為数を用いてメッセージ識別コード（ＭＡＣ−Ｉ）を算出し、ネットワークがユーザシグナルメッセージのリプレーアタックを受けないように保護される。
ターゲットＲＮＣが前回ＳＲＮＣ移転プロセスで受信したＩＫをＩＫU＿ｏｌｄとし、受信したＣＫをＣＫU＿ｏｌｄとする。
ステップＳ１０３４において、ターゲットＲＮＣがコアネットワークノードに移転需要メッセージに送信し、該メッセージが更新後の拡張したエアインターフェースキーＩＫU、ＣＫUを含む。
ステップＳ１０３６において、コアネットワークノードがターゲットＲＮＣに移転要請メッセージを送信し、該メッセージが更新後の拡張したエアインターフェースキーＩＫU、ＣＫUを含む。
ターゲットＲＮＣが更新後の拡張したエアインターフェースキーＩＫU／ＣＫUをソースＲＮＣからターゲットＲＮＣまでの透明容器におけるＩＫ／ＣＫフィールドに置く。
ステップＳ１０３８において、ターゲットＲＮＣがコアネットワークノードに移転要請確認メッセージを送信する。
ステップＳ１０４０において、コアネットワークノードがターゲットＲＮＣに移転コマンドメッセージを送信する。
ステップＳ１０４２において、ターゲットＲＮＣがコアネットワークアクセスポイントに移転検出メッセージを送信する。
ここで、ステップＳ１０３４〜Ｓ１０４２は選択可能なものである。
ステップＳ１０４４において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。
ステップＳ１０４６において、ＵＥがＳＲＮＣと同様なアルゴリズムによって、完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。
ＵＥが前回ＳＲＮＣ移転プロセスに用いたＩＫをＩＫU＿ｏｌｄとし、受信したＣＫをＣＫU＿ｏｌｄとする。
ステップＳ１０４８において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。
ステップＳ１０５０において、ターゲットＲＮＣがコアネットワークアクセスポイントに移転完了メッセージを送信する。該メッセージは選択可能なものである。
図１０は、本発明の実施例によるもう１種の無線通信システムにおいてエアインターフェースキーの更新を示すフローチャートである。本実施例と図８に示す実施例は、図３に基づく拡張したキーの枠組を用いることに共通し、区別としてはキーの更新の方法が異なるところにある。本実施例では、毎回成功したＳＲＮＣ移転プロセスの後、コアネットワークノードが自ら保存した伝統的なキーＩＫ、ＣＫ及び拡張キーＩＫU、ＣＫUに応じて、ネクストホップの拡張キーＩＫU'、ＣＫU'を導き出し、そしてネクストホップ拡張キーＩＫU'、ＣＫU'をターゲットＲＮＣに送信して保存し、次回のＳＲＮＣ移転のために用意しておく。次回のＳＲＮＣ移転の際、ソースＲＮＣ（即ち、前回ＳＲＮＣ移転プロセスにおけるターゲットＲＮＣ）が保存した拡張キーＩＫU'、ＣＫU'をターゲットＲＮＣに送信し、ターゲットＲＮＣが受信したキーをそのまま使用する。
本実施例は以下のステップを含む。
ステップＳ１１０２〜ステップＳ１１２８は、図７に示す実施例におけるステップＳ７０２〜ステップＳ７２８に対応する。
ターゲットＲＮＣ及び／又はＵＥが拡張したセキュリティを支援しないと、フローがここで終わる。ターゲットＲＮＣとＵＥとがいずれも拡張したセキュリティを支援するが、ソースＲＮＣが拡張したセキュリティを支援しないと、コアネットワークノードがＡＫＡとセキュリティモード構築プロセス、又はセキュリティモード構築プロセスのみを開始すると決定し、拡張したキーを設立する。ターゲットＲＮＣとＵＥとも拡張したセキュリティを支援し、且つソースＲＮＣも拡張したセキュリティを支援すると、ステップＳ１１３０を続ける。
ステップＳ１１３０において、コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、自ら保存したＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づきネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
コアネットワークノードが１つのネクストホップカウンターネットワークＮＣＣを維持し、ネクストホップ拡張キーＩＫU'、ＣＫU'の算出回数をカウントするに用いられる。コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やし、増やした後のネットワークＮＣＣに対応するネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出し、またネットワークＮＣＣを段階的に増やしてもよい。
ステップＳ１１３２において、コアネットワークノードがターゲットＲＮＣに、ネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを含む移転完了応答メッセージを送信する。
ステップＳ１１３４において、ターゲットＲＮＣが受信したネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを保存し、次回のＳＲＮＣの移転のために用意しておく。
ステップＳ１１３６において、ターゲットＲＮＣがＲＮＣ内部移転を開始すると決定する。
ステップＳ１１３８において、ターゲットＲＮＣがコアネットワークノードに、ネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを含む移転需要メッセージを送信する。
ターゲットＲＮＣが拡張したエアインターフェースキーＩＫU／ＣＫUをソースからターゲットまでの透明容器におけるＩＫ／ＣＫフィールドに置いて送信する。
ステップＳ１１４０において、コアネットワークノードがターゲットＲＮＣに、ネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを含む移転要請メッセージを送信する。
ステップＳ１１４２において、ターゲットＲＮＣが受信した拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUを保存する。
ステップＳ１１４４において、ターゲットＲＮＣがコアネットワークノードに移転要請確認メッセージを送信する。
ステップＳ１１４６において、コアネットワークノードがターゲットＲＮＣに移転コマンドメッセージを送信する。
ステップＳ１１４８において、ターゲットＲＮＣがコアネットワーク接点に移転検出メッセージを送信する。
ここで、ステップＳ１１３８〜Ｓ１１４８選択可能なものである。
ステップＳ１１５０において、ターゲットＲＮＣがＵＥにセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。該メッセージは、ネットワークＮＣＣを含んでもよい。
ステップＳ１１５２において、ＵＥがネットワーク側と同様なアルゴリズムで完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。
本実施例では、ＵＥが１つのネクストホップカウンター端末ＮＣＣを維持し、ネットワークＮＣＣを受信した際、現在のアクティブにした拡張キーに対応する端末ＮＣＣがネットワークＮＣＣに等しいかを判断し、端末ＮＣＣがネットワークＮＣＣに等しいと、ＵＥが自ら保存した拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUをそのまま使用する。端末ＮＣＣがネットワークＮＣＣに等しくないと、ＵＥが拡張キーＩＫU／ＣＫUを算出し、そして端末ＮＣＣがネットワークＮＣＣに等しくなるまでに、対応する端末ＮＣＣを段階的に増やす。ＵＥがネットワークＮＣＣと端末ＮＣＣを介して、ターゲットＲＮＣとキーの一致を保持する。
ステップＳ１１５４において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。
ステップＳ１１５６において、ターゲットＲＮＣがコアネットワーク接点に移転完了メッセージを送信する。
ステップＳ１１５８において、コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、自ら保存したＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
コアネットワークノードが１つのネクストホップカウンターネットワークＮＣＣを維持し、ネクストホップ拡張キーＩＫU'、ＣＫU'の算出回数をカウントすることが好ましい。コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やし、そして段階的に増やした後のネットワークＮＣＣに対応するネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出し、そしてネットワークＮＣＣを段階的に増やしてもよい。
ステップＳ１１６０において、コアネットワークノードがターゲットＲＮＣに、ネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを含む移転完了応答メッセージを送信する。
ステップＳ１１６２において、ターゲットＲＮＣが受信したネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを保持し、次回のＳＲＮＣ移転のために用意しておく。
図７、図９及び図１１に示す実施例のＳＲＮＣ移転プロセスでは、ターゲットＲＮＣとソースＲＮＣとの間のメッセージインタラクションがコアネットワークノード（ＳＧＳＮ＋又はＭＳＣ＋）の移転を通さなくてもよく、即ち拡張したＳＲＮＣ移転フローを用いて行う。この時、ソースＲＮＣがターゲットＲＮＣに送信した移転要請メッセージを拡張した移転要請メッセージと称する。図７、図９及図１１における移転需要メッセージと移転要請メッセージをソースＲＮＣからターゲットＲＮＣに送信した拡張された移転要請メッセージに替え、移転要請確認メッセージと移転コマンドメッセージをターゲットＲＮＣからソースＲＮＣに送信した拡張した移転応答メッセージに替える。図７、図９及図１１における移転完了と移転完了確認メッセージをそれぞれターゲットＲＮＣとコアネットワークノードとの間の拡張した移転完了要請メッセージと拡張した移転完了応答メッセージに替える。
ここで、拡張した移転要請メッセージにネクストホップ拡張されたエアインターフェース完全性キーＩＫ'U、及び／又はネクストホップ拡張したエアインターフェース暗号化キーＣＫ'Uを持ち、ソースＲＮＣがネクストホップ拡張キーＩＫ'UとＣＫ'Uをそれぞれ移転需要メッセージのＩＫとＣＫフィールドに置いてターゲットＲＮＣに送信する。それ以外、その他のステップの操作は完全に同様である。キー更新原理が前記実施例と同一であるため、詳細な記載はここでは不要である。
図１１を参照し、本発明の実施例によるさらに１種の無線通信システムにおいてエアインターフェースキー更新のフロー図を示す。本実施例と図９に示す実施例と同じなものは図３に示す拡張したキー枠組に基づき、区別はキー更新の方法が異なっている。本実施例では、毎回成功したＳＲＮＣ移転プロセスの後、コアネットワークノードが自己保存した伝統的なキーＩＫ、ＣＫ及び拡張キーＩＫU、ＣＫUに応じて、ネクストホップの拡張キーＩＫU'、ＣＫU'を推定し、そしてネクストホップ拡張キーＩＫU'、ＣＫU'をターゲットＲＮＣ＋に送信して保存し、次回のＳＲＮＣ移転のために用意しておく。次回のＳＲＮＣ移転の際、ソースＲＮＣ＋（即ち、前回ＳＲＮＣ移転プロセスにおけるターゲットＲＮＣ＋）が保存した拡張キーＩＫU'、ＣＫU'をターゲットＲＮＣに送信し、ターゲットＲＮＣが受信したキーをそのまま使用する。
本実施例は以下のステップを含む。
ステップＳ１２０２〜ステップＳ１２２２は、図７に示す実施例におけるステップＳ７０２〜ステップＳ７２２に対応する。
ステップＳ１２２４において、コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、自ら保存したＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
コアネットワークノードが一つのネクストホップカウンターネットワークＮＣＣ、ネクストホップ拡張キーＩＫU'、ＣＫU'の算出回数をカウントすることが好ましい。コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やし、そして段階的に増やした後のネットワークＮＣＣに対応するネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出し、ネットワークＮＣＣを段階的に増やしてもよい。
ステップＳ１２２６において、コアネットワークノードがターゲットＲＮＣ＋に、ネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを含む移転完了応答メッセージを送信する。
ステップＳ１２２８において、ターゲットＲＮＣ＋が受信したネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを保存し、次回ＳＲＮＣ移転のために用意しておく。
ステップＳ１２３０において、ソースＲＮＣ＋がコアネットワークノードとの間のＩｕｒインターフェースを解除する。
該ステップとステップＳ１２２８は前後順を問わない。
ターゲットＲＮＣ及び／又はＵＥが拡張したセキュリティを支援しない場合、ステップＳ１２２４とステップＳ１２２８を省略し、フローがステップＳ１２３０で終わる。ターゲットＲＮＣとＵＥとも拡張したセキュリティを支援するが、ソースＲＮＣが拡張したセキュリティを支援しない場合、コアネットワークノードがＡＫＡとセキュリティモード構築プロセス、又はセキュリティモード構築プロセスのみを開始すると決定し、拡張したキーを設立する。ターゲットＲＮＣとＵＥとも拡張したセキュリティを支援し、且つソースＲＮＣも拡張したセキュリティを支援すると、ステップＳ１２３２を続ける。
ステップＳ１２３２において、ターゲットＲＮＣ＋がＲＮＣ内部移転を開始すると決定する。
ステップＳ１２３４において、ターゲットＲＮＣがステップＳ１２２８で保存した拡張した完全性キーＩＫU'及び／又は拡張した暗号化キーＣＫU'を用い、即ちターゲットＲＮＣ＋がＩＫU'をＩＫUとし、ＣＫU'をＣＫUとする。
ステップＳ１２３６において、ターゲットＲＮＣ＋がＵＥに、ネットワークＮＣＣを含むセル更新確認メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。
ステップＳ１２３８において、ＵＥがネットワーク側と同様なアルゴリズムに基づき完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。
本実施例では、ＵＥが１つのネクストホップカウンター端末ＮＣＣを維持し、ネットワークＮＣＣを受信した場合に、現在のアクティブにしたキーに対応する端末ＮＣＣがネットワークＮＣＣに等しいかを判断し、端末ＮＣＣがネットワークＮＣＣに等しい場合、ＵＥが自ら保存した拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUをそのまま使用する。端末ＮＣＣがネットワークＮＣＣに等しくない場合、ＵＥが拡張キーＩＫU／ＣＫUを算出し、端末ＮＣＣがネットワークＮＣＣに等しくなるまで、対応する端末ＮＣＣを段階的に増やす。ＵＥがネットワークＮＣＣと端末ＮＣＣを介して、ターゲットＲＮＣとキーの一致を保持する。
ステップＳ１２４０において、ＵＥがターゲットＲＮＣ＋にＵＴＲＡＮ移動性情報確認メッセージ、又はＲＡＮ移動性情報確認メッセージを送信する。
ステップＳ１２４２において、ターゲットＲＮＣ＋がコアネットワーク接点に移転完了メッセージを送信する。
ステップＳ１２４４において、コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、自ら保存したＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
コアネットワークノードが１つのネクストホップカウンターネットワークＮＣＣを維持し、ネクストホップ拡張キーＩＫU'、ＣＫU'の算出回数をカウントすることが好ましい。コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やし、そして段階的に増やした後のネットワークＮＣＣに対応するネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出し、そしてネットワークＮＣＣを増やしてもよい。
ステップＳ１２４６において、コアネットワークノードがターゲットＲＮＣ＋に、ネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを含む移転完了応答メッセージを送信する。
ステップＳ１２４８において、ターゲットＲＮＣ＋が受信したネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを保存し、次回のＳＲＮＣ移転のために用意しておく。
ここで、ステップＳ１２４２〜ステップＳ１２４８は選択可能なものである。
図１２は、汎用ＳＲＮＣ静的移転フローを用いてＳＲＮＣ移転キーの更新を行う模式図を示す。該実施例が図９に対応する実施例との区別は、両者のキーの更新方式が異なっているところにある。具体的なステップは以下のとおりである。
ステップＳ１３０２において、ソースＲＮＣがＳＲＮＣ移転フローを実行すると決定する。
ステップＳ１３０４において、ソースＲＮＣがソースコアネットワークノードに、ソースＲＮＣが現在用いる拡張キーＩＫU／ＣＫUを含む移転需要メッセージを送信する。
ソースＲＮＣが拡張キーＩＫUとＣＫUをそれぞれソースＲＮＣからターゲットＲＮＣまでの透明容器の伝統的なＩＫとＣＫフィールドに置くことが好ましい。
ステップＳ１３０６において、ソースコアネットワークノードが自ら保存したＩＫ、ＣＫ（又はＫASMEU）、及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
コアネットワークノードが１つのネクストホップカウンターネットワークＮＣＣを維持し、ネクストホップ拡張キーＩＫU'、ＣＫU'の算出回数をカウントすることが好ましい。コアネットワークノードがＳＲＮＣ移転が無事に完了したと知った後、ネットワークＮＣＣを段階的に増やし、そして段階的に増やした後のネットワークＮＣＣに対応するネクストホップ拡張キーＩＫU'、ＣＫU'を算出する。
又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在の拡張キーＩＫU、ＣＫUに基づいてネクストホップ拡張キーＩＫU'、ＣＫU'を算出し、ネットワークＮＣＣを段階的に増やしてもよい。
ステップＳ１３０８において、ソースコアネットワークノードがターゲットコアネットワークノードに、現在の拡張キーＩＫU／ＣＫU、ネクストホップ拡張キーＩＫU'／ＣＫU'、及び／又は対応するネットワークＮＣＣを含む転送移転要請メッセージを送信する。
ステップＳ１３１０において、ターゲットコアネットワークノードがターゲットＲＮＣに、現在の拡張キーＩＫU／ＣＫU、ネクストホップ拡張キーＩＫU'／ＣＫU'、及び／又は対応するネットワークＮＣＣを含む移転要請メッセージを送信する。
ステップＳ１３１２において、ターゲットＲＮＣが受信した現在の拡張キーＩＫU／ＣＫU、ネクストホップ拡張キーＩＫU'、ＣＫU'、及び／又は対応するネットワークＮＣＣを保存する。
ステップＳ１３１４において、ターゲットＲＮＣがターゲットコアネットワークノードに移転要請確認メッセージを送信する。
ステップＳ１３１６において、ターゲットコアネットワークノードがソースコアネットワークノードに転送移転応答メッセージを送信する。
ステップＳ１３１８において、ソースコアネットワークノードがソースＲＮＣに移転コマンドメッセージを送信する。
ステップＳ１３２０において、ソースＲＮＣがターゲットＲＮＣに移転提出メッセージを送信する。
ステップＳ１３２２において、ターゲットＲＮＣがターゲットコアネットワークノードに移転検出メッセージを送信する。
ステップＳ１３２４において、ターゲットＲＮＣがＵＥにＵＴＲＡＮ移動性情報メッセージ、又はセル更新確認メッセージ、ＵＲＡ更新確認メッセージを送信する。
ステップＳ１３２６において、ＵＥが現在のアクティブにした拡張キーＩＫU／ＣＫUを用いて、受信したメッセージを解読、検証し、ターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージを送信し、このメッセージが依然としてＵＥとソースＲＮＣとの通信に用いる拡張キーＩＫU／ＣＫUを使用してセキュリティ保護を行う。
ステップＳ１３２８において、ターゲットＲＮＣがターゲットコアネットワークノードに移転完了メッセージを送信し、コアネットワークノードに移転が無事に完了したと通知する。
ステップＳ１３３０において、ターゲットコアネットワークノードとソースコアネットワークノードが転送移転完了／確認メッセージのインタラクションを行う。
ステップＳ１３３２において、ソースコアネットワークノードがソースＲＮＣとのＩｕ接続を解除する。
ステップＳ１３３４において、ターゲットＲＮＣがＲＮＣ内部移転を開始すると決定する。
ステップＳ１３３６において、ターゲットＲＮＣが保存したネクストホップ拡張キーＩＫU'／ＣＫU'を用いて、ＩＫU'をＩＫUとし、ＣＫU'をＣＫUとする。
ステップＳ１３３８において、ターゲットＲＮＣがＵＥに、ネットワークＮＣＣを含むＵＴＲＡＮ移動性情報メッセージ、又はＵＲＡ更新確認メッセージ、又はＲＡＮ移動性情報メッセージを送信する。
ステップＳ１３４０において、ＵＥがネットワーク側と同様なアルゴリズムで拡張キーＩＫU ／ＣＫUを同期する。
本実施例では、ＵＥが１つのネクストホップカウンター端末ＮＣＣを維持し、ネットワークＮＣＣを受信した時、現在アクティブにした拡張キーに対応する端末ＮＣＣがネットワークＮＣＣに等しいかを判断し、端末ＮＣＣがネットワークＮＣＣに等しい場合、ＵＥが自ら保存した拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUをそのまま使用する。端末ＮＣＣがネットワークＮＣＣに等しくない場合、ＵＥが拡張キーＩＫU／ＣＫUを算出し、端末ＮＣＣがネットワークＮＣＣに等しくなるまで、対応する端末ＮＣＣを段階的に増やす。ＵＥがネットワークＮＣＣと端末ＮＣＣを介して、ターゲットＲＮＣとキーの一致を保持する。
ステップＳ１３４２において、ＵＥがターゲットＲＮＣにＵＴＲＡＮ移動性情報確認メッセージを送信する。該メッセージが更新された拡張キーＣＫU／ＩＫUを用いてセキュリティ保護を行う。ターゲットＲＮＣが該メッセージを受信した後、更新されたキーを用いて該メッセージを検証する。検証に成功すると、内部ＳＲＮＳ移転フローが無事に完了される。
図１３を参照し、汎用ＳＲＮＣ静的移転フローを用いてＳＲＮＣ移転キーの更新を行う模式図を示す。該実施例と図７に対応する実施例との区別は、両者のキーの更新方式が異なっているところにある。具体的なステップは以下とおりである。
ステップＳ１４０２〜１４０４は、図１２に対応するステップＳ１３０２〜１３０４に同一である。
ステップＳ１４０６において、ソースコアネットワークノードが保存された伝統的なキーＩＫ、ＣＫ及び現在の変形中間キーＫRNC*に基づいてネクストホップ変形中間キーＫRNC*を算出する。
好適なスキームとして、本実施例においてコアネットワークノードが１つのネクストホップカウンターネットワークＮＣＣを維持し、変形中間キーＫRNC*の算出回数をカウントすることである。コアネットワークノードが移転需要メッセージを受信した後、ネットワークＮＣＣを段階的に増やし、そして段階的に増やした後のネットワークＮＣＣに対応するネクストホップ変形中間キーＫRNC*を算出し、又は、コアネットワークノードがまずＩＫ、ＣＫ及び現在変形中間キーＫRNC*に基づいてネクストホップ変形中間キーＫRNC*を算出し、そしてネットワークＮＣＣを段階的に増やしてもよい。
ステップＳ１４０８において、ソースコアネットワークノードがターゲットコアネットワークノードに、現在の拡張キーＩＫU／ＣＫU、ネクストホップ変形中間キーＫRNC*、及び／又は対応するネットワークＮＣＣを含む転送移転要請メッセージを送信する。
ステップＳ１４１０において、ターゲットコアネットワークノードがターゲットＲＮＣに、現在の拡張キーＩＫU／ＣＫU、ネクストホップ変形中間キーＫRNC*、及び／又は対応するネットワークＮＣＣを含む移転要請メッセージを送信する。
ステップＳ１４１２において、ターゲットＲＮＣが受信した現在の拡張キーＩＫU／ＣＫU、ネクストホップ変形中間キーＫRNC*、及び／又は対応するネットワークＮＣＣを保存する。
ステップＳ１４１４〜Ｓ１４３４は、図１２に対応するステップＳ１３１４〜１３３４と同一である。
ステップＳ１４３６において、ターゲットＲＮＣが保存した変形中間キーＫRNC*に応じて拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUを推定して算出する。
ターゲットＲＮＣが中間キーＫRNCを変形中間キーＫRNC*に等しくさせ、中間キーＫRNCに基づいて更新されたＩＫU及び／又はＣＫUを算出してもよい。
ステップＳ１４３８において、図１２に対応するステップＳ１３３８と同一である。
ステップＳ１４４０において、ＵＥが変形中間キーＫRNC*に基づいて完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。
ＵＥが中間キーＫRNCを変形中間キーＫRNC*に等しくさせ、中間キーＫRNCに基づいて更新されたＩＫU及び／又はＣＫUを算出してもよい。
本ステップでは、ＵＥが１つのネクストホップカウンター端末ＮＣＣを維持し、ネットワークＮＣＣを受信した場合に、ＵＥが現在アクティブにした拡張キーに対応する端末ＮＣＣがネットワークＮＣＣに等しいかを判断し、端末ＮＣＣがネットワークＮＣＣに等しいと、ＵＥが端末ＮＣＣに対応する自ら保存した変形中間キーＫRNC*に基づいて拡張した完全性キーＩＫU及び／又は拡張した暗号化キーＣＫUを更新する。端末ＮＣＣがネットワークＮＣＣに等しくない場合、ＵＥが変形中間キーＫRNC*を算出して、端末ＮＣＣがネットワークＮＣＣに等しくなるまで、対応する端末ＮＣＣを段階的に増やし、変形中間キーＫRNC*に基づいて拡張した完全性キーＩＫU及び／又は暗号化キーＣＫUを更新する。ＵＥがネットワークＮＣＣと端末ＮＣＣを介して、ターゲットＲＮＣとキーの一致を保持する。
ステップＳ１４４２において、図１２に対応するステップＳ１３４２と同一である。
図１４は、本発明の実施例による無線アクセスシステムの構成ブロック図を示し、ソースＲＮＣ１５０２とターゲットＲＮＣ１５０４を含む。
ここで、ソースＲＮＣ１５０２が、ターゲットＲＮＣに対して静的移転を行うように設置される。
ここで、ターゲットＲＮＣ１５０４は、ソースＲＮＣ１５０２がターゲットＲＮＣ１５０４に対する静的移転を完了した後、ＳＲＮＣ内部移転を行うように設置され、ＳＲＮＣ内部移転プロセスでは、ターゲットＲＮＣ１５０４がソースＲＮＣ１５０２から又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新する。
ここで、ソースＲＮＣ１５０２が拡張したセキュリティを支援する場合、ソースＲＮＣ１５０２が送信したキーは拡張キーである。しかしながら、ターゲットＲＮＣ１５０４がそれを拡張キーと見なし、伝統的なキーと見なしてもよい。ソースＲＮＣ１５０２が拡張したセキュリティモードを支援しない場合には、ソースＲＮＣ１５０２のキーが伝統的なキーのみとなる。
本実施例の無線アクセスシステムは更に、コアネットワークノード１５０６を含むことが好ましい。このコアネットワークノード１５０６が、保存された伝統的なキー及び現在の変形中間キーを用いてネクストホップ変形中間キーを生成し、ターゲットＲＮＣ１５０４に送信するように設置され、又は、保存した伝統的なキー及び現在の拡張キーを用いてネクストホップ拡張キーを生成し、ターゲットＲＮＣ１５０４に送信するように設置される。
コアネットワークノード１５０６がネクストホップカウンターネットワークＮＣＣを含み、ネクストホップ変形中間キー又はネクストホップ拡張キーの生成回数をカウントするように設置されることが好ましい。
本実施例の無線アクセスシステムは更に、ユーザ設備ＵＥ１５０８を含み、ＵＥ１５０８にはネクストホップカウンター端末ＮＣＣが設置されることが好ましい。該ＵＥ１５０８は、ターゲットＲＮＣ１５０４が送信する移転確認メッセージを受信するように設置され、前記移転確認メッセージがコアネットワークノード１５０６のネクストホップカウンターネットワークＮＣＣを含む受信モジュールと、端末ＮＣＣがネットワークＮＣＣに等しいかを判断するように設置される判断モジュールと、判断モジュールの判断結果がYESであると、端末ＮＣＣに対応する予め保存された変形中間キーに応じて自身の拡張キーを更新するように設置され、又は、端末ＮＣＣに対応する予め保存された拡張キーを用いるように設置される確定モジュールと、判断モジュールの判断結果がNOであると、変形中間キーを算出し、端末ＮＣＣがネットワークＮＣＣに等しくなるまで、対応する端末ＮＣＣを段階的に増やし、そして変形中間キーに応じて自身の拡張キーを算出し、更新するように設置され、又は、拡張キーを算出し、前記端末ＮＣＣが前記ネットワークＮＣＣに等しくなるまで、対応する端末ＮＣＣを段階的に増やすように設置される否定モジュールとを含む。
本発明の提供するスキームはＵＭＴＳシステムに限られず、当業者は本発明実施例を参照してそれを他の無線通信システムに用いてもよく、本発明より限定されない。
当業者にとっては、上述の本発明の各モジュール又は各ステップは汎用の計算装置によって実現することができ、単独の計算装置に集中させてもよく、複数の計算装置から構成されるネットワークに分布させてもよく、または、計算装置が実行可能なプログラムのコードによって実現することもできるので、それらを記憶装置に記憶させて計算装置によって実行でき、また、場合によっては、示されたまたは述べられたステップと異なる順で実行されてもよく、又はそれらの夫々を集積回路ブロックに製作し、又はそれらにおける複数のモジュール又はステップを単独の集積回路モジュールに製作して実現することができることは明らかである。このように、本発明は如何なるハードウェアとソフトウェアの結合にも限定されない。
以上は、本発明の好適な実施例に過ぎず、本発明を限定するものではない。当業者であれば本発明に様々な修正や変形が可能である。本発明の精神や原則内での如何なる修正、置換、改良などは本発明の保護範囲内に含まれる。

Claims (29)

  1. エアインターフェースキーの更新方法であって、
    ソース無線ネットワークコントローラＲＮＣがターゲットＲＮＣへの静的移転を完了するステップと、
    前記ターゲットＲＮＣがサービス無線ネットワークコントローラＳＲＮＣ内部移転を行うステップと、
    前記ＳＲＮＣ内部移転プロセスでは、前記ターゲットＲＮＣが前記ソースＲＮＣから又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップとを含み、
    前記ソースＲＮＣがターゲットＲＮＣへの静的移転を完了するステップの前、
    前記ソースＲＮＣが前記ターゲットＲＮＣへ静的移転を行うことと、
    前記静的移転プロセスでは、前記ソースＲＮＣがその用いる現在キーを前記ターゲットＲＮＣに直接送信し、前記ターゲットＲＮＣが前記現在キーを用いてユーザ設備ＵＥと通信することとを更に含み、
    前記ターゲットＲＮＣがＳＲＮＣ内部移転を行うステップは、
    前記ターゲットＲＮＣが第２ターゲットＲＮＣへＳＲＮＣ移転を行い、ここで、前記ターゲットＲＮＣと第２ターゲットＲＮＣが同一なＲＮＣであることを含む方法。
  2. 前記ターゲットＲＮＣが前記ソースＲＮＣ又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップは、
    前記ターゲットＲＮＣが前記ソースＲＮＣ又はコアネットワークノードから送信される変形中間キーに応じて自身の拡張キーを推定し更新し、前記変形中間キーを、前回ＳＲＮＣ静的移転が無事に完了した後、前記コアネットワークノードが保存した伝統的なキーと現在の変形中間キーを用いて生成し、前記ターゲットＲＮＣに送信することを含む請求項１に記載の方法。
  3. 前記ソースＲＮＣがターゲットＲＮＣへの静的移転を完了するステップの前、
    前記ソースＲＮＣが前記コアネットワークノードに移転需要メッセージを送信し、前記移転需要メッセージが前記ソースＲＮＣの現在の拡張キーを含み、前記現在の拡張キーが現在の拡張完全性キーＩＫ Ｕ 及び／又は現在の拡張暗号化キーＣＫ Ｕ を含むことと、
    前記コアネットワークノードが前記ターゲットＲＮＣに移転要請メッセージを送信し、前記移転要請メッセージが前記ソースＲＮＣの現在の拡張キーを含むことを更に含む請求項２に記載の方法。
  4. 前記ソースＲＮＣが前記コアネットワークノードに移転需要メッセージを送信するステップは、
    前記ソースＲＮＣが前記現在の拡張完全性キーＩＫ Ｕ を前記移転需要メッセージのＩＫフィールドに置き、及び／又は前記現在の拡張暗号化キーＣＫ Ｕ を前記移転需要メッセージのＣＫフィールドに置き、前記コアネットワークノードに送信することを含み、
    前記コアネットワークノードが前記ターゲットＲＮＣに移転要請メッセージを送信するステップは、
    前記コアネットワークノードが前記ソースＲＮＣが送信する現在の拡張完全性キーＩＫ Ｕ を前記移転要請メッセージのＩＫフィールドに置き、及び／又は前記現在の拡張暗号化キーＣＫ Ｕ を前記移転要請メッセージのＣＫフィールドに置き、前記ターゲットＲＮＣに送信することを含む請求項３に記載の方法。
  5. 前記コアネットワークノードが前記ターゲットＲＮＣに移転要請メッセージを送信するステップの後、
    前記ターゲットＲＮＣが拡張したセキュリティモードを支援しない場合、前記移転要請メッセージのＩＫフィールドの内容を伝統的な完全性キーＩＫとし、ＣＫフィールドの内容を伝統的な暗号化キーＣＫとして用いることと、
    前記ターゲットＲＮＣが拡張したセキュリティモードを支援する場合、前記移転要請メッセージのＩＫフィールドの内容をＩＫ Ｕ とし、ＣＫフィールドの内容をＣＫ Ｕ として用いることとを更に含む請求項４に記載の方法。
  6. 前記ソースＲＮＣがターゲットＲＮＣへの静的移転を完了するステップの前、
    前記ソースＲＮＣが前記ターゲットＲＮＣに拡張した移転要請メッセージを送信し、前記拡張した移転要請メッセージが前記ソースＲＮＣの現在の拡張キーを含み、前記現在の拡張キーが現在の拡張完全性キーＩＫ Ｕ 及び／又は現在の拡張暗号化キーＣＫ Ｕ を含むことを更に含む請求項２に記載の方法。
  7. 前記ソースＲＮＣが前記ターゲットＲＮＣに拡張した移転要請メッセージを送信するステップは、
    前記ソースＲＮＣが前記現在の拡張完全性キーＩＫ Ｕ を前記拡張した移転要請メッセージのＩＫフィールドに置き、及び／又は前記現在の拡張暗号化キーＣＫ Ｕ を前記拡張した移転要請メッセージのＣＫフィールドに置き、前記ターゲットＲＮＣに送信することを含む請求項６に記載の方法。
  8. 前記ソースＲＮＣが前記ターゲットＲＮＣに拡張した移転要請メッセージを送信するステップの後、
    前記ターゲットＲＮＣが拡張したセキュリティモードを支援しない場合、前記拡張した移転要請メッセージのＩＫフィールドの内容を伝統的な完全性キーＩＫとし、ＣＫフィールドの内容を伝統的な暗号化キーＣＫとして用いることと、
    前記ターゲットＲＮＣが拡張したセキュリティモードを支援する場合、前記拡張した移転要請メッセージのＩＫフィールドの内容をＩＫ Ｕ とし、ＣＫフィールドの内容をＣＫ Ｕ として用いることとを更に含む請求項７に記載の方法。
  9. 前記コアネットワークノードが前記ターゲットＲＮＣに移転要請メッセージを送信するステップの後、
    前記ターゲットＲＮＣがユーザ設備ＵＥに移転確認メッセージを送信し、前記移転確認メッセージが前記ターゲットＲＮＣのセキュリティ能力の指示情報を含むことと、
    前記ＵＥが前記ターゲットＲＮＣに確認応答メッセージを送信し、前記確認応答メッセージが前記ＵＥのセキュリティ能力の指示情報を含むことを更に含む請求項３に記載の方法。
  10. 前記ターゲットＲＮＣがＳＲＮＣ内部移転を行うステップは、
    前記ターゲットＲＮＣが前記ＵＥに移転確認メッセージを送信し、前記移転確認メッセージが前記コアネットワークノードのネクストホップカウンターネットワークＮＣＣを含むことと、
    前記ＵＥが現在アクティブにしたキーに対応するネクストホップカウンター端末ＮＣＣが前記ネットワークＮＣＣに等しいかを判断することと、
    はいである場合、前記ＵＥが前記端末ＮＣＣに対応する予め保存した変形中間キーに応じて自身の拡張キーを更新することと、
    いいえである場合、前記ＵＥが変形中間キーを算出し、前記端末ＮＣＣが前記ネットワークＮＣＣに等しくなるまでに、対応する前記端末ＮＣＣを逓増し、そして前記変形中間キーに応じて自身の拡張キーを算出して更新することとを含む請求項１に記載の方法。
  11. 前記方法は、
    前記ターゲットＲＮＣが前記ＳＲＮＣ内部移転を完了することと、
    前記コアネットワークノードが保存した伝統的なキーと現在の変形中間キーに応じ、ネクストホップ変形中間キーを算出し、そして前記ターゲットＲＮＣに前記ネクストホップ変形中間キーを送信することとを更に含む請求項１０に記載の方法。
  12. 前記コアネットワークノードが保存した伝統的なキーと現在の変形中間キーに応じ、ネクストホップ変形中間キーを算出するステップの前又は後、
    前記コアネットワークノードが前記ネットワークＮＣＣを逓増することを更に含む請求項１１に記載の方法。
  13. 前記ターゲットＲＮＣが前記ソースＲＮＣ又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップは、
    前記ターゲットＲＮＣが保存した現在の拡張キーを用いて自身の拡張キーを更新し、前記現在の拡張キーが前記ソースＲＮＣの現の拡張キーであることを含む請求項１に記載の方法。
  14. 前記ターゲットＲＮＣが保存した現在の拡張キーを用いて自身の拡張キーを更新するステップは、
    前記ターゲットＲＮＣが以下の公式で保存した前記ソースＲＮＣから受信した拡張キーを用いて自身の拡張キーを更新する請求項１３に記載の方法。
    ＩＫ Ｕ ＝Ｆ（ＩＫ Ｕ ＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
    ＣＫ Ｕ ＝Ｆ（ＣＫ Ｕ ＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
    又は、
    （ＩＫ Ｕ 、ＣＫ Ｕ ）＝Ｆ（ＩＫ Ｕ ＿ｏｌｄ||ＣＫ Ｕ ＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
    ここで、Ｆは任意のキー生成関数、Ｐａｒａｍｅｔｅｒはパラメーター、ＩＫ Ｕ ＿ｏｌｄとＣＫ Ｕ ＿ｏｌｄは前記ターゲットＲＮＣ現在の拡張キー、ＩＫ Ｕ とＣＫ Ｕ は前記ターゲットＲＮＣ更新後の拡張キー、“||”はカスケードである。
  15. 前記方法は、
    前記ターゲットＲＮＣが前記ＵＥに移転確認メッセージを送信することと、
    前記ＵＥが前記移転確認メッセージを受信し、以下の公式で保存した現在の拡張キーを用いて自身の拡張キーを更新し、
    ＩＫ Ｕ ＝Ｆ（ＩＫ Ｕ ＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
    ＣＫ Ｕ ＝Ｆ（ＣＫ Ｕ ＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
    又は、
    （ＩＫ Ｕ 、ＣＫ Ｕ ）＝Ｆ（ＩＫ Ｕ ＿ｏｌｄ||ＣＫ Ｕ ＿ｏｌｄ，Ｐａｒａｍｅｔｅｒ）；
    ここで、Ｆは任意のキー生成関数、Ｐａｒａｍｅｔｅｒはパラメーター、ＩＫ Ｕ ＿ｏｌｄとＣＫ Ｕ ＿ｏｌｄはＵＥ現在の拡張キー、ＩＫ Ｕ とＣＫ Ｕ はＵＥ更新後の拡張キー、“||”はカスケードであることと、
    前記ＵＥが前記ターゲットＲＮＣに確認応答メッセージを送信することとを更に含む請求項１４に記載の方法。
  16. 前記ターゲットＲＮＣが前記ソースＲＮＣ又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップは、
    前記ターゲットＲＮＣが前記ソースＲＮＣ又はコアネットワークノードが送信した拡張キーを用いて自身の拡張キーを更新し、前記ソースＲＮＣ又はコアネットワークノードの拡張キーを前回ＳＲＮＣ静的移転が無事に完了した後、前記コアネットワークノードが保存した伝統的なキーと現在の拡張キーを用いて生成し、前記ターゲットＲＮＣに送信することを含む請求項１に記載の方法。
  17. 前記方法は、
    前記ターゲットＲＮＣが前記ＵＥに移転確認メッセージを送信し、前記移転確認メッセージが前記コアネットワークノードのネクストホップカウンターネットワークＮＣＣを含むことと、
    前記ＵＥが現在のアクティブにしたキーに対応するネクストホップカウンター端末ＮＣＣが前記ネットワークＮＣＣに等しいかを判断することと、
    はいであると、前記ＵＥが前記端末ＮＣＣに対応する予め保存した拡張キーを用いることと、
    いいえであると、前記ＵＥが拡張キーを算出し、そして前記端末ＮＣＣが前記ネットワークＮＣＣに等しくなるまでに、対応する前記端末ＮＣＣを逓増することとを更に含む請求項１６に記載の方法。
  18. 前記方法は更に、
    前記ターゲットＲＮＣが前記ＳＲＮＣ内部移転を完了するステップと、
    前記コアネットワークノードが保存した伝統的なキーと現在の拡張キーに応じて、ネクストホップ拡張キーを算出し、そして前記ターゲットＲＮＣに前記ネクストホップ拡張キーを送信するステップとを更に含む請求項１７に記載の方法。
  19. 前記コアネットワークノードが保存した伝統的なキーと現在の拡張キーに応じて、ネクストホップ拡張キーを算出するステップの前又は後、
    前記コアネットワークノードが前記ネットワークＮＣＣを逓増することを更に含む請求項１８に記載の方法。
  20. 前記ターゲットＲＮＣがコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップは、
    前記コアネットワークノードが自ら保存した伝統的なキーと現在の拡張キーを用いて、ネクストホップ拡張キーを算出して前記ターゲットＲＮＣに送信することと、
    前記ターゲットＲＮＣが前記ネクストホップ拡張キーを用いて自身の拡張キーを更新することとを含む請求項１に記載の方法。
  21. 前記ソースＲＮＣが拡張したセキュリティを支援するソースＲＮＣであり、及び／又は、前記ターゲットＲＮＣが拡張したセキュリティを支援するターゲットＲＮＣである請求項１に記載の方法。
  22. 前記移転需要メッセージは更に前記ソースＲＮＣのネクストホップ変形中間キーを含み、前記移転要請メッセージが更に前記ソースＲＮＣの前記ネクストホップ変形中間キーを含む請求項３に記載の方法。
  23. 前記ソースＲＮＣがターゲットＲＮＣへの静的移転を完了するステップの前、
    前記ソースＲＮＣが前記コアネットワークノードに移転需要メッセージを送信し、前記移転需要メッセージが前記ソースＲＮＣの現在の拡張キーと前記ソースＲＮＣのネクストホップ拡張キーを含み、前記現在の拡張キーが現在の拡張完全性キーＩＫ Ｕ 及び／又は現在の拡張暗号化キーＣＫ Ｕ を含むことと、
    前記コアネットワークノードが前記ターゲットＲＮＣに移転要請メッセージを送信し、前記移転要請メッセージが前記ソースＲＮＣの現在の拡張キーと前記ソースＲＮＣの前記ネクストホップ拡張キーを含むこととを更に含む請求項１に記載の方法。
  24. 前記ターゲットＲＮＣが前記コアネットワークノードから受信したキーに応じて自身の拡張キーを更新するステップは、
    前記ターゲットＲＮＣが前記コアネットワークノードから受信した前記ソースＲＮＣのネクストホップ拡張キーに応じて自身の拡張キーを更新することを含む請求項２３に記載の方法。
  25. 静的移転を行うように設置されるソース無線ネットワークコントローラＲＮＣと、ここで、前記静的移転プロセスでは、前記ソースＲＮＣがその用いる現在キーをターゲットＲＮＣに直接送信し、前記ターゲットＲＮＣが前記現在キーを用いてユーザ設備ＵＥと通信し、
    前記ソースＲＮＣが前記ターゲットＲＮＣへの静的移転を完了した後、ＳＲＮＣ内部移転を行い、前記内部移転プロセスでは、前記ターゲットＲＮＣが前記ソースＲＮＣから又はコアネットワークノードから受信したキーに応じて自身の拡張キーを更新するように設置されるターゲットＲＮＣと、を含み、
    前記ターゲットＲＮＣがＳＲＮＣ内部移転を行うことが、
    前記ターゲットＲＮＣが第２ターゲットＲＮＣへＳＲＮＣ移転を行い、ここで、前記ターゲットＲＮＣと第２ターゲットＲＮＣが同一なＲＮＣであることを含む無線アクセスシステム。
  26. 前記無線アクセスシステムは更に、
    保存された伝統的なキーと現在の変形中間キーを用いてネクストホップ変形中間キーを生成し、前記ターゲットＲＮＣに送信するように設置されるコアネットワークノード、
    又は、
    保存された伝統的なキーと現在の拡張キーを用いてネクストホップ拡張キーを生成し、前記ターゲットＲＮＣに送信するように設置されるコアネットワークノードを含む請求項２５に記載の無線アクセスシステム。
  27. 前記コアネットワークノードは、更に、ネクストホップ変形中間キー又はネクストホップ拡張キーの生成回数を数えるように設置されるネクストホップカウンターネットワークＮＣＣを含む請求項２６に記載の無線アクセスシステム
  28. 前記無線アクセスシステムは、更に、
    ネクストホップカウンター端末ＮＣＣを設置するユーザ設備ＵＥを含み、前記ＵＥが、
    前記ターゲットＲＮＣが送信した移転確認メッセージを受信し、前記移転確認メッセージがコアネットワークノードのネクストホップカウンターネットワークＮＣＣを含むように設置される受信モジュールと、
    前記端末ＮＣＣがネットワークＮＣＣに等しいかを判断するように設置される判断モジュールと、
    前記判断モジュールの判断結果がYESであると、前記端末ＮＣＣに対応する予め保存した変形中間キーに応じて自身の拡張キーを更新し、又は、前記端末ＮＣＣに対応する予め保存した拡張キーを用いるように設置される確定モジュールと、
    前記判断モジュールの判断結果がNOであると、変形中間キーを算出し、前記端末ＮＣＣが前記ネットワークＮＣＣに等しくなるまでに、対応する前記端末ＮＣＣを逓増し、そして前記変形中間キーに応じて自身の拡張キーを算出し更新し、又は、拡張キーを算出し、そして前記端末ＮＣＣが前記ネットワークＮＣＣに等しくなるまでに、対応する前記端末ＮＣＣを増やすように設置される否定モジュールとを含む請求項２５に記載の無線アクセスシステム。
  29. 前記ソースＲＮＣが拡張したセキュリティソースＲＮＣを支援する、及び／又は、前記ターゲットＲＮＣが拡張したセキュリティターゲットＲＮＣを支援する請求項２５に記載の無線アクセスシステム。
JP2013513529A 2010-06-07 2011-03-11 エアインターフェースキーの更新、生成方法及び無線アクセスシステム Active JP5828892B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201010202417.8A CN101867924B (zh) 2010-06-07 2010-06-07 空中接口密钥的更新、生成方法及无线接入系统
CN201010202417.8 2010-06-07
PCT/CN2011/071719 WO2011153855A1 (zh) 2010-06-07 2011-03-11 空中接口密钥的更新、生成方法及无线接入系统

Publications (2)

Publication Number Publication Date
JP2013529447A JP2013529447A (ja) 2013-07-18
JP5828892B2 true JP5828892B2 (ja) 2015-12-09

Family

ID=42959432

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013513529A Active JP5828892B2 (ja) 2010-06-07 2011-03-11 エアインターフェースキーの更新、生成方法及び無線アクセスシステム

Country Status (6)

Country Link
US (1) US8934868B2 (ja)
EP (1) EP2579633B1 (ja)
JP (1) JP5828892B2 (ja)
CN (1) CN101867924B (ja)
CA (2) CA2849638C (ja)
WO (1) WO2011153855A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101841810B (zh) 2010-06-07 2016-01-20 中兴通讯股份有限公司 空中接口密钥的更新方法、核心网节点及无线接入系统
CN101867924B (zh) 2010-06-07 2016-07-06 中兴通讯股份有限公司 空中接口密钥的更新、生成方法及无线接入系统
WO2014161151A1 (en) * 2013-04-02 2014-10-09 Qualcomm Incorporated Method and apparatus for avoiding call drops during serving radio network subsystem (srns) relocation procedure
EP3886397B1 (en) 2014-03-21 2023-01-18 Sun Patent Trust Security key derivation in dual connectivity
US10681590B2 (en) * 2014-05-09 2020-06-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handover procedures in a communication network
MX2019009648A (es) * 2017-02-14 2019-09-27 Ericsson Telefon Ab L M Metodos y nodos de red para administrar la recopilacion de mediciones de qoe durante la reubicacion o transferencia.

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020018571A1 (en) * 1999-08-31 2002-02-14 Anderson Walter F. Key management methods and communication protocol for secure communication systems
JP2001339386A (ja) * 2000-05-25 2001-12-07 Nec Corp 無線通信システム、無線ネットワーク制御装置、ユーザ端末装置
GB0020443D0 (en) * 2000-08-18 2000-10-04 Nokia Networks Oy Controlling communication between stations
CN101094439B (zh) * 2006-06-23 2011-05-04 华为技术有限公司 无线通信系统中为广播业务动态分配资源的方法及装置
EP2223493B1 (en) * 2007-12-19 2017-11-22 Nokia Technologies Oy Methods, apparatuses, system and related computer program products for handover security
CN101232731B (zh) * 2008-02-04 2012-12-19 中兴通讯股份有限公司 用于ue从utran切换到eutran的密钥生成方法和系统
CN101715188B (zh) * 2010-01-14 2015-11-25 中兴通讯股份有限公司 一种空口密钥的更新方法及系统
US8929543B2 (en) * 2010-03-17 2015-01-06 Telefonaktiebolaget L M Ericsson (Publ) Enhanced key management for SRNS relocation
CN101867924B (zh) 2010-06-07 2016-07-06 中兴通讯股份有限公司 空中接口密钥的更新、生成方法及无线接入系统

Also Published As

Publication number Publication date
US8934868B2 (en) 2015-01-13
US20130078956A1 (en) 2013-03-28
EP2579633B1 (en) 2017-04-19
CA2849638A1 (en) 2011-12-15
CA2849638C (en) 2017-10-24
CN101867924B (zh) 2016-07-06
CN101867924A (zh) 2010-10-20
JP2013529447A (ja) 2013-07-18
EP2579633A1 (en) 2013-04-10
WO2011153855A1 (zh) 2011-12-15
CA2803653A1 (en) 2011-12-15
EP2579633A4 (en) 2014-01-15

Similar Documents

Publication Publication Date Title
JP6512416B2 (ja) 通信装置および方法
JP5828892B2 (ja) エアインターフェースキーの更新、生成方法及び無線アクセスシステム
JP5238066B2 (ja) ハンドオーバーのためのマルチホップ暗号分離を与える方法、装置及びコンピュータプログラム手順
JP5774096B2 (ja) エアインターフェースキーの更新方法、コアネットワークノード及び無線アクセスシステム
US20170019945A1 (en) Dual Connectivity Re-Establishment
US20080039096A1 (en) Apparatus, method and computer program product providing secure distributed HO signaling for 3.9G with secure U-plane location update from source eNB
US8072939B2 (en) Mobile communication method, radio base station, and mobile station
JP2012532539A (ja) 無線リソース制御接続再確立の際のセキュリティキー処理方法、装置及びシステム
JP5770288B2 (ja) エアーインターフェースキーの更新方法、コアネットワークノード及びユーザ設備
CN104812010A (zh) 一种在小小区增强场景下支持ue恢复的方法
US11616768B2 (en) Method and apparatus for handling security keys for individual bearers
CN101835151B (zh) 空中接口密钥的更新方法及无线接入系统
CN101902736B (zh) 空中接口密钥的更新方法、核心网节点及无线接入系统
WO2012022186A1 (zh) 空中接口密钥的更新方法、核心网节点、ue及无线接入系统
JP2010045815A (ja) 移動通信方法、無線基地局及び移動局

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140227

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20141007

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20141008

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150107

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150602

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150827

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150929

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20151020

R150 Certificate of patent or registration of utility model

Ref document number: 5828892

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250