以下、添付図面を参照しながら本開示での実施形態を詳細に説明する。なお、図面の説明において同一または同等の要素には同一の符号を付し、重複する説明を省略する。
呼制御システムは、発信端末と着信端末との間の呼および通話を制御するコンピュータシステムである。呼とは発信端末と着信端末との間で一時的に占有される通信経路のことをいう。発信端末とは最初に呼接続を要求する通信端末のことをいい、着信端末とはその呼接続要求に応答する通信端末のことをいう。これら二つの通信端末間で呼が確立されることで、発信者(発信端末のユーザ)および着信者(着信端末のユーザ)は会話することができる。通話とは、発信端末と着信端末との間で送受信される音声を意味し、また、発信端末と着信端末との間での音声の送受信も意味する。
本実施形態では、呼制御システムは、発信端末と着信端末との間の通話をテキストに変換して、変換されたテキストを発信端末および着信端末の少なくとも一方に表示させる音声テキスト化サービス(これは音声認識サービスともいう。)を実行する。本開示では、変換されたテキストを音声テキストともいう。
図1は実施形態に係る呼制御システム1の全体構成を示す図である。呼制御システム1は、発信端末31が在圏する発側ネットワーク21と、着信端末32が在圏する着側ネットワーク22と、発側ネットワーク21および着側ネットワーク22を接続するコアネットワーク10とを備える。呼制御システム1では、複数の装置および端末の間で制御信号が伝送されることで呼(通信経路)が確立され、音声を示すデータ信号がその呼を介して伝送されることで、通話が可能になる。
発信端末31および着信端末32はいずれも、通話機能を有する通信端末である。発信端末31および着信端末32のそれぞれは固定端末でもよいし携帯端末でもよい。発信端末31および着信端末32の例として、携帯電話機、スマートフォン、タブレット端末、ウェアラブル端末、またはパーソナルコンピュータが挙げられるが、端末の種類はこれらに限定されない。発信端末31と着信端末32とで端末の種類が同じでもよいし異なってもよい。
発側ネットワーク21および着側ネットワーク22はいずれも、端末が直接に接続するアクセスネットワークである。アクセスネットワークの構成は限定されない。例えば、アクセスネットワークは任意の無線ネットワークまたは有線ネットワークであってもよい。発側ネットワーク21と着側ネットワーク22との間でアクセスネットワークの種類(プロトコル)が同じでもよいし異なってもよい。
コアネットワーク10は、呼制御システム1の中核を成すネットワークであり、様々な通信制御装置を備える。本実施形態では、コアネットワーク10はIMSネットワークであるとする。IMSネットワークは、通信プロトコルとしてSIPを用い、データ通信だけでなく音声または動画のリアルタイム通信を実現するマルチメディアサービスを提供できるネットワークである。IMSネットワークでは、呼セッション制御機能(CSCF:Call Session Control Function)、アプリケーションサーバ(AS:Application Server)、ゲートウェイ、加入者管理機能(HSS:Home Subscriber Server)などの複数の通信制御装置により呼が処理される。CSCFは、呼またはセッションを設定したり、予め定められたサービスを起動したりする呼制御装置である。アプリケーションサーバは、予め定められた付加サービス(例えば、音声テキスト化サービス)を実行したり、その付加サービスの実行の可否を判定したりする装置である。ゲートウェイは、アクセスネットワークとコアネットワークとを接続する装置である。HSSはユーザのプロファイル(加入者情報)を記憶する装置(データベース)である。
本実施形態では、コアネットワーク10は、MCE(Media Composition Enabler)およびSMS-GW(SMSゲートウェイ)という2種類の通信制御装置をさらに備える。MCEは通話の付加機能を提供するメディア処理装置である。SMS-GWは、コアネットワークと他のネットワークとを接続するゲートウェイの一種であり、ショートメッセージサービス(SMS)を提供する装置である。
図1は、付加サービスを伴う呼の制御に特に関連する通信制御装置を示し、具体的には、発側CSCF11、着側CSCF12、発側AS13、着側AS14、発側MCE15、着側MCE16、発側SMS-GW17、および着側SMS-GW18を示す。
発側CSCF11および着側CSCF12はいずれも、発信端末31と着信端末32とを通信接続するための呼制御を実行する。発側CSCF11と着側CSCF12との間で制御信号およびデータ信号(例えば音声データ)が送受信されることで、発側と着側とが相互に接続される。発側AS13は発側のアプリケーションサーバであり、着側AS14は着側のアプリケーションサーバである。発側MCE15は発側のメディア処理装置であり、着側MCE16は着側のメディア処理装置である。発側SMS-GW17は発側のSMSゲートウェイであり、着側SMS-GW18は着側のSMSゲートウェイである。
図1はさらに発側Webサーバ41、着側Webサーバ42、および音声認識エンジン43を示す。発側Webサーバ41および音声認識エンジン43は、発信端末31に音声テキスト化サービスを提供する発側サービス基盤を構成する。着側Webサーバ42および音声認識エンジン43は、着信端末32に音声テキスト化サービスを提供する着側サービス基盤を構成する。音声認識エンジン43は、発側および着側の双方により用いられる共通のコンピュータであり、音声認識を用いて音声をテキストに変換する。発側および着側のサービス基盤はいずれも、コアネットワーク10とは別の通信ネットワーク内に設けられる。発側Webサーバ41は、発信端末31、発側AS13、および発側MCE15のそれぞれとデータ通信を実行することができる。着側Webサーバ42は、着信端末32、着側AS14、および着側MCE16のそれぞれとデータ通信を実行することができる。音声認識エンジン43は発側MCE15および着側MCE16のそれぞれとデータ通信を実行することができる。発信端末31は発側Webサーバ41と接続することで音声テキスト化サービスを発信者に提供することができる。着信端末32は着側Webサーバ42と接続することで音声テキスト化サービスを着信者に提供することができる。
本実施形態では、コアネットワーク10はセッションデータベース(セッションDB)19をさらに備える。セッションデータベース19は、音声テキスト化サービスを伴う呼(セッション)に関するセッション情報を記憶する装置(記憶部)であり、発側および着側の双方により用いられる共通のデータベースである。セッションデータベース19は発側AS13および着側AS14にアクセスされ得る。
例えば、一つの呼に対応するセッション情報は、セッションID、発側補助セッションID、着側補助セッションID、発信端末31の加入者番号、着信端末32の加入者番号、発側エンドポイント、着側エンドポイント、および認識方向というデータ項目群を含んでもよい。セッションIDは呼(セッション)を一意に特定する識別子である。補助セッションIDは、コアネットワーク10の外側に位置するWebサーバでも呼を一意に特定できるように用意される識別子である。発側補助セッションIDは発側Webサーバ41のために用いられ、着側補助セッションIDは着側Webサーバ42のために用いられる。エンドポイントはWebサーバを一意に特定する識別子である。発側エンドポイントは発側Webサーバ41を一意に特定し、着側エンドポイントは着側Webサーバ42を一意に特定する。認識方向は、音声テキストをどの通信端末に送信するかを示す情報である。
セッション情報のデータ構造は限定されず、任意の方針で設計されてよい。例えば、セッション情報は発側のレコードと着側のレコードとを互いに関連付けることで表現されてもよい。あるいは、セッション情報は、発側および着側の双方のデータ項目が1レコードに統合されることで表現されてもよい。
図1に示す各装置は、少なくとも一つのコンピュータを用いて構成される。複数のコンピュータが用いられる場合には、これらのコンピュータが通信ネットワークを介して相互に接続することで、論理的に一つの装置が構築される。
呼制御システム1の特徴の一つは、発信者および着信者の双方が音声テキスト化サービスを利用する場合に、発側および着側のいずれか一方が、発信者および着信者の双方の音声をテキストに変換する点にある。図1に示すように音声認識エンジン43が発側と着側とで共通であったとしても、その音声認識エンジン43への接続が発側と着側との間で異なると音声認識の結果が異なってしまう可能性がある。例えば、或る一つの発話が発側MCE15から音声認識エンジン43に入力された場合と、同じ発話が着側MCE16から音声認識エンジン43に入力された場合とで、音声テキストが異なる可能性がある。発側および着側の双方の間で通話内容のテキストを一致させるために、呼制御システム1では、発側MCE15および着側MCE16のうちの一方のみが共通のメディア処理装置として機能する。この共通のメディア処理装置は、発信者および着信者の双方の音声を音声認識エンジン43に送信し、音声テキストを発側Webサーバ41および着側Webサーバ42の双方に送信する。図1は、この仕組みに関連する接続51,52も示す。接続51は一つの呼(セッション)において発側MCE15が共通のメディア処理装置として機能する場合に用いられ、接続52は一つの呼(セッション)において着側MCE16が共通のメディア処理装置として機能する場合に用いられる。
図2は、アプリケーションサーバの機能構成の一例を示す図である。発側AS13は機能要素としてサービス制御部131、セッション制御部132、およびサービスシナリオ部133を備える。サービス制御部131は発側CSCF11との間でデータを送受信する機能要素である。セッション制御部132は発側MCE15との間でデータを送受信する機能要素である。サービスシナリオ部133は発側SMS-GW17および発側Webサーバ41のそれぞれとの間でデータを送受信する機能要素である。発側MCE15が発側および着側のそれぞれの音声を処理する場合には、サービスシナリオ部133は着側Webサーバ42との間でもデータを送受信する可能性があり、図2における接続61はその通信を示す。
着側AS14は機能要素としてサービス制御部141、セッション制御部142、およびサービスシナリオ部143を備える。サービス制御部141は着側CSCF12との間でデータを送受信する機能要素である。セッション制御部142は着側MCE16との間でデータを送受信する機能要素である。サービスシナリオ部143は着側SMS-GW18および着側Webサーバ42のそれぞれとの間でデータを送受信する機能要素である。着側MCE16が発側および着側のそれぞれの音声を処理する場合には、サービスシナリオ部143は発側Webサーバ41との間でもデータを送受信する可能性があり、図2における接続62はその通信を示す。
発側AS13および着側AS14はいずれも、発信者および着信者の双方が音声テキスト化サービスを利用する場合に、発側MCE15および着側MCE16のうちの一方を共通のメディア処理装置として機能させる制御部を備える。発側AS13では、サービス制御部131、セッション制御部132、およびサービスシナリオ部133の少なくとも一つがその制御部に相当する。着側AS14では、サービス制御部141、セッション制御部142、およびサービスシナリオ部143の少なくとも一つがその制御部に相当する。
本実施形態では発側MCE15が双方の音声を処理する例を説明する。したがって、図1に示す接続51と図2に示す接続61とが利用される。しかし、本開示はその例に限定されるものではなく、着側MCE16が双方の音声を処理してもよい。
図3~図6を参照しながら、本実施形態に係る呼制御システム1の動作の例を説明する。図3~図6はいずれも呼制御システム1の動作の一例を示すシーケンス図である。図3は呼を確立する処理の例を示す。図4および図5は音声テキスト化サービスを起動する処理の例を示す。図6は音声テキストを通信端末上に表示する処理の例を示す。理解を容易にするために、図3~図6では、通話および音声テキスト化サービスの制御に特に関係する構成要素、処理、およびデータ信号に限って示す。
まず、図3を参照しながら、呼を確立する処理の例を処理フローS1として説明する。
ステップS101では、発信端末31が発信者の発信操作に応じてINVITEメッセージを送信し、発側AS13がそのINVITEメッセージを受信する。INVITEメッセージは、発信端末31と着信端末32との間に呼(セッション)を確立するために伝送される制御信号(呼確立要求信号)である。このINVITEメッセージは発側ネットワーク21を経由してコアネットワーク10に入る。コアネットワーク10では、発側CSCF11がそのINVITEメッセージを発側AS13に転送する。
ステップS102では、サービス制御部131がそのINVITEメッセージに応答して発信端末31(発信者)のために音声テキスト化サービスを起動する。サービス制御部131は加入者管理機能にアクセスして発信者の加入者情報を参照し、発信者が音声テキスト化サービスを契約しているか否かを判定する。発信者が音声テキスト化サービスを契約している場合に、サービス制御部131はサービスを起動する。本実施形態では、発信者が音声テキスト化サービスの契約者であることを前提とする。サービスの起動に関連して、サービス制御部131、セッション制御部132、およびサービスシナリオ部133は連携して、これから確立する呼のセッションIDと、発側補助セッションIDと、発信端末31の加入者番号と、着信端末32の加入者番号とを含むセッション情報をセッションデータベース19に格納する。
ステップS103では、サービスシナリオ部133が発側SMS-GW17にプッシュ通知を送信し、ステップS104では、発側SMS-GW17がそのプッシュ通知に応答して発信端末31にプッシュ要求を送信する。サービスシナリオ部133は、サービス制御部131からの指示に応答してユーザプロファイルにアクセスして発信者のユーザ情報を参照し、音声テキスト化サービスの契約状態を判定する。発信者に音声テキスト化サービスを提供できる場合に、サービスシナリオ部133はプッシュ通知を送信する。本実施形態では、発信者が音声テキスト化サービスを享受する資格を有することを前提とする。プッシュ要求は、発信端末31が発側Webサーバ41から音声テキスト化サービスを受けるために必要な情報(例えば、発信端末31のデバイストークン、および発側補助セッションID)を含み、プッシュ通知は、そのプッシュ要求を構成する情報の少なくとも一部を含む。
ステップS105では、セッション制御部132が発側MCE15との接続のためにINVITEメッセージを発側MCE15に送信する。発側MCE15はそのINVITEメッセージに応答して音声テキスト化サービスのための処理を実行した後に、ステップS106において200_OKメッセージを送信する。200_OKメッセージは、INVITEメッセージに対応する処理が正常に実行されたことを示す応答信号である。すなわち、200_OKメッセージはINVITEメッセージに対応する成功応答信号である。
ステップS107では、サービス制御部131が着側AS14に向けてINVITEメッセージを送信する。サービス制御部131は、INVITEメッセージのヘッダ情報に、発側MCE15を一意に特定するための識別子である発側メディア装置IDと、発側で音声テキスト化サービスが実行されることを示す発側サービス情報とを付加する。そして、サービス制御部131は発側メディア装置IDおよび発側サービス情報を含むINVITEメッセージを送信する。このINVITEメッセージは発側CSCF11および着側CSCF12を経由して着側AS14に到達する。
ステップS108では、サービス制御部141が発側AS13からのINVITEメッセージに応答して着信端末32(着信者)のために音声テキスト化サービスを起動する。サービス制御部141は加入者管理機能にアクセスして着信者の加入者情報を参照し、着信者が音声テキスト化サービスを契約しているか否かを判定する。着信者が音声テキスト化サービスを契約している場合に、サービス制御部141はサービスを起動する。本実施形態では、着信者が音声テキスト化サービスの契約者であることを前提とする。サービスの起動に関連して、サービス制御部141、セッション制御部142、およびサービスシナリオ部143は連携して、これから確立する呼の着側補助セッションIDをセッションデータベース19内の対応するセッション情報に書き込む。
ステップS109では、サービスシナリオ部143が着側SMS-GW18にプッシュ通知を送信し、ステップS110では、着側SMS-GW18がそのプッシュ通知に応答して着信端末32にプッシュ要求を送信する。サービスシナリオ部143は、サービス制御部141からの指示に応答してユーザプロファイルにアクセスして着信者のユーザ情報を参照し、音声テキスト化サービスの契約状態を判定する。着信者に音声テキスト化サービスを提供できる場合に、サービスシナリオ部143はプッシュ通知を送信する。本実施形態では、着信者が音声テキスト化サービスを享受する資格を有することを前提とする。プッシュ要求は、着信端末32が着側Webサーバ42から音声テキスト化サービスを受けるために必要な情報(例えば、着信端末32のデバイストークン、および着側補助セッションID)を含み、プッシュ通知は、そのプッシュ要求を構成する情報の少なくとも一部を含む。
ステップS111では、セッション制御部142が着側MCE16との接続のためにINVITEメッセージを着側MCE16に送信する。着側MCE16はそのINVITEメッセージに応答して音声テキスト化サービスのための処理を実行する。着側MCE16はINVITEメッセージ内の発側メディア装置IDおよび発側サービス情報を参照することで、発側で音声テキスト化サービスが実行されることと、発側MCE15がそのサービスを実行することとを認識する。この認識に基づいて、着側MCE16は音声データを音声認識エンジン43に提供しない。ただし、着側MCE16と着側AS14との間の接続は、呼が切断されるまで維持される。ステップS112では、着側MCE16が200_OKメッセージを着側AS14に送信する。
ステップS113では、サービス制御部141がINVITEメッセージを着信端末32に向けて送信する。INVITEメッセージは着側AS14から着側CSCF12に送られ、着側CSCF12から着側ネットワーク22を経由して着信端末32に送信される。着信端末32がそのINVITEメッセージを受信することで、着信端末32に対する呼出処理が完了する。
ステップS114では、着信者が電話に出たことに応答して、着信端末32が200_OKメッセージを送信し、この200_OKメッセージが着側ネットワーク22および着側CSCF12を経由して着側AS14に到達する。
ステップS115では、着側AS14のサービス制御部141、セッション制御部142、およびサービスシナリオ部143のそれぞれがそのメッセージを処理し、最後にサービス制御部141が200_OKメッセージを発側AS13に向けて送信する。サービス制御部141は、200_OKメッセージのヘッダ情報に、着側MCE16を一意に特定するための識別子である着側メディア装置IDと、着側で音声テキスト化サービスが実行されることを示す着側サービス情報とを付加する。そして、サービス制御部141は着側メディア装置IDおよび着側サービス情報を含む200_OKメッセージを送信する。この200_OKメッセージは着側CSCF12および発側CSCF11を経由して発側AS13に到達する。
ステップS116では、セッション制御部132がその200_OKメッセージを発側MCE15に送信する。発側MCE15はその200_OKメッセージ内の着側メディア装置IDおよび着側サービス情報を参照することで、着側でも音声テキスト化サービスが実行されることを認識する。この認識に基づいて、発側MCE15は発信端末31からの音声データと着信端末32からの音声データとを音声認識エンジン43に提供する。このように、発側AS13は発側MCE15を共通のメディア処理装置として機能させる。ステップS117では、発側MCE15が200_OKメッセージを発側AS13に返し、ステップS118では、発側AS13がその200_OKメッセージを発信端末31に向けて送信する。200_OKメッセージは発側CSCF11および発側ネットワーク21を経由して発信端末31に到達する。
ステップS119では、発信端末31が200_OKメッセージを受信することで、発信端末31と着信端末32との間に、データ信号を伝送するためのU-Plane(ユーザ・プレイン)のバスが確立される。すなわち、発信端末31と着信端末32との間に呼が確立される。この結果、発信端末31と着信端末32との間で通話が可能になる。
次に、図4を参照しながら、音声テキスト化サービスを起動する処理の例を処理フローS2として説明する。この例は、通信端末での音声テキスト化サービスの開始のタイミングが発信端末31と着信端末32との間で同じかまたはほぼ同じ場合を示す。
ステップS201では、発信端末31が音声テキスト化サービスのためのアプリケーションプログラムを起動するために接続要求を発側Webサーバ41に送信する。接続要求は発信端末31と発側Webサーバ41との間に通信接続を確立するためのデータ信号であり、プッシュ要求により提供された情報の少なくとも一部(例えば、発信端末31のデバイストークン、および発側補助セッションID)を含む。
ステップS202では、発側Webサーバ41と発側AS13のサービスシナリオ部133との間で、発信者を認証するための処理が実行される。発側Webサーバ41は、接続要求により提供された情報の少なくとも一部(例えば、発信端末31のデバイストークン)を含む認証要求を発側AS13に送信する。サービスシナリオ部133はその認証要求に応答して認証処理を実行する。例えば、サービスシナリオ部133はデバイストークンが有効か否かを検査する。サービスシナリオ部133はその処理結果を発側Webサーバ41に送信する。本実施形態では、発信者が認証されることを前提とする。
ステップS203では、発信端末31が音声テキスト化サービスのためのアプリケーションプログラムを起動させて起動信号を発側Webサーバ41に送信する。起動信号はそのアプリケーションプログラムを実行するためのデータ信号である。
ステップS204では、発側Webサーバ41がその起動信号に応答して発側AS13にイベント通知を送信する。このイベント通知は発側エンドポイントおよび発側補助セッションIDを含む。
ステップS205では、発側AS13のサービスシナリオ部133が発側エンドポイントをセッションデータベース19に登録する。サービスシナリオ部133は、発側補助セッションIDに対応するセッション情報に発側エンドポイントを書き込む。この登録処理により、現在確立されている呼(セッション)での音声テキストを発側Webサーバ41経由で発信端末31に送信することが可能になる。
着側でもステップS201~S205と同様の処理が実行される。その同様の処理をステップS211~S215として示す。
ステップS211では、着信端末32が音声テキスト化サービスのためのアプリケーションプログラムを起動するために接続要求を着側Webサーバ42に送信する。接続要求は、プッシュ要求により提供された情報の少なくとも一部(例えば、着信端末32のデバイストークン、および着側補助セッションID)を含む。
ステップS212では、着側Webサーバ42と着側AS14のサービスシナリオ部143との間で、発信者を認証するための処理が実行される。本実施形態では、着信者も認証されることを前提とする。
ステップS213では、着信端末32が音声テキスト化サービスのためのアプリケーションプログラムを起動させて起動信号を着側Webサーバ42に送信する。
ステップS214では、着側Webサーバ42がその起動信号に応答して着側AS14にイベント通知を送信する。このイベント通知は着側エンドポイントおよび着側補助セッションIDを含む。
ステップS215では、着側AS14のサービスシナリオ部143が着側エンドポイントをセッションデータベース19に登録する。サービスシナリオ部143は、着側補助セッションIDに対応するレコードに着側エンドポイントを書き込む。この登録処理により、現在確立されている呼(セッション)での音声テキストを着側Webサーバ42経由で着信端末32に送信することが可能になる。
発側では、ステップS205の後にステップS206,S207が実行される。ステップS206では、発信端末31が、発信者が音声テキスト化サービスの利用に同意することを示す同意信号を発側Webサーバ41に送信する。ステップS207では、発側Webサーバ41がその同意信号に応答して発側AS13にイベント通知を送信する。このイベント通知は発信者の同意を示す。これらの同意信号およびイベント通知はいずれも発側補助セッションIDを含む。
着側では、ステップS215の後にステップS216,S217が実行される。ステップS216では、着信端末32が、着信者が音声テキスト化サービスの利用に同意することを示す同意信号を着側Webサーバ42に送信する。ステップS217では、着側Webサーバ42がその同意信号に応答して発側AS13に向けてイベント通知を送信する。このイベント通知は着信者の同意を示す。これらの同意信号およびイベント通知はいずれも着側補助セッションIDを含む。
ステップS208では、サービスシナリオ部133が、ステップS207,S217での二つのイベント通知に基づいて、確立された呼に対応するセッション情報の認識方向を「双方向」に設定する。具体的には、サービスシナリオ部133はセッションデータベース19にアクセスして、発側または着側の補助セッションIDに対応するセッション情報を特定し、このセッション情報の認識方向を「双方向」に設定する。このように、サービスシナリオ部133は、発信端末31および着信端末32の双方から同意信号が送信されたことに応答して認識方向を「双方向」に設定する。この結果、ステップS220で示すように、発着側の双方で音声テキスト化サービスが実行される。
次に、図5を参照しながら、音声テキスト化サービスを起動する処理の別の例を処理フローS2Aとして説明する。この例は、通信端末での音声テキスト化サービスの開始のタイミングが発信端末31と着信端末32との間で異なる場合を示し、より具体的には、着信端末32が発信端末31よりも後に音声テキスト化サービスを開始する場合を示す。
処理フローS2Aでも処理フローS2と同様に、発側ではステップS201~S207が実行される。音声テキスト化サービスのアプリケーションプログラムの起動に関する処理のタイミングが発側と着側とである程度大きく異なる場合には、発側ではステップS207の後にステップS208Aが実行される。このステップS208Aでは、サービスシナリオ部133が、ステップS207でのイベント通知に基づいて、確立された呼に対応するセッション情報(発側補助セッションIDに対応するセッション情報)の認識方向を「発側」に設定する。この結果、ステップS221に示すように、発信端末31でのみ音声テキスト化サービスが実行される。
ステップS221の後に、着側でステップS211~S217が実行されると、発側ではステップS208Bが実行される。このステップS208Bでは、サービスシナリオ部133が、ステップS217でのイベント通知に基づいて、確立された呼に対応するセッション情報(着側補助セッションIDに対応するセッション情報)の認識方向を「発側」から「双方向」に更新する。このように、サービスシナリオ部133は、発信端末31および着信端末32の双方から同意信号が送信されたことに応答して認識方向を「双方向」に設定する。この結果、ステップS222で示すように、発着側の双方で音声テキスト化サービスが実行可能になる。ステップS222は処理フローS2におけるステップS220と同じである。
次に、図6を参照しながら、音声テキストを通信端末上に表示する処理の例を処理フローS3として説明する。処理フローS3は、発着側の双方で音声テキスト化サービスが実行可能になったこと(すなわち、ステップS220またはS222)を前提とする。
ステップS301~S309は、着信者の音声(着側音声)をテキストに変換して、その音声テキストを発信端末31および着信端末32の双方に表示にする処理を示す。
ステップS301では、着信端末32から送信された音声データ(着側音声)が着側ネットワーク22を介してコアネットワーク10に送られ、着側CSCF12、発側CSCF11、発側AS13などの通信制御装置を経由して発側MCE15に送信される。ステップS302では発側MCE15がその音声データを音声認識エンジン43に送信する。ステップS303では、音声認識エンジン43がその音声データに対して音声認識を実行することで着側音声をテキストに変換し、その音声テキストを発側MCE15に送信する。この音声テキストは着側テキストに相当する。
ステップS304では、発側MCE15が、その音声テキストと、発話者が誰であるかを示す発話種別とを含む認識結果を発側Webサーバ41に送信する。音声テキストは着側音声を示すので、このステップで送信される認識結果では、発話種別は着側を示す。ステップS305では、発側MCE15がその認識結果を着側Webサーバ42にも送信する。発側MCE15は発側AS13を介して現在の呼に対応するセッション情報をセッションデータベース19から取得する。セッション情報の認識方向が「双方向」であることに応答して、発側MCE15はそのセッション情報から発側エンドポイントおよび着側エンドポイントを取得する。発側MCE15はこれらのエンドポイントにより認識結果の送信先(すなわち、発側Webサーバ41および着側Webサーバ42)を取得することができる。このように、発側MCE15は、認識方向が「双方向」であることに応答して着側テキストを発側Webサーバ41および着側Webサーバ42の双方に向けて送信する。
ステップS306では、発側Webサーバ41が発信端末31に認識結果を送信する。発側Webサーバ41は、認識結果に含まれる発話種別が着側であることに基づいて、音声テキストが通話相手のものとして発信端末31上に表示されるように、音声テキストを含むデータを生成する。
ステップS307では、発信端末31がそのデータに基づいて、音声テキストを着信者(通話相手)のものとして画面上に表示する。これにより、発信者は相手が話した内容を視覚的に認識できる。
ステップS308では、着側Webサーバ42が着信端末32に認識結果を送信する。着側Webサーバ42は、認識結果に含まれる発話種別が着側であることに基づいて、音声テキストが着信者自身のものとして着信端末32上に表示されるように、音声テキストを含むデータを生成する。
ステップS309では、着信端末32がそのデータに基づいて、音声テキストを着信者自身のものとして画面上に表示する。これにより、着信者は自分の発話を視覚的に認識できる。
ステップS310~S318は、発信者の音声(発側音声)をテキストに変換して、その音声テキストを発信端末31および着信端末32の双方に表示にする処理を示す。
ステップS310では、発信端末31から送信された音声データ(発側音声)が発側ネットワーク21を介してコアネットワーク10に送られ、発側CSCF11および発側AS13を経由して発側MCE15に送信される。ステップS311では発側MCE15がその音声データを音声認識エンジン43に送信する。ステップS312では、音声認識エンジン43がその音声データに対して音声認識を実行することで発側音声をテキストに変換し、その音声テキストを発側MCE15に送信する。この音声テキストは発側テキストに相当する。
ステップS313では、発側MCE15が、その音声テキストと、発話者が誰であるかを示す発話種別とを含む認識結果を発側Webサーバ41に送信する。音声テキストは発側音声を示すので、このステップで送信される認識結果では、発話種別は発側を示す。ステップS314では、発側MCE15がその認識結果を着側Webサーバ42にも送信する。発側MCE15は発側AS13を介して、現在の呼に対応するセッション情報をセッションデータベース19から取得する。セッション情報の認識方向が「双方向」であることに応答して、発側MCE15はそのセッション情報から発側エンドポイントおよび着側エンドポイントを取得し、これにより発側Webサーバ41および着側Webサーバ42を特定できる。このように、発側MCE15は、認識方向が「双方向」であることに応答して発側テキストを発側Webサーバ41および着側Webサーバ42の双方に向けて送信する。
ステップS315では、発側Webサーバ41が発信端末31に認識結果を送信する。発側Webサーバ41は、認識結果に含まれる発話種別が発側であることに基づいて、音声テキストが発信者自身のものとして発信端末31上に表示されるように、音声テキストを含むデータを生成する。
ステップS316では、発信端末31がそのデータに基づいて、音声テキストを発信者自身のものとして画面上に表示する。これにより、発信者は自分の発話を視覚的に認識できる。
ステップS317では、着側Webサーバ42が着信端末32に認識結果を送信する。着側Webサーバ42は、認識結果に含まれる発話種別が発側であることに基づいて、音声テキストが通話相手のものとして着信端末32上に表示されるように、音声テキストを含むデータを生成する。
ステップS318では、着信端末32がそのデータに基づいて、音声テキストを発信者(通話相手)のものとして画面上に表示する。これにより、着信者は相手が話した内容を視覚的に認識できる。
このように、双方のWebサーバは発話種別に基づいて音声テキストの表示態様を設定する。音声テキストを発話者自身または通話相手のものとして表示する手法は何ら限定されず、任意の手法が採用されてよい。Webサーバは発話種別に応じて音声テキストの表示位置(たとえば、音声テキストの吹き出しの表示位置)を変えてもよい。例えば、Webサーバは、発話者自身の音声テキストが右側(一方の側の一例)に表示され、通話相手の音声テキストが左側(他方の側の一例)に表示されるように表示態様を制御してもよい。あるいは、Webサーバは発話種別に応じて、音声テキストのフォントを変えてもよいし、吹き出しの形状または背景色を変えてもよい。
発話種別に基づく音声テキストの表示態様の設定は発信端末31および着信端末32で実行されてもよい。具体的には、発側Webサーバ41および着側Webサーバ42のそれぞれが、音声テキストと共に発話種別も、対応する通信端末に送信することで、該通信端末にその発話種別に基づいて音声テキストの表示態様を設定させてもよい。この仕組みによっても、発信端末31および着信端末32のそれぞれは、表示位置、フォント、吹き出しの形状または背景色などの表示態様を設定することができる。
本実施形態ではコアネットワーク10がIMSネットワークであるが、本開示に係る呼制御システムは任意の種類のコアネットワークに適用されてもよい。これに関連して、本開示に係る呼制御システムはSIP以外の通信プロトコルを用いてもよい。
発側AS13に実装される機能要素の少なくとも一部は、発側AS13以外の通信制御装置に実装されてもよい。同様に、着側AS14に実装される機能要素の少なくとも一部は、着側AS14以外の通信制御装置に実装されてもよい。
上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック(構成部)は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した1つの装置を用いて実現されてもよいし、物理的又は論理的に分離した2つ以上の装置を直接的又は間接的に(例えば、有線、無線などを用いて)接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記1つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。
機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知(broadcasting)、通知(notifying)、通信(communicating)、転送(forwarding)、構成(configuring)、再構成(reconfiguring)、割り当て(allocating、mapping)、割り振り(assigning)などがあるが、これらに限られない。たとえば、送信を機能させる機能ブロック(構成部)は、送信部(transmitting unit)や送信機(transmitter)と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。
例えば、本開示の一実施の形態における通信制御装置は、本開示の処理を行うコンピュータとして機能してもよい。図7は、その通信制御装置として機能するコンピュータ100のハードウェア構成の一例を示す図である。コンピュータ100は、物理的には、プロセッサ1001、メモリ1002、ストレージ1003、通信装置1004、入力装置1005、出力装置1006、バス1007などを含んでもよい。
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。通信制御装置のハードウェア構成は、図に示した各装置を1つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
通信制御装置における各機能は、プロセッサ1001、メモリ1002などのハードウェア上に所定のソフトウェア(プログラム)を読み込ませることによって、プロセッサ1001が演算を行い、通信装置1004による通信を制御したり、メモリ1002及びストレージ1003におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。
プロセッサ1001は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ1001は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置(CPU:Central Processing Unit)によって構成されてもよい。
また、プロセッサ1001は、プログラム(プログラムコード)、ソフトウェアモジュール、データなどを、ストレージ1003及び通信装置1004の少なくとも一方からメモリ1002に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、通信制御装置の各機能要素は、メモリ1002に格納され、プロセッサ1001において動作する制御プログラムによって実現されてもよい。上述の各種処理は、1つのプロセッサ1001によって実行される旨を説明してきたが、2以上のプロセッサ1001により同時又は逐次に実行されてもよい。プロセッサ1001は、1以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されてもよい。
メモリ1002は、コンピュータ読み取り可能な記録媒体であり、例えば、ROM(Read Only Memory)、EPROM(Erasable Programmable ROM)、EEPROM(Electrically Erasable Programmable ROM)、RAM(Random Access Memory)などの少なくとも1つによって構成されてもよい。メモリ1002は、レジスタ、キャッシュ、メインメモリ(主記憶装置)などと呼ばれてもよい。メモリ1002は、本開示の一実施の形態に係る方法を実施するために実行可能なプログラム(プログラムコード)、ソフトウェアモジュールなどを保存することができる。
ストレージ1003は、コンピュータ読み取り可能な記録媒体であり、例えば、CD-ROM(Compact Disc ROM)などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Blu-ray(登録商標)ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー(登録商標)ディスク、磁気ストリップなどの少なくとも1つによって構成されてもよい。ストレージ1003は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ1002及びストレージ1003の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。
通信装置1004は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア(送受信デバイス)であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置1004は、例えば周波数分割複信(FDD:Frequency Division Duplex)及び時分割複信(TDD:Time Division Duplex)の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。
入力装置1005は、外部からの入力を受け付ける入力デバイス(例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど)である。出力装置1006は、外部への出力を実施する出力デバイス(例えば、ディスプレイ、スピーカー、LEDランプなど)である。なお、入力装置1005及び出力装置1006は、一体となった構成(例えば、タッチパネル)であってもよい。
また、プロセッサ1001、メモリ1002などの各装置は、情報を通信するためのバス1007によって接続される。バス1007は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。
また、コンピュータ100は、マイクロプロセッサ、デジタル信号プロセッサ(DSP:Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)、FPGA(Field Programmable Gate Array)などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ1001は、これらのハードウェアの少なくとも1つを用いて実装されてもよい。
以上説明したように、本開示の一側面に係る呼制御システムは、発信端末と着信端末との間で伝送される通話をテキストに変換する音声テキスト化サービスを実行可能である。呼制御システムは、発信端末を利用する発信者と着信端末を利用する着信者との双方が音声テキスト化サービスの利用者である場合に、発信端末に対応する発側メディア処理装置と着信端末に対応する着側メディア処理装置とのうちの一方を共通のメディア処理装置として機能させる制御部を備える。共通のメディア処理装置は、発信者または着信者の音声をテキストに変換する音声認識エンジンと接続する。共通のメディア処理装置は、発信端末から送信された発信者の発側音声を音声認識エンジンに入力することで発側テキストを取得し、発側テキストを発信端末および着信端末の双方に向けて送信する。共通のメディア処理装置は、着信端末から送信された着信者の着側音声を音声認識エンジンに入力することで着側テキストを取得し、着側テキストを発信端末および着信端末の双方に向けて送信する。
このような側面においては、発信者および着信者の双方が音声認識サービスの利用者である場合に、発信者および着信者の双方の音声が共通のメディア処理装置を介してテキストに変換され、そのテキストが発信端末および着信端末の双方に送信される。発側および着側の双方について、共通のメディア処理装置が用いられるので、発側および着側の双方の間で通話内容のテキストを一致させることができる。
また、発側メディア処理装置と着側メディア処理装置の双方を用いるのではなく、そのうちの一方が用いられるので、音声テキスト化サービスを実行するために用いられるハードウェア資源および利用ライセンス数の少なくとも一方を節約することができる。また、音声テキスト化サービスに関連するメッセージ(例えばガイダンス)を、共通のメディア処理装置から発信端末および着信端末の双方に送信することも可能になる。
他の側面に係る呼制御システムでは、制御部が発側メディア処理装置を共通のメディア処理装置として機能させてもよい。或る同一種類の処理が実行されるタイミングは着側よりも発側の方が早い。したがって、発側メディア処理装置を共通のメディア処理装置として用いることで、音声テキスト化サービスに関連する処理を早く開始することができ、その分、音声テキスト化サービスをより早くユーザに提供することが可能になる。
他の側面に係る呼制御システムでは、制御部が、発側メディア処理装置を一意に特定する発側メディア装置IDを着側メディア処理装置に向けて送信し、発側メディア装置IDを受信した着側メディア処理装置から、着側メディア処理装置を一意に特定する着側メディア装置IDを受信し、着側メディア装置IDの受信に応答して、発側メディア処理装置を共通のメディア処理装置として機能させてもよい。発側および着側の双方のメディア処理装置の識別子を取得することで共通のメディア処理装置を確実に機能させることができる。
他の側面に係る呼制御システムでは、発側メディア処理装置が、発側テキストまたは着側テキストを発信端末に送信する発側Webサーバと接続し、着側メディア処理装置が、発側テキストまたは着側テキストを着信端末に送信する着側Webサーバと接続してもよい。呼制御システムは、発側Webサーバを一意に特定する発側エンドポイントと、着側Webサーバを一意に特定する着側エンドポイントとを含むセッション情報を記憶するデータベースをさらに備えてもよい。共通のメディア処理装置は、セッション情報の発側エンドポイントおよび着側エンドポイントを取得し、発側エンドポイントに基づいて、発側テキストまたは着側テキストを発側Webサーバに送信することで、発側テキストまたは着側テキストを発信端末に向けて送信し、着側エンドポイントに基づいて、発側テキストまたは着側テキストを着側Webサーバに送信することで、発側テキストまたは着側テキストを着信端末に向けて送信してもよい。そのエンドポイントを参照することで、テキストを送信すべきWebサーバを特定することができる。
他の側面に係る呼制御システムでは、制御部が、ユーザが音声テキスト化サービスの利用に同意することを示す同意信号が発信端末および着信端末の双方から送信されたことに応答して、音声テキストをどの通信端末に送信するかを示す認識方向を双方向に設定し、共通のメディア処理装置が、認識方向が双方向であることに応答して、発側テキストまたは着側テキストを発側Webサーバおよび着側Webサーバの双方に向けて送信してもよい。ユーザの同意に応じて認識方向を設定することで、発信者および着信者の双方が音声テキスト化サービスを希望する場合にのみその双方にテキストを送信することが可能になる。
他の側面に係る呼制御システムでは、共通のメディア処理装置が、発側テキストおよび着側テキストのそれぞれについて、発話者が発信者および着信者のどちらであるかを示す発話種別をさらに発側Webサーバおよび着側Webサーバの双方に送信してもよい。この発話種別がWebサーバに提供されることで、Webサーバは発話者の種類に応じてテキストを処理することができる。
他の側面に係る呼制御システムでは、発側Webサーバは、発話種別が発信者を示す場合には、発信端末上で発側テキストが発話者自身の音声テキストとして表示されるように発側テキストの表示態様を設定し、発話種別が着信者を示す場合には、発信端末上で着側テキストが通話相手の音声テキストとして表示されるように着側テキストの表示態様を設定してもよい。着側Webサーバは、発話種別が発信者を示す場合には、着信端末上で発側テキストが通話相手の音声テキストとして表示されるように発側テキストの表示態様を設定し、発話種別が着信者を示す場合には、着信端末上で着側テキストが発話者自身の音声テキストとして表示されるように着側テキストの表示態様を設定してもよい。
発側および着側のそれぞれで、発話種別に応じて上記のようにテキストの表示態様を設定することで、通信端末の利用者と発話者との関係に応じてテキストを表示することができる。通信端末は自機のユーザの音声テキストと通話相手の音声テキストとを互いに異なる表示態様で表示し、このことは、音声テキスト化サービスのユーザインタフェースの改善に寄与し得る。
他の側面に係る呼制御システムでは、発側Webサーバは、発話種別が発信者を示す場合には、発信端末上で発側テキストが発話者自身の音声テキストとして表示されるように発側テキストを発信端末上の第1の側に表示させ、発話種別が着信者を示す場合には、発信端末上で着側テキストが通話相手の音声テキストとして表示されるように着側テキストを発信端末上の第2の側に表示させてもよい。着側Webサーバは、発話種別が発信者を示す場合には、着信端末上で発側テキストが通話相手の音声テキストとして表示されるように発側テキストを着信端末上の第1の側に表示させ、発話種別が着信者を示す場合には、着信端末上で着側テキストが発話者自身の音声テキストとして表示されるように着側テキストを着信端末上の第2の側に表示させてもよい。
発側および着側のそれぞれで、発話種別に応じて上記のようにテキストの表示位置を設定することで、通信端末の利用者と発話者との関係に応じてテキストを表示することができる。通信端末は自機のユーザの音声テキストと通話相手の音声テキストとを互いに異なる側に表示するので、発信者および着信者のそれぞれに、自分の発話と相手の発話とを分かり易く示すことができる。
他の側面に係る呼制御システムでは、発側Webサーバが、発話種別を発側テキストまたは着側テキストと共に発信端末に送信することで、発信端末に発話種別に基づいて発側テキストまたは着側テキストの表示態様を設定させ、着側Webサーバが、発話種別を発側テキストまたは着側テキストと共に着信端末に送信することで、着信端末に発話種別に基づいて発側テキストまたは着側テキストの表示態様を設定させてもよい。
発側および着側のそれぞれで、発話種別に応じて上記のようにテキストの表示態様を設定することで、通信端末の利用者と発話者との関係に応じてテキストを表示することができる。通信端末は自機のユーザの音声テキストと通話相手の音声テキストとを互いに異なる表示態様で表示し、このことは、音声テキスト化サービスのユーザインタフェースの改善に寄与し得る。
以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。
情報の通知は、本開示において説明した態様/実施形態に限られず、他の方法を用いて行われてもよい。例えば、情報の通知は、物理レイヤシグナリング(例えば、DCI(Downlink Control Information)、UCI(Uplink Control Information))、上位レイヤシグナリング(例えば、RRC(Radio Resource Control)シグナリング、MAC(Medium Access Control)シグナリング、報知情報(MIB(Master Information Block)、SIB(System Information Block)))、その他の信号又はこれらの組み合わせによって実施されてもよい。また、RRCシグナリングは、RRCメッセージと呼ばれてもよく、例えば、RRC接続セットアップ(RRC Connection Setup)メッセージ、RRC接続再構成(RRC Connection Reconfiguration)メッセージなどであってもよい。
本開示において説明した各態様/実施形態は、LTE(Long Term Evolution)、LTE-A(LTE-Advanced)、SUPER 3G、IMT-Advanced、4G(4th generation mobile communication system)、5G(5th generation mobile communication system)、FRA(Future Radio Access)、NR(new Radio)、W-CDMA(登録商標)、GSM(登録商標)、CDMA2000、UMB(Ultra Mobile Broadband)、IEEE 802.11(Wi-Fi(登録商標))、IEEE 802.16(WiMAX(登録商標))、IEEE 802.20、UWB(Ultra-WideBand)、Bluetooth(登録商標)、その他の適切なシステムを利用するシステム及びこれらに基づいて拡張された次世代システムの少なくとも一つに適用されてもよい。また、複数のシステムが組み合わされて(例えば、LTE及びLTE-Aの少なくとも一方と5Gとの組み合わせ等)適用されてもよい。
本開示において説明した各態様/実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。
本開示において基地局によって行われるとした特定動作は、場合によってはその上位ノード(upper node)によって行われることもある。基地局を有する1つ又は複数のネットワークノード(network nodes)からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局及び基地局以外の他のネットワークノード(例えば、MME又はS-GWなどが考えられるが、これらに限られない)の少なくとも1つによって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが1つである場合を例示したが、複数の他のネットワークノードの組み合わせ(例えば、MME及びS-GW)であってもよい。
情報等は、上位レイヤ(又は下位レイヤ)から下位レイヤ(又は上位レイヤ)へ出力され得る。複数のネットワークノードを介して入出力されてもよい。
入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
判定は、1ビットで表される値(0か1か)によって行われてもよいし、真偽値(Boolean:true又はfalse)によって行われてもよいし、数値の比較(例えば、所定の値との比較)によって行われてもよい。
本開示において説明した各態様/実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知(例えば、「Xであること」の通知)は、明示的に行うものに限られず、暗黙的(例えば、当該所定の情報の通知を行わない)ことによって行われてもよい。
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術(同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL:Digital Subscriber Line)など)及び無線技術(赤外線、マイクロ波など)の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。
本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及びシンボルの少なくとも一方は信号(シグナリング)であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア(CC:Component Carrier)は、キャリア周波数、セル、周波数キャリアなどと呼ばれてもよい。
本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。
また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースはインデックスによって指示されるものであってもよい。
上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。様々なチャネル(例えば、PUCCH、PDCCHなど)及び情報要素は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的な名称ではない。
本開示においては、「基地局(BS:Base Station)」、「無線基地局」、「固定局(fixed station)」、「NodeB」、「eNodeB(eNB)」、「gNodeB(gNB)」、「アクセスポイント(access point)」、「送信ポイント(transmission point)」、「受信ポイント(reception point)、「送受信ポイント(transmission/reception point)」、「セル」、「セクタ」、「セルグループ」、「キャリア」、「コンポーネントキャリア」などの用語は、互換的に使用され得る。基地局は、マクロセル、スモールセル、フェムトセル、ピコセルなどの用語で呼ばれる場合もある。
基地局は、1つ又は複数(例えば、3つ)のセルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム(例えば、屋内用の小型基地局(RRH:Remote Radio Head)によって通信サービスを提供することもできる。「セル」又は「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局及び基地局サブシステムの少なくとも一方のカバレッジエリアの一部又は全体を指す。
本開示においては、「移動局(MS:Mobile Station)」、「ユーザ端末(user terminal)」、「ユーザ装置(UE:User Equipment)」、「端末」などの用語は、互換的に使用され得る。
移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、又はいくつかの他の適切な用語で呼ばれる場合もある。
基地局及び移動局の少なくとも一方は、送信装置、受信装置、通信装置などと呼ばれてもよい。なお、基地局及び移動局の少なくとも一方は、移動体に搭載されたデバイス、移動体自体などであってもよい。当該移動体は、乗り物(例えば、車、飛行機など)であってもよいし、無人で動く移動体(例えば、ドローン、自動運転車など)であってもよいし、ロボット(有人型又は無人型)であってもよい。なお、基地局及び移動局の少なくとも一方は、必ずしも通信動作時に移動しない装置も含む。例えば、基地局及び移動局の少なくとも一方は、センサなどのIoT(Internet of Things)機器であってもよい。
また、本開示における基地局は、ユーザ端末で読み替えてもよい。例えば、基地局及びユーザ端末間の通信を、複数のユーザ端末間の通信(例えば、D2D(Device-to-Device)、V2X(Vehicle-to-Everything)などと呼ばれてもよい)に置き換えた構成について、本開示の各態様/実施形態を適用してもよい。この場合、基地局が有する機能をユーザ端末が有する構成としてもよい。また、「上り」及び「下り」などの文言は、端末間通信に対応する文言(例えば、「サイド(side)」)で読み替えられてもよい。例えば、上りチャネル、下りチャネルなどは、サイドチャネルで読み替えられてもよい。
同様に、本開示におけるユーザ端末は、基地局で読み替えてもよい。この場合、ユーザ端末が有する機能を基地局が有する構成としてもよい。
本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up、search、inquiry)(例えば、テーブル、データベース又は別のデータ構造での探索)、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)(例えば、情報を受信すること)、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)(例えば、メモリ中のデータにアクセスすること)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断(決定)」は、「想定する(assuming)」、「期待する(expecting)」、「みなす(considering)」などで読み替えられてもよい。
「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、2又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された2つの要素間に1又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、2つの要素は、1又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光(可視及び不可視の両方)領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」又は「結合」されると考えることができる。
本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
本開示において使用する「第1の」、「第2の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、2つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第1及び第2の要素への参照は、2つの要素のみが採用され得ること、又は何らかの形で第1の要素が第2の要素に先行しなければならないことを意味しない。
本開示において、「含む(include)」、「含んでいる(including)」及びそれらの変形が使用されている場合、これらの用語は、用語「備える(comprising)」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は(or)」は、排他的論理和ではないことが意図される。
本開示において、例えば、英語でのa, an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。
本開示において、「AとBが異なる」という用語は、「AとBが互いに異なる」ことを意味してもよい。なお、当該用語は、「AとBがそれぞれCと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。