特許 6657169 無線通信システムでサービスを制御するための方法

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

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

(11)【特許番号】6657169

(24)【登録日】2020年2月7日

(45)【発行日】2020年3月4日

(54)【発明の名称】無線通信システムでサービスを制御するための方法

(51)【国際特許分類】

   H04W 4/14 20090101AFI20200220BHJP

   H04W 4/16 20090101ALI20200220BHJP

   H04W 68/00 20090101ALI20200220BHJP

   H04W 76/16 20180101ALI20200220BHJP

   H04W 88/14 20090101ALI20200220BHJP

   H04W 92/24 20090101ALI20200220BHJP

【ＦＩ】

   H04W4/14

   H04W4/16

   H04W68/00

   H04W76/16

   H04W88/14

   H04W92/24

【請求項の数】16

【全頁数】25

(21)【出願番号】特願2017-254115(P2017-254115)

(22)【出願日】2017年12月28日

(62)【分割の表示】特願2014-560858(P2014-560858)の分割

【原出願日】2013年3月8日

(65)【公開番号】特開2018-50349(P2018-50349A)

(43)【公開日】2018年3月29日

【審査請求日】2018年1月29日

(31)【優先権主張番号】61/608,580

(32)【優先日】2012年3月8日

(33)【優先権主張国】US

(31)【優先権主張番号】61/612,484

(32)【優先日】2012年3月19日

(33)【優先権主張国】US

(31)【優先権主張番号】61/614,470

(32)【優先日】2012年3月22日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100154922

【弁理士】

【氏名又は名称】崔 允辰

(74)【代理人】

【識別番号】100140534

【弁理士】

【氏名又は名称】木内 敬二

(72)【発明者】

【氏名】サン・ソ・ジョン

(72)【発明者】

【氏名】ソン・ヤン・チョ

(72)【発明者】

【氏名】ヨン・キョ・ペク

(72)【発明者】

【氏名】スン・ファン・ウォン

(72)【発明者】

【氏名】ハン・ナ・リム

【審査官】 本橋 史帆

(56)【参考文献】

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

【文献】 Qualcomm Incorporated，Corrections related to use of location area identifier IE at MME upon receiving SGsAP-PAGING-REQUEST message[online]，3GPP TSG-CT WG1#66 C1-103430，＜URL:http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_66_Xian/docs/C1-103430.zip＞，２０１０年 ８月２３日

【文献】 Alcatel-Lucent，Originating & Terminating network Information Flows[online]，3GPP TSG-CT WG4#54bis C4-112274，＜URL:http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_54bis_Hyderabad/Docs/C4-112274.zip＞，２０１１年１０月１０日

【文献】 Motorola，Correction to the SMS paging procedure[online]，3GPP TSG-CT WG1#62 C1-094931，＜URL:http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_62_Beijing/docs/C1-094931.zip＞，２００９年１１月 ９日

【文献】 Samsung，Filtering CS paging without SMS indicator for SMS only UE[online]，3GPP TSG-SA WG2#75 S2-095346，＜URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_75_Kyoto/Docs/S2-095346.zip＞，２００９年 ８月３１日

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

Ｈ０４Ｂ ７／２４− ７／２６

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

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

端末で信号を送受信する無線通信システムにおける方法であって、
前記端末が、ＣＳ（ｃｉｒｃｕｉｔ ｓｗｉｔｃｈｅｄ）サービスを識別するための識別子を含む対象端末に対するＣＳサービスと関連したサービスリクエストをＨＬＲ（ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ）に送信する段階と、
前記対象端末がＳＭＳ（ｓｈｏｒｔ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ） ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストが音声コール（ｖｏｉｃｅ ｃａｌｌ）と関連した場合、前記端末が、前記ＨＬＲから前記サービスリクエストに対する拒絶メッセージを受信する段階と、
前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストがＳＭＳと関連した場合、前記ＨＬＲがＭＭＥ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）に前記サービスリクエストを伝達し、前記ＭＭＥが前記ＭＭＥのＣＳサービスへの転換なしに前記サービスリクエストに基づいて前記対象端末にページング（ｐａｇｉｎｇ）メッセージを送信するようにする段階とを含む
ことを特徴とする方法。

【請求項2】

前記拒絶メッセージに基づいてＣＳサービスと関連したページング手続きが中断されることを特徴とする、請求項１に記載の方法。

【請求項3】

前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応する場合、前記対象端末に対するＳＭＳは、前記ＭＭＥによってサポートされ、前記対象端末に対するＣＳサービスは、前記ＭＭＥによってサポートされないことを特徴とする、請求項１に記載の方法。

【請求項4】

前記拒絶メッセージは、コール拒絶に対する理由を含むことを特徴とする、請求項１に記載の方法。

【請求項5】

移動通信システムで信号を送受信するＨＬＲ（ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ）における方法であって、
端末からＣＳ（ｃｉｒｃｕｉｔ ｓｗｉｔｃｈｅｄ）サービスを識別するための識別子を含む対象端末に対するＣＳサービスと関連したサービスリクエストを受信する段階と、
前記対象端末がＳＭＳ（ｓｈｏｒｔ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ） ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストが音声コール（ｖｏｉｃｅ ｃａｌｌ）と関連した場合、前記ＣＳサービスと関連した拒絶理由を含む前記サービスリクエストに対する拒絶メッセージを前記端末に送信する段階と、
前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストがＳＭＳと関連した場合、ＭＭＥ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）にＣＳサービスへの転換なしに前記サービスリクエストに基づいて前記対象端末にページング（ｐａｇｉｎｇ）メッセージを送信するように、前記ＭＭＥに前記サービスリクエストを伝達する段階とを含む方法。

【請求項6】

前記拒絶メッセージに基づいてＣＳサービスと関連したページング手続きが中断されることを特徴とする、請求項５に記載の方法。

【請求項7】

前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応する場合、前記対象端末に対するＳＭＳは、前記ＭＭＥによってサポートされ、前記対象端末に対するＣＳサービスは、前記ＭＭＥによってサポートされないことを特徴とする、請求項５に記載の方法。

【請求項8】

前記拒絶メッセージは、コール拒絶に対する理由を含むことを特徴とする、請求項５に記載の方法。

【請求項9】

端末と対象端末間で信号を送受信する無線通信システムであって、
前記端末は、
信号を送受信する第１の送受信部と、
前記第１の送受信部を制御し、ＣＳ（ｃｉｒｃｕｉｔ ｓｗｉｔｃｈｅｄ）サービスを識別するための識別子を含む前記対象端末に対するＣＳサービスと関連したサービスリクエストをＨＬＲ（ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ）に送信し、前記対象端末がＳＭＳ（ｓｈｏｒｔ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ） ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストが音声コール（ｖｏｉｃｅ ｃａｌｌ）と関連した場合、前記ＨＬＲから前記サービスリクエストに対する拒絶メッセージを受信する制御部とを含み、
前記ＨＬＲは、
信号を送受信する第２の送受信部と、
前記第２の送受信部を制御し、前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストがＳＭＳと関連した場合、ＭＭＥ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）のＣＳサービスへの転換なしに前記サービスリクエストに基づいて前記対象端末にページング（ｐａｇｉｎｇ）メッセージを送信するように前記ＭＭＥに前記サービスリクエストを伝達するように制御する制御部とを含む
ことを特徴とする無線通信システム。

【請求項10】

前記拒絶メッセージに基づいてＣＳサービスと関連したページング手続きを中断することを特徴とする、請求項９に記載の無線通信システム。

【請求項11】

前記ＭＭＥは、前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応する場合、前記対象端末に対するＳＭＳをサポートし、前記対象端末に対するＣＳサービスをサポートしないことを特徴とする、請求項９に記載の無線通信システム。

【請求項12】

前記拒絶メッセージは、コール拒絶に対する理由を含むことを特徴とする、請求項９に記載の無線通信システム。

【請求項13】

移動通信システムのＨＬＲ（ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ）であって、
信号を送受信する送受信部と、
前記送受信部を制御し、端末からＣＳ（ｃｉｒｃｕｉｔ ｓｗｉｔｃｈｅｄ）サービスを識別するための識別子を含む対象端末に対するＣＳサービスと関連したサービスリクエストを受信し、前記対象端末がＳＭＳ（ｓｈｏｒｔ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ） ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストが音声コール（ｖｏｉｃｅ ｃａｌｌ）と関連した場合、前記ＣＳサービスと関連した拒絶理由を含む前記サービスリクエストに対する拒絶メッセージを前記端末に送信し、前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応し、前記ＣＳサービスを識別するための識別子に従って前記サービスリクエストがＳＭＳと関連した場合、ＭＭＥ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）にＣＳサービスへの転換なしに前記サービスリクエストに基づいて前記対象端末にページング（ｐａｇｉｎｇ）メッセージを送信するように、前記ＭＭＥに前記サービスリクエストを伝達する制御部とを含むＨＬＲ。

【請求項14】

前記拒絶メッセージに基づいてＣＳサービスと関連したページング手続きが中断されることを特徴とする、請求項１３に記載のＨＬＲ。

【請求項15】

前記対象端末がＳＭＳ ｏｎｌｙ識別子に対応する場合、前記対象端末に対するＳＭＳは、前記ＭＭＥによってサポートされ、前記対象端末に対するＣＳサービスは、前記ＭＭＥによってサポートされないことを特徴とする、請求項１３に記載のＨＬＲ。

【請求項16】

前記拒絶メッセージは、コール拒絶に対する理由を含むことを特徴とする、請求項１３に記載のＨＬＲ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、無線通信システムでネットワーク網のロードを高めず、かつ通信サービスを制御する方法及び装置に関する。

【背景技術】

【0002】

図１は、ＬＴＥ移動通信システムの構造を示した図面である。

【0003】

