特許 6012331 移動通信システムにおける基地局及び規制方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6012331

(24)【登録日】2016年9月30日

(45)【発行日】2016年10月25日

(54)【発明の名称】移動通信システムにおける基地局及び規制方法

(51)【国際特許分類】

   H04W 48/06 20090101AFI20161011BHJP

   H04W 48/10 20090101ALI20161011BHJP

   H04W 72/04 20090101ALI20161011BHJP

【ＦＩ】

   H04W48/06

   H04W48/10

   H04W72/04 150

【請求項の数】4

【全頁数】14

(21)【出願番号】特願2012-173638(P2012-173638)

(22)【出願日】2012年8月6日

(65)【公開番号】特開2014-33385(P2014-33385A)

(43)【公開日】2014年2月20日

【審査請求日】2015年7月24日

(73)【特許権者】

【識別番号】392026693

【氏名又は名称】株式会社ＮＴＴドコモ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】矢葺 匠吾

(72)【発明者】

【氏名】大藤 義顕

(72)【発明者】

【氏名】原野 聖悟

(72)【発明者】

【氏名】佐々木 優輔

【審査官】 ▲高▼橋 真之

(56)【参考文献】

【文献】 特開平０４−１２９３３７（ＪＰ，Ａ）

【文献】 特開２０１１−０８２７１６（ＪＰ，Ａ）

【文献】 国際公開第２０１０／１５０４５５（ＷＯ，Ａ１）

【文献】 特開平１０−０１３９４９（ＪＰ，Ａ）

【文献】 西田克利外，音声呼のＩＭＳ−回線交換間ハンドオーバ方式の改善提案，電子情報通信学会技術研究報告NS2010-178，２０１１年 ２月２４日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｗ ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

ユーザ装置及びコアネットワークの通信ノードの間で制御信号を送受信するためにユーザ装置毎に設定された制御信号用のベアラを通じて、制御信号をユーザ装置から受信する受信部と、
音声信号について或る規制率で規制が発動されている場合、前記制御信号を送信したユーザ装置の音声信号を規制するか否かを、前記或る規制率に応じて決定する規制部と
を有し、前記規制部が、前記ユーザ装置の音声信号を規制することに決定した場合、音声ベアラ設定要求信号を送信したユーザ装置について設定されている前記制御信号用のベアラを流れる情報を破棄し、
ユーザ装置のデータ信号について規制が発動されている場合、規制が発動されていることを示す報知信号が送信部から送信され、前記報知信号が示す規制率に基づいて音声信号の規制率が決定される、移動通信システムにおける基地局。

【請求項2】

音声信号について或る規制率で規制が発動されていた場合、前記規制部は、乱数を生成し、前記或る規制率について指定されている所定値と前記乱数との比較結果により、前記ユーザ装置の音声信号を規制するか否かを決定する、請求項１に記載の基地局。

【請求項3】

前記ユーザ装置の音声信号を規制しないことを前記規制部が決定した場合、当該基地局は、前記音声ベアラ設定要求信号を前記コアネットワークの通信ノードに通知し、前記ユーザ装置及び前記通信ノードの間に前記音声信号用のベアラが設定される、請求項２に記載の基地局。

【請求項4】

ユーザ装置及びコアネットワークの通信ノードの間で制御信号を送受信するためにユーザ装置毎に設定された制御信号用のベアラを通じて、制御信号をユーザ装置から受信するステップと、
音声信号について或る規制率で規制が発動されている場合、前記制御信号を送信したユーザ装置の音声信号を規制するか否かを、前記或る規制率に応じて決定するステップと
を有し、前記ユーザ装置の音声信号を規制することに決定した場合、音声ベアラ設定要求信号を送信したユーザ装置について設定されている制御信号用のベアラを流れる情報は破棄され、
ユーザ装置のデータ信号について規制が発動されている場合、規制が発動されていることを示す報知信号が送信部から送信され、前記報知信号が示す規制率に基づいて音声信号の規制率が決定される、移動通信システムにおける基地局が実行する制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

開示される発明は移動通信システムにおける基地局及び規制方法等に関連する。

【背景技術】

【0002】

基地局や交換局等のネットワークの通信ノード(EPC)が輻輳した場合や、ルータが故障した等の場合、ユーザ装置(UE)の通信の全部又は一部は禁止又は規制される。ロングタームエボリューション(LTE：Long Term Evolution)方式の移動通信システムの場合、音声信号のサービス、ビデオ信号のサービス、データ信号のサービス等のように様々なサービスが存在し、いずれのサービスもパケット回線を使用して行われるため、そのような規制をサービス毎に個別に行うことが検討されている。この規制はサービス固有アクセス規制(Service Specific Access Control：SSAC)と呼ばれている。従来の移動通信システムにおける規制については非特許文献1に記載されている。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】3GPP TS36.331 V9.11.0(5.3.3章、6.3.1章)

