特表 2022-516369 イベント処理方法、ロケーションアプリケーション機器、ユーザ機器、及びコンピュータプログラム

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-02-25

(54)【発明の名称】イベント処理方法、ロケーションアプリケーション機器、ユーザ機器、及びコンピュータプログラム

(51)【国際特許分類】

   H04W 64/00 20090101AFI20220217BHJP

   H04W 24/10 20090101ALI20220217BHJP

【ＦＩ】

H04W64/00

H04W24/10

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021539552

(86)(22)【出願日】2020-03-13

(85)【翻訳文提出日】2021-07-06

(86)【国際出願番号】 CN2020079148

(87)【国際公開番号】W WO2020199899

(87)【国際公開日】2020-10-08

(31)【優先権主張番号】201910252297.3

(32)【優先日】2019-03-29

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＷＣＤＭＡ

２．ブルートゥース

(71)【出願人】

【識別番号】514187420

【氏名又は名称】テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ワン，タオ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA34

5K067DD11

5K067DD44

5K067EE02

5K067EE10

5K067EE16

5K067FF03

5K067JJ51

(57)【要約】

本願実施例は、アプリケーションが無線信号強度に従ってパラメータ構成ポリシーを調整するニーズを実現するための、イベント処理方法及び機器、並びにシステムを開示する。本願実施例によるイベント処理方法は、ロケーションアプリケーション機器が、ロケーション報告要求を生成するステップであって、ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用される、ステップと、ユーザ機器（ＵＥ）がＵＥの無線信号強度に従って遅延ロケーション報告イベントの発生有無を決定するように、ロケーションアプリケーション機器が、ＵＥにロケーション報告要求を送信するステップと、ロケーションアプリケーション機器が、遅延ロケーション報告イベントの発生に従ってＵＥによって送信されるイベント報告情報を取得するステップと、を含む。
【選択図】図４

【特許請求の範囲】

【請求項1】

ロケーションアプリケーション機器によって実行される、イベント処理方法であって、
前記ロケーションアプリケーション機器が、ロケーション報告要求を生成するステップであって、前記ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用される、ステップと、
ユーザ機器（ＵＥ）が前記ＵＥの無線信号強度に従って前記遅延ロケーション報告イベントの発生有無を決定するように、前記ロケーションアプリケーション機器が、前記ＵＥに前記ロケーション報告要求を送信するステップと、
前記ロケーションアプリケーション機器が、前記遅延ロケーション報告イベントの発生に応答して前記ＵＥによって送信されるイベント報告情報を取得するステップと、
を含むイベント処理方法。

【請求項2】

前記ロケーション報告要求は、要求タイプパラメータ、イベントトリガータイプパラメータ、イベントコンテンツパラメータのうちの少なくとも１つを含み、
前記要求タイプパラメータは、前記ロケーション報告要求の要求タイプが遅延ロケーション報告タイプであることを指示するために使用され、
前記イベントトリガータイプパラメータは、前記遅延ロケーション報告イベントのトリガータイプが、無線信号強度トリガータイプであることを指示するために使用され、
前記イベントコンテンツパラメータは、前記遅延ロケーション報告イベントに対応するコンテンツ情報を指示するために使用される、
請求項１に記載のイベント処理方法。

【請求項3】

前記イベントコンテンツパラメータは、無線信号強度条件、ロケーション報告の最大時間間隔、ロケーション報告の最小時間間隔、ロケーション報告頻度パラメータ、ロケーション報告のサービス品質（ＱｏＳ）要件パラメータ、ＵＥロケーションを報告するか否かを示す指示パラメータのうちの少なくとも１つを含む、
請求項２に記載のイベント処理方法。

【請求項4】

前記イベント報告情報は、前記ＵＥが前記遅延ロケーション報告イベントが発生したことを検出した場合に送信され、又は、
前記イベント報告情報は、前記ＵＥが前記遅延ロケーション報告イベントが発生したことを検出してから一定時間遅延した後に送信され、前記イベント報告情報は、前記ＵＥの無線信号強度が前記無線信号強度条件を満たす実際の発生時間を含む、
請求項３に記載のイベント処理方法。

【請求項5】

前記イベント処理方法は、
前記ロケーションアプリケーション機器が、前記イベント報告情報に従って、前記遅延ロケーション報告イベントが発生したときの前記ＵＥの無線信号強度が前記無線信号強度条件を満たすと決定するステップ
を更に含む、請求項３又は４に記載のイベント処理方法。

【請求項6】

前記ロケーションアプリケーション機器が、前記ＵＥに前記ロケーション報告要求を送信する前記ステップの後、前記イベント処理方法は、
前記ロケーションアプリケーション機器が、前記ＵＥによって送信されるタイムアウト指示情報を取得するステップであって、前記タイムアウト指示情報は、前記ＵＥが、前回のイベント報告以降に、前記遅延ロケーション報告イベントを検出しておらず、且つ、前回のイベント報告から現時点までの時間間隔が、前記最大時間間隔に達したことを指示するために使用される、ステップと、
前記ロケーションアプリケーション機器が、前記タイムアウト指示情報に従って、前記ＵＥが前記遅延ロケーション報告イベントの検出をサポートすることを決定するステップと、
を更に含む、請求項３ないし５のいずれか一項に記載のイベント処理方法。

【請求項7】

前記ロケーションアプリケーション機器が、ＵＥに前記ロケーション報告要求を送信する前記ステップは、
前記ロケーションアプリケーション機器が、アプリケーション機能（ＡＦ）エンティティであり、前記ＡＦエンティティが、前記ロケーション報告要求をネットワーク露出機能（ＮＥＦ）エンティティに送信し、前記ＮＥＦエンティティによって前記ロケーション報告要求をゲートウェイ移動位置センタ（ＧＭＬＣ）に送信し、前記ＧＭＬＣによって前記ロケーション報告要求をアクセスおよびモビリティ管理機能（ＡＭＦ）エンティティに送信し、前記ＡＭＦエンティティによって無線アクセスネットワーク（ＲＡＮ）を介して前記ロケーション報告要求を前記ＵＥに送信するステップ、又は、
前記ロケーションアプリケーション機器が、ロケーションサービス（ＬＣＳ）クライアントであり、前記ＬＣＳクライアントが、前記ロケーション報告要求をＧＭＬＣに送信し、前記ＧＭＬＣによって前記ロケーション報告要求をＡＭＦエンティティに送信し、前記ＡＭＦエンティティによってＲＡＮを介して前記ロケーション報告要求を前記ＵＥに送信するステップ
を含む、請求項１ないし６のいずれか一項に記載のイベント処理方法。

【請求項8】

ユーザ機器（ＵＥ）によって実行されるイベント処理方法であって、
前記ユーザ機器（ＵＥ）が、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得するステップであって、前記ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用される、ステップと、
前記ＵＥが、前記ロケーション報告要求に従って、前記ＵＥの無線信号強度を取得するステップと、
前記ＵＥが、前記ＵＥの無線信号強度に従って、前記遅延ロケーション報告イベントが発生したか否かを決定するステップと、
前記遅延ロケーション報告イベントの発生に応答して、前記ＵＥが、前記ロケーションアプリケーション機器にイベント報告情報を送信するステップと、
を含むイベント処理方法。

【請求項9】

前記ユーザ機器（ＵＥ）が、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得する前記ステップの後、前記イベント処理方法は、
前記ＵＥが、前記ロケーション報告要求から要求タイプパラメータ、イベントトリガータイプパラメータ、イベントコンテンツパラメータのうちの少なくとも１つを取得するステップと、
前記ＵＥが、前記要求タイプパラメータに従って、前記ロケーション報告要求の要求タイプが遅延ロケーション報告タイプであると決定するステップ、及び／又は、
前記ＵＥが、前記イベントトリガータイプパラメータに従って、前記遅延ロケーション報告イベントのトリガータイプが無線信号強度トリガータイプであると決定するステップ、及び／又は、
前記ＵＥが、前記イベントコンテンツパラメータに従って、前記遅延ロケーション報告イベントに対応するコンテンツ情報を決定するステップと、
を更に含む、請求項８に記載のイベント処理方法。

