JP2017103536A - 無線基地局及び無線通信方法 - Google Patents

Abstract

【課題】無線基地局（eNB）が、新規なRRCコネクションの確立理由（Establishment Cause）に対応していない場合でも、RRC Connection Requestを異常終了させずに正常に処理し得る無線基地局及び無線通信方法を提供する。【解決手段】無線基地局は、RRC Connection Requestをユーザ装置から受信し、当該RRC Connection Requestに含まれるEstablishment Causeが、無線基地局においてサポートしていない未サポート確立理由である場合、当該未サポート確立理由と対応付けられた動作に従ってRRC Connection Requestを処理する。【選択図】図５

Description

本発明は、無線リソース制御レイヤにおけるコネクション要求に基づいてユーザ装置とのコネクションを確立する無線基地局及び無線通信方法に関する。

3rd Generation Partnership Project（3GPP）は、Long Term Evolution（LTE）を仕様化し、LTEの更なる高速化を目的としてLTE-Advanced（以下、LTE-Advancedを含めてLTEという）を仕様化している。

LTEでは、ユーザ装置（UE）が、RRC Connection Requestを無線アクセスネットワーク（E-UTRAN）、具体的には、無線基地局（eNB）に送信することによって、無線リソース制御（RRC）レイヤのコネクション（RRCコネクション）の確立が開始される。UE及びeNBは、確立したRRCコネクションを用いて要求された通信（呼処理）を実行する。

RRC Connection Requestは、RRCコネクションの確立理由、具体的には、呼種別を示すEstablishment Causeを含む（非特許文献１参照）。Establishment Causeは、enumerated形式で表現され、８つの呼種別が規定されている。

例えば、UEからの発信データ（mobile originating data (mo-Data）や、緊急呼（emergency）がEstablishment Causeとして規定されている。これにより、無線アクセスネットワークは、Establishment Causeが緊急呼であった場合、当該緊急呼を他の呼よりも優先的に処理することなどが可能となる。

また、Establishment Causeには、将来の拡張性を考慮して予備のCauseが確保されている。具体的には、spare1及びspare2が確保されている。

3GPP TS 36.331 V12.7.0 Subclause 6.2.2 Message definitions, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 12)、3GPP、2015年9月

3GPPは、次に標準化されるリリース（Rel.13）において、新規なEstablishment Causeを規定することを検討している。このような新規なEstablishment Causeを規定する場合、上述した予備のCause（spare1, spare2）を用いることが考えられるが、次のような問題がある。

すなわち、UEがこのような新規なEstablishment Causeに対応、つまり、最新リリースに対応していても、eNBが新規なEstablishment Causeに対応していないケースが想定される。

この場合、eNBは、spare1またはspare2であることは判定できても、新規に規定されたEstablishment Causeを判定することはできない。また、このような場合にeNBがどのような動作をするかについては、eNBの実装によるが、UEから送信されたRRC Connection Requestを拒否したり、エラーとして検出したりすることが想定される。

このように、eNBが新規なEstablishment Causeに対応していない場合、UEから送信されたRRC Connection Requestを正常に処理できずに、異常終了する問題がある。

そこで、本発明は、このような状況に鑑みてなされたものであり、無線基地局（eNB）が、新規なRRCコネクションの確立理由（Establishment Cause）に対応していない場合でも、RRC Connection Requestを異常終了させずに正常に処理し得る無線基地局及び無線通信方法の提供を目的とする。

本発明の一態様に係る無線基地局は、無線リソース制御レイヤにおけるコネクション要求に基づいて、ユーザ装置とのコネクションを確立する。当該無線基地局は、前記コネクションの確立理由を含む前記コネクション要求を前記ユーザ装置から受信するコネクション要求受信部と、前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由である場合、前記未サポート確立理由と対応付けられた動作に従って前記コネクション要求を処理するコネクション処理部とを備える。