【発明の概要】

【発明が解決しようとする課題】

【0004】

SSACによる規制機能は全てのユーザ装置(UE：User Equipment)に必須ではなく、オプションである。例えば、SSACによる音声信号の規制が発動された場合、SSACに対応可能なユーザ装置(UE)は規制の対象となるが、SSACに対応していないユーザ装置(UE)は規制の非対象となる。このように、SSAC用の機能がユーザ装置(UE)に実装されているか否か起因して、規制の対象となったりならなかったりすることは、ユーザ間の公平性の観点からは好ましくない。

【0005】

開示される発明の課題は、ユーザ装置(UE)がサービス固有アクセス規制(SSAC)に対応できるか否かによらず、音声信号を公平に規制できるようにすることである。

【課題を解決するための手段】

【0006】

開示される発明による基地局(eNB: evolved Node B)は、
ユーザ装置(UE)及びコアネットワークの通信ノード(EPC: Evolved Packet Core)の間で制御信号を送受信するためにユーザ装置(UE)毎に設定された制御信号用のベアラを通じて、制御信号をユーザ装置(UE)から受信する受信部と、
音声信号について或る規制率で規制が発動されていた場合、前記制御信号を送信したユーザ装置(UE)の音声信号を規制するか否かを、前記或る規制率に応じて決定する規制部と
を有し、前記規制部が、前記ユーザ装置(UE)の音声信号を規制することに決定した場合、前記音声ベアラ設定要求信号を送信したユーザ装置(UE)について設定されている前記制御信号用のベアラを流れる情報を破棄する、移動通信システムにおける基地局である。

【発明の効果】

【0007】

開示される発明によれば、ユーザ装置(UE)がサービス固有アクセス規制(SSAC)方式に対応できるか否かによらず、音声信号を公平に規制できるようにすることができる。

【図面の簡単な説明】

【0008】

【図1】ユーザ装置(UE)が通信の可否を判定するための規制時の動作例を示す図。

【図2】SSAC規制時におけるユーザ装置(UE)の動作を示すシーケンス図。

【図3】実施の形態による音声信号の規制方法を実行する前段階としてユーザ装置(UE)、基地局(eNB)及びコアネットワークの通信ノード(EPC)の間で行われる発着信手順のシーケンスを示す図。

【図4】ユーザ装置(UE)、基地局(eNB)及び通信ノード(EPC)の間に(i)データ信号用ベアラ及び(ii)制御信号用ベアラが設定された様子を示す図。

【図5】基地局(eNB)が行う音声信号の規制方法を示すフローチャート。

【図6】ユーザ装置(UE)、基地局(eNB)及び通信ノード(EPC)の間に(i)データ信号用ベアラ及び(ii)制御信号用ベアラに加えて(iii)音声信号用ベアラが設定され、音声信号が送受信される様子を示す図。

【図7】ユーザ装置(UE)、基地局(eNB)及び通信ノード(EPC)の間に設定された制御信号用ベアラを通じて受信された音声ベアラ設定要求信号を破棄することで、規制を実現する様子を示す図。

【図8】データ信号を規制する場合の動作例を示すフローチャート。

【図9】基地局の機能ブロック図。

【発明を実施するための形態】

【0009】

添付図面を参照しながら以下の観点から実施形態を説明する。図中、同様な要素には同じ参照番号又は参照符号が付されている。

【0010】

1．規制
1.1 ACB
1.2 SSAC
1.3 ユーザ装置(UE)の動作
1.4 二重規制
2．動作例
2.1 音声信号の規制
2.2 データ信号の規制
3．基地局
これらの項目の区分けは本発明に本質的ではなく、2以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に(矛盾しない限り)適用されてよい。

【0011】

＜1．規制＞
＜＜1.1 ACB＞＞
LTE方式の移動通信システムではACBによる規制とSSACによる規制とが用意されている。ACBはアクセスクラス規制(Access Class Barring)である。SSACはサービス固有アクセス規制(Service Specific Access Control)である。アクセスクラスは全てのユーザ装置(UE)について通信開始前に予め決まっている。従ってユーザ装置(UE)はアクセスクラス毎に分類される。基地局は規制対象にするアクセスクラスを決定し、それを報知信号又は報知情報でセルに在圏するユーザ装置(UE)に報知する。待受中であるアイドル状態から通信中であるアクティブ状態に遷移して通信を開始しようとするユーザ装置(UE)は、受信した報知信号から自身のアクセスクラスが規制対象であるか否かを判断する。当該ユーザ装置(UE)のアクセスクラスが規制対象であった場合、ユーザ装置は乱数を発生し、乱数と閾値との比較結果に応じて通信の可否を判定する。判定の結果、通信できる場合はRRCコネクションが設定され、通信が開始される。アクセスクラス規制を実施するために使用する信号は、システムインフォメーションブロック2(SIB2)である。