【請求項10】

前記イベントコンテンツパラメータは、無線信号強度条件、ロケーション報告の最大時間間隔、ロケーション報告の最小時間間隔、ロケーション報告頻度パラメータ、ロケーション報告のサービス品質（ＱｏＳ）要件パラメータ、ＵＥロケーションを報告するか否かを示す指示パラメータのうちの少なくとも１つを含む、
請求項９に記載のイベント処理方法。

【請求項11】

前記ＵＥが、前記ＵＥの無線信号強度に従って、前記遅延ロケーション報告イベントが発生したか否かを決定する前記ステップは、
前記ＵＥが、前記ＵＥの無線信号強度が前記無線信号強度条件を満たすか否かを検出し、前記ＵＥの無線信号強度が前記無線信号強度条件を満たすことに応答して、前記ＵＥが、前記遅延ロケーション報告イベントが発生したと決定し、前記ＵＥの無線信号強度が前記無線信号強度条件を満たさないことに応答して、前記ＵＥが、前記遅延ロケーション報告イベントが発生していないと決定するステップ
を含む、請求項１０に記載のイベント処理方法。

【請求項12】

前記遅延ロケーション報告イベントの発生に応答して、前記ＵＥが、前記ロケーションアプリケーション機器にイベント報告情報を送信する前記ステップは、
前記遅延ロケーション報告イベントの発生、及び前回のイベント報告から現時点までの時間間隔が、前記最小時間間隔に達したことに応答して、前記ＵＥが、前記ロケーションアプリケーション機器にイベント報告情報を送信するステップ、又は、
前記遅延ロケーション報告イベントの発生、及び前回のイベント報告から現時点までの時間間隔が、前記最小時間間隔に達していないことに応答して、前記ＵＥが、前記遅延ロケーション報告イベントが発生したことを検出してから一定時間遅延した後に前記ロケーションアプリケーション機器にイベント報告情報を送信するステップであって、前記イベント報告情報は、前記ＵＥの無線信号強度が前記無線信号強度条件を満たす実際の発生時間を含む、ステップ、又は、
前記遅延ロケーション報告イベントの発生、及び前記ＵＥが、現在ネットワークにアクセスできないことに応答して、前記ＵＥが、前記遅延ロケーション報告イベントが発生したことを検出してから一定時間遅延した後に前記ロケーションアプリケーション機器に前記イベント報告情報を送信するステップ
を含む、請求項１０又は１１に記載のイベント処理方法。

【請求項13】

前記ＵＥが、前記ＵＥの無線信号強度に従って、前記遅延ロケーション報告イベントが発生したか否かを決定する前記ステップの後、前記イベント処理方法は、
前記ＵＥが、前回のイベント報告以降に、前記遅延ロケーション報告イベントを検出しておらず、且つ、前回のイベント報告から現時点までの時間間隔が、前記最大時間間隔に達したことに応答して、前記ＵＥが、前記ロケーションアプリケーション機器にタイムアウト指示情報を送信するステップ
を更に含む、請求項１０乃至１２のいずれか一項に記載のイベント処理方法。

【請求項14】

ロケーションアプリケーション機器であって、
プロセッサと、メモリと、を備え、
前記メモリは、命令を記憶するように構成され、
前記プロセッサは、前記メモリ内の前記命令を実行することにより、請求項１ないし７のいずれか一項に記載のイベント処理方法を実現するように構成される、
ロケーションアプリケーション機器。

【請求項15】

ユーザ機器（ＵＥ）であって、
プロセッサと、メモリと、を備え、
前記メモリは、命令を記憶するように構成され、
前記プロセッサは、前記メモリ内の前記命令を実行することにより、請求項８ないし１３のいずれか一項に記載のイベント処理方法を実現するように構成される、
ユーザ機器（ＵＥ）。

【請求項16】

コンピュータプログラムであって、
コンピュータによって実行される場合に、前記コンピュータに、請求項１ないし７のいずれか一項に記載のイベント処理方法を実行させる、コンピュータプログラム。

【請求項17】

コンピュータプログラムであって、
コンピュータによって実行される場合に、前記コンピュータに、請求項８ないし１３のいずれか一項に記載のイベント処理方法を実行させる、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願への相互参照］
本願は、２０１９年０３月２９日に提出された、発明の名称が「イベント処理方法及び機器、並びにシステム」である中国特許出願第２０１９１０２５２２９７．３号の優先権を主張し、当該中国特許出願の全ての内容が参照により本願に援用される。

【0002】

［技術分野］
本願は、コンピュータ技術分野に関し、特に、イベント処理方法及び機器、並びにシステムに関する。

【背景技術】

【0003】

現在の無線通信システムでは、以下の５つのロケーション要求タイプがある。

【0004】

第１のロケーション要求タイプは、ＮＩ－ＬＲ（Ｎｅｔｗｏｒｋ Ｉｎｄｕｃｅｄ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）であり得、ＮＩ－ＬＲでは、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）の緊急通話などの特定の特別な監視サービスについて、ＵＥにサービスを提供するアクセスおよびモビリティ管理機能エンティティ（ＡＭＦ：Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）によってロケーション報告要求をトリガーする。

【0005】

第２のロケーション要求タイプは、ＭＴ－ＬＲ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｅｄ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）であり得、ＭＴ－ＬＲでは、外部アプリケーション機能（ＡＦ：Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）エンティティ又は公衆陸上移動通信網（ＰＬＭＮ：Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）内部の位置決めサービス（ＬＣＳ：Ｌｏｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ）クライアント（ｃｌｉｅｎｔ）がロケーション要求をＰＬＭＮに送信して、ターゲットＵＥのロケーション情報を要求する。

【0006】

第３のロケーション要求タイプは、ＭＯ－ＬＲ（Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）であり得、ＭＯ－ＬＲでは、ＵＥが、サービスするＰＬＭＮにロケーション要求を送信して、当該ＵＥに関するロケーション情報を取得する。

【0007】

第４のロケーション要求タイプは、即時ロケーション要求（Ｉｍｍｅｄｉａｔｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）であり得、即時ロケーション要求では、ＬＣＳクライアントがターゲットＵＥ（又は一グループのターゲットＵＥ）にロケーション要求を送信し、短時間でターゲットＵＥ（又は一グループのターゲットＵＥ）ロケーション情報を含む応答を受信することが望まれ、この期間では特別なサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）の要件がある可能性がある。

【0008】

第５のロケーション要求タイプは、遅延ロケーション要求（Ｄｅｆｅｒｒｅｄ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）であり得、遅延ロケーション要求では、ＬＣＳクライアントがターゲットＵＥ（又は一グループのターゲットＵＥ）のロケーション要求をＰＬＭＮに送信し、将来のある時点で、又は特定のイベントが発生したときに、ターゲットＵＥ（又は一グループのターゲットＵＥ）のロケーション情報を受信することが期待される。

【0009】

ロケーションサービスタイプが遅延ロケーション要求であるシナリオでは、遅延ロケーション要求をトリガーするトリガーイベントを定義する必要があるが、現在定義されたトリガーイベントは、アプリケーションがパラメータ構成ポリシーを調整するニーズを実現できない。

【発明の概要】

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

【0010】

本願実施例は、アプリケーションが無線信号強度に従ってパラメータ構成ポリシーを調整するニーズを実現することにより、パラメータ構成ポリシーの調整の柔軟性を向上させることができる、イベント処理方法及び機器並びにシステムを提供する。

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

【0011】