前記図１を参照すれば、示したようにＬＴＥ移動通信システムの無線アクセスネットワークは次世代基地局(Ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ、ＥＵＴＲＡＮ、以下、ＥＮＢ又はＮｏｄｅ Ｂと言う)１０５とＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)１１０及びＳ−ＧＷ(Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ)１１５から構成される。ユーザ端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、以下、ＵＥ又は端末と称する)１００は、ＥＮＢ１１０及びＳ−ＧＷ１１５、及びＰ−ＧＷ（ＰＤＮ−Ｇａｔｅｗａｙ)１２０を通じて外部ネットワークに接続することができる。

【0004】

ＡＦ(Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ)１３０は、ユーザとアプリケーション水準でアプリケーションに係る情報を交換する装置である。

【0005】

ＰＣＲＦ１２５は、ユーザのＱｏＳに係るｐｏｌｉｃｙを制御する装置であり、ｐｏｌｉｃｙに該当するＰＣＣ(Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ)ｒｕｌｅはＰ−ＧＷ１２０に伝達されて適用される。

【0006】

ＥＮＢ１０５は、ＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)ノードとしてＵＴＲＡＮシステムのＲＮＣ、及びＧＥＲＡＮシステムのＢＳＣに対応される。ＥＮＢ１０５は、ＵＥ１００と無線チャンネルで接続されて既存ＲＮＣ／ＢＳＣと類似の役目を実行する。

【0007】

ＬＴＥではインターネットプロトコルを通じるＶｏＩＰ(Ｖｏｉｃｅ ｏｖｅｒ ＩＰ)のようなリアルタイムサービスを含む全てのユーザトラフィックが共用チャンネル(ｓｈａｒｅｄ ｃｈａｎｎｅｌ)を通じてサービスされるので、ＵＥ１００の状況情報を聚合してスケジューリングをする装置が必要であり、これをＥＮＢ１０５が担当する。

【0008】

Ｓ−ＧＷ１１５は、データベアラーを提供する装置であり、ＭＭＥ１１０の制御に応じてデータベアラーを生成したり除去したりする。

【0009】

ＭＭＥ１１０は、各鐘制御機能を担当する装置であり、１つのＭＭＥ１１０は複数の基地局と接続されてもよい。

【0010】

ＰＣＲＦ(Ｐｏｌｉｃｙ Ｃｈａｒｇｉｎｇ ａｎｄ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ)１２５はトラフィックに対するＱｏＳ及び課金を総括的に制御するエンティティーである。

【0011】

このような無線通信システムでサービスを提供するとき、ネットワーク網のロードを高めず、かつサービスを提供することができる方法及び装置が要求される。

【先行技術文献】

【非特許文献】

【0012】

【非特許文献1】Samsung，Filtering CS paging without SMS indicator for SMS only UE[online]，3GPP TSG-SA WG2#75 S2-095346，＜URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_75_Kyoto/Docs/S2-095346.zip＞，２００９年 ８月３１日

【非特許文献2】Alcatel-Lucent，Originating & Terminating network Information Flows[online]，3GPP TSG-CT WG4#54bis C4-112274，＜URL:http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_54bis_Hyderabad/Docs/C4-112274.zip＞，２０１１年１０月１０日

【発明の概要】

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

【0013】

本発明の実施形態は、前記問題点を解決するためのもので、ＰＳ(Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ ｄａｔａ ｎｅｔｗｏｒｋ)にだけ加入したユーザにＣＳ(Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ ｖｏｉｃｅ ｎｅｔｗｏｒｋ)サービスリクエストが提供されるとき、網のロードを高めず、かつユーザにサービス制限を通知することができる方法及び装置を提供することを目的とする。

【0014】

本発明の他の実施形態は、一般コールを使用しているユーザの端末で緊急コール発信が必要な場合、網のロードを与えず、要求される条件のうちに緊急コールを発信させる方法及び装置を提供することを目的とする。

【0015】

本発明の、また他の実施形態は、ネットワーク網の混雑状況にあるとき、混雑の程度を高めず、かつサービスを調節することができる方法及び装置を提供することを目的とする。

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

【0016】

実施形態による無線通信システムで信号を送受信する端末における方法は、他の端末とデータ送受信のためにＧａｔｅｗａｙ Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ（ＧＭＳＣ)でＣｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ ｖｏｉｃｅ ｎｅｔｗｏｒｋ(ＣＳ）サービスリクエストを送信する段階と、前記ＧＭＳＣから前記サービスリクエストに対するコール拒絶応答を受信する段階とを含み、前記コール拒絶応答は前記他の端末のコアネットワークのうちの１つのエンティティーから送信することを特徴とする。

【0017】

他の実施形態による無線通信システムの端末において、混雑制御方法は、基地局へＮｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ(ＮＡＳ)リクエストを送信する段階と、前記リクエストに対応してコアネットワークから混雑によるＮＡＳ拒絶を受信する段階と、前記端末と前記基地局の間のＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ)接続を解除しなければならないことを指示するインジケーターを含むＲＲＣ接続設定(ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ)信号を前記基地局に送信する段階と、を含む。

【0018】

他の実施形態による無線通信システムで端末は、他の端末とデータ送受信のためにＧａｔｅｗａｙ Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ(ＧＭＳＣ)でＣｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ ｖｏｉｃｅ ｎｅｔｗｏｒｋ(ＣＳ)サービスリクエストを送信する送受信部と、前記ＧＭＳＣから前記サービスリクエストに対するコール拒絶応答を受信するように前記送受信部を制御する制御部と、を含み、前記コール拒絶応答は前記他の端末のコアネットワークのうちの１つのエンティティーから送信することを特徴とする。

【0019】

また他の実施形態による混雑制御を実行する端末は、基地局へＮｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ（ＮＡＳ)リクエストを送信し、前記リクエストに対応してコアネットワークから混雑によるＮＡＳ拒絶を受信する送受信部と、前記送受信部を制御して前記端末と前記基地局の間のＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ(ＲＲＣ)接続を解除しなければならないことを指示するインジケーターを含むＲＲＣ接続設定(ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ)信号を前記基地局へ送信する制御部と、を含む。

【発明の効果】

【0020】

実施形態によれば、ＰＳサービスだけ使用する受信端末機に発信端末機がＣＳサービスをリクエストする場合にも網のロードを高めない状態でサービス提供が可能である。

【0021】

他の実施形態によれば、ユーザ端末が一般コールを使用している途中、緊急コールを提供しなければならない場合にも緊急コールの要求条件に当るサービスを提供することができる効果を奏する。

【0022】

また他の実施形態によれば、網の混雑状況で混雑を解決するとき、網のロードを減らすことができる方向へサービス提供することが可能である。

【図面の簡単な説明】

【0023】

【図1】ＬＴＥ移動通信システムの構造を示した図面である。

【図2】第１実施形態による信号送受信過程を示した図面である。

【図3】第１実施形態による他の信号送受信過程を示した図面である。

【図4】第１実施形態によるまた他の信号送受信過程を示した図面である。

【図5】第２実施形態による信号送受信過程を示した図面である。

【図6】第２実施形態による他の信号送受信過程を示した図面である。

【図7】第２実施形態による他の信号送受信過程を示した図面である。

【図8】第２実施形態によるまた他の信号送受信過程を示した図面である。

【図9】第３実施形態による信号送受信過程を示した図面である。

【図10】第３実施形態による他の信号送受信過程を示した図面である。

【図11】第３実施形態による他の信号送受信過程を示した図面である。

【図12】第３実施形態によるまた他の信号送受信過程を示した図面である。

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

【0024】

以下、本発明の実施形態を説明するに当り、関連する公知機能又は構成に対する具体的な説明が本発明の要旨を不明瞭にすることができると判断される場合にはその詳細な説明を省略する。

【0025】

同一理由で添付図面において一部構成要素は誇張されたり省略されたり概略的に示した。また、各構成要素の大きさは実際大きさを全的に反映するものではない。各図面で同一又は対応する構成要素には同一参照番号を付す。

【0026】

また、本発明の実施形態を具体的に説明するに当り、基本的な３ＧＰＰ(Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)ＬＴＥシステムを主な対象とするが、本発明の実施形態は類似の技術的背景及びシステム形態を有するそのほかの通信／コンピューターシステムにも本発明の範囲を大きく外れない範囲で適用可能であり、これは本発明の技術分野で熟練された技術的知識を有する者の判断で可能であろう。例えば、ＬＴＥシステムを対象とした本技術は類似のシステム構造を有するＵＴＲＡＮ／ＧＥＲＡＮシステムでも適用されることができる。この場合、ＥＮＢ(ＲＡＮノード)はＲＮＣ／ＢＳＣに対置されることができ、ＭＭＥはＳＧＳＮに対置されることができ、Ｓ−ＧＷは省略されたりＳＧＳＮに含まれ、Ｐ−ＧＷはＧＧＳＮに対応されることができる。

【0027】

また、ＬＴＥシステムのｂｅａｒｅｒ概念は、ＵＴＲＡＮ／ＧＥＲＡＮシステムのＰＤＰ ｃｏｎｔｅｘｔに対応されることができる。また、実施形態の全般で各通信エンティティーは他のエンティティーと信号を送受信できる送受信部及び前記送受信部を制御して前記送受信部を通じて送受信される信号に基づいて演算ができる制御部を含むことができる。また、実施形態で端末はユーザに視覚的な信号を与えることができる表示部を含むことができる。

【0028】

＜第１実施形態＞
今まで一般的に無線通信サービスを受けるユーザは、音声通話のためのＣＳ(Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ ｖｏｉｃｅ ｎｅｔｗｏｒｋ)サービスとデータ通信のためのＰＳ（Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ ｄａｔａ ｎｅｔｗｏｒｋ)サービスに対する加入を同時にすることが一般的であった。

【0029】

実施形態でＰＳサービスに対してだけ加入されたユーザが仮定されることができる。実施形態でＰＳサービスに対してだけ加入されたユーザもＳＭＳサービスは受けることができるが別途の措置無しにＣＳサービスが提供されることができない。即ち、実施形態で音声通話などのＣＳサービス無しにＰＳデータサービスとＳＭＳサービスを受けるユーザが(このようなユーザを今後ＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳユーザと称する)仮定されることができる。