【0012】

アクセスクラスの種類はいくつでもよいが、一例として、0-15のアクセスクラスが設定されてもよい。例えば、次のようにアクセスクラスが規定されていてもよい。

【0013】

0-9：一般呼
10：緊急呼
11：PLMN呼又は保守呼
12：優先呼(セキュリティサービス呼)
13：優先呼(パブリックユーティリティ呼)
14：緊急サービス呼
15：PLMNスタッフ呼
上記のアクセスクラスのうち11、15は事業者又はオペレータが使用するための呼である。ユーザ装置(UE)が送受信する対象として例えば以下の種類がある。

【0014】

・データ発信信号(mobile originating calls：MO)
・音声発信信号(MMTEL voice/video)
・シグナリング信号(mobile originating signaling：MOシグナリング)。これは、位置登録のための信号や、交換局を移る際に使用される信号である。

【0015】

・CSフォールバック信号(mobile originating Circuit Switching fallback：CSFB)
・着信信号(mobile terminating calls：MT)
・緊急信号(emergency calls)
＜＜1.2 SSAC＞＞
サービス固有アクセス規制(Service Specific Access Control：SSAC)も報知信号(SIB2)により通知される。待受中であるアイドル状態から通信中であるアクティブ状態に遷移して通信を開始しようとするユーザ装置(UE)は、受信した報知信号からSSACによる規制が発動されているか否かを判断する。SSACによる規制が発動されていた場合において、規制対象のサービスを利用しようとする場合(例えば、音声サービスを利用しようとする場合)、ユーザ装置(UE)は乱数を発生し、乱数と閾値との比較結果に応じて通信の可否を判定する。判定の結果、通信できる場合はRRCコネクションが設定され、通信が開始される。上述したように、SSACによる規制に対応する機能はユーザ装置(UE)にとって必須の機能ではなく、オプションである。このため、例えば、SSACに対応しているか否かによって規制の対象になるか否かが異なってしまう。

【0016】

＜＜1.3 ユーザ装置(UE)の動作＞＞
図1はユーザ装置(UE)が通信の可否を判定するための動作例を示す。概して左側のステップ101-139は3GPPのリリース8及び9に関する動作(Rel-8/9動作)であり、右側のステップ141-159は3GPPのリリース10に関する動作(Rel-10から規定される動作)である。

【0017】

ステップ101-105は着信に伴う発信規制に関する処理を表す。ステップ101において、ユーザ装置(UE)の上位レイヤ(例えば、アプリケーションレイヤ)から通信の要求が生じたとする。NASはノンアクセスストラタム(Non Access Stratum)を表し、下位レイヤにおける無線アクセスに関する処理以外の処理を行う上位レイヤに対応する。ステップ102-105は着信規制(PPAC)に関する処理を表す。ステップ102において、ユーザ装置(UE)は着信が生じたか否かを判定し、着信が生じている場合はステップ103においてタイマ(T302)が起動していれば規制され(ステップ104)、起動していなければ規制されない(ステップ105)。ステップ102において着信が生じていなかった場合、フローはステップ111に進む。

【0018】

ステップ111-116は緊急呼の規制に関する処理を表す。ステップ111において、緊急呼が生じたか否かが判定され、緊急呼が生じた場合、ステップ112において緊急呼の規制が発動されているか否かが判定される。規制が発動されていた場合、ステップ113においてユーザ装置(UE)のアクセスクラスが11-15の何れかであるか否かが判定される。アクセスクラスがこれらの内の何れかであった場合、ステップ114において、ユーザ装置(UE)のそのアクセスクラスについて通信が許可されているか否かが判定される。許可されていなければユーザ装置(UE)は規制され(ステップ115)、許可されていればユーザ装置(UE)は規制されない(ステップ116)。ユーザ装置(UE)のアクセスクラスが11-15の内の何れでもなかった場合、又はステップ114においてYesであった場合、ユーザ装置(UE)は規制対象になる(ステップ115)。ステップ112において緊急呼の規制が発動されていなかった場合、又はステップ114においてNoであった場合、ユーザ装置(UE)は規制対象ではない(ステップ116)。ステップ111において緊急呼が生じていなかった場合、フローはステップ121に進む。

【0019】