一態様において、本願実施例は、ロケーションアプリケーション機器によって実行される、イベント処理方法を提供し、前記方法は、
ロケーションアプリケーション機器が、ロケーション報告要求を生成するステップであって、前記ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用される、ステップと、
ユーザ機器（ＵＥ）が前記ＵＥの無線信号強度に従って前記遅延ロケーション報告イベントの発生有無を決定するように、前記ロケーションアプリケーション機器が、前記ＵＥに前記ロケーション報告要求を送信するステップと、
前記ロケーションアプリケーション機器が、前記遅延ロケーション報告イベントの発生に従って前記ＵＥによって送信されるイベント報告情報を取得するステップと、を含む。

【0012】

一方、本願実施例は、更に、ユーザ機器（ＵＥ）によって実行される、イベント処理方法を提供し、前記方法は、
ユーザ機器（ＵＥ）が、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得するステップであって、前記ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用される、ステップと、
前記ＵＥが、前記ロケーション報告要求に従って、前記ＵＥの無線信号強度を取得するステップと、
前記ＵＥが、前記ＵＥの無線信号強度に従って、前記遅延ロケーション報告イベントが発生したか否かを決定するステップと、
前記遅延ロケーション報告イベントが発生した場合、前記ＵＥが、前記ロケーションアプリケーション機器にイベントの発生の確認情報を送信するステップと、を含む。

【0013】

本願のいくつかの実施例において、前記ユーザ機器（ＵＥ）が、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得する前記ステップは、
前記ロケーションアプリケーション機器が、具体的にはアプリケーション機能（ＡＦ）エンティティであり、前記ＡＦエンティティが、前記ロケーション報告要求をゲートウェイ移動位置センタ（ＧＭＬＣ）に送信し、前記ＧＭＬＣによって前記ロケーション報告要求をアクセスおよびモビリティ管理機能（ＡＭＦ）エンティティに送信し、前記ＡＭＦエンティティによって前記ロケーション報告要求を前記ＵＥに送信するステップ、又は、
前記ロケーションアプリケーション機器が、具体的にはロケーションサービス（ＬＣＳ）クライアントであり、前記ＬＣＳクライアントが、前記ロケーション報告要求をＧＭＬＣに送信し、前記ＧＭＬＣによって前記ロケーション報告要求をＡＭＦエンティティに送信し、前記ＡＭＦエンティティによって前記ロケーション報告要求を前記ＵＥに送信するステップを含む。

【0014】

一方、本願実施例は、更に、処理モジュールと、送受信モジュールとを備えるロケーションアプリケーション機器を提供し、ここで、
前記処理モジュールは、ロケーション報告要求を生成するように構成され、前記ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用され、
前記処理モジュールは、更に、ユーザ機器（ＵＥ）が前記ＵＥの無線信号強度に従って前記遅延ロケーション報告イベントの発生有無決定するように、送受信モジュールを介して、前記ＵＥに前記ロケーション報告要求を送信するように構成され、
前記処理モジュールは、更に、前記遅延ロケーション報告イベントの発生に従って前記ＵＥによって送信されるイベント報告情報を取得するように構成される。

【0015】

上記の態様において、ロケーションアプリケーション機器の構成モジュールは、更に、上述した別の態様及び様々な可能な実施形態で説明されたステップを実行することもでき、上述した別の態様及び様々な可能な実施形態の説明を参照されたい。

【0016】

本願のいくつかの実施例において、ロケーションアプリケーション機器は、具体的には、アプリケーション機能（ＡＦ）エンティティ、又はロケーションサービスクライアント（ＬＣＳ ｃｌｉｅｎｔ）であり得る。

【0017】

一方、本願実施例は、更に、処理モジュールと、送受信モジュールとを備えるＵＥを提供し、ここで、
前記処理モジュールは、前記送受信モジュールを介して、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得するように構成され、前記ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用され、
前記処理モジュールは、更に、前記ロケーション報告要求に従って、前記ＵＥの無線信号強度を取得するように構成され、
前記処理モジュールは、更に、前記ＵＥの無線信号強度に従って、前記遅延ロケーション報告イベントが発生したか否かを決定するように構成され、
前記処理モジュールは、更に、前記遅延ロケーション報告イベントが発生した場合、前記送受信モジュールを介して、前記ロケーションアプリケーション機器にイベント報告情報を送信するように構成される。

【0018】

上記の態様において、ＵＥの構成モジュールは、更に、上述した別の態様及び様々な可能な実施形態で説明されたステップを実行することもでき、上述した別の態様及び様々な可能な実施形態の説明を参照されたい。

【0019】

一方、本願実施例は、プロセッサと、メモリとを備えるロケーションアプリケーション機器を提供する。前記メモリは、命令を記憶するように構成され、前記プロセッサは、前記メモリ内の命令を実行することにより、ロケーションアプリケーション機器に、上記の態様のいずれかに記載の方法を実行させるように構成される。

【0020】

一方、本願実施例は、プロセッサと、メモリとを備えるＵＥを提供し、前記メモリは、命令を記憶するように構成され、前記プロセッサは、前記メモリ内の命令を実行することにより、ＵＥに、上記の態様のいずれかに記載の方法を実行させるように構成される。

【0021】

一方、本願実施例は、ロケーションアプリケーション機器と、ユーザ機器（ＵＥ）とを備える、イベント処理システムを提供し、ここで、
前記ロケーションアプリケーション機器は、前述した、ロケーションアプリケーション機器によって実行されるイベント処理方法を実行するように構成され、
前記ＵＥは、前述した、ＵＥによって実行されるイベント処理方法を実行するように構成される。

【0022】

一方、本願実施例は、命令が記憶されたコンピュータ可読記憶媒体を提供し、前記命令がコンピュータで実行されるときに、前記コンピュータに、上記の各態様に記載の方法を実行させる。

【発明の効果】

【0023】

本願実施例において、ロケーションアプリケーション機器は、まず、ロケーション報告要求を生成し、その後、ロケーションアプリケーション機器は、ＵＥにロケーション報告要求を送信し、ＵＥは、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得でき、ＵＥは、ロケーション報告要求に従ってＵＥの無線信号強度を取得する。その後、ＵＥは、ＵＥの無線信号強度に従って、遅延ロケーション報告イベントが発生したか否かを決定し、遅延ロケーション報告イベントの発生に応答して、ロケーションアプリケーション機器にイベント報告情報を送信し、ロケーションアプリケーション機器は、遅延ロケーション報告イベントの発生に従ってＵＥによって送信されたイベント報告情報を取得する。本願実施例におけるロケーションアプリケーション機器は、ＵＥに無線信号強度に基づく遅延ロケーション報告イベントを指示できるため、ＵＥは、それ自体の無線信号強度に従って、遅延ロケーション報告イベントが発生したか否かを決定でき、ロケーションアプリケーション機器は、ＵＥによって送信されたイベント報告情報に従ってＵＥの無線信号強度を決定でき、これにより、アプリケーションが無線信号強度に従ってパラメータ構成ポリシーを調整するニーズを実現することができる。

【図面の簡単な説明】

【0024】

本願実施例の技術的解決策をより明確に説明するために、以下は、実施例の説明で使用される図面について簡単に紹介する。以下に説明される図面は、本願のいくつかの実施例に過ぎず、当業者にとっては、これらの図面に従って他の図面を得ることもできることは自明である。

【図1】本願実施例によるイベント処理システムの構成の例示的な構造図である。

【図2】本願実施例によるイベント処理システムの構成の別の例示的な構造図である。

【図3】本願実施例によるイベント処理システムの構成の別の例示的な構造図である。

【図4】本願実施例によるロケーションアプリケーション機器とＵＥとのインタラクションの例示的なフローチャートである。

【図5】本願実施例によるロケーション報告要求の構成の概略図である。

【図6】本願実施例によるイベントコンテンツパラメータの構成の概略図である。