【0030】

もし、ユーザ端末がＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳユーザのためにネットワークに登録された場合、プロバイダーネットワークはデータサービスとＳＭＳ送受信サービスをユーザに提供することができる。ところで、このようなユーザに対してモバイル端末(ｍｏｂｉｌｅ ｔｅｒｍｉｎａｔｉｎｇ)ＣＳサービス(例え、音声通話)リクエストが発生する場合が生ずることができる。例えば、受信者の電話番号を考慮せずランダム広告／広報電話、旧音声通話加入者に割り当てられてから回収されてＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳ加入者に割り当てられた電話番号に対して旧音声通話加入者で誤認して電話をかける場合があり得る。

【0031】

このようにＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳユーザにｍｏｂｉｌｅ ｔｅｒｍｉｎａｔｉｎｇ ＣＳサービス(音声通話)が発生すると、ネットワークは加入者の位置確認及びｐａｇｉｎｇなどのようなシグナリング過程を経るべきであり、いずれにしても加入者がＣＳサービス(音声通話サービス)を使用することができないので無意味な過程でプロバイダー網のロードだけ増加させる要因になる。

【0032】

実施形態では前記のような問題を解決するために次の過程を提案する。実施形態のプロバイダー網で受信者が現在ＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳとしてネットワークに登録されており、この受信者にｍｏｂｉｌｅ ｔｅｒｍｉｎａｔｉｎｇ ＣＳサービス発生したことを認知した場合に、ユーザ端末がＣＳサービスに対してｄｅｔａｃｈされていると判断すること(即ち、音声通話を拒否すること、或いはＣＳサービスをサポートしないこと)で解決することができる。より具体的に次のような方案を利用することができる。

【0033】

図２は、第１実施形態によるＨＬＲ(Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）を判断主体とした信号送受信過程を示した図面である。

【0034】

段階２１０で、ＵＥ１(２０１)はＭＭＥ２０２、ＭＳＣＭ２０３及びＨＬＲ２０４のうちの１つ以上にＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳ端末で登録されることができる。実施形態でユーザ端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ)２０１は、ＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳを使用する端末で、ＰＳデータサービスとＳＭＳだけ使用可能である。実施形態全般でＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳはＣＳサービスを受けることができない端末も適用されることができる。

【0035】

段階２１５で相手のユーザの端末(ＵＥ２)(２０６)はＵＥ１(２０１)がＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳ加入者であることが分からず音声通話発信することができる。実施形態では音声通話で例示されるが、これに限定されずＣＳを通じるサービスを含むことができる。

【0036】

段階２２０で、ＵＥ２(２０６)はＵＥ１(２０１)を受信端末として音声通話発信をするためのリクエストをＧＭＳＣ(Ｇａｔｅｗａｙ Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ)２０５に伝達することができる。

【0037】

段階２２５で、前記音声通話リクエストがＧＭＳＣ２０５に到着すると、ＧＭＳＣ２０５は加入者が位置したＭＳＣ／ＶＬＲを探すためにＨＬＲ２０４にＳｅｎｄ Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ(ＳＲＩ)メッセージを伝達する。前記メッセージには現在発生したサービスが音声通話(又はＳＭＳ以外のＣＳサービスなのか)なのかＳＭＳなのかを示すためのｓｅｒｖｉｃｅ ｉｎｄｉｃａｔｏｒが含まれることができる。

【0038】

段階２３０で、ＨＬＲ２０４はユーザ端末の登録情報(又は加入情報)に応じて、ＵＥ１(２０１)へ向けるサービスがＳＭＳなのか否かと、前記ＵＥ１(２０１)の加入情報を判断する。もし、前記サービスがＳＭＳであればＵＥ１(２０１)が登録されたＭＳＣ２０３でサービスリクエストを伝達することができる。

【0039】

もし、サービスがそれ以外の(ＣＳサービスや音声通話)の場合、ＨＬＲ２０４は、ユーザ端末２０１が当該サービスに対してｄｅｔａｃｈされたことのように処理することができる。

【0040】

段階２３５で、この時、ＨＬＲ２０４はＳＲＩに対する応答で当該コールが拒否されたことを通知するメッセージをＧＭＳＣ２０５に伝達することができる。前記コール拒否メッセージにはユーザ端末がＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳの形態にだけ登録されたことを通知するための情報が含まれることができる。実施形態によって前記段階２３５の過程は、Ｓｅｎｄ Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージを使用したり、新しい形態のメッセージを使用して実行されることができる。

【0041】

段階２４０で、ＧＭＳＣ２０５はｎｅｇａｔｉｖｅ応答を受けた場合、ｐａｇｉｎｇ ｒｅｔｒｙをしてはいけないのでｐａｇｉｎｇ ｔｉｍｅｒを終了することができる。

【0042】

段階２４５で、ＧＭＳＣ２０５は音声通話(ＳＭＳ以外のＣＳサービス)に対する試みが失敗したことを発信者のネットワークに通知する。発信者のネットワークは、これを認知した場合、発信者端末２０６に受信者がＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳの形態で登録されており、他のＣＳサービス(音声通話)が不可能であり、ＳＭＳは使用可能であることを通知することができる。このような過程はＧＭＳＣ２０５が発信者端末２０６に通じて直接伝達したり、発信者ネットワークのＭＳＣに、そしてＭＳＣがＲＮＣ(ＢＳＣ)を通じて発信者端末２０６に前記情報を伝達することによって成ることができ、これを受信した発信者端末２０６はこれを記憶したりユーザに公知することができる。ユーザに対する前記公知は音声の形態で案内文句を伝達するが、ユーザ端末の画面を通じて通知することなどが含まれることができる。

【0043】

図３は、第１実施形態による他の信号送受信過程を示した図面である。

【0044】

図３を参照すれば、段階３１０でＵＥ１(３０１)はＭＭＥ３０２、ＭＳＣ３０３及びＨＬＲ３０４のうちの１つ以上にＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳ端末で登録されることができる。実施形態でユーザ端末(ＵＥ１)３０１は、ＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳを使用する端末で、ＰＳデータサービスとＳＭＳだけのうちの１つ以上を提供することができる。

【0045】

段階３１５で、相手ユーザの端末３０６は、ＵＥ１(３０１)がＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳ加入者であることが分からず音声通話発信することができる。

【0046】

段階３２０で、ＵＥ２(３０６)の音声通話リクエストがＧＭＳＣ３０５に到着すると、段階３２５でＧＭＳＣ３０５は、ＵＥ１(３０１)が位置したＭＳＣ３０３を探してＩＡＭメッセージを伝達することができる。前記ＩＡＭメッセージは、現在発生したサービスが音声通話(ＳＭＳ以外のＣＳサービス)なのかＳＭＳなのかを示すためのｓｅｒｖｉｃｅ ｉｎｄｉｃａｔｏｒが含むことができる。

【0047】

段階３３０で、ＭＳＣ３０３はもしＵＥ１(３０１)へ向けるサービスがＳＭＳであれば ＵＥ１(３０１)が登録されたＭＭＥ３０２にｐａｇｉｎｇ ｒｅｑｕｅｓｔを送信し、もしサービスがその以外のＣＳサービス(例えば、音声通話)であれば段階３３５でＵＥ１(３０１)のユーザがＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳで登録されたことをＧＭＳＣ３０５に通知するメッセージを伝達することができる。前記メッセージはコール拒絶(Ｃａｌｌ ｒｅｊｅｃｔ)メッセージであればよく、前記コール拒絶メッセージは拒絶原因を含むことができる。また、実施形態の段階３３５でＭＳＣ３０３は、ＲＣＨメッセージを使用したり、新しい形態のメッセージを通じてＵＥ１(３０１)のユーザがＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳで登録されたことを通知することができる。

【0048】

応答を受信した後のＧＭＳＣ３０５の作動は、図２の段階２４０と段階２４５と同一作動をそれぞれ段階３４０及び段階３４５で実行することができる。

【0049】

図４は、第１実施形態によるまた他の信号送受信過程を示した図面である。

【0050】

段階４１０で、ＵＥ１(４０１)はＭＭＥ４０２、ＭＳＣ４０３及びＨＬＲ４０４のうちの１つ以上にＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳ端末で登録されることができる。実施形態でユーザ端末(ＵＥ１)４０１は、ＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳを使用する端末である。

【0051】

ところが、段階４１５で相手ユーザの端末４０６はＵＥ１(４０１)がＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳ加入者であることが分からず音声通話発信することができる。

【0052】

段階４２０で、音声通話リクエストがＧＭＳＣ４０５に到着すると、ＧＭＳＣ４０５は、ＵＥ１(４０１)が位置したＭＳＣ４０３を探してＩＡＭメッセージを伝達することができる。前記ＩＡＭメッセージは現在発生したサービスが音声通話(ＳＭＳ以外のＣＳサービス)なのかＳＭＳなのかを示すためのｓｅｒｖｉｃｅ ｉｎｄｉｃａｔｏｒが含むことができる。

【0053】

段階４３０で、ＭＳＣ４０３はＭＭＥ４０２にｐａｇｉｎｇ ｒｅｑｕｅｓｔメッセージを伝達する。前記ｐａｇｉｎｇ ｒｅｑｕｅｓｔメッセージは、ＳＧｓ＿Ｐａｇｉｎｇ＿Ｒｅｑメッセージを通じて伝達することができ、前記ＳＧｓ＿Ｐａｇｉｎｇ＿Ｒｅｑメッセージは前記ページングが何のサービスを提供するためのページングなのかを示すインジケーターを含むことができる。

【0054】

段階４３５で、ＭＭＥ４０２はもしＵＥ１(４０１)へ向けるサービスがＳＭＳであればサービスを進行することができる。

【0055】