ステップ121-129はアクセスクラス規制(ACC)に関する処理を表す。ステップ121において、MOデータ、すなわちデータ発信信号(mobile originating calls)が生じたか否かが判定される。MOデータが生じていた場合、ステップ122においてタイマ(T302又はT303)が起動していればフローはステップ128に進み、ユーザ装置(UE)は規制される。タイマが起動していなかった場合、ステップ123において発信呼の規制が発動されているか否かが判定される。発動されていた場合、ステップ124において、ユーザ装置(UE)のアクセスクラスが11-15の何れかであるか否かが判定される。アクセスクラスがこれらの内の何れかであった場合、ステップ125において、ユーザ装置(UE)のアクセスクラスについて通信が許可されているか否かが判定される。許可されていた場合、ユーザ装置(UE)は規制されない(ステップ129)。また、ステップ123においては発信呼の規制が発動されていなかった場合も、ユーザ装置(UE)は規制されない(ステップ129)。ユーザ装置(UE)のアクセスクラスが11-15の内の何れでもなかった場合、又はユーザ装置(UE)のアクセスクラスについて通信が許可されていなかった場合、ステップ126において乱数と閾値ABF(Ac-Barring Factor)1とが比較され、乱数がABF1より小さかった場合、フローはステップ129に進み、ユーザ装置(UE)は規制されない。乱数がABF1より小さくなかった場合、ステップ127においてタイマ(T303)が起動していればフローはステップ128に進み、ユーザ装置(UE)は規制される。

【0020】

ステップ131-139はシグナリング規制(PPAC)に関する処理を表す。ステップ131において、MOシグナリング、すなわちシグナリング信号(mobile originating signaling)が生じたか否かが判定される。MOシグナリングが生じていた場合、ステップ132においてタイマ(T302又はT305)が起動していれば、フローはステップ138に進み、ユーザ装置(UE)は規制される。タイマが起動していなかった場合、ステップ133において発信呼の規制が発動されているか否かが判定される。発動されていた場合、ステップ134において、ユーザ装置(UE)のアクセスクラスが11-15の何れかであるか否かが判定される。アクセスクラスがこれらの内の何れかであった場合、ステップ135において、ユーザ装置(UE)のアクセスクラスについて通信が許可されているか否かが判定される。許可されていた場合、ユーザ装置(UE)は規制されない(ステップ139)。また、ステップ133においてシグナリング呼の規制が発動されていなかった場合も、ユーザ装置(UE)は規制されない(ステップ139)。ユーザ装置(UE)のアクセスクラスが11-15の内の何れでもなかった場合、又はユーザ装置(UE)のアクセスクラスについて通信が許可されていなかった場合、ステップ136において乱数と閾値ABF2とが比較され、乱数がABF2より小さかった場合、フローはステップ139に進み、ユーザ装置(UE)は規制されない。乱数がABF2より小さくなかった場合、ステップ137においてタイマ(T305)が起動していればフローはステップ138に進み、ユーザ装置(UE)は規制される。ステップ131においてMOシグナリングが生じていなかった場合、フローはステップ141に進む。

【0021】

ステップ141-159はCSFB規制に関する処理を表す。ステップ141において、タイマ(T302又はT306)が起動していた場合、ユーザ装置(UE)は規制される(ステップ147)。タイマが起動していなかった場合、ステップ142においてCSFB呼の規制が発動されているか否かが判定される。発動されていた場合、ステップ143において、ユーザ装置(UE)のアクセスクラスが11-15の何れかであるか否かが判定される。アクセスクラスがこれらの内の何れかであった場合、ステップ144において、ユーザ装置(UE)のアクセスクラスについて通信が許可されているか否かが判定される。許可されていた場合、ユーザ装置(UE)は規制されない(ステップ148)。ユーザ装置(UE)のアクセスクラスが11-15の内の何れでもなかった場合、又はユーザ装置(UE)のアクセスクラスについて通信が許可されていなかった場合、ステップ145において乱数と閾値ABF3とが比較され、乱数がABF3より小さかった場合、フローはステップ148に進み、ユーザ装置(UE)は規制されない。乱数がABF3より小さくなかった場合、ステップ146においてタイマ(T306)が起動され、満了するとフローはステップ147に進み、ユーザ装置(UE)は規制される。ステップ142においてCSFB呼の規制が発動されていなかった場合、フローはステップ153に進む。

【0022】

ステップ153において発信呼の規制が発動されているか否かが判定される。発動されていた場合、ステップ154において、ユーザ装置(UE)のアクセスクラスが11-15の何れかであるか否かが判定される。アクセスクラスがこれらの内の何れかであった場合、ステップ155において、ユーザ装置(UE)のアクセスクラスについて通信が許可されているか否かが判定される。許可されていた場合、ユーザ装置(UE)は規制されない(ステップ159)。また、ステップ153においてシグナリング呼の規制が発動されていなかった場合も、ユーザ装置(UE)は規制されない(ステップ159)。ユーザ装置(UE)のアクセスクラスが11-15の内の何れでもなかった場合、又はユーザ装置(UE)のアクセスクラスについて通信が許可されていなかった場合、ステップ156において乱数と閾値ABF1とが比較され、乱数がABF1より小さかった場合、フローはステップ159に進み、ユーザ装置(UE)は規制されない。乱数がABF1より小さくなかった場合、ステップ157においてタイマ(T306)が起動していればフローはステップ158に進み、ユーザ装置(UE)は規制される。