【図7】本願実施例による、ロケーションアプリケーション機器によって実行されるイベント処理方法のフローチャートである。

【図8】本願実施例による、ロケーションアプリケーション機器によって実行される別のイベント処理方法のフローチャートである。

【図9】本願実施例による、ＵＥによって実行されるイベント処理方法のフローチャートである。

【図10】本願実施例による、ＵＥによって実行される別のイベント処理方法のフローチャートである。

【図11】本願実施例によるロケーションサービスに基づくネットワークアーキテクチャの概略図である。

【図12】本願実施例における遅延ロケーション報告イベントの要求及びトリガーの例示的なフローチャートである。

【図13】本願実施例における別の遅延ロケーション報告イベントの要求及びトリガーの例示的なフローチャートである。

【図14】本願実施例によるロケーションアプリケーション機器の構成の例示的な構造図である。

【図15】本願実施例によるＵＥの構成の例示的な構造図である。

【図16】本願実施例による、イベント処理方法が適用されるサーバの構成の例示的な構造図である。

【図17】本願実施例によるイベント処理方法が適用される端末の構成の例示的な構造図である。

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

【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】

ステップＳ０１ａにおいて、ＬＣＳクライアントが、ＧＭＬＣにＬＣＳロケーション報告要求を送信する。

【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】

一つの可能な実施形態において、ＵＥは、それ自体の無線信号強度に従って、無線信号強度に基づく遅延ロケーション報告イベントの発生を判断する。

【0154】

ステップＳ１０において、ＵＥが、ＡＭＦ及びＬＭＦにイベント報告情報を送信する。

【0155】

ステップＳ１１において、ＵＥはＬＭＦとインタラクションして、ＵＥ位置決めプロセスを実行する。

【0156】

ステップＳ１２において、ＬＭＦが、イベント通知メッセージをＧＭＬＣに送信する。

【0157】

一つの可能な実施形態において、イベント通知メッセージは、当該遅延報告イベントの発生の指示情報を搬送する。報告要求メッセージでＵＥのロケーション情報を報告することが必要とされる場合、当該イベント通知メッセージでＵＥのロケーション情報を搬送する。

【0158】

ステップＳ１３ａにおいて、ＧＭＬＣが、ロケーション報告イベントの発生の応答メッセージをＬＣＳクライアントに送信する。

【0159】

ＬＣＳクライアントは、受信されたロケーション報告イベントの発生の応答メッセージに従って、ＵＥのイベント報告情報を取得する。

【0160】

ステップＳ１３ｂ－１において、ＧＭＬＣが、ロケーション報告イベントの発生の応答メッセージをＮＥＦに送信する。

【0161】

ステップＳ１３ｂ－２において、ＮＥＦが、ロケーション報告イベントの発生の応答メッセージをＡＦに送信する。

【0162】

ＡＦは、受信されたロケーション報告イベントの発生の応答メッセージに従って、ＵＥのイベント報告情報を取得する。

【0163】

図１３を参照すると、本願実施例における別の遅延ロケーション報告イベントの要求及びトリガーの例示的なフローチャートを示す。図１３は、ＵＥがローミング状態にあるシナリオを示し、ＬＣＳクライアントは、ロケーション報告要求をＨＧＭＬＣに送信するか、又はＡＦは、ＬＣＳロケーション報告要求をＮＥＦに送信し、ＮＥＦは、当該要求をＨＧＭＬＣに送信する。当該ロケーション報告要求には、ＵＥ（又はＵＥグループ）の識別子、遅延ロケーション報告要求、及び関連するパラメータが含まれる。本願実施例において、遅延ロケーション報告要求のイベントタイプ及び関連するパラメータを搬送する必要がある。当該イベントタイプは、無線信号強度である。主に、当該プロセスは以下のステップを含む。

【0164】

ステップＰ０１ａにおいて、ＬＣＳクライアントが、ＨＧＭＬＣにＬＣＳロケーション報告要求を送信する。

【0165】

例えば、ＬＣＳクライアントは、ＬＣＳロケーション報告要求をＨＧＭＬＣに送信する。当該要求は、当該ロケーション報告要求のタイプがＬＤＲであること、トリガーイベントタイプ及び関連するパラメータを含む。ここで、ＬＤＲは、遅延ロケーション報告タイプを指す。トリガーイベントは、無線信号強度を指す。

【0166】

ステップＰ０１ｂ－１において、ＡＦが、ＮＥＦにＬＣＳロケーション報告要求を送信する。

【0167】

当該要求は、当該ロケーション報告要求のタイプがＬＤＲであること、トリガーイベントタイプ及び関連するパラメータを含む。ここで、ＬＤＲは、遅延ロケーション報告タイプを指す。トリガーイベントは、無線信号強度を指す。

【0168】

ステップＰ０１ｂ－２において、ＮＥＦが、ＨＧＭＬＣにＬＣＳロケーション報告要求を送信する。

【0169】

ここで、ＡＦは、ＬＣＳロケーション報告要求をＮＥＦに送信し、ＮＥＦは、当該要求をＨＧＭＬＣに送信する。ＮＥＦとＨＧＭＬＣとの間では、Ｎｇｍｌｃサービスを使用してＬＣＳロケーション報告要求を伝送することができる。

【0170】

ステップＰ０１ａは、ロケーションアプリケーション機器がＬＣＳクライアントである場合に対応し、ステップＰ０１ｂ－１及びステップＰ０１ｂ－２は、ロケーションアプリケーション機器がＡＦである場合に対応することに留意されたい。

【0171】

ここで、ＡＦは、ＬＣＳロケーション報告要求をＮＥＦに送信し、ＮＥＦは、当該要求をＨＧＭＬＣに送信する。ＨＧＭＬＣは、公衆陸上移動通信網（ＨＰＬＭＮ：Ｈｏｍｅ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）に帰属するＧＭＬＣである。

【0172】

ステップＰ０２において、ＨＧＭＬＣはＵＤＭとインタラクションし、ユーザデータ管理（ＳＤＭ：Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）サービスを呼び出す。

【0173】

ここで、ＵＤＭは、保存されているＵＥのプライバシコンテキスト情報を検証して、当該ロケーション報告要求をサポートできるか否かを判断する。当該ロケーション報告要求をサポートする場合、後続のステップＰ０３を実行する。当該ロケーション報告要求をサポートしない場合、ステップＰ０８ａを実行し、当該ロケーション報告要求の拒絶メッセージをＬＣＳクライアントに送信するか、又は、当該ロケーション報告要求をサポートしない場合、ステップＰ０８ｂ－１及びＰ０８ｂ－２を実行する。

【0174】

ステップＰ０３ａにおいて、ＨＧＭＬＣはＵＤＭとインタラクションし、ユーザコンテキスト管理（ＵＥＣＭ：ＵＥ Ｃｏｎｔｅｘｔ Ｍａｎａｇｅｍｅｎｔ）サービスを呼び出す。

【0175】

ここで、ＨＧＭＬＣは、ＶＧＭＬＣのアドレス及びＡＭＦのアドレスをＵＤＭに要求する。

【0176】

ステップＰ０３ｂにおいて、ＨＧＭＬＣが、当該ロケーション報告要求をＶＧＭＬＣに送信する。

【0177】

ここで、ＶＧＭＬＣは、公衆陸上移動通信網（ＶＰＬＭＮ：Ｖｉｓｉｔｅｄ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）を訪問するＧＭＬＣである。

【0178】

ステップＰ０４において、ＶＧＭＬＣが、ＡＭＦにロケーション報告要求メッセージを送信する。

【0179】