もし、サービスがその以外のＣＳサービス(例えば、音声通話)であれば段階４４０でＵＥ１(４０１)のユーザがＰＳ ｏｎｌｙ ｗｉｔｈ ＳＭＳの形態で登録されていることを ＭＳＣ４０３に通知するメッセージを伝達することができる。前記メッセージは、Ｐａｇｉｎｇ ｒｅｊｅｃｔであってもよく、前記メッセージはページング拒絶の理由を示したインジケーターを含むことができる。また実施形態でＭＭＥ４０２はＳＧｓ ｐａｇｉｎｇ ｒｅｊｅｃｔメッセージを使用したり、新しい形態のメッセージを使用することもできる。

【0056】

段階４４５で、ＭＳＣ４０３はページング拒絶などのｎｅｇａｔｉｖｅ応答を受けた場合、ｐａｇｉｎｇ ｒｅｔｒｙをしてはいけないのでｐａｇｉｎｇ ｔｉｍｅｒを終了することができる。

【0057】

段階４５０で、ＭＳＣ４０３は音声通話をするためのコールが拒絶されたことをＧＭＳＣ４０５に通知することができる。実施形態で音声通話試みが失敗したことを発信者のネットワークに通知する形態ではコール拒絶メッセージと共に拒絶された原因を含むメッセージを通じてＧＭＳＣ４０５に通知することができる。

【0058】

以後、発信者ネットワークの段階４５５及び段階４６６の作動は、前記図２の段階２４０及び段階２４５と同一に進行されることができる。

【0059】

＜第２実施形態＞
一方、端末が緊急サービス(ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅ)を受けようとする時は、一般ベアラー(ｎｏｒｍａｌ ｂｅａｒｅｒ)ではない緊急ベアラー(ｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ)が生成しなければならない。普通の場合、一般的なｎｏｒｍａｌ ｂｅａｒｅｒはｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒに転換されて使用されることができない。もし、ユーザがｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅをリクエストした場合、実施形態によってプロバイダーネットワークはｌｏｃａｌ ｒｅｇｕｌａｔｉｏｎ(政府の規制など)で決めた時間限度内にｅｍｅｒｇｅｎｃｙ ｃａｌｌをｓｅｔｕｐ(設定)するべきである。

【0060】

ところで、ユーザ端末が同時にａｃｔｉｖａｔｉｏｎできる最大ｂｅａｒｅｒの個数は具現によって制限されることができる。端末は、一般的に最大１、３、或いは５個までｂｅａｒｅｒを同時にａｃｔｉｖａｔｉｏｎできる。もし、端末がシステムにａｔｔａｃｈ（登録)して使用中のｎｏｒｍａｌ ｂｅａｒｅｒの数が最大ｂｅａｒｅｒの数に至った場合に緊急コール(ｅｍｅｒｇｅｎｃｙ ｃａｌｌ)を実行する場合や、それともｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅに必要な最大ｂｅａｒｅｒの数が複数の場合、ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのためのｂｅａｒｅｒを全部生成すると、端末がサポートすることができる最大ｂｅａｒｅｒの数を超過するようになることができる(例えば、最大サポートｂｅａｒｅｒ数は３個、ａｃｔｉｖｅ ｎｏｒｍａｌ ｂｅａｒｅｒの数は２個、必要Ｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒの数は２個である場合)。この場合には、ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅ提供のためにはｎｏｒｍａｌ ｂｅａｒｅｒを整理してｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒを生成すべきである必要性がある。

【0061】

端末は、自分が使用することができるｂｅａｒｅｒ最大個数、現在活性化(ａｃｔｉｖｅ)されたｎｏｒｍａｌ ｂｅａｒｅｒの数、及びｅｍｅｒｇｅｎｃｙ ｃａｌｌ(ｓｅｒｖｉｃｅ)に必要なｂｅａｒｅｒの数を考慮してｎｏｒｍａｌ ｂｅａｒｅｒ整理を実行した後、ｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒを設定(ｓｅｔｕｐ)したり、それともｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ ｓｅｔｕｐをリクエストしながらｎｏｒｍａｌ ｂｅａｒｅｒ整理を同時にリクエストすることもできる。

【0062】

即ち、ユーザ端末はｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅが必要であれば、ｎｏｒｍａｌ ｂｅａｒｅｒに対する非活性(ｄｅａｃｔｉｖａｔｉｏｎ)をネットワークにリクエストしたり、内部的な非活性(ｌｏｃａｌｌｙ ｄｅａｃｔｉｖａｔｉｏｎ)した後、ベアラーコンテキスト(ｂｅａｒｅｒ ｃｏｎｔｅｘｔ)の状態をＴＡＵ過程を通じてコア網に通知することができる。一方、コア網(例えば、ＭＭＥ)が端末の最大サポートｂｅａｒｅｒ数が分かっている場合には端末がｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ生成をリクエストした場合、自分でｎｏｒｍａｌ ｂｅａｒｅｒを整理して与えてもよい。より具体的に、次のような解決方案を使用することができる。

【0063】

図５は、第２実施形態による信号送受信過程を示した図面である。

【0064】

より具体的に、図５は本発明の一実施形態によってａｔｔａｃｈ過程を通じてｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅを提供する方法を示す。

【0065】

図５を参照すれば、実施形態２で端末５０１がＭＭＥ５０２、ＳＧＷ５０３、ＰＧＢＷ５０４及びＨＳＳ５０５が含まれたネットワークと信号を送受信できる。実施形態によって端末５０１は、基地局を通じて前記ネットワークと信号を送受信できる。

【0066】

段階５１０で、端末５０１はユーザが緊急サービスを使用することを望むことを検出することができる。

【0067】

段階５１５で、端末５０１は現在使用するベアラー数を検出することができる。前記現在使用されるベアラーは実施形態によって一般ベアラー数字であることができる。端末５０１は、前記検出したベアラー数と前記緊急サービスに使用されるベアラー及び端末５０１が同時にサポートすることができるベアラー数に基づいて現在使用されるベアラーのうちで一部又は全部のベアラーが非活性化されるべきであるかを判断することができる。また、実施形態によって端末５０１は、自分が同時にａｃｔｉｖｅできるベアラーの個数が現在緊急コールのために必要なベアラーの個数を満たすことができないと判断することができる。

【0068】