【0023】

＜＜1.4 二重規制＞＞
上述したようにSSACに対応できる機能をユーザ装置(UE)が実装しているか否かに依存して音声信号の規制の対象になったりならなかったりする点で不公平であるという問題が懸念される。更に、SSACとACBを用いて規制を行う場合、音声信号を意図する規制率で規制することが困難になってしまう問題も生じる。

【0024】

図2はユーザ装置(UE)及び基地局(eNB)における音声信号の発信規制に関するシーケンスを示す。この場合における音声信号は、LTE方式の移動通信システムにおいて送受信される音声信号、すなわちボイスオーバーLTE呼(VoLTE)である。ユーザ装置(UE)は、下位レイヤに関する信号処理を行うRRC信号処理部と、RRCよりも上位レイヤの信号処理を行うノンアクセスストラタム(NAS)信号処理部と、NASよりも上位レイヤ(例えば、アプリケーションレイヤ)の信号処理を行うIMS信号処理部とを有する。

【0025】

ステップ21において、基地局(eNB)は、SSACによる規制及びACBによる規制を発動していることを示す報知情報又は報知信号をSIB2により送信している。説明の便宜上、SSAC規制は音声信号を規制率R_SSACで規制することを示し、ACBは該当するアクセスクラスのユーザ装置(UE)の通信を規制率R_ACBで規制するものとする。

【0026】

ステップ22において、ユーザ装置(UE)において、音声信号の発信要求が生じたとする。IMS信号処理部は、音声信号(VoLTE)の発信要求に応じて、音声信号について規制が発動されているか否かをRRC信号処理部に問い合わせ、SSACに関する情報(SSAC情報)を取得する(ステップ23、24)。目下の例の場合、音声信号は規制率R_SSACで規制されることになっている。

【0027】

ステップ25において、IMS信号処理部は規制率R_SSACに応じて音声信号の発信の可否を暫定的に決める。例えば、規制率R_SSACが40％であったとすると、IMS信号処理部は、0以上1以下の乱数を生成し、生成された乱数が0.4以下であるか否かを判定することで、音声信号の発信の可否を暫定的に決める。音声信号の発信が許可された場合、例えば、乱数が0.4以下であった場合、発信要求信号がRRC信号処理部に通知される(ステップ26、27)。

【0028】

目下の例の場合、ACB規制も発動されている。アクセスストラタム(AS)であるRRC信号処理部はサービス種別を判別せず、アクセスクラス毎に規制を行うので、RRC信号処理部は、音声信号の発信要求を許可するか否かを規制率R_ACBに応じて決める。例えば、規制率R_ACBが20％であったとすると、RRC信号処理部は、0以上1以下の乱数を生成し、生成された乱数が0.2以下であるか否かを判定することで、音声信号の発信の可否を確定する。音声信号の発信がステップ28により最終的に許可された場合、例えば、乱数が0.2以下であった場合、音声信号が基地局(eNB)に発信される。

【0029】

図示の例の場合、最終的に音声信号が送信されるには、ステップ25及び28の双方で発信が許可されなければならない。上記の例の場合、ステップ25における規制率は40％であり、ステップ28における規制率は20％であるので、ステップ25及び28の双方を経て発信できる確率は、(SSACにより禁止されない確率)×(ACBにより禁止されない確率)＝(1-40/100)×(1-20/100)=0.48となる。これは、音声信号について52％の規制を単独に行った場合と等価である。このように、SSACによる規制率を40％に設定し、ACBによる規制率を20％に設定しても、音声信号が実際に規制される割合は52％となり、音声信号を意図した割合(40％)で規制することは困難である。SSAC及びACB双方が適用される場合にこのような二重規制になることを予想してSSACの規制率を設定することも理論上は可能であるが、SSAC単独の場合とSSAC及びACB双方の場合とで規制率の設定の仕方を異ならせることは、処理が複雑化するので得策ではない。更に、仮にそのように複雑な仕方で規制率を設定したとしても、SSACに対応できるか否かはユーザ装置(UE)の性能に依存するので、ユーザ間で規制が不公平に適用される問題は解決しない。SSACに対応できないユーザ装置(UE)の場合、ステップ25における処理を行うことなく、ステップ28においてのみ規制を受けることになる。開示される発明はこのような懸念を解決する。