例えば、ＶＧＭＬＣは、ＡＭＦのサービス（例えば、Ｎａｍｆ＿Ｌｏｃａｔｉｏｎ＿ＰｒｏｖｉｄｅＰｏｓｉｔｉｏｎｉｎｇＩｎｆｏサービスなど）を呼び出して、当該ロケーション報告要求メッセージをＡＭＦに送信し、当該メッセージは、ＵＥ（又はＵＥグループ）の識別子、ＨＧＭＬＣのアドレス及びロケーション遅延報告（ＬＤＲ：Ｌｏｃａｔｉｏｎ Ｄｅｆｅｒｒｅｄ Ｒｅｐｏｒｔ）の参照番号（ｒｅｆｅｒｅｎｃｅ ｎｕｍｂｅｒ）、及びトリガーイベントのタイプ及びパラメータを含む。ＡＭＦが、遅延ロケーション報告要求をサポートしない場合、ステップＰ０５及びステップＰ０６をスキップして、ステップＰ０７を直接実行する。ＡＭＦが、当該遅延ロケーション報告要求をサポートする場合、ステップＰ０５を実行する。

【0180】

ステップＰ０５において、ＡＭＦが、ＵＥにロケーション報告要求の通知メッセージを送信する。

【0181】

ＵＥが到達不能状態にある場合、ＡＭＦはＵＥの状態が到達可能になるまで待機する。ＵＥがアイドル状態にある場合、ＡＭＦは、ネットワークよってトリガーされるサービス要求プロセスを開始して、ＵＥとのシグナリング接続を確立し、ＵＥのモビリティ管理状態が接続状態になる。ＵＥが接続状態になることに応答して、ＡＭＦは、ＮＡＳメッセージを介して当該要求をＵＥに送信し、当該要求には、当該ロケーション報告要求のタイプがＬＤＲであること、トリガーイベントタイプ及び関連するパラメータが含まれる。ここで、ＬＤＲは、遅延ロケーション報告タイプを指す。トリガーイベントは、無線信号強度を指す。

【0182】

ステップＰ０６において、ＵＥが、ＡＭＦにロケーション報告要求の確認結果を送信する。

【0183】

ＵＥが当該イベントタイプをサポートし、且つ、当該トリガーイベントに同意する場合、ロケーション報告要求の受信確認メッセージを含むＮＡＳメッセージをＡＭＦに送信する。ＵＥが当該トリガーイベントを同意しない場合、ロケーション報告要求の拒絶メッセージを含むＮＡＳメッセージをＡＭＦに送信する。

【0184】

ステップＰ０７ａにおいて、ＡＭＦが、ＶＧＭＬＣにロケーション報告要求の応答メッセージを送信する。

【0185】

ＡＭＦは、ロケーション報告要求の応答メッセージをＶＧＭＬＣに送信し、当該メッセージは、ロケーション報告要求が受け入れられるか拒否されるかを指示する。

【0186】

ステップＰ０７ｂにおいて、ＵＥが当該ロケーション報告要求を受け入れる場合、ＡＭＦは、ＬＭＦにロケーション報告要求メッセージを送信し、当該メッセージは、ＵＥ（又はＵＥグループ）の識別子、当該ロケーション報告要求のタイプがＬＤＲであること、トリガーイベントタイプ及び関連するパラメータ、並びにＬＤＲ ｒｅｆｅｒｅｎｃｅ ｎｕｍｂｅｒを含む。

【0187】

ステップＰ０７ａ及びステップＰ０７ｂの実行順序を限定しないことを理解されたい。

【0188】

ステップＰ０８ａにおいて、ＶＧＭＬＣが、ＬＣＳクライアントにロケーション報告要求の応答メッセージを送信する。

【0189】

ＶＧＭＬＣは、ロケーション報告要求の応答メッセージをＨＧＭＬＣに転送し、ＨＧＭＬＣは、当該応答メッセージをＬＣＳクライアントに転送する。当該メッセージは、ロケーション報告要求が受け入れられるか拒否されるかを指示する。

【0190】

ステップＰ０８ｂ－１において、ＶＧＭＬＣが、ＮＥＦにロケーション報告要求の応答メッセージを送信する。

【0191】

ＶＧＭＬＣは、ロケーション報告要求の応答メッセージをＨＧＭＬＣに転送し、ＨＧＭＬＣは、当該応答メッセージをＮＥＦに転送する。当該メッセージは、当該ロケーション報告要求が受け入れられるか拒否されるかを指示する。

【0192】

ステップＰ０８ｂ２において、ＮＥＦが、ＡＦにロケーション報告要求の応答メッセージを送信する。

【0193】

ＮＥＦは、ロケーション報告要求の応答メッセージをＡＦに転送する。当該メッセージは、ロケーション報告要求が受け入れられるか拒否されるかを指示する。

【0194】

ステップＰ０９において、ＵＥが、イベントの発生を検出する。

【0195】

一つの可能な実施形態において、ＵＥは、それ自体の無線信号強度に従って、無線信号強度に基づく遅延ロケーション報告イベントの発生を判断する。

【0196】

ステップＰ１０において、ＵＥが、ＡＭＦ及びＬＭＦにイベント報告情報を送信する。

【0197】

ステップＰ１１において、ＵＥはＬＭＦとインタラクションして、ＵＥ位置決めプロセスを実行する。

【0198】

ステップＰ１２ａにおいて、ＬＭＦが、イベント通知メッセージをＶＧＭＬＣに送信する。

【0199】

一つの可能な実施形態において、イベント通知メッセージは、当該遅延報告イベントの発生の指示情報を搬送する。ロケーション報告要求メッセージでＵＥのロケーション情報を報告するように要求することが必要とされる場合、当該イベント通知メッセージでＵＥのロケーション情報を搬送する。

【0200】

ステップＰ１２ｂにおいて、ＶＧＭＬＣが、イベント通知メッセージをＨＧＭＬＣに送信する。

【0201】

ステップＰ１３ａにおいて、ＨＧＭＬＣが、ロケーション報告イベントの発生の応答メッセージをＬＣＳクライアントに送信する。

【0202】

ＬＣＳクライアントは、受信されたロケーション報告イベントの発生の応答メッセージに従って、ＵＥのイベント報告情報を取得する。

【0203】

ステップＰ１３ｂ－１において、ＨＧＭＬＣが、ロケーション報告イベントの発生の応答メッセージをＮＥＦに送信する。

【0204】

ステップＰ１３ｂ－２において、ＮＥＦが、ロケーション報告イベントの発生の応答メッセージをＡＦに送信する。

【0205】

ＡＦは、受信されたロケーション報告イベントの発生の応答メッセージに従って、ＵＥのイベント報告情報を取得する。

【0206】

上記の例から分かるように、本願実施例では、アプリケーションは、無線信号品質が悪い領域のＵＥ識別子情報及びロケーション情報を取得することが可能であり、これは、アプリケーションレイヤが、ネットワーク品質の状況に従ってアプリケーションレイヤのパラメータ構成ポリシーを調整するのに役立つ。

【0207】

上述した各方法の実施例について、説明を簡単にするために、それらを全て一連の動作の組み合わせとして表したが、本願によると、一部のステップを他の順番で、又は同時に実行できるため、当業者は、本出願が、本明細書に記載の動作の順番に限定されないことを知るべきであることに留意されたい。更に、当業者はまた、本明細書に記載の実施例がすべて好ましい実施例であり、関連する動作及びモジュールが本願によって必ずしも必要とされないことも知るべきである。

【0208】

本願実施例の上記の技術的解決策をより良く実施するために、以下は更に、上記の技術的解決案を実施するための関連する装置を提供する。

【0209】

図１４は、本願実施例によるロケーションアプリケーション機器１０００を示し、ロケーションアプリケーション機器１０００は、処理モジュール１００１と送受信モジュール１００２とを備え、ここで、
処理モジュール１００１は、ロケーション報告要求を生成するように構成され、ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用される。

【0210】