前記判断結果、端末５０１が現在使用するベアラーを非活性化する必要がない場合、端末は緊急サービスのためのコールを形成(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するためにＭＭＥ５０２と信号を送受信できる。

【0069】

段階５１５で、一部又は全て使用中の一般ベアラーが非活性化される必要がある場合、端末５０１はｌ ｌｏｃａｌ ｄｅｔａｃｈを実行することができる。前記ｌｏｃａｌ ｄｅｔａｃｈは端末５０１の判断に応じて端末５０１が主導的に実行することができる。

【0070】

段階５２５で、端末５０１はＭＭＥ５０２に緊急サービス(ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅ)に対するｒｅ−ａｔｔａｃｈ過程を実行することができる。実施形態によって前記過程はＡｔｔａｃｈ ｒｅｑｕｅｓｔを送信しながらなることができ、前記ａｔｔａｃｈ ｒｅｑｕｅｓｔはコール又はサービスの種類を含むことができる。

【0071】

段階５３０及び段階５３５で端末５０１から前記ａｔｔａｃｈ ｒｅｑｕｅｓｔを受信したコア網は前記ａｔｔａｃｈ ｒｅｑｕｅｓｔに基づいて、ｅｍｅｒｇｅｎｃｙ ａｔｔａｃｈであることを判断し、認証／許可及びベアラーコンテキストセットアップを通じ、既存形成されたｎｏｒｍａｌ ｂｅａｒｅｒは削除(ｃｌｅａｎｕｐ)してｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ生成する。

【0072】

この結果、段階５４０でＵＥ５０１とコア網の間にＩＭＳコールが設定されることができる。

【0073】

図６は、第２実施形態による他の信号送受信過程を示した図面である。

【0074】

より具体的に、図６は本発明の一実施形態によってユーザ端末が明示的にｎｏｒｍａｌ ｂｅａｒｅｒの削除をリクエストする方法を示す。

【0075】

図６を参照すれば、実施形態で端末６０１がＭＭＥ６０２、ＳＧＷ６０３及びＰＧＷ６０４が含まれたネットワークと信号を送受信できる。実施形態によって端末６０１は基地局を通じて前記ネットワークと信号を送受信できる。

【0076】

段階６１０で、端末６０１はユーザが緊急サービスを使用することを望むことを検出することができる。

【0077】

段階６１５で、端末６０１は現在使用されるベアラー数を検出することができる。前記現在使用されるベアラーは実施形態によって一般ベアラー数字であってもよい。端末６０１は、前記検出したベアラー数と前記緊急サービスに使用されるベアラー及び端末６０１が同時にサポートすることができるベアラー数に基づいて現在使用されるベアラーのうちで一部又は全てベアラーが非活性化されるべきであるか判断することができる。また、実施形態によって端末６０１は自分が同時にａｃｔｉｖｅできるベアラーの個数が現在緊急コールのために必要なベアラーの個数を満たすことができないと判断することができる。

【0078】

前記判断結果、端末６０１が現在使用するベアラーを非活性化する必要がない場合、端末は緊急サービスのためのコールを確立(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するためにＭＭＥ６０２と信号を送受信できる。

【0079】

前記判断結果、端末６０４は同時に活性化(ａｃｔｉｖａｔｅ)できるベアラー(ｂｅａｒｅｒ)の個数によって緊急コールのためのベアラー個数を充足させることができないと判断した場合に段階６２０でｎｏｒｍａｌ ｂｅａｒｅｒ又はｎｏｒｍａｌ ＰＤＮ ｃｏｎｎｅｃｔｉｏｎ削除をコア網にリクエストする。実施形態で前記リクエストはＲｅｑｕｅｓｔ ｂｅａｒｅｒ ｒｅｓｏｕｒｃｅ ｍｏｄｉｆｉｃａｔｉｏｎ又はＰＤＮ ｄｉｓｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔを通じてＭＭＥ６０２へ伝達することができる。

【0080】

段階６２５で前記リクエストを受信したＭＭＥ６０２はベアラーリソースコマンド又はセッション削除リクエストを通じてＳＧＷ６０３へ前記リクエストを伝達することができる。

【0081】

段階６３０で、前記リクエストを受信したＳＧＷ６０３はベアラーリソースコマンド又はセッション削除リクエストを通じてＰＧＷ６０５へ前記リクエストを伝達することができる。

【0082】

段階６３５乃至段階６４５で前記リクエストに対する応答をＰＧＷ６０４からＳＧＷ６０３、ＳＧＷ６０３からＭＭＥ６０２、ＭＭＥ６０２から端末６０１へ伝達することができる。

【0083】

段階６５０で、以前段階の結果で端末６０１はｄｅｔａｃｈされることができる。

【0084】

段階６５０で、端末６０１はＭＭＥ６０２でＡｔｔａｃｈ Ｒｅｑｕｅｓｔ又はＰＤＮ 接続リクエストを送信することができる。前記リクエスト送信のとき、タイプ情報に緊急であるか否かを表示することができる。また実施形態に応じてｅｍｅｒｇｅｎｃｙ ＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔを送信し、もし、全てｂｅａｒｅｒが削除された場合には端末はｄｅｔａｃｈされるので、代わりにｅｍｅｒｇｅｎｃｙ ａｔｔａｃｈ ｒｅｑｕｅｓｔを送信することができる。

【0085】

段階６６０で、緊急ａｔｔａｃｈ及びＰＤＮ接続設定のうちの１つ以上が実行されることができ、段階６５０でＩＭＣコールが設定されることができる。

【0086】

一方、本発明のまた他の一実施形態によれば、ユーザ端末６０１はｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのために既存ｂｅａｒｅｒをｌｏｃａｌｌｙ ｄｅａｃｔｉｖａｔｅさせた後、ＴＡＵ過程を通じてこれをコア網に通知することもできる。より具体的に、ユーザがｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅをＵＥ６０１にリクエストすると、ＵＥ６０１はｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのために既存ｂｅａｒｅｒの一部又は全体がｄｅａｃｔｉｖａｔｅされるべきと判断される場合、ｄｅａｃｔｉｖａｔｅされるｂｅａｒｅｒを選択した後、これらを除いた残りａｃｔｉｖｅ ＥＰＳ ｂｅａｒｅｒの情報だけＴＡＵ ｒｅｑｕｅｓｔメッセージのＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓにａｃｔｉｖｅ ｂｉｔをセッティングしてコアネットワークに送信することができる。また他の実施形態によれば、ＵＥ６０１はｄｅａｃｔｉｖａｔｅされるｂｅａｒｅｒはｉｎａｃｔｉｖｅと表示し、残すｂｅａｒｅｒはａｃｔｉｖｅにセッティングしてコアネットワークへ送信することもできる。この時、ＵＥ６０１はＥＰＳ ｕｐｄａｔｅ ｔｙｐｅを通じて現在送信するＴＡＵがｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅに対するリクエストをコアネットワークに通知することができる。また他の実施形態で端末６０１はＡｄｄｉｔｉｏｎａｌ ｕｐｄａｔｅ ｔｙｐｅを通じて現在送信するＴＡＵがｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅに対するリクエストなのをコアネットワークに通知することができる。また他の実施形態によれば端末６０１は別途のｅｍｅｒｇｅｎｃｙ ｉｎｄｉｃａｔｏｒを通じて現在送信するＴＡＵがｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅに対するリクエストなのをコアネットワークに通知することができる。端末６０１はさらにつながるｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのためにＳ１／Ｓ５ ｓｅｔｕｐが進行しなければならないことをコアネットワークに通知するためにａｃｔｉｖｅ ｆｌａｇもｓｅｔｔｉｎｇできる。

【0087】

ＭＭＥ６０２は、上記過程を通じてＵＥ６０１がｅｍｅｒｇｅｎｃｙサービスのために ｂｅａｒｅｒ ｃｏｎｔｅｘｔを変えたことを認知することができる。ＭＭＥ６０２は自分が記憶しているＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓと端末がＴＡＵ ｒｅｑｕｅｓｔに入れたＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓを比べてｄｅａｃｔｉｖａｔｅしなければならないＥＰＳ ｂｅａｒｅｒがあればｂｅａｒｅｒ ｃｌｅａｎｕｐを実行することができる。

【0088】

ＭＭＥ６０２はＵＥ６０１がｅｍｅｒｇｅｎｃｙサービスのためにＴＡＵを送信した場合は、ＵＥ６０１がつながるｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅリクエスト(ＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔ)を早く送信するようにＴＡＵ ａｃｃｅｐｔをｂｅａｒｅｒ ｃｌｅａｎｕｐが完了する前に前記ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅリクエストを送信することができる。

【0089】

端末６０１は、ＴＡＵ ａｃｃｅｐｔを受けると自分がリクエストしたｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓの修正が完了したことを分かるようになり、つながるＥｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのためのｐｒｏｃｅｄｕｒｅを実行する。

【0090】

もし、ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのためのｂｅａｒｅｒ整理の必要な状況がｉｄｌｅ ｍｏｄｅで発生した場合には実施形態で、次の方法を適用してもよい。
ユーザ端末６０１はｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのために既存ｂｅａｒｅｒの一部又は全体がｄｅａｃｔｉｖａｔｅされなければならないと判断される場合、ｄｅａｃｔｉｖａｔｅされるｂｅａｒｅｒを選択した後、これらを除いた残りａｃｔｉｖｅ ＥＰＳ ｂｅａｒｅｒの情報だけＴＡＵ ｒｅｑｕｅｓｔメッセージのＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓにａｃｔｉｖｅ ｂｉｔをセッティングして入れてコアネットワークに送信する。又はＵＥ６０１はｄｅａｃｔｉｖａｔｅされるｂｅａｒｅｒはｉｎａｃｔｉｖｅで表示し、残すｂｅａｒｅｒはａｃｔｉｖｅにセッティングしてコアネットワークに送信することもできる。Ｉｄｌｅ ｍｏｄｅなのでＴＡＵ ｒｅｑｕｅｓｔを送信するために端末６０１はｅＮＢとＲＲＣ ｃｏｎｎｅｃｔｉｏｎを結ばなければならない。ＵＥ６０１はＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ ｒｅｑｕｅｓｔを送信しながらｅｓｔａｂｌｉｓｈｍｅｎｔ ｃａｕｓｅをｅｍｅｒｇｅｎｃｙでｓｅｔｔｉｎｇできる。

【0091】

ｅＮＢは、ＵＥ６０１から受けたＲＲＣメッセージに含んでいるＴＡＵ ｒｅｑｕｅｓｔメッセージをＳ１−ＡＰのＩｎｉｔｉａｌ ＵＥメッセージを通じて伝達するのに、もし、ＲＲＣ ｅｓｔａｂｌｉｓｈｍｅｎｔ ｃａｕｓｅがｅｍｅｒｇｅｎｃｙであればこれをＴＡＵ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅと共に伝達することができる。

【0092】

ＭＭＥ６０２は、ＴＡＵ ｒｅｑｕｅｓｔを受けたがＲＲＣ ｅｓｔａｂｌｉｓｈｍｅｎｔ ｃａｕｓｅがｅｍｅｒｇｅｎｃｙであればＵＥ６０１がｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのためにＴＡＵ ｒｅｑｕｅｓｔを送信したことが分かる。以後、作動は以前の過程同様に進行されてもよい。

【0093】

前記２つの実施形態ではユーザ端末６０１がｌｏｃａｌｌｙ ｄｅａｃｔｉｖｅしたｂｅａｒｅｒ情報をＴＡＵメッセージを使用してネットワークに通知することを説明したが、上記の過程は２Ｇ／３Ｇ網でＲＡＵ（Ｒｏｕｔｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ)メッセージを通じて同様に適用されることができる。又はユーザ端末６０１はネットワークに送信するＥＳＲ（Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)メッセージに前記ＴＡＵメッセージに入れたｂｅａｒｅｒ ｓｔａｔｕｓを挿入して代わりに送信することもできる。

【0094】

前記実施形態による方法は、既存システムの大きい変更無し適用されることができるというメリットがあるが、緊急状況でなるべくｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅをユーザに早く適用することができる改善案も必要なことがある。

【0095】

図７は、第２実施形態による他の信号送受信過程を示した図面である。

【0096】

より具体的に、図７は本発明の他の実施形態によって既存ｂｅａｒｅｒに対する整理と新しいｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒの生成が同時に進行されることができるようにする信号送受信方法に対して開示している。

【0097】

図７を参照すれば、実施形態では端末７０１がＥＮＢ７０２、ＭＭＥ７０３、ＳＧＷ７０４及びＰＧＷ７０５が含まれたネットワークと信号を送受信できる。

【0098】

段階７１０で、端末７０１はユーザが緊急サービスを使用することを望むことを検出することができる。

【0099】

段階７１５で、端末７０１は現在使用されるベアラー数を検出することができる。前記現在使用されるベアラーは、実施形態によって一般ベアラー数字であってもよい。端末７０１は前記検出したベアラー数と前記緊急サービスに使用されるベアラー及び端末７０１が同時にサポートすることができるベアラー数に基づいて現在使用されるベアラーのうちで一部又は全てベアラーが非活性化しなければならないかを判断することができる。また、実施形態によって端末７０１は自分が同時にａｃｔｉｖｅできるベアラーの個数が現在緊急コールのために必要なベアラーの個数を満たすことができないと判断することができる。

【0100】

前記判断結果、端末７０１が現在使用するベアラーを非活性化する必要がない場合、端末は緊急サービスのためのコールを確立(ｅｓｔａｂｌｉｓｈｍｅｎｔ)するためにＭＭＥ７０２と信号を送受信できる。

【0101】