本発明の一態様に係る無線通信方法は、無線リソース制御レイヤにおけるコネクション要求に基づいて、ユーザ装置と無線基地局とのコネクションを確立することに関する。当該無線通信方法は、前記ユーザ装置が、前記コネクションの確立理由を含む前記コネクション要求を前記無線基地局に送信するステップと、前記無線基地局が、前記コネクション要求を前記ユーザ装置から受信するステップと、前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由である場合、前記無線基地局が、前記未サポート確立理由と対応付けられた動作に従って前記コネクション要求を処理するステップとを含む。

上述した無線基地局及び無線通信方法によれば、無線基地局（eNB）が、新規なRRCコネクションの確立理由（Establishment Cause）に対応していない場合でも、RRC Connection Requestを異常終了させずに正常に処理し得る。

図１は、本実施形態に係る無線通信システム10の全体概略構成図である。 図２は、UE100の機能ブロック構成図である。 図３は、eNB200の機能ブロック構成図である。 図４は、RRCコネクションの確立シーケンスを示す図である。 図５は、eNB200によるEstablishment Causeの判定動作フローを示す図である。

以下、実施形態を図面に基づいて説明する。なお、同一の機能や構成には、同一または類似の符号を付して、その説明を適宜省略する。

（１）無線通信システムの全体概略構成
図１は、本実施形態に係る無線通信システム10の全体概略構成図である。無線通信システム10は、Long Term Evolution（LTE）に従った無線通信システムであり、無線アクセスネットワーク20及びユーザ装置100（以下、UE100）を含む。

無線アクセスネットワーク20は、3GPPにおいて規定されるEvolved Universal Terrestrial Radio Access Network（E-UTRAN）であり、無線基地局200（以下、eNB200）、及び移動管理装置300（以下、MME300）を含む。

なお、無線通信システム10は、必ずしもLTE（E-UTRAN）に限定されない。例えば、無線アクセスネットワーク20は、5Gとして規定されるユーザ装置と無線通信を実行する無線基地局を含む無線アクセスネットワークであってもよい。

UE100及びeNB200は、LTEの仕様に従った無線通信を実行する。特に、本実施形態では、UE100及びeNB200は、無線リソース制御レイヤ（RRCレイヤ）におけるコネクションを確立し、確立した当該コネクションを用いて通信を実行する。

また、本実施形態では、UE100は、LTEの最新のリリース（例えば、Rel.13）に対応しているが、eNB200は、最新のリリースには対応しておらず、以前のリリース（例えば、Rel.12）に対応している。なお、以下、リリースに関する記載は、飽くまで一例であり、リリースの番号や、Establishment Causeの名称や内容は、特に限定されない。

UE100は、RRCレイヤにおけるコネクション（RRCコネクション）の確立を要求するRRC Connection Request（コネクション要求）をeNB200に送信する。eNB200は、UE100から受信したRRC Connection Requestに基づいて、UE100との接続、つまり、RRCコネクションの確立を実行する。

RRC Connection Requestには、当該コネクションの確立理由を示すフィールドしてEstablishment Causeが含まれている。Establishment Causeは、言い換えれば、当該コネクションに関する呼種別を示す情報である。

Rel.13以前のリリース（Rel.12以下のリリース）では、Establishment Causeとして、予備のCause、具体的には、spare1及びspare2が規定されている。一方、Rel.13では、当該予備のCauseが、新規なEstablishment Causeと規定（例えば、VoLTEなど）されている。なお、Establishment Causeは、enumerated形式で表現され、例えば、spare1, spare2は、”6”, “7”で表現される。

従って、最新のリリースに対応しているUE100は、Establishment Causeとして、”6”または“7”をeNB200に通知することができる。

eNB200は、受信したRRC Connection Requestに基づいて、RRC Connection SetupをUE100に返送する。UE100は、eNB200から受信したRRC Connection Setupの内容に基づいてRRCコネクションを設定し、RRCコネクションを確立する。UE100は、RRCコネクションの設定が完了すると、RRC Connection Setup CompleteをeNB200に送信する。なお、RRCコネクションの確立手順、及びEstablishment Causeの詳細については、さらに後述する。

