(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-02-08
(45)【発行日】2024-02-19
(54)【発明の名称】光ワイヤレス通信受信ユニット、システム及び方法
(51)【国際特許分類】
H04B 10/114 20130101AFI20240209BHJP
【FI】
H04B10/114
(21)【出願番号】P 2023502900
(86)(22)【出願日】2021-07-05
(86)【国際出願番号】 EP2021068453
(87)【国際公開番号】W WO2022012985
(87)【国際公開日】2022-01-20
【審査請求日】2023-03-14
(32)【優先日】2020-07-17
(33)【優先権主張国・地域又は機関】EP
【早期審査対象出願】
(73)【特許権者】
【識別番号】516043960
【氏名又は名称】シグニファイ ホールディング ビー ヴィ
【氏名又は名称原語表記】SIGNIFY HOLDING B.V.
【住所又は居所原語表記】High Tech Campus 48,5656 AE Eindhoven,The Netherlands
(74)【代理人】
【識別番号】100163821
【氏名又は名称】柴田 沙希子
(72)【発明者】
【氏名】ヴェント マティアス
(72)【発明者】
【氏名】ストッベラー ピーター ヨハンネス
【審査官】対馬 英明
(56)【参考文献】
【文献】特表2018-538671(JP,A)
【文献】国際公開第2020/101155(WO,A1)
【文献】米国特許出願公開第2009/0252499(US,A1)
【文献】特表2020-503729(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04B 10/00-10/90
H04J 14/00-14/08
(57)【特許請求の範囲】
【請求項1】
自由空間を介して伝播される光信号として天井に取り付けられた送信ユニットのセットのうちの1つの送信ユニットである送信ユニットと受信ユニットとの間でデータを転送するための光ワイヤレス通信(OWC)システムのためのOWC受信ユニットであって、
当該受信ユニットは、
当該受信ユニットのモーション及び当該受信ユニットの回転に起因する向きをセンシングするためのモーションセンサと、
受光を検出するために配置される光ディテクタと、
前記受光から変調データを復調するための復調システムと、
ローカルRFトランシーバと、
前記セットのうちの送信ユニットからデータを受信する一方、当該受信ユニットの将来の向き及び位置の予測を導出する、及び、前記予測から、
当該受信ユニットが前記セットのうちの異なる送信ユニット
のラインオブサイト内にある場合、前記セットのうちの異なる送信ユニットが将来のデータ転送に使用されるべきであると決定し、前記送信ユニットとの通信リンクがまだアクティブである際に、前記セットのうちの当該異なる送信ユニットが通信の準備をするための第1の指示を提供する、及び
当該受信ユニットが前記セットのうちのいずれの送信ユニットのラインオブサイト内にない場合、ローカルRFトランシーバが将来のデータ転送に使用されるべきであると決定し、前記送信ユニットとの通信リンクがまだアクティブである際に、リモートRFシステムがRF通信の準備をするための第2の指示を提供する、
ように構成されるコントローラと、
を含む、OWC受信ユニット。
【請求項2】
前記モーションセンサは、リニア加速度センサ及びターンレートセンサを含む、請求項1に記載のOWC受信ユニット。
【請求項3】
前記モーションセンサは、3軸加速度計及び3軸ジャイロスコープを含む、請求項2に記載のOWC受信ユニット。
【請求項4】
当該受信ユニットは、前記送信ユニットのセットの空間レイアウトを記憶するメモリを含み、前記コントローラは、どの異なる送信ユニットが使用されるべきかを決定するために及び/又は異なる通信システムが使用されるべきであると決定するために前記空間レイアウトを考慮するように構成される、請求項1乃至3のいずれか一項に記載のOWC受信ユニット。
【請求項5】
回転速度が、ラインオブサイト内に来ることになる送信ユニットに関するインディケーションとして使用される、請求項1乃至
3のいずれか一項に記載のOWC受信ユニット。
【請求項6】
前記RFトランシーバを使用して通信している場合、前記コントローラは、
センシングされた向きが変化した後、当該受信ユニットのセンシングされた向き及び動きが所定期間静止していることに対応する場合、複数のOWC送信ユニットを使用する動作に戻す、請求項1乃至
3のいずれか一項に記載のOWC受信ユニット。
【請求項7】
自由空間を介して伝播される光信号として送信ユニットと受信ユニットとの間でデータを転送するための光ワイヤレス通信(OWC)システムであって、
当該システムは、
請求項1に記載のOWC受信ユニットと、
光源と光出力にデータを変調するための変調システムとを各々が含む、天井に取り付けられた送信ユニットのセットと、
前記送信ユニットのセットと通信するシステムコントローラと、
を含む、システム。
【請求項8】
当該システムは、前記送信ユニットのセットの空間レイアウトを記憶するメモリを含み、コントローラが、どの異なる送信ユニットが使用されるべきかを決定するために及び/又は異なる通信システムが使用されるべきであると決定するために前記空間レイアウトを考慮するように構成される、請求項7に記載のシステム。
【請求項9】
自由空間を介して伝播される光信号として天井に取り付けられた送信ユニットのセットのうちの1つの送信ユニットである送信ユニットと受信ユニットとの間でデータを転送するための光ワイヤレス通信(OWC)システムのための受信ユニットのためのOWC方法であって、前記OWCシステムは、通信のための無線周波数(RF)リンクを提供し、当該方法は、
前記送信ユニットから前記受信ユニットにデータを送信することと、
前記受信ユニットのモーション及び前記受信ユニットの回転に起因する向きをセンシングすることと、
前記送信ユニットからデータを受信する一方、前記受信ユニットの将来の向き及び位置の予測を導出することと、
前記予測から、前記受信ユニットが前記セットのうちの異なる送信ユニットのラインオブサイト内にある場合、前記セットのうちの異なる送信ユニットが将来のデータ転送に使用されるべきであると決定する、及び、前記送信ユニットとの通信リンクがまだアクティブである際に、前記セットのうちの当該異なる送信ユニットが通信の準備をするための第1の指示を提供することと、
前記予測から、前記受信ユニットが前記セットのうちのいずれの送信ユニットのラインオブサイト内にない場合、RF通信システムが将来のデータ転送に使用されるべきであると決定する、及び、前記送信ユニットとの通信リンクがまだアクティブである際に、リモートRFシステムがRF通信の準備をするための第2の指示を提供することと、
を含む、方法。
【請求項10】
当該方法は、前記送信ユニットのセットの空間レイアウトを記憶することを含み、当該方法は、どの異なる送信ユニットが使用されるべきかを決定するために及び/又は異なる通信システムが使用されるべきであると決定するために前記空間レイアウトを考慮することを含む、請求項
9に記載の方法。
【請求項11】
コンピュータプログラムコード手段を含むコンピュータプログラムであって、前記コンピュータプログラムコード手段は、当該コンピュータプログラムが請求項1に記載のOWC受信ユニットに含まれるコンピュータで実行された場合、請求項9又は10に記載の方法を実施するように構成される、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、光ワイヤレス通信受信ユニット、システム及び方法に関する。
【背景技術】
【0002】
ライトフィデリティ(Li-Fi:Light Fidelity)は、可視光通信(VLC:Visible Light Communication)も含む、光ワイヤレス通信(OWC:Optical Wireless Communication)の新しいタイプである。LiFi、OWC及びVLCは、ケーブルワイヤ(有線)通信に代わるものであり、光を通信媒体として使用する。
【0003】
光ベースの通信は、ライオンオブサイト(line of sight)が間にあるデバイスに、例えば最大14Gbit/s等、高データレート通信のアビリティ(ability)を提供する。これは、例えば、オフィス環境内の通信デバイスのセットに適用される。
【0004】
国際特許出願WO2020/101155 A1は、屋外VLCネットワークにおいてビークルモビリティをサポートするための方法を開示する。いくつかの技術によれば、ハンドオーバプロセスの発生に先立ち、ハンドオーバ事前通知が、その直後に現在のサービングセルからターゲットセルに移動するビークルのために該ターゲットセルに提供される。事前通知は、ターゲットセルが、ハンドオーバプロセスの発生に先立って、ハンドオーバのためのリソースを予約することを含む、来るべきハンドオーバの準備をすることを可能にする。
【0005】
欧州特許出願EP 3539226 A1は、アプリケーション制御システム内の通信トラフィックを方向付けるための方法であって、アプリケーション制御システムは、光波を使用して通信ユニットにメッセージを送信することができる複数のアプリケーション制御コンポーネントを含む、方法を開示する。アプリケーション制御システム内のアプリケーション制御コンポーネントの及びアプリケーション制御システム内の通信ユニットの位置情報を決定することにより、通信ユニットに対する関心エリアが、少なくとも位置情報に基づいて計算される。通信ユニットの関心エリア内に位置する複数のアプリケーション制御コンポーネントからの1つ以上のアプリケーション制御コンポーネントのサブグループが特定され、アプリケーション制御システムを通るデータパスが、特定されたアプリケーション制御コンポーネントのサブグループを使用して通信ユニットと通信するようにプログラムされる。
【0006】
既知のLiFiプロダクトは、天井に取り付けられる光アクセスポイントのグリッドに依拠する。これらのアクセスポイントのビームは、下の机のレベルにおいて近隣のアクセスポイントとオーバーラップを作るように十分に広い(及びこれにより、大きな視野及び/又はカバレッジエリアを有する)。このようなシステムにおける受信デバイスは、典型的には、机に位置する。
【0007】
設置を簡単にするために、アクセスポイントのグリッドは、例えば、天井の照明器具のグリッドとアラインされる。このような設置における各アクセスポイントは、数平方メートルに到達(可視光の場合、照明)しなければならず、したがって、かなりの円錐エリア(significant conical area)を照らす。このような設置は、(ドングル及び/又はモバイルデバイスに向かう)ダウンリンクに照明光を利用し、モバイルデバイスのユーザを邪魔しないように(アクセスポイントに向かう)アップリンクに赤外光を使用してもよい。代替的に、ダウンリンク及びアップリンクの両方が赤外光を利用し、これにより、照明及び通信インフラストラクチャを少なくとも部分的に解きほぐし(disentangle)てもよい。
【0008】
アクセスポイントと通信するために、ドングルが、ラップトップ又はタブレット等のユーザデバイスに接続される。これらのドングルも、少なくとも1つのアクセスポイントがドングルからの信号を受信することを確実にするように同様の広いビームを発する。アクセスポイント及びドングルのビームは方向が固定され、ゆえに、ビーム方向の調整は必要とされない。
【0009】
各アクセスポイントは、1つ又は複数のトランシーバに接続されるモデムを含む。ユーザデバイスは、光リンクを介してアクセスポイントに接続し、ユーザデバイスも、1つ又は複数のトランシーバに接続されるモデムを含む。
【0010】
モデムの機能は、可視光又は不可視光接続を介してデータを送信及び受信するためのプロトコルを処理することである。モデムトランスミッタは、(例えばLEDを使用して)送信データの電気信号を光信号に変換し、モデムレシーバは、(フォトダイオードを使用して)光信号を電気受信データ信号に変換する。
【0011】
レシーバがモバイルフォン又はタブレットコンピュータ等のモバイルデバイスとして実装される場合、レシーバは、典型的には、使用中に動かされる、例えば、傾けられる。問題の1つは、まさにユーザがデバイスとインタラクションしたい場合、ネットワーク中断を処理する必要があり、レイテンシの増加につながる可能性があることである。
【発明の概要】
【発明が解決しようとする課題】
【0012】
本発明の目的は、従来技術を改善することにあり、この目的は、請求項1に記載の光ワイヤレス通信(OWC:Optical Wireless Communication)受信ユニット、請求項7に記載のOWCシステム、請求項9に記載のOWC方法及び請求項11に記載のコンピュータプログラムによって達成される。
【課題を解決するための手段】
【0013】
一態様による例によれば、自由空間(free space)を介して伝播される光信号として送信ユニットと受信ユニットとの間でデータを転送するための光ワイヤレス通信(OWC:Optical Wireless Communication)システムであって、
システムは、光源と光出力にデータを変調するための変調システムとを各々が含む、送信ユニットのセットを含み、
受信ユニットは、
受信ユニットのモーション(motion)及び向き(orientation)をセンシングする(sense)ためのモーションセンサと、
受光(received light)を検出するように配置される光ディテクタ(light detector)と、
変調データを復調するための復調システムと、
を含み、
システムは、セットのうちの送信ユニットからデータを受信する一方、受信ユニットの将来の向き及び位置の予測を導出する、並びに
予測から、セットのうちの異なる送信ユニットが将来のデータ転送に使用されるべきであると決定する、及び/又は
予測から、異なる通信システムが将来のデータ転送に使用されるべきであると決定する、
ように構成されるコントローラを含む、システムが提供される。
【0014】
このシステムは、将来の位置及び向きの予測を提供することで、ハンドオーバの準備ができるだけ早く、好ましくは通信リンクがまだある場合に準備され、これにより、ハンドオーバ時の通信を最小限の時間で中断させることを可能にする。
【0015】
予測は、位置の範囲及び向きの範囲を生成してもよい。予測は、既存のチャネルが損なわれる前に新しいチャネルが開始されることを可能にするために使用されてもよく、したがって、ハンドオーバにかなりの時間を必要とするプロトコルであっても、時間が節約される。
【0016】
送信ユニットは、現在の送信ユニットとのアクティブな接続に関与することなく受信ユニット信号をサーチしてもよい。受信ユニット信号が読み取られることができる場合、受信ユニットと送信ユニットとの間のすべてのチャネル推定が、古い接続をあきらめることなく行われてもよく、受信ユニットによるアクションは必要とされない。
【0017】
軌道推定(trajectory estimation)の使用は、すべての送信ユニットがその視野内の受信ユニットからのすべての変調光を常時監視する必要を回避する。斯くして、これは、送信ユニットのリソースを低減させる。代わりに、監視は、(動き(movement)又は傾き(tilting)の)予測された軌道に沿うものに制限されてもよい。
【0018】
送信ユニットは、受信ユニットから受信される信号に大きな信号対雑音比(SNR:signal to noise ratio)を見出す場合、このSNRを(調整ノード(coordinating node)として機能する)コントローラにシグナリングする(signal)ことができる。これは、コントローラが、シームレスなダウンストリームハンドオーバを実施することを可能にする。
【0019】
また、アップストリームハンドオーバは、前の送信ユニットと新しい送信ユニットが通信を確立しており、データストリームのオーバーラップ(data stream overlap)が「メイクビフォアブレーク(make before break)」を可能にするため、シームレスであることができる。
【0020】
コントローラは、受信ユニットの一部であってもよい。この場合、受信ユニットは、様々なSNR数値を収集し、ハンドオーバが必要であるかどうかを判断してもよい。受信ユニットは、動きセンシング(movement sensing)及び信号対雑音比のトレンド分析を並行して使用し、実質的な動き(substantial movement)に起因して変更(change)が必要であるか、又はスプリアスな動き(spurious movement)に過ぎなかった場合に切り替え(switchover)を起こさないようにするかを判断することができる。
【0021】
代わりに、コントローラは、送信ユニットの一部であってもよく、又は送信ユニット間に分散されてもよい。
【0022】
好ましくは、システムはさらに、送信ユニットのセットの空間レイアウトを記憶するメモリを含み、コントローラは、どの異なる送信ユニットが使用されるべきかを決定するために及び/又は異なる通信システムが使用されるべきであると決定するために空間レイアウトを考慮するように構成される。
【0023】
例えば、コントローラは、システムの空間レイアウトを考慮して、予測された位置及び向き(の範囲)に適した送信ユニットがあるか否かを決定する。受信ユニットのためのタイムスロットを割り当てる準備があらかじめ開始される、送信ユニットのセットがあってもよい。適切な送信ユニットがない場合、異なる通信システムに切り替える準備が行われてもよく、これにより、動きにもかかわらず通信が継続することが可能である。
【0024】
メモリは、システムコントローラと通信する別個のストレージとして実装されてもよく、又は、システムコントローラのコンポーネントとして実装されてもよく、これは、予測がシステムコントローラで実施される場合にとりわけ有用である。代替的に、予測が受信ユニットのコントローラで実施される場合、メモリは依然としてシステムに実装されてもよく、関連情報が、コンフィギュレーション(configuration)時、又はネットワークへの参加時(固定の場合)若しくは断続的に(可変の場合)、又は受信ユニットに位置するさらなるメモリへの記憶の要求時に受信ユニットに転送されてもよい。
【0025】
モーションセンサは、リニア加速度センサ(linear acceleration sensor)及びターンレートセンサ(turn rate sensor)を含んでもよい。例えば、リニア加速度センサは、3軸加速度計(3-axis accelerometer)を含み、ターンレートセンサは、3軸ジャイロスコープ(3-axis gyroscope)を含む。
【0026】
コントローラは、受信ユニットのマイクロフォンによって収集される音にさらに基づいて予測を導出するように構成されてもよい。これらの音は、手に取られる受信ユニットに関連する情報を提供することができる。
【0027】
コントローラは、
セットのうちの当該異なる送信ユニットが通信の準備をするための指示(instruction)を提供する、及び/又は
当該異なる通信システムが通信の準備をするための指示を提供する、
ように構成されてもよい。
【0028】
この指示は、例えば、送信ユニットのうちの1つとの通信がまだ継続している際に行われる。
【0029】
異なる通信システムには、例えば、WiFi(登録商標)システム又は他のRF通信プロトコルが含まれる。
【0030】
コントローラは、受信ユニットに少なくとも部分的に実装されてもよい。代替的に、コントローラは、受信ユニットからリモートにあり、送信ユニットのセットに結合されるシステムのためのマスタコントローラを含んでもよく、受信ユニットは、
低電力RFリンク、又は
光通信、
を介してコントローラにモーションセンシング情報(motion sensing information)を提供するように構成されてもよい。
【0031】
また、自由空間を介して伝播される光信号として送信ユニットのセットのうちの1つの送信ユニットである送信ユニットと受信ユニットとの間でデータを転送するための光ワイヤレス通信(OWC:Optical Wireless Communication)システムのための受信ユニットであって、
受信ユニットのモーション及び向きをセンシングするためのモーションセンサと、
受光を検出するように配置される光ディテクタと、
変調データを復調するための復調システムと、
セットのうちの送信ユニットからデータを受信する一方、受信ユニットの将来の向き及び位置の予測を導出する、並びに
予測から、セットのうちの異なる送信ユニットが将来のデータ転送に使用されるべきであると決定する、及び/又は
予測から、異なる通信システムが将来のデータ転送に使用されるべきであると決定する、
ように構成されるコントローラと、
を含む、受信ユニットが提供される。
【0032】
受信ユニットのこの実施は、予測を生成するためのコントローラと、任意選択的に、メモリとを組み込む。
【0033】
また、自由空間を介して伝播される光信号として送信ユニットのセットのうちの1つの送信ユニットである送信ユニットと受信ユニットとの間でデータを転送するための光ワイヤレス通信(OWC:Optical Wireless Communication)方法であって、
送信ユニットから受信ユニットにデータを送信することと、
受信ユニットのモーション及び向きをセンシングすることと、
送信ユニットからデータを受信する一方、受信ユニットの将来の向き及び位置の予測を導出することと、
予測から、セットのうちの異なる送信ユニットが将来のデータ転送に使用されるべきであると決定すること、及び/又は
予測から、異なる通信システムが将来のデータ転送に使用されるべきであると決定することと、
を含む、方法が提供される。
【0034】
方法は、送信ユニットのセットの空間レイアウトを記憶することを含み、方法は、どの異なる送信ユニットが使用されるべきかを決定するために及び/又は異なる通信システムが使用されるべきであると決定するために空間レイアウトを考慮することを含んでもよい。
【0035】
方法はソフトウェアで実施されてもよく、また、方法を実施するためのコンピュータプログラムが提供されてもよい。
【0036】
上記では、(複数の)送信ユニット及び(複数の)受信ユニットの機能性は、少なくとも送信ユニット及び受信ユニットであるものとして述べられたが、送信ユニットはトランシーバユニットを使用して実装されてもよく、受信ユニットはさらなるトランシーバユニットを使用して実装されてもよく、これにより、本発明を損なうことなくトランシーバ間の双方向通信を可能にしてもよいことは明らかであろう。
【0037】
本発明のこれらの及び他の態様は、以下に述べられる実施形態を参照して明らかになり、解明されるであろう。
【図面の簡単な説明】
【0038】
本発明のより良好な理解のために、及び、どのようにして本発明が実施され得るかをより明らかに示すために、例としてのみ、添付の図面が参照される。
【
図1】
図1は、LiFiシステムの典型的な構成を示す。
【
図2】
図2は、本発明によるLiFiシステムを示す。
【
図3】
図3は、アップリンクとダウンリングの違いを説明するために使用される。
【
図4】
図4は、光ワイヤレス通信(OWC)方法を示す。
【発明を実施するための形態】
【0039】
本発明が、図を参照して述べられる。
【0040】
詳細な説明及び特定の例示は、装置、システム及び方法の例示的な実施形態を示すものであるが、説明のみを目的としたものであり、本発明の範囲を限定することを意図したものではないことが理解されるべきである。本発明の装置、システム及び方法のこれら及び他の特徴、態様及び有利な点は、以下の説明、添付の特許請求の範囲、及び添付の図面からよりよく理解されることになるであろう。図面は単に概略的なものであり、縮尺通りに描かれていないことを理解されたい。同じ参照番号は、図面全体にわたって同じ又は類似の部分を示すために用いられることも理解されたい。
【0041】
図1は、天井に取り付けられたインフラストラクチャを形成する送信ユニット10のセットと、LiFi受信ユニット12とを含む典型的なLiFiシステムを示している。送信ユニットは、アクセスポイント(AP)として知られ、好ましくは、例えば、UTPを使用するEthernet(登録商標)リンク又は光ファイバネットワーク等の有線リンクによって、バックボーンにリンクされ、AP及び/又はグローバルシステムコントローラが、例えば、ハンドオーバ時に、アラインする(align)ことを可能にする。受信ユニットは、エンドデバイス(ED)として知られる。
【0042】
各APは、1つ又は複数のLiFiトランシーバに接続されるモデムを含む。エンドデバイスは、光リンク(optical link)を介してAPに接続することができる。各EDも、1つ又は複数のLiFiトランシーバに接続されるモデムを含む。LiFiモデムの機能は、可視光又は不可視光接続を介してデータを送信及び受信するための物理層(PHY)及びメディアアクセス制御層(MAC)プロトコルを処理することである。
【0043】
LiFiトランシーバは、モデムの送信データの電気信号を(例えば、LED、VCSEL又はレーザダイオードを介して)光信号に変換するトランスミッタと、光信号を(例えば、フォトダイオードを介して)モデムの受信データの電気信号に変換するレシーバを含む。エンドデバイスは、例えば、ラップトップ等のモバイルデバイスに取り付けられるドングル14によって実装される。後付けする代わりに、レシーバ機能は、理想的には、モバイルデバイス自体に統合されることが想定され、このようにして、ラップトップ、タブレット、モバイルフォン及び/又は他のデバイスが、ドングルを必要とせずに光通信を使用してもよい。モバイルデバイスは、オフィス又は会議室のテーブルの上に置かれることが多い。
【0044】
LiFiエンドポイントが統合された又は取り付けられたモバイルデバイス、すなわち、エンドデバイスが扱われるう場合、これは、典型的には、傾けられることになる。問題の1つは、まさにユーザがデバイスとインタラクションしたい場合、ネットワーク中断を処理する必要があり、レイテンシの増加につながる可能性があることである。
【0045】
会議及びディスカッション中、ユーザは、典型的には、モバイルデバイスをテーブルの上に置き、これは、LiFiを介した安定的な接続を可能にする。ユーザがモバイルデバイスを手に取る場合、モバイルデバイスは、典型的には、傾けられ、これは、アップリンクビームがすぐに天井の異なるスポットに方向付けられることを意味する。ダウンリンクビームは、モバイルデバイスにおけるディテクタに依然到達し得る。ダウンリンクが依然機能するかどうかは、ディテクタの指向性、例えば、モバイルデバイスにおけるディテクタの視野角及び/又はコーン(cone)に依存する。
【0046】
本発明は、受信ユニットのモーション及び向きをセンシングするためのモーションセンサを有する受信ユニット(すなわち、ED)を使用する光ワイヤレス通信(OWC)システムを提供する。(受信ユニット若しくは送信ユニットの一部であってもよい又は両方の外部にあってもよい)システムのコントローラは、送信ユニット(すなわち、AP)からデータを受信する一方、受信ユニットの将来の向き及び位置の予測を導出するように構成される。予測から、セットのうちの異なる送信ユニットが将来のデータ転送のために選択されてもよく、及び/又は、異なる通信システムが将来のデータ転送のために選択されてもよい。どのオプションが使用されることになるかは、コンテキスト(context)に依存してもよい。例えば、天井に取り付けられたLiFi APの規則的なアレイが設けられ、ユーザが部屋の中央に位置するオフィスを考える。この場合、動き(movement)が発生すると、この結果、一般的には、別のLiFi APがラインオブサイトに入ることになる。しかしながら、ユーザがアレイの端に位置する場合、動きの結果、ラインオブサイト内にLiFi APが存在しない状況が生じる可能性がある。このようなシナリオでは、RFベースのシステム等、異なる通信システムへのバーチカルハンドオーバ(vertical handover)が整えられ(in order)てもよい。
【0047】
図2は、本発明によるシステムの実施の一例を示している。システムは、自由空間を介して伝播される(例えば、300GHz~430THzの赤外線の範囲における)光信号として送信ユニット10と受信ユニット12との間でデータを転送するためのものである。
【0048】
システムは、ダウンリンク、すなわち、送信ユニットから受信ユニットへのデータ転送を参照して述べられる。しかしながら、典型的には、双方向のデータ転送があり、システムは相応に理解されるべきである。アップリンクは、光学的(例えば、赤外線)であってもよく、又はRF接続であってもよい。
【0049】
システムは、光源22と光出力にデータを変調するための変調システム20とを各々が含む、送信ユニット10のセットを含む。各送信ユニットは、ローカルコントローラ23を有する。
【0050】
受信ユニット12は、受信ユニットのモーション及び向きをセンシングするための、モーションセンサ24を含む。光ディテクタ26が、受光を検出するために配置され、復調システム28が、変調データを復調するために設けられる。
【0051】
受信ユニットも、ローカルコントローラ30を有する。
【0052】
上記の説明から明らかなように、送信ユニットも、光ディテクタ及びデモジュレータを含んでもよく、受信ユニットも、光源及びモジュレータを含んでもよい。しかしながら、アップリンクは、代わりに、WiFi等の別の通信システムによって実施されてもよい。受信ユニットは、WiFiトランシーバ32を備えて示されている。これは、LiFi APが視界にない場合にダウンリンク通信に使用されてもよい。また、他の代替的な通信システムが採用されてもよい。
【0053】
システム全体は、システムコントローラ34を有する。受信ユニット及び送信ユニットは別個のものとして示されているが、それらのうちの一方又は他方に組み込まれてもよい。コントローラ34は、セットのうちの送信ユニットからデータを受信する一方、受信ユニットの将来の向き及び位置の予測を導出するように構成される。
【0054】
メモリ40は、送信ユニットのセットの空間レイアウトを記憶し、システムコントローラ34は、どの異なる送信ユニットが使用されるべきかを決定するために及び/又は異なる通信システムが使用されるべきであると決定するために空間レイアウトを考慮する。
【0055】
メモリは、各APと共有されてもよく、又は(図示のように)システムコントローラ34が通信する中央ユニットの一部であってもよい。EDが、将来の位置及び向きの予測、並びに視界に入ることになるAPのアセスメント(assessment)を行う場合、EDは、レイアウト情報をメモリから取得し、ローカルに記憶してもよい。LiFiインフラストラクチャは一般に(とりわけ、天井に取り付けられたLiFi APの場合)固定されるので、斯かる情報は、EDがネットワークに参加すると記憶されてもよい。
【0056】
予測から、システムコントローラは、セットのうちの異なる送信ユニットが将来のデータ転送に使用されるべきであると決定する、及び/又は、予測から、異なる通信システムが将来のデータ転送に使用されるべきであると決定することが可能である。
【0057】
これにより、このシステムは、位置及び向きの予測を提供することで、ハンドオーバの準備ができるだけ早く準備され、これにより、ハンドオーバ時の通信を最小限の時間で中断させることを可能にする。
【0058】
予測は、例えば、位置の範囲及び向きの範囲を生成する。予測は、既存のチャネルが損なわれる前に新しいチャネルが開始されることを可能にするために使用され、したがって、ハンドオーバにかなりの時間を必要とするプロトコルであっても、時間が節約される。
【0059】
軌道推定の使用は、すべての送信ユニットがその視野内の受信ユニットからのすべての変調光を常時監視する必要を回避する。斯くして、予測は、EDからの信号を「スニッフィングする(sniff)」ようにAPのサブセットをトリガするために使用されてもよい。これは、送信ユニットのリソースを低減させる。例えば、電力消費が節約されるだけでなく、別の差し迫った又は現在の接続に必要とされ得るデモジュレータが縛り付けられ(tied up)ない。
【0060】
(現在使用中のものではない)送信ユニットは、受信ユニットから受信される信号に大きな信号対雑音比(SNR)を見出す場合、このSNRを、調整ノードとして機能する、コントローラにシグナリングすることができる。この場合、コントローラは、候補の受信ユニットの複数のSNRを比較し、最良の新しい送信ユニットに接続ハンドオーバを命令してもよい。この場合、送信ユニットは、直接引き継ぎを開始することができるようにすでにチャネルを推定していてもよい。これは、シームレスなダウンストリームハンドオーバのオプションを提供する。
【0061】
また、アップストリームハンドオーバは、前の送信ユニットと新しい送信ユニットが通信を確立しており、データストリームのオーバーラップが「メイクビフォアブレーク」を可能にするため、シームレスであることができる。前の送信ユニットは、新しい送信ユニットが成功裏のパケットの受信をシグナリングする場合、通信を停止することができる。受信ユニットは、自身を新しい送信ユニットに同調する(tune)。
【0062】
コントローラは、受信ユニットの一部であってもよい。この場合、受信ユニットは、様々なSNR数値を収集し、ハンドオーバが必要であるかどうかを判断してもよい。受信ユニットは、動きセンシング及びSNRのトレンド分析を並行して使用し、実質的な動きに起因して変更が必要であるか、又はスプリアスな動きに過ぎなかった場合に切り替えを起こさないようにするかを判断することができる。これは、受信ユニットが、空間のマップがなくても、軌道推定を高めるために送信ユニットの方向及びロケーションを適応的に学習することを可能にする。しかしながら、光ストリームの観察が、実際のマップを用いて推定された位置及び方向を調整することを可能にし得るように、部屋マップ(room map)が、第1の接続された送信ユニットから受信ユニットに(上記のように)配信されてもよい。
【0063】
送信ユニットは、現在の送信ユニットとのアクティブな接続に関与することなく受信ユニット信号をサーチしてもよい。受信ユニット信号が読み取られることができる場合、受信ユニットと送信ユニットとの間のすべてのチャネル推定が、古い接続をあきらめることなく行われてもよく、受信ユニットによるアクションは必要とされない。
【0064】
例えば、コントローラは、システムの空間レイアウトを考慮して、予測された位置及び向き(の範囲)に適した送信ユニットがあるか否かを決定する。受信ユニットのためのタイムスロットを割り当てる準備が開始される、送信ユニットのセットがあってもよい。適切な送信ユニットがない場合、異なる通信システムに切り替える準備が行われてもよい。モーションセンサ24は、例えば、動き検出(movement detection)のためのリニア加速度センサ及びターンレートセンサを含む。例えば、リニア加速度センサは、3軸加速度計を含み、ターンレートセンサは、3軸ジャイロスコープを含む。また、モーションセンサは、向きを検出するためのものであり、斯くして、コンパス及び/又はチルトセンサ(tilt sensor)等の向きセンサを含んでもよい。「モーションセンサ(motion sensor)」という用語は、動き及び向きの検出のためのセンサの任意の組み合わせを包含するために使用される。
【0065】
動き及び向きの推定は、モーションセンサ情報を洗練させるために追加の仮定を使用してもよい。例えば、人は後ろ向きに、モバイルを前向きに手に持って歩くことはないと仮定されることができる。EDがヘッドセットにある場合、これは、さらなる追加の情報を与える。
【0066】
また、受信ユニットは、一例においてマイクロフォン36を有し、音が、予測の導出を支援するために使用される。デバイスを扱うノイズがマイクロフォンによって拾われるので、音は、EDが扱われているという明らかなインディケーションを与えるために使用されることができる。EDの取り扱いは、傾きの検出に先立ち警告を発することができ、早期に確立された代替のデータ接続又はAPにリダイレクトしてもよい。また、音の検出は、モーションセンシング及び軌道推定を優先又はアクティブにするために使用されてもよい。これは、所定の時間中にモーション/向きの変化が検出されない(及びノイズが検出されない)場合にモーション/軌道推定がパワーダウンされ得るので、電力消費を減らすために使用されてもよい。この場合、モーション/軌道推定は、マイクロフォンからの音声入力における音の検出時に再開されてもよい。
【0067】
また、所定の閾値を超える音に基づいてモーション/軌道推定をトリガすることは、不必要な電力消費をもたらす可能性があるため、機械学習が導入され、デバイスが方向/向きを変える前の音声信号の共通性/相関が音声トリガプロファイルを定義するために使用される学習フェーズによって、処理されるために典型的な音を特徴付けてもよい。この場合、通常動作中、音声トリガプロファイルに対応する音声入力が、モーション/軌道推定をウェイクアップするために使用されてもよい。
【0068】
追加の任意選択的なモードは、新しいAPが利用可能ではない軌道に沿った動きではなく、何らかの動き(すなわち、検出されたターンレート>0)が起こる場合にRFベースの通信に切り替えることを提供することである。LiFiリンクは、デバイスが再び作業面上に又は安定した操作角度に置かれるので、ターンレートがゼロに近い場合にのみ再確立されてもよい。モバイルデバイスの回転又は取り扱いが検出され次第、接続システムは、異なるネットワーク、例えば、WiFi、LTE又は5G等に接続することを試みてもよい。これは、引継ぎ(take over)アクションが準備され得る前に通信が割り込まれることになるので信号対ノイズ比を測定するだけよりも効率的である。
【0069】
好ましくは、LiFiからRFに切り替える代わりに、RFベースの通信リンクは、EDでのモーションの検出時に並行してアクティブにされてもよい。このようにして、EDによるモーション及び/又は評価に関する情報は、LiFi APへのラインオブサイトリンクがない場合でも、予測されるAPへのハンドオーバを支援するために、LiFi AP及び/又はシステムコントローラに伝えられてもよい。このようにして、LiFiリンクはできるだけ長くアクティブに維持されるが、(別のLiFi APへの)ホリゾンタルハンドオーバ(horizontal handover)及び/又は(WiFi APへの)バーチカルハンドオーバ(vertical handover)のいずれかの準備がなされることができる。WiFiリンクは、ニードトゥハブベースで(on a need-to-have basis)アクティブに保たれることができる。
【0070】
追加の入力が、予測を支援するために使用されてもよい。例えば、EDの取り扱いは、音に基づくだけでなく、タッチ検出エレクトロニクスによる又はカメラ等の光学的センシング手段によるユーザの手の接近に基づいて検出されてもよい。
【0071】
最良の結果を得るために、アップリンク及びダウンリンクが、一緒に次のAPロケーションに切り替えられてもよい。接続は、例えば、EDのターンレートが閾値(0.1度/秒等)を下回ると確立されてもよい。これにより、すぐに更新されることを必要とするハンドオーバが行われないようにすることができる。
【0072】
APコンフィギュレーションを記憶するためのメモリが前述されている。しかしながら、室内のAPの位置と向きを関連付けるために、代替的に、又は追加的に、自己学習アプローチが使用されてもよい。また、磁気コンパスが用いられてもよい。回転速度プロファイルを観察することによって決定されることができる、推定最終角度が使用されてもよく、これは、動きが停止する可能性のある場所を決定するために処理されてもよい。
【0073】
ハンドオーバは、上述したように現在のLiFiリンクが中断される前に開始されることが好ましい。加速度計は、実際の角度ターン(angular turn)がなされる前でも動きの傾向(tendency of movement)をセンシングすることができる。これにより、予測された軌道におけるAPは、すでにモバイルデバイスのビームをサーチすることができる。これは、再接続を大幅にスピードアップすることができる。
【0074】
ダウンリンクは、角度変化がアップリンクビームに対するものと同様のドラスティックな影響を有さないので、サーチ中に維持されることができ、アップリンク接続が既になされている場合にのみジャンプしてもよい。
【0075】
図3は、どのようにアップリンクとダウンリンクのこの非対称性が、ダウンリンクの受信は最大限のLiFiレシーバに対し広い角度範囲で可能であるのに対し、アップリンク送信はできる限り1つのアクセスポイントに送信エネルギを集中させるためにより狭いビームを使用するという事実に由来するかを示している。
【0076】
図3は、ED光学系50が、フォトディテクタ52及びIRエミッタ54があるアクセスポイント10の方に向けられていることを示している。ED光学系は、右の画像において角度θだけ傾けられていることが示されている。これは、発せられたビーム56をもはやフォトディテクタ52に届かなくする。傾けられたEDは、APから来るビーム58を依然として受けることができる。
【0077】
ハンドオーバシーケンスは、例えば、プログラムされる。現在のAPから、APのシーケンスが、現在の回転方向に沿って評価されてもよい。回転速度は、どのAPがどの瞬間にサイト(sight)に入りそうであるというインディケーションを与える得る。評価は、経路(path)がLiFi APによってシームレスにサポートされることができず、WiFi等の代替の通信リンクが確立される必要があることを知るために実行されてもよい。
【0078】
速度及び回転方向の変化は、空間におけるLiFiビームの軌道を繰り返し洗練させるために使用されることができる。
【0079】
システムは、代替の通信システムが使用された場合にLiFiに戻る(switch back)必要もある。この場合、スターティングポイントは、モバイルEDのRFベースの接続(例えば、WiFi、LTE又は5G)である。その後、モバイルデバイスは、上述したように傾けられる。情報が、モーション及び向きセンサから獲得される。EDが机の上に置かれると、モーション情報は安定する。安定したレベルに達した後、接続はLiFiに戻される。
【0080】
ここで、完全性のために、典型的な接続プロセスが、ITU-TホームネットワーキングG.vlcプロトコル(G.9991)に基づいて述べられる。受信ユニット(ED)が送信ユニット(AP)のカバレッジエリアに入る場合、以下のステップが取られる。
【0081】
1.登録(Registration)
EDは、APによって送信される専用フレームを検出する:MAP-D(Default Medium Access Plan)。MAP-Dフレームを検出するための時間は、APがMAP-Dフレームを送信する頻度に依存する。現在提案されているLiFi実装において、APは、MACサイクル(40ms)ごとにフレームを送信する。
【0082】
フレームMAP-Dから取得される情報により、EDは、別の非デフォルトフレームを復号できるはずである:MAP-A。APは、MACサイクルごとにMAP-Aフレームを送信しなければならない。MAP-Aフレームは、MACサイクル内で他のフレームがどこで見つかるかを伝える。
【0083】
フレームMAP-Aから取得される情報により、EPは、MACサイクル内でRCBTS(Registration Contention Based Time Slot)を介してAPに登録することができる。RCBTSは、フレームMAP-Aにおいて示される。APは、200ms以内に応答しなければならない。
【0084】
登録のための総時間は、典型的には、350ms以内である。
【0085】
2.チャネル推定(Channel estimation)
一般に、レシーバはほぼ制御できている(mostly in control)。レシーバは、テスト信号を測定し、BAT(Bit Allocation Table)を決定する。MACサイクルの一部/領域に各々適用される、複数のBATが決定されることができる。レシーバは、(MACサイクルの専用部分で発生する)プローブフレームの発生をトランスミッタに要求し得る。トランスミッタは、これらのプローブフレームを送信するためにリソース(タイムスロット)を割り当てる必要がある。
【0086】
また、レシーバは、フレームのヘッダとペイロードの間にACEシンボル(Additional Channel Estimation)を追加するようトランスミッタに要求し得る。レシーバはBATを決定すると、BATをトランスミッタに提供する。(MACサイクル内の異なる領域に対する)複数のBATがある場合、トランスミッタは、相応に適切なBATを選択する。トランスミッタは、各フレームのヘッダにおいてBAT-IDでBATを示す。
【0087】
チャネル推定は、例えば、約1秒の継続時間(duration)を有する。
【0088】
チャネル通信のポイントまでの、新しいLiFiチャンネルの確立は、10~20秒かかり得る。チャネルが接続を失った後の再接続である場合、既知のソフトウェアリファインメントが存在し、時間が10秒以下、例えば、2~3秒に短縮されることを可能にする。このアプローチは、あるAPから別のAPへのハンドオーバにも適用され得る。
【0089】
本発明の予測は、既存の通信リンクがまだアクティブである際に、ハンドオーバ(すなわち、上記の登録及び推定)を事前に準備することによって、この典型的な2~3秒の中断を低減又は排除するために使用される。
【0090】
このようなハンドオーバ中に古いAPから候補の新しいAPに渡されるべき情報には、例えば、当該EDのMACアドレスが含まれる。さらに、割り当てられたIPアドレス、暗号化システムのための鍵等のセキュリティ情報、割り当てられたバンド及びビットローディング等の使用された物理層パラメータを提供してもよい。
【0091】
また、APは、WiFi(登録商標)又は任意のBluetooth(登録商標)接続を介した並列チャネルのためのMAC/IPアドレス等、利用可能なRF接続に関する情報を同じEDに転送することができる。また、受信ユニットは、(軌道予測とは無関係に)他のAP信号を時折(occasionally)サーチしてもよい。
【0092】
図4は、送信ユニットのセットのうちの1つの送信ユニットである送信ユニットと受信ユニットとの間でデータを転送するための光ワイヤレス通信(OWC:Optical Wireless Communication)方法を示している。
【0093】
ステップ60において、送信ユニットから受信ユニットにデータが送信される。
【0094】
ステップ62において、受信ユニットのモーション及び向きがセンシングされる。
【0095】
ステップ64において、送信ユニットからデータを受信する一方、受信ユニットの将来の向き及び動きの予測が導出される。予測に依存して、ステップ66において、セットのうちの異なる送信ユニットが特定されてもよく、あるいは、ステップ68において、異なる通信システムが将来のデータ転送に使用されるべきであると決定されてもよい。
【0096】
上述したように、ある実施形態は、複数のコントローラを利用する。各コントローラは、必要とされる様々な機能を実行するために、ソフトウェア及び/又はハードウェアを用いて、種々のやり方で実装されることができる。「プロセッサ」は、所要の機能を実行するように、ソフトウェア(例えば、マイクロコード)を使用してプログラムされてもよい、1つ以上のマイクロプロセッサを採用する、コントローラの一例である。コントローラは、プロセッサを用いて、又はプロセッサを用いずに実装されてもよく、また、一部の機能を実行するための専用ハードウェアと、他の機能を実行するためのプロセッサ(例えば、1つ以上のプログラムされたマイクロプロセッサ、及び関連回路)との組み合わせとして実装されてもよい。
【0097】
本開示の様々な実施形態で採用されてもよいコントローラ構成要素の例としては、限定するものではないが、従来のマイクロプロセッサ、特定用途向け集積回路(ASIC:application specific integrated circuit)、及びフィールドプログラマブルゲートアレイ(FPGA:field-programmable gate array)が挙げられる。
【0098】
様々な実装形態では、プロセッサ又はコントローラは、1つ以上の記憶媒体、例えば、RAM、PROM、EPROM、及びEEPROM等の、揮発性及び不揮発性のコンピュータメモリに関連付けられてもよい。記憶媒体は、1つ以上のプロセッサ及び/又はコントローラ上で実行されると、所要の機能を実行する、1つ以上のプログラムでエンコードされてもよい。様々な記憶媒体は、プロセッサ又はコントローラ内に固定されてもよく、あるいは、それらの記憶媒体上に記憶されている1つ以上のプログラムが、プロセッサ又はコントローラ内にロードされることができるように、可搬性であってもよい。
【0099】
図面、本開示、及び添付の請求項の検討によって、開示される実施形態に対する変形形態が、当業者により理解されることができ、また、特許請求される発明を実施する際に実行されることができる。請求項では、単語「含む」は、他の構成要素又はステップを排除するものではなく、不定冠詞「1つの(a)」又は「1つの(an)」は、複数を排除するものではない。
【0100】
特定の手段が、互いに異なる従属請求項内に列挙されているという単なる事実は、これらの手段の組み合わせが、有利に使用され得ないことを示すものではない。
【0101】
「に適合される」という用語が特許請求の範囲又は明細書において使用される場合、「に適合される」という用語は、「に構成される」という用語と同等であることが意図されていることに留意されたい。
【0102】
請求項中のいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。