前記判断結果、ユーザがｅｍｅｒｇｅｎｃｙ ｃａｌｌリクエストしたとき、ＵＥ７０１はｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのために既存ｂｅａｒｅｒの一部又は全体がｄｅａｃｔｉｖａｔｅしなければならないと判断される場合、段階７２０で端末７０１はｄｅａｃｔｉｖａｔｅされるｂｅａｒｅｒを選択した後、これらを除いた残りａｃｔｉｖｅ ＥＰＳ ｂｅａｒｅｒの情報だけＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔメッセージのＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓにａｃｔｉｖｅ ｂｉｔをセッティングして入れてＭＭＥ７０３に送信することができる。また他の実施形態でＵＥ７０１はｄｅａｃｔｉｖａｔｅされるｂｅａｒｅｒはｉｎａｃｔｉｖｅと表示し、残すｂｅａｒｅｒはａｃｔｉｖｅにセッティングしてＭＭＥ７０３に送信することもできる。端末７０１が削除するｂｅａｒｅｒを選択する基準はＡＲＰによって、ＱＣＩによって、或いはｄｅｆａｕｌｔ／ｄｅｄｉｃａｔｅｄ ｂｅａｒｅｒであるか否かによって(ｄｅｄｉｃａｔｅ ｂｅａｒｅｒを削除)、及び一定時間ａｃｔｉｖｉｔｙがないｂｅａｅｒなのかのうちのいずれか１つによって決定されることができる。

【0102】

段階７２０で、ＭＭＥ７０３は上記の過程を通じてＵＥ７０１がｅｍｅｒｇｅｎｃｙサービスのためにｂｅａｒｅｒ ｃｏｎｔｅｘｔを変えたことを認知することができる。ＭＭＥ７０３は自分が記憶しているＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓと端末がＰＤＰ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔに入れたＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓを比べてｄｅａｃｔｉｖａｔｅしなければならないＥＰＳ ｂｅａｒｅｒがあればｂｅａｒｅｒ ｃｌｅａｎｕｐを実行することができる。また、段階７１５で受信した情報に基づいてｂｅａｒｅｒ ｃｌｅａｎｕｐを実行することもできる。これと共にＭＭＥ７０３はｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのためのＰＤＮ ｃｏｎｎｅｃｔｉｏｎを生成する過程を実行することができる。

【0103】

段階７２５で、ＭＭＥ７０３はセッション生成リクエストをＳＧＷ７０４に送信することができる。前記セッション生成リクエストは除去すべきであるベアラーＩＤを含むことができる。

【0104】

段階７３０で、ＳＧＷ７０４はＰＧＷ７０５に段階７２５で受信した信号に基づいてセッション生成リクエストを伝達することができる。

【0105】

段階７３５乃至段階７４５で各ノードは応答メッセージを伝達することができ、段階７５０でｅＮＢ７０２は端末７０１にＲＲＣ ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎを伝達することができる。前記ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎはＤＢＲリストを含むことができる。

【0106】

段階７５５で、端末とコアネットワークの間にＩＭＳコール設定になることができる。

【0107】

図８は、第２実施形態による他の信号送受信過程を示した図面である。

【0108】

より具体的に図８でユーザ端末８０１は、ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅに対するｂｅａｒｅｒ設定をリクエストしながら、既存ｎｏｒｍａｌ ｂｅａｒｅｒの整理をネットワークですることをリクエストすることもできる。

【0109】

図８を参照すれば、実施形態では端末８０１がｅＮＢ８０２、ＭＭＥ８０３、ＳＧＷ８０４及びＰＧＷ８０５が含まれたネットワークと信号を送受信できる。

【0110】

段階８１０及び段階８１５は、図７の段階７１０及び段階７１５と同様に進行されることができる。

【0111】

段階８２０でユーザがｅｍｅｒｇｅｎｃｙ ｃａｌｌリクエストすれば、端末８０１は自分が同時にａｃｔｉｖａｔｅできるｂｅａｒｅｒの個数によってｅｍｅｒｇｅｎｃｙ ｃａｌｌのためのｂｅａｒｅｒ個数を充足させる事ができないと判断した場合、Ｅｍｅｒｇｅｎｃｙ ＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔに単純に既存ｂｅａｒｅｒに対する整理をリクエストすることを通知する識別子を含むことができる。また、前記リクエストには端末８０１が同時にサポートすることができるベアラー情報を含ませることができる。

【0112】

段階８２５で、もし端末８０１が同時にａｃｔｉｖａｔｅできる最大ｂｅａｒｅｒの個数がコア網に予め通知された場合であればＭＭＥ８０３が端末がｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅをリクエストした場合、自意的にｂｅａｒｅｒ処理をすることができる。又はもしユーザ端末８０１がｂｅａｒｅｒ整理をリクエストしたが、ユーザ端末８０１でサポートするｂｅａｒｅｒ数に対する情報を網が有していない場合、ＭＭＥ８０３単純が全てのｎｏｒｍａｌ ｂｅａｒｅｒを削除することも可能である。

【0113】

実施形態でＭＭＥ８０３はユーザ加入情報によって端末８０１が同時にサポートすることができる最大ｂｅａｒｅｒが分かる。この場合には端末８０１のｃｏｎｔｅｘｔ ｔａｂｌｅにＩＳＭＩによる最大サポートｂｅａｒｅｒ数のｍａｐｐｉｎｇがあるとか、それともＩＭＥＩＳＶを基準で端末８０１機種によって最大使用することができるｂｅａｒｅｒの数が分かることもできる。この場合には、ＭＭＥ８０３内部にＩＥＭＩＳＶによるユーザ端末機種、及びこの機種で使用することができる最大ｂｅａｒｅｒの数に対するｍａｐｐｉｎｇが設定されていなければならない。

【0114】

プロバイダーはＭＭＥ８０３にこのような情報を通知するためにＨＳＳの端末情報を更新したり、それともＯ＆Ｍなどのｃｏｎｆｉｇｕｒａｔｉｏｎ方式を使用して、ＭＭＥ８０３に端末８０３のＩＭＥＩＳＶによる機種、及びこれによる最大ｂｅａｒｅｒの数を設定することができる。

【0115】

端末８０１がｅｍｅｒｇｅｎｃｙ ＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔを送信するとＭＭＥ８０３は端末８０１に対する情報によって最大ｂｅａｒｅｒサポート個数によってｎｏｒｍａｌ ｂｅａｒｅｒの全体又は一部が削除しなければならないと判断することができる。もし、一部ｂｅａｒｅｒだけ削除する場合、削除するｂｅａｒｅｒを選択する基準はＡＲＰに応じて、又はＱＣＩに応じて又はｄｅｆａｕｌｔ／ｄｅｄｉｃａｔｅｄ ｂｅａｒｅｒであるか否かに応じて(ｄｅｄｉｃａｔｅ ｂｅａｒｅｒを削除)、又は一定時間ａｃｔｉｖｉｔｙがないｂｅａｒｅｒなのかに応じて決まることができる。

【0116】

段階８３０及び段階８３５で、コア網はａｃｔｉｖｅにされている当該ｎｏｒｍａｌ ｂｅａｒｅｒを削除し(Ｓ−ＧＷ８０４とＰ−ＧＷ８０５までｂｅａｒｅｒ ｃｌｅａｎｕｐ)、ｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ／ｓｅｓｓｉｏｎを生成する。ここで既存ｂｅａｒｅｒ削除と新しいｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ生成は同時に発生することもでき、並列的に別に進行されることもできる。同時に進行される場合は、ｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ生成のためのｃｒｅａｔｅ ｓｅｓｓｉｏｎ ｒｅｑｕｅｓｔメッセージに削除するｂｅａｒｅｒのｌｉｓｔを示したりｎｏｒｍａｌ ｂｅａｒｅｒ全体削除表示するためのｃｌｅａｎｕｐ ｉｎｄｉｃａｔｏｒを挿入することができる。

【0117】

ＭＭＥ８０３は、削除されたｂｅａｒｅｒの情報と新しくできたｂｅａｒｅｒの情報(ｂｅａｒｅｒ ｉｄ、ｂｅａｒｅｒ ＱｏＳ、Ｓ５ ＴＥＩＤなど)をｅＮＢ８０２に通知する。ｅＮＢ８０２は、これによってＵＥ８０１間のｄａｔａ ｒａｄｉｏ ｂｅａｒｅｒを更新する。

【0118】

コア網はｅｍｅｒｇｅｎｃｙ ＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔに削除するｂｅａｒｅｒ ｉｄが含まれた場合、ａｃｔｉｖｅにされている当該ｎｏｒｍａｌ ｂｅａｒｅｒを削除(Ｓ−ＧＷ８０４とＰ−ＧＷ８０５までｂｅａｒｅｒ ｃｌｅａｎｕｐ)してｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ／ｓｅｓｓｉｏｎを生成することができる。

【0119】

ここで既存ｂｅａｒｅｒ削除と新しいｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ生成は同時に発生することもでき、並列的に別に進行されることもできる。同時に進行される場合はｅｍｅｒｇｅｎｃｙ ｂｅａｒｅｒ生成のために伝達するｃｒｅａｔｅ ｓｅｓｓｉｏｎ ｒｅｑｕｅｓｔメッセージに削除するｂｅａｒｅｒのｌｉｓｔ又はｎｏｒｍａｌ ｂｅａｒｅｒ全体削除のためのｃｌｅａｎｕｐ ｉｎｄｉｃａｔｏｒを挿入することができる。

【0120】

ＭＭＥ８０３は、削除されたｂｅａｒｅｒの情報と新しくできたｂｅａｒｅｒの情報(ｂｅａｒｅｒ ｉｄ、ｂｅａｒｅｒ ＱｏＳ、Ｓ５ ＴＥＩＤなど)をｅＮＢ８０２に通知することができる。ｅＮＢ８０２はこれによってＵＥ８０１間のｄａｔａ ｒａｄｉｏ ｂｅａｒｅｒを更新し、最終的にこれはユーザ端末８０１に通知する。

【0121】