MME300は、無線アクセスネットワーク20を構成する複数のeNB200を管理し、UE100のモビリティ制御などを実行する論理的なノード（装置）である。つまり、MME300は、UE100の移動性を管理する。

（２）無線通信システムの機能ブロック構成
次に、無線通信システム10の機能ブロック構成について説明する。具体的には、UE100及びeNB200の機能ブロック構成について説明する。

（２．１）UE100
図２は、UE100の機能ブロック構成図である。図２に示すように、UE100は、呼処理部110、コネクション要求送信部120及びコネクション設定部130を備える。

なお、図２に示すように、UE100の各機能ブロックは、無線通信モジュール、プロセッサ（メモリを含む）、機能モジュール（外部接続IF、位置検出、各種測定など）、及び電源（バッテリ含む）などのハードウェア要素によって実現される。

呼処理部110は、UE100のユーザの操作に基づいて生起される呼（音声通信など）や、UE100に実装されるアプリケーションによって生起される呼（データ通信など）を処理する。

具体的には、呼処理部110は、生起された呼種別をコネクション要求送信部120に通知するとともに、当該呼種別に応じたRRCコネクションの設定をコネクション要求送信部120に要求する。

コネクション要求送信部120は、呼処理部110からの要求に基づいて、eNB200とのコネクションの設定を要求するコネクション要求をeNB200に送信する。具体的には、コネクション要求送信部120は、RRC Connection RequestをeNB200に送信する。

なお、上述したように、RRC Connection Requestには、Establishment Causeが含まれる。

コネクション設定部130は、eNB200とのコネクションを設定する。具体的には、コネクション設定部130は、eNB200からRRC Connection Setupを受信する。コネクション設定部130は、RRC Connection Setupの内容に基づいてRRCコネクションを設定し、RRCコネクションを確立する。

また、コネクション設定部130は、RRCコネクションの設定が完了したことを示すRRC Connection Setup CompleteをeNB200に送信する。

（２．２）eNB200
図３は、eNB200の機能ブロック構成図である。図３に示すように、eNB200は、コネクション要求受信部210、判定部220及びコネクション処理部230を備える。

なお、図３に示すように、eNB200の各機能ブロックは、無線通信モジュール、プロセッサ（メモリを含む）、機能モジュール（ネットワークIFなど）及び電源などのハードウェア要素によって実現される。

コネクション要求受信部210は、UE100によって送信されたコネクション要求を受信する。具体的には、コネクション要求受信部210は、RRCコネクションのEstablishment Cause（確立理由）を含むRRC Connection RequestをUE100から受信する。

判定部220は、コネクション要求受信部210が受信したRRC Connection Requestに含まれるEstablishment Causeを判定する。具体的には、判定部220は、Establishment Causeが、以下の何れであるかを判定する。

・emergency
・highPriorityAccess
・mt-Access
・mo-Signalling
・mo-Data
・delayTolerantAccess-v1020
・spare2
・spare1
具体的には、上述したEstablishment Causeは、特定の数値（0〜7）に対応付けられている。特に、判定部220は、Establishment Causeがspare1またはspare2であった場合、当該Establishment CauseがeNB200においてサポートしていないCause（未サポート確立理由）であると判定する。未サポート確立理由は、未知の確立理由（Unknown Establishment Cause）と表現されてもよい。

コネクション処理部230は、コネクション要求受信部210が受信したRRC Connection Requestに基づいて、UE100とのRRCコネクションの設定に関する処理を実行する。

具体的には、コネクション処理部230は、判定部220によって判定されたEstablishment Causeと対応付けられた動作に従ってRRC Connection Requestを処理する。例えば、コネクション処理部230は、Establishment Causeがemergency（緊急呼）であった場合、他のEstablishment Causeよりも優先してRRCコネクションを設定することができる。また、無線アクセスネットワーク20が輻輳している場合には、コネクション処理部230は、特定のEstablishment Cause（例えば、mo-Data）によるRRC Connection Requestを拒否することもできる。