【0030】

＜2．動作例＞
＜＜2.1 音声信号の規制＞＞
図3は実施の形態による音声信号の規制方法を実行する前段階としてユーザ装置(UE)、基地局(eNB)及びコアネットワークの通信ノード(EPC)の間で行われる発着信手順のシーケンスを示す。

【0031】

ステップ301において、ユーザ装置(UE)は、RRCコネクションリクエストのメッセージを基地局(eNB)に送信し、RRCコネクションを設定することを要求する。

【0032】

ステップ302において、基地局(eNB)は、RRCコネクションセットアップのメッセージをユーザ装置(UE)に送信し、設定するRRCコネクションを通知する。

【0033】

ステップ303において、ユーザ装置(UE)は、RRCコネクションセットアップコンプリートのメッセージを基地局(eNB)に送信し、RRCコネクションの設定が完了したことを基地局(eNB)に通知する。

【0034】

ステップ304において、基地局(eNB)は、RRCコネクションを設定したユーザ装置(UE)についてベアラを設定するために、初期UEメッセージをコアネットワークの通信ノードに送信する。目下の例では、通信ノードはエボルブドパケットコア(EPC)の交換局(MME)である。

【0035】

ステップ305において、通信ノード(EPC)は、初回コンテキスト設定要求(Initial Context Setup Request)のメッセージを基地局(eNB)に通知する。初回コンテキスト設定要求のメッセージは、ユーザ装置(UE)、基地局(eNB)及び通信ノード(EPC)間にわたって設定されるベアラを指定する。具体的には、(i)データ信号を送受信するためのベアラ(データ信号用ベアラ)と、(ii)IMSとUEの制御信号を送受信するためのベアラ(制御信号用ベアラ)とが指定される。データ信号用ベアラはユーザプレーン(U-plane)ベアラである。制御信号用ベアラもU-planeベアラである。すなわち、制御信号用ベアラというU-planeベアラを通じて、制御信号が送受信される。

【0036】

ステップ306において、基地局(eNB)は、データ信号用ベアラ及び制御信号用ベアラを設定する。また、基地局(eNB)は、上り信号及び下り信号を受信するためのバッファを設定する。

【0037】

ステップ307において、基地局(eNB)は、セキュリティモードコマンド(Security Mode Command)のメッセージをユーザ装置(UE)に送信し、これに応じてユーザ装置(UE)及び基地局(eNB)間にセキュリティ設定が行われる。また、基地局(eNB)は、データ信号用ベアラ及び制御信号用ベアラを設定するために、RRCリコンフィギュレーションのメッセージをユーザ装置(UE)に送信する。これに応じて、ユーザ装置(UE)は、基地局(eNB)から通知されたデータ信号用ベアラ及び制御信号用ベアラを設定する。

【0038】

ステップ308においてユーザ装置(UE)はセキュリティモードコマンドに対する応答を返す。また、ステップ309において、RRCリコンフィギュレーションに対する応答として、設定が完了したことを基地局(eNB)に通知する。これにより、図4に示すように、(i)データ信号用ベアラ及び(ii)制御信号用ベアラがユーザプレーン(U-plane)ベアラとして設定されたことになる。このようなベアラの設定はユーザ装置(UE)毎に行われる。ユーザ装置(UE)はデータ信号用ベアラを用いてデータ信号を送受信することができるが、(i)データ信号用ベアラ及び(ii)制御信号用ベアラが設定されただけでは音声信号を送受信することはできない。音声信号を送受信するには、後述の音声信号用ベアラ(U-planeベアラ)が設定されなければならない。

【0039】

図5は図3に示す手順の実施中又は終了後に基地局(eNB)が行う音声信号の規制方法を示すフローチャートである。音声信号は、LTE方式の移動通信システムにおいて送受信されるボイスオーバーLTE(VoLTE)である。本実施形態では、音声信号を規制する際に、従来のACBやSSACによる規制は行われず、音声信号を何％規制するかが基地局(eNB)又は他の通信ノード(EPC)で決定され、その規制率で基地局(eNB)が規制を行う。すなわち、音声信号を規制する場合、規制していることや規制率を示す報知信号(SIB2)は報知されない。これに対してデータ信号を規制する場合は、従来のACBによる規制が行われる。すなわち、データ信号を規制する場合は、ACBにより規制することを示す報知信号(SIB2)が従来通り報知される。従って、実施の形態では、音声信号を規制する場合は図5に示す方法を使用する代わりに、SSACもACBもディセーブルにされる一方、データ信号を規制する場合は従来のACBによる規制方法が使用され、SSACはディセーブルにされる。

【0040】