処理モジュール１００１は、更に、送受信モジュール１００２を介してユーザ機器（ＵＥ）にロケーション報告要求を送信することにより、ＵＥがＵＥの無線信号強度に従って、遅延ロケーション報告イベントが発生したか否かを決定するようにする、ように構成され、
処理モジュール１００１は、更に、ＵＥが、遅延ロケーション報告イベントの発生に応答して、ロケーションアプリケーション機器１０００に送信したイベント報告情報を取得するように構成される。

【0211】

本願のいくつかの実施例において、ロケーション報告要求は、要求タイプパラメータ、イベントトリガータイプパラメータ、イベントコンテンツパラメータのうちの少なくとも１つを含み、ここで、
要求タイプパラメータは、ロケーション報告要求の要求タイプが遅延ロケーション報告タイプであることを指示するために使用され、
イベントトリガータイプパラメータは、遅延ロケーション報告イベントのトリガータイプが、無線信号強度トリガータイプであることを指示するために使用され、
イベントコンテンツパラメータは、遅延ロケーション報告イベントに対応するコンテンツ情報を指示するために使用される。

【0212】

本願のいくつかの実施例において、イベントコンテンツパラメータは、無線信号強度条件、ロケーション報告の最大時間間隔、ロケーション報告の最小時間間隔、ロケーション報告頻度パラメータ、ロケーション報告のサービス品質（ＱｏＳ）要件パラメータ、ＵＥロケーションを報告するか否かを示す指示パラメータのうちの少なくとも１つを含む。

【0213】

本願のいくつかの実施例において、イベント報告情報は、ＵＥが遅延ロケーション報告イベントが発生したことを検出した場合に送信され、又は、
イベント報告情報は、ＵＥが遅延ロケーション報告イベントが発生したことを検出してから一定時間遅延した後に送信され、イベント報告情報は、ＵＥの無線信号強度が無線信号強度条件を満たす実際の発生時間を含む。

【0214】

本願のいくつかの実施例において、処理モジュール１００１は、更に、イベント報告情報に従って、遅延ロケーション報告イベントが発生するときのＵＥの無線信号強度が、無線信号強度条件を満たすことを決定するように構成される。

【0215】

本願のいくつかの実施例において、処理モジュール１００１は、更に、ユーザ機器（ＵＥ）にロケーション報告要求を送信した後、ＵＥによって送信されるタイムアウト指示情報を取得し、タイムアウト指示情報は、ＵＥが、前回のイベント報告以降に、遅延ロケーション報告イベントを検出しておらず、且つ、前回のイベント報告から現時点までの時間間隔が、最大時間間隔に達したことを指示するために使用され、タイムアウト指示情報に従って、ＵＥが遅延ロケーション報告イベントの検出をサポートすることを決定するように構成される。

【0216】

本願のいくつかの実施例において、ロケーションアプリケーション機器１０００が、アプリケーション機能（ＡＦ）エンティティであり、処理モジュール１００１は、ロケーション報告要求をネットワーク露出機能（ＮＥＦ）エンティティに送信し、ＮＥＦエンティティによってロケーション報告要求をゲートウェイ移動位置センタ（ＧＭＬＣ）に送信し、ＧＭＬＣによってロケーション報告要求をアクセスおよびモビリティ管理機能（ＡＭＦ）エンティティに送信し、ＡＭＦエンティティによってＲＡＮを介してロケーション報告要求を前記ＵＥに送信するように構成され、又は、
ロケーションアプリケーション機器１０００が、ロケーションサービス（ＬＣＳ）クライアントであり、処理モジュール１００１は、ロケーション報告要求をＧＭＬＣに送信し、ＧＭＬＣによってロケーション報告要求をＡＭＦエンティティに送信し、ＡＭＦエンティティによってＲＡＮを介してロケーション報告要求をＵＥに送信するように構成される。

【0217】

図１５は、本願実施例によるＵＥ１１００を示し、ＵＥ１１００は、処理モジュール１１０１と、送受信モジュール１１０２とを備え、ここで、
処理モジュール１１０１は、送受信モジュール１１０２を介して、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得するように構成され、ロケーション報告要求は、無線信号強度に基づく遅延ロケーション報告イベントを指示するために使用される。

【0218】

処理モジュール１１０１は、更に、ロケーション報告要求に従って、ＵＥ１１００の無線信号強度を取得するように構成され、
処理モジュール１１０１は、更に、Ｕ１１００Ｅの無線信号強度に従って、遅延ロケーション報告イベントが発生したか否かを決定するように構成され、
処理モジュール１１０１は、更に、遅延ロケーション報告イベントの発生に応答して、ＵＥ１１００が、ロケーションアプリケーション機器にイベント報告情報を送信するように構成される。

【0219】

本願のいくつかの実施例において、処理モジュール１１０１は、更に、ロケーション報告要求から、要求タイプパラメータ、イベントトリガータイプパラメータ、イベントコンテンツパラメータのうちの少なくとも１つを取得し、要求タイプパラメータに従って、ロケーション報告要求の要求タイプが遅延ロケーション報告タイプであることを決定し、及び／又は、イベントトリガータイプパラメータに従って、遅延ロケーション報告イベントのトリガータイプが無線信号強度トリガータイプであることを決定し、及び／又は、イベントコンテンツパラメータに従って、遅延ロケーション報告イベントに対応するコンテンツ情報を決定するように構成される。

【0220】

本願のいくつかの実施例において、イベントコンテンツパラメータは、無線信号強度条件、ロケーション報告の最大時間間隔、ロケーション報告の最小時間間隔、ロケーション報告頻度パラメータ、ロケーション報告のサービス品質（ＱｏＳ）要件パラメータ、ＵＥロケーションを報告するか否かを示す指示パラメータのうちの少なくとも１つを含む。

【0221】

本願のいくつかの実施例において、処理モジュール１１０１は、ＵＥ１１００の無線信号強度が無線信号強度条件を満たすか否かを検出し、ＵＥ１１００の無線信号強度が無線信号強度条件を満たすことに応答して、ＵＥ１１００が、遅延ロケーション報告イベントが発生したと決定し、ＵＥ１１００の無線信号強度が、無線信号強度条件を満たしていないことに応答して、ＵＥ１１００が、遅延ロケーション報告イベントが発生していないと決定するように構成される。

【0222】

本願のいくつかの実施例において、処理モジュール１１０１は、更に、遅延ロケーション報告イベントの発生、及び前回のイベント報告から現時点までの時間間隔が、最小時間間隔に達したことに応答して、ＵＥ１１００が、ロケーションアプリケーション機器にイベント報告情報を送信し、又は、遅延ロケーション報告イベントの発生、及び前回のイベント報告から現時点までの時間間隔が、最小時間間隔に達していないことに応答して、ＵＥ１１００が遅延ロケーション報告イベントが発生したことを検出してから一定時間遅延した後に、ロケーションアプリケーション機器にイベント報告情報を送信し、イベント報告情報は、ＵＥ１１００の無線信号強度が無線信号強度条件を満たす実際の発生時間を含み、又は、遅延ロケーション報告イベントの発生、及びＵＥ１１００が、現在ネットワークにアクセスできないことに応答して、ＵＥ１１００が、遅延ロケーション報告イベントが発生したことを検出してから一定時間遅延した後に、ロケーションアプリケーション機器にイベント報告情報を送信するように構成される。

【0223】

本願のいくつかの実施例において、処理モジュール１１０１は、更に、ＵＥ１１００が、前回のイベント報告以降に、遅延ロケーション報告イベントを検出しておらず、且つ、前回のイベント報告から現時点までの時間間隔が、最大時間間隔に達したことに応答して、ＵＥ１１００が、ロケーションアプリケーション機器にタイムアウト指示情報を送信するように構成される。

【0224】