さらに、コネクション処理部230は、RRC Connection Requestに含まれるEstablishment Causeが、eNB200においてサポートしていない未サポート確立理由（spare1, spare2）である場合、当該未サポート確立理由と対応付けられた動作、つまり、ポリシーに従ってRRC Connection Requestを処理する。

例えば、コネクション処理部230は、Establishment Causeがspare2であった場合、”spare2”と対応付けられているmo-Dataの動作に従ってRRC Connection Requestを処理する。勿論、mo-Dataではなく、例えば、さらに優先度が低いEstablishment Causeと対応付けられた動作に従ってRRC Connection Requestを処理してもよい。

すなわち、コネクション処理部230は、RRC Connection Requestに含まれるEstablishment Causeが未サポート確立理由である場合、eNB200においてサポートしているEstablishment Causeの何れかと対応付けられた動作に従ってRRC Connection Requestを処理することができる。

本実施形態では、コネクション処理部230は、RRC Connection Requestに含まれるEstablishment Causeが未サポート確立理由（例えば、spare2）である場合、当該未サポート確立理由を、eNB200においてサポートしている所定のEstablishment Cause（例えば、mo-Data）に変換する。

具体的には、コネクション処理部230は、未サポート確立理由と対応付けられている数値（例えば、”7”）を、eNB200においてサポートしているEstablishment Cause（例えば、”4”）に変換する。コネクション処理部230は、変換後のEstablishment Causeと対応付けられた動作に従ってRRC Connection Requestを処理する。

このようなコネクション処理部230の動作によって、未サポート確立理由（spare1, spare2）を受信した場合でも、Establishment Causeがmo-Dataに変換されるため、一般呼の発信と見なした接続処理が可能となる。

また、コネクション処理部230は、変換後のEstablishment Causeを含むメッセージ（S1メッセージ）をMME300に送信することができる。

（３）無線通信システムの動作
次に、無線通信システム10の動作について説明する。具体的には、RRCコネクションの確立シーケンス、及びeNB200によるEstablishment Causeの判定動作について説明する。

（３．１）RRCコネクションの確立シーケンス
図４は、RRCコネクションの確立シーケンスを示す。図４に示すように、UE100は、UE100のユーザの操作、またはUE100に実装されるアプリケーションからの要求に怖じて、RRC Connection RequestをeNB200に送信する（S10）。

eNB200は、UE100によって送信されたRRC Connection Requestに含まれるEstablishment Causeを判定する（S20）。なお、Establishment Causeの判定動作については、さらに後述する。

eNB200は、受信したRRC Connection Requestに基づいて、RRC Connection Setupを送信する（S30）。

UE100は、受信したRRC Connection Setupの内容に基づいてRRCコネクションを設定し、RRCコネクションを確立する。UE100は、RRCコネクションの設定が完了すると、RRC Connection Setup CompleteをeNB200に送信する（S40）。

また、eNB200は、判定したEstablishment Cause、または未サポート確立理由であったために他のEstablishment Causeに変換したEstablishment Causeを含むS1メッセージをMME300に送信する（S50）。

具体的には、eNB200は、当該Establishment Causeを含むInitial UE messageをMME300に送信する。

（３．２）eNB200によるEstablishment Causeの判定動作
図５は、eNB200によるEstablishment Causeの判定動作フローを示す。具体的には、図５は、図４に示したS20における具体的な動作を含むeNB200の動作フローを示す。

図５に示すように、eNB200は、UE100からRRC Connection Requestを受信する（S210）。

eNB200は、受信したRRC Connection Requestに含まれるEstablishment Causeが、新規なEstablishment Causeか否かを判定する（S220）。ここで、新規なEstablishment Causeとは、具体的には、上述した未サポート確立理由を意味する。すなわち、最新リリースに対応していないeNB200は、RRC Connection Requestに含まれるEstablishment Causeがspare1またspare2である場合、新規なEstablishment Causeであると判定する。