一方、本発明の別の実施形態によって、ＥＭＭ過程とＥＳＭ過程を併合する方法も提案する。即ち、ＴＡＵ／ＲＡＵ ｒｅｑｕｅｓｔメッセージとＥＳＲメッセージにＥＳＭ ｍｅｓｓａｇｅ ｃｏｎｔａｉｎｅｒを含んで送信することである。ここでＥＳＭ ｍｅｓｓａｇｅ ｃｏｎｔａｉｎｅｒには端末８０１が生成して送信するＥＳＭ ｒｅｑｕｅｓｔメッセージ(例えば、ＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔ)が含まれることができる。

【0122】

より具体的に、ｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅがｉｎｉｔｉａｔｉｏｎされた場合、ユーザ端末８０１はｌｏｃａｌｌｙ ｄｅａｃｔｉｖａｔｅ−ｂｅａｒｅｒの情報をＴＡＵ／ＲＡＵ ｒｅｑｕｅｓｔ又はＥＳＲメッセージを通じて以前の実施形態によって送信しながら、同時にＥＳＭ ｍｅｓｓａｇｅ ｃｏｎｔａｉｎｅｒにＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔを含んで共に送信する。即ち、端末８０１は自分がｌｏｃａｌｌｙ ｄｅａｃｔｉｖａｔｉｏｎさせたｂｅａｒｅｒの情報又はｄｅａｃｔｉｖａｔｉｏｎされた後、残っているｂｅａｒｅｒの情報をＴＡＵ ｒｅｑｕｅｓｔ／ＲＡＵ ｒｅｑｕｅｓｔ／ＥＳＲメッセージのＥＰＳ ｂｅａｒｅｒ ｃｏｎｔｅｘｔ ｓｔａｔｕｓ ＩＥに含み、ＥＳＭ ｍｅｓｓａｇｅ ｃｏｎｔａｉｎｅｒにｅｍｅｒｇｅｎｃｙ ｓｅｒｖｉｃｅのためのＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔを含ませてＴＡＵ／ＲＡＵ ｒｅｑｕｅｓｔ又はＥＳＲメッセージをＭＭＥ８０３に送信する。ＭＭＥ８０３は以前の実施形態によって端末のｂｅａｒｅｒに対するｃｌｅａｎｕｐを実行すると共にＥＳＭ ｍｅｓｓａｇｅ ｃｏｎｔａｉｎｅｒに入っているＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ ｒｅｑｕｅｓｔ メッセージを利用してＰＤＮ ｃｏｎｎｅｃｔｉｏｎ生成リクエストも処理することができる。前述の実施形態２による緊急コール提供方法で各信号の含む情報は互いに変えて使用されることができる。

【0123】

＜実施形態３＞
一方、もし、コアネットワークノード(例えば、ＭＭＥ、ＳＧＳＮ)が多いシグナリング処理によって混雑の場合、コアネットワークノードは自分にサービスを受けているユーザ端末が他のコアネットワークノードにサービス受けるように迂回するように誘導することができる。

【0124】

この過程は、基地局ノードがユーザ端末のためのコアネットワークノードを新しく選択する過程と、ユーザ端末の情報をコアネットワークノードに登録する過程を通じてなる。ところで、もし基地局ノードがユーザ端末のためのコアネットワークの選択過程中に前記混雑した既存コアネットワークノードをさらに選んだら、混雑状況が改善し難い。一方、基地局が新しいコアネットワークノードを選択してユーザ端末に対するコアネットワークノードが変更された場合、新しいコアネットワークノードはユーザ端末に対する情報を登録しなければならないのに、この過程のうちに既存コアネットワークノードに記憶されているユーザ端末の情報を得ようとリクエストすると、これを処理するために混雑した既存コアネットワークノードの状態が悪くなることができる。

【0125】

実施形態で先ず(混雑状態である)既存コアネットワークノードはユーザ端末に混雑によってサービス提供が困難であることをＮＡＳ階層の情報を通じて通知する。これを受信したユーザ端末はコアネットワークに対する登録(ｒｅｇｉｓｔｒａｔｉｏｎ)再設定過程で、下位階層(ＡＳ ｌａｙｅｒ)に既存コアネットワークノードを探すことができる情報(例えば、Ｓ−ＴＭＳＩ、ＧＵＴＩ、ＧＵＭＭＥI、又はＰ−ＴＭＳＩ)を提供しない。既存コアネットワークノードに対する情報がなければ、端末のＡＳ階層は基地局とＲＲＣ接続を生成するとき、当該情報を提供することができなく、これは基地局がユーザ端末に対する新しいコアネットワークノードを選択するように誘発する。ユーザ端末のＮＡＳリクエストメッセージ(例えば、ａｔｔａｃｈ ｒｅｑｕｅｓｔ)は基地局を通じて新しく選択されたコアネットワークノードへ伝達する。この時、ユーザ端末は新しいコアネットワークノードがユーザ端末に対する情報(ｃｏｎｔｅｘｔ)を既存コアネットワークノードから持って来て混雑が加重されることを防ぐために、新しいコアネットワークノードがユーザ端末の情報(ｃｏｎｔｅｘｔ)をＨＳＳと直接通信する過程を通じて設定するように誘発する情報(又は識別子)を新しいコアネットワークノードに伝達することができる。

【0126】

図９は、第３実施形態による信号送受信過程を示した図面である。

【0127】

図９を参照すれば、端末９０１がＲＡＮ９０２を通じてＭＭＥ／ＳＧＳＮ９０３、９０４と信号を送受信できる。また、ＭＭＥ／ＳＧＳＮ９０３、９０４の混雑によって既存に接続しているＯｌｄ ＭＭＥ／ＳＧＳＮ９０３と新たに接続するＮｅｗ ＭＭＥ／ＳＧＳＮ９０４に区別されることができる。しかし、実施形態でＭＭＥ／ＳＧＳＮが変更されることは混雑の原因ではない場合にも適用されることができることを明らかにする。

【0128】

段階９１０で、Ｏｌｄ ＭＭＥ／ＳＧＳＮ９０３に混雑状況が発生することができる。前記混雑状況はトラフィックの増加及び一部装置の副作動中の１つ以上を含むことができる。

【0129】

図面に示したように、混雑状態であるコアネットワークノード(以下、既存コアネットワークノードと称する)は段階９１５でユーザ端末９０１からＮＡＳリクエストメッセージ(例えば、ＴＡＵ ｒｅｑｕｅｓｔ又はａｔｔａｃｈ ｒｅｑｕｅｓｔ)が発生すると、段階９２０で混雑によってリクエストが断たれたことを通知したり、又はロード状態で端末９０１の再登録が必要であるという情報と共にユーザ端末９０１にＮＡＳ応答又は拒絶メッセージ(例えば、ＴＡＵ ｒｅｊｅｃｔ又はａｔｔａｃｈ ｒｅｊｅｃｔ)を伝達する。この時、ＮＡＳメッセージを含んで基地局９０２に伝達するＳ１−ＡＰメッセージ(Ｄｏｗｎｌｉｎｋ ＮＡＳ Ｔｒａｎｓｐｏｒｔ)には追加的にユーザ端末と基地局９０２の間のＲＲＣ接続が、ＮＡＳメッセージ伝達以後、削除しなければならないことをリクエストする情報(例えば、ｉｍｍｅｄｉａｔｅ ｒｅｌｅａｓｅ ｒｅｑｕｉｒｅｄ ｉｎｄｉｃａｔｏｒ)が含まれることができる。

【0130】

段階９２５で、基地局９０２はコアネットワークノードから受信したメッセージをＲＲＣメッセージ(ＤＬＩｎｆｏｒｍａｔｉｏｎＴｒａｎｓｆｅｒ)に含んでユーザ端末９０１に伝達することができる。前記ＲＲＣメッセージには混雑インジケーターと及びタイマー情報を含むことができる。

【0131】

特に前記のようにＲＲＣ接続を直ちに削除することをリクエストされた場合、段階９３０でメッセージが伝達すると、ＲＲＣ接続を解除する。このようにＲＲＣ接続を解除することは、基地局９０２がユーザ端末９０１のためのコアネットワークノードを再選択する作動がＲＲＣ接続を生成する過程中に実行されるから、ユーザ端末９０１がＮＡＳリクエストを実行するとき、既存ＲＲＣ接続をリサイクルすると、既存コアネットワークノードがさらに使用されることができるからである。

【0132】

これと類似の効果を得るさらに他の方法で、コアネットワークノードは常用者端末９０１に伝達する前記ＮＡＳ応答／拒絶メッセージ又は基地局９０２がユーザ端末９０１に伝達するＲＲＣメッセージ(ＤＬＩｎｆｏｒｍａｔｉｏｎＴｒａｎｓｆｅｒ)にｔｉｍｅｒ値を設定することができる。このｔｉｍｅｒは基地局９０２が既存のＲＲＣ接続を解除するのに必要な一種の保護区間である。即ち、ユーザ端末９０１は、コアネットワークノード又はＲＲＣメッセージを通じてｔｉｍｅｒ値を受信すると、当該ｔｉｍｅｒが経た後、ＮＡＳリクエストを試みることができる。

【0133】

段階９３５でユーザ端末９０１のＮＡＳ階層は、以後ＮＡＳリクエスト(ａｔｔａｃｈ ｒｅｑｕｅｓｔ)を試みるとき、下位階層に既存コアネットワークを探すことができる情報(例えば、Ｓ−ＴＭＳＩ、ＧＵＴＩ、ＧＵＭＭＥＩ、Ｐ−ＴＭＳＩなど)を伝達しない。

【0134】

段階９４０で、ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ／ｓｅｔｕｐが進行され、段階９４５でユーザ端末９０１のＡＳ階層でＲＲＣ接続を生成する過程中に既存コアネットワークを探すことができる情報(例えば、ＭＭＥルーティング情報)を基地局９０２に伝達しないこともある。

【0135】

段階９４５で、基地局９０２はＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｓｅｔｕｐ ｃｏｍｐｌｅｔｅメッセージを受信し、段階９５０でＲＡＮ９０２は既存コアネットワーク(Ｃｏｒｅ Ｎｅｔｗｏｒｋ、ＣＮ)を探すことができる情報がないので新しいコアネットワークノードを選択し、段階９５５で含まれているＮＡＳリクエストメッセージを新しいコアネットワークノードに伝達する。