上記の本願実施例から分かるように、ロケーションアプリケーション機器は、まず、ロケーション報告要求を生成し、その後、ロケーションアプリケーション機器は、ＵＥにロケーション報告要求を送信し、ＵＥは、ロケーションアプリケーション機器によって生成されたロケーション報告要求を取得でき、ＵＥは、ロケーション報告要求に従ってＵＥの無線信号強度を取得する。その後、ＵＥは、ＵＥの無線信号強度に従って、遅延ロケーション報告イベントが発生したか否かを決定し、遅延ロケーション報告イベントが発生した場合、ＵＥは、ロケーションアプリケーション機器にイベント報告情報を送信し、ロケーションアプリケーション機器は、遅延ロケーション報告イベントの発生に従ってＵＥによって送信されたイベント報告情報を取得する。本願実施例におけるロケーションアプリケーション機器が、無線信号強度に基づく遅延ロケーション報告イベントをＵＥに指示できるため、ＵＥは、それ自体の無線信号強度に従って遅延ロケーション報告イベントが発生したか否かを決定でき、ロケーションアプリケーション機器は、ＵＥによって送信されたイベント報告情報に従ってＵＥの無線信号強度を決定し、それにより、ロケーションアプリケーション機器は、アプリケーションが無線信号強度に従ってパラメータ構成ポリシーを調整するニーズを実現することができる。

【0225】

図１６は、本願実施例によるサーバの例示的な構造図であり、当該サーバ１２００は、前述したロケーションアプリケーション機器であり得、異なる構成やパフォーマンスにより、比較的に大きな違いが生じる可能性があり、１つ又は複数の中央処理装置（ＣＰＵ：ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ）１２２２（例えば、１つ又は複数のプロセッサなど）と、メモリ１２３２と、アプリケーション１２４２又はデータ１２４４を記憶するための１つ又は複数の記憶媒体１２３０（例えば、１つ又は複数の大容量記憶機器など）とを備えることができる。ここで、メモリ１２３２及び記憶媒体１２３０は、一時的な記憶媒体又は永続的な記憶装置であり得る。記憶媒体１２３０に記憶されるプログラムは、１つ又は複数のモジュール（図示せず）を備えることができ、各モジュールは、サーバへの一連の命令操作を含み得る。更に、中央処理装置１２２２は、記憶媒体１２３０と通信し、サーバ１２００で記憶媒体１２３０内の一連の命令操作を実行するように構成されることができる。

【0226】

サーバ１２００は、更に、１つ又は複数の電源１２２６と、１つ又は複数の有線又は無線ネットワークインターフェース１２５０と、１つ又は複数の入力出力インターフェース１２５８と、及び／又は、１つ又は複数のオペレーティングシステム１２４１（例えば、Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒ、Ｍａｃ ＯＳ（登録商標） Ｘ、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）、ＦｒｅｅＢＳＤ（登録商標）など）とを備えることができる。

【0227】

上記の実施例において、ロケーションアプリケーション機器によって実行されるイベント処理方法のステップは、図１６に示されるサーバ構造に基づくことができる。

【0228】

本願実施例は、更に、別の端末を提供し、当該端末は、前述したＵＥであり得、図１７に示されたように、説明を容易にするために、本願実施例に関連する部分のみが示されており、開示されていない技術的詳細については、本願の方法の実施例を参照されたい。当該端末は、携帯電話機、タブレット、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、販売端末（ＰＯＳ：Ｐｏｉｎｔ ｏｆ Ｓａｌｅｓ）、車載コンピュータなどの任意の端末機器であり得、端末が携帯電話機であることを例として説明する。

【0229】

図１７は、本願実施例による端末に関連する携帯電話機の構造のブロック図を示す。図１７を参照すると、携帯電話機は、無線周波数（ＲＦ：Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）回路１３１０、メモリ１３２０、入力ユニット１３３０、ディスプレイユニット１３４０、センサ１３５０、オーディオ回路１３６０、ワイヤレスフィデリティ（ＷｉＦｉ：Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）モジュール１３７０、プロセッサ１３８０、及び電源１３９０などのコンポーネントを含む。当業者なら自明であるが、図１７で示された携帯電話機の構造は、携帯電話機への限定を構成するものではなく、図に示されるよりも多い又は少ないコンポーネントを備えるか、又は一部の部品を組み合わせるか、又は異なるコンポーネント配置を有することができる。

【0230】

以下、図１７を参照して、携帯電話機の各構成要素について例を挙げて紹介する。

【0231】

ＲＦ回路１３１０は、情報の送受信又は通信プロセスにおいて、信号を送受信するために使用され、特に、基地局のダウンリンク情報を受信した後、プロセッサ１３８０に処理させ、更に、設計されたアップリンクデータを基地局に送信するために使用される。通常、ＲＦ回路１３１０は、アンテナ、少なくとも１つの増幅器、トランシーバ、結合器、低雑音増幅器（ＬＮＡ：Ｌｏｗ Ｎｏｉｓｅ Ａｍｐｌｉｆｉｅｒ）、ダイプレクサなどを含むが、これらに限定されない。更に、ＲＦ回路１３１０は、無線通信を介してネットワーク及び他の機器と通信できる。前記無線通信は、任意の通信規格又はプロトコルを使用するでき、例えば、グローバルモバイル通信システム（ＧＳＭ：Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｏｆ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、汎用パケット無線サービス（ＧＰＲＳ：Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）、コード分割多重アクセス（ＣＤＭＡ：Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、広帯域コード分離多重アクセス（ＷＣＤＭＡ：Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、Ｅメール、ショートメッセージサービス（ＳＭＳ：Ｓｈｏｒｔ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）などを含むが、これらに限定されない。

【0232】

メモリ１３２０は、ソフトウェアプログラムやモジュールを記憶するように構成でき、プロセッサ１３８０は、メモリ１３２０に記憶されたソフトウェアプログラムやモジュールを実行することによって、携帯電話機の様々な機能アプリケーション及びデータ処理を実行する。メモリ１３２０は、主に、プログラム記憶領域及びデータ記憶領域を含み得、ここで、プログラム記憶領域は、オペレーティングシステム、少なくとも１つの機能に必要なアプリケーション（例えば、音声再生機能、画像再生機能など）を記憶することができる。データ記憶領域は、携帯電話機の使用に基づいて作成されたデータ（例えば、オーディオデータ、電話帳など）を記憶することができる。更に、メモリ１３２０は、高速ランダムアクセスメモリを含んでもよく、不揮発性メモリ（例えば、少なくとも１つのディスクメモリ、フラッシュメモリ、又は他の不揮発性固体メモリなど）を含んでもよい。

【0233】

入力ユニット１３３０は、入力されたデジタル又は文字情報を受信し、携帯電話機のユーザ設定及び機能制御に関連するキー信号入力を受信するように構成されることができる。更に、入力ユニット１３３０は、タッチパネル１３３１と他の入力機器１３３２を備えることができる。タッチパネル１３３１は、タッチスクリーンとも称し得、追加的に、又は代替的に、その近くでのユーザのタッチ操作（例えば、指、スタイラスなどの任意の適切なオブジェクト又は付属品を使用して、タッチパネル１３３１上又はタッチパネル１３３１の近くでユーザによって実行される操作など）を収集し、事前に設定されたプログラムに従って対応する接続装置を駆動することができる。一つの可能な実施形態において、タッチパネル１３３１は、タッチ検出装置とタッチコントローラの２つのパートを含み得る。ここで、タッチ検出装置は、ユーザのタッチ方位を検出し、タッチ操作による信号を検出し、当該信号をタッチコントローラに伝送する。タッチコントローラは、タッチ検出装置からのタッチ情報を受信し、それをタッチポイント座標に変換して、プロセッサ１３８０に送信し、プロセッサ１３８０によって送信される命令を受信して実行することができる。更に、タッチパネル１３３１は、抵抗性、容量性、赤外線、及び弾性表面波などの複数のタイプで実装できる。タッチパネル１３３１に加えて、入力ユニット１３３０は、更に、他の入力機器１３３２を備えることができる。例示的に、他の入力機器１３３２は、物理キーボード、ファンクションキー（音量調節ボタン、スイッチボタンなど）、トラックボール、マウス、及びジョイスティックなどのうちの１つ又は複数を含み得るが、これらに限定されない。

