JP7074806B2 - 通信システム、通信端末および基地局 - Google Patents

通信システム、通信端末および基地局 Download PDF

Info

Publication number
JP7074806B2
JP7074806B2 JP2020113959A JP2020113959A JP7074806B2 JP 7074806 B2 JP7074806 B2 JP 7074806B2 JP 2020113959 A JP2020113959 A JP 2020113959A JP 2020113959 A JP2020113959 A JP 2020113959A JP 7074806 B2 JP7074806 B2 JP 7074806B2
Authority
JP
Japan
Prior art keywords
menb
senb
cell
data
bearer
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
JP2020113959A
Other languages
English (en)
Other versions
JP2020162180A (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.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric 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 Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Publication of JP2020162180A publication Critical patent/JP2020162180A/ja
Priority to JP2022078625A priority Critical patent/JP2022106987A/ja
Application granted granted Critical
Publication of JP7074806B2 publication Critical patent/JP7074806B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0055Transmission or use of information for re-establishing the radio link
    • H04W36/0069Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink
    • H04W36/00695Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink using split of the control plane or user plane
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/08Reselecting an access point
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W16/00Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24Cell structures
    • H04W16/32Hierarchical cell structures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0055Transmission or use of information for re-establishing the radio link
    • H04W36/0069Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/08Reselecting an access point
    • H04W36/087Reselecting an access point between radio units of access points
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/24Reselection being triggered by specific parameters
    • H04W36/26Reselection being triggered by specific parameters by agreed or negotiated communication parameters
    • H04W36/28Reselection being triggered by specific parameters by agreed or negotiated communication parameters involving a plurality of connections, e.g. multi-call or multi-bearer connections
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks

Landscapes

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

Description

本開示は、無線通信技術に関する。
移動体通信システムの規格化団体である3GPP(3rd Generation Partnership Project)において、無線区間についてはロングタームエボリューション(Long Term Evolution:LTE)と称し、コアネットワークおよび無線アクセスネットワーク(以下、まとめて、ネットワークとも称する)を含めたシステム全体構成については、システムアーキテクチャエボリューション(System Architecture Evolution:SAE)と称される新たな通信方式が検討されている(例えば、非特許文献1~10参照)。この通信方式は3.9G(3.9 Generation)システムとも呼ばれる。
LTEのアクセス方式としては、下り方向はOFDM(Orthogonal Frequency Division Multiplexing)、上り方向はSC-FDMA(Single Carrier Frequency Division Multiple Access)が用いられる。また、LTEは、W-CDMA(Wideband Code division Multiple Access)とは異なり、回線交換を含まず、パケット通信方式のみになる。
非特許文献1(5章)に記載される、3GPPでの、LTEシステムにおけるフレーム構成に関する決定事項について、図1を用いて説明する。図1は、LTE方式の通信システムで使用される無線フレームの構成を示す説明図である。図1において、1つの無線フレーム(Radio frame)は10msである。無線フレームは10個の等しい大きさのサブフレーム(Subframe)に分割される。サブフレームは、2個の等しい大きさのスロット(slot)に分割される。無線フレーム毎に1番目および6番目のサブフレームに下り同期信号(Downlink Synchronization Signal:SS)が含まれる。同期信号には、第一同期信号(Primary Synchronization Signal:P-SS)と、第二同期信号(Secondary Synchronization Signal:S-SS)とがある。
3GPPでの、LTEシステムにおけるチャネル構成に関する決定事項が、非特許文献1(5章)に記載されている。CSG(Closed Subscriber Group)セルにおいてもnon-CSGセルと同じチャネル構成が用いられると想定されている。
物理報知チャネル(Physical Broadcast channel:PBCH)は、基地局から移動端末への下り送信用のチャネルである。BCHトランスポートブロック(transport block)は、40ms間隔中の4個のサブフレームにマッピングされる。40msタイミングの明白なシグナリングはない。
物理制御フォーマットインジケータチャネル(Physical Control Format Indicator Channel:PCFICH)は、基地局から移動端末への下り送信用のチャネルである。PCFICHは、PDCCHsのために用いるOFDM(Orthogonal Frequency Division Multiplexing)シンボルの数を、基地局から移動端末へ通知する。PCFICHは、サブフレーム毎に送信される。
物理下り制御チャネル(Physical Downlink Control Channel:PDCCH)は、基地局から移動端末への下り送信用のチャネルである。PDCCHは、後述のトランスポートチャネルの1つである下り共有チャネル(Downlink Shared Channel:DL-SCH)のリソース割り当て(allocation)情報、後述のトランスポートチャネルの1つであるページングチャネル(Paging Channel:PCH)のリソース割り当て(allocation)情報、DL-SCHに関するHARQ(Hybrid Automatic Repeat reQuest)情報を通知する。PDCCHは、上りスケジューリンググラント(Uplink Scheduling Grant)を運ぶ。PDCCHは、上り送信に対する応答信号であるAck(Acknowledgement)/Nack(Negative Acknowledgement)を運ぶ。PDCCHは、L1/L2制御信号とも呼ばれる。
物理下り共有チャネル(Physical Downlink Shared Channel:PDSCH)は、基地局から移動端末への下り送信用のチャネルである。PDSCHには、トランスポートチャネルである下り共有チャネル(DL-SCH)、およびトランスポートチャネルであるPCHがマッピングされている。
物理マルチキャストチャネル(Physical Multicast Channel:PMCH)は、基地局から移動端末への下り送信用のチャネルである。PMCHには、トランスポートチャネルであるマルチキャストチャネル(Multicast Channel:MCH)がマッピングされている。
物理上り制御チャネル(Physical Uplink Control Channel:PUCCH)は、移動端末から基地局への上り送信用のチャネルである。PUCCHは、下り送信に対する応答信号(response signal)であるAck/Nackを運ぶ。PUCCHは、CQI(Channel Quality Indicator)レポートを運ぶ。CQIとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またPUCCHは、スケジューリングリクエスト(Scheduling Request:SR)を運ぶ。
物理上り共有チャネル(Physical Uplink Shared Channel:PUSCH)は、移動端末から基地局への上り送信用のチャネルである。PUSCHには、トランスポートチャネルの1つである上り共有チャネル(Uplink Shared Channel:UL-SCH)がマッピングされている。
物理HARQインジケータチャネル(Physical Hybrid ARQ Indicator Channel:PHICH)は、基地局から移動端末への下り送信用のチャネルである。PHICHは、上り送信に対する応答信号であるAck/Nackを運ぶ。物理ランダムアクセスチャネル(Physical Random Access Channel:PRACH)は、移動端末から基地局への上り送信用のチャネルである。PRACHは、ランダムアクセスプリアンブル(random access preamble)を運ぶ。
下り参照信号(リファレンスシグナル(Reference Signal):RS)は、LTE方式の通信システムとして既知のシンボルである。以下の5種類の下りリファレンスシグナルが定義されている。セル固有参照信号(Cell-specific Reference Signals:CRSs)、MBSFN参照信号(MBSFN reference signals)、UE固有参照信号(UE-specific reference signals)であるデータ復調用参照信号(Demodulation Reference Signals:DM-RSs)、位置決定参照信号(Positioning Reference Signals:PRSs)、チャネル情報参照信号(Channel-State Information Reference Signals:CSI-RSs)。移動端末の物理レイヤの測定として、リファレンスシグナルの受信電力(Reference Signal Received Power:RSRP)測定がある。
非特許文献1(5章)に記載されるトランスポートチャネル(Transport channel)について、説明する。下りトランスポートチャネルのうち、報知チャネル(Broadcast Channel:BCH)は、その基地局(セル)のカバレッジ全体に報知される。BCHは、物理報知チャネル(PBCH)にマッピングされる。
下り共有チャネル(Downlink Shared Channel:DL-SCH)には、HARQ(Hybrid ARQ)による再送制御が適用される。DL-SCHは、基地局(セル)のカバレッジ全体への報知が可能である。DL-SCHは、ダイナミックあるいは準静的(Semi-static)なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング(Persistent Scheduling)ともいわれる。DL-SCHは、移動端末の低消費電力化のために移動端末の間欠受信(Discontinuous reception:DRX)をサポートする。DL-SCHは、物理下り共有チャネル(PDSCH)へマッピングされる。
ページングチャネル(Paging Channel:PCH)は、移動端末の低消費電力を可能とするために移動端末のDRXをサポートする。PCHは、基地局(セル)のカバレッジ全体への報知が要求される。PCHは、動的にトラフィックに利用できる物理下り共有チャネル(PDSCH)のような物理リソースへマッピングされる。
マルチキャストチャネル(Multicast Channel:MCH)は、基地局(セル)のカバレッジ全体への報知に使用される。MCHは、マルチセル送信におけるMBMS(Multimedia Broadcast Multicast Service)サービス(MTCHとMCCH)のSFN合成をサポートする。MCHは、準静的なリソース割り当てをサポートする。MCHは、PMCHへマッピングされる。
上りトランスポートチャネルのうち、上り共有チャネル(Uplink Shared Channel:UL-SCH)には、HARQ(Hybrid ARQ)による再送制御が適用される。UL-SCHは、ダイナミックあるいは準静的(Semi-static)なリソース割り当てをサポートする。UL-SCHは、物理上り共有チャネル(PUSCH)へマッピングされる。
ランダムアクセスチャネル(Random Access Channel:RACH)は、制御情報に限られている。RACHは、衝突のリスクがある。RACHは、物理ランダムアクセスチャネル(PRACH)へマッピングされる。
HARQについて説明する。HARQとは、自動再送要求(Automatic Repeat reQuest:ARQ)と誤り訂正(Forward Error Correction)との組合せによって、伝送路の通信品質を向上させる技術である。HARQには、通信品質が変化する伝送路に対しても、再送によって誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。
再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればCRC(Cyclic Redundancy Check)エラーが発生した場合(CRC=NG)、受信側から送信側へ「Nack」を送信する。「Nack」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればCRCエラーが発生しない場合(CRC=OK)、受信側から送信側へ「Ack」を送信する。「Ack」を受信した送信側は次のデータを送信する。
非特許文献1(6章)に記載される論理チャネル(ロジカルチャネル:Logical channel)について、説明する。報知制御チャネル(Broadcast Control Channel:BCCH)は、報知システム制御情報のための下りチャネルである。論理チャネルであるBCCHは、トランスポートチャネルである報知チャネル(BCH)、あるいは下り共有チャネル(DL-SCH)へマッピングされる。
ページング制御チャネル(Paging Control Channel:PCCH)は、ページング情報(Paging Information)およびシステム情報(System Information)の変更を送信するための下りチャネルである。PCCHは、移動端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるPCCHは、トランスポートチャネルであるページングチャネル(PCH)へマッピングされる。
共有制御チャネル(Common Control Channel:CCCH)は、移動端末と基地局との間の送信制御情報のためのチャネルである。CCCHは、移動端末がネットワークとの間でRRC接続(connection)を有していない場合に用いられる。下り方向では、CCCHは、トランスポートチャネルである下り共有チャネル(DL-SCH)へマッピングされる。上り方向では、CCCHは、トランスポートチャネルである上り共有チャネル(UL-SCH)へマッピングされる。
マルチキャスト制御チャネル(Multicast Control Channel:MCCH)は、1対多の送信のための下りチャネルである。MCCHは、ネットワークから移動端末への1つあるいはいくつかのMTCH用のMBMS制御情報の送信のために用いられる。MCCHは、MBMS受信中の移動端末のみに用いられる。MCCHは、トランスポートチャネルであるマルチキャストチャネル(MCH)へマッピングされる。
個別制御チャネル(Dedicated Control Channel:DCCH)は、1対1にて、移動端末とネットワークとの間の個別制御情報を送信するチャネルである。DCCHは、移動端末がRRC接続(connection)である場合に用いられる。DCCHは、上りでは上り共有チャネル(UL-SCH)へマッピングされ、下りでは下り共有チャネル(DL-SCH)にマッピングされる。
個別トラフィックチャネル(Dedicated Traffic Channel:DTCH)は、ユーザ情報の送信のための個別移動端末への1対1通信のチャネルである。DTCHは、上りおよび下りともに存在する。DTCHは、上りでは上り共有チャネル(UL-SCH)へマッピングされ、下りでは下り共有チャネル(DL-SCH)へマッピングされる。
マルチキャストトラフィックチャネル(Multicast Traffic channel:MTCH)は、ネットワークから移動端末へのトラフィックデータ送信のための下りチャネルである。MTCHは、MBMS受信中の移動端末のみに用いられるチャネルである。MTCHは、マルチキャストチャネル(MCH)へマッピングされる。
CGIとは、セルグローバル識別子(Cell Global Identifier)のことである。ECGIとは、E-UTRANセルグローバル識別子(E-UTRAN Cell Global Identifier)のことである。LTE、後述のLTE-A(Long Term Evolution Advanced)およびUMTS(Universal Mobile Telecommunication System)において、CSG(Closed Subscriber Group)セルが導入される。
CSG(Closed Subscriber Group)セルとは、利用可能な加入者をオペレータが特定しているセル(以下「特定加入者用セル」という場合がある)である。特定された加入者は、PLMN(Public Land Mobile Network)の1つ以上のセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている1つ以上のセルを「CSGセル(CSG cell(s))」と呼ぶ。ただし、PLMNにはアクセス制限がある。
CSGセルは、固有のCSGアイデンティティ(CSG identity:CSG ID;CSG-ID)を報知し、CSGインジケーション(CSG Indication)にて「TRUE」を報知するPLMNの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのCSG-IDを用いてCSGセルにアクセスする。
CSG-IDは、CSGセルまたはセルによって報知される。LTE方式の通信システムにCSG-IDは複数存在する。そして、CSG-IDは、CSG関連のメンバーのアクセスを容易にするために、移動端末(UE)によって使用される。
移動端末の位置追跡は、1つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても移動端末の位置を追跡し、移動端末を呼び出す、換言すれば移動端末が着呼することを可能にするために行われる。この移動端末の位置追跡のための区域をトラッキングエリアと呼ぶ。
3GPPにおいて、Home-NodeB(Home-NB;HNB)、Home-eNodeB(Home-eNB;HeNB)と称される基地局が検討されている。UTRANにおけるHNB、およびE-UTRANにおけるHeNBは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献3には、HeNBおよびHNBへのアクセスの3つの異なるモードが開示されている。具体的には、オープンアクセスモード(Open access mode)と、クローズドアクセスモード(Closed access mode)と、ハイブリッドアクセスモード(Hybrid access mode)とが開示されている。
各々のモードは、以下のような特徴を有する。オープンアクセスモードでは、HeNBおよびHNBは、通常のオペレータのノーマルセルとして操作される。クローズドアクセスモードでは、HeNBおよびHNBは、CSGセルとして操作される。このCSGセルは、CSGメンバーのみアクセス可能なCSGセルである。ハイブリッドアクセスモードでは、HeNBおよびHNBは、非CSGメンバーも同時にアクセス許可されているCSGセルとして操作される。言い換えれば、ハイブリッドアクセスモードのセル(ハイブリッドセルとも称する)は、オープンアクセスモードとクローズドアクセスモードとの両方をサポートするセルである。
3GPPでは、全ての物理セル識別子(Physical Cell Identity:PCI)のうち、CSGセルで使用するためにネットワークによって予約されたPCI範囲がある(非特許文献1 10.5.1.1章参照)。PCI範囲を分割することをPCIスプリットと称することがある。PCIスプリットに関する情報(PCIスプリット情報とも称する)は、システム情報によって基地局から傘下の移動端末に対して報知される。基地局の傘下とは、該基地局をサービングセルとすることを意味する。
非特許文献4は、PCIスプリットを用いた移動端末の基本動作を開示する。PCIスプリット情報を有していない移動端末は、全PCIを用いて、例えば504コード全てを用いて、セルサーチを行う必要がある。これに対して、PCIスプリット情報を有する移動端末は、当該PCIスプリット情報を用いてセルサーチを行うことが可能である。
また3GPPでは、リリース10として、ロングタームエボリューションアドヴァンスド(Long Term Evolution Advanced:LTE-A)の規格策定が進められている(非特許文献5、非特許文献6参照)。LTE-Aは、LTEの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。
LTE-Aシステムでは、100MHzまでのより広い周波数帯域幅(transmission bandwidths)をサポートするために、二つ以上のコンポーネントキャリア(Component Carrier:CC)を集約する(「アグリゲーション(aggregation)する」とも称する)、キャリアアグリゲーション(Carrier Aggregation:CA)が検討されている。
CAが構成される場合、UEはネットワーク(Network:NW)と唯一つのRRC接続(RRC connection)を有する。RRC接続において、一つのサービングセルがNASモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル(Primary Cell:PCell)と呼ぶ。下りリンクで、PCellに対応するキャリアは、下りプライマリコンポーネントキャリア(Downlink Primary Component Carrier:DL PCC)である。上りリンクで、PCellに対応するキャリアは、上りプライマリコンポーネントキャリア(Uplink Primary Component Carrier:UL PCC)である。
UEの能力(ケーパビリティ(capability))に応じて、セカンダリセル(Secondary Cell:SCell)が、PCellとサービングセルとの組を形成するために構成される。下りリンクで、SCellに対応するキャリアは、下りセカンダリコンポーネントキャリア(Downlink Secondary Component Carrier:DL SCC)である。上りリンクで、SCellに対応するキャリアは、上りセカンダリコンポーネントキャリア(Uplink Secondary Component Carrier:UL SCC)である。
一つのUEに対して、一つのPCellと、一つ以上のSCellからなるサービングセルとの組が構成される。
また、LTE-Aでの新技術としては、より広い帯域をサポートする技術(Wider bandwidth extension)、および多地点協調送受信(Coordinated Multiple Point transmission and reception:CoMP)技術などがある。3GPPでLTE-Aのために検討されているCoMPについては、非特許文献7に記載されている。
モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。LTEおよびLTE-Aが本格的に運用を開始されると、更に通信速度が高速化され、トラフィック量が増加することが見込まれる。
また、スマートフォンおよびタブレット端末の普及によって、セルラー系無線通信によるトラフィック量が爆発的に増加しており、世界中で無線リソースの不足が懸念されている。
トラフィック量の増加の問題に対して、3GPPにおいて、リリース12版の規格書の策定が進められている。リリース12版の規格書では、将来の膨大なトラフィック量に対応するために、スモールeNBを用いることが検討されている。例えば、多数のスモールeNBを設置して、多数のスモールセルを構成することによって、周波数利用効率を高めて、通信容量の増大を図る技術などが検討されている。
その中で、マクロセルとスモールセルとがオーバラップしている場合に、移動端末がマクロセルとスモールセルとの両方に接続する技術として、デュアルコネクティビティ(dual connectivity)が議論されている(非特許文献11参照)。
3GPP TS36.300 V11.7.0 3GPP TS36.304 V11.2.0 3GPP S1-083461 3GPP R2-082899 3GPP TR 36.814 V9.0.0 3GPP TR 36.912 V10.0.0 3GPP TR 36.819 V11.1.0 3GPP TS 36.141 V11.1.0 3GPP R1-134496 3GPP R1-132236 3GPP TR36.842 V0.2.0
前述のように、非特許文献11には、マクロセルとスモールセルとがオーバラップしている場合に、移動端末がマクロセルとスモールセルとの両方に接続する技術として、デュアルコネクティビティ(dual connectivity)が開示されている。
しかし、デュアルコネクティビティ中の移動端末がハンドオーバを行うときの取り扱いについては、非特許文献11には何ら開示されていない。従来のハンドオーバ方法では、移動端末は、1つのセルとのみ接続しており、デュアルコネクティビティにおけるマクロセルとスモールセルとの両方との接続については考慮されていない。
したがって、従来のハンドオーバ方法を何の工夫もなく、デュアルコネクティビティ中の移動端末に適用することは不可能である。
本開示の目的は、デュアルコネクティビティ中の移動端末装置がハンドオーバを行うことができる技術を提供することである。
本開示に係る通信システムは、通信端末と、前記通信端末と無線通信を行うための複数のセルを構成する複数の基地局とを備える通信システムであって、前記複数のセルは、スモールセルである第1セルと、前記第1セルと共に前記通信端末に第1デュアルコネクティビティを提供するマクロセルである第2セルと、前記第1セルと共に前記通信端末に第2デュアルコネクティビティを提供するマクロセルである第3セルとを含み、前記通信端末は、前記第1デュアルコネクティビティから前記第2デュアルコネクティビティへ移行するために前記第2セルから前記第3セルへのハンドオーバを行う間、前記第1セルとの接続を維持し、前記通信端末が前記第2セルから前記第3セルへの前記ハンドオーバを行う間、前記第3セルを構成する前記基地局から前記第2セルを構成する前記基地局への通知と、前記第2セルを構成する前記基地局から前記第1セルを構成する前記基地局への通知とを行うことによって、前記第1セルを用いて構成されているベアラの構成を変更しないことを特徴とする。
本開示に係る通信端末は、通信端末と、前記通信端末と無線通信を行うための複数のセルを構成する複数の基地局とを備える通信システムで用いられる通信端末であって、前記複数のセルは、スモールセルである第1セルと、前記第1セルと共に前記通信端末に第1デュアルコネクティビティを提供するマクロセルである第2セルと、前記第1セルと共に前記通信端末に第2デュアルコネクティビティを提供するマクロセルである第3セルとを含み、前記通信端末は、前記第1デュアルコネクティビティから前記第2デュアルコネクティビティへ移行するために前記第2セルから前記第3セルへのハンドオーバを行う間、前記第1セルとの接続を維持し、前記通信端末が前記第2セルから前記第3セルへの前記ハンドオーバを行う間、前記第3セルを構成する前記基地局から前記第2セルを構成する前記基地局への通知と、前記第2セルを構成する前記基地局から前記第1セルを構成する前記基地局への通知とを行うことによって、前記第1セルを用いて構成されているベアラの構成を変更しないことを特徴とする。
本開示に係る基地局は、通信端末と、前記通信端末と無線通信を行うための複数のセルを構成する複数の基地局とを備える通信システムで用いられる基地局であって、前記複数のセルは、スモールセルである第1セルと、前記第1セルと共に前記通信端末に第1デュアルコネクティビティを提供するマクロセルである第2セルと、前記第1セルと共に前記通信端末に第2デュアルコネクティビティを提供するマクロセルである第3セルとを含み、前記第1セルおよび前記第2セルは前記基地局または他の基地局によって構成され、前記第3セルは前記基地局によって構成され、前記基地局は、前記通信端末が前記第1デュアルコネクティビティから前記第2デュアルコネクティビティへ移行するために前記第2セルから前記第3セルへのハンドオーバを行う場合に、前記第1セルを用いて構成されているベアラの構成を前記第2セルから引き継ぎ可能かを判断し、前記ベアラの前記構成を前記第2セルから引き継ぎ可能と判断した場合、前記ハンドオーバの間、前記通信端末と前記第1セルとの間の接続を維持することを決定し、前記通信端末が前記第2セルから前記第3セルへの前記ハンドオーバを行う間、前記第3セルを構成する前記基地局から前記第2セルを構成する前記基地局への通知と、前記第2セルを構成する前記基地局から前記第1セルを構成する前記基地局への通知とを行うことによって、前記第1セルを用いて構成されている前記ベアラの構成を変更しないことを特徴とする。
本開示によれば、デュアルコネクティビティ中の移動端末装置がハンドオーバを行うことができる。
本開示の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
LTE方式の通信システムで使用される無線フレームの構成を示す説明図である。 3GPPにおいて議論されているLTE方式の通信システム700の全体的な構成を示すブロック図である。 図2に示す移動端末71の構成を示すブロック図である。 図2に示す基地局72の構成を示すブロック図である。 MMEの構成を示すブロック図である。 LTE方式の通信システムにおいて移動端末(UE)が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。 マクロeNBとスモールeNBとが混在する場合のセルの構成の概念を示す図である。 実施の形態1の通信システムにおけるeNBのカバレッジの一例を示す図である。 実施の形態1の通信システムにおけるeNBのカバレッジの一例を示す図である。 実施の形態1の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 図10のステップST908のHO前処理のシーケンスの一例を示す図である。 図10のステップST928のHO処理のシーケンスの一例を示す図である。 図10のステップST949のHO後処理のシーケンスの一例を示す図である。 実施の形態1の変形例1の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 図14のステップST1009のHO前処理のシーケンスの一例を示す図である。 図14のステップST1010のHO後処理のシーケンスの一例を示す図である。 実施の形態2の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態2の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態2の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態3の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態3の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態3の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態4の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態4の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態4の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態5の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態5の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 実施の形態5の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。 図28のステップST2025のEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。 図28のステップST2025のEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。 UEとの間のデータの送受信の状況の一例を示す図である。 実施の形態6の通信システムにおけるEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。 実施の形態6の通信システムにおけるEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。 実施の形態7の通信システムにおけるEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。 実施の形態7の通信システムにおけるEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。
実施の形態1.
図2は、3GPPにおいて議論されているLTE方式の通信システム700の全体的な構成を示すブロック図である。図2について説明する。無線アクセスネットワークは、E-UTRAN(Evolved Universal Terrestrial Radio Access Network)70と称される。通信端末装置である移動端末装置(以下「移動端末(User Equipment:UE)」という)71は、基地局装置(以下「基地局(E-UTRAN NodeB:eNB)」という)72と無線通信可能であり、無線通信で信号の送受信を行う。
移動端末71に対する制御プロトコル、例えばRRC(Radio Resource Control)と、ユーザプレイン、例えばPDCP(Packet Data Convergence Protocol)、RLC(Radio Link Control)、MAC(Medium Access Control)、PHY(Physical layer)とが基地局72で終端するならば、E-UTRANは1つあるいは複数の基地局72によって構成される。
移動端末71と基地局72との間の制御プロトコルRRC(Radio Resource Control)は、報知(Broadcast)、ページング(paging)、RRC接続マネージメント(RRC connection management)などを行う。RRCにおける基地局72と移動端末71との状態として、RRC_IDLEと、RRC_CONNECTEDとがある。
RRC_IDLEでは、PLMN(Public Land Mobile Network)選択、システム情報(System Information:SI)の報知、ページング(paging)、セル再選択(cell re-selection)、モビリティなどが行われる。RRC_CONNECTEDでは、移動端末はRRC接続(connection)を有し、ネットワークとのデータの送受信を行うことができる。またRRC_CONNECTEDでは、ハンドオーバ(Handover:HO)、隣接セル(Neighbour cell)の測定(メジャメント(measurement))などが行われる。
基地局72は、eNB76と、Home-eNB75とに分類される。通信システム700は、複数のeNB76を含むeNB群72-1と、複数のHome-eNB75を含むHome-eNB群72-2とを備える。またコアネットワークであるEPC(Evolved Packet Core)と、無線アクセスネットワークであるE-UTRAN70とで構成されるシステムは、EPS(Evolved Packet System)と称される。コアネットワークであるEPCと、無線アクセスネットワークであるE-UTRAN70とを合わせて、「ネットワーク」という場合がある。
eNB76は、移動管理エンティティ(Mobility Management Entity:MME)、あるいはS-GW(Serving Gateway)、あるいはMMEおよびS-GWを含むMME/S-GW部(以下「MME部」という場合がある)73とS1インタフェースにより接続され、eNB76とMME部73との間で制御情報が通信される。一つのeNB76に対して、複数のMME部73が接続されてもよい。eNB76間は、X2インタフェースにより接続され、eNB76間で制御情報が通信される。
Home-eNB75は、MME部73とS1インタフェースにより接続され、Home-eNB75とMME部73との間で制御情報が通信される。一つのMME部73に対して、複数のHome-eNB75が接続される。あるいは、Home-eNB75は、HeNBGW(Home-eNB GateWay)74を介してMME部73と接続される。Home-eNB75とHeNBGW74とは、S1インタフェースにより接続され、HeNBGW74とMME部73とはS1インタフェースを介して接続される。
一つまたは複数のHome-eNB75が一つのHeNBGW74と接続され、S1インタフェースを通して情報が通信される。HeNBGW74は、一つまたは複数のMME部73と接続され、S1インタフェースを通して情報が通信される。
MME部73およびHeNBGW74は、上位装置、具体的には上位ノードであり、基地局であるeNB76およびHome-eNB75と、移動端末(UE)71との接続を制御する。MME部73は、コアネットワークであるEPCを構成する。基地局72およびHeNBGW74は、E-UTRAN70を構成する。
さらに3GPPでは、以下のような構成が検討されている。Home-eNB75間のX2インタフェースはサポートされる。すなわち、Home-eNB75間は、X2インタフェースにより接続され、Home-eNB75間で制御情報が通信される。MME部73からは、HeNBGW74はHome-eNB75として見える。Home-eNB75からは、HeNBGW74はMME部73として見える。
Home-eNB75が、HeNBGW74を介してMME部73に接続される場合および直接MME部73に接続される場合のいずれの場合も、Home-eNB75とMME部73との間のインタフェースは、S1インタフェースで同じである。
基地局装置72は、1つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、移動端末71と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で移動端末71と無線通信を行う。1つの基地局装置72が複数のセルを構成する場合、1つ1つのセルが、移動端末71と通信可能に構成される。
図3は、図2に示す移動端末71の構成を示すブロック図である。図3に示す移動端末71の送信処理を説明する。まず、プロトコル処理部801からの制御データ、およびアプリケーション部802からのユーザデータが、送信データバッファ部803へ保存される。送信データバッファ部803に保存されたデータは、エンコーダー部804へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部803から変調部805へ直接出力されるデータが存在してもよい。エンコーダー部804でエンコード処理されたデータは、変調部805にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部806へ出力され、無線送信周波数に変換される。その後、アンテナ807から基地局72に送信信号が送信される。
また、移動端末71の受信処理は、以下のように実行される。基地局72からの無線信号がアンテナ807により受信される。受信信号は、周波数変換部806にて無線受信周波数からベースバンド信号に変換され、復調部808において復調処理が行われる。復調後のデータは、デコーダー部809へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部801へ渡され、ユーザデータはアプリケーション部802へ渡される。移動端末71の一連の処理は、制御部810によって制御される。よって制御部810は、図3では省略しているが、各部801~809と接続している。
図4は、図2に示す基地局72の構成を示すブロック図である。図4に示す基地局72の送信処理を説明する。EPC通信部901は、基地局72とEPC(MME部73など)、HeNBGW74などとの間のデータの送受信を行う。他基地局通信部902は、他の基地局との間のデータの送受信を行う。EPC通信部901および他基地局通信部902は、それぞれプロトコル処理部903と情報の受け渡しを行う。プロトコル処理部903からの制御データ、ならびにEPC通信部901および他基地局通信部902からのユーザデータおよび制御データは、送信データバッファ部904へ保存される。
送信データバッファ部904に保存されたデータは、エンコーダー部905へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部904から変調部906へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部906にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部907へ出力され、無線送信周波数に変換される。その後、アンテナ908より一つもしくは複数の移動端末71に対して送信信号が送信される。
また、基地局72の受信処理は以下のように実行される。一つもしくは複数の移動端末71からの無線信号が、アンテナ908により受信される。受信信号は、周波数変換部907にて無線受信周波数からベースバンド信号に変換され、復調部909で復調処理が行われる。復調されたデータは、デコーダー部910へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部903あるいはEPC通信部901、他基地局通信部902へ渡され、ユーザデータはEPC通信部901および他基地局通信部902へ渡される。基地局72の一連の処理は、制御部911によって制御される。よって制御部911は、図4では省略しているが、各部901~910と接続している。
図5は、MMEの構成を示すブロック図である。図5では、前述の図2に示すMME部73に含まれるMME73aの構成を示す。PDN GW通信部1001は、MME73aとPDN GWとの間のデータの送受信を行う。基地局通信部1002は、MME73aと基地局72との間のS1インタフェースによるデータの送受信を行う。PDN GWから受信したデータがユーザデータであった場合、ユーザデータは、PDN GW通信部1001から、ユーザプレイン通信部1003経由で基地局通信部1002に渡され、1つあるいは複数の基地局72へ送信される。基地局72から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部1002から、ユーザプレイン通信部1003経由でPDN GW通信部1001に渡され、PDN GWへ送信される。
PDN GWから受信したデータが制御データであった場合、制御データは、PDN GW通信部1001から制御プレイン制御部1005へ渡される。基地局72から受信したデータが制御データであった場合、制御データは、基地局通信部1002から制御プレイン制御部1005へ渡される。
HeNBGW通信部1004は、HeNBGW74が存在する場合に設けられ、情報種別によって、MME73aとHeNBGW74との間のインタフェース(IF)によるデータの送受信を行う。HeNBGW通信部1004から受信した制御データは、HeNBGW通信部1004から制御プレイン制御部1005へ渡される。制御プレイン制御部1005での処理の結果は、PDN GW通信部1001経由でPDN GWへ送信される。また、制御プレイン制御部1005で処理された結果は、基地局通信部1002経由でS1インタフェースにより1つあるいは複数の基地局72へ送信され、またHeNBGW通信部1004経由で1つあるいは複数のHeNBGW74へ送信される。
制御プレイン制御部1005には、NASセキュリティ部1005-1、SAEベアラコントロール部1005-2、アイドルステート(Idle State)モビリティ管理部1005-3などが含まれ、制御プレインに対する処理全般を行う。NASセキュリティ部1005-1は、NAS(Non-Access Stratum)メッセージのセキュリティなどを行う。SAEベアラコントロール部1005-2は、SAE(System Architecture Evolution)のベアラの管理などを行う。アイドルステートモビリティ管理部1005-3は、待受け状態(アイドルステート(Idle State);LTE-IDLE状態、または、単にアイドルとも称される)のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の1つあるいは複数の移動端末71のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
MME73aは、1つまたは複数の基地局72に対して、ページング信号の分配を行う。また、MME73aは、待受け状態(Idle State)のモビリティ制御(Mobility control)を行う。MME73aは、移動端末が待ち受け状態のとき、および、アクティブ状態(Active State)のときに、トラッキングエリア(Tracking Area)リストの管理を行う。MME73aは、UEが登録されている(registered)追跡領域(トラッキングエリア:Tracking Area)に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。MME73aに接続されるHome-eNB75のCSGの管理およびCSG-IDの管理、そしてホワイトリスト管理は、アイドルステートモビリティ管理部1005-3で行われてもよい。
次に通信システムにおけるセルサーチ方法の一例を示す。図6は、LTE方式の通信システムにおいて移動端末(UE)が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップST1で、周辺の基地局から送信される第一同期信号(P-SS)、および第二同期信号(S-SS)を用いて、スロットタイミング、フレームタイミングの同期をとる。
P-SSとS-SSとを合わせて、同期信号(SS)という。同期信号(SS)には、セル毎に割り当てられたPCIに1対1に対応するシンクロナイゼーションコードが割り当てられている。PCIの数は504通りが検討されている。この504通りのPCIを用いて同期をとるとともに、同期がとれたセルのPCIを検出(特定)する。
次に同期がとれたセルに対して、ステップST2で、基地局からセル毎に送信される参照信号(リファレンスシグナル:RS)であるセル固有参照信号(Cell-specific Reference Signal:CRS)を検出し、RSの受信電力(Reference Signal Received Power:RSRP)の測定を行う。参照信号(RS)には、PCIと1対1に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップST1で特定したPCIから、該セルのRS用のコードを導出することによって、RSを検出し、RSの受信電力を測定することが可能となる。
次にステップST3で、ステップST2までで検出された一つ以上のセルの中から、RSの受信品質が最もよいセル、例えば、RSの受信電力が最も高いセル、つまりベストセルを選択する。
次にステップST4で、ベストセルのPBCHを受信して、報知情報であるBCCHを得る。PBCH上のBCCHには、セル構成情報が含まれるMIB(Master Information Block)がマッピングされる。したがってPBCHを受信してBCCHを得ることで、MIBが得られる。MIBの情報としては、例えば、DL(ダウンリンク)システム帯域幅(送信帯域幅設定(transmission bandwidth configuration:dl-bandwidth)とも呼ばれる)、送信アンテナ数、SFN(System Frame Number)などがある。
次にステップST5で、MIBのセル構成情報をもとに該セルのDL-SCHを受信して、報知情報BCCHの中のSIB(System Information Block)1を得る。SIB1には、該セルへのアクセスに関する情報、セルセレクションに関する情報、他のSIB(SIBk;k≧2の整数)のスケジューリング情報が含まれる。また、SIB1には、トラッキングエリアコード(Tracking Area Code:TAC)が含まれる。
次にステップST6で、移動端末は、ステップST5で受信したSIB1のTACと、移動端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子(Tracking Area Identity:TAI)のTAC部分とを比較する。トラッキングエリアリストは、TAIリスト(TAI list)とも称される。TAIはトラッキングエリアを識別するための識別情報であり、MCC(Mobile Country Code)と、MNC(Mobile Network Code)と、TAC(Tracking Area Code)とによって構成される。MCCは国コードである。MNCはネットワークコードである。TACはトラッキングエリアのコード番号である。
移動端末は、ステップST6で比較した結果、ステップST5で受信したTACがトラッキングエリアリスト内に含まれるTACと同じならば、該セルで待ち受け動作に入る。比較して、ステップST5で受信したTACがトラッキングエリアリスト内に含まれなければ、移動端末は、該セルを通して、MMEなどが含まれるコアネットワーク(Core Network,EPC)へ、TAU(Tracking Area Update)を行うためにトラッキングエリアの変更を要求する。
コアネットワークを構成する装置(以下「コアネットワーク側装置」という場合がある)は、TAU要求信号とともに移動端末から送られてくる該移動端末の識別番号(UE-IDなど)をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、移動端末に更新後のトラッキングエリアリストを送信する。移動端末は、受信したトラッキングエリアリストに基づいて、移動端末が保有するTACリストを書き換える(更新する)。その後、移動端末は、該セルで待ち受け動作に入る。
スマートフォンおよびタブレット端末の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。
従来のセルの構成では、eNBによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のeNBによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。
小セル化された場合、eNBによって構成されるセルは、従来のeNBによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のeNBに比べて、多数の小セル化されたeNBが必要となる。
以下の説明では、従来のeNBによって構成されるセルのように、カバレッジが比較的大きいセルを「マクロセル」といい、マクロセルを構成するeNBを「マクロeNB」という。また、小セル化されたセルのように、カバレッジが比較的小さいセルを「スモールセル」といい、スモールセルを構成するeNBを「スモールeNB」という。
マクロeNBは、例えば、非特許文献8に記載される「ワイドエリア基地局(Wide Area Base Station)」であってもよい。
スモールeNBは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールeNBは、ピコセルを構成するピコeNB、フェムトセルを構成するフェムトeNB、HeNB、RRH(Remote Radio Head)、RRU(Remote Radio Unit)、RRE(Remote Radio Equipment)またはRN(Relay Node)であってもよい。また、スモールeNBは、非特許文献8に記載される「ローカルエリア基地局(Local Area Base Station)」または「ホーム基地局(Home Base Station)」であってもよい。
図7は、マクロeNBとスモールeNBとが混在する場合のセルの構成の概念を示す図である。マクロeNBによって構成されるマクロセルは、比較的広い範囲のカバレッジ1301を有する。スモールeNBによって構成されるスモールセルは、マクロeNBによって構成されるマクロセルのカバレッジ1301に比べて範囲が小さいカバレッジ1302を有する。
複数のeNBが混在する場合、あるeNBによって構成されるセルのカバレッジが、他のeNBによって構成されるセルのカバレッジ内に含まれる場合がある。図7に示すセルの構成では、参照符号「1304」または「1305」で示されるように、スモールeNBによって構成されるスモールセルのカバレッジ1302が、マクロeNBによって構成されるマクロセルのカバレッジ1301内に含まれる場合がある。
また、参照符号「1305」で示されるように、複数、例えば2つのスモールセルのカバレッジ1302が、1つのマクロセルのカバレッジ1301内に含まれる場合もある。移動端末(UE)1303は、例えばスモールセルのカバレッジ1302内に含まれ、スモールセルを介して通信を行う。
また図7に示すセルの構成では、参照符号「1306」で示されるように、マクロeNBによって構成されるマクロセルのカバレッジ1301と、スモールeNBによって構成されるスモールセルのカバレッジ1302とが複雑に重複する場合が生じる。
また、参照符号「1307」で示されるように、マクロeNBによって構成されるマクロセルのカバレッジ1301と、スモールeNBによって構成されるスモールセルのカバレッジ1302とが重複しない場合も生じる。
さらには、参照符号「1308」で示されるように、多数のスモールeNBによって構成される多数のスモールセルのカバレッジ1302が、1つのマクロeNBによって構成される1つのマクロセルのカバレッジ1301内に構成される場合も生じる。
図8および図9は、実施の形態1の通信システムにおけるeNBのカバレッジの一例を示す図である。図8および図9では、デュアルコネクティビティ中のUE57がマクロセル51,53間でHOを行う場合を示す。
以下の説明では、デュアルコネクティビティを行うマクロセルを「マスターセル」といい、マスターセルを構成するeNBを「マスターeNB(略称:MeNB)」という場合がある。また、HO元のMeNBを「ソースMeNB(略称:S-MeNB)」といい、HO先のMeNBを「ターゲットMeNB(略称:T-MeNB)」という場合がある。
また、デュアルコネクティビティを行うスモールセルを「セカンダリセル」といい、セカンダリセルを構成するeNBを「セカンダリeNB(略称:SeNB)」という場合がある。
図8および図9では、S-MeNBを参照符号「51」で示し、S-MeNB51のカバレッジを参照符号「52」で示す。また、T-MeNBを参照符号「53」で示し、T-MeNB53のカバレッジを参照符号「54」で示す。また、SeNBを参照符号「55」で示し、SeNB55のカバレッジを参照符号「56」で示す。
図9では、図8に示すSeNB55に加えて、もう1つのSeNB58が存在する場合を示す。図9では、図8に示すSeNB55を、移動元のSeNB(以下「移動元SeNB」という場合がある)55とし、もう1つのSeNBを、移動先のSeNB(以下「移動先SeNB」という場合がある)58とする。また、図9において、参照符号「56」は移動元SeNB55のカバレッジを示し、参照符号「59」は移動先SeNB58のカバレッジを示す。
本実施の形態では、図8および図9に示すUE57の移動によって、UE57の周辺セルのメジャメントにおいてS-MeNB51の受信品質が劣化し、T-MeNB53の受信品質が改善しているというメジャメント報告が行われる場合について説明する。
図10は、実施の形態1の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図11は、図10のステップST908のHO前処理のシーケンスの一例を示す図である。図12は、図10のステップST928のHO処理のシーケンスの一例を示す図である。図13は、図10のステップST949のHO後処理のシーケンスの一例を示す図である。ここで、ハンドオーバ関連処理とは、ハンドオーバ(HO)に関連する処理をいい、HO前処理、HO処理およびHO後処理を含む。
本実施の形態では、非特許文献11に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢1A(Alternative 1A)の場合(非特許文献11 8.1.1.1参照)において、デュアルコネクティビティ中のUEがマクロセル間のHOを行う方法について開示する。
ユーザプレインアーキテクチャの選択肢1Aでは、S-GWからMeNBを介して通信を行うパス(以下「MeNB経由パス」という場合がある)と、S-GWからスモールセルであるSeNBを介して通信を行うパス(以下「SeNB経由パス」という場合がある)とにおいて、通信が行われる。MeNB経由パスは、ベアラ1を用いるパスであり、例えばステップST902およびステップST903において、パケットデータの通信に用いられる。SeNB経由パスは、ベアラ2を用いるパスであり、例えばステップST904およびステップST905において、パケットデータの通信に用いられる。
MeNBが、デュアルコネクティビティ中のUEに対して、メジャメント制御メッセージを通知する方法を以下に開示する。
図10に示す例では、ステップST901において、S-MeNBは、UEにメジャメント制御(Measurement Control)メッセージを通知する。該メジャメント制御メッセージに、周辺のSeNBのメジャメントを設定してもよい。あるいは、SeNB用の周波数のメジャメントを設定してもよい。また、メジャメントの設定として、MeNBとは別に、SeNB用またはSeNB用の周波数におけるイベント、もしくはイベントのクライテリアを設定してもよい。
設定パラメータとしては、SeNBの識別子、周波数、報告のためのイベント番号、受信品質の閾値、測定期間などがある。受信品質としては、RSRP(Reference Signal Received Power)、RSRQ(Reference Signal Received Quality)などがある。
ステップST901においてメジャメント制御メッセージを受信したUEは、周辺セル(MeNBおよびSeNB)のメジャメントを行う。
ステップST906において、UEは、S-MeNBにメジャメント報告(Measurement Report)メッセージを通知する。ステップST906においてメジャメント報告メッセージを受信したS-MeNBは、ステップST907において、メジャメント報告の結果を用いて、UEをT-MeNBにハンドオーバ(HO)させるか否かを決定する。図10に示す例では、S-MeNBは、ステップST907において、UEをT-MeNBにHOさせることを決定する。
S-MeNBがステップST907においてUEをT-MeNBにHOさせることを決定すると、ステップST908に移行し、ステップST908において、図11に示すHO前処理であるSeNBリリース処理が実行される。
S-MeNBは、具体的には、図10のステップST907において、UEをT-MeNBにHOさせることを決定すると、図11のステップST909に移行する。
ステップST909において、S-MeNBは、SeNBにSeNBリリース要求(SeNB Release Request)メッセージを通知する。ステップST909においてSeNBリリース要求メッセージを受信したSeNBは、ステップST910において、SeNBリリース応答(SeNB Release Response)メッセージをS-MeNBに通知する。
ステップST911において、S-MeNBは、UEに、RRCに関する情報としてRRC接続再構成(RRC Connection Reconfiguration)メッセージを通知する。
ステップST912において、SeNBは、S-MeNBに、PDCPのシーケンス番号(Sequence Number;略称:SN)の状況を伝達するSN状況伝達(SN Status Transfer)を行う。具体的には、SeNBは、S-MeNBに、PDCPのSN情報を通知する。また、ステップST913において、SeNBは、S-MeNBに、送信が完了していないデータを転送するデータ転送(Data Forwarding)を行って、ロスのない通信を確立してもよい。
また、ベアラの種別、サービス品質(Quality of Service;略称:QoS)、接続先のセルのバックホールで発生する遅延時間、転送回数(転送したデータの再転送)に応じて、転送の有無、SNのリオーダリング(reordering)の有無を判断してもよい。例えば、VoIP(Voice over Internet Protocol)などの音声データのようにデータロスが発生しても問題がないサービスについては、転送を行わない、あるいは、リオーダリングを行わない。また、例えば、ハンドオーバ中のハンドオーバで転送データの再転送になるときには転送を行わない。また、例えば、リアルタイム性を要するサービスの場合には、接続先のセルのバックホールで発生する遅延時間が大きいときには転送を行わない。以上のようにすることによって、リソースリリースを速やかに行うことができ、安定した動作を提供することができる。
ステップST914において、S-MeNBは、SeNBから転送されたデータをバッファに記憶する。
ステップST915において、UEは、S-MeNBにRRC接続再構成完了(RRC Connection Reconfiguration Complete)メッセージを通知する。これによって、S-MeNBとUEとの間でRRCの設定および無線同期が完了すると、ステップST916において、UEとS-MeNBとの間で通信が開始されるとともに、ステップST917において、UEとS-GWとの間で通信が開始される。
ステップST918において、S-MeNBは、MMEに、パスの切替えを要求するパススイッチ要求(Path Switch Request)メッセージを通知する。パススイッチ要求メッセージを通知されたMMEは、ステップST919において、S-GWに、ベアラの変更を要求するベアラ変更要求(Modify Bearer Request)メッセージを通知する。
ステップST918、あるいは、ステップST919では、SeNBの変更の有無を示す情報が付与されていてもよい。または、UEのHOによるパススイッチ要求あるいはベアラ変更要求でないことを示す情報が付与されていてもよい。または、HO対象のUEを識別する情報が付与されないことによって、UEのHOによるパススイッチ要求あるいはベアラ変更要求でないことを示すようにしてもよい。
これによって、MME、あるいは、S-GW、あるいは、別途設けている位置登録管理機能部において、通常のHO処理と異なり、UEの位置情報の更新処理、位置情報の更新に伴う無線リソースの管理処理を省くことができる。
ベアラ変更要求メッセージを通知されたS-GWは、ステップST920において、通信に使用していたベアラ2の送信先を、SeNBから、S-MeNBに変更する。また、このとき、S-MeNBのユーザの収容状況を考慮して、S-MeNB経由パス用にベアラを変更してもよい。
ステップST924において、S-GWは、MMEに、ベアラの変更要求に応じたことを表すベアラ変更応答(Modify Bearer Response)メッセージを通知する。ベアラ変更応答メッセージを通知されたMMEは、ステップST925において、S-MeNBに、パスの切替え要求を受諾したことを表すパススイッチ要求受諾応答(Path Switch Request Ack)メッセージを通知する。
このように、S-MeNBは、図10のステップST902、ステップST903、図11のステップST916およびステップST922において、同一のUEに対して、ベアラ1およびベアラ2という2つのベアラを送受信する。
このとき、S-GWは、ステップST921において、SeNBに送信するPDCPにエンドマーカ(End Marker)を付与して転送処理の終了を伝えてもよい。これによって、SeNBは、転送データの終わりを認識することができるので、転送バッファを無駄のないタイミングでリリースすることが可能となる。
また、SeNBは、ステップST923において、エンドマーカを付与してS-MeNBに転送してもよい。これによって、S-MeNBが転送受け付けバッファを無駄のないタイミングでリリースすることが可能となる。
ステップST926において、S-MeNBは、SeNBに、UEコンテキストを解放(リリース)するように指示するUEコンテキスト解放(UE context release)メッセージを通知する。S-MeNBは、ステップST923でエンドマーカを通知された場合は、ステップST926において、SeNBにUEコンテキスト解放メッセージを通知することに加えて、SeNBに、エンドマーカを受けたことを通知する。このようにSeNBにUEコンテキスト解放メッセージ、またはエンドマーカを受けたことを通知することによって、SeNBは、ステップST927において、UEの管理情報をリリースすることができる。
エンドマーカは、ベアラの種別、またはQoSに応じて、エンドマーカの付与の有無を判断されてもよい。VoIPなどの音声データのようにデータロスが発生しても問題がないサービスについては、エンドマーカを付与しなくても、リソースを解放することによって、リソースの管理を速やかに行うことができ、安定した動作を提供することができるという効果を得ることができる。
図8に示すように、UE57が移動して、S-MeNB51のカバレッジ52の境界に近づくと、前述の図10のステップST907において、S-MeNB51が、UE57のメジャメント報告に基づいて、T-MeNB53にHOすると決定する。このとき、通信中のSeNB55のメジャメント値も良好になる。
S-MeNB51は、SeNB55のメジャメント値が良好なときは、HO後もSeNB55のカバレッジ56内にUE57が存在すると判断する。そして、図11のステップST909において、SeNB55に通知するリリース要求メッセージに、リソース保留指示情報、あるいは、リソースを保留できるIDを付与して通知してもよい。
これによって、SeNB55は、設定していたRRCに関する設定または情報、無線同期に関する設定または情報をリリースせず、T-MeNB53にHOした後、T-MeNB53からSeNB55にデュアルコネクティビティの再設定をするときのリソース確保処理、再同期処理を削減することができる。
ステップST927のSeNBによるUEの管理情報のリリース後は、図10のステップST928において、S-MeNBからT-MeNBへのハンドオーバ処理が行われる。これによって、2つのベアラはともに、S-MeNBからT-MeNBに切り替えられる。
ステップST928のハンドオーバ処理は、具体的には、図12に示すようにして実行される。ステップST929において、S-MeNBは、ハンドオーバ要求(Handover Request)メッセージを、HO先であるT-MeNBに通知する。HO要求メッセージには、HOを行うE-RAB(E-UTRAN Radio Access Bearer)情報が含まれる。
ステップST930において、T-MeNBは、収容キャパシティを確認するアドミッション制御を行う。T-MeNBは、アドミッション制御の結果に基づいて、HOを受付可能であると判断すると、ステップST931において、S-MeNBにHO要求受諾応答(Handover Request Ack)メッセージを通知する。
ステップST931のHO要求応答可メッセージを受けて、S-MeNBは、ステップST932において、UEに、モビリティ制御情報を含むRRC接続再構成(RRC Connection Reconfiguration)メッセージを通知する。
ステップST933において、S-MeNBは、T-MeNBに対して、SN状況伝達(SN Status Transfer)を行う。具体的には、S-MeNBは、T-MeNBにPDCPのSN情報を通知する。
ステップST934において、S-MeNBは、T-MeNBに、送信が完了していないデータを転送するデータ転送(Data Forwarding)を行ってもよい。ステップST935において、T-MeNBは、S-MeNBから転送されたデータをバッファに記憶する。
ステップST936において、UEは、無線設定を完了し、T-MeNBに、RRC接続再構成完了(RRC Connection Reconfiguration Complete)メッセージを通知する。このようにして無線設定が完了すると、ステップST937において、UEとT-MeNBとの間で通信が開始されるとともに、ステップST938において、UEとS-GWとの間で通信が開始される。
ステップST939において、T-MeNBは、MMEに、パススイッチ要求(Path Switch Request)メッセージを通知する。パススイッチ要求メッセージを通知されたMMEは、ステップST940において、S-GWに、ベアラ変更要求(Modify Bearer Request)メッセージを通知する。
ステップST939、あるいは、ステップST940では、SeNBの変更の有無を示す情報が付与されていてもよい。または、UEのHOによるパススイッチ要求あるいはベアラ変更要求であることを示す情報が付与されていてもよい。または、HO対象のUEを識別する情報が付与されることによって、UEのHOによるパススイッチ要求あるいはベアラ変更要求であることを示すようにしてもよい。または、従来のパススイッチ要求あるいはベアラ変更要求とすることによって、従来のUEのHOであることを示すようにしてもよい。
これによって、MME、あるいは、S-GW、あるいは、別途設けている位置登録管理機能部において、通常のHO処理として、UEの位置情報の更新処理、位置情報の更新に伴う無線リソース管理処理を行うことができる。
ベアラ変更要求メッセージを通知されたS-GWは、ステップST941において、通信に使用していたベアラ2の送信先を、T-MeNBに変更する。また、このとき、T-MeNBのユーザの収容状況を考慮して、T-MeNB経由パス用にベアラを変更してもよい。
以上によって、ベアラ1とベアラ2とがT-MeNB経由に設定され、ステップST937において、UEとT-MeNBとの間で通信が行われるとともに、ステップST943において、S-GWとT-MeNBとの間で通信が行われる。
ステップST945において、S-GWは、MMEに、ベアラ変更応答(Modify Bearer Response)メッセージを通知する。ベアラ変更応答メッセージを通知されたMMEは、ステップST946において、T-MeNBに、パススイッチ要求受諾応答(Path Switch Request Ack)メッセージを通知する。
S-GWは、ロスのない伝送をするために、ステップST942において、S-MeNBへの最終データにエンドマーカを付与してもよい。これによって、S-MeNBは、転送バッファを無駄のないタイミングでリリースできるようになる。
ステップST944において、S-MeNBは、最終転送データにエンドマーカを付与してもよい。これによって、T-MeNBが、転送受け付けバッファを無駄のないタイミングでリリースすることが可能となる。
ステップST947において、T-MeNBは、S-MeNBに、UEコンテキスト解放(UE context release)メッセージを通知する。S-MeNBは、ステップST944でエンドマーカを通知された場合は、ステップST947において、S-MeNBにUEコンテキスト解放メッセージを通知することに加えて、S-MeNBに、エンドマーカを受けたことを通知する。このようにS-MeNBにUEコンテキスト解放メッセージ、またはエンドマーカを受けたことを通知することによって、S-MeNBは、ステップST948において、UEの管理情報をリリースすることができる。
ステップST948のS-MeNBによるUEの管理情報のリリース後は、図10のステップST949において、HO後処理であるSeNB追加処理が行われる。ステップST949のSeNB追加処理は、具体的には、図13に示すようにして実行される。
図10のステップST928のHO処理によるT-MeNBへの切替え後、T-MeNBは、図13のステップST950において、SeNBに、SeNB追加要求(SeNB Addition Request)メッセージを通知する。
ステップST951において、SeNBは、T-MeNBに、SeNB追加応答(SeNB Addition Response)メッセージを通知する。
ステップST952において、T-MeNBは、UEに、RRCに関する情報として、RRC接続再構成(RRC Connection Reconfiguration)メッセージを通知する。
また、ステップST951でSeNBがSeNB追加要求メッセージへの返信として、SeNB追加要求を受け付けたことを表すSeNB追加応答メッセージを通知したことを受けて、T-MeNBは、ステップST953において、SN状況伝達(SN Status Transfer)として、SeNBにPDCPのSN情報を通知する。
T-MeNBは、ステップST954において、SeNBに、送信が完了していないデータを転送するデータ転送(Data Forwarding)を行って、ロスのない通信を確立してもよい。
T-MeNBは、ベアラの種別、あるいは、QoSに応じて、データ転送の有無、あるいは、SNのリオーダリングの有無を判断してもよい。VoIPなどの音声データのようにデータロスが発生しても問題がないベアラについては、データ転送、またはSNのリオーダリングを省くことによって、リソースリリースを速やかに行い、安定した動作を提供することができるという効果を得ることができる。
ステップST955において、SeNBは、T-MeNBから転送されたデータをバッファに記憶する。
ステップST956において、UEは、無線同期を完了し、T-MeNBに、SeNBとUEとの間のRRC接続の再構成が完了したことを表すRRC接続再構成完了(RRC Connection Reconfiguration Complete)メッセージを通知する。このようにして無線同期が完了すると、ステップST957において、UEとSeNBとの間で通信が開始されるとともに、ステップST958において、UEとS-GWとの間で通信が開始される。
さらに、ステップST959において、SeNBは、無線設定の完了、具体的にはSeNBの追加が完了したことを表すSeNB追加完了メッセージを、T-MeNBに通知する。SeNB追加完了メッセージを通知されたT-MeNBは、ステップST960において、MMEに、パススイッチ要求(Path Switch Request)メッセージを通知する。パススイッチ要求メッセージを通知されたMMEは、ステップST961において、S-GWに、ベアラ変更要求(Modify Bearer Request)メッセージを通知する。
ステップST960、あるいは、ステップST961では、SeNBの変更(追加)の有無を示す情報が付与されていてもよい。または、UEのHOによるパススイッチ要求あるいはベアラ変更要求でないことを示す情報が付与されていてもよい。または、HO対象のUEを識別する情報が付与されないことによって、UEのHOによるパススイッチ要求あるいはベアラ変更要求でないことを示すようにしてもよい。
これによって、MME、あるいは、S-GW、あるいは、別途設けている位置登録管理機能部において、通常のHO処理と異なり、UEの位置情報の更新処理、位置情報の更新に伴う無線リソースの管理処理を省くことができる。
ベアラ変更要求メッセージを通知されたS-GWは、ステップST962において、通信に使用していたベアラ2の送信先を、S-MeNBに変更する。また、このとき、SeNBのユーザの収容状況を考慮して、SeNB経由パス用にベアラを変更してもよい。
ステップST966において、S-GWは、MMEに、ベアラ変更応答(Modify Bearer Response)メッセージを通知する。ベアラ変更応答メッセージを通知されたMMEは、ステップST967において、T-MeNBに、パスの切替完了を表すパススイッチ要求受諾応答(Path Switch Request Ack)メッセージを通知する。以上によって、ベアラ2がSeNB経由に設定され、ステップST957において、UEとSeNBとの間で通信が行われるとともに、ステップST964において、S-GWとSeNBとの間で通信が行われる。ステップST968において、T-MeNBは、UEのベアラ2に対する管理情報をリリースしてもよい。
このとき、S-GWは、ステップST963において、T-MeNBに送信するPDCPにエンドマーカを付与して転送処理の終了を伝えてもよい。これによって、T-MeNBは、転送データの終わりを認識することができるので、転送バッファを無駄のないタイミングでリリースすることが可能となる。
また、T-MeNBは、ステップST965において、エンドマーカを付与してSeNBに転送してもよい。これによって、SeNBが転送バッファを無駄のないタイミングでリリースすることが可能となる。
エンドマーカは、ベアラの種別、またはQoSに応じて、エンドマーカの付与の有無を判断されてもよい。VoIPなどの音声データのようにデータロスが発生しても問題がないサービスについては、エンドマーカを付与しなくても、リソースを解放することによって、リソースの管理を速やかに行うことができ、安定した動作を提供することができるという効果を得ることができる。
前述の図9に示すように、UE57が移動して、S-MeNB51のカバレッジ52の境界に近づき、移動元SeNB55をリリースし、S-MeNB51からT-MeNB53へのHOを実行した後、SeNB58を追加する。このとき、T-MeNB53は、図10のステップST906において通知されるメジャメント報告に加えて、UE57の移動方向情報、あるいは、UE57の移動速度情報、あるいは、周辺SeNBの位置情報(各SeNBのGPS情報、あるいは、各SeNBがどのMeNBに近いかを表す情報)、あるいは、移動先のSeNBのセルサイズ(セルサイズに相当するSeNBの最大送信電力値でもよい)、あるいは、当該UEがSeNBのCSG(Closed Subscriber Group)に含まれるかどうかの情報、あるいは、これらの組合せによって、追加するSeNB58を決定してもよい。UEと記載したが、複数のUEをまとめているモバイルルータであってもよい。これらの判断結果として、HO後に追加するSeNBを指定するSeNB指定情報を、図12のステップST929において通知されるHO要求メッセージに追加してもよい。
例えば、UEが電車に乗っている場合、当該UEのメジャメント情報において、通信中のSeNBに対するメジャメント値が、移動先SeNBより良好であっても、移動先SeNBが通信可能な品質で、位置情報から移動先SeNBがT-MeNBのカバレッジ内であることが分かると、移動先SeNBを追加することによって、デュアルコネクティビティ処理を軽減することができる。すなわち、移動元SeNBを追加後、当該UEが高速で移動することによって、即座に移動元SeNBをリリースして、移動先SeNBを追加することによる処理の増加を防ぐことができる。
また、例えば、移動元SeNBにおいて、CSGで通信しているときに、人体などのシャドーイングで誤って移動先SeNBが一時的に良好であっても、CSGで通信していること、あるいは、移動速度が遅いことによって、移動元SeNBを追加する。これによって、継続して安定した通信を行うことできる。
以上のように本実施の形態では、UEが1つのマクロセルと1つのスモールセルとに接続されて、デュアルコネクティビティを行うとき、UEの移動に伴って、UEが接続されるマクロセルを、移動元のマクロセルであるS-MeNBから、移動先のマクロセルであるT-MeNBに切替えるHO処理の前に、HO前処理が行われ、HO処理の後に、HO後処理が行われる。HO前処理では、スモールセルであるSeNBがリリースされて、SeNBとの接続が解消される。HO後処理では、SeNBが追加されて、SeNBとの接続が再度確立される。
これによって、非特許文献11に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢1Aの場合において、デュアルコネクティビティ中のUEがマクロセル間のHOを実現することができる。
実施の形態1 変形例1.
図14は、実施の形態1の変形例1の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図15は、図14のステップST1009のHO前処理のシーケンスの一例を示す図である。図16は、図14のステップST1010のHO後処理のシーケンスの一例を示す図である。本変形例のハンドオーバ関連処理は、前述の図10~図13に示す実施の形態1のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。
本実施の形態では、非特許文献11に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢3C(Alternative 3C)の場合(非特許文献11 8.1.1.8参照)において、デュアルコネクティビティ中のUEがマクロセル間のHOを行う方法について開示する。
ユーザプレインアーキテクチャの選択肢3Cでは、MeNBによって、MeNBとUEとの間で、直接通信を行うパス(ベアラ1)と、スモールセルを介して通信を行うパスとでベアラ(ベアラ2)が分割されるベアラスプリットが行われる。
ベアラスプリットの場合、1つのEPSベアラに対応するE-RABが、S-MeNBで、2つのパスに分離され、S-GWとUEとの間でデータが通信される。一つはステップST1001において、S-MeNBとUEとの間でデータが直接通信される。もう一つは、ステップST1003およびステップST1004において、S-MeNBとUEとの間でデータがSeNBを介して通信される。
S-MeNBとS-GWとの間は、ステップST1002において、1つのパスでデータが通信される。SeNBとMeNBとの間の通信は、異なるeNB間で行われる。異なるeNB間の通信路の通信品質が悪い場合は、データの欠落などが生じる場合がある。このような問題を解決するために、SeNBとMeNBとの間の通信において、送達確認処理を導入するとよい。例えば、再送処理を導入するとよい。このようにすることによって、SeNBとMeNBとの間の通信におけるデータの欠落を低減することが可能となる。
ベアラスプリットによって、デュアルコネクティビティ中のUEがMeNB間HOを行う場合について説明する。
UEの移動によって、メジャメントによるS-MeNBの受信品質が劣化し、T-MeNBの受信品質が改善し、イベントクライテリアに従ってメジャメント報告を行う場合について説明する。
本実施の形態では、以下のようにしてSeNBリリース処理が行われる。図14のステップST906でUEからメジャメント報告を受信したS-MeNBは、図15のステップST907において、メジャメント報告の結果を用いて、UEをT-MeNBへHOさせることを決定する。
S-MeNBは、UEをT-MeNBへHOさせることを決定すると、ステップST909において、SeNBに、SeNBのリリースを要求するSeNBリリース要求(SeNB Release Request)メッセージを送信する。また、S-MeNBは、ステップST911において、UEに、RRCに関する情報として、RRC接続再設立要求メッセージを送信する。これによって、S-MeNBは、ベアラ2のベアラスプリットをやめて、ステップST916およびステップST917において、直接UEに対してベアラ2を送受信する。
SeNBのリリース後は、図14のステップST928において、S-MeNBからT-MeNBへのハンドオーバ(HO)処理を行う。ステップST928のHO処理は、前述の図12に示すHO処理と同様にして実行される。このHO処理によって、2つのベアラはともに、S-MeNBからT-MeNBに切り替えられる。
T-MeNBへの切替え後、図14のステップST1010のHO後処理が実行される。具体的には、図16のステップST950において、T-MeNBは、SeNBに追加要求メッセージを通知し、ステップST952において、UEに、通信を行うためのRRCに関する情報を通知する。以上によって、ベアラ2をベアラスプリットする。
ベアラスプリットされたベアラ2のうちの一つのベアラは、ステップST1005において、T-MeNBとUEとの間でデータが直接通信されるときに用いられ、もう一つのベアラは、ステップST1007およびステップST1008において、T-MeNBとUEとの間でデータがSeNBを介して通信されるときに用いられる。T-MeNBとS-GWとの間は、ステップST1006において、1つのパスでデータが通信される。このように、ベアラスプリットは、MMEおよびS-GWに、パススイッチ要求を送らずに処理することが可能である。
以上のように本変形例によれば、非特許文献11に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢3Cの場合、すなわちマクロセルとUEとの間、およびスモールセルとUEとの間で、ベアラスプリットされたベアラを用いて通信が行われる場合においても、デュアルコネクティビティ中のUEがマクロセル間のHOを実現することができる。
実施の形態2.
図17~図19は、実施の形態2の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図17と図18とは、境界線BL1で接続されている。図18と図19とは、境界線BL2で接続されている。本実施の形態のハンドオーバ関連処理は、前述の図10~図13に示す実施の形態1のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。
本実施の形態では、非特許文献11に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢1A(Alternative 1A)の場合(非特許文献11 8.1.1.1参照)において、SeNBをリリースしないでHOを行う方法について開示する。
ユーザプレインアーキテクチャの選択肢1Aでは、ステップST902およびステップST903において、ベアラ1を用いて、S-GWからMeNBを介して通信を行うパスと、ステップST904およびステップST905において、ベアラ2を用いて、S-GWからスモールセルを介して通信を行うパスとの2つのパスで通信が行われる。
本実施の形態では、デュアルコネクティビティ中のUEがMeNB間HOを行う場合、SeNBとの接続はリリースされない。すなわち、UEのデュアルコネクティビティを保ったまま、MeNB間のHOが行われる。
MeNBが、デュアルコネクティビティ中のUEに対してメジャメント制御メッセージを通知する方法を以下に開示する。
図17~図19に示す例では、ステップST901において、S-MeNBは、UEにメジャメント制御メッセージを通知する。該メジャメント制御メッセージに、周辺のSeNBのメジャメントを設定してもよい。あるいは、SeNB用の周波数のメジャメントを設定してもよい。また、メジャメントの設定として、MeNBとは別に、SeNB用あるいはSeNB用の周波数におけるイベントあるいはイベントのクライテリアを設定してもよい。
設定パラメータとして、SeNBの識別子、周波数、報告のためのイベント番号、受信品質の閾値、測定期間などがある。受信品質として、RSRP、RSRQなどがある。
ステップST901でメジャメント制御メッセージを受信したUEは、MeNBおよびSeNBのメジャメントを行う。
ここでは、UEの移動によって、メジャメントによるS-MeNBの受信品質が劣化し、T-MeNBの受信品質が改善し、イベントクライテリアに従ってメジャメント報告を行う場合について説明する。
ステップST906において、UEは、S-MeNBに対してメジャメント報告を行う。UEからのメジャメント報告に、デュアルコネクティビティに用いているSeNBの識別子と受信品質を含めてもよい。
ステップST906でUEからメジャメント報告を受信したS-MeNBは、ステップST907において、メジャメント報告の結果を用いて、UEをT-MeNBへHOさせることを決定する。
ステップST1100において、S-MeNBは、T-MeNBに、HO要求メッセージを通知する。このHO要求メッセージに、SeNBに関する情報(以下「SeNB情報」という場合がある)を含めて通知するとよい。SeNB情報として、例えば、SeNBの識別子、UEにおけるSeNBの受信品質などがある。
また、SeNBのベアラに関する情報(以下「ベアラ情報」という場合がある)として、E-RAB識別子などがある。MeNBは、SeNBにベアラが複数設定されている場合は、各ベアラに対する識別子を設けてもよい。各ベアラの識別子とベアラ構成に関する情報を関連させて通知するとよい。また、該SeNBの識別子と該ベアラの識別子とを関連させて通知してもよい。ベアラ毎に設定されるベアラ構成に関する情報として、例えば、QoSパラメータ、具体的には、サービス品質クラス識別子(QoS Class Identifier;略称:QCI)、割当ておよび保持優先度(Allocation and Retention Priority;略称:ARP)、帯域保証サービス品質情報(Guaranteed Bit Rate QoS Information)などがある。
このようにすることによって、ベアラ毎の設定が可能になり、S-MeNBは、T-MeNBに対して、SeNBの使用しているベアラ設定を通知することが可能となる。T-MeNBは、SeNBのベアラ毎のベアラ設定を取得することが可能となり、ベアラ毎の変更が必要か否かの判断が可能となる。ベアラ設定は、SeNBのベアラ情報に関する情報を関連させて通知するとよい。
RRCに関する設定情報として、例えば、RRCコンテキスト(RRC context)がある。RRCコンテキストには、例えば、無線リソースの構成を示すAS(Access Stratum)構成(AS configuration)、無線リソース管理(Radio Resource Management;略称:RRM)情報を示すRRM構成(RRM configuration)などがある。
RRCに関する情報は、MeNBのためのRRCに関する情報およびSeNBのためのRRCに関する情報がある。各RRCに関する情報を識別可能とするとよい。例えば、MeNBのためのRRCコンテキストとSeNBのためのRRCコンテキストとを別々に作成する。あるいは、1つのRRCコンテキストの中に、MeNBのための情報とSeNBのための情報とを別々に作成してもよい。
このようにすることによって、SeNBのためのRRCに関する情報とMeNBのためのRRCに関する情報とを個別に設定可能にし、S-MeNBはT-MeNBに対してMeNBとSeNB、各々のRRCに関する情報を通知することが可能となる。T-MeNBは、S-MeNBとSeNB、各々のRRCに関する情報を取得することが可能となり、T-MeNBは、SeNBのRRCに関する設定の変更が必要か否かの判断が可能となる。
ステップST1101において、T-MeNBは、S-MeNBからHO要求メッセージで受信した情報を用いて、SeNBを変更するか否か判断する。この処理は、T-eNBがSeNBのベアラをS-eNBで設定していた状態で引継ぎが可能かを判断する。例えば、T-eNBで収容可能なS-eNB数に制限があり、その制限によって受け入れが不可能な場合がある。また、デュアルコネクティビティにおけるユーザプレインアーキテクチャの選択肢3Cの場合では、S-MeNBでベアラスプリットされたベアラを収容できるか否かも判断の情報となる。
SeNBの変更を行うと判断された場合は、ステップST1102に移行する。また、SeNBの変更を行うと判断した場合に限らず、HO処理において、T-MeNBがSeNBのリリースを決定した場合に、ステップST1102に移行してもよい。
ステップST1102において、T-MeNBは、前述の図10に示すステップST908のSeNBリリース処理を実行してSeNBをリリースした後、ステップST908のHO処理を実行する。具体的には、T-MeNBは、S-MeNBに、SeNBリリース処理の実行要求を示す情報(以下「SeNBリリース処理実行要求情報」という場合がある)を通知する。T-MeNBからSeNBリリース処理実行要求情報を通知されたS-MeNBは、実施の形態1で開示した方法を適用すればよく、ここでは説明を省略する。
なお、この場合、ステップST1100のS-MeNBからT-MeNBへのHO要求は省略してもよい。T-MeNBは、S-MeNBにSeNBリリース処理実行要求情報を通知した後、ステップST930のアドミッション制御を行うとよい。
T-MeNBからS-MeNBへのSeNBリリース処理実行要求情報の通知を、HO要求受諾応答メッセージを用いて行ってもよい。例えば、アドミッション制御の後のステップST1104におけるHO要求受諾応答メッセージを用いて行ってもよい。HO処理においてSeNBをリリースすると決定したT-MeNBは、MeNB間のみのHOを行うと判断し、それに応じてアドミッション制御を行い、SeNBリリース処理実行要求情報を含めたS-MeNBに対して、HO要求受諾応答メッセージを通知する。MeNBのHOの際はSeNBをリリースするとシステムとして規定している場合は、HO要求受諾応答メッセージがSeNBリリース処理の実行要求を示すとしてもよい。T-MeNBからHO要求受諾応答メッセージを受信したデュアルコネクティビティを行っているS-MeNBは、SeNBのリリース処理を実行する。
T-MeNBからUEへのSeNBリリース処理実行要求情報の通知を、MCI(Mobility Control Information)を含むRRC接続再構成(RRC Connection Reconfiguration)メッセージを用いて通知してもよい。例えば、ステップST1106のMCIを含むRRC接続再構成メッセージを用いてもよい。MeNBのHOの際はSeNBをリリースするとシステムとして規定している場合は、MCIを含むRRC接続再構成メッセージがSeNBリリース処理の実行要求を示すとしてもよい。S-MeNBからMCIを含むRRC接続再構成メッセージを受信したSeNBを構成しているUEは、SeNBのリリース処理を実行する。
T-MeNBは、SeNBを変更しないと判断した場合は、ステップST1103において、SeNBの使用を維持したままHO処理を行うことを決定する。換言すれば、MeNBのみの変更を行う。SeNBの変更をしないと判断した場合は、SeNB使用のベアラ2の変更処理は行わない。
ステップST930において、T-MeNBは、HO要求に対するアドミッション制御を行う。このアドミッション制御は、前述した、SeNBを変更するか否かの判断の前に行われてもよい。あるいは、その判断と併せて行われてもよい。
SeNBの変更を行わないので、MeNBの変更によるアドミッション制御を行う。アドミッション制御において、T-MeNBは、T-MeNBのためのRRCに関する設定を行う。RRCに関する設定として、無線リソースの構成を示すAS構成(AS configuration)、RRM情報を示すRRM構成(RRM configuration)などがある。また、RRC接続再構成メッセージに含まれる情報の設定も行ってもよい。
T-MeNBで用いるUE個別RACHプリアンブル構成は、SeNBで用いるUE個別のRACHプリアンブル構成と別々に設けて設定してもよい。また、T-MeNBで用いるC-RNTI(Cell-Radio Network Temporary Identifier)は、SeNBで用いるC-RNTIと別々に設けて設定してもよい。SeNBがT-MeNB傘下にない他のUEをサポートするような場合に、各UEに個別に設定することができるので、柔軟な制御を可能とする。
あるいは、T-MeNBで用いるUE個別のRACHプリアンブル構成をSeNBで用いるUE個別のRACHプリアンブル構成と同じに設定してもよい。また、T-MeNBで用いるC-RNTIをSeNBで用いるC-RNTIと同じに設定してもよい。SeNBがT-MeNB傘下にない他のUEをサポートしない場合などに、各UE個別に設定する必要が無く、1つの値で制御することができるので、制御が簡易になる。
T-MeNBのためのRRCに関する設定は、UEがT-MeNBとRRC接続再構成を可能とする情報が必要となる。
T-MeNBは、HO要求受入を決定した場合、ステップST1104において、S-MeNBに、HO指示メッセージを含むHO要求受諾応答メッセージを通知する。このHO指示メッセージに、前述のT-MeNBのためのRRCに関する設定情報を含めるとよい。
また、SeNBを用いたベアラ2を維持する場合、T-MeNBは、S-MeNBに、SeNBを用いたベアラ2の構成を維持したままHOが可能であることを通知してもよい。また、SeNBを用いたベアラ2の構成を維持する場合、T-MeNBは、S-MeNBに、SeNBのためのRRCに関する設定を維持したままHOが可能であることを通知してもよい。これらの通知は、HO要求受諾応答メッセージを用いて行うとよい。SeNBを用いないベアラに対するHO要求受諾応答メッセージと一緒に通知してもよい。SeNBを用いないベアラに対するHO要求受諾応答メッセージと別に通知してもよい。
HO要求受諾応答メッセージ、または、HO指示メッセージに、SeNBのRRCに関する設定の変更があるか否かの情報を含めてもよい。S-MeNBは、該情報を取得し、変更があると認識した場合に、さらに、SeNBのRRCに関する設定を取得するようにしてもよい。これによって、変更がない場合の処理を簡略化することが可能となる。
SeNBのRRCに関する設定に変更がない場合、該設定情報をHO指示メッセージに含めなくてもよい。これによって、シグナリングする情報量を削減することが可能となる。
あるいは、SeNBのためのRRCに関する設定情報を、HO指示メッセージに含めてもよい。S-MeNBが、T-MeNBから取得したSeNBのためのRRCに関する設定情報と、自セルが有しているSeNBのためのRRCに関する設定情報とを比較することが可能となり、確実に変更が無いことを検証することが可能となる。
ステップST1104でHO要求受諾応答メッセージを受信したS-MeNBは、T-MeNBへ、デュアルコネクティビティ中のUEに対するSeNBを維持したままのHOであることを認識することができる。
SeNBを維持したままのHOを行うことを認識したS-MeNBは、SeNBに対して、ベアラ2構成の変更の要求を行わない。SeNBのためのRRCに関する設定変更の要求を行わない。
ステップST1105において、T-MeNB、S-MeNBおよびSeNB間で、SeNBへHOが起動されることを示す情報を通知する処理が行われる。たとえば、T-MeNBは、SeNBへHOが起動されることを示す情報を通知する。この通知は、T-MeNBがS-MeNBへHO要求受諾応答メッセージを送信したときに行うとよい。あるいは、T-MeNBからHO要求受諾応答メッセージを受信したS-MeNBが、SeNBへHOを起動することを示す情報を通知してもよい。
図18のステップST1108において、S-MeNBは、PDCPのSN情報、および、送信が完了していないデータをT-MeNBに転送し、ロスのない通信を確立する。
デュアルコネクティビティ中のUEがMeNB間HO中に、SeNB起動によるベアラ2構成の変更は行わないようにしてもよい。HO中にSeNB起動によるベアラ構成の変更があると、S-MeNBからT-MeNBへのMeNB変更時に該処理を行うこととなるので、制御が複雑になり、誤動作の可能性が高くなる。HO時のSeNB起動によるベアラ2の構成の変更は行わないとすることによって、誤動作を低減することが可能となる。
HO中に、SeNB起動によるベアラ2の構成の変更が行われないようにする方法を以下に開示する。
T-MeNBは、SeNBへHOが起動されることを示す情報を通知する。この通知は、T-MeNBがS-MeNBへHO要求受諾応答メッセージを送信したときに行うとよい。あるいは、T-MeNBからHO要求受諾応答メッセージを受信したS-MeNBが、SeNBへHOを起動することを示す情報を通知してもよい。
HOが起動されたことを示す情報を受信したSeNBは、ベアラ2の構成の変更要求を起動しない。該HOが完了するまで起動しないとするとよい。
他の方法として、該HO中は、S-MeNBあるいはT-MeNBは、SeNBからのベアラ2構成変更要求に対してNack(あるいは拒否)をSeNBに通知してもよい。理由情報を含めてもよく、理由として、HO中によることを示す情報を設けて設定するとよい。
SeNBがHO完了を認識する方法を以下に開示する。T-MeNBは、SeNBへHO完了したことを示す情報を通知するとよい。この通知は、HO処理において、T-MeNBがMMEからパススイッチ要求受諾応答メッセージを受信したときに行うとよい。あるいは、後述するMeNBの変更処理完了をHO完了としてもよい。
このようにすることによって、デュアルコネクティビティ中のUEのHO処理中に、SeNB起動の該UEに対するベアラ2構成の変更を行わないようにすることができる。したがって、システムとして誤動作を低減することが可能となる。
他の方法について開示する。前述のSeNBを維持したままのHOを行う場合、S-MeNBは、SeNBに対して、ベアラ2の構成の変更の要求、およびSeNBのためのRRCに関する設定変更の要求を行わないことを開示したが、他の方法として、SeNBを維持したままのHOを行う場合、S-MeNBは、SeNBに対して、SeNBを維持したままのHOであることを通知してもよい。あるいは、ベアラ2構成の変更の要求、SeNBのためのRRCに関する設定変更の要求を行わないことを通知してもよい。前述のHOが起動されることを示す情報とともに通知してもよい。
これによって、SeNBは、HO中に、該HOがSeNBを維持したままのHOを行う場合か否かなどを認識することが可能となる。SeNBを維持したままのHOの場合は、SeNBは、該HO中はSeNB起動の該UEに対するベアラ2の構成の変更を行わないようにすることができる。前述と同様の効果を得ることが可能となる。
HO要求受諾応答メッセージを受信したS-MeNBは、ステップST1106において、UEへ、T-MeNBへHOをさせるために、モビリティ制御情報(Mobility Control Information;略称:MCI)を含むRRC接続再構成(RRC Connection Reconfiguration)メッセージを通知する。また、HO要求受諾応答メッセージを受信したS-MeNBはUEへ、SeNBを用いたベアラの変更が無いことを通知してもよい。
S-MeNBはUEへ、該HO時、ベアラ2を行うE-RAB用のSeNBの変更が無いことを通知する。また、SeNBのためのRRCに関する設定変更が無いことを通知してもよい。該MCIを含むRRC接続再構成メッセージに一緒に含めて通知するとよい。
必要に応じて、S-MeNBは、SeNBのためのRRCに関する設定情報を認識している場合は、該設定情報をUEに通知してもよい。UEは、自UEが接続しているSeNBに対するRRCに関する設定情報と、受信した該設定情報とを比較することが可能となり、確実に変更が無いことを検証することが可能となる。
ステップST1106において、MCIを含むRRC接続再構成メッセージを受信したUEは、SeNBとの同期および接続を維持したまま、S-MeNBからT-MeNBへのHOを行う。UEは、SeNBとの無線リソースを維持したままHOを行う。この状態においてUEは、SeNBとの通信が可能である。
UEからSeNBへの上りデータの取扱い方法について、以下に開示する。UEは、SeNBと接続を維持したままHOを行う場合、ベアラ2の上りデータの送信を維持することができる。または、S―MeNBからT-MeNBへのHOが完了するまで、UEは、HO中は上りデータの送信を停止し、バッファに記憶することもできる。このようにすることによって、制御プレインの確立を待つことができ、制御プレインパスの未確立時のSeNBとS―MeNB、または、SeNBとT-MeNBの制御情報のバッファリング処理などを削減することができ、SeNBの処理を簡易化することが可能となる。
ステップST1106において、S-MeNBから、T-MeNBへのHOを指示するMCIを受信したUEは、ステップST1107において、ベアラ1の上りデータの送信を停止し、バッファに記憶する。
ステップST1109において、UEは、MCIに従い、S-MeNBからT-MeNBへ接続変更処理を行う。UEは、MCIを受信した後、S-MeNBとの接続を切断してT-MeNBとの接続を行う。UEは、ステップST1106のRRC接続再構成メッセージで受信した内容を用いて、T-MeNBのためのRRC接続の再構成を行い、T-MeNBと接続を行う。
UEは、ステップST1110において、T-MeNBとRA処理を行い、ステップST1111において、T-MeNBに対してRRC接続再構成完了メッセージを通知する。
UEは、T-MeNBにRRC接続再構成完了メッセージ通知後、T-MeNBとの間で、直接データ通信を行うことが可能となる。
UEは、T-MeNBとのRRC接続再構成完了メッセージを通知後、ベアラ1の上りデータを送信する。
SeNBからUEへ通知する下りデータの取扱い方法について、以下に開示する。SeNBは、UEと接続を維持したままHOを行う場合、ベアラ2の下りデータの送信を維持することができる。
または、S―MeNBからT-MeNBへのHOが完了するまで、SeNBは、HO中は下りデータの送信を停止し、バッファに記憶することもできる。このようにすることによって、制御プレインの確立を待つことができ、制御プレインパスの未確立時のSeNBとS―MeNB、または、SeNBとT-MeNBの制御情報のバッファリング処理などを削減することができ、SeNBの処理を簡易化することが可能となる。
SeNBは、MeNBによって、UEに対するデュアルコネクティビティのためのベアラの構成を通知される。また、SeNBの該UEに対するRRCに関する設定情報は、該MeNBによって通知される。
したがって、SeNBは、どのMeNBから該ベアラの構成が通知されたか、どのMeNBに、SeNBが設定したRRCに関する設定情報を通知すればよいか、などを認識する必要がある。すなわち、該MeNBを認識する必要がある。
また、SeNBは、MeNB間でデュアルコネクティビティを行うUEのためのデータ通信を行う。SeNBは、どのMeNBからのデータをUEに送信すればよいか、UEからのデータをどのMeNBへ送信すればよいかを認識する必要がある。すなわち、該MeNBを認識する必要がある。
前者のMeNBと後者のMeNBとを別に設定してもよいが、ここでは、同一である場合について説明する。以下の説明では、該MeNBを、SeNBの制御MeNBと称する。
デュアルコネクティビティ中のUEのHO処理において、SeNBの変更は行われず、MeNBがS-MeNBからT-MeNBに変更される場合について、該SeNBの制御MeNBが、どのMeNBに変更されたかを認識する方法を開示する。
SeNBの制御MeNBが、どのMeNBに変更されたかを認識する方法の具体例として、以下の(1),(2)の2つを開示する。
(1)S-MeNBがSeNBに制御MeNBの変更を通知する。
(2)T-MeNBがSeNBに制御MeNBの変更を通知する。
前記具体例(1)について、具体例を以下に開示する。T-MeNBは、UEからRRC接続再構成完了メッセージを受信すると、S-MeNBに対して、SeNBへ制御MeNBの変更を要求するように、SeNBの制御MeNB変更要求メッセージの通知を行う。該通知はX2シグナリングを用いて行うとよい。該通知に、制御MeNBの変更を行うSeNBの識別子を含めて通知してもよい。また、変更の理由情報を含めて通知してもよい。HOによるMeNBの変更であることを示す情報を設けて通知してもよい。
該通知を受信したS-MeNBは、制御MeNBの変更を行うSeNBへ、制御MeNBの変更を要求する制御MeNB変更要求メッセージを通知する。該通知は、X2シグナリングを用いて行ってもよい。あるいはMeNBとSeNBとの間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。
該シグナリングに含める情報の具体例として、以下の(1)~(5)の5つを開示する。
(1)制御MeNBの変更を示す情報。
(2)変更後の制御MeNBの識別子。ここでは、T-MeNBの識別子。
(3)SeNBを用いたパスのベアラ識別子。ここでは、E-RAB識別子(E-RAB IDなどであってもよい)、あるいは、EPSベアラ識別子。
(4)ベアラを用いてデュアルコネクティビティを行うUEの識別子。
(5)前記(1)~(4)の組合せ。
制御MeNB変更要求メッセージを受信したSeNBは、該制御MeNB変更要求メッセージに含まれる情報から、MeNBの変更を行うベアラを特定する。SMeNBは、該ベアラの制御MeNBを変更後のMeNBに変更する。SeNBにおけるベアラの管理は、制御MeNBの識別子と関連付けて行うとよい。すなわち、ベアラの識別子と制御MeNBの識別子とを関連付けておくとよい。このようにすることによって、SeNBは、デュアルコネクティビティを行うUEのためのベアラの制御MeNBの変更が可能となる。
SeNBは、制御MeNBの変更後、該ベアラの修正、リリースの要求は、変更後の制御MeNBからのみ受入れることとする。また、SeNBは、変更後のMeNBとデータの通信を行うこととする。
このようにすることによって、SeNBは、制御MeNBが、どのMeNBに変更されたかを認識することができ、変更後の制御MeNBとの間で、該UEに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。
制御MeNBの変更を行ったSeNBは、S-MeNBに対して、制御MeNB変更応答メッセージを通知してもよい。該メッセージに、制御MeNBの変更を行ったことを示す情報を含めてもよい。
SeNBから制御MeNB変更応答メッセージを受信したS-MeNBは、変更後の制御MeNB、ここではT-MeNBに、SeNBの制御MeNB変更が完了したことを示すメッセージを通知してもよい。
このようにすることによって、変更後のMeNB、ここではT-MeNBは、SeNBの制御MeNBが変更されたことを認識することができ、該SeNBに対して、該UEに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を開始することが可能となる。
変更後MeNBは、SeNBに対して、該UEに対する該ベアラの制御MeNBが変更になったことを確認するメッセージを通知してもよい。また、SeNBは該メッセージに対して応答してもよい。
前記具体例(2)について、以下に具体例を開示する。T-MeNBは、UEからRRC接続再構成完了メッセージを受信すると、SeNBに、制御MeNB変更要求メッセージの通知を行う。該SeNBの識別子は、S-MeNBから受信したHO要求メッセージ含まれるSeNB情報を用いるとよい。該通知はX2シグナリングを用いて行うとよい。あるいはMeNBとSeNB間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。該シグナリングに含める情報は、前記具体例(1)の方法で開示したものを適用することができる。
T-MeNBから、制御MeNB変更要求メッセージを受信したSeNBにおける処理は、前記具体例(1)と同様であるので、説明を省略する。
このようにすることによって、SeNBは制御MeNBがどのMeNBに変更されたかを認識することができ、変更後の制御MeNBとの間で該UEに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。
制御MeNBの変更を行ったSeNBは、T-MeNBに対して、制御MeNB変更応答メッセージを通知してもよい。該メッセージに、制御MeNBの変更を行ったことを示す情報を含めてもよい。
SeNBから制御MeNB変更応答メッセージを受信したT-MeNBは、変更前の制御MeNB、ここではS-MeNBに、SeNBの制御MeNB変更が完了したことを示すメッセージを通知してもよい。
このようにすることによって、変更前のMeNB、ここではS-MeNBは、SeNBの制御MeNBが変更されたことを認識することができ、該SeNBに対して、該UEに対する該ベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を終了することが可能となる。
また、SeNBを用いてデュアルコネクティビティ中のUEのHOが行われた場合、SeNBは、変更後のMeNB(T-MeNB)とベアラ構成に関する制御のための通信、およびデータ通信を行うことが可能となる。
したがって、UEとT-MeNBとの間でSeNBを介してデータ通信を行うことが可能となる。
SeNBのMeNB変更処理について具体例を説明する。ステップST1111でUEからRRC接続再構成完了メッセージを受信したT-MeNBは、ステップST1112において、S-MeNBに対して、SeNBの制御MeNBの変更を要求する制御MeNB変更要求メッセージを通知する。該SeNBの制御MeNB変更要求メッセージに、制御MeNBの変更を行うSeNBの識別子を含める。
該メッセージを受信したS-MeNBは、ステップST1113において、制御MeNBの変更を行うSeNBに対して、制御MeNB変更要求メッセージを通知する。該制御MeNB変更要求メッセージに、制御MeNBの変更を示す情報、T-MeNBの識別子、SeNBを用いたパスのベアラ識別子、SeNBにおける制御MeNBを変更するベアラの識別子、S-MeNBの識別子、SeNBを用いてデュアルコネクティビティを行うHO対象のUEの識別子を含める。このようにすることによって、SeNBは、どのMeNBが設定したどのベアラについて制御MeNBの変更を行えばよいかを認識することができる。
該制御MeNB変更要求メッセージを受信したSeNBは、ステップST1114において、受信した情報を用いて、制御MeNBの変更を行う。これによって、SeNBは、以降、変更後の制御MeNBであるT-MeNBと、ベアラに関する制御のための通信およびデータ通信を行う。制御MeNBを変更したSeNBは、変更前の制御MeNBとの制御のための通信およびデータ通信を終了する。
ステップST1114で制御MeNBの変更を行ったSeNBは、ステップST1115において、S-MeNBに対して、制御MeNBを変更したことを通知するために、制御MeNB変更応答メッセージを通知する。該制御MeNB変更応答メッセージを受信したS-MeNBは、ステップST1116において、T-MeNBに対してSeNBの制御MeNBの変更が終了したことを通知するために、SeNBの制御MeNB変更応答メッセージを通知する。これによって、T-MeNBは、SeNBの制御MeNBがT-MeNBに変更されたことを認識することができる。したがって、T-MeNBは、SeNBと、ベアラに関する制御のための通信およびデータ通信を行うことが可能となる。
以上のように、本実施の形態では、SeNBへの制御MeNB変更要求メッセージの通知を、S-MeNBを介して実行しているが、S-MeNBを介さずに、直接、T-MeNBとSeNBとの間で、制御MeNB変更要求メッセージ、および制御MeNB変更応答メッセージを送受信してもよい。その場合、制御MeNB変更要求メッセージにS-MeNBの情報を含めて、SeNBの制御MeNB変更処理において、不正な制御MeNB変更要求でないことの判断に用いてもよい。
図18に示すステップST1112からステップST1116を、ステップST1117とする。ステップST1117は、T-MeNB、S-MeNBおよびSeNBの間で行われるSeNBの制御MeNB変更処理を示す。
その後の、MeNB変更のためのS-GWにおけるパス切替処理は、前述の図12と同様であるので、説明を省略する。パス切替処理によって、S-GWと、HO対象であったUEとの間において、T-MeNBを介したデータ通信を行うことが可能となる。
S-GWとUEとの間におけるデータ通信は、一つはS-MeNBとUEとの間でデータが直接通信され、もう一つはSeNBとUEとの間でデータが直接通信される。本実施の形態で開示した方法とすることによって、ベアラによるデュアルコネクティビティ中のUEがMeNB間HOを行うことが可能となる。
SeNBの制御MeNB変更処理について、他の方法を開示する。前述に開示した方法では、SeNBの制御MeNB変更処理は、T-MeNBがUEからRRC接続再構成完了メッセージを受信した後に行われる。
他の方法として、T-MeNBがS-MeNBに対してHO要求受諾応答メッセージを通知した後、あるいは、S-MeNBがT-MeNBからHO要求受諾応答メッセージを受信した後、あるいは、S-MeNBがUEにMCIを含むRRC接続再構成メッセージを送信した後に、SeNBの制御MeNB変更処理を行うようにしてもよい。SeNBの制御MeNB変更処理は、前述の方法を適用するとよい。
このようにすることによって、早期に、SeNBにおいて制御MeNBをT-MeNBに変更することが可能となるので、早期に、SeNBとT-MeNBとの間で制御データ通信を行うことが可能となる。
SeNBの制御MeNB変更処理について、他の方法を開示する。T-MeNBが、MMEおよびS-GWに対して行うパススイッチ処理を完了した後に、SeNBの制御MeNB変更処理を行うようにしてもよい。T-MeNBは、MMEからパススイッチ要求受諾応答メッセージを受信すると、SeNBへMeNBの変更通知を行う。
あるいは、S-MeNBは、T-MeNBからUEコンテキストリリース(UE context release)メッセージを受信すると、SeNBへMeNBの変更通知を行う、としてもよい。SeNBの制御MeNB変更処理は、前述の方法を適用するとよい。
このようにすることによって、MMEおよびS-GWのT-MeNBへのパス切替えも含めてHO処理が終了した後に、SeNBを用いたベアラによるデータ通信を行うことが可能となる。確実にHO処理が終了した後に行うことによって、データ通信の制御の複雑化を避けることが可能となる。
以上のように本実施の形態によれば、HO処理が起動されると、スモールセルであるSeNBに、スモールセルを制御するマクロセルが変更されることが通知される。これによって、S-GWからスモールセルを介して通信を行うパスは保持したまま、HO処理を実行することができるので、HO処理中であっても、ユーザプレインデータ通信を継続することが可能となる。
また、実施の形態1のようにSeNBをリリースした後、HOを実行する場合と比較して、制御シーケンスが簡易になるので、デュアルコネクティビティ中からのHOシーケンスにおけるシグナリングする情報量を削減することが可能となる。
実施の形態3.
図20~図22は、実施の形態3の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図20と図21とは、境界線BL3で接続されている。図21と図22とは、境界線BL4で接続されている。本実施の形態のハンドオーバ関連処理は、前述の図10~図13に示す実施の形態1および図17~図19に示す実施の形態2のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。
本実施の形態では、非特許文献11に記載されるデュアルコネクティビティのユーザプレインアーキテクチャの選択肢3C(Alternative 3C)の場合(非特許文献11 8.1.1.8参照)において、SeNBをリリースしないでHOを行う方法について開示する。
ユーザプレインアーキテクチャの選択肢3Cでは、MeNBによって、MeNBとUEとの間で、直接通信を行うパスと、スモールセルを介して通信を行うパスとでベアラが分割されるベアラスプリットが行われる。
ベアラスプリットによるデュアルコネクティビティ中のUEがMeNB間HOを行う場合、SeNBとの接続はリリースされない。すなわち、UEのデュアルコネクティビティを保ったまま、MeNB間のHOが行われる。
ベアラスプリットの場合、実施の形態1の変形例1でも説明したが、1つのEPSベアラに対応するE-RABが、S-MeNBで、2つのパスに分離され、S-GWとUEとの間でデータが通信される。一つはステップST1001において、S-MeNBとUE間でデータが直接通信される。もう一つは、ステップST1003およびステップST1004において、S-MeNBとUE間でデータがSeNBを介して通信される。ステップST1002において、S-MeNBとS-GWとの間は、一つのパスでデータが通信される。
ベアラスプリットによって、デュアルコネクティビティ中のUEがMeNB間HOを行う場合について説明する。
MeNBが、ベアラスプリットによるデュアルコネクティビティ中のUEに対してメジャメント制御メッセージを通知する方法は、実施の形態1で開示した方法を適用することができる。ここでは説明を省略する。
ここでは、メジャメントによるS-MeNBの受信品質が劣化し、T-MeNBの受信品質が改善し、イベントクライテリアに従ってメジャメント報告を行う場合について説明する。
ステップST906において、UEは、S-MeNBに対してメジャメント報告を行う。UEからのメジャメント報告に、デュアルコネクティビティに用いているSeNBの識別子と受信品質を含めてもよい。
該UEからメジャメント報告を受信したS-MeNBは、該報告の結果を用いて該UEをT-MeNBへHOさせることを決定する。
ステップST1201において、S-MeNBは、T-MeNBに対してHO要求メッセージを通知する。このメッセージに、SeNB情報を含めて通知するとよい。また、SeNBを用いてベアラスプリットを行っているベアラに関するベアラ情報を通知してもよい。また、ベアラスプリットに関する情報を通知してもよい。また、ベアラスプリットにおけるRRCに関する情報を通知してもよい。
SeNB情報として、例えば、SeNBの識別子、UEにおけるSeNBの受信品質などがある。
ベアラスプリットを行っているベアラに関するベアラ情報として、E-RAB識別子などがある。
ベアラスプリットに関する情報として、MeNBとUEとの間の直接のパスと、SeNBを介したMeNBとUEとの間のパスとにスプリットされたベアラ(以下「スプリットベアラ」という場合がある)の構成(以下「スプリットベアラ構成」という場合がある)に関する情報がある。MeNBは、スプリットされたパス毎にスプリットベアラの設定を行うとよい。各パスに対する識別子を設けてもよい。各パスの識別子と、パス毎に設定したスプリットベアラ構成に関する情報とを関連させて通知するとよい。また、SeNBを用いるパスの場合は、該SeNBの識別子と該パスの識別子とを関連させて通知してもよい。パス毎に設定されるスプリットベアラ構成に関する情報として、例えば、QoSパラメータ、具体的には、QCI、ARP、帯域保証サービス品質情報などがある。
このようにすることによって、パス毎のスプリットベアラ設定を可能にし、S-MeNBはT-MeNBに対してパス毎のスプリットベアラ設定を通知することが可能となる。T-MeNBは、パス毎のスプリットベアラ設定を取得することが可能となり、パス毎のスプリットベアラの設定の変更が必要か否か判断可能となる。
ベアラスプリットを行っているベアラに関するベアラ情報と、スプリットベアラ構成に関する情報とを関連させて通知するとよい。ベアラスプリットを行っているベアラと、行っていないベアラとを識別可能となる。
ベアラスプリットにおけるRRCに関する設定情報として、例えば、RRCコンテキスト(RRC context)がある。RRCコンテキストには、例えば、無線リソースの構成を示すAS構成(AS configuration)、RRM情報を示すRRM構成(RRM configuration)などがある。
RRCに関する情報は、MeNBのためのRRCに関する情報およびSeNBのためのRRCに関する情報がある。各RRCに関する情報を識別可能とするとよい。例えば、MeNBのためのRRCコンテキストとSeNBのためのRRCコンテキストとを別々に作成する。あるいは、1つのRRCコンテキストの中に、MeNBのための情報とSeNBのための情報とを別々に作成してもよい。
このようにすることによって、SeNBのためのRRCに関する情報とMeNBのためのRRCに関する情報とを個別に設定可能にし、S-MeNBはT-MeNBに対してMeNBとSeNB、各々のRRCに関する情報を通知することが可能となる。T-MeNBは、S-MeNBとSeNB、各々のRRCに関する情報を取得することが可能となり、T-MeNBは、SeNBのRRCに関する設定の変更が必要か否か判断可能となる。
T-MeNBは、S-MeNBからHO要求メッセージで受信した情報を用いて、ステップST1101において、SeNBを変更するか否か判断する。このステップST1101の処理は、図17のステップST1101の処理と同様であるので、説明を省略する。
SeNBの変更を行うと判断した場合は、ステップST1102に移行する。ステップST1102の処理は、実施の形態2で開示した方法を適用すればよく、ここでは説明を省略する。
SeNBの変更をしないと判断した場合は、T-MeNBは、ステップST1103において、SeNBの使用を維持したままHO処理を行うことを決定する。換言すれば、T-MeNBは、MeNBのみの変更を行うことを決定する。SeNBの変更をしないと判断した場合は、SeNB使用のスプリットベアラ構成を維持する。SeNBへのスプリットベアラ構成の変更処理は行わない。
ステップST1202において、T-MeNBは、HO要求に対するアドミッション制御を行う。このアドミッション制御は、前述のSeNBを変更するか否かの判断の前に行われてもよい。あるいは、その判断と併せて行われてもよい。
SeNBの変更を行わないので、MeNBの変更によるアドミッション制御を行う。アドミッション制御において、T-MeNBは、T-MeNBのためのRRCに関する設定を行う。RRCに関する設定として、無線リソースの構成を示すAS構成(AS configuration)、RRM情報を示すRRM構成(RRM configuration)などがある。また、RRC接続再構成メッセージに含まれる情報の設定も行ってもよい。
T-MeNBで用いるUE個別RACHプリアンブル構成は、SeNBで用いるUE個別のRACHプリアンブル構成と別々に設けて設定してもよい。また、T-MeNBで用いるC-RNTIはSeNBで用いるC-RNTIと別々に設けて設定してもよい。SeNBがT-MeNB傘下にない他のUEをサポートするような場合に、各UEに個別に設定することができるので、柔軟な制御を可能とする。
あるいは、T-MeNBで用いるUE個別のRACHプリアンブル構成をSeNBで用いるUE個別のRACHプリアンブル構成と同じに設定してもよい。また、T-MeNBで用いるC-RNTIをSeNBで用いるC-RNTIと同じに設定してもよい。SeNBがT-MeNB傘下にない他のUEをサポートしない場合などに、各UE個別に設定する必要が無く、1つの値で制御することができるので、制御が簡易になる。
T-MeNBのためのRRCに関する設定は、UEがT-MeNBとRRC接続再構成を可能とする情報が必要となる。
T-MeNBがHO要求受入を決定した場合、ステップST1203において、T-MeNBは、S-MeNBに対して、HO要求受諾応答メッセージにHO指示メッセージを含めて通知する。このHO指示メッセージに前述のT-MeNBのためのRRCに関する設定情報を含めるとよい。
また、SeNBを用いたスプリットベアラの構成を維持する場合、T-MeNBは、S-MeNBに、該SeNBの識別子、E-RAB識別子、ベアラスプリットに関する情報、ベアラスプリットにおけるRRCに関する情報などを通知する。あるいは、T-MeNBは、S-MeNBに、SeNBを用いたスプリットベアラの構成を維持したままHOが可能であることを通知してもよい。また、SeNBを用いたスプリットベアラの構成を維持する場合、T-MeNBは、S-MeNBに、SeNBのためのRRCに関する設定を維持したままHOが可能であることを通知してもよい。
このようにすることによって、通知する情報量を削減することが可能となる。これらの通知は、HO要求受諾応答メッセージを用いて行うとよい。SeNBを用いないベアラに対するHO要求受諾応答メッセージと一緒に通知してもよい。SeNBを用いないベアラに対するHO要求受諾応答メッセージと別に通知してもよい。
HO要求受諾応答メッセージ、または、HO指示メッセージに、SeNBのRRCに関する設定の変更があるか否かの情報を含めてもよい。S-MeNBは、該情報を取得し、変更があると認識した場合に、さらに、SeNBのRRCに関する設定を取得するようにしてもよい。これによって、変更がない場合の処理を簡略化することが可能となる。
SeNBのRRCに関する設定に変更がない場合、該設定情報をHO指示メッセージに含めなくてもよい。シグナリングする情報量を削減可能となる。
あるいは、SeNBのためのRRCに関する設定情報を、HO指示メッセージに含めてもよい。S-MeNBが、T-MeNBから取得したSeNBのためのRRCに関する設定情報と、自セルが有しているSeNBのためのRRCに関する設定情報とを比較することが可能となり、確実に変更が無いことを検証することが可能となる。
ステップST1203でHO要求受諾応答メッセージを受信したS-MeNBは、T-MeNBへ、デュアルコネクティビティ中のUEに対するSeNBを維持したままのHOであることを認識することができる。
SeNBを維持したままのHOを行うことを認識したS-MeNBは、SeNBに対して、スプリットベアラ構成の変更の要求を行わない。SeNBのためのRRCに関する設定変更の要求を行わない。
デュアルコネクティビティ中のUEがMeNB間HO中に、SeNB起動によるベアラスプリット構成の変更は行わないようにしてもよい。HO中にSeNB起動によるベアラスプリット構成の変更があると、S-MeNBからT-MeNBへのMeNB変更時に該処理を行うこととなるため、制御が複雑になり、誤動作の可能性が高くなる。HO時のSeNB起動によるベアラスプリット構成の変更は行わないようにすることによって、誤動作を低減することが可能となる。
HO中に、SeNB起動によるベアラスプリット構成の変更が行われないようにする方法を以下に開示する。
T-MeNBは、SeNBへHOが起動されることを示す情報を通知する。この通知は、T-MeNBがS-MeNBへHO要求受諾応答メッセージを送信したときに行うとよい。あるいは、T-MeNBからHO要求受諾応答メッセージを受信したS-MeNBが、SeNBへHOを起動することを示す情報を通知してもよい。
HOが起動されたことを示す情報を受信したSeNBは、ベアラスプリット構成の変更要求を起動しない。該HOが完了するまで起動しないとするとよい。
他の方法として、該HO中は、S-MeNBあるいはT-MeNBは、SeNBからのベアラスプリット構成変更要求に対してNack(あるいは拒否)をSeNBに通知してもよい。理由情報を含めてもよく、理由として、HO中によることを示す情報を設けて設定するとよい。
図20~図22の処理においては、ステップST1204において、T-MeNB、S-MeNBおよびSeNB間でこれらの処理が行われる。
SeNBがHO完了を認識する方法を以下に開示する。T-MeNBは、SeNBへHO完了したことを示す情報を通知するとよい。この通知は、HO処理において、T-MeNBがMMEからパススイッチ要求受諾応答メッセージを受信したときに行うとよい。あるいは、後述するMeNBの変更処理完了をHO完了としてもよい。
このようにすることによって、デュアルコネクティビティ中のUEのHO処理中に、SeNB起動の該UEに対するベアラスプリット構成の変更を行わないようにすることができる。したがって、システムとして誤動作を低減することが可能となる。
他の方法について開示する。前述のSeNBを維持したままのHOを行う場合、S-MeNBは、SeNBに対して、スプリットベアラ構成の変更の要求、また、SeNBのためのRRCに関する設定変更の要求を行わないことを開示したが、他の方法として、SeNBを維持したままのHOを行う場合、S-MeNBは、SeNBに対して、SeNBを維持したままのHOであることを通知してもよい。あるいは、スプリットベアラ構成の変更の要求、SeNBのためのRRCに関する設定変更の要求を行わないことを通知してもよい。前述のHOが起動されることを示す情報とともに通知してもよい。
これによって、SeNBは、HO中に、該HOがSeNBを維持したままのHOを行う場合か否かなどを認識することが可能となる。SeNBを維持したままのHOの場合は、SeNBは、該HO中はSeNB起動の該UEに対するベアラスプリット構成の変更を行わないようにすることができる。前述と同様の効果を得ることが可能となる。
HO要求受諾応答メッセージを受信したS-MeNBは、ステップST1205において、T-MeNBにHOをさせるために、MCI(Mobility Control Information)を含むRRC接続再構成(RRC Connection Reconfiguration)メッセージをUEに通知する。また、HO要求受諾応答メッセージを受信したS-MeNBは、UEに、SeNBを用いたベアラスプリットの変更が無いことを通知してもよい。
S-MeNBはUEへ、該HO時、スプリットベアラを行うE-RAB用のSeNBの変更が無いことを通知する。また、SeNBのためのRRCに関する設定変更が無いことを通知してもよい。該MCIを含むRRC接続再構成メッセージに一緒に含めて通知するとよい。
必要に応じて、S-MeNBは、SeNBのためのRRCに関する設定情報を認識している場合は、該設定情報をUEに通知してもよい。UEは、自UEが接続しているSeNBに対するRRCに関する設定情報と、受信した該設定情報とを比較することが可能となり、確実に変更が無いことを検証することが可能となる。
ステップST1205でMCIを含むRRC接続再構成メッセージを受信したUEは、SeNBとの同期および接続を維持したまま、S-MeNBからT-MeNBへのHOを行う。UEは、SeNBとの無線リソースを維持したままHOを行う。例えば、UEは、SeNBに対するMAC設定をリセットしない。あるいは、SeNBに対するRLC設定を再構成しない。この状態においてUEは、SeNBとの通信が可能である。
MeNBに対する設定は、該MCIを含むRRC接続再構成メッセージのMeNBに対するRRCに関する設定情報に従う。PDCPは、MeNBに位置するので、PDCPの設定は、MeNBに対する設定に従うとよい。例えば、S-MeNBに対する設定からT-MeNBに対する設定に再設定される。MCIを含むRRC接続再構成メッセージにおいて、MeNBに対するRRCに関する設定情報と、SeNBに対するRRCに関する設定情報とを個別に設けて、個別に設定可能とするとよい。これによって、UEは、SeNBに対する設定とMeNBに対する設定とを個別に、再構成あるいは維持あるいはデフォルト設定への移行が可能となる。この例では、UEは、SeNBに対する設定を維持したままMeNBに対する設定を再構成することが可能となるので、SeNBの接続を維持したままS-MeNBからT-MeNBへの変更が可能となる。
UEからSeNBへの上りデータの取扱い方法について以下に開示する。UEは、SeNBと接続を維持したままHOを行う場合でも、SeNBがS-MeNBと接続しているかT-MeNBと接続しているか認識しない。HO処理中、もし、SeNBがまだT-MeNBと接続していないときに、UEがSeNBに上りデータを送信した場合、SeNBはT-MeNB上りデータを送信することができず、該上りデータのロスを引き起こすことになる。ここでは、そのような問題を解決する方法を開示する。
UEは、S-MeNBからMCI受信後、上りデータの送信を停止し、バッファに記憶する。また、UEは、T-MeNBとのRRC接続再構成が完了するまで上りデータの送信を停止し、バッファに記憶する。UEは、T-MeNBとのRRC接続再構成完了メッセージを通知後上りデータを送信する。UEは、S-MeNBからMCI受信後の新たな上りデータの送信を停止し、バッファに記憶するとよい。該上りデータとして、UEから送信する上りデータ全てとするとよい。UEは、T-MeNBへの直接のパスで送信する上りデータと、SeNBを介したT-MeNBへのパスで送信する上りデータとを振り分ける前に停止し、バッファに記憶するとよい。あるいは、たとえ、T-MeNBへの直接のパスで送信する上りデータと、SeNBを介したT-MeNBへのパスで送信する上りデータとがUE内で振り分けられたとしても、両方を停止し、バッファに記憶するとよい。UEにおける上りデータの処理として、PDCP SNのナンバリングは行ってもよい。このようにすることによって、上りデータのロスが生じる問題を解決することが可能となる。
ステップST1205において、S-MeNBから、T-MeNBへのHOを指示するMCIを受信したUEは、ステップST1206において、上りデータの送信を停止し、バッファに記憶する。ステップST1207において、UEはMCIに従い、S-MeNBからT-MeNBに接続変更処理を行う。
ステップST1207において、UEは、MCIを受信した後、S-MeNBとの接続を切断してT-MeNBと接続を行う。UEは、ステップST1205のRRC接続再構成メッセージで受信した内容を用いて、T-MeNBのためのRRC接続の再構成を行い、T-MeNBと接続を行う。
UEは、ステップST1212でT-MeNBとRA処理を行い、ステップST1213でT-MeNB対してRRC接続再構成完了メッセージを通知する。
UEは、T-MeNBにRRC接続再構成完了メッセージ通知後、T-MeNBとの間で直接データ通信を行うことが可能となる。
UEは、T-MeNBとのRRC接続再構成完了メッセージを通知後、上りデータを送信する。上りデータは、UEにおいて、T-MeNBへ直接送信するパスとSeNBを介してT-MeNBへ送信するパスとに分割され、UEは、T-MeNB、SeNB各々に対して、上りデータを送信する。
ステップST1219において、UEは、T-MeNBへ直接送信するパスで上りデータを送信する。ステップST1220において、UEは、SeNBに上りデータを送信する。上りデータの送信はPDCP SNに従って送信してもよい。
UEあるいはSeNBは、UEがS-MeNBからT-MeNBにHO中、UEとSeNB間の同期処理を必要に応じて行っておくとよい。あるいは、UEがSeNBに対して上りデータ送信開始前に行ってもよい。RA処理を用いてもよい。
UEは、MCIの受信前、すなわち上りデータの送信が停止される前にSeNBとの間で送受信していたS-MeNBへの上りデータについては送信処理を続けてもよい。S-MeNBとの間で直接行っていた上りデータについても送信不達となるまで送信処理を続けてもよい。これらは、S-MeNBによって通知されたオーバヘッド圧縮設定などを用いて行う。
UEは、MCIの受信前、すなわち上りデータの送信が停止される前にS-MeNBと直接またはSeNBを介してS-MeNBとの間で送受信していた上りデータのうち、送信を失敗したデータから、T-MeNBへの送信を開始してもよい。UEは、送信を失敗したデータのうち、PDCP SNの最も小さいデータからT-MeNBへ送信を開始してもよい。該データから、UEは、T-MeNB直接あるいはSeNBを介してT-MeNBに送信するとよい。
このようにすることによって、データのロスを最小にすることが可能となる。また、この方法は、SeNBでの上りデータのバッファが少なくて済むので、SeNBのバッファ容量の低減および構成の簡易化を可能とする。SeNBを安価にすることが可能となる。
T-MeNBへの送信は、T-MeNBへ直接およびSeNBを介してT-MeNBへ送信する両方の場合において、T-MeNBによって設定されたヘッダ圧縮設定を用いるとよい。
SeNBを介して上りデータをT-MeNBに送信するパスにおいて、SeNBがまだT-MeNBと接続していない場合がある。このような場合、SeNBは、T-MeNBとのMeNB設定の変更が完了するまで、UEからの上りデータをバッファに記憶するとよい。SeNBは、T-MeNBとのMeNB設定変更完了後、UEからの上りデータをT-MeNBに送信する。SeNBは、データのPDCP SNを用いてリオーダリングして送信してもよい。
これによって、SeNBとT-MeNBとの間でMeNB設定変更が何らからの理由で遅延し、UEからSeNBへの上りデータ送信が行われてしまったような場合でも、SeNBにおけるデータのロスが発生する問題を解決することができる。
上りデータのロスが発生する問題を解決する他の方法を開示する。UEはT-MeNBとの接続完了を待たずに上りデータをSeNBに送信する。SeNBは、T-MeNBとのMeNB設定の変更が完了するまで、UEからの上りデータをバッファに記憶する。SeNBは、T-MeNBとのMeNB設定変更完了後、UEからの上りデータをT-MeNBに送信する。SeNBは、データのPDCP SNを用いてリオーダリングして送信してもよい。これによって、SeNBにおけるデータのロスが発生する問題を解決することができる。
この場合、前述の方法に比べて、SeNBに必要となるバッファ量は大きくなるが、SeNBとT-MeNBとの間でMeNBの設定変更が行われると、直ちにSeNBからT-MeNBへバッファしていた上りデータを送信することが可能となるので、UEからの上りデータが早期にT-MeNBに送達することが可能となる。
UEがT-MeNBに接続完了を通知する前に上りデータをSeNBに送信する具体例を説明する。
UEがS-MeNBからMCIを受信後、新たな上りデータを、SeNBを介してT-MeNBに送信する。T-MeNBは、S-MeNBを介してUEに、ヘッダ圧縮設定を通知し、UEは、SeNBを介したT-MeNBとの新たな上り通信に該ヘッダ圧縮設定を用いる。
この場合、UEは、MCI受信前にSeNBとの間で行っていたS-MeNBへの上りデータの送信を停止するとよい。S-MeNBへの上りデータ送信失敗したデータも、T-MeNBによるヘッダ圧縮設定でSeNBへ送信してもよい。UEは、データ送信を失敗したデータのうち、PDCP SNの最も小さいデータからSeNBを介してT-MeNBへ送信開始してもよい。
あるいは、UEは、SeNBとの間において、S-MeNB向とT-MeNB向との両方の上りデータを送信してもよい。SeNBはこれらを、どちらのヘッダ圧縮が用いられているかを識別することでどちらに向けての上りデータかを判断してもよい。あるいは、他の方法として、UEからSeNBへの上りデータに、どちら向けの上りデータかを示す情報を含めてあるいは付加して送信するとよい。例えば該情報を1ビットとして含める。1ビットの設定方法として、例えば、SeNBがユーザプレインデータのみしか送受信しない場合、PDCPフォーマットのD/Cビットを該情報用のビットとして設定するようにしてもよい。
SeNBは、T-MeNBとのMeNB設定の変更が完了するまで、UEからの上りデータをバッファし、T-MeNBとのMeNB設定変更が完了した後、UEからの上りデータをT-MeNBに送信する。SeNBは、データのPDCP SNを用いてリオーダリングして送信してもよい。
S-MeNBがUEから受信した上りデータについて説明する。S-MeNBが受信したUEからの上りデータは、UEから直接受信した上りデータもSeNBを介して受信した上りデータもあわせて、PDCP SNによって管理するとよい。S-MeNBは、PDCP SNに従ってリオーダリングしてS-GWに送信する。
S-MeNBがUEにMCIを送信した場合、MCIを送信するときに直接UEとの間で通信中の上りデータは、S-MeNBにデータ送達成功後、S-MeNBからS-GWへ送信してもよい。また、同様に、MCIを送信するときにSeNBを介してUEとの間で通信中の上りデータは、S-MeNBにデータ送達成功後、S-GWへ送信してもよい。S-GWで、S-MeNBから受信したデータとT-MeNBから受信したデータとの順序管理を行うとよい。
UEがMCIを受信した時点で送信完了と判断していたデータが、何らかの原因でS-MeNBへまだ送達成功していない場合、UEがT-MeNBに対して該データを送信しないことによって発生するデータの損失を防ぐことができる。また、S-MeNBからS-GWへ送信する代わりに、T-MeNBへ転送(フォワーディング(forwarding))してもよい。T-MeNBにおいて、PDCP SNに従ってリオーダリングしてS-GWに送信するとよい。これによって、S-GWに送信する方法と同様の効果が得られる。
また、S-MeNBが該データをS-GWへ送信するのか、T-MeNBへ転送するのかを設定可能としてもよい。設定する主体としては、RAN側あるいはコアネットワーク側のノードとするとよい。該設定情報は、予めS-MeNBに通知されるとよい。例えば、MME、あるいはS-GWは、S-MeNBに対して該設定情報を予め通知する。
また、S-MeNBがUEにMCIを送信した場合、直前に送達失敗したデータ後に送達成功したデータを、S-GWへ送信、あるいはT-MeNBへ転送(フォワーディング(forwarding))してもよい。UEでは送達失敗したデータからT-MeNBで上り送信が行われる。UEがHO完了後T-MeNBとの間で該データ以降のデータの送達が失敗したような場合、該転送されたデータを利用できる。
MeNBからSeNBを介してUEへ通知する下りデータの取扱い方法について、以下に開示する。
ステップST1203でHO要求受諾応答メッセージ受信したS-MeNBは、新たな下りデータの送信を停止し、バッファに記憶する。該下りデータとして、HOをさせるUEへ送信する下りデータ全てとするとよい。S-MeNBは、UEへの直接のパスで送信する下りデータと、SeNBを介したUEへのパスで送信する下りデータを振り分ける前に停止し、バッファに記憶するとよい。あるいは、たとえ、UEへの直接のパスで送信する下りデータと、SeNBを介したUEへのパスで送信する下りデータとがS-MeNB内で振り分けられたとしても、両方のデータの送信を停止し、バッファに記憶するとよい。S-MeNBにおける下りデータの処理として、PDCP SNのナンバリングは行ってもよい。
S-MeNBは、HO要求受諾応答メッセージの受信前、すなわちデータの送信が停止される前にUEとの間で送受信していた下りデータのうち、送信不達となった下りデータ以降の下りデータを、T-MeNBに対して転送(フォワーディング(forwarding))する。
送信不達となった下りデータのうち、PDCP SNの最も小さいデータからT-MeNBへ転送(フォワーディング(forwarding))するとよい。S-MeNBからUEへの直接のパスによって送信した下りデータおよびSeNBを介したパスによって送信した下りデータをあわせて最もPDCP SNが小さいデータからT-MeNBへ転送(フォワーディング(forwarding))するとよい。
ステップST1208において、S-MeNBは、T-MeNBへの転送(フォワーディング(forwarding))を開始し、ステップST1209において、SN状況伝達(SN Status Transfer)を行い、ステップST1210でデータ転送(Data Forwarding)を行う。転送は、PDCP SNで管理され、ステップST942およびステップST944において通知されるS-GWからのエンドマーカまでが転送される。
ステップST1211において、T-MeNBは、S-MeNBから転送(フォワーディング(forwarding))されたデータをバッファに記憶する。
このようにすることによって、たとえ、UEがSeNBを用いてデュアルコネクティビティを行っていたとしても、HO処理時に下りデータのロスが生じるのを防ぐことが可能となる。
T-MeNBは、UEとの直接のRRC接続再構成が完了するまで、および、SeNBにおけるMeNB変更処理が完了するまで、下りデータをバッファに記憶する。T-MeNBは、ベアラスプリットによって、UEとの直接のパスによる下りデータと、SeNBを介したパスによる下りデータとを、分離する前にバッファしてもよいし、分離した後にバッファしてもよい。いずれも、ナンバリングされたPDCP SNで管理することが可能である。UEにおいてもPDCP SNでリオーダリングすることが可能となる。
分離する前にバッファに記憶する方法の場合、SeNBを用いたベアラスプリット構成を変更する場合に、両方のパスともに新たなベアラスプリット構成が設定された後に、該ベアラスプリット構成に適した、データの分離のためのスケジューリングを可能とする。したがって、デュアルコネクティビティのUEにとって効率がよいスケジューリングを行うことができる。
他方、分離した後にバッファに記憶する方法の場合、両方のパスが利用可能となった場合に即時に該両方のパスを用いて下りデータをUEに送信することが可能となる。すなわち、遅延量の増大を防ぐことができる。
T-MeNBは、UEとの直接の接続が完了したとき、および、SeNBにおけるMeNB変更処理が完了したとき、各パスに下りデータを分離スケジューリングして、各パスを用いてUEに対して下りデータを送信する。
他の方法を開示する。T-MeNBは、UEとの直接の接続の完了、およびSeNBとのMeNB変更通知完了のいずれか早い方で、UEへの下りデータ送信を開始する。
T-MeNBがデータを分離する前にバッファに記憶する場合は、両方のパスが設立するまで、早い方のパスで下りデータ送信を行う。その後、両方のパスが設立したときに、ベアラスプリットを開始するとよい。
T-MeNBがデータを分離した後にバッファに記憶する場合は、各パスの設立に応じて下りデータ送信を行うとよい。
このようにすることによって、可能な限り早期に下りデータをUEに送信することができる。
SeNBは、MeNBによって、UEに対するデュアルコネクティビティのためのベアラスプリットの構成を通知される。また、SeNBの該UEに対するRRCに関する設定情報は該MeNBによって通知される。
したがって、SeNBはどのMeNBから該ベアラスプリットの構成が通知されたか、どのMeNBにSeNBが設定したRRCに関する設定情報を通知すればよいか、などを認識する必要がある。すなわち、該MeNBを認識する必要がある。
また、SeNBは、MeNB間でデュアルコネクティビティを行うUEのためのデータ通信を行う。SeNBは、どのMeNBからのデータをUEに送信すればよいか、UEからのデータをどのMeNBへ送信すればよいかを認識する必要がある。すなわち、該MeNBを認識する必要がある。
前者のMeNBと後者のMeNBとを別に設定してもよいが、ここでは、同一である場合について説明する。該MeNBを、SeNBの制御MeNBと称する。
デュアルコネクティビティ中のUEのHO処理において、SeNBの変更は行わず、MeNBがS-MeNBからT-MeNBに変更される場合について、該SeNBの制御MeNBがどのMeNBに変更されたかを認識する方法を以下に開示する。具体例として、以下の(1),(2)の2つを開示する。
(1)S-MeNBがSeNBに制御MeNBの変更を通知する。
(2)T-MeNBがSeNBに制御MeNBの変更を通知する。
前記具体例(1)について具体例を開示する。T-MeNBは、UEからRRC接続再構成完了メッセージを受信すると、S-MeNBに対して、SeNBの制御MeNB変更要求メッセージの通知を行う。該通知はX2シグナリングを用いて行うとよい。該通知に、制御MeNBの変更を行うSeNBの識別子を含めて通知してもよい。また、変更の理由情報を含めて通知してもよい。HOによるMeNBの変更であることを示す情報を設けて通知してもよい。
該通知を受信したS-MeNBは、制御MeNBの変更を行うSeNBへ、制御MeNBの変更を通知する。該通知はX2シグナリングを用いて行ってもよい。あるいはMeNBとSeNB間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。
該シグナリングに含める情報の具体例として、以下の(1)~(7)の7つを開示する。
(1)制御MeNBの変更を示す情報。
(2)変更後の制御MeNBの識別子。ここでは、T-MeNBの識別子。
(3)SeNBを用いたパスのベアラ識別子。ここでは、E-RAB識別子(E-RAB IDなどであってもよい)、あるいは、EPSベアラ識別子。
(4)SeNBにおける制御MeNBを変更するスプリットベアラの識別子。
(5)ベアラスプリット構成の設定要求したMeNBの識別子。ここでは、S-MeNBの識別子。
(6)ベアラスプリットを用いてデュアルコネクティビティを行うUEの識別子。
(7)前記(1)~(6)の組合せ。
制御MeNB変更通知メッセージを受信したSeNBは、該変更通知メッセージに含まれる情報から、MeNBの変更を行うスプリットベアラを特定する。SMeNBは、該スプリットベアラの制御MeNBを変更後のMeNBに変更する。SeNBにおけるスプリットベアラの管理は制御MeNBの識別子と関連付けて行うとよい。すなわち、スプリットベアラの識別子と制御MeNBの識別子とを関連付けておくとよい。このようにすることによって、SeNBは、デュアルコネクティビティを行うUEのためのスプリットベアラの制御MeNBの変更が可能となる。
SeNBは、制御MeNBの変更後、該スプリットベアラの修正、リリースの要求は、変更後の制御MeNBからのみ受入れることとする。また、SeNBは、変更後のMeNBとデータの通信を行うこととする。
このようにすることによって、SeNBは制御MeNBがどのMeNBに変更されたかを認識することができ、変更後の制御MeNBとの間で該UEに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。
制御MeNBの変更を行ったSeNBは、S-MeNBに対して、制御MeNB変更応答メッセージを通知してもよい。該メッセージに、制御MeNBの変更を行ったことを示す情報を含めてもよい。
SeNBから制御MeNB変更応答メッセージを受信したS-MeNBは、変更後の制御MeNB、ここではT-MeNBに、SeNBの制御MeNB変更が完了したことを示すメッセージを通知してもよい。
このようにすることによって、変更後のMeNB、ここではT-MeNBは、SeNBの制御MeNBが変更されたことを認識することができ、該SeNBに対して、該UEに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を開始することが可能となる。
変更後MeNBは、SeNBに対して、該UEに対する該スプリットベアラの制御MeNBが変更になったことを確認するメッセージを通知してもよい。また、SeNBは該メッセージに対して応答してもよい。
前記具体例(2)について具体例を開示する。T-MeNBは、UEからRRC接続再構成完了メッセージを受信すると、SeNBに、制御MeNB変更要求メッセージの通知を行う。該SeNBの識別子は、S-MeNBから受信したHO要求メッセージ含まれるSeNB情報を用いるとよい。該通知はX2シグナリングを用いて行うとよい。あるいはMeNBとSeNB間に設けられるインタフフェース上のシグナリングを用いて行ってもよい。該シグナリングに含める情報は、前記具体例(1)の方法で開示したものを適用することができる。
T-MeNBから、制御MeNB変更要求メッセージを受信したSeNBにおける処理は、前記具体例(1)と同様であるので、説明を省略する。
このようにすることによって、SeNBは、制御MeNBが、どのMeNBに変更されたかを認識することができ、変更後の制御MeNBとの間で該UEに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を行うことが可能となる。
制御MeNBの変更を行ったSeNBは、T-MeNBに対して、制御MeNB変更応答メッセージを通知してもよい。該メッセージに、制御MeNBの変更を行ったことを示す情報を含めてもよい。
SeNBから制御MeNB変更応答メッセージを受信したT-MeNBは、変更前の制御MeNB、ここではS-MeNBに、SeNBの制御MeNB変更が完了したことを示すメッセージを通知してもよい。
このようにすることによって、変更前のMeNB、ここではS-MeNBは、SeNBの制御MeNBが変更されたことを認識することができ、該SeNBに対して、該UEに対する該スプリットベアラの修正、リリースの要求などの制御のための通信、およびデータ通信を終了することが可能となる。
また、SeNBを用いてデュアルコネクティビティ中のUEのHOが行われた場合、SeNBは、変更後のMeNB(T-MeNB)とスプリットベアラ構成に関する制御のための通信、およびデータ通信を行うことが可能となる。
したがって、UEとT-MeNBとの間でSeNBを介してデータ通信を行うことが可能となる。
SeNBのMeNB変更処理について、具体例を説明する。図21のステップST1213でUEからRRC接続再構成完了メッセージを受信したT-MeNBは、ステップST1214において、S-MeNBに対してSeNBの制御MeNBの変更要求メッセージを通知する。該メッセージに、制御MeNBの変更を行うSeNBの識別子を含める。
該メッセージを受信したS-MeNBは、ステップST1215において、制御MeNBの変更を行うSeNBに対して、制御MeNBの変更を要求するメッセージを通知する。該メッセージに、制御MeNBの変更を示す情報、T-MeNBの識別子、SeNBを用いたパスのベアラ識別子、SeNBにおける制御MeNBを変更するスプリットベアラの識別子、S-MeNBの識別子、SeNBを用いてデュアルコネクティビティを行うHO対象のUEの識別子を含める。このようにすることによって、SeNBは、どのMeNBが設定したどのスプリットベアラについて制御MeNBの変更を行えばよいかを認識することができる。
該メッセージを受信したSeNBは、ステップST1216において、ステップST1215で受信した情報を用いて、制御MeNBの変更を行う。これによって、SeNBは、以降、変更後のMeNBであるT-MeNBとスプリットベアラに関する制御のための通信およびデータ通信を行う。制御MeNBを変更したSeNBは、変更前の制御MeNBとの制御のための通信およびデータ通信を終了する。
制御MeNBの変更を行ったSeNBは、ステップST1217でS-MeNBに対して、制御MeNBを変更したことを通知するために、制御MeNB変更応答メッセージを通知する。該応答メッセージを受信したS-MeNBは、ステップST1218でT-MeNBに対してSeNBの制御MeNB変更が終了したことを通知するためSeNBの制御MeNB変更応答メッセージを通知する。これによって、T-MeNBは、SeNBのMeNBがT-MeNBに変更されたことを認識することができる。したがって、T-MeNBは、SeNBと、スプリットベアラに関する制御のための通信およびデータ通信を行うことが可能となる。
これによって、ステップST1220、ステップST1221において、T-MeNBからUEへの下りデータも、UEからT-MeNBへの上りデータも、SeNBを介して通信を行うことが可能となる。
図12に示すステップST1214からステップST1218を、ステップST1222とする。ステップST1222は、T-MeNB、S-MeNB、SeNBで行われるSeNBのMeNB変更処理を示す。
その後のステップST939からステップST947の、MeNB変更のためのS-GWにおけるパス切り替え処理は、図12と同様であるので、説明を省略する。
これによって、S-GWと、HO対象であったUEとの間において、T-MeNB、あるいは、T-MeNBとSeNBを介したデータ通信を行うことが可能となる。
S-GWとUEとの間でのデータ通信は、一つは、ステップST1005において、S-MeNBとUE間でデータが直接通信され、もう一つは、ステップST1007とステップST1008において、S-MeNBとUEとの間でデータがSeNBを介して通信される。ステップST1006において、S-MeNBとS-GWとの間は1つのパスでデータが通信される。
本実施の形態で開示した方法とすることによって、ベアラスプリットによるデュアルコネクティビティ中のUEがMeNB間HOを行うことが可能となる。
SeNBへのMeNB変更処理ステップST1222について、他の方法を開示する。前述に開示した方法では、SeNBへのMeNB変更処理は、T-MeNBがUEからRRC接続再構成完了メッセージを受信した後に行った。
他の方法として、T-MeNBがS-MeNBに対してHO要求受諾応答メッセージを通知した後、あるいは、S-MeNBがT-MeNBからHO要求受諾応答メッセージを受信した後、あるいは、S-MeNBがUEにMCIを含むRRC接続再構成メッセージを送信した後に、SeNBへのMeNB変更処理を行うようにしてもよい。SeNBへのMeNB変更処理は、前述の方法を適用するとよい。
このようにすることによって、早期に、SeNBにおいて制御MeNBをT-MeNBに変更することが可能となるので、早期に、SeNBとT-MeNBとの間でデータ通信を行うことが可能となる。
したがって、UEは上りデータを、T-MeNBとRRC接続再構成完了するまで送信停止し、バッファしなくてよい。あるいは、SeNBにおいて送信停止しバッファしなくてよい。UEは、SeNBを用いたスプリットベアラによって、SeNBを介してT-MeNBに対して早期に上りデータを通信することが可能となる。
また、T-MeNBは下りデータを、UEからRRC接続再構成完了を受信するまで送信停止し、バッファしなくてよい。T-MeNBは、SeNBを用いたスプリットベアラによって、SeNBを介してUEに対して早期に上りデータを通信することが可能となる。
これは、UEとT-MeNB間の直接のパスによるデータ通信がまだ行なわれない間も、UEとT-MeNBとの間でSeNBを介したパスを用いて通信が可能になる。これによって、HO時のデータ通信処理を低遅延で行うことが可能となり、HO時のデータロスを低減させることが可能となる。
SeNBへのMeNB変更処理ステップST1222について、他の方法を開示する。T-MeNBが、MMEおよびS-GWに対して行うパススイッチ処理を完了した後に、SeNBへのMeNB変更処理を行うようにしてもよい。T-MeNBは、MMEからパススイッチ要求受諾応答メッセージを受信したときに、SeNBへMeNBの変更通知を行う。
あるいは、S-MeNBは、T-MeNBからUEコンテキストリリース(UE context release)メッセージを受信したときに、SeNBへMeNBの変更通知を行う、としてもよい。SeNBへのMeNB変更処理は、前述の方法を適用するとよい。
このようにすることによって、MMEおよびS-GWのT-MeNBへのパス切替えも含めてHO処理が終了した後に、SeNBを用いたスプリットベアラによるデータ通信を行うことが可能となる。確実にHO処理が終了した後に行うことによって、データ通信の制御の複雑化を避けることが可能となる。
実施の形態4.
図23~図25は、実施の形態4の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図23と図24とは、境界線BL5で接続されている。図24と図25とは、境界線BL6で接続されている。本実施の形態のハンドオーバ関連処理は、前述の図10~図13に示す実施の形態1、図17~図19に示す実施の形態2、および図20~図22に示す実施の形態3のハンドオーバ関連処理と類似するので、同一のステップについては同一のステップ番号を付して、説明を省略する。
本実施の形態では、前述の実施の形態3と下りデータの取扱い方法が異なる。本実施の形態において、MeNBからSeNBを介してUEへ通知する下りデータの取扱い方法について以下に開示する。
本実施の形態では、ステップST1203でHO要求受諾応答メッセージ受信したS-MeNBは、新たな下りデータの送信を停止し、バッファに記憶する。下りデータとして、HOをさせるUEへ送信する下りデータ全てとするとよい。S-MeNBは、UEへの直接のパスで送信する下りデータと、SeNBを介したUEへのパスで送信する下りデータを振り分けた後にストップし、バッファに記憶して、SeNBを介したUEへのパスで送信する下りデータはストップせずに、送信を継続するとよい。S-MeNBにおける下りデータの処理として、PDCP SNのナンバリングは行ってもよい。
S-MeNBは、HO要求受諾応答メッセージの受信前、すなわちデータの送信が停止される前にUEとの間で送受信していた下りデータのうち、送信不達となった下りデータ以降の下りデータを、T-MeNBに対して転送(フォワーディング(forwarding))する。送信不達となった下りデータのうち、PDCP SNの最も小さいデータからT-MeNBへ転送(フォワーディング(forwarding))するとよい。S-MeNBからUEへの直接のパスによって送信した下りデータのうち最もPDCP SNが小さいデータからT-MeNBへ転送(フォワーディング(forwarding))するとよい。
ステップST1301において、S-MeNBは、T-MeNBへの転送(フォワーディング(forwarding))を開始し、ステップST1209において、SN状況伝達(SN Status Transfer)を行い、ステップST1210において、データ転送(Data Forwarding)を行う。転送は、PDCP SNで管理され、ステップST942およびステップST944において通知されるS-GWからのエンドマーカまでが転送される。
以降のステップは、実施の形態3と同様に実行される。具体的には、ステップST1211において、T-MeNBは、S-MeNBから転送(フォワーディング(forwarding))されたデータをバッファに記憶する。
このようにすることによって、たとえ、UEがSeNBを用いてデュアルコネクティビティを行っていたとしても、HO処理時に下りデータのロスが生じるのを防ぐことが可能となる。
本実施の形態では、T-MeNBは、UEとの直接のRRC接続再構成が完了するまで、および、SeNBにおけるMeNB変更処理が完了するまで、下りデータをバッファに記憶する。T-MeNBは、ベアラスプリットによって、UEとの直接のパスによる下りデータと、SeNBを介したパスによる下りデータとを、分離した後にバッファに記憶するとよい。ナンバリングされたPDCP SNで管理することが可能である。UEにおいてもPDCP SNでリオーダリングすることが可能となる。
分離する前にバッファに記憶する方法の場合、SeNBを用いたベアラスプリット構成を変更する場合に、両方のパスともに新たなベアラスプリット構成が設定された後に、該ベアラスプリット構成に適した、データの分離のためのスケジューリングを可能とする。したがって、デュアルコネクティビティのUEにとって効率がよいスケジューリングを行うことができる。
他方、分離した後にバッファに記憶する方法の場合、両方のパスが利用可能となった場合に即時に該両方のパスを用いて下りデータをUEに送信可能となる。すなわち、遅延量の増大を防ぐことができる。
以降のステップは、実施の形態3と同様に実行される。T-MeNBは、UEとの直接の接続が完了したとき、および、SeNBにおけるMeNB変更処理が完了したとき、各パスに下りデータを分離スケジューリングして、各パスを用いてUEに対して下りデータを送信する。
他の方法を開示する。T-MeNBは、UEとの直接の接続の完了、およびSeNBとのMeNB変更通知完了のいずれか早い方で、UEへの下りデータ送信を開始する。
このようにすることによって、可能な限り早期に、下りデータをUEに送信することができる。
実施の形態5.
図26~図28は、実施の形態5の通信システムにおけるハンドオーバ関連処理のシーケンスの一例を示す図である。図26と図27とは、境界線BL7で接続されている。図27と図28とは、境界線BL8で接続されている。
本実施の形態では、S-MeNBからT-MeNBへのハンドオーバが行われる前は、EPSに対応するベアラ(以下「EPSベアラ」という場合がある)として、ベアラ2(以下「EPSベアラ#2」と記載する場合がある)を用いて、SeNBとS-MeNBとの両方が、UEとの間でデータの送受信を行う。ハンドオーバの処理中は、SeNBのみが、UEとの間でデータの送受信を行う。ハンドオーバの処理後は、SeNBとT-MeNBとの両方が、UEとの間でデータの送受信を行う。
一例として、EPSベアラ#2を用いて、SeNBおよびS-MeNBの両方との間で、データを送受信するUEについて説明する。このUEが、S-MeNBから、T-MeNBにハンドオーバを行う際、ハンドオーバ直前に、EPSベアラ#2は、S-MeNBのRLC/MACを経由せずに、SeNBのRLC/MAC/PHYのみを経由するように、全て移行される。あるいは、EPSベアラ#2は、GTPu/PDCPも含めて、S-GWよりも下位は全てS-MeNBを経由せずに、SeNBのRLC/MAC/PHYのみを経由するように、全て移行される。あるいは、EPSベアラ#2は、SeNBのRLC/MAC/PHYのみを経由するように全て移行されることに代えて、SeNBのGTPu/PDCP/RLC/MAC/PHYの全てを経由するように、全て移行される。以下の説明では、このように、ベアラを、SeNBを経由するように全て移行することを、「SeNBへ全移行する」という場合がある。
図26のステップST2001において、S-MeNB、T-MeNB、MMEおよびS-GWは、エリア制限を付与する(Area Restriction Provided)。
ステップST2002からステップST2011のHO決定までは、前述の実施の形態4と同様に行われる。具体的には、ステップST2002において、S-MeNBは、UEにメジャメント制御(Measurement Control)メッセージを通知する。該メジャメント制御メッセージに、周辺のSeNBのメジャメントを設定してもよい。あるいは、SeNB用の周波数のメジャメントを設定してもよい。また、メジャメントの設定として、MeNBとは別に、SeNB用またはSeNB用の周波数におけるイベント、もしくはイベントのクライテリアを設定してもよい。
設定パラメータとしては、SeNBの識別子、周波数、報告のためのイベント番号、受信品質の閾値、測定期間などがある。受信品質としては、RSRP(Reference Signal Received Power)、RSRQ(Reference Signal Received Quality)などがある。
ステップST2002においてメジャメント制御メッセージを受信したUEは、周辺セル、すなわちMeNBおよびSeNBのメジャメントを行う。
ステップST2003において、UEとS-MeNBとの間で、パケットデータの通信が行われ、ステップST2004において、S-MeNBとS-GWとの間で、パケットデータの通信が行われる。
EPSベアラ#2がベアラスプリットされる場合、ステップST2005において、UEとS-MeNBとの間でパケットデータが直接通信され、ステップST2006において、S-MeNBとS-GWとの間でパケットデータが直接通信される。
また、ステップST2007およびステップST2008において、UEとS-MeNBとの間で、SeNBを介して、パケットデータが通信される。具体的には、ステップST2007において、UEとSeNBとの間でパケットデータの通信が行われ、ステップST2008において、SeNBとS-MeNBとの間でパケットデータの通信が行われる。
ステップST2009において、S-MeNBは、UEに、上りリンク割り当て(UL allocation)情報を通知する。ステップST2010において、UEは、S-MeNBにメジャメント報告(Measurement Report)メッセージを通知する。
ステップST2010でメジャメント報告メッセージを受信したS-MeNBは、ステップST2011において、メジャメント報告の結果を用いて、UEをT-MeNBにハンドオーバ(HO)させるか否かを決定する。図26に示す例では、S-MeNBは、ステップST2011において、UEをT-MeNBにHOさせることを決定する。
S-MeNBは、ステップST2011でUEをT-MeNBにHOさせることを決定すると、ステップST2012に移行する。ステップST2012において、S-MeNBは、EPSベアラ#2をSeNBへ全移行するための修正(以下「EPSベアラ#2のSeNBへの全移行のための修正」という場合がある)を行うか否かを決定する。図26に示す例では、S-MeNBは、EPSベアラ#2のSeNBへの全移行のための修正を行うことを決定する。
ステップST2013において、S-MeNBは、SeNBに対するEPSベアラ#2全移行可否確認処理を行う。ここで、SeNBに対するEPSベアラ#2全移行可否確認処理とは、EPSベアラ#2をSeNBへ全移行することが可能か否か、すなわちEPSベアラ#2のSeNBへの全移行の可否をSeNBに確認する処理をいう。具体的には、S-MeNBは、SeNBに対するEPSベアラ#2全移行可否確認処理として、SeNBに対して、EPSベアラ#2のSeNBへの全移行が可能か否かを確認する全移行可否確認信号を通知する。全移行可否確認信号を受信したSeNBは、S-MeNBに対して、EPSベアラ#2のSeNBへの全移行の可否を通知する。
ステップST2014において、S-MeNBは、SeNBから通知された全移行の可否に基づいて、SeNBへの全移行が可能であるか否かを判断する。SeNBへの全移行が可能であると判断された場合は、ステップST2015に移行し、SeNBへの全移行が可能でないと判断された場合は、ステップST2016に移行する。
ステップST2015において、UE、SeNBおよびS-MeNBは、S-MeNBに対するEPSベアラ#2全移行修正処理を行う。具体的には、ステップST2015において、EPSベアラ#2をSeNBへ全移行する処理が行われる。
ステップST2016において、S-MeNBは、図17のステップST1102と同様にして、SeNBをリリースした後、HO処理を実行する。他の実施の形態では、SeNBへの全移行が可能でないと判断されてステップST2016に移行した場合、SeNBをリリースせずに、HO処理を実行してもよい。
ステップST2017において、S-MeNBとS-GWとの間でパケットデータの通信が行われる。ステップST2018において、UEとSeNBとの間でパケットデータの通信が行われる。ステップST2019において、SeNBとS-MeNBとの間でパケットデータの通信が行われる。
ステップST2020において、S-MeNBは、ハンドオーバ要求(Handover Request)メッセージを、HO先であるT-MeNBに通知する。HO要求メッセージには、SeNB情報および、EPSベアラ#2に関する情報(以下「EPSベアラ#2情報」という場合がある)が含まれる。SeNB情報およびEPSベアラ#2情報は、HO要求メッセージとは別のメッセージを用いて通知されてもよい。
ステップST2021において、T-MeNBは、SeNBの変更が必要か否かを判断する。SeNBの変更が必要であると判断された場合は、ステップST2022に移行し、SeNBの変更が必要でないと判断された場合は、ステップST2023に移行する。
ステップST2022において、T-MeNBは、図17のステップST1102と同様にして、SeNBをリリースした後、ハンドオーバ(HO)処理を実行する。
ステップST2023において、T-MeNBは、ベアラ構成の変更が必要か否かを判断する。ベアラ構成の変更が必要であると判断された場合は、図28のステップST2025に移行し、ベアラ構成の変更が必要でないと判断された場合は、ステップST2024に移行する。
ステップST2024において、SeNBおよびT-MeNBによって、SeNBに対するMeNB変更確認処理が行われる。ここで、MeNB変更確認処理とは、S-MeNBからT-MeNBへのMeNBの変更を行うか否かを確認する処理をいう。具体的には、MeNB変更確認処理として、T-MeNBが、SeNBに対して、S-MeNBからT-MeNBへのMeNBの変更を行うか否かを確認するMeNB変更確認信号を通知する。MeNB変更確認信号を受信したSeNBは、T-MeNBに対して、MeNBの変更を行うか否かを通知する。ステップST2024の処理には、S-MeNBは関与しない。
図28のステップST2025において、UE、SeNB、S-MeNB、T-MeNB、MMEおよびS-GWによって、EPSベアラ#1用MeNB HO処理が行われる。SeNBを介したNASシグナリングがある場合も、ステップST2025のEPSベアラ#1用MeNB HO処理に従う。EPSベアラ#1用MeNB HO処理の詳細については後述する。
ステップST2026において、SeNB、S-MeNBおよびT-MeNBによって、SeNBに対するMeNB変更処理が行われる。これは、MeNBのハンドオーバ完了後、SeNBの制御プレイン(C-plane)、たとえばシグナリングを行うマクロeNB(MeNB)が変更されたことを通知する処理である。この処理は、EPSベアラ#2のMeNBをT-MeNBに変更したことを通知し、T-MeNBとSeNBとの間でデータ送受信を可能にするために必要な処理である。具体的には、ステップST2026において、S-MeNBが、SeNBに対して、MeNBがT-MeNBに変更されたことを表す信号を通知する。
ステップST2027において、UEとSeNBとの間でパケットデータの通信が行われる。ステップST2028において、SeNBとT-MeNBとの間でパケットデータの通信が行われてもよい。
ステップST2029において、T-MeNBは、EPSベアラ#2のSeNBへの全移行のために、EPSベアラ#2の修正を行うか否かを判断する。図28に示す例では、T-MeNBは、EPSベアラ#2のSeNBへの全移行のために、EPSベアラ#2の修正を行うことを決定する。
これによって、EPSベアラ#2は、MeNBのハンドオーバ処理中に、ハンドオーバしないSeNBのみから送受信されるように変更されるので、ハンドオーバの影響を受けなくなる。したがって、ハンドオーバ処理を簡素化することができるので、ハンドオーバの失敗を軽減することができる。また、データの欠落を軽減することができる。
ステップST2030において、UE、SeNBおよびT-MeNBは、SeNBに対するEPSベアラ#2全移行可否確認処理、およびEPSベアラ#2のSeNBへの全移行のための修正処理を行う。ステップST2030の処理には、S-MeNBは関与しない。
ステップST2031において、UEとT-MeNBとの間でパケットデータの通信が行われる。ステップST2032において、T-MeNBとS-GWとの間でパケットデータの通信が行われる。
ステップST2033において、UEとSeNBとの間でパケットデータの通信が行われる。ステップST2034において、SeNBとT-MeNBとの間でパケットデータの通信が行われる。
図29および図30は、図28のステップST2025のEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。
ステップST2041において、T-MeNBは、前述の図12に示すステップST930と同様にして、収容キャパシティを確認するアドミッション制御を行う。T-MeNBは、アドミッション制御の結果に基づいて、HOを受付可能であると判断すると、ステップST2042において、ステップST931と同様にして、S-MeNBに、HO要求受諾応答(Handover Request Ack)メッセージを通知する。
ステップST2042のHO要求受諾応答メッセージを受けて、ステップST2043において、SeNB、S-MeNBおよびT-MeNBは、SeNBに対するMeNB変更処理を行う。ここで、MeNB変更処理とは、T-MeNBからS-MeNBへ、さらにS-MeNBからSeNBへのデータの流れ、または、T-MeNBからS-MeNBおよびT-MeNBからSeNBへのデータの流れにおいて、SeNBの制御プレイン(C-plane)、たとえばシグナリングを行うマクロeNB(MeNB)が変更されたことを通知する処理である。具体的には、SeNBに対して、S-MeNBが、T-MeNBにMeNBが変更されたことを表す信号を通知する。MeNBが変更されたことは、ステップST2042のHO要求受諾応答(Handover Request Ack)メッセージを用いて通知されてもよい。
ステップST2044において、UEとS-MeNBとの間でパケットデータの通信が行われる。ステップST2045において、S-MeNBとT-MeNBとの間でパケットデータの通信が行われる。
ステップST2046において、S-MeNBは、UEに、下りリンク割り当て(DL allocation)情報を通知する。ステップST2047において、S-MeNBは、UEに、モビリティ制御情報を含むRRC接続再構成(RRC Connection Reconfiguration)メッセージを通知する。ステップST2047では、SeNBおよびEPSベアラ#2に変更がないことを通知してもよい。
ステップST2048からステップST2055までの処理は、3GPP TS36.300と同じである。具体的には、ステップST2048において、UEは、旧セルであるS-MeNBからデタッチするとともに、新セルであるT-MeNBへの同期を開始する。
ステップST2049において、S-MeNBは、バッファに記憶中のパケット、および送信中のパケットを、ターゲットeNBであるT-MeNBに伝達する。
ステップST2050において、S-MeNBは、T-MeNBに、図11のステップST912と同様にして、PDCPのシーケンス番号(SN)の状況を伝達するSN状況伝達(SN Status Transfer)を行う。また、ステップST2051において、S-MeNBは、T-MeNBに、送信が完了していないデータを転送するデータ転送(Data Forwarding)を行ってもよい。
ステップST2052において、T-MeNBは、S-MeNBから伝達されたパケットをバッファに記憶する。
ステップST2053において、UEは、T-MeNBに同期(Synchronization)する。ステップST2054において、T-MeNBは、UEに、上りリンク割り当て(UL allocation)情報およびUE用トラッキングエリア(TA)を通知する。ステップST2055において、UEは、T-MeNBに、RRC接続再構成完了(RRC Connection Reconfiguration Complete)メッセージを通知する。
図30のステップST2056において、SeNB、S-MeNBおよびT-MeNBによって、図28のステップST2026と同様にして、SeNBに対するMeNBの変更処理が行われる。これは、SeNBの制御プレイン(C-plane)、たとえばシグナリングを行うマクロeNB(MeNB)が変更したことを通知する処理である。
ステップST2057において、UEとT-MeNBとの間でパケットデータの通信が行われてもよい。ステップST2058において、UEとSeNBとの間でパケットデータの通信が行われる。ステップST2059において、SeNBとT-MeNBとの間でパケットデータの通信が行われてもよい。ステップST2060において、T-MeNBは、S-GWにパケットデータを伝達してもよい。
ステップST2671において、T-MeNB、MMEおよびS-GWは、EPSベアラ#1およびEPSベアラ#2のパスをいずれも、S-MeNBからT-MeNBに変更することを要求するパススイッチ要求を行う。
具体的には、ステップST2061において、T-MeNBは、MMEに、パススイッチ要求(Path Switch Request)メッセージを通知する。パススイッチ要求メッセージを通知されたMMEは、ステップST2062において、S-GWに、ベアラ変更要求(Modify Bearer Request)メッセージを通知する。
ベアラ変更要求メッセージを通知されたS-GWは、ステップST2063において、下りパスを変更する。ステップST2064において、S-GWは、S-MeNBに送信するPDCPにエンドマーカを付与して転送処理の終了を伝えてもよい。S-MeNBは、ステップST2066において、エンドマーカを付与してT-MeNBに転送してもよい。ステップSTST2065において、T-MeNBとS-GWとの間で、パケットデータの通信が行われてもよい。
ステップST2067において、S-GWは、MMEに、ベアラ変更応答(Modify Bearer Response)メッセージを通知する。ベアラ変更応答メッセージを通知されたMMEは、ステップST2068において、T-MeNBに、パスの切替完了を表すパススイッチ要求受諾応答(Path Switch Request Ack)メッセージを通知する。このようにして、ステップST2671の処理が終了する。
ステップST2069において、T-MeNBは、S-MeNBに、UEコンテキスト解放(UE context release)メッセージを通知する。UEコンテキスト解放メッセージを通知されたS-MeNBは、ステップST2670において、UEに割り当てていたリソースを解放(リリース)する。ステップST2670のリソースのリリース処理の後、前述の図28のステップST2026のSeNBに対するMeNBの変更処理が行われる。
前述のように、図28のステップST2029の処理によって、ハンドオーバ時に、SeNBのみが、UEとの間で、EPSベアラ#2を用いたデータの送受信を行うように設定される。このステップST2029の処理をどのようにして行うかについて、図31を用いて説明する。
図31は、UEとの間のデータの送受信の状況の一例を示す図である。S-GW601は、PDCP処理eNB切替部602を備える。S-MeNB603は、第1PDCP処理部604、RLC処理部605、MAC処理部606、PHY処理部607および第2PDCP処理部608を備える。SeNB609は、PDCP処理部610、PDCPパス切替部611、RLC処理部612、MAC処理部613およびPHY処理部614を備える。
ハンドオーバ切替前は、UE615は、S-MeNB603およびSeNB609の両方と、EPSベアラ#2を用いたデータの送受信を行っている。たとえば、下りリンクの場合、S-GW601から、データが、S-MeNB603の第1PDCP処理部604および第2PDCP処理部608に与えられる。第1および第2PDCP処理部(以下、まとめて「PDCP処理部」という場合がある)604,608は、LTEまたはLTE-AにおけるPDCPの処理を行う。
第2PDCP処理部608に与えられたデータは、SeNB609のPDCPパス切替部611に与えられる。PDCPパス切替部611は、PDCPのパスの切替を行う。PDCPパス切替部611は、ハンドオーバ中ではないので、第2PDCP処理部608からのPDCPをRLC処理部612に与えると判断し、第2PDCP処理部608からのデータをRLC処理部612に与える。RLC処理部612は、LTEまたはLTE-AにおけるRLCの処理を行う。
RLC処理部612に与えられたデータは、その後、MAC処理部613、PHY処理部614に順に与えられ、無線伝送によって、UE615に与えられる。MAC処理部613は、LTEまたはLTE-AにおけるMACの処理を行う。PHY処理部614は、LTEまたはLTE-AにおけるPHYの処理を行う。
本実施の形態のように、SeNB609におけるデータの送受信は変わらず、MeNBのハンドオーバのみが行われる場合、ハンドオーバ中は、UE615と、S-MeNB603との間で、EPSベアラ#2を用いたデータの送受信は行われない。
PDCPを含めてSeNB609へ全移行する場合、S-GW601は、PDCP処理eNB切替部602によって、PDCPの処理を行うeNBを切替える。PDCP処理eNB切替部602は、S-MeNB603の第2PDCP処理部608ではなく、SeNB609のPDCP処理部610に対して、EPSベアラ#2を用いてデータを送信する。PDCP処理部610は、LTEまたはLTE-AにおけるPDCPの処理を行う。
S-GW601からデータを受信したSeNB609は、受信したデータに対して、PDCP処理部610によってPDCPの処理を行い、処理後のデータをPDCPパス切替部611に与える。SeNB609は、PDCPパス切替部611によって、S-MeNB603の第2PDCP処理部608からのPDCPデータではなく、自装置のPDCP処理部610からのPDCPデータを選択し、RLC処理部612に与える。
RLC処理部612に与えられたPDCPデータは、その後、MAC処理部613、PHY処理部614の順に与えられて処理され、最後に、無線伝送によって、UE615に送信される。
PDCP処理eNB切替部602およびPDCPパス切替部611を設けることによって、MeNBのハンドオーバ中は、データの導通を、ハンドオーバしないSeNBのみで行う処理を実現することができる。
上りリンクの場合でも、下りリンクの場合と同様の処理の流れとなる。上りリンクの場合も、下りリンクの場合と同様に、PDCP処理eNB切替部602およびPDCPパス切替部611を設けることによって、MeNBのハンドオーバ中は、データの導通を、ハンドオーバしないSeNBのみで行う処理を実現することができる。
また、前述の図28のステップST2025のハンドオーバ処理の後に、SeNBとT-MeNBとの両方で、EPSベアラ#2を用いたデータの送受信が行われる場合の処理は、以下のようにして実行される。ハンドオーバ時は、SeNBにおいて、S-MeNBからT-MeNBに接続を変更する。その後、T-MeNBが、SeNBのみのデータの送受信経路を、SeNBとT-MeNBとのデータの送受信経路に変更する。あるいは、ハンドオーバ時は、一度に、SeNBおよびT-MeNBの両方のデータの送受信経路を用いて接続する、といった方法も考えられる。
その際、無線リソースの構成(Configuration)の変更については、(A)T-MeNBからのスプリットベアラ構成の設定で行う場合と、(B)データの送受信経路の切替の変更で行う場合との二通りが考えられる。
前記(A)のT-MeNBからのスプリットベアラ構成の設定で行う場合の具体例として、以下の(A-1)~(A-4)の4つを開示する。
(A-1)S-MeNBからT-MeNBに通知が必要な情報は、SeNBの識別情報、具体的にはSeNBの行先番地(アドレス)に関する情報である。PDCP処理されたデータをSeNBに送信することになるが、その際にSeNBの識別情報が必要となるためである。SeNBの識別情報がないと、T-MeNBは、どのSeNBにデータを送信したらよいのか、どのSeNBからデータを受信したらよいのかが分からない。また、T-MeNBは、SeNBが、どのRRCコネクションパラメータで動作しているかのパラメータ情報を知る必要があるので、その情報も通知される。
(A-2)T-MeNBからS-MeNBに通知が必要な情報は、MeNBのハンドオーバに成功したか失敗したかの情報である。また、S-MeNBのバッファにデータが滞留している場合は、データ転送(Data Forwarding)を行う指示を表す情報も、T-MeNBからS-MeNBに通知が必要な情報である。
(A-3)UEに通知が必要な情報は、S-MeNBからT-MeNBへ、ハンドオーバによってMeNBが切り替わったことを表す通知である。この場合、UEは、S-MeNBではなく、T-MeNBとの間でデータの送受信を行うことになる。
(A-4)SeNBは、スプリットベアラ構成の場合は、S-MeNBおよびT-MeNBのどちらかのPDCP処理部を経由してS-GWとデータの送受信を行うことになる。したがって、SeNBに通知が必要な情報は、SeNBが、S-MeNBおよびT-MeNBのどちらのMeNBのPDCP処理部を経由するかの情報である。
前記(B)のデータの送受信経路の切替の変更で対応する場合の具体例として、以下の(B-1)~(B-4)の4つを開示する。
(B-1)S-MeNBからT-MeNBに通知が必要な情報は、SeNBの識別情報である。S-MeNBが、ハンドオーバ前は、どのSeNBと同時通信していたのかを知らないと、ハンドオーバ後に、どのSeNBと同時通信してよいのかが分からないためである。また、T-MeNBは、SeNBが、どのRRCコネクションパラメータで動作しているかのパラメータ情報を知る必要があるので、その情報も通知される。本具体例(B-1)では、SeNBは、データの送受信のみで、制御情報(シグナリング)は、T-MeNBが受け持つようになる場合を想定している。
(B-2)T-MeNBからS-MeNBに通知が必要な情報は、前記具体例(A-2)と同様、MeNBのハンドオーバに成功したか失敗したかの情報、およびS-MeNBのバッファにデータが滞留している場合の、データ転送(Data Forwarding)を行うように指示する通知である。
(B-3)UEに通知が必要な情報は、前記具体例(A-3)と同様、S-MeNBからT-MeNBへ、ハンドオーバによってMeNBが切り替わったことを表す通知である。この場合、UEは、S-MeNBではなく、T-MeNBとの間でデータの送受信を行うことになる。
(B-4)SeNBに通知が必要な情報は、ハンドオーバの完了(成功)によって、S-MeNBからT-MeNBにMeNBが切り替わったことを表す情報である。SeNBは、MeNBに従属した存在であるので、従属先であるMeNBのうち、どのMeNBが、自装置に対する制御信号たとえばシグナリングを送受信しているのかを知り、そのMeNBからの制御に従う必要があるためである。
前述の図26~図30に示すシーケンスにおいて、無線リソースの構成(Configuration)の変更は、(1)ステップST2026、(2)ステップST2056、および(3)ステップST2043の3つのタイミングで行われる。前記(1)~(3)の各タイミングについて、以下に具体的に説明する。
(1)ステップST2026におけるSeNBに対するMeNB変更処理のタイミングでは、ステップST2063の下りパス変更のタイミングの後に、無線リソースの構成(Configuration)の変更が行われることになる。したがって、MeNBがT-MeNBに切り替わり、しかも、S-MeNBのリソースが解放された後であるので、誤って、ハンドオーバ前のリソースで処理されてしまうことを防ぐことができる。また、簡潔な処理で実現することができ、また規模が比較的小さい回路で処理を実現することができる。
(2)ステップST2056におけるSeNBに対するMeNB変更処理のタイミングでは、ステップST2063の下りパス変更のタイミングの前に、無線リソースの構成(Configuration)の変更が行われることになる。したがって、ハンドオーバによって上位装置がS-MeNBからT-MeNBに切り替わる前に、UEとの間の無線通信が、ハンドオーバ後に行われるべき動作となっているという矛盾が発生する。
これによって、前記(1)のタイミングで行われる場合よりも処理が複雑になるが、切り替わりタイミングが早いので、その分、SeNBのみでデータの送受信が行われることによるリスク、たとえばSeNBに複数のUEからアクセスが集中して輻輳状態となることを回避し、安定した動作を実現することができる。
(3)ステップST2043におけるSeNBに対するMeNB変更処理のタイミングは、ステップST2042でT-MeNBが、ハンドオーバ要求に対するAck応答を通知した直後である。本タイミングでは、前記(2)のタイミングよりも、さらに早いタイミングで、無線リソースの構成(Configuration)の変更が行われる。
これによって、前記(2)のタイミングで行われる場合よりも、ハンドオーバに失敗した場合の処理などがさらに複雑になるが、前述のリスクを、より確実に回避することができるので、より安定した動作を実現することができる。
前記(2)および(3)のタイミングにおいて、無線リソースの構成(Configuration)によってデータの送受信ができるのは、上りデータの送受信のみである。下りデータの送受信については、T-MeNBがS-GWからデータを受信した後になる。
実施の形態6.
図32および図33は、実施の形態6の通信システムにおけるEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。図32と図33とは、境界線BL10で接続されている。
前述の実施の形態5では、S-MeNBが再構成(reconfiguration)を行うが、本実施の形態では、T-MeNBが再構成(reconfiguration)を行う。具体的には、本実施の形態では、前述の図26~図30に示す実施の形態5のシーケンスにおいて、図29および図30に示すステップST2025に代えて、図32および図33に示すステップST2680のEPSベアラ#1用MeNB HO処理を行うこと以外は、実施の形態5と同様の処理を行う。
図32および図33に示すステップST2680の処理は、図29および図30に示すステップST2025のEPSベアラ#1用MeNB HO処理と類似するので、同一のステップについては、同一のステップ番号を付して、共通する説明を省略する。
ステップST2680の処理は、図29および図30に示す実施の形態5のステップST2025において、図29のステップST2046およびステップST2047に代えて、ステップST2681およびステップST2682の処理を行うこと以外は、実施の形態5のステップST2025の処理と同様である。
本実施の形態では、ステップST2681において、T-MeNBが、UEに、下りリンク割り当て(DL allocation)情報を通知する。またステップST2682において、T-MeNBが、UEに、RRC接続再構成(RRC Connection Reconfiguration)メッセージを通知する。本実施の形態では、RRC接続再構成メッセージは、モビリティ制御情報を含まない。
このように、前述の実施の形態5では、S-MeNBがUEにRRC接続再構成(RRC Connection Reconfiguration)メッセージを通知するが、本実施の形態では、T-MeNBがUEにRRC接続再構成(RRC Connection Reconfiguration)メッセージを通知する。
これによって、ハンドオーバ元であるS-MeNBではなく、これから通信接続を行うハンドオーバ先であるT-MeNBによって、最適なRRC接続設定が行われることになるので、UEとMeNBとの通信を安定させることができる。
実施の形態7.
図34および図35は、実施の形態7の通信システムにおけるEPSベアラ#1用MeNB HO処理のシーケンスの一例を示す図である。図34と図35とは、境界線BL11で接続されている。
本実施の形態では、前述の図26~図30に示す実施の形態5のシーケンスにおいて、図29および図30に示すステップST2025に代えて、図34および図35に示すステップST2690のEPSベアラ#1用MeNB HO処理を行うこと以外は、実施の形態5と同様の処理を行う。
図34および図35に示すステップST2690の処理は、図29および図30に示すステップST2025のEPSベアラ#1用MeNB HO処理と類似するので、同一のステップについては、同一のステップ番号を付して、共通する説明を省略する。
ステップST2690の処理は、図29および図30に示す実施の形態5のステップST2025に加えて、ステップST2691の処理を行うこと以外は、実施の形態5のステップST2025の処理と同様である。
本実施の形態では、ステップST2646およびステップST2647の前に、ステップST2691において、T-MeNBが、S-MeNBに、RRC接続再構成(RRC Connection Reconfiguration)メッセージおよび下りリンク割り当て(DL allocation)情報を通知する。
このように本実施の形態では、T-MeNBからS-MeNBに対して通知してから、その内容をS-MeNBからUEに通知する。これによって、前述の実施の形態6と同様に、S-MeNBからUEに再構成メッセージを通知するのではなく、T-MeNBから通知された再構成メッセージの内容をS-MeNB経由でUEに通知することになる。
したがって、実施の形態6と同様に、ハンドオーバ元であるS-MeNBではなく、これから通信接続を行うハンドオーバ先であるT-MeNBによって、最適なRRC接続設定が行われることになるので、UEとMeNBとの通信を安定させることができる。
前述の各実施の形態およびその変形例は、SeNBが複数のサービングセルを構成する場合にも適用することができる。また、同様に、MeNBが複数のサービングセルを構成する場合にも適用することができる。SeNBが構成するサービングセルの集合をSCG(secondary cell group)と称し、MeNBが構成するサービングセルの集合をMCG(master cell group)と称することがある。
前述の各実施の形態およびその変形例は、例示に過ぎず、各実施の形態およびその変形例を自由に組合せることができる。また、各実施の形態およびその変形例の任意の構成要素を適宜、変更または省略することができる。
本開示は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、限定的なものではない。例示されていない無数の変形例が、想定され得るものと解される。
51 S-MeNB、52 S-MeNBのカバレッジ、53 T-MeNB、54 T-MeNBのカバレッジ、55,58 SeNB、56,59 SeNBのカバレッジ、57 UE。

Claims (3)

  1. 通信端末と、
    前記通信端末と無線通信を行うための複数のセルを構成する複数の基地局と
    を備える通信システムであって、
    前記複数のセルは、
    スモールセルである第1セルと、
    前記第1セルと共に前記通信端末に第1デュアルコネクティビティを提供するマクロセルである第2セルと、
    前記第1セルと共に前記通信端末に第2デュアルコネクティビティを提供するマクロセルである第3セルと
    を含み、
    前記通信端末は、前記第1デュアルコネクティビティから前記第2デュアルコネクティビティへ移行するために前記第2セルから前記第3セルへのハンドオーバを行う間、前記第1セルとの接続を維持し、
    前記通信端末が前記第2セルから前記第3セルへの前記ハンドオーバを行う間、前記第3セルを構成する前記基地局から前記第2セルを構成する前記基地局への通知と、前記第2セルを構成する前記基地局から前記第1セルを構成する前記基地局への通知とを行うことによって、前記第1セルを用いて構成されているベアラの構成を変更しないことを特徴とする通信システム。
  2. 通信端末と、前記通信端末と無線通信を行うための複数のセルを構成する複数の基地局とを備える通信システムで用いられる通信端末であって、
    前記複数のセルは、
    スモールセルである第1セルと、
    前記第1セルと共に前記通信端末に第1デュアルコネクティビティを提供するマクロセルである第2セルと、
    前記第1セルと共に前記通信端末に第2デュアルコネクティビティを提供するマクロセルである第3セルと
    を含み、
    前記通信端末は、前記第1デュアルコネクティビティから前記第2デュアルコネクティビティへ移行するために前記第2セルから前記第3セルへのハンドオーバを行う間、前記第1セルとの接続を維持し、
    前記通信端末が前記第2セルから前記第3セルへの前記ハンドオーバを行う間、前記第3セルを構成する前記基地局から前記第2セルを構成する前記基地局への通知と、前記第2セルを構成する前記基地局から前記第1セルを構成する前記基地局への通知とを行うことによって、前記第1セルを用いて構成されているベアラの構成を変更しないことを特徴とする通信端末。
  3. 通信端末と、前記通信端末と無線通信を行うための複数のセルを構成する複数の基地局とを備える通信システムで用いられる基地局であって、
    前記複数のセルは、
    スモールセルである第1セルと、
    前記第1セルと共に前記通信端末に第1デュアルコネクティビティを提供するマクロセルである第2セルと、
    前記第1セルと共に前記通信端末に第2デュアルコネクティビティを提供するマクロセルである第3セルと
    を含み、
    前記第1セルおよび前記第2セルは前記基地局または他の基地局によって構成され、前記第3セルは前記基地局によって構成され、
    前記基地局は、
    前記通信端末が前記第1デュアルコネクティビティから前記第2デュアルコネクティビティへ移行するために前記第2セルから前記第3セルへのハンドオーバを行う場合に、前記第1セルを用いて構成されているベアラの構成を前記第2セルから引き継ぎ可能かを判断し、
    前記ベアラの前記構成を前記第2セルから引き継ぎ可能と判断した場合、前記ハンドオーバの間、前記通信端末と前記第1セルとの間の接続を維持することを決定し、
    前記通信端末が前記第2セルから前記第3セルへの前記ハンドオーバを行う間、前記第3セルを構成する前記基地局から前記第2セルを構成する前記基地局への通知と、前記第2セルを構成する前記基地局から前記第1セルを構成する前記基地局への通知とを行うことによって、前記第1セルを用いて構成されている前記ベアラの構成を変更しないことを特徴とする基地局。
JP2020113959A 2014-03-20 2020-07-01 通信システム、通信端末および基地局 Active JP7074806B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022078625A JP2022106987A (ja) 2014-03-20 2022-05-12 移動体通信システム、マスタ基地局、セカンダリ基地局、変更先の基地局、移動端末

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2014058327 2014-03-20
JP2014058327 2014-03-20
JP2014105050 2014-05-21
JP2014105050 2014-05-21

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2016508707A Division JP6731844B2 (ja) 2014-03-20 2015-03-16 通信システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022078625A Division JP2022106987A (ja) 2014-03-20 2022-05-12 移動体通信システム、マスタ基地局、セカンダリ基地局、変更先の基地局、移動端末

Publications (2)

Publication Number Publication Date
JP2020162180A JP2020162180A (ja) 2020-10-01
JP7074806B2 true JP7074806B2 (ja) 2022-05-24

Family

ID=54144576

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2016508707A Expired - Fee Related JP6731844B2 (ja) 2014-03-20 2015-03-16 通信システム
JP2020113959A Active JP7074806B2 (ja) 2014-03-20 2020-07-01 通信システム、通信端末および基地局
JP2022078625A Pending JP2022106987A (ja) 2014-03-20 2022-05-12 移動体通信システム、マスタ基地局、セカンダリ基地局、変更先の基地局、移動端末

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2016508707A Expired - Fee Related JP6731844B2 (ja) 2014-03-20 2015-03-16 通信システム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2022078625A Pending JP2022106987A (ja) 2014-03-20 2022-05-12 移動体通信システム、マスタ基地局、セカンダリ基地局、変更先の基地局、移動端末

Country Status (5)

Country Link
US (3) US10743227B2 (ja)
EP (4) EP4266795A3 (ja)
JP (3) JP6731844B2 (ja)
CN (1) CN106134253B (ja)
WO (1) WO2015141607A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4266795A3 (en) 2014-03-20 2023-12-06 Mitsubishi Electric Corporation Communication system, communication terminal and base station
CN107113901B (zh) * 2014-11-07 2021-02-19 诺基亚技术有限公司 双连接中的数据转发支持
WO2016119109A1 (zh) 2015-01-26 2016-08-04 华为技术有限公司 一种切换装置及方法
CN109479215B (zh) 2016-06-30 2022-07-29 华为技术有限公司 多连接通信方法和设备
CN108990125B (zh) * 2017-06-01 2020-12-22 华为技术有限公司 数据传输的方法、终端设备和网络设备
EP3685619A4 (en) * 2017-09-28 2021-04-07 Samsung Electronics Co., Ltd. METHOD AND NETWORK NODE FOR PERFORMING DATA TRANSMISSION AND MEASUREMENTS ON MULTIPLE PARTS OF BANDWIDTH
EP3697131A4 (en) * 2017-11-14 2020-10-28 Huawei Technologies Co., Ltd. SWITCHING PROCESS AND DEVICE
JP2021511697A (ja) * 2017-12-07 2021-05-06 オッポ広東移動通信有限公司Guangdong Oppo Mobile Telecommunications Corp., Ltd. 端末コンテキスト取得方法及び装置、コンピュータ記憶媒体
US10687263B2 (en) 2018-02-15 2020-06-16 Qualcomm Incorporated Enhanced make-before-break handover
US10893560B2 (en) 2018-06-25 2021-01-12 Verizon Patent And Licensing Inc. Bearer control for secondary radio access technology in dual connectivity networks
US10972950B2 (en) * 2018-07-20 2021-04-06 Qualcomm Incorporated Methods and apparatus for handover enhancements
WO2020087368A1 (en) * 2018-10-31 2020-05-07 Mediatek Singapore Pte. Ltd. Apparatus and mechanism of reordering with dual protocol to reduce mobility interruption in wireless network
WO2020087318A1 (en) 2018-10-31 2020-05-07 Chongqing University Of Posts And Telecommunications Systems and methods for a handover
EP3918832A4 (en) * 2019-01-31 2022-02-23 ZTE Corporation METHOD AND DEVICE FOR CARRIER TRAFFIC MIGRATION IN SYSTEMS WITH MULTICONNECTIVITY
CN112822731A (zh) * 2019-11-18 2021-05-18 上海华为技术有限公司 一种数据处理方法及相关设备
JP2021175107A (ja) * 2020-04-27 2021-11-01 日本電気株式会社 無線端末、センターサーバ装置、及びこれらの方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015141607A1 (ja) 2014-03-20 2015-09-24 三菱電機株式会社 通信システム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5726756B2 (ja) * 2009-12-07 2015-06-03 レノボ・イノベーションズ・リミテッド(香港) 無線通信システム、携帯端末、及びセルサーチ方法
KR101964083B1 (ko) * 2012-10-31 2019-04-01 삼성전자 주식회사 무선 통신 시스템에서 기지국간 반송파 집적을 통한 데이터 전송 방법 및 장치
US9848322B2 (en) * 2013-01-17 2017-12-19 Intel IP Corporation Method, apparatus and system for managing bearers in a wireless communication system
US9713044B2 (en) 2014-01-30 2017-07-18 Sharp Kabushiki Kaisha Systems and methods for dual-connectivity operation
WO2015115458A1 (ja) * 2014-01-31 2015-08-06 京セラ株式会社 基地局、ユーザ端末、及び通信制御方法
US20170034866A1 (en) 2014-01-31 2017-02-02 Telefonaktiebolaget Lm Ericsson (Publ) Method Between Two eNBs to Agree on Radio Resource Configuration for a UE Which Supports Dual Connectivity Between the eNBs
WO2015115621A1 (ja) * 2014-01-31 2015-08-06 京セラ株式会社 通信制御方法、マスタ基地局、セカンダリ基地局、及びユーザ端末
KR101862530B1 (ko) 2014-01-31 2018-06-29 후지쯔 가부시끼가이샤 무선 통신 방법, 무선 통신 시스템, 기지국 및 무선국
US9288694B2 (en) 2014-02-07 2016-03-15 Nokia Solutions And Networks Oy Partial failure handling of bearer mapping in dual connectivity
EP3282760B1 (en) * 2015-04-10 2020-06-03 Kyocera Corporation Method for controlling handover procedure and base station
US10945168B2 (en) * 2016-04-20 2021-03-09 Electronics And Telecommunications Research Institute Handover method
CN118158760A (zh) 2019-01-09 2024-06-07 三菱电机株式会社 用户装置、基站及通信系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015141607A1 (ja) 2014-03-20 2015-09-24 三菱電機株式会社 通信システム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BROADCOM CORPORATION,MCG handover for Dual Connectivity[online], 3GPP TSG-RAN WG2♯85 R2-140531,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85/Docs/R2-140531.zip>,2014年02月14日,第2.1節、第2.2節
Ericsson,Mobility procedures for dual connectivity[online], 3GPP TSG-RAN WG2♯85 R2-140642,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85/Docs/R2-140642.zip>,2014年02月14日,第2,4節
Huawei,MeNB Mobility Procedure[online], 3GPP TSG-RAN WG3♯83 R3-140117,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_83/Docs/R3-140117.zip>,2014年02月14日

Also Published As

Publication number Publication date
JP2022106987A (ja) 2022-07-20
EP3737156A1 (en) 2020-11-11
EP3122119A4 (en) 2017-10-25
EP3122119A1 (en) 2017-01-25
US20180176839A1 (en) 2018-06-21
US11997557B2 (en) 2024-05-28
EP3474600A1 (en) 2019-04-24
JP2020162180A (ja) 2020-10-01
US20220353770A1 (en) 2022-11-03
CN106134253A (zh) 2016-11-16
US10743227B2 (en) 2020-08-11
JP6731844B2 (ja) 2020-07-29
WO2015141607A1 (ja) 2015-09-24
CN106134253B (zh) 2019-11-29
EP4266795A2 (en) 2023-10-25
US20200314715A1 (en) 2020-10-01
JPWO2015141607A1 (ja) 2017-04-06
EP4266795A3 (en) 2023-12-06

Similar Documents

Publication Publication Date Title
JP7074806B2 (ja) 通信システム、通信端末および基地局
JP7187596B2 (ja) 移動体通信システム、基地局
US20230132427A1 (en) Communication system, user apparatus, and base station
JP7313281B2 (ja) 通信システム
JP6968706B2 (ja) 通信システム
JP2024023803A (ja) 通信システム、端末装置およびSgNB
JP7321322B2 (ja) 移動端末装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200701

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211005

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211124

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: 20220412

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220512

R150 Certificate of patent or registration of utility model

Ref document number: 7074806

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150