【0136】

ユーザ端末９０１に対するＮＡＳリクエストメッセージを受信した新しいコアネットワークノードはユーザ端末９０１の情報(ｃｏｎｔｅｘｔ)を得るための過程を実行しなければならない。この時、新しいコアネットワークノードはユーザ端末９０１がＮＡＳリクエストメッセージに挿入した識別子(ＧＵＴＩ、又はｏｌｄ ＧＵＴＩ)を利用して必要な場合、既存コアネットワークノードにユーザ端末９０１の情報(ｃｏｎｔｅｘｔ)をリクエストすることができる。ところが、もし、混雑する既存コアネットワークノードにこのようなリクエストが集中される場合、混雑が加重されることができる。これを解決するため、既存コアネットワークノードは新しいコアネットワークノードに１)混雑が発生されるとこれを別途のｏｖｅｒｌｏａｄ ｉｎｄｉｃａｔｉｏｎのようなコアネットワーク間メッセージ交換を通じて通知した、又は２)新しいコアネットワークノードがｃｏｎｔｅｘｔリクエストのためにｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｒｅｑｕｅｓｔを送信すると、これに対する応答／拒絶を通じて混雑状況を通知することができる。これを受信した新しいコアネットワークノードは既存コアネットワークノードが混雑することを認知し、これを記憶して追後活用することができ、段階９６０でコアネットワークはユーザ端末９０１のＩＭＳＩを得るためのｉｄｅｎｔｉｔｙ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ過程を実行する。ユーザ端末９０１からＩＭＳＩを受信すると、これを活用して端末のｃｏｎｔｅｘｔを設定し、残りの登録過程を実行する(段階９６５)。

【0137】

図１０は、第３実施形態による他の信号送受信過程を示した図面である。

【0138】

図１０を参照すれば、端末１００１がＲＡＮ１００２を通じてＭＭＥ／ＳＧＳＮ１００３、１００４と信号を送受信できる。また、ＭＭＥ／ＳＧＳＮ１００３、１００４の混雑によって既存に接続しているＯｌｄ ＭＭＥ／ＳＧＳＮ１００３と新たに接続するＮｅｗ ＭＭＥ／ＳＧＳＮ１００４に区別されることができる。しかし、実施形態でＭＭＥ／ＳＧＳＮが変更されることは混雑の原因ではない場合にも適用されることができることを明らかにする。

【0139】

段階１０１０乃至段階１０４０の場合、図９の段階９１０乃至段階９４０とそれぞれ対応される。

【0140】

段階１０４５でユーザ端末１００１のＮＡＳ階層でＮＡＳリクエスト(ａｔｔａｃｈ ｒｅｑｕｅｓｔ)を生成するとき、端末１００１は新しいコアネットワークノードに現在発生したＮＡＳリクエストが既存コアネットワークノードの混雑又はコアネットワーク変更選好によって発生したことを直接通知する情報を含ませて送信することができる。段階１０５０で基地局１００２は新しいＣＮノードを選択してＮｅｗ ＭＭＥ／ＳＧＳＮ１００４でＩｎｉｔｉａｌ ＵＥ ｍｅｓｓａｇｅを送信することができ、前記Ｉｎｉｔｉａｌ ＵＥ ｍｅｓｓａｇｅはＣＮ ｏｖｅｒｌｏａｄによるｒｅ−ａｔｔａｃｈであることを通知するインジケーターを含むことができる。ユーザ端末１００１に対するＮＡＳリクエストメッセージを受信した新しいコアネットワークノードはユーザ端末１００１の情報(ｃｏｎｔｅｘｔ)を得るための過程を実行しなければならないのに(段階１０６０)、前記ＮＡＳリクエストの発生原因に対する情報(即ち、既存コアネットワークノードの混雑で又はコアネットワーク変更リクエストによって)が含まれた場合には、既存コアネットワークノードの混雑を認知し、これを記憶して追後活用することができ、もし必要であればユーザ端末１００１のＩＭＳＩを得るためのｉｄｅｎｔｉｔｙ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ過程を実行する。ユーザ端末１００１からＩＭＳＩを受信すると、これを活用して端末１００１のｃｏｎｔｅｘｔを設定し、残り登録過程を実行する(段階１０６５)。

【0141】

図１１は、第３実施形態による他の信号送受信過程を示した図面である。

【0142】

図１１を参照すれば、端末１１０１がＲＡＮ１１０２を通じてＭＭＥ／ＳＧＳＮ１１０３、１１０４と信号を送受信できる。また、ＭＭＥ／ＳＧＳＮ１１０３、１１０４の混雑によって既存に接続しているＯｌｄ ＭＭＥ／ＳＧＳＮ１１０３と新たに接続するＮｅｗ ＭＭＥ／ＳＧＳＮ１１０４に区別されることができる。しかし、実施形態でＭＭＥ／ＳＧＳＮが変更されることは混雑の原因ではない場合にも適用されることができることを明らかにする。

【0143】

段階１１１０乃至段階１１５０の場合、図９の段階９１０乃至９５０とそれぞれ対応されることができる。

【0144】

実施形態でユーザ端末１１０１のＮＡＳ階層でＮＡＳリクエスト(ａｔｔａｃｈ ｒｅｑｕｅｓｔ)を生成するとき、現在発生したＮＡＳリクエストが既存コアネットワークノードの混雑又はコアネットワーク変更選好によって発生した場合、ＧＵＴＩ、ｏｌｄ ＧＵＴＩ代わりにＩＭＳＩを端末識別子で含んで伝達することである。これは新しいコアネットワークノードが既存コアネットワークノードにユーザ端末の情報(ｃｏｎｔｅｘｔ)をリクエストしないようにして、ＩＭＳＩに基づいて端末(１１０１)のｃｏｎｔｅｘｔを設定し、残り登録過程を実行するようにする。

【0145】

段階１１５５で基地局１１０２はＩｎｉｔｉａｌ ＵＥ ｍｅｓｓａｇｅにＮＡＳ ｒｅｑｕｅｓｔと端末１１０１のＩＭＳＩを含ませて送信することができる。以後、残り登録過程を実行する(段階１１６５)。

【0146】

図１２は、実施形態によるまた他の信号送受信過程を示した図面である。

【0147】

図１２を参照すれば、端末１２０１がＲＡＮ１２０２を通じてＭＭＥ／ＳＧＳＮ１２０３、１２０４と信号を送受信できる。またＭＭＥ／ＳＧＳＮ１２０３、１２０４の混雑によって既存に接続しているＯｌｄ ＭＭＥ／ＳＧＳＮ１２０３と新たに接続するＮｅｗ ＭＭＥ／ＳＧＳＮ１２０４に区別されることができる。しかし、実施形態でＭＭＥ／ＳＧＳＮが変更されることは混雑の原因ではない場合にも適用されることができることを明らかにする。

【0148】

前記図９乃至図１１に記述された実施形態はユーザ端末１２０１がコアネットワークノードに明示的にＮＡＳリクエストを送信した場合に対するが、図１２に記述される実施形態はユーザ端末１２０１が明示上にＮＡＳリクエストを送信しない場合にも適用されることができる。即ち、例えばコアネットワークノードが混雑すると判断すると、基地局１２０２を通じてコアネットワークノード再設定が必要さをユーザ端末１２０１に通知し、以後図９乃至図１１の作動と類似の過程を通じて新しいコアネットワークノードを通じて登録されるようにすることである。段階１２１０で端末１２０１、基地局１２０２及びＯｌｄ ＭＭＥ／ＳＧＳＮ１２０３が接続モード(ｃｏｎｎｅｃｔｅｄ ｍｏｄｅ)で作動している。

【0149】

段階１２１５で、Ｏｌｄ ＭＭＥ／ＳＧＳＮ１２０３がコアネットワークノードが混雑すると判断すると、段階１１２０でコアネトオクノードは基地局１２０２にユーザ端末１２０１に対してｌｏａｄ ｂａｌａｎｃｉｎｇのために接続の解除が必要さを通知する情報を含むコマンドメッセージを伝達する。

【0150】

段階１２２５で、これを受信した基地局１２０２はユーザ端末１２０２のＲＲＣ接続を解除するコマンドを伝達しながら、ｌｏａｄ ｂａｌａｎｃｉｎｇのためにコアネットワーク変更が必要であることを通知する。このようにＲＲＣ接続が解除された以後の作動は図９乃至１１でＲＲＣ接続解除以後のことがそのまま適用されることができるので詳細な説明は省略する。

【0151】

本発明が属する技術分野の通常の知識を有する者は、本発明がその技術的思想や必須な特徴を変更せず他の具体的な形態で実施されることができるということを理解することができるであろう。よって、以上で記述した実施形態はあらゆる面で例示的なもので限定的ではないことを理解すべきである。本発明の範囲は前記詳細な説明よりは後述する特許請求の範囲によって表し、特許請求の範囲の意味及び範囲、及びその均等概念から導出される全ての変更又は変形された形態が本発明の範囲に含まれるように解釈されなければならない。

【0152】

一方、本明細書と図面には本発明の好ましい実施形態対して開示した。たとえ特定用語が使用されたが、これは単に本発明の記述内容を容易に説明して発明の理解を助けるための一般的な意味で使用されたものであって、本発明の範囲を限定しようとするものではない。ここに開示された実施形態外にも本発明の技術的思想に基づいて他の変形形態が実施可能であるということは本発明が属する技術分野で通常の知識を有する者に自明なものである。

【符号の説明】

【0153】

２０１ ユーザ端末(ＵＥ１)
２０２ ＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)
２０３ ＭＳＣ
２０４ ＨＬＲ(Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）
２０５ ＧＭＳＣ(Ｇａｔｅｗａｙ Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ)
２０６ 相手のユーザの端末(ＵＥ２)

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】