新規なEstablishment Causeと判定した場合、eNB200は、当該新規なEstablishment Cause（未サポート確立理由）と対応付けられた動作、具体的には接続処理を実行する（S230）。例えば、上述したように、eNB200は、Establishment Causeがspare2であった場合、”spare2”と対応付けられているmo-Dataの動作に従ってRRC Connection Requestを処理する。

一方、新規なEstablishment Causeでないと判定した場合、つまり、eNB200がサポートしている既存のEstablishment Causeと判定した場合、eNB200は、当該Establishment Cause（未サポート確立理由）と対応付けられた接続処理を実行する（S240）。
（４）作用・効果
上述した実施形態によれば、以下の作用効果が得られる。eNB200（コネクション処理部230）は、RRC Connection Requestに含まれるEstablishment Causeが、eNB200においてサポートしていない未サポート確立理由（spare1, spare2）である場合、当該未サポート確立理由と対応付けられた動作、つまり、ポリシーに従ってRRC Connection Requestを処理する。

より具体的には、eNB200は、RRC Connection Requestに含まれるEstablishment Causeが未サポート確立理由である場合、eNB200においてサポートしているEstablishment Causeの何れかと対応付けられた動作に従ってRRC Connection Requestを処理する。

これにより、UE100が、新規なEstablishment Causeが規定された最新リリース（Rel.13）に対応し、eNB200が最新リリースに対応していないような場合でも、当該呼用のRRC Connection Requestを異常終了させずに正常に処理することができる。

さらに、このようにeNB200が動作するため、無線通信システム10において複数のリリースに対応する装置（UE100及びeNB200）が混在する場合でも、バックワードコンパチビリティを確保することができる。

また、このようなバックワードコンパチビリティを確保するために、UE100の改修は特に必要ないため、改修に伴うUEなどへのインパクトを抑えつつ、バックワードコンパチビリティを確保することができる。

本実施形態では、eNB200は、RRC Connection Requestに含まれるEstablishment Causeが未サポート確立理由（例えば、spare2）である場合、当該未サポート確立理由を、eNB200においてサポートしている所定のEstablishment Cause（例えば、mo-Data）に変換する。このため、既存のEstablishment Causeと対応付けられている動作を踏襲しつつ、未サポート確立理由を含むRRC Connection Requestを正常に処理することができる。

本実施形態では、eNB200は、変換後のEstablishment Causeを含むメッセージ（S1メッセージ）をMME300に送信することができる。このため、MME300は、eNB200がどのような確立理由（呼種別）として当該RRCコネクションを取り扱ったかを速やかに認識することができる。

（５）その他の実施形態
以上、実施形態に沿って本発明の内容を説明したが、本発明はこれらの記載に限定されるものではなく、種々の変形及び改良が可能であることは、当業者には自明である。

例えば、上述した実施形態では、eNB200は、RRC Connection Requestに含まれるEstablishment Causeが未サポート確立理由である場合、eNB200においてサポートしているEstablishment Causeの何れかと対応付けられた動作に従ってRRC Connection Requestを処理していたが、当該動作は、無線アクセスネットワーク20の状況（負荷など）に応じて変更するようにしてもよい。また、当該変更は、無線アクセスネットワーク20の状況に応じて動的に行われてもよい。

例えば、無線アクセスネットワーク20の混雑時やアクセスクラス規制の発動時には、Establishment Causeが未サポート確立理由である場合、RRC Connection Requestを拒否し、当該RRC Connection Requestに係る呼を生起したUE100を速やかにアイドル状態に遷移させるようにしてもよい。

このように、eNB200は、RRC Connection Requestに含まれるEstablishment Causeが未サポート確立理由である場合、eNB200の実装（インプリメンテーション）に基づいて、当該Establishment Causeを含むRRC Connection Requestを受け付けることができる。

また、上述した実施形態では、RRC Connection Requestに含まれるEstablishment Causeを対象として説明したが、本発明は、必ずしもRRC Connection Requestに限定されるものではなく、無線リソースの制御に関するレイヤにおける接続要求であれば、RRC Connection Request以外のメッセージに含まれるEstablishment Cause（確立理由）に適用することも可能である。