フローはステップ51から始まり、ステップ52に進む。ステップ52において、基地局(eNB)は、ユーザ装置(UE)から音声ベアラ設定要求信号を受信し、バッファに蓄積する。音声ベアラ設定要求信号は、音声信号を送受信するための音声信号用ベアラを設定することをIPマルチメディアシステムのサーバ(IMSサーバ)に要求する信号である。音声ベアラ設定要求信号を、IMSサーバに通知することで、音声信号用ベアラを設定するシーケンスが実行される。

【0041】

ステップ53において、基地局(eNB)は、音声信号について規制が発動されているか否かを確認する。規制の要否及び規制率を基地局(eNB)が自ら決定してもよいし、基地局(eNB)以外の通信ノード(EPC)が規制の要否等を決定して基地局(eNB)に通知してもよい。例えば、エボルブドパケットコア(EPC)の交換局(MME)、オペレーティングシステム(OPS)、オペレーション管理ノード(OAM)等が規制の要否等を基地局(eNB)に通知してもよい。音声信号について規制が発動されている場合、フローはステップ54に進む。

【0042】

なお、ユーザ装置(UE)各々について規制が何時適用されるかについては、例えば、図3のステップ306のように初期のベアラが設定された時点でもよいし、或いは基地局(eNB)が自ら又は他の装置からの指示に応じて規制の発動を決定した際に、既に呼設定が行われているユーザ装置(UE)の中から規制対象のユーザ装置(UE)が選択されてもよい。

【0043】

ステップ54において、基地局(eNB)は、音声通信の許否を規制率に従って判定する。例えば、規制率が40％であったとすると、基地局(eNB)は、0以上1以下の乱数を生成し、生成された乱数が0.4以下であるか否かを判定することで、音声通信の可否を決定してもよい。なお、規制率はACBの規制率を考慮して決定されてもよい。音声通信が許可された場合、例えば、乱数が0.4以下であった場合、フローはステップ55に進む。ステップ53において、規制が発動されていなかった場合も、フローはステップ55に進む。

【0044】

ステップ55において、基地局(eNB)は制御信号用ベアラ(図4の(ii))を通じて音声ベアラ要求信号をIMSサーバに通知する。これに応じて、IMSサーバは、音声信号を送受信するためのベアラ(音声信号用ベアラ)を設定することを基地局(eNB)に通知する。基地局(eNB)はIMSサーバからの指示に従って、U-planeベアラである音声信号用ベアラを設定する(ステップ56)。図6はユーザ装置(UE)、基地局(eNB)及び通信ノード(EPC)間に、(i)データ信号用ベアラ及び(ii)制御信号用ベアラに加えて、(iii)音声信号用ベアラが設定されている様子を示す。

【0045】

図5のステップ57において、ユーザ装置(UE)は、設定された音声信号用ベアラを介して音声信号(VoLTE)を送受信し、フローはステップ59に進み、終了する。

【0046】

一方、ステップ54において、ユーザ装置(UE)の音声通信が許可されなかった場合、フローはステップ58に進む。

【0047】

ステップ58において、基地局(eNB)は、制御信号用ベアラを通じてユーザ装置(UE)から受信した後にバッファに蓄積していた音声ベアラ設定要求信号等を破棄する。より正確に言えば、基地局(eNB)は音声ベアラ設定要求信号を送信したユーザ装置(UE)について設定されている制御信号用ベアラを流れる情報を破棄する。その結果、図7に示すように、音声ベアラ設定要求信号はIMSサーバに通知されず、(iii)音声信号用ベアラが設定されることはない。そして、フローはステップ59に進み、終了する。

【0048】

実施の形態によれば、音声信号を規制する場合、従来のACBやSSACによらず、制御用ベラを通じて受信した音声ベアラ設定要求信号をIMSサーバに通知するか否かを、規制率に応じて決定する。これにより、セルに在圏するユーザ装置(UE)の音声信号を、基地局(eNB)又は他の通信ノード(EPC)が意図した規制率で正確に規制できる。しかも、ユーザ装置(UE)がSSACに対応可能であるか否かによらず、音声信号を公平に規制できる。

【0049】

＜＜2.2 データ信号の規制＞＞
図5に示す例では、音声信号が規制されていた。図8を参照しながらデータ信号を規制する場合の動作例を説明する。データ信号が規制される場合、従来と同様に、ACBによる規制が行われる。図8はデータ信号を規制する場合の動作例を示す。フローはステップ81から始まり、ステップ82に進む。

【0050】