【0234】

ディスプレイユニット１３４０は、ユーザによって入力された情報又はユーザに提供される情報、及び携帯電話機の各メニューを表示するように構成されることができる。ディスプレイユニット１３４０は、ディスプレイパネル１３４１を備えることができ、一つの可能な実施形態において、液晶ディスプレイ（ＬＣＤ；Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）、有機発光ダイオード（ＯＬＥＤ：Ｏｒｇａｎｉｃ Ｌｉｇｈｔ－Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）などを採用してディスプレイパネル１３４１を構成することができる。更に、タッチパネル１３３１は、ディスプレイパネル１３４１を覆うことができ、タッチパネル１３３１が、その上の又は近くのタッチ操作を検出した後にプロセッサ１３８０に伝送することにより、タッチイベントのタイプを決定し、その後、プロセッサ１３８０は、タッチイベントのタイプに従って、ディスプレイパネル１３４１で対応する視覚出力を表示する。図１７では、タッチパネル１３３１及びディスプレイパネル１３４１は、携帯電話機の入力及び出力機能を実現するための２つの独立したコンポーネントとして使用されるか、いくつかの実施例では、タッチパネル１３３１及びディスプレイパネル１３４１を集積して、携帯電話機の入力及び出力機能を実現することができる。

【0235】

携帯電話機は、更に、光センサ、運動センサ、及び他のセンサなど、少なくとも一種のセンサ１３５０を備えることができる。更に、光センサは、環境光センサ及び近接センサを含み得、ここで、環境光センサは、環境の光線の明るさに従って、ディスプレイパネル１３４１の輝度を調節でき、近接センサは、携帯電話機が耳に当てられているときに、ディスプレイパネル１３４１及び／又はバックライトをオフにすることができる。加速度計センサは、モーションセンサの１つとして、各方向における（通常は３軸）加速度の大きさを検出でき、静止時の重力の大きさと方向を検出でき、携帯電話機の姿勢を識別する必要があるアプリケーション（例えば、水平および垂直画面切り替え、関連ゲーム、磁力計姿勢校正）、振動識別関連機能（歩数計、パーカッションなど）などを識別するために使用できる。携帯電話機が備えることができるジャイロスコープ、気圧計、湿度計、温度計、赤外線センサなどの他のセンサについては、ここで詳細に説明しない。

【0236】

オーディオ回路１３６０、スピーカ１３６１、マイクロフォン１３６２は、ユーザと携帯電話機との間のオーディオインターフェースを提供できる。オーディオ回路１３６０は、受信されたオーディオデータを変換した後の電気信号をスピーカ１３６１に伝送し、スピーカ１３６１によって音声信号に変換されて出力することができる。一方、マイクロフォン１３６２は、収集した音声信号を電気信号に変換して、オーディオ回路１３６０に伝送し、オーディオ回路１３６０によって当該電気信号をオーディオデータに変換し、オーディオデータをプロセッサ１３８０に出力して処理した後、ＲＦ回路１３１０を介して別の携帯電話機などに送信するか、又は更なる処理のためにオーディオデータをメモリ１３２０に記憶する。

【0237】

ＷｉＦｉは、短距離無線伝送技術であり、ユーザにワイヤレスブロードバンドインターネットアクセスを提供し、ユーザは、携帯電話機のＷｉＦｉモジュール１３７０を介して電子メールを送受信したり、Ｗｅｂページを閲覧したり、ストリーミングメディアにアクセスしたりすることができる。図１７はＷｉＦｉモジュール１３７０を示しているが、それは携帯電話機の必要な構成要素ではなく、本発明の本質を変えることなく必要に応じて省略できることを理解されたい。

【0238】

プロセッサ１３８０は、携帯電話機の制御センタであり、様々なインターフェース及び回線を使用して携帯電話機全体の各部分を接続し、メモリ１３２０に記憶されたソフトウェアプログラム及び／又はモジュールを実行し、メモリ１３２０内に記憶されたデータを呼び出すことにより、携帯電話機の各種機能及びデータ処理を実行し、それにより、携帯電話機の全体的な監視を実行する。一つの可能な実施形態において、プロセッサ１３８０は、１つ又は複数の処理ユニットを備えることができ、好ましくは、プロセッサ１３８０は、アプリケーションプロセッサとモデムプロセッサを統合することができ、ここで、アプリケーションプロセッサは、主に、オペレーティングシステム、ユーザインターフェース、及びアプリケーションなどを処理し、モデムプロセッサは、主に、無線通信を処理する。前記モデムプロセッサは、プロセッサ１３８０に統合されない場合があることを理解されたい。

【0239】

携帯電話機は、更に、各コンポーネントに電力を供給するための電源１３９０（バッテリなど）を備え、好ましくは、電源は、電力管理システムを介してプロセッサ１３８０に論理的に接続でき、それにより、電力管理システムにより、充電、放電、及び消費電力管理などの機能を管理することを実現する。

【0240】

図示されていないが、携帯電話機は、更に、カメラ、ブルートゥースモジュールなどを備えることができ、ここでは詳細に説明しない。

【0241】

本願実施例において、当該端末に含まれるプロセッサ１３８０は、ＵＥによって実行される上記のイベント処理方法の実行を制御する機能も有する。

【0242】

更に、前述した装置の実施例は例示的なものに過ぎず、ここで、分離部材として説明されたユニットは、物理的に分離されてもされていなくてもよく、ユニットとして表示された部材は、物理的なユニットである場合もそうでない場合もあることに留意されたい。つまり、前記ユニットは、１箇所に配置されてもよいし、複数のネットワークユニットに分散されてもよい。実際の必要に応じて、そのうちの一部又はすべてのモジュールを選択して、本実施例の技術案の目的を実現することができる。更に、本願による装置の実施例の図面では、モジュール間の接続関係は、モジュール間に通信接続があることを表し、１つ又は複数の通信バス又は信号線の形で実現できる。当業者は、創造的な努力なしに、理解して実施することができる。

【0243】

当業者は、上記の実施形態の説明から、ソフトウェアと必要な汎用ハードウェアの組み合わせの方式で本願を実現できることを理解することができる。もちろん、専用集積回路、専用ＣＰＵ、専用メモリ、専用コンポーネントなどの専用ハードウェアで実現することもできる。一般には、コンピュータプログラムによって完了される機能は、すべて対応するハードウェアを使用して簡単に実現でき、更に、同じ機能を実現するために使用されるハードウェアの構造も多様である（例えば、アナログ回路、デジタル回路、又は専用回路など）。しかし、本出願については、多くの場合、ソフトウェアプログラムの実現がより適切な実施形態である。このような理解に基づき、本願の技術的解決策の実質的な部分、すなわち、先行技術に貢献のある部分は、ソフトウェア製品の形で具現されることができ、当該コンピュータソフトウェア製品は、可読記憶媒体（コンピュータフロッピー（登録商標）ディスク、Ｕディスク、モバイルハードディスク、読み取り専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク又は光ディスクなど）に記憶され、コンピュータ機器（パーソナルコンピュータ、サーバ、又はネットワーク機器など）に、本願の各実施例に記載の方法を実行させるためのいくつかの命令を含む。

【0244】

まとめると、上記の実施例は、本願の技術的解決策を説明するためのものに過ぎず、本願を限定するものではない。上記の実施例を参照して本願について詳細に説明したが、当業者なら理解すべきこととして、上記の各実施例で記載された技術的解決策を変更するか、又はその中の技術的特徴の一部を同等に置換することができ、これらの変更又は置換により、対応する技術的解決策の本質が本願の各実施例の技術的解決策の精神および範囲から逸脱しない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【国際調査報告】