また、本発明は、以下のように表現されてもよい。本発明の一態様は、無線リソース制御レイヤにおけるコネクション要求（RRC Connection Request）に基づいて、ユーザ装置（UE100）とのコネクション（RRCコネクション）を確立する無線基地局（eNB200）であって、前記コネクションの確立理由を含む前記コネクション要求を前記ユーザ装置から受信するコネクション要求受信部（コネクション要求受信部210）と、前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由（例えば、spare2）である場合、前記未サポート確立理由と対応付けられた動作に従って前記コネクション要求を処理するコネクション処理部（コネクション処理部230）とを備える。

本発明の一態様において、前記コネクション処理部は、前記コネクション要求に含まれる前記確立理由が前記未サポート確立理由である場合、前記無線基地局においてサポートしている前記確立理由の何れかと対応付けられた動作に従って前記コネクション要求を処理してもよい。

本発明の一態様において、前記コネクション処理部は、前記コネクション要求に含まれる前記確立理由が前記未サポート確立理由である場合、前記未サポート確立理由を、前記無線基地局においてサポートしている所定の前記確立理由に変換し、変換後の前記確立理由と対応付けられた動作に従って前記コネクション要求を処理してもよい。

本発明の一態様において、前記コネクション処理部は、変換後の前記確立理由を含むメッセージを、前記ユーザ装置の移動性を管理する移動管理装置に送信してもよい。

本発明の一態様は、無線リソース制御レイヤにおけるコネクション要求に基づいて、ユーザ装置と無線基地局とのコネクションを確立する無線通信方法であって、前記ユーザ装置が、前記コネクションの確立理由を含む前記コネクション要求を前記無線基地局に送信するステップと、前記無線基地局が、前記コネクション要求を前記ユーザ装置から受信するステップと、前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由である場合、前記無線基地局が、前記未サポート確立理由と対応付けられた動作に従って前記コネクション要求を処理するステップとを含む。

上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

10 無線通信システム
20 無線アクセスネットワーク
100 UE
110 呼処理部
120 コネクション要求送信部
130 コネクション設定部
200 eNB
210 コネクション要求受信部
220 判定部
230 コネクション処理部
300 MME

Claims (5)

1. 無線リソース制御レイヤにおけるコネクション要求に基づいて、ユーザ装置とのコネクションを確立する無線基地局であって、
   前記コネクションの確立理由を含む前記コネクション要求を前記ユーザ装置から受信するコネクション要求受信部と、
   前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由である場合、前記未サポート確立理由と対応付けられた動作に従って前記コネクション要求を処理するコネクション処理部と
   を備える無線基地局。
2. 前記コネクション処理部は、前記コネクション要求に含まれる前記確立理由が前記未サポート確立理由である場合、前記無線基地局においてサポートしている前記確立理由の何れかと対応付けられた動作に従って前記コネクション要求を処理する請求項１に記載の無線基地局。
3. 前記コネクション処理部は、前記コネクション要求に含まれる前記確立理由が前記未サポート確立理由である場合、前記未サポート確立理由を、前記無線基地局においてサポートしている所定の前記確立理由に変換し、変換後の前記確立理由と対応付けられた動作に従って前記コネクション要求を処理する請求項１に記載の無線基地局。
4. 前記コネクション処理部は、変換後の前記確立理由を含むメッセージを、前記ユーザ装置の移動性を管理する移動管理装置に送信する請求項３に記載の無線基地局。
5. 無線リソース制御レイヤにおけるコネクション要求に基づいて、ユーザ装置と無線基地局とのコネクションを確立する無線通信方法であって、
   前記ユーザ装置が、前記コネクションの確立理由を含む前記コネクション要求を前記無線基地局に送信するステップと、
   前記無線基地局が、前記コネクション要求を前記ユーザ装置から受信するステップと、
   前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由である場合、前記無線基地局が、前記未サポート確立理由と対応付けられた動作に従って前記コネクション要求を処理するステップと
   を含む無線通信方法。

Images