ステップ82において、基地局(eNB)は、データ信号について規制が発動されているか否かを確認する。規制の要否及び規制率を基地局(eNB)が自ら決定してもよいし、基地局(eNB)以外の通信ノード(EPC)が規制の要否等を決定して基地局(eNB)に通知してもよい。例えば、エボルブドパケットコア(EPC)の交換局(MME)、オペレーティングシステム(OPS)、オペレーション管理ノード(OAM)等が規制の要否等を基地局(eNB)に通知してもよい。データ信号について規制が発動されていなければ、フローはステップ85に進んで終了し、データ信号について規制が発動されていた場合、フローはステップ83に進む。

【0051】

ステップ83において、基地局(eNB)は、データ信号について規制が行われていること及び規制率を示す報知信号(SIB2)を作成する。

【0052】

ステップ84において、基地局(eNB)は、ステップ83で作成した報知信号をセルに在圏するユーザ装置(UE)に報知する。報知信号を受信したユーザ装置(UE)は規制に関する情報(SIB2)を抽出し、データ信号を通信する際に、規制率に応じて通信可否を判断する。

【0053】

ステップ84の後、フローはステップ85に進み、終了する。

【0054】

本実施形態の場合、音声信号を通信する場合にはSSACもACBも考慮されず、音声信号用ベアラを設定するための音声ベアラ設定要求信号がユーザ装置(UE)から基地局(eNB)に送信される。ユーザ装置(UE)からの音声ベアラ設定要求信号は規制されることなく常に送信される一方、その音声ベアラ設定要求信号をIMSサーバに通知するか否かが、基地局(eNB)により規制率に従って決定される。データ信号を規制する場合、基地局(eNB)は従来のACBと同様に、アクセスクラス及び規制率を報知信号(SIB2)で報知する。ユーザ装置(UE)は、データ信号を送信する場合はACBの規制率に従って通信の可否を決定する一方、音声信号を送信する場合は音声ベアラ設定要求信号を規制することなく常に基地局(eNB)に送信し、音声通信の可否を基地局(eNB)が決定する。実施の形態によれば、音声信号もデータ信号も意図した規制率でユーザ間で公平に規制できる。

【0055】

＜3．基地局＞
図9は基地局(eNB)の機能ブロック図を示す。図9には基地局(eNB)に備わる様々な機能部又は処理部のうち、実施の形態に特に関連のある機能部又は処理部が示されている。基地局(eNB)は上位ノード通信インタフェース91、下位ノード通信インタフェース92、ベアラ制御部93、規制部94及び報知信号生成部95を少なくとも有する。

【0056】

上位ノード通信インタフェース91は基地局(eNB)よりも上位の通信ノード(EPC)との間の通信を行う機能を有する。そのような通信ノード(EPC)は、例えば、交換局(MME)、オペレーションシステム(OPS)等である。

【0057】

下位ノード通信インタフェース92は、ユーザ装置(UE)に下り信号を送信する機能、及びユーザ装置(UE)からの上り信号を受信する機能を有する。

【0058】

ベアラ制御部93は、ユーザ装置(UE)、基地局(eNB)及び通信ノード(EPC)間にベアラを設定するための処理を行う。例えば、ベアラ制御部93は、通信ノード(EPC)からの指示に従って転送先アドレスや転送元アドレスを設定する。ベアラ制御部93は、ユーザ装置(UE)及びIMSサーバ間でやり取りされる情報をバッファリングする機能、規制部94からの指示に従って音声ベアラ設定要求信号等のような制御信号用のベアラを流れる情報を破棄する機能等を有する。ベアラ制御部93は各種のベアラをユーザ装置(UE)毎に管理する。

【0059】

規制部94は、基地局(eNB)が自ら決定した規制率又は他の通信ノード(EPC)が決定した規制率に従って、音声信号の通信の許否を決定する。音声信号の通信が許可される場合、音声信号を送受信するための音声信号用ベアラを設定するように、ベアラ制御部93に通知する。音声信号の通信が許可されない場合、制御信号用ベアラを通じて受信した音声ベアラ設定要求信号等を破棄するように、ベアラ制御部93に指示する。

【0060】

報知信号生成部95は、データ信号を規制する場合に、規制が発動されていることを示す報知信号(SIB2)を生成する。報知信号は下位ノード通信インタフェース92により送信される。

【0061】

以上、音声信号(VoLTE)を規制する実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、2以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に(矛盾しない限り)適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には1つの部品で行われてもよいし、あるいは1つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、通信端末及び情報処理装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明に従って動作するソフトウェアは、ランダムアクセスメモリ（RAM）、フラッシュメモリ、読み取り専用メモリ（ROM）、EPROM、EEPROM、レジスタ、ハードディスク（HDD）、リムーバブルディスク、CD−ROM、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。

【符号の説明】

【0062】

91 上位レイヤ通信インタフェース
92 下位レイヤ通信インタフェース
93 ベアラ制御部
94 規制部
95 報知信号生成部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】