特許 7376472 測位プロトコルメッセージのセグメント化のための方法およびシステム

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

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

(11)【特許番号】

(24)【登録日】2023-10-30

(45)【発行日】2023-11-08

(54)【発明の名称】測位プロトコルメッセージのセグメント化のための方法およびシステム

(51)【国際特許分類】

   H04W 64/00 20090101AFI20231031BHJP

   H04W 8/24 20090101ALI20231031BHJP

   H04W 28/06 20090101ALI20231031BHJP

   H04L 1/16 20230101ALI20231031BHJP

【ＦＩ】

H04W64/00

H04W8/24

H04W28/06 110

H04L1/16

【請求項の数】 14

(21)【出願番号】P 2020519795

(86)(22)【出願日】2018-10-02

(65)【公表番号】

(43)【公表日】2020-12-17

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

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

(87)【国際公開日】2019-04-11

【審査請求日】2021-09-02

(31)【優先権主張番号】62/569,551

(32)【優先日】2017-10-08

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

(31)【優先権主張番号】62/587,428

(32)【優先日】2017-11-16

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

(31)【優先権主張番号】16/148,722

(32)【優先日】2018-10-01

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

(73)【特許権者】

【識別番号】595020643

【氏名又は名称】クゥアルコム・インコーポレイテッド

【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(72)【発明者】

【氏名】エッジ、スティーブン・ウィリアム

(72)【発明者】

【氏名】フィッシャー、スベン

【審査官】伊藤 嘉彦

(56)【参考文献】

【文献】特表２０１４－５０２０８１（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１２／０１４７７３２（ＵＳ，Ａ１）

【文献】特開２０１６－０７６９５４（ＪＰ，Ａ）

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

【文献】Qualcomm Europe，Initial proposed contents for stage 3 LPP specification[online]，3GPP TSG-RAN WG2♯67 Meeting R2-094407，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_67/Docs/R2-094407.zip>，2009年08月18日

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

Ｈ０４Ｌ １／１６

Ｈ０４Ｗ ４／００ － ９９／００

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

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

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

【請求項1】

位置特定セッションにおけるロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージのサイズを制限するための方法であって、
第１のデバイスから第２のデバイスに、前記第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを送信することと、
前記第１のＬＰＰメッセージの前記送信の後で、前記第２のデバイスから前記第１のデバイスにおいて、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える複数のＬＰＰメッセージセグメントを受信することと、ここにおいて、前記複数のＬＰＰメッセージセグメントの各々が、それぞれの前記ＬＰＰメッセージセグメントが最後であることまたは最後ではないことを示すセグメント情報フィールド、及び前記複数のＬＰＰメッセージセグメントを含むＬＰＰトランザクションの最後を示す最後のトランザクションフィールドを含み、ここにおいて、前記セグメント情報フィールドが前記最後のトランザクションフィールドと独立であり、ここにおいて、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、それぞれの前記最後ではないＬＰＰメッセージセグメントが最後ではないこと、および１つまたは複数の追加のＬＰＰメッセージセグメントが転送されるであろうことを示すように設定された前記セグメント情報フィールドを含み、
前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であること、およびこれ以上のＬＰＰメッセージセグメントが転送されないであろうことを示すように設定された前記セグメント情報フィールドを含む、
前記第１のデバイスにおいて、前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントを記憶することと、
前記第１のデバイスによって、前記最後のＬＰＰメッセージセグメントが受信された後で前記複数のＬＰＰメッセージセグメントを処理すること、ここにおいて前記処理することが同じＬＰＰメッセージタイプに基づく、
を含む方法。

【請求項2】

前記第１のデバイスにおいて、前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を記憶することと、
前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数を記憶した後で、前記第１のデバイスによって、前記複数のＬＰＰメッセージセグメントのうちの少なくとも１つの前記受信におけるエラーを決定することと、
前記エラーを決定したことに応答して、前記第１のデバイスによって、前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数を廃棄することとをさらに備える、請求項１に記載の方法。

【請求項3】

前記エラーの前記決定を示すメッセージを、前記第１のデバイスから前記第２のデバイスに送信することをさらに備える、請求項２に記載の方法。

【請求項4】

前記複数のＬＰＰメッセージセグメントのうちの前記少なくとも１つの前記受信における前記エラーを前記決定することが、前記第１のデバイスにおいて受信された前記複数のＬＰＰメッセージセグメントのうちの前記少なくとも１つが、前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数とは異なるメッセージタイプを有すると決定すること、または、前記第１のデバイスにおいて受信された前記複数のＬＰＰメッセージセグメントのうちの前記少なくとも１つが、前記複数のＬＰＰメッセージセグメントのための手順の現在の状態に対する無効なメッセージタイプを有すると決定することを備える、請求項２に記載の方法。

【請求項5】

位置特定セッションにおけるロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージのサイズを制限するための方法であって、
第１のデバイスから第２のデバイスにおいて、前記第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを受信することと、
前記第１のＬＰＰメッセージの前記受信の後で、見込まれるＬＰＰメッセージのサイズがある閾値を超えるであろうことを決定することと、
前記第２のデバイスから前記第１のデバイスに、前記見込まれるＬＰＰメッセージに対応する情報を備える複数のＬＰＰメッセージセグメントを送信することとを備え、前記複数のＬＰＰメッセージセグメントが、１つまたは複数の最後ではないＬＰＰメッセージセグメントと最後のＬＰＰメッセージセグメントとを備え、ここにおいて、前記複数のＬＰＰメッセージセグメントの各々が、それぞれの前記ＬＰＰメッセージセグメントが最後であることまたは最後ではないことを示すセグメント情報フィールド、及び前記複数のＬＰＰメッセージセグメントを含むＬＰＰトランザクションの最後を示す最後のトランザクションフィールドを含み、ここにおいて、前記セグメント情報フィールドが前記最後のトランザクションフィールドと独立である、ここにおいて、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、それぞれの前記最後ではないＬＰＰメッセージセグメントが最後ではないこと、および１つまたは複数の追加のＬＰＰメッセージセグメントが転送されるであろうことを示すように設定された前記セグメント情報フィールドを含み、前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であること、およびこれ以上のＬＰＰメッセージセグメントが転送されないであろうことを示すように設定された前記セグメント情報フィールドを含む、
前記第１のデバイスにおいて、前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントを記憶することと、
前記第１のデバイスによって、前記最後のＬＰＰメッセージセグメントが受信された後で前記複数のＬＰＰメッセージセグメントを処理すること、ここにおいて前記処理することが同じＬＰＰメッセージタイプに基づく、
方法。

【請求項6】

前記第１のデバイスがエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備え、前記第２のデバイスがユーザ機器（ＵＥ）を備え、または、
前記第１のデバイスがＵＥを備え、前記第２のデバイスがＥ－ＳＭＬＣもしくはＬＭＦを備える、請求項１または５に記載の方法。

【請求項7】

前記第１のＬＰＰメッセージが、ＬＰＰ能力要求メッセージ、ＬＰＰ能力提供メッセージ、またはＬＰＰ位置情報要求メッセージを備える、請求項１または５に記載の方法。

【請求項8】

前記複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントが、前記見込まれるＬＰＰメッセージと同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備える、請求項５に記載の方法。

【請求項9】

前記同じＬＰＰメッセージタイプが、ＬＰＰ能力提供メッセージタイプ、ＬＰＰ支援データ提供メッセージタイプ、ＬＰＰ支援データ要求メッセージタイプ、ＬＰＰ位置情報要求メッセージタイプ、またはＬＰＰ位置情報提供メッセージタイプを備える、請求項８に記載の方法。

【請求項10】

前記第１のＬＰＰメッセージを受信する前に、前記第２のデバイスが、前記第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを前記第１のデバイスに送信する、請求項１または５に記載の方法。

【請求項11】

前記第２のＬＰＰメッセージがＬＰＰ能力要求メッセージを備える、請求項１０に記載の方法。

【請求項12】

前記第２のデバイスにおいて前記第１のデバイスから、前記複数のＬＰＰメッセージセグメントのうちの少なくとも１つの前記受信におけるエラーの決定を示すメッセージを受信することと、
前記エラーの前記決定を示す前記メッセージを受信したことに応答して、前記複数のＬＰＰメッセージセグメントと関連付けられるＬＰＰセッションを中止することとをさらに備える、請求項５に記載の方法。

【請求項13】

セグメント化されたロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージを受信するためのデバイスであって、
通信インターフェースと、
メモリと、
前記通信インターフェースおよび前記メモリと通信可能に結合される１つまたは複数の処理ユニットとを備え、前記処理ユニットが、前記デバイスに、
前記通信インターフェースを介して送信デバイスへ、前記デバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを送信させ、
前記第１のＬＰＰメッセージの前記送信の後で、前記通信インターフェースを介して、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える複数のＬＰＰメッセージセグメントを前記送信デバイスから受信させるように構成され、ここにおいて、前記複数のＬＰＰメッセージセグメントの各々が、それぞれの前記ＬＰＰメッセージセグメントが最後であることまたは最後ではないことを示すセグメント情報フィールド、及び前記複数のＬＰＰメッセージセグメントを含むＬＰＰトランザクションの最後を示す最後のトランザクションフィールドを含み、ここにおいて、前記セグメント情報フィールドが前記最後のトランザクションフィールドと独立である、ここにおいて、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、それぞれの前記最後ではないＬＰＰメッセージセグメントが最後ではないこと、および１つまたは複数の追加のＬＰＰメッセージセグメントが転送されるであろうことを示すように設定された前記セグメント情報フィールドを含み、
前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であること、およびこれ以上のＬＰＰメッセージセグメントが転送されないであろうことを示すように設定された前記セグメント情報フィールドを含む、
前記デバイスにおいて、前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントを記憶させ、
前記デバイスによって、前記最後のＬＰＰメッセージセグメントが受信された後で前記複数のＬＰＰメッセージセグメントを処理させ、ここにおいて前記処理することが同じＬＰＰメッセージタイプに基づく、
デバイス。

【請求項14】

セグメント化されたロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージを送信するためのデバイスであって、
通信インターフェースと、
メモリと、
前記通信インターフェースおよび前記メモリと通信可能に結合される１つまたは複数の処理ユニットとを備え、前記処理ユニットが、前記デバイスに、
前記通信インターフェースを介して、受信デバイスから、前記受信デバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを受信させ、
前記第１のＬＰＰメッセージの前記受信の後で、見込まれるＬＰＰメッセージのサイズがある閾値を超えるであろうことを決定させ、
前記受信デバイスへ、前記通信インターフェースを介して、前記見込まれるＬＰＰメッセージに対応する情報を備える複数のＬＰＰメッセージセグメントを送信させるように構成され、前記複数のＬＰＰメッセージセグメントが、１つまたは複数の最後ではないＬＰＰメッセージセグメントと最後のＬＰＰメッセージセグメントとを備え、ここにおいて、前記複数のＬＰＰメッセージセグメントの各々が、それぞれの前記ＬＰＰメッセージセグメントが最後であることまたは最後ではないことを示すセグメント情報フィールド、及び前記複数のＬＰＰメッセージセグメントを含むＬＰＰトランザクションの最後を示す最後のトランザクションフィールドを含み、ここにおいて、前記セグメント情報フィールドが前記最後のトランザクションフィールドと独立である、ここにおいて、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、それぞれの前記最後ではないＬＰＰメッセージセグメントが最後ではないこと、および１つまたは複数の追加のＬＰＰメッセージセグメントが転送されるであろうことを示すように設定された前記セグメント情報フィールドを含み、
前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であること、およびこれ以上のＬＰＰメッセージセグメントが転送されないであろうことを示すように設定された前記セグメント情報フィールドを含む、
前記受信デバイスにおいて、前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントを記憶させ、
前記受信デバイスによって、前記最後のＬＰＰメッセージセグメントが受信された後で前記複数のＬＰＰメッセージセグメントを処理させ、ここにおいて前記処理することが同じＬＰＰメッセージタイプに基づく、
デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

[0001] 本明細書で開示される主題は、ワイヤレス通信システムに関し、より詳細には、測位プロトコルを使用するワイヤレス通信システムにおけるユーザ機器の位置特定のためのシステムおよび方法に関する。

【背景技術】

【0002】

[0002] 携帯電話などのユーザ機器（ＵＥ）の位置を知ることが望ましいことがしばしばある。位置は、ＵＥがナビゲーション情報をユーザに提供することを可能にすること、人物または資産発見サービスを可能にすること、または、緊急通報の緊急応答者にＵＥの位置を提供することなどの、様々な用途のいずれかのために使用され得る。ＵＥの位置を決定するプロセスは、とりわけ、ロングタームエボリューション（ＬＴＥ（登録商標））測位プロトコル（ＬＰＰ：ＬＴＥ Positioning Protocol）などの測位プロトコルを使用した、ＵＥとエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ：Enhanced Serving Mobile Location Center）などの位置サーバ（ＬＳ：location server）との間の通信を伴い得る。

【0003】

[0003] しかしながら、いくつかの事例では、測位プロトコル（例えば、ＬＰＰ）メッセージのサイズが問題を引き起こし得る。例えば、ＬＰＰメッセージのサイズが、ＵＥとＬＳとの間でＬＰＰメッセージを搬送するために使用されるトランスポートプロトコルにより課されるサイズの制限を超えることがある。その場合、ＬＰＰメッセージを搬送することが可能ではないことがあり、場合によっては、ＵＥの位置特定の失敗、またはＵＥのために取得される位置推定における障害（例えば、より低い正確さ）をもたらす。

【発明の概要】

【0004】

[0004] 本明細書で開示される方法および技法は、ユーザ機器と位置サーバとの間の位置特定セッションにおいてＬＴＥ測位プロトコル（ＬＰＰ）メッセージのサイズを制限することによって、これらの問題および他の問題に対処する。実施形態は、第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることを示す第１のＬＰＰメッセージを、第１のデバイスが第２のデバイスに送信することを可能にし得る。続いて、第１のデバイスは、１つまたは複数の最後ではないＬＰＰメッセージセグメントと最後のＬＰＰメッセージセグメントとを備える複数のＬＰＰメッセージセグメントを第２のデバイスから受信でき、各ＬＰＰメッセージセグメントは「最後ではない」または「最後である」ことの指示を含む。第１のデバイスは次いで、最後ではないＬＰＰメッセージセグメントを記憶でき、最後のＬＰＰメッセージセグメントを受信した後でＬＰＰメッセージセグメントを処理する。第１のＬＰＰメッセージを送信する前に、第１のデバイスは、第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることを示すＬＰＰメッセージを第２のデバイスから受信し得る。

【0005】

[0005] 本開示によれば、位置特定セッションにおけるＬＰＰメッセージのサイズを制限するための第１の例示的な方法は、第１のデバイスから第２のデバイスに、第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを送信することと、第１のＬＰＰメッセージを送信した後で、第２のデバイスから第１のデバイスにおいて、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える複数のＬＰＰメッセージセグメントを受信することとを備える。１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントは、それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、最後のＬＰＰメッセージセグメントは、最後のＬＰＰメッセージセグメントが最後であることの指示を含む。

【0006】

[0006] 第１の例示的な方法の代替的な実施形態は、１つまたは複数の以下の特徴を含み得る。第１のデバイスが、エンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ：Location Management Function）を備えることがあり、第２のデバイスがユーザ機器（ＵＥ）を備えることがあり、または、第１のデバイスがＵＥを備えることがあり、第２のデバイスがＥ－ＳＭＬＣもしくはＬＭＦを備えることがある。第１のＬＰＰメッセージは、ＬＰＰ能力要求メッセージ（LPP Request Capabilities Message）およびＬＰＰ能力提供メッセージ（LPP Provide Capabilities message）またはＬＰＰ位置情報要求メッセージ（LPP Request Location Information message）を備え得る。第１のＬＰＰメッセージを送信する前に、第１のデバイスは、第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを第２のデバイスから受信し得る。第２のＬＰＰメッセージは、ＬＰＰ能力要求メッセージを備え得る。複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントは、同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備え得る。同じＬＰＰメッセージタイプは、ＬＰＰ能力提供メッセージタイプ、ＬＰＰ支援データ提供（LPP Provide Assistance Data）メッセージタイプ、ＬＰＰ支援データ要求（LPP Request Assistance Data）メッセージタイプ、ＬＰＰ位置情報要求（LPP Request Location Information）メッセージタイプ、またはＬＰＰ位置情報提供（LPP Provide Location Information）メッセージタイプを備え得る。方法はさらに、第１のデバイスによって、各ＬＰＰメッセージセグメントが受信されるときに複数のＬＰＰメッセージセグメントの各ＬＰＰメッセージセグメントを処理することを備えることがあり、この処理は同じＬＰＰメッセージタイプに基づく。方法はさらに、第１のデバイスにおいて、１つまたは複数の最後ではないＬＰＰメッセージセグメン
トの各々の最後ではないＬＰＰメッセージセグメントを記憶することと、第１のデバイスによって、最後のＬＰＰメッセージが受信された後で複数のＬＰＰメッセージセグメントを処理することとを備えることがあり、この処理は同じＬＰＰメッセージタイプに基づく。方法はさらに、第１のデバイスにおいて、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を記憶したことに続いて、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を記憶することと、第１のデバイスによって、複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信におけるエラーを決定することと、エラーを決定したことに応答して、第１のデバイスによって、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を廃棄することとを備え得る。方法はさらに、エラーの決定を示すメッセージを、第１のデバイスから第２のデバイスに送信することを備え得る。複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信におけるエラーを決定することは、第１のデバイスにおいて受信された複数のＬＰＰメッセージセグメントのうちの少なくとも１つが、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数とは異なるメッセージタイプを有すると決定することを備え得る。複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信におけるエラーを決定することは、第１のデバイスにおいて受信された複数のＬＰＰメッセージセグメントのうちの少なくとも１つが、複数のＬＰＰメッセージセグメントのための手順の現在の状態に対する無効なメッセージタイプを有すると決定することを備え得る。

【0007】

[0007] 本開示によれば、位置特定セッションにおけるロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージのサイズを制限するための第２の例示的な方法は、第２のデバイスにおいて第１のデバイスから、第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを受信することと、第１のＬＰＰメッセージの受信の後で、見込まれるＬＰＰメッセージのサイズがある閾値を超えると決定することと、第２のデバイスから第１のデバイスに、見込まれるＬＰＰメッセージに対応する情報を備える複数のＬＰＰメッセージセグメントを送信することとを備え、複数のＬＰＰメッセージセグメントは１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備え、１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントは、それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、最後のＬＰＰメッセージセグメントは、最後のＬＰＰメッセージセグメントが最後であることの指示を含む。

【0008】

[0008] 第２の例示的な方法の代替的な実施形態は、１つまたは複数の以下の特徴を含み得る。第１のデバイスが、エンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備えることがあり、第２のデバイスがユーザ機器（ＵＥ）を備えることがあり、または、第１のデバイスがＵＥを備えることがあり、第２のデバイスがＥ－ＳＭＬＣもしくはＬＭＦを備えることがある。第１のＬＰＰメッセージは、ＬＰＰ能力要求メッセージ、ＬＰＰ能力提供メッセージまたはＬＰＰ位置情報要求メッセージを備え得る。複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントは、見込まれるＬＰＰメッセージと同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備え得る。同じＬＰＰメッセージタイプは、ＬＰＰ能力提供メッセージタイプ、ＬＰＰ支援データ提供メッセージタイプ、ＬＰＰ支援データ要求メッセージタイプ、ＬＰＰ位置情報要求メッセージタイプ、またはＬＰＰ位置情報提供メッセージタイプを備え得る。第１のＬＰＰメッセージを受信する前に、第２のデバイスは、第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを第１のデバイスに送信し得る。第２のＬＰＰメッセージは、ＬＰＰ能力要求メッセージを備え得る。方法はさらに、第１のデバイスから第２のデバイスにおいて、複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信におけるエラーの決定を示すメッセージを受信することと、エラーの決定を示すメッセージを受信したことに応答して、複数のＬＰＰメッセージセグメントと関連付けられるＬＰＰセッションを中止することとを備え得る。

【0009】

[0009] 本開示によれば、セグメント化されたロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージを受信するための例示的なデバイスは、通信インターフェースと、メモリと、処理ユニットとを備え、処理ユニットは、通信インターフェースおよびメモリに通信可能に結合され、デバイスに、通信インターフェースを介して送信デバイスへ、デバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを送信させ、第１のＬＰＰメッセージの送信の後で、通信インターフェースを介して送信デバイスから、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える複数のＬＰＰメッセージセグメントを受信させるように構成される。１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントは、それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、最後のＬＰＰメッセージセグメントは、最後のＬＰＰメッセージセグメントが最後であることの指示を含む。

【0010】

[0010] 例示的なデバイスの代替的な実施形態は、以下の特徴のうちの１つまたは複数を備え得る。デバイスが、エンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備えることがあり、送信デバイスがユーザ機器（ＵＥ）を備えることがあり、または、デバイスがＵＥを備えることがあり、送信デバイスがＥ－ＳＭＬＣもしくはＬＭＦを備える。デバイスは、第１のＬＰＰメッセージを送信する前に、送信デバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを送信デバイスから受信するように構成され得る。処理ユニットはさらに、デバイスに、同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備える複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントを受信させるように構成され得る。処理ユニットはさらに、デバイスに、１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントをメモリ内に記憶させ、最後のＬＰＰメッセージセグメントが受信された後で複数のＬＰＰメッセージセグメントを処理させるように構成されることがあり、この処理は同じＬＰＰメッセージタイプに基づき得る。処理ユニットはさらに、デバイスに、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を記憶したことに続いて、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数をメモリ内に記憶させ、複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信におけるエラーを決定させ、エラーを決定したことに応答して、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を廃棄させるように構成され得る。

【0011】

[0011] 本開示によれば、セグメント化されたロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージを送信するための例示的なデバイスは、通信インターフェースと、メモリと、処理ユニットとを備え、処理ユニットは、通信インターフェースおよびメモリと通信可能に結合され、デバイスに、通信インターフェースを介して受信デバイスから、受信デバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを受信させ、第１のＬＰＰメッセージの受信の後で、見込まれるＬＰＰメッセージのサイズがある閾値を超えるであろうことを決定させ、通信インターフェースを介して受信デバイスへ、見込まれるＬＰＰメッセージに対応する情報を備える複数のＬＰＰメッセージセグメントを送信させるように構成され、複数のＬＰＰメッセージセグメントは、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える。１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントは、それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、最後のＬＰＰメッセージセグメントは、最後のＬＰＰメッセージセグメントが最後であることの指示を含む。

【0012】

[0012] 例示的なデバイスの代替の実施形態はさらに、以下の特徴のうちの１つまたは複数を備え得る。受信デバイスが、エンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備えることがあり、デバイスがユーザ機器（ＵＥ）を備えることがあり、または、受信デバイスがＵＥを備えることがあり、デバイスがＥ－ＳＭＬＣもしくはＬＭＦを備えることがある。処理ユニットはさらに、デバイスに、第１のＬＰＰメッセージを受信する前に、デバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを受信デバイスへ送信させるように構成され得る。処理ユニットはさらに、デバイスに、受信デバイスから通信インターフェースを介して、複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信におけるエラーの決定を示すメッセージを受信させ、エラーの決定を示すメッセージを受信したことに応答して、複数のＬＰＰメッセージセグメントと関連付けられるＬＰＰセッションを中止させるように構成され得る。

【0013】

[0013] 以下の図を参照して非限定的で非網羅的な態様が説明され、別段に規定されていない限り、様々な図の全体を通じて、同様の参照番号は同様の部分を指す。

【図面の簡単な説明】

【0014】

【図1】一実施形態による、ユーザ機器（ＵＥ）の位置特定のサポートを可能にするためのシステムのアーキテクチャを示す簡略化されたブロック図。

【図2】一実施形態による、ＬＰＰメッセージセグメント化が使用される、ＵＥとエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）との間の位置特定セッションのある態様を示すシグナリングフロー図。

【図3】一実施形態による、ＬＰＰメッセージセグメント化が使用される、ＵＥとエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）との間の位置特定セッションのある態様を示すシグナリングフロー図。

【図4】一実施形態による、ＬＰＰメッセージセグメント化が使用される、ＵＥとエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）との間の位置特定セッションのある態様を示すシグナリングフロー図。

【図5】一実施形態による、ＬＰＰメッセージセグメント化が使用される、ＵＥとエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）との間の位置特定セッションのある態様を示すシグナリングフロー図。

【図6】一実施形態による、ＬＰＰメッセージセグメント化が使用される、ＵＥとエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）との間の位置特定セッションのある態様を示すシグナリングフロー図。

【図7】一実施形態による、位置特定セッションにおいてＬＰＰメッセージセグメント化をサポートする方法のプロセスフロー図。

【図8】一実施形態による、位置特定セッションにおいてＬＰＰメッセージセグメント化をサポートする方法のプロセスフロー図。

【図9】ＵＥの一実施形態のブロック図。

【図10】一実施形態による、位置サーバなどのコンピュータシステムのブロック図。

【詳細な説明】

【0015】

[0019] 図面において、同様の要素を示すために同様の番号が使用される。

【0016】

[0020] 本出願の一部をなす添付の図面に関し、いくつかの例示的な実施形態が本明細書で説明される。以下の説明は、実施形態を与えるにすぎず、本開示の範囲、適用可能性、または構成を限定することは意図されない。むしろ、実施形態の以下の説明は、一実施形態を実現することを可能にする説明を当業者に与える。本開示の趣旨および範囲から逸脱することなく、要素の機能および構成において様々な変更が行われ得ることを理解されたい。

【0017】

[0021] 本明細書で説明される実施形態はＬＰＰなどの特定の技術および規格に言及するが、本明細書で提供される技法は他の技術、規格、および／またはワイヤレス環境に適用され得ることを当業者が認識するであろうことが、留意され得る。

【0018】

[0022] 携帯電話、タブレット、パーソナルメディアプレーヤー、車載システム、または同様の電子デバイスなどのＵＥの位置を知ることは、多くの場合に望ましい。位置は、ＵＥがナビゲーション情報をユーザに提供することを可能にすること、人物または資産発見サービスを可能にすること、または、緊急通報の緊急応答者にＵＥの位置を提供することなどの、様々な用途のいずれかのために使用され得る。ＵＥの位置を決定するプロセスは、とりわけ、３ＧＰＰ（登録商標）技術仕様（ＴＳ）３６．３５５における第３世代パートナーシッププロジェクト（３ＧＰＰ）によって定義されるＬＴＥ測位プロトコル（ＬＰＰ）などの測位プロトコルを使用した、ＵＥとエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）などの位置サーバ（ＬＳ）との間の通信を伴い得る。

【0019】

[0023] しかしながら、いくつかの事例では、測位プロトコル（例えば、ＬＰＰ）メッセージのサイズが問題を引き起こし得る。例えば、ＬＰＰの場合、ＬＰＰメッセージのサイズが、ＵＥとＬＳとの間でＬＰＰメッセージを搬送するために使用されるトランスポートプロトコルにより課されるサイズの制限を超えることがある。例えば、ＬＰＰメッセージは、ＬＴＥアクセスのある制御プレーン位置のためのサービング基地局（例えば、ｅＮＢ）とＵＥとの間でＬＰＰメッセージを転送するために使用され得るパケットデータコンバージェンスプロトコル（ＰＤＣＰ）トランスポートプロトコルによって許容され得る、８１８８オクテットという最大のサイズを超え得る。ＵＥとＬＳ（例えば、Ｅ－ＳＭＬＣ）がこの最大値未満にＬＰＰメッセージサイズを制約することが必要であり得ることが、示唆される。しかし、これは、ある重要な情報を制限すること、または別のエンティティに提供しないことによって、ＬＰＰセッションを損ない得る、稚拙な解決法であり得る。

【0020】

[0024] 全般に通信に関連し、より具体的にはＵＥのための位置特定サービスをサポートするための技法に関連する、本明細書で説明される技法は、測位プロトコル（例えば、ＬＰＰ）メッセージがセグメント化されることを可能にすることによって、これらの問題および他の問題に対処し得る。セグメント化により、メッセージサイズの制限（例えば、ＬＴＥアクセスのための制御プレーン位置の場合の８１８８オクテット）を超えるであろう測位プロトコル（例えば、ＬＰＰメッセージ）のための見込まれるメッセージは、ＵＥまたはＬＳによって送信される前に、メッセージセグメントと呼ばれる２つ以上のより小さい測位プロトコルメッセージへとセグメント化（または分割）される。例えば、各メッセージセグメントは、良く形成された測位プロトコルメッセージであり得る。例えば、ＬＰＰの場合、各ＬＰＰメッセージセグメントは、３ＧＰＰ ＴＳ ３６．３５５におけるＬＰＰの抽象構文記法１（ＡＳＮ．１：Abstract Syntax Notation One）定義に従った良く形成されたＬＰＰメッセージであることがあり、他のＬＰＰメッセージセグメントの各々と同じＬＰＰトランザクション識別子（ＩＤ）を含むことがある。しかしながら、各メッセージセグメントは、セグメント化がない場合に見込まれる測位プロトコルメッセージ全体が含むであろう情報のサブセットのみを含み得る。加えて、全てのメッセージセグメントに含まれる全体の情報は、見込まれる測位プロトコルメッセージに含まれていたであろう情報に対応し得る（例えば、それと同じであり得る）。

【0021】

[0025] 一部の測位プロトコル（例えば、ＬＰＰ）では、２つ以上のメッセージセグメントのセットの受信者は、受信されたメッセージセグメントが、送信の前にセグメント化された、より大きい測位プロトコルメッセージに対応することを認識している必要があり得る。例えば、受信者は、全ての受信されたメッセージセグメントに基づく処理およびアクションを行う前に、全てのメッセージセグメントが受信されるまで待機する必要があり得る。逆に、メッセージセグメントがより大きい見込まれる測位プロトコルメッセージの一部であることを受信者が認識していない場合、受信者は、最適ではない可能性がある、またはメッセージセグメントの送信者によって意図されるアクションではない可能性がある、受信されたメッセージセグメントに基づく処理およびアクションを行うことがある。このことは、直ちに、または場合によっては後に、１つまたは複数の後続のメッセージセグメントが受信されるとき、問題を引き起こし得る。例として、ＬＰＰの場合、ＬＳ（例えば、Ｅ－ＳＭＬＣ）が見込まれるＬＰＰ位置情報要求（ＲＬＩ：Request Location Information）メッセージを２つ以上のＬＰＰ ＲＬＩメッセージセグメントへとセグメント化する必要がある場合、第１のＬＰＰ ＲＬＩメッセージセグメントを受信し、より多くのＬＰＰ ＲＬＩメッセージセグメントが後に続くことを認識していない受信ＵＥは、第１のＬＰＰ ＲＬＩによって要求される位置関連の測定を取得し始め得る。ＵＥが後で第２のＬＰＰ ＲＬＩメッセージセグメントを受信するとき、ＵＥは、第２のＬＰＰ ＲＬＩメッセージセグメントが、３ＧＰＰ ＴＳ ３６．３５５における規則に従って第１のＬＰＰメッセージセグメントと同じＬＰＰトランザクションＩＤを含む場合、エラーを決定することがあり、次いで、第２のＬＰＰ ＲＬＩメッセージセグメントを廃棄（例えば、無視）し、および／または、第１のＬＰＰ ＲＬＩメッセージセグメントのための位置測定を中止することがある。代わりに、ＵＥは、第１のＬＰＰ ＲＬＩメッセージセグメントへの異なるトランザクションとして第２のＬＰＰ ＲＬＩメッセージセグメントを扱うことがあり、次いで、第２のＬＰＰ ＲＬＩメッセージセグメントによって要求される別個の位置情報を取得し、これを、第１のＬＰＰ ＬＩメッセージセグメントのためにＬＳに返される位置情報とは別個にＬＳへ返すことがあり、これはＬＳに対する問題を引き起こすことがある。しかしながら、第１のＬＰＰ ＲＬＩメッセージセグメントがメッセージセグメントであり、完全なセグメント化されていないＬＰＰメッセージではないことを、ＵＥが認識している場合、ＵＥは、第１のＬＰＰ ＲＬＩメッセージセグメントの後で第２の（および任意の追加の）ＬＰＰ ＲＬＩメッセージセグメントを受信するのを待機し、その後で、これらのメッセージセグメントによって要求される位置測定結果を取得し始めることがある。代わりに、ＵＥは、第１のＬＰＰ ＲＬＩメッセージセグメントがＵＥによって受信されるとき、第１のＬＰＰ ＲＬＩメッセージセグメントによって要求される位置測定結果を取得し始めることがあり、第２のおよび任意の追加のＬＰＰ ＲＬＩメッセージセグメントが後でＵＥによって受信されるとき、これらによって要求される追加の位置測定結果を取得する準備が整い得る。

【0022】

[0026] ＬＰＰの場合、ＬＰＰ ＲＬＩについて説明されたばかりの問題と同様の問題が、ＵＥによりＬＳ（例えば、Ｅ－ＳＭＬＣ）に送信されるべき見込まれるＬＰＰ位置情報提供（ＰＬＩ）メッセージがメッセージサイズの制限を超え、２つ以上のＬＰＰ ＰＬＩメッセージセグメントへとセグメント化される必要があるときに、生じ得る。この場合、第１のＬＰＰ ＰＬＩメッセージセグメントの後に追加のＬＰＰ ＰＬＩメッセージセグメントがあることをＬＳ（例えば、Ｅ－ＳＭＬＣ）が認識していない場合、ＬＳは、第１のＬＰＰ ＰＬＩメッセージセグメントに含まれる位置情報だけに基づいてＵＥの位置推定を取得しようと試みることがあり、このことは、全てのＬＰＰ ＰＬＩメッセージセグメントに含まれる位置情報からの位置推定を、それらが全て受信されたＬＳであった後に取得するために待機することと比較して、より不正確な位置推定をもたらすことがあり、または場合によっては位置推定をもたらさないことがある。ＬＰＰを用いると、ＬＳは時々、あるＬＰＰメッセージセグメントが、ＬＰＰメッセージセグメントの中にトランザクションの終了の指示がないことから、最後のメッセージセグメントではないことを認識していることがある。しかしながら、これは、ＬＳが最後の位置のためのＬＰＰ ＰＬＩメッセージセグメントを受信するときにのみ使用されることがあり、最後ではない位置に対して、例えば、ＬＳがＵＥから定期的な位置情報を要求したときに使用可能ではないことがある。これらの問題により、何ら最終的なアクションをとることなく全てのＬＰＰメッセージセグメントが受信されるまで待機するために、ＬＰＰメッセージセグメントが受信されていることをＬＰＰメッセージセグメントの受信者が認識していることが必要であり得るならば。

【0023】

[0027] ＬＰＰ ＲＬＩメッセージおよびＬＰＰ ＰＬＩメッセージについて説明されたばかりの問題と同様の問題が、ＬＰＰ支援データ提供（ＰＡＤ）メッセージがＬＳによってセグメント化される場合に、ＬＰＰ ＰＡＤメッセージについても生じることがある。ＬＳからＬＰＰ ＰＡＤメッセージセグメントを受信するＵＥは、トランザクション終了フラグの欠如から、さらなる支援データが後に続くことを認識していることがある。しかしながら、ＵＥの位置特定（例えば、リアルタイムキネマティクス（ＲＴＫ：Real Time Kinematics）を使用した）をサポートするために使用されるＬＰＰ支援データ定期配信手順において、ＵＥは、ＬＰＰ ＰＡＤメッセージセグメントを受信し、さらなるＬＰＰ ＰＡＤメッセージセグメントがすぐ後（例えば、５０～２００ミリ秒以内）に続くか、または何らかのより長い時間期間（例えば、数秒以上）の後にのみ続くのかを、知らないことがあり、もしくは認識していないことがある。

【0024】

[0028] 状況に応じて、ＵＥ、ＬＳ、または両方が、セグメント化された測位プロトコル（例えば、ＬＰＰ）メッセージをセグメント化および／または受信できるようにされ得る。測位プロトコル（例えば、ＬＰＰ）メッセージの送信者が、受信者がセグメント化されたメッセージの受信をサポートすることを事前に知る（およびそれにより、上で説明された問題などの問題を回避する）ことを可能にするために、１つまたは複数の能力フラグが、この能力を示すために１つまたは複数の測位プロトコルメッセージに含まれ得る。例えば、ＬＰＰの場合、１つまたは複数の能力フラグが、ＬＰＰメッセージセグメントの受信および／または送信をサポートするためのＬＳ能力をＵＥに示すために、ＬＰＰ能力要求メッセージに含まれ得る（例えば、ＬＳによってＵＥに送信され得る）。同様に、１つまたは複数の能力フラグが、ＬＰＰメッセージセグメントの送信および／または受信をサポートするためのＵＥ能力を示すために、ＬＰＰ能力提供メッセージに含まれ得る（例えば、ＬＳに示すためにＵＥによって送信され得る）。ＬＰＰメッセージがセグメント化されるとき、ＬＰＰメッセージセグメントは、最後ではないメッセージセグメントを示すためにあるフラグをＬＰＰメッセージセグメントに含め、最後のメッセージセグメントを示すために異なるフラグを含めることなどによって、他のフラグを使用して示され得る。

【0025】

[0029] 本明細書でより詳細に説明されるように、実施形態は、説明される機能に応じて追加の特徴を含み得る。例えば、ＬＰＰの場合、各ＬＰＰメッセージセグメントは良く形成されたＬＰＰメッセージであり得るので、ＬＰＰ ＡＳＮ．１の規則により、２つ以上のＬＰＰメッセージセグメントにおいて現れ得る一部の情報の複製があってもよい。従って、いくつかの実施形態によれば、あらゆる複製される情報が同一であること、または少なくとも一貫していること（例えば、矛盾しないこと）を要求する規則が、ＬＰＰにおいて定められ得る。加えて、または代わりに、セグメント化をサポートするＵＥまたはＬＳは、遅延が制限される必要があるとき、または混雑しているとき、サポートを無効にするように切り替えてもよい（例えば、セグメント化のサポートがないことを示してもよい）。ＬＰＰメッセージを送信するときのセグメント化をサポートする第１のエンティティ（例えば、ＵＥまたはサーバ）が、ＬＰＰメッセージを受信するときのセグメント化をサポートしない第２のエンティティとのＬＰＰセッションを有するとき、第１のエンティティは、送信されるＬＰＰメッセージをセグメント化しないことがあり、しかし、代わりに、ＬＰＰメッセージが許可される最大サイズ（例えば、ＰＤＣＰによる制限の場合、８１８８オクテットなど）未満であることを確実にするために必要であれば、送信されるＬＰＰメッセージの中の情報の内容を減らすことがある。

【0026】

[0030] 図１は、一実施形態による、本明細書で説明されるＬＰＰメッセージをセグメント化するための技法を実現するために使用され得る、ＵＥ１０２の位置特定サポートのためのネットワークアーキテクチャ１００を示す図である。ネットワークアーキテクチャ１００は、進化型パケットシステム（ＥＰＳ：Evolved Packet System）と呼ばれることがある。示されるように、ネットワークアーキテクチャ１００は、ＵＥ１０２、進化型ユニバーサルモバイルテレコミュニケーションズサービス（ＵＭＴＳ）地上無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ）１２０、および進化型パケットコア（ＥＰＣ：Evolved Packet Core）１３０を含み得る。Ｅ－ＵＴＲＡＮ１２０およびＥＰＣ１３０は、ＵＥ１０２のためのサービングネットワークでありＵＥ１０２のためのホーム公衆陸上移動網（ＨＰＬＭＮ：Home Public Land Mobile Network）１４０と通信する、訪問公衆陸上移動網（ＶＰＬＭＮ：Visited Public Land Mobile Network）の一部であり得る。ＶＰＬＭＮ Ｅ－ＵＴＲＡＮ１２０、ＶＰＬＭＮ ＥＰＣ１３０、および／またはＨＰＬＭＮ１４０は、他のネットワークと相互接続し得る。例えば、インターネットは、ＨＰＬＭＮ１４０およびＶＰＬＭＮ ＥＰＣ１３０などの異なるネットワークへ、およびそれから、メッセージを運ぶために使用され得る。簡潔にするために、これらのネットワーク並びに関連するエンティティおよびインターフェースは示されていない。示されるように、ネットワークアーキテクチャ１００は、パケット交換サービスをＵＥ１０２に提供する。しかしながら、当業者が容易に理解するように、本開示全体にわたって提示される様々な概念は、回線交換サービスを提供するネットワークに拡張され得る。

【0027】

[0031] ＵＥ１０２は、狭帯域モノのインターネット（ＩｏＴ）（ＮＢ－ＩｏＴ）および／またはＬＴＥ無線アクセスのために構成される任意の電子デバイスであり得る。ＵＥ１０２は、デバイス、ワイヤレスデバイス、モバイル端末、端末、移動局（ＭＳ）、モバイルデバイス、セキュアユーザプレーンロケーション（ＳＵＰＬ：Secure User Plane Location）対応端末（ＳＥＴ：SUPL Enabled Terminal）と呼ばれることがあり、または何らかの他の名称で呼ばれることがあり、スマートウォッチ、デジタルグラス、または他の頭に装着されるディスプレイ、フィットネスモニタ、スマートカー、スマートアプライアンス、携帯電話、スマートフォン、ラップトップ、タブレット、携帯情報端末（ＰＤＡ）、パーソナルメディアプレーヤー、追跡デバイス、制御デバイス、または何らかの他のポータブルデバイスもしくは移動可能デバイスに対応する（またはそれらの一部である）ことがある。ＵＥ１０２は、単一のエンティティを備えることがあり、あるいは、ユーザがオーディオ、ビデオ、および／もしくはデータＩ／Ｏデバイス、並びに／またはボディセンサおよび別個の有線モデムもしくはワイヤレスモデムを利用し得るパーソナルエリアネットワークの中などの複数のエンティティを備えることがある。通常、必須ではないが、ＵＥ１０２は、モバイル通信用グローバルシステム（ＧＳＭ（登録商標））、符号分割多元接続（ＣＤＭＡ）、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ（登録商標））、ＬＴＥ、ＮＢ－ＩｏＴ、ＬＴＥカテゴリＭ１（ＬＴＥ－Ｍ）とも呼ばれるエンハンストマシンタイプ通信（ｅＭＴＣ：Enhanced Machine Type Communications）、第５世代（５Ｇ）ニューラジオ（ＮＲ：New Radio）、高速パケットデータ（ＨＲＰＤ：High Rate Packet Data）、ＷｉＭＡＸ（登録商標）などをサポートするワイヤレスワイドエリアネットワーク（ＷＷＡＮ）などの、１つまたは複数のタイプのＷＷＡＮとのワイヤレス通信をサポートし得る。ＶＰＬＭＮ Ｅ－ＵＴＲＡＮ１２０と組み合わされたＶＰＬＭＮ ＥＰＣ１３０、およびＨＰＬＭＮ１４０が、ＷＷＡＮの例であり得る。ＵＥ１０２はまた、ＩＥＥＥ ８０２．１１ ＷｉＦｉ（登録商標）（Ｗｉ－Ｆｉ（登録商標）とも呼ばれる）またはＢｌｕｅｔｏｏｔｈ（登録商標）（ＢＴ）をサポートするワイヤレスローカルエリアネットワーク（ＷＬＡＮ）などの、１つまたは複数のタイプのＷＬＡＮとのワイヤレス通信をサポートし得る。ＵＥ１０２はまた、デジタル加入者線（ＤＳＬ）、または例えばパケットケーブルを使用することなどによって、１つまたは複数のタイプの有線ネットワークとの通信をサポートし得る。図１は１つのＵＥ１０２だけを示すが、ＵＥ１０２に各々対応し得る多数の他のＵＥがあり得る。

【0028】

[0032] ＵＥ１０２は、Ｅ－ＵＴＲＡＮ１２０およびＥＰＣ１３０を含み得るワイヤレス通信ネットワークとの接続状態に入り得る。一例では、ＵＥ１０２は、Ｅ－ＵＴＲＡＮ１２０の中の進化型ノードＢ（ｅＮＢ）１０４などのセルラートランシーバにワイヤレス信号を送信すること、および／またはそれからワイヤレス信号を受信することによって、セルラー通信ネットワークと通信し得る。Ｅ－ＵＴＲＡＮ１２０は、１つまたは複数の追加のｅＮＢ１０６を含み得る。ｅＮＢ１０４は、ＵＥ１０２に向かってユーザプレーン（ＵＰ）プロトコル終端および制御プレーン（ＣＰ）プロトコル終端を提供する。ｅＮＢ１０４は、ＵＥ１０２のためのサービングｅＮＢであることがあり、基地局、基地トランシーバ局、無線基地局、無線トランシーバ、無線ネットワークコントローラ、トランシーバ機能、基地局サブシステム（ＢＳＳ：basic service set）、拡張サービスセット（ＥＳＳ：extended service set）、ＮＲ ＮｏｄｅＢ（ｇＮＢ）とも呼ばれることがあり、または何らかの他の適切な用語で呼ばれることもある。ＵＥ１０２はまた、アクセスポイント（ＡＰ）、フェムトセル、ホーム基地局、スモールセル基地局、ホームノードＢ（ＨＮＢ）またはホームｅＮｏｄｅＢ（ＨｅＮＢ）などのローカルトランシーバ（図１に示されない）にワイヤレス信号を送信し、またはそれからワイヤレス信号を受信でき、それらは、ＷＬＡＮ（例えば、ＩＥＥＥ ８０２．１１ネットワーク）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ、例えばＢｌｕｅｔｏｏｔｈネットワーク）、またはセルラーネットワーク（例えば、次の段落で論じられるものなどのＬＴＥネットワークまたは他のＷＷＡＮ）へのアクセスを提供し得る。もちろん、これらは、ワイヤレスリンクを介してモバイルデバイスと通信し得るネットワークの例にすぎず、特許請求される主題はこの点について限定されないことを理解されたい。

【0029】

[0033] ワイヤレス通信をサポートし得るネットワーク技術の例はＮＢ－ＩｏＴを含むが、ＧＳＭ、ＣＤＭＡ、ＷＣＤＭＡ、ＬＴＥ、ＮＲ、ＨＲＰＤ、およびｅＭＴＣ無線タイプをさらに含み得る。ＮＢ－ＩｏＴ、ＧＳＭ、ＷＣＤＭＡ、ＬＴＥ、ｅＭＴＣ、およびＮＲは、３ＧＰＰによって定義された（またはそれによって定義されつつある）技術である。ＣＤＭＡおよびＨＲＰＤは、第３世代パートナーシッププロジェクト２（３ＧＰＰ２：3rd Generation Partnership Project 2）によって定義された技術である。ｅＮＢ１０４および１０６などのセルラートランシーバは、（例えば、サービス契約の下での）サービスのためにワイヤレス電気通信ネットワークへの加入者アクセスを提供する機器の展開を備え得る。ここで、セルラートランシーバは、セルラートランシーバがアクセスサービスを提供することが可能である範囲に少なくとも一部に基づいて決定されるセル内の加入者デバイスにサービスする際にセルラー基地局の機能を行い得る。

【0030】

[0034] ｅＮＢ１０４および１０６は、ＶＰＬＭＮ ＥＰＣ１３０にインターフェース（例えば、３ＧＰＰ Ｓ１インターフェース）によって接続される。ＥＰＣ１３０は、モビリティ管理エンティティ（ＭＭＥ）１０８、およびそれを通じてデータ（例えば、インターネットプロトコル（ＩＰ）パケット）がＵＥ１０２へ、およびＵＥ１０２から転送され得るサービングゲートウェイ（ＳＧＷ）１１２を含む。ＭＭＥ１０８は、ＵＥ１０２のためのサービングＭＭＥであることがあり、そして、ＵＥ１０２とＥＰＣ１３０との間のシグナリングを処理し、ＵＥ１０２のアタッチメントおよびネットワーク接続、ＵＥ１０２のモビリティ（例えば、ネットワークセルと追跡エリア間のハンドオーバーを介した）、並びにＵＥ１０２の代わりにデータベアラを確立および解放することをサポートする、制御ノードである。ＭＭＥ１０８はまた、ＵＥ１０２のためのデータベアラの確立と解放のオーバーヘッドを避けるために、ＭＭＥ１０８をバイパスすることによってではなく、データパケットがＭＭＥ１０８を介してＵＥへ、およびＵＥから転送されるセルラーＩｏＴ（ＣＩｏＴ）制御プレーン（ＣＰ）最適化として知られている、３ＧＰＰ ＣＩｏＴ機能を使用して、ＵＥ１０２への、およびＵＥ１０２からのユーザプレーン（ＵＰ）データ転送をサポートし得る。一般に、ＭＭＥ１０８は、ＵＥ１０２のためのベアラおよび接続管理を提供し、ＶＰＬＭＮ ＥＰＣ１３０の中の、ＳＧＷ１１２、ｅＮＢ１０４および１０６、エンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）１１０、並びに訪問ゲートウェイモバイルロケーションセンター（Ｖ－ＧＭＬＣ：Visited Gateway Mobile Location Center）１１６に接続され得る。

【0031】

[0035] Ｅ－ＳＭＬＣ１１０は、３ＧＰＰ技術仕様（ＴＳ）２３．２７１および３６．３０５において定義される３ＧＰＰ制御プレーン（ＣＰ）位置特定方法を使用してＵＥ１０２の位置特定をサポートするＬＳであることがあり、ＣＰ位置特定セッションの一部としてＵＥ１０２と、ＬＰＰメッセージを交換し、および／または、オープンモバイルアライアンス（ＯＭＡ：Open Mobile Alliance）によって定義されるＬＰＰ拡張（ＬＰＰｅ）プロトコルと組み合わされるＬＰＰのためのメッセージ（ＬＰＰ／ＬＰＰｅとも呼ばれ得る）を交換し得る。単にゲートウェイモバイルロケーションセンター（ＧＭＬＣ：Gateway Mobile Location Center）とも呼ばれ得るＶ－ＧＭＬＣ１１６は、ＵＥ１０２の位置へ、外部クライアント（例えば、外部クライアント１５０）または別のネットワーク（例えば、ＨＰＬＭＮ１４０）の代わりにアクセスを提供し得る。外部クライアント１５０は、ＵＥ１０２との何らかの関連付けを有し得る（例えば、ＶＰＬＭＮ Ｅ－ＵＴＲＡＮ１２０、ＶＰＬＭＮ ＥＰＣ１３０、およびＨＰＬＭＮ１４０を介してＵＥ１０２のユーザによってアクセスされ得る）ウェブサーバまたはリモートアプリケーションであり得る。外部クライアント１５０はまた、（例えば、友人または親類の発見器、資産追跡、または子供もしくはペットの位置特定などのサービスを可能にするために）ＵＥ１０２の位置を取得して提供することを含み得る、何らかの他の１人または複数のユーザに位置特定サービスを提供する、サーバ、アプリケーション、またはコンピュータシステムであり得る。

【0032】

[0036] 示されるように、ＨＰＬＭＮ１４０は、（例えば、インターネットを介して）Ｖ－ＧＭＬＣ１１６に接続され得るホームＧＭＬＣ（Ｈ－ＧＭＬＣ）１４８、並びに、（例えば、インターネットを介して）ＳＧＷ１１２に接続され得るパケットデータネットワークゲートウェイ（ＰＤＧ）１１４を含む。ＰＤＧ１１４は、ＵＥ１０２に、インターネットプロトコル（ＩＰ）アドレス割振りと、外部ネットワーク（例えば、インターネット）および外部クライアント（例えば、外部クライアント１５０）および外部サーバへのＩＰデータアクセスおよび他のデータアクセス、並びに他のデータ転送関連の機能とを提供し得る。いくつかの場合、ＰＤＧ１１４は、ＵＥ１０２がＶＰＬＭＮ ＥＰＣ１３０からローカルのＩＰブレークアウトを受信するとき、ＶＰＬＭＮ ＥＰＣ１３０の中に位置し、ＨＰＬＭＮ１４０の中に位置しないことがある。ＰＤＧ１１４は、ホームＳＵＰＬロケーションプラットフォーム（Ｈ－ＳＬＰ）１１８などの、位置サーバ（ＬＳ）に接続され得る。Ｈ－ＳＬＰ１１８は、ＯＭＡによって定義されるＳＵＰＬ ＵＰ位置特定方法をサポートでき、Ｈ－ＳＬＰ１１８に記憶されているＵＥ１０２の契約情報に基づいてＵＥ１０２のための位置特定サービスをサポートできる。ＶＰＬＭＮ ＥＰＣ１３０の中の、またはそれからアクセス可能な、ネットワークアーキテクチャ１００のいくつかの実施形態では、発見ＳＬＰ（Ｄ－ＳＬＰ：Discovered SLP）または緊急ＳＬＰ（Ｅ－ＳＬＰ：Emergency SLP）（図１には示されない）が、ＳＵＰＬ ＵＰの方法を使用してＵＥ１０２を位置特定するために使用され得る。ネットワークアーキテクチャ１００の中のＨ－ＳＬＰ１１８およびＥ－ＳＭＬＣ１１０はともに、ＵＥ１０２の測位のためにＬＰＰおよび／またはＬＰＰ／ＬＰＰｅプロトコルを利用し得る、ＬＳの例である。

【0033】

[0037] ３ＧＰＰ ＴＳ ２３．２７１およびＴＳ ３６．３０５において定義される３ＧＰＰ ＣＰ位置特定方法などの、ＣＰ位置特定方法では、ＵＥ１０２の位置特定をサポートするためのシグナリング（例えば、ＬＰＰ、ＬＰＰ／ＬＰＰｅ、および他のメッセージを含む）は、ＶＰＬＭＮ ＥＰＣ１３０およびＥ－ＵＴＲＡＮ１２０のための既存のシグナリングインターフェースとプロトコルとを使用して、参加しているエンティティ（例えば、Ｖ－ＧＭＬＣ１１６、ＭＭＥ１０８、Ｅ－ＳＭＬＣ１１０、ｅＮＢ１０４、およびＵＥ１０２）の間で転送され得る。対照的に、ＳＵＰＬなどのＵＰ位置特定方法では、ＵＥ１０２の位置特定をサポートするためのシグナリング（例えば、埋め込まれたＬＰＰおよび／またはＬＰＰ／ＬＰＰｅメッセージを搬送するＳＵＰＬメッセージなど）は、データベアラを使用して（例えば、インターネットプロトコル（ＩＰ）を使用して）参加しているエンティティ（例えば、ＵＥ１０２およびＨ－ＳＬＰ１１８）の間で転送され得る。

【0034】

[0038] Ｈ－ＧＭＬＣ１４８は、ＵＥ１０２のためのホーム加入者サーバ（ＨＳＳ）１４５に接続されることがあり、これは、ＵＥ１０２のためのユーザ関連情報および加入者関連情報を含む中央データベースである。Ｈ－ＧＭＬＣ１４８は、外部クライアント１５０などの外部クライアントの代わりにＵＥ１０２への位置アクセスを提供し得る。Ｈ－ＧＭＬＣ１４８、ＰＤＧ１１４、およびＨ－ＳＬＰ１１８のうちの１つまたは複数は、例えばインターネットなどの別のネットワークを通じて、外部クライアント１５０に接続され得る。いくつかの場合、別のＰＬＭＮ（図１には示されない）の中に位置する要求ＧＭＬＣ（Ｒ－ＧＭＬＣ：Requesting GMLC）が、Ｒ－ＧＭＬＣに接続される外部クライアントの代わりにＵＥ１０２への位置アクセスを提供するために、Ｈ－ＧＭＬＣ１４８に（例えば、インターネットを介して）接続され得る。Ｒ－ＧＭＬＣ、Ｈ－ＧＭＬＣ１４８、およびＶ－ＧＭＬＣ１１６は、３ＧＰＰ ＴＳ ２３．２７１において定義される３ＧＰＰ ＣＰの解決法を使用したＵＥ１０２への位置アクセスをサポートし得る。

【0035】

[0039] ＶＰＬＭＮ（ＶＰＬＭＮ Ｅ－ＵＴＲＡＮ１２０およびＶＰＬＭＮ ＥＰＣ１３０を備える）および別個のＨＰＬＭＮ１４０が図１に示されているが、両方のＰＬＭＮ（ネットワーク）が同じＰＬＭＮであり得ることを理解されたい。その場合、（ｉ）Ｈ－ＳＬＰ１１８、ＰＤＧ１１４、およびＨＳＳ１４５が、ＭＭＥ１０８およびＥ－ＳＭＬＣ１１０と同じネットワーク（ＥＰＣ）の中にあることがあり、（ｉｉ）Ｖ－ＧＭＬＣ１１６およびＨ－ＧＭＬＣ１４８が、同じＧＭＬＣであることがある。

【0036】

[0040] 特定の実現形態では、ＵＥ１０２は、全地球航法衛星システム（ＧＮＳＳ）または他の衛星測位システム（ＳＰＳ）宇宙船（ＳＶ）１６０から受信される信号の測定結果、ｅＮＢ１０４および１０６などのセルラートランシーバから受信される信号の測定結果、並びに／またはローカルトランシーバから受信される信号の測定結果などの、位置関連の測定結果（位置測定結果とも呼ばれる）を取得することが可能な、回路および処理リソースを有し得る。ＵＥ１０２はさらに、これらの位置関連の測定結果に基づいて、ＵＥ１０２の位置決定または推定される位置を計算することが可能な、回路および処理リソースを有し得る。いくつかの実現形態では、ＵＥ１０２によって取得される位置関連の測定結果は、Ｅ－ＳＭＬＣ１１０またはＨ－ＳＬＰ１１８などのＬＳに転送されることがあり、その後で、ＬＳが測定結果に基づいてＵＥ１０２の位置を推定または決定することがある。

【0037】

[0041] ＵＥ１０２によって取得された位置関連の測定結果は、ＧＰＳ、ＧＬＯＮＡＳＳ、ガリレオ、もしくは北斗などの、ＳＰＳまたは全地球航法衛星システム（ＧＮＳＳ）に属するＳＶ１６０から受信された信号の測定結果を含むことがあり、並びに／あるいは、既知の位置に固定された地上波送信機（例えば、ｅＮＢ１０４、ｅＮＢ１０６、または他のローカルトランシーバなど）から受信された信号の測定結果を含むことがある。次いで、ＵＥ１０２または別個のＬＳ（例えば、Ｅ－ＳＭＬＣ１１０またはＨ－ＳＬＰ１１８）は、例えば、ＧＮＳＳ、補助ＧＮＳＳ（Ａ－ＧＮＳＳ：Assisted GNSS）、アドバンスト順方向リンク三角測量（ＡＦＬＴ：Advanced Forward Link Trilateration）、観測到着時間差（ＯＴＤＯＡ：Observed Time Difference Of Arrival）、もしくは拡張セルＩＤ（ＥＣＩＤ：Enhanced Cell ID）、ＷＬＡＮ（ＷｉＦｉとも呼ばれる）、またはそれらの組合せなどの、いくつかの測位方法のうちのいずれか１つを使用して、これらの位置関連の測定結果に基づいて、ＵＥ１０２のための位置推定を取得し得る。これらの技法（例えば、Ａ－ＧＮＳＳ、ＡＦＬＴ、およびＯＴＤＯＡ）のうちのいくつかでは、擬似距離またはタイミング差が、ＵＥ１０２によって、既知の位置に固定された３つ以上の地上波送信機に対して、もしくは軌道データが正確に知られている４つ以上のＳＶ１６０、またはそれらの組合せに対して相対的に、パイロット信号、ナビゲーション信号、測位基準信号（ＰＲＳ）、または送信機もしくはＳＶ１６０によって送信され、ＵＥ１０２において受信された他の測位関連の信号に少なくとも一部基づいて、測定され得る。ここで、Ｅ－ＳＭＬＣ１１０またはＨ－ＳＬＰ１１８などのＬＳは、Ａ－ＧＮＳＳ、ＡＦＬＴ、ＯＴＤＯＡ、ＥＣＩＤ、およびＷＬＡＮなどの測位技法を容易にするために、例えば、ＵＥ１０２によって測定されるべき信号に関する情報（例えば、予想される信号タイミング、信号コーディング、信号周波数、信号ドップラー）、地上送信機および／もしくは関連するセルアンテナの位置および／または識別情報、並びに／あるいは、ＧＮＳＳ ＳＶ１６０の信号、タイミング情報および軌道情報を含む、測位支援データ（ＡＤ）をＵＥ１０２に提供することが可能であり得る。この容易化は、ＵＥ１０２による信号取得および測定の正確さを改善すること、および／または、いくつかの場合、ＵＥ１０２が位置測定結果に基づいて推定される位置を計算することを可能にすることを含み得る。例えば、ＬＳは、セルラートランシーバおよび送信機（例えば、ｅＮＢ１０４および１０６）の位置および識別情報、並びに／または、特定の場所などのある特定の１つまたは複数の領域の中のローカルトランシーバおよび送信機を示すアルマナック（例えば、基地局アルマナック（ＢＳＡ））を備えることがあり、信号電力、信号タイミング、信号帯域幅、信号コーディング、および／または信号周波数などの、これらのトランシーバおよび送信機によって送信される信号を記述する情報をさらに含むことがある。

【0038】

[0042] ＥＣＩＤの場合、ＵＥ１０２は、セルラートランシーバ（例えば、ｅＮＢ１０４および１０６）および／もしくはローカルトランシーバから受信される信号の信号強度の測定結果（例えば、受信信号強度指示（ＲＳＳＩ）または基準信号受信電力（ＲＳＲＰ））を取得でき、並びに／または、信号対雑音比（Ｓ／Ｎ）、基準信号受信品質（ＲＳＲＱ）、および／もしくは、ＵＥ１０２とセルラートランシーバ（例えば、ｅＮＢ１０４または１０６）もしくはローカルトランシーバとの間の往復信号伝播時間（ＲＴＴ：Round Trip signal propagation Time）を取得できる。ＵＥ１０２は、ＵＥ１０２の位置を決定するためにこれらの測定結果をＬＳ（例えば、Ｅ－ＳＭＬＣ１１０またはＨ－ＳＬＰ１１８）に転送でき、または、いくつかの実現形態では、ＵＥ１０２は、ＥＣＩＤを使用してＵＥ１０２の位置を決定するために、ＬＳまたはセルラートランシーバ（例えば、ｅＮＢ１０４）から受信される支援データ（例えば、地上アルマナックデータ）と一緒にこれらの測定結果を使用できる。

【0039】

[0043] ＯＴＤＯＡの場合、ＵＥ１０２は、近くのトランシーバまたは基地局（例えば、ｅＮＢ１０４および１０６）から受信される、測位基準信号（ＰＲＳ）および／またはセル固有基準信号（ＣＲＳ）などの信号間で、基準信号時間差（ＲＳＴＤ）を測定し得る。ＲＳＴＤ測定結果は、２つの異なるトランシーバからＵＥ１０２において受信される信号（例えば、ＣＲＳまたはＰＲＳ）間の到達時間差（例えば、ｅＮＢ１０４から受信される信号とｅＮＢ１０６から受信される信号との間のＲＳＴＤ）を提供し得る。ＵＥ１０２は、測定されたＲＳＴＤをＬＳ（例えば、Ｅ－ＳＭＬＣ１１０またはＨ－ＳＬＰ１１８）に返すことができ、ＬＳは、測定されたトランシーバの既知の位置および既知の信号タイミングに基づいて、ＵＥ１０２の推定される位置を計算できる。ＯＴＤＯＡのいくつかの実現形態では、ＲＳＴＤ測定のために使用される信号（例えば、ＰＲＳまたはＣＲＳ信号）は、全地球測位システム（ＧＰＳ）時間または協定世界時（ＵＴＣ）などの一般的な世界時間へと、例えば、一般的な世界時間を正確に取得するために各トランシーバまたは送信機においてＧＰＳ受信機を使用して、トランシーバまたは送信機によって正確に同期され得る。

【0040】

[0044] Ａ－ＧＮＳＳの場合、ＵＥ１０２は、１つまたは複数のＧＮＳＳのためのもう１つのＳＶ１６０に対する、ドップラー、擬似距離、符号位相、および／またはキャリア位相の測定結果を取得し得る。ＷＬＡＮ測位の場合、ＵＥ１０２は、１つまたは複数の見えているＷｉＦｉ ＡＰの識別情報、並びに、場合によっては、ＲＳＳＩおよび／またはＲＴＴの測定結果などの、見えているＷｉＦｉ ＡＰから送信されるビーコンフレームおよび／または他の信号に対する測定結果を取得し得る。ＥＣＩＤおよびＯＴＤＯＡについて上で説明されたように、これらの測定結果は、ＵＥ１０２の位置を計算するためにＬＳ（例えば、Ｅ－ＳＭＬＣ１１０またはＨ－ＳＬＰ１１８）に転送されることがあり、または、ＵＥ１０２は、ＬＳから、セルラートランシーバから、または送信機自体から（例えば、ＳＶ１６０から）受信されるＡＤ（例えば、ＳＶ１６０またはＷＬＡＮ ＡＰのためのＡＤ）に基づいて、位置自体を計算することがある。いくつかの実現形態では、２つ以上の測位方法の混種の組合せが、ＵＥ１０２の位置を取得するためにＬＳおよびＵＥ１０２によって使用され得る。

【0041】

[0045] 上で説明されたような、Ａ－ＧＮＳＳ、ＯＴＤＯＡ、ＡＦＬＴ、ＥＣＩＤ、およびＷＬＡＮなどの測位方法は、地上送信機（例えば、ｅＮＢ１０４および１０６）および／またはＳＰＳ ＳＶ（例えば、ＳＶ１６０）から送信されるダウンリンク信号のＵＥによる測定に基づいてＵＥ１０２などのＵＥによってサポートされるので、ダウンリンク（ＤＬ）測位方法と呼ばれ得る。対照的に、アップリンク（ＵＬ）測位方法を用いて、ネットワーク側のエンティティ（例えば、ｅＮＢ１０４およびｅＮＢ１０６）は、ＵＥの位置推定を取得するために、ＵＥ（例えば、ＵＥ１０２）によって送信されるアップリンク信号を測定し得る。次いで、ＵＥの位置をＬＳが決定することを可能にするために、ＵＬ測位方法の測定結果が、ＴＳ ３５．４５５において３ＧＰＰによって定義されるＬＰＰアネックス（ＬＰＰａ）プロトコルを使用してＬＳ（例えば、Ｅ－ＳＭＬＣ１１０）に転送され得る。

【0042】

[0046] ＵＥ１０２の位置の推定は、位置、位置推定、位置決定、決定、場所、場所推定、または場所決定と呼ばれることがあり、測地学により決定されることがあるので、高度成分（例えば、海水面からの高さ、地表からの高さまたは深さ、床面の高さまたは地下室の深さ）を含むことも含まないこともある、ＵＥ１０２の位置座標（例えば、緯度および経度）を提供する。代わりに、ＵＥ１０２の位置は、都市の位置として（例えば、郵便住所、または何らかの地点の指定、または特定の部屋もしくは階などの建物の中の小さいエリアとして）表され得る。ＵＥ１０２の位置は不確実性も含むことがあり、そうすると、何らかの所与のまたはデフォルトの確率もしくは信頼性レベル（例えば、６７％または９５％）でＵＥ１０２がその内部に位置することが予想される（地理的にまたは都市形態で定義される）エリアまたはボリュームとして表されることがある。ＵＥ１０２の位置はさらに、絶対位置（例えば、緯度、経度、および場合によっては高度、並びに／または不確実さに関して定義される）であることがあり、または、例えば、既知の絶対位置にある何らかの原点に対して相対的に定義される距離および方向、または相対的なＸ、Ｙ（およびＺ）座標を備える、相対的な位置であることがある。本明細書に含まれる説明では、位置という用語の使用は、別段に指示されない限り、これらの変形のいずれかを備え得る。ＵＥ１０２の位置推定を決定する（例えば、計算する）ために使用される測定結果（例えば、ＵＥ１０２によって取得される、またはｅＮＢ１０４などの別のエンティティによって取得される）は、測定結果、位置測定結果、位置関連の測定結果、測位測定結果、または場所測定結果と呼ばれることがあり、ＵＥ１０２の位置を決定するアクションは、ＵＥ１０２の測位またはＵＥ１０２の位置特定と呼ばれることがある。

【0043】

[0047] ダウンリンク測位方法では、および場合によっては一部のアップリンク測位方法では、ＵＥ１０２およびＬＳ（例えば、Ｅ－ＳＭＬＣ１１０および場合によってはＨ－ＳＬＰ１１８）が、ＬＰＰのためのメッセージなどの測位プロトコルメッセージを交換する必要があり得る。しかしながら、ＵＥ１０２とＬＳとの間でＬＰＰメッセージを搬送するために使用されるトランスポートプロトコルは、一部のＬＰＰメッセージが超える可能性があるサイズの制約を課すことがある。例えば、ＵＥ１０２とｅＮＢ１０４との間でメッセージ（例えば、ＬＰＰメッセージ）を搬送するために使用されるＰＤＣＰプロトコルは、ＵＥ１０２によるＬＴＥアクセスの場合は８１８８オクテット、およびＵＥ１０２によるＮＢ－ＩｏＴアクセスの場合は１６００オクテットという全体的な制限を（例えば、ＰＤＣＰ上のプロトコルのために）課すことがある。しかし、現在のＬＰＰ規格のもとでは、この制限が超越されることがある。例えば、ＬＰＰ支援データ（ＡＤ）要求メッセージをＥ－ＳＭＬＣ１１０に送信するとき、例えば、３ＧＰＰリリース１４におけるＬＰＰプロトコルは、ＵＥ１０２が、（ＵＥ１０２がすでにそのためのＡＤを有するＡＰに対する）最大で２０４８個のＷＬＡＮアクセスポイント（ＡＰ）アドレスを含むことを許容し、そのＷＬＡＮ ＡＰアドレスは各々が６オクテットのアドレスを使用して特定される。このことは、アドレス単独で１２２８８オクテットをもたらし、これはＵＥ１０２とｅＮＢ１０４との間でＬＰＰメッセージを中継するために使用されるＰＤＣＰプロトコルの最大のメッセージサイズの制限を大きく超える。別の例では、２４個の近隣セルのためのＯＴＤＯＡ支援データを提供するためにＬＳによってＵＥ１０２に送信されるＬＰＰ支援データ提供メッセージは、サイズが最大で３７００オクテット前後であることがあり、これは、ＮＢ－ＩｏＴに対するＰＤＣＰの制限を超える。従って、前に示されたように、本明細書で提供される技法は、ＵＥ１０２および／またはＬＳ（例えば、Ｅ－ＳＭＬＣ１１０またはＨ－ＳＬＰ１１８）が、ＬＰＰメッセージをセグメント化し、セグメント化されたＬＰＰメッセージを送信および／または受信するための能力を示すことを可能にする。

【0044】

[0048] 図１に示されるネットワークアーキテクチャ１００は、ＬＴＥまたはＮＢ－ＩｏＴを使用して、ＶＰＬＭＮ Ｅ－ＵＴＲＡＮ１２０およびＶＰＬＭＮ ＥＰＣ１３０へのワイヤレスアクセスをＵＥ１０２に適用し得る。しかしながら、ＵＥ１０２が他のタイプの無線アクセスネットワーク（ＲＡＮ）および／または他のタイプのコアネットワークにアクセスするような、他の同様のネットワークアーキテクチャが存在し得る。例えば、ＵＥ１０２がＮＲ無線アクセス技術（ＲＡＴ）を使用するとき、ＵＥ１０２は、ネットワークアーキテクチャ１００におけるＥ－ＵＴＲＡＮ１２０およびＥＰＣ１３０をそれぞれ置き換え得る次世代無線アクセスネットワーク（ＮＧ－ＲＡＮ）および５Ｇコアネットワーク（５ＧＣＮ）にアクセスし得る。この場合、図１に示されるＥＰＣ１３０のための一部のネットワーク要素が異なり得る。例えば、ＭＭＥ１０８は、アクセスおよびモビリティ管理機能（ＡＭＦ）によって置き換えられることがあり、Ｅ－ＳＭＬＣ１１０は、位置管理機能（ＬＭＦ）などのＮＲワイヤレスアクセスのためのＣＰ位置特定方法をサポートするＬＳによって置き換えられることがある。以下の様々な技法の説明では、従って、ＵＥ１０８がＮＢ－ＩｏＴまたはＬＴＥ ＲＡＴアクセスではなくＮＲ ＲＡＴアクセスを有する例では、ＭＭＥ１０８の代わりにＡＭＦを用い、Ｅ－ＳＭＬＣ１１０の代わりにＬＭＦを用いることが可能であり得る。同様に、ＬＰＰｅなどのＬＰＰからの、または、ＮＲ無線アクセスを伴うＵＥ１０２のためのＮＲ測位プロトコル（ＮＰＰ）からの、他の測位プロトコルが使用され得る。従って、ＬＰＰメッセージのセグメント化をサポートするために本明細書で提供される技法も、ＬＰＰｅまたはＮＰＰなどの他の測位プロトコルのためのメッセージをセグメント化することに適用可能であり得る。

【0045】

[0049] 図２は、ＬＰＰメッセージのセグメント化が使用される、端点Ａ２１０と端点Ｂ２２０との間での位置特定セッションまたは位置特定セッションの一部のシグナリングフロー２００の図である。端点Ａ２１０または端点Ｂ２２０のいずれか１つがネットワークアーキテクチャ１００の中のＵＥ１０２に対応することがあり、端点Ａ２１０または端点Ｂ２２０の他方がネットワークアーキテクチャ１００の中のＥ－ＳＭＬＣ１１０に対応する。シグナリングフロー２００は、ＬＰＰを使用したＵＥ１０２とＥ－ＳＭＬＣ１１０との間の位置特定セッションに適用されるものとして説明されるが、本明細書の他の箇所で説明されるように、シグナリングフロー２００は、他のエンティティ（例えば、ＵＥ１０２およびＬＭＦまたはＵＥ１０２およびＨ－ＳＬＰ１１８）および／または他の測位プロトコル（例えば、ＬＰＰ／ＬＰＰｅまたはＮＰＰ）に適用され得る。図２に示されるように、以下で説明されるアクション２３０、２４０－ａ、２４０－ｂ、および２５０において転送されるＬＰＰメッセージは、非アクセス層プロトコル（ＮＡＳ：Non-Access Stratum Protocol）プロトコル、Ｓ１アプリケーションプロトコル（Ｓ１ＡＰ）、位置特定サービス（ＬＣＳ）アプリケーションプロトコル（ＬＣＳ－ＡＰ）、無線リソース制御（ＲＲＣ）プロトコル、およびＰＤＣＰプロトコルなどの、トランスポートプロトコルを使用して、ＭＭＥ１０８およびｅＮＢ１０４などの中間エンティティ（図２に示されない）を介して、Ｅ－ＳＭＬＣ１１０とＵＥ１０２との間で転送され得る。代わりに、シグナリングフロー２００がＳＵＰＬ（例えば、端点Ａ２１０または端点Ｂ２２０のうちの１つがＥ－ＳＭＬＣ１１０ではなくＨ－ＳＬＰ１１８に対応する）に適用されるとき、下で説明されるＬＰＰメッセージの各々は、ＳＵＰＬ ＰＯＳメッセージなどのＳＵＰＬメッセージの内部に埋め込まれることがあり、ＰＤＧ１１４、ＳＧＷ１１２、およびｅＮＢ１０４を介してＵＥ１０２とＨ－ＳＬＰ１１８との間で転送されることがある。

【0046】

[0050] シグナリングフロー２００はブロック２２５において開始でき、ブロック２２５において、端点Ａ２１０は、単一のＬＰＰメッセージの転送のためのより低次のレイヤのトランスポートプロトコルによって許容される最大のサイズ閾値を超えるＬＰＰメッセージを端点Ｂ２２０に転送する必要があり得る。端点Ａ２１０は次いで、見込まれるＬＰＰメッセージの情報の内容を、元の見込まれるＬＰＰメッセージと同じＬＰＰメッセージタイプおよび同じＬＰＰトランザクション識別子（ＩＤ）（ＩＤ「ｊ」と図２に示される）を使用する各々良く形成されたＬＰＰメッセージであり得る２つ以上のＬＰＰメッセージセグメントへと分割することによって、ブロック２２５においてＬＰＰメッセージをセグメント化し得る。ブロック２２５におけるセグメント化は、いくつかの実施形態における見込まれるＬＰＰメッセージの情報の内容についてのものにすぎないことがあり、見込まれるＬＰＰメッセージ自体が、作成もセグメント化もされないことがある。端点Ａ２１０は、各ＬＰＰメッセージセグメントに、「ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールド」とここで呼ばれる新しいＬＰＰパラメータを含め得る。端点Ａ２１０は、ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを使用して、各ＬＰＰメッセージセグメントが最後のＬＰＰメッセージセグメントであるかどうか、またはより多くのＬＰＰメッセージセグメントが向かってきているかどうかを示し得る。セグメント化の必要をなくすためのＬＰＰメッセージの内容の削減ではなく、端点Ａ２１０によりブロック２２５においてセグメント化を使用するという決定は、図３に関連して下でさらに説明される端点Ｂ２２０のＬＰＰセグメント化能力の端点Ａ２１０による知識に基づき得る。

【0047】

[0051] ブロック２２５に対する最大のサイズ閾値は、端点Ａ２１０と端点Ｂ２２０との間のＬＰＰメッセージの搬送において使用される全ての送信リンクに対する、最小の最大メッセージサイズ制限に基づくことがあり、そのような情報が最大メッセージサイズ制限に含まれる場合、任意のトランスポートプロトコルによってメッセージに続いて添付される任意の追加の情報を補償するために調整されることがあることに留意されたい。以前に言及されたように、端点Ａ２１０から端点Ｂ２２０に送信されるべき見込まれるＬＰＰメッセージは、ブロック２２５におけるセグメント化の前に端点Ａ２１０によって実際に作成されることもされないこともあることに留意されたい。ブロック２２５のいくつかの事例では、例えば、見込まれるＬＰＰメッセージに含まれることが意図される情報の少なくとも一部分が最大のサイズ閾値を超えるであろうと決定されると、ＬＰＰメッセージセグメントが作成され得る。

【0048】

[0052] アクション２３０において、端点Ａ２１０は、第１のＬＰＰメッセージセグメントを端点Ｂ２２０に送信し、それがセグメント化されたＬＰＰメッセージの一部であること、および、ＬＰＰメッセージの内容全体を配信するためにさらなる追加のＬＰＰメッセージセグメントのうちの１つが続いて転送されるであろうことを示すために、「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」に設定されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含める。セグメント化の使用、およびより多くのＬＰＰメッセージセグメントが向かってきていることを認識することにより、端点Ｂ２２０は、アクション２３０に続いて受信したときに第１のＬＰＰメッセージセグメントを記憶し得る。

【0049】

[0053] アクション２４０－ａおよび２４０－ｂにおいて、端点Ａ２１０は、追加のＬＰＰメッセージセグメント（例えば、第２の、第３の、および場合によってはさらなるセグメント）を端点Ｂ２２０に送信でき、各セグメントが依然としてアクション２３０において開始されたセグメント化されたＬＰＰメッセージの一部であること、および、ＬＰＰメッセージの内容全体を配信するためにさらなる追加のＬＰＰメッセージセグメントのうちの１つが続いて転送されるであろうことを示すために、各ＬＰＰメッセージセグメントに「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」に設定されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含める。シグナリングフロー２００のいくつかの例では、アクション２４０－ｂは（例えば、２つまたは３つのセグメントを備えるＬＰＰメッセージに対して）行われないことがあり、いくつかの事例では、アクション２４０－ａは（例えば、２つのセグメントを備えるＬＰＰメッセージに対して）行われないことがある。シグナリングフロー２００の他の例では、２４０－ａおよび２４０－ｂに対する追加のアクションが、（例えば、４つより多くのセグメントを備えるＬＰＰメッセージに対して）追加のＬＰＰメッセージセグメントを転送するために行われることがある。セグメント化の使用、およびより多くのＬＰＰメッセージセグメントが向かってきていることを認識することにより、端点Ｂ２２０は、アクション２４０－ａおよび２４０－ｂに対して（および任意の追加の同様のアクションに対して）受信されるとき、追加のＬＰＰメッセージセグメントを記憶し得る。

【0050】

[0054] アクション２５０において、端点Ａ２１０は、端点Ｂ２２０に最後のＬＰＰメッセージセグメントを送信し、これが最後のＬＰＰメッセージセグメントであることを示すために、「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」に設定されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含める。

【0051】

[0055] ブロック２６０において、アクション２５０におけるさらなるメッセージなしの指示を認めたことにより、端点Ｂ２２０は、完全なＬＰＰメッセージが受信されたと見なすことができ、元のメッセージ内容を再び組み立てることができる（例えば、アクション２３０、２４０－ａ、および２４０－ｂのために受信され記憶されたＬＰＰメッセージセグメント、並びに、アクション２５０において受信されたＬＰＰメッセージセグメントの各々を復号し、復号されたＬＰＰメッセージセグメントの各々の情報の内容を抽出して組み合わせることによって）。

【0052】

[0056] シグナリングフロー２００の一部として、端点Ａ２１０および端点Ｂ２２０は、３ＧＰＰ ＴＳ ３６．３５５において規定されるＬＰＰのための信頼性のある搬送規則を、アクション２３０、２４０－ａ、２４０－ｂ、および２５０において転送される各々の個別のＬＰＰメッセージセグメントに、ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドの値とは独立に適用できる。例えば、アクション２３０、２４０－ａ、２４０－ｂ、および２５０において転送されるＬＰＰメッセージセグメントのうちの任意の１つまたは複数は、（ｉ）別々のＬＰＰシーケンス番号を含むことがあり、（ｉｉ）端点Ａ２１０による次のＬＰＰメッセージセグメントの転送の前に端点Ｂ２２０によって送信され得るＬＰＰ肯定応答を端点Ｂ２２０から要求することがあり、（ｉｉｉ）ＬＰＰ肯定応答がＬＰＰメッセージセグメントにおいて端点Ａ２１０によって要求されるときに、ＬＰＰ肯定応答が端点Ｂ２２０から端点Ａ２１０によって受信されない場合、端点Ａ２１０によって再送信されることがある。端点Ａ２１０および端点Ｂ２２０はまた、ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドの値とは独立に、３ＧＰＰ ＴＳ ３６．３５５において規定されるようなＬＰＰメッセージの共通フィールドを各々の個別のＬＰＰメッセージセグメントへと設定するための規則を利用し得る。これらの共通フィールドは、トランザクションＩＤ、トランザクション終了フラグ、シーケンス番号、および肯定応答を備え得る。

【0053】

[0057] 図３は、一実施形態による、どのようにメッセージセグメント化能力が通信され得るかの例を示す、ＬＰＰメッセージがセグメント化され得るときの、ＵＥ１０２とＥ－ＳＭＬＣ１１０との間の位置特定セッションのためのシグナリングフロー３００の図である。しかしながら、実施形態はそのように限定されないことが理解されるであろう。例えば、ＬＰＰメッセージセグメント化能力および／またはＬＰＰメッセージセグメント化は、他の状況または実施形態では異なるＬＰＰメッセージに適用され得る。図３に示されるように、以下で説明されるアクション３１５、３２０、３３０、３４０、３４５、および３５５において転送されるＬＰＰメッセージは、非アクセス層プロトコル（ＮＡＳ）、Ｓ１アプリケーションプロトコル（Ｓ１ＡＰ）、位置特定サービス（ＬＣＳ）アプリケーションプロトコル（ＬＣＳ－ＡＰ）、無線リソース制御（ＲＲＣ）プロトコル、およびＰＤＣＰプロトコルなどの、トランスポートプロトコルを使用して、ＭＭＥ１０８およびｅＮＢ１０４などの中間エンティティを介して、Ｅ－ＳＭＬＣ１１０とＵＥ１０２との間で転送され得る。代わりに、ＳＵＰＬが使用されるとき（例えば、シグナリングフロー３００の中のＥ－ＳＭＬＣ１１０がＨ－ＳＬＰ１１８によって置き換えられた状態で）、下で説明されるＬＰＰメッセージの各々が、ＳＵＰＬ ＰＯＳメッセージなどのＳＵＰＬメッセージの内部に埋め込まれ、ＳＵＰＬに適切なエンティティおよびプロトコル（例えば、ＰＤＧ１１４、ＳＧＷ１１２、およびｅＮＢ１０４など）を介して中継され得る。

【0054】

[0058] シグナリングフロー３００はブロック３１０において開始することがあり、ここで、Ｅ－ＳＭＬＣ１１０がＵＥ１０２に対する位置特定要求を受信する。当業者が諒解するように、位置特定要求は、様々な方法のいずれかで受信され得る。例えば、ＵＥ１０２は、Ｅ－ＳＭＬＣ１１０との位置特定セッションを促し得るメッセージをＥ－ＳＭＬＣ１１０に送信し得る。このメッセージはＵＥ１０２によって実行されるアプリケーション（例えば、ナビゲーションアプリケーション）によって惹起されることがあり、このことが、１０２の位置推定を要求することがある。他のシナリオでは、位置特定要求は、１つまたは複数の他のエンティティ（例えば、Ｖ－ＧＭＬＣ１１６、Ｈ－ＧＭＬＣ１４８、ＭＭＥ１０８）を介してＭＭＥ１０８または外部クライアント（例えば、外部クライアント１５０）から受信され得る。

【0055】

[0059] Ｅ－ＳＭＬＣ１１０は次いで、位置特定セッションの一部として、アクション３１５においてＬＰＰ能力要求メッセージをＵＥ１０２に送信でき、アクション３１５において、Ｅ－ＳＭＬＣ１１０は、ＵＥ１０２によってサポートされる測位方法を含むＵＥ１０２の測位能力と、各々のサポートされる測位方法に対して、ＵＥ１０２が使用または提供することが可能であるＡＤのタイプおよび位置情報（ＬＩ）のタイプの指示とを含む。いくつかの実施形態によれば、例えば図２において端点Ｂ２２０について例示されるように、Ｅ－ＳＭＬＣ１１０がＵＥ１０２からセグメント化されたＬＰＰメッセージを受信可能であるかどうかを示すために、フラグがＥ－ＳＭＬＣ１１０によってＬＰＰ能力要求メッセージに含められ得る。いくつかの実施形態では、例えば図２において端点Ａ２１０について例示されるように、Ｅ－ＳＭＬＣ１１０がＵＥ１０２にセグメント化されたＬＰＰメッセージを送信することが可能であるかどうかを示すために、追加のまたは代替のフラグがＥ－ＳＭＬＣ１１０によって含められ得る。例えば、各フラグは単一のビットを備えることがあり、「１」の値はＥ－ＳＭＬＣ１１０が関連する能力を有することを示し、「０」の値はＥ－ＳＭＬＣ１１０が関連する能力を有しないことを示す。これらのフラグの一方または両方の存在は、Ｅ－ＳＭＬＣ１１０がＵＥ１０２のＬＰＰセグメント化能力を要求していることも示し得る。

【0056】

[0060] それに応答して、ＵＥ１０２は、アクション３２０におけるＬＰＰ能力提供メッセージをＥ－ＳＭＬＣ１１０に送信し、例えば、ＵＥ１０２によってサポートされる測位方法と、各々のサポートされる測位方法に対する、ＵＥ１０２が使用もしくは提供することが可能であるＡＤのタイプおよび／またはＬＩのタイプの指示とを含む、ＵＥ１０２のＬＰＰ測位能力をＥ－ＳＭＬＣ１１０に提供する。

【0057】

[0061] ＵＥ１０２はまた、ＵＥ１０２がＬＰＰメッセージをセグメント化することが可能であることの指示を、アクション３２０において送信されるＬＰＰ能力提供メッセージに含めることができる。例えば、ＵＥ１０２は、上で説明されたようにアクション３１５においてＬＰＰメッセージセグメント化に対するＥ－ＳＭＬＣ１１０のサポートの指示を受信したことに応答して、その指示を含めることができる。いくつかの実施形態では、例えば、新しいフラグがＵＥ１０２によってＬＰＰ能力提供メッセージに追加されることがあり、このことは、図２の端点Ａ２１０について例示されたように、ＵＥ１０２がＬＰＰメッセージをセグメント化してセグメント化されたＬＰＰメッセージをＥ－ＳＭＬＣ１１０に送信することが可能であるかどうかを、Ｅ－ＳＭＬＣ１１０に示すことができる。例えば、図２の端点Ｂ２２０について例示されるように、ＵＥ１０２がＥ－ＳＭＬＣ１１０からセグメント化されたＬＰＰメッセージを受信可能であるかどうかを示すために、別の新しいフラグも、または別の新しいフラグが代わりに、ＵＥ１０２によって追加され得る。望まれる機能に応じて、セグメント化されたＬＰＰメッセージを受信する能力を示すためのフラグは、ＬＰＰメッセージをセグメント化するための能力を示すフラグと異なり得る。他の実施形態では、これらの能力の両方が単一のフラグによって示され得る。一例では、単一のビットを各々備える２つの別個のフラグが使用されることがあり、「１」の値はＵＥ１０２が関連する能力を有することを示し、「０」の値はＵＥ１０２が関連する能力を有しないことを示す。図３に示される例では、これらのフラグまたは能力の一方または両方が、アクション３２０において、ＬＰＰ能力提供メッセージの中でＥ－ＳＭＬＣ１１０へＵＥ１０２によって示され得る。

【0058】

[0062] アクション３２０の一例では、アクション３２０において送信されるべきＬＰＰ能力提供メッセージがより低次のレイヤのトランスポートプロトコルによって許容される最大サイズ閾値を超え、ＵＥ１０２がＥ－ＳＭＬＣ１１０に向かうＬＰＰメッセージのセグメント化をサポートし、Ｅ－ＳＭＬＣ１１０がアクション３１５においてセグメント化されたＬＰＰメッセージを受信することのサポートを示した場合、ＵＥ１０２は、図２について説明されたようにアクション３２０において、ＬＰＰ能力提供メッセージをセグメント化し、メッセージをＥ－ＳＭＬＣ１１０に転送し得る。

【0059】

[0063] アクション３２０においてＵＥ１０２のＬＰＰ測位能力を受信したことに応答して、ブロック３２５において、Ｅ－ＳＭＬＣ１１０は、（ｉ）ＵＥ１０２の位置を取得するために１つまたは複数の測位方法を使用することを決定し（例えば、アクション３２０においてＵＥ１０２によってサポートされるものとして示される１つまたは複数の測位方法）、および／または（ｉｉ）ＵＥ１０２に送信すべき適切な支援データ（例えば、ブロック３２５において決定される１つまたは複数の測位方法に対して必要な支援データおよび／またはアクション３２０においてＵＥ１０２によってサポートされるものとして示される支援データ）を決定し得る。一実施形態では、ブロック３２５における決定の少なくとも一部は、（アクション３２０において示されるような）ＬＰＰメッセージセグメント化をサポートするためのＵＥ１０２の能力、および／または、（例えば、アクション３１５において示されるような）ＬＰＰメッセージセグメント化をサポートするためのＥ－ＳＭＬＣ１１０の能力に基づき得る。例えば、ＵＥ１０２がセグメント化されたＬＰＰメッセージの受信をサポートしないことをＵＥ１０２が示す場合、Ｅ－ＳＭＬＣ１１０は、後で説明されるようにアクション３４５におけるセグメント化の必要をなくすために、ブロック３２５において決定された支援データの量を減らすことができる。逆に、ＵＥ１０２がセグメント化されたＬＰＰメッセージの受信をサポートすることをＵＥ１０２が示す場合、Ｅ－ＳＭＬＣ１１０は、ブロック３２５においてより大きな量の支援データを決定でき、後で説明されるようにアクション３４５においてＬＰＰセグメント化を利用できる。別の例では、ＵＥ１０２がセグメント化されたＬＰＰメッセージの送信または受信をサポートしないことをＵＥ１０２が示す場合、Ｅ－ＳＭＬＣ１１０は、後で説明されるようなアクション３４５における支援データのセグメント化、もしくは後で説明されるようなアクション３５５における位置情報のセグメント化を必要とするであろう、または必要とし得る、測位方法をブロック３２５において使用しないと決定し得る。逆に、ＵＥ１０２がセグメント化されたＬＰＰメッセージの送信および受信をサポートすることをＵＥ１０２が示す場合、Ｅ－ＳＭＬＣ１１０は、後で説明されるようなアクション３４５における支援データのセグメント化、もしくは後で説明されるようなアクション３５５における位置情報のセグメント化を必要とするであろう、または必要とし得る、測位方法をブロック３２５において決定し得る。

【0060】

[0064] ブロック３２５において決定された測位方法に基づいて、Ｅ－ＳＭＬＣ１１０は、アクション３３０において、ＬＰＰ位置情報要求（ＲＬＩ）メッセージをＵＥ１０２に送信する。アクション３３０において送信されるＬＰＰ ＲＬＩメッセージは、ブロック３２５において決定される１つまたは複数の測位方法を使用して、ＵＥ１０２から位置測定結果および／または位置推定を要求し得る。一実施形態では、アクション３３０における位置測定結果に対する要求は、（アクション３２０において示されるような）ＬＰＰメッセージセグメント化をサポートするためのＵＥ１０２の能力、および／または、（例えば、アクション３１５において示されるような）ＬＰＰメッセージセグメント化をサポートするためのＥ－ＳＭＬＣ１１０の能力に基づき得る。例えば、ＵＥ１０２がセグメント化されたＬＰＰメッセージの送信をサポートしないことをＵＥ１０２が示す場合、Ｅ－ＳＭＬＣ１１０は、後で説明されるようにアクション３５５におけるＵＥ１０２によるセグメント化の必要をなくすために、アクション３３０において要求される位置測定結果の数を減らすことができる。逆に、ＵＥ１０２がセグメント化されたＬＰＰメッセージの送信をサポートすることをＵＥ１０２が示す場合、Ｅ－ＳＭＬＣ１１０は、アクション３３０において要求される位置測定結果の数を増やすことができ、後で説明されるようなアクション３５５におけるＬＰＰのセグメント化を使用してより多数の位置測定結果を受信でき、このことは、ＵＥ１０２のより正確な位置特定を可能にし得る。一実施形態では、アクション３３０において送信されるＬＰＰ ＲＬＩメッセージは、例えば、ブロック３１０における位置に対する要求がＵＥ１０２の位置推定の定期的な報告または惹起された報告に対する要求を示す場合、ＵＥ１０２からの一連の２つ以上の定期的なまたは惹起された位置測定結果もしくは位置推定を要求し得る。

【0061】

[0065] アクション３３０の一例では、アクション３３０において送信されるべきＬＰＰ ＲＬＩメッセージがより低次のレイヤのトランスポートプロトコルによって許容される最大サイズ閾値を超え、Ｅ－ＳＭＬＣ１１０がＵＥ１０２に向かうＬＰＰメッセージのセグメント化をサポートし、ＵＥ１０２がアクション３２０においてセグメント化されたＬＰＰメッセージを受信することのサポートを示した場合、Ｅ－ＳＭＬＣ１１０は、図２について説明されたようにアクション３３０において、ＬＰＰ ＲＬＩメッセージをセグメント化し、メッセージをＥ－ＳＭＬＣ１１０に転送し得る。

【0062】

[0066] アクション３３０において要求される位置測定結果または位置推定をサポートするために、ＵＥ１０２は任意選択で、ＵＥ１０２がアクション３３０において要求される位置測定結果および／または位置推定を取得するのを助けるための、Ｅ－ＳＭＬＣ１１０からの支援データを要求するために、アクション３４０においてＬＰＰ支援データ要求（ＲＡＤ：Request Assistance Data）メッセージをＥ－ＳＭＬＣ１１０に送信し得る。一実施形態では、アクション３４０において要求される支援データは、（例えば、アクション３２０において示されるような）ＬＰＰメッセージセグメント化をサポートするためのＵＥ１０２の能力、および／または、（例えば、アクション３１５において示されるような）ＬＰＰメッセージセグメント化をサポートするためのＥ－ＳＭＬＣ１１０の能力に一部基づき得る。例えば、ＵＥ１０２がセグメント化されたＬＰＰメッセージの受信をサポートしない場合、または、Ｅ－ＳＭＬＣ１１０がセグメント化されたＬＰＰメッセージの送信をサポートしないことをＥ－ＳＭＬＣ１１０がアクション３２０において示す場合、ＵＥ１０２は、後で説明されるようにアクション３４５におけるセグメント化の必要をなくすために、アクション３４０において要求された支援データの量を減らすことができる。逆に、ＵＥ１０２がセグメント化されたＬＰＰメッセージの受信をサポートし、Ｅ－ＳＭＬＣ１１０がセグメント化されたＬＰＰメッセージの送信をサポートすることをＥ－ＳＭＬＣ１１０がアクション３１５において示す場合、ＵＥ１０２は、アクション３４０において要求される支援データの量を増やすことができ、支援データを受信するために後で説明されるようにアクション３４５においてＬＰＰセグメント化を利用できる。

【0063】

[0067] アクション３４０の一例では、アクション３４０において送信されるべきＬＰＰ ＲＡＤメッセージがより低次のレイヤのトランスポートプロトコルによって許容される最大サイズ閾値を超え、ＵＥ１０２がＥ－ＳＭＬＣ１１０に向かうＬＰＰメッセージのセグメント化をサポートする場合、および、Ｅ－ＳＭＬＣ１１０がアクション３１５においてセグメント化されたＬＰＰメッセージを受信することのサポートを示した場合、ＵＥ１０２は、図２について説明されたようにアクション３４０において、ＬＰＰ ＲＡＤメッセージをセグメント化し、メッセージをＥ－ＳＭＬＣ１１０に転送し得る。

【0064】

[0068] アクション３４５において、Ｅ－ＳＭＬＣ１１０は、ＬＰＰ ＡＤ提供（ＰＡＤ）メッセージをＵＥ１０２に送信し得る。ＬＰＰ ＰＡＤメッセージは、アクション３４０において送信されたＬＰＰ ＲＡＤメッセージにおいて要求されるＡＤ、および／または、ブロック３２５において決定されたＡＤの一部もしくは全てを含むことがあり、後で説明されるようにブロック３５０において、位置情報を取得するためにＵＥ１０２を支援することがある。ＬＰＰ ＰＡＤにおいて提供される情報は、ブロック３２５において決定される測位方法（例えば、Ａ－ＧＮＳＳ、ＯＴＤＯＡ、ＷＬＡＮ、ＥＣＩＤなど）に応じて、および／またはＥ－ＳＭＬＣ１１０に対して利用可能な情報に応じて変化し得る。シグナリングフロー３００の１つの変形では、アクション３４５はアクション３３０の前に起こり、アクション３４０は起こらない。

【0065】

[0069] アクション３４５の一例では、アクション３４５において送信されるべきＬＰＰ ＰＡＤメッセージがより低次のレイヤのトランスポートプロトコルによって許容される最大サイズ閾値を超え、Ｅ－ＳＭＬＣ１１０がＵＥ１０２に向かうＬＰＰメッセージのセグメント化をサポートする場合、および、ＵＥ１０２がアクション３２０においてセグメント化されたＬＰＰメッセージを受信することのサポートを示した場合、Ｅ－ＳＭＬＣ１１０は、図２について説明されたようにアクション３４５において、ＬＰＰ ＰＡＤメッセージをセグメント化し、メッセージをＥ－ＳＭＬＣ１１０に転送し得る。

【0066】

[0070] ブロック３５０－１において、ＵＥ１０２は、アクション３３０において要求される位置測定結果または位置推定を取得する。任意選択で、ＵＥ１０２は、ブロック３５０－１において位置測定結果および／または位置推定を取得するのを助けるために、アクション３４５において受信される支援データを使用し得る。

【0067】

[0071] アクション３５５－１において、ＵＥは、ブロック３５０－１において取得された位置測定結果または位置推定を含むＬＰＰ位置情報提供（ＰＬＩ）メッセージをＥ－ＳＭＬＣ１１０に返す。アクション３５５－１の一例では、アクション３５５－１において送信されるべきＬＰＰ ＰＬＩメッセージがより低次のレイヤのトランスポートプロトコルによって許容される最大サイズ閾値を超え、ＵＥ１０２がＥ－ＳＭＬＣ１１０に向かうＬＰＰメッセージのセグメント化をサポートし、Ｅ－ＳＭＬＣ１１０がアクション３１５においてセグメント化されたＬＰＰメッセージを受信することのサポートを示した場合、ＵＥ１０２は、図２について説明されたようにアクション３５５－１において、ＬＰＰ ＰＬＩメッセージをセグメント化し、メッセージをＥ－ＳＭＬＣ１１０に転送し得る。

【0068】

[0072] ブロック３６０－１において、Ｅ－ＳＭＬＣ１１０は、アクション３５５－１においてＬＰＰ ＰＬＩメッセージの中で受信された位置測定結果または位置推定を使用して、ＵＥ１０２の位置を決定（または検証）し得る。ＵＥ１０２の位置は続いて、ブロック３１０において受信される要求を発するエンティティに返され得る（図示されない）。

【0069】

[0073] シグナリングフロー３００の一実施形態では、Ｅ－ＳＭＬＣ１１０がアクション３３０においてＵＥ１０２からの定期的なまたは惹起された位置測定結果もしくは位置推定を要求する場合、ＵＥ１０２は、新しい位置測定結果または新しい位置推定を取得するために、１つまたは複数のより後の時間にブロック３５０－１を繰り返し得る。例えば、ブロック３５０－１は、定期的な位置特定の場合は固定された定期的な間隔で、または惹起された位置特定の場合はＵＥ１０２によって何らかのトリガイベントが検出されるときに（例えば、ＵＥ１０２がサービングセルを変更する、あらかじめ定められたエリアに入る、もしくはそこから出る、または、以前の位置から閾値を超える距離移動するなど）繰り返され得る。図３は、３５０－ｎと表記される、ブロック３５０－１の１つのそのような反復を示す。

【0070】

[0074] ブロック３５０－ｎにおけるブロック３５０－１の反復に続いて、ＵＥ１０２は、ブロック３５０－ｎにおいて取得された位置測定結果または位置推定を含むＬＰＰ位置情報提供（ＰＬＩ）メッセージをアクション３５５－ｎにおいてＥ－ＳＭＬＣ１１０に返す。アクション３５５-ｎの一例では、アクション３５５-ｎにおいて送信されるべきＬＰＰ ＰＬＩメッセージがより低次のレイヤのトランスポートプロトコルによって許容される最大サイズ閾値を超え、ＵＥ１０２がＥ－ＳＭＬＣ１１０に向かうＬＰＰメッセージのセグメント化をサポートし、Ｅ－ＳＭＬＣ１１０がアクション３１５においてセグメント化されたＬＰＰメッセージを受信することのサポートを示した場合、ＵＥ１０２は、図２について説明されたようにアクション３５５-ｎにおいて、ＬＰＰ ＰＬＩメッセージをセグメント化し、メッセージをＥ－ＳＭＬＣ１１０に転送し得る。

【0071】

[0075] ブロック３６０－ｎにおいて、Ｅ－ＳＭＬＣ１１０は、アクション３５５－ｎにおいてＬＰＰ ＰＬＩメッセージの中で受信される位置測定結果または位置推定を使用して、ＵＥ１０２の位置を決定（または検証）し得る。ＵＥ１０２の位置は続いて、ブロック３１０において受信される要求を発するエンティティに返され得る（図示されない）。

【0072】

[0076] ブロック３５０－１並びにアクション３５５－１および３６０－１の追加の反復は、ブロック３５０－ｎ並びにアクション３５５－ｎおよび３６０－ｎについてすぐ上で説明されたように起こり得る（図３には図示されない）。位置特定手順は、位置報告の最長の時間長または最大の数が達成されたとき、または、Ｅ－ＳＭＬＣ１１０によって取り消されたとき、終了し得る（図３には図示されない）。

【0073】

[0077] 図４は、支援データを要求してそれをＵＥ１０２に提供するためにＬＰＰメッセージセグメント化がどのように使用され得るかの例を示す、ＵＥ１０２とＥ－ＳＭＬＣ１１０との間の位置特定セッションの部分のシグナリングフロー４００の図である。例えば、シグナリングフロー４００は、ＬＰＰメッセージセグメント化が使用されるとき、シグナリングフロー３００におけるアクション３４０および３４５をサポートするために使用され得る。

【0074】

[0078] シグナリングフロー４００の中のブロック４１０において、ＵＥ１０２は、ＬＰＰ支援データ要求（ＲＡＤ）メッセージをＥ－ＳＭＬＣ１１０に送信する。この場合、ＬＰＰ ＲＡＤメッセージサイズがより低次のレイヤ（例えば、ＰＤＣＰ）によってサポートされる最大サイズ閾値を超えるであろうと想定される。その結果、ＵＥ１０２は、ＬＰＰ ＲＡＤメッセージをｎ個のＬＰＰメッセージセグメントへとセグメント化し、ここでｎは２以上に等しく、ｎ個のＬＰＰメッセージセグメントは図４のアクション４２０－１および４２０－ｎにおいてＥ－ＳＭＬＣに送信される。２より大きいｎに対して、アクション４２０－１は、第２のＬＰＰメッセージセグメントから第（ｎ－１）のＬＰＰメッセージセグメントまで繰り返される（図４には図示されない）。アクション４２０－１において送信される第１のＬＰＰメッセージセグメントに対して、および、最後の１つを除く各々の後続のＬＰＰメッセージセグメントに対して、ＬＰＰメッセージセグメントは、図２について説明されたような「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」フラグを含む。アクション４２０－ｎにおいて送信される最後のＬＰＰメッセージセグメントは、「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」フラグを含む。ブロック４１０において送信されるＬＰＰメッセージセグメントの各々はまた、図４に示されるように別個のＬＰＰシーケンス番号を含み得る。Ｅ－ＳＭＬＣ１１０は、「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」フラグが含まれることに基づいて、アクション４２０－１において送信される第１のＬＰＰメッセージセグメントと、最後の１つを除く各々の後続のＬＰＰメッセージセグメントとを記憶でき、「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」フラグが含まれることからＥ－ＳＭＬＣ１１０によって認識され得る最後のＬＰＰメッセージセグメントを受信した後で、全てのＬＰＰメッセージセグメントの内容を組み立て直すことができる。組み立て直されたＬＰＰメッセージの内容は、ＵＥ１０２によって要求されている全ての支援データについての情報を提供し得る。

【0075】

[0079] アクション４３０－１において、Ｅ－ＳＭＬＣ１１０は、ブロック４１０において要求された支援データの一部または全てを含むＬＰＰ支援データ提供（ＰＡＤ）メッセージをＵＥ１０２に返すことによって応答する。Ｅ－ＳＭＬＣ１１０は、Ｅ－ＳＭＬＣ１１０がＵＥ１０２に対して有用であり得ると考える、任意の要求されていない支援データも提供し得る。アクション４３０－ｍが起こらない場合、アクション４３０－１において送信されるＬＰＰ ＰＡＤは、ＴＲＵＥに設定されたｅｎｄＴｒａｎｓａｃｔｉｏｎパラメータを含み得る。

【0076】

[0080] アクション４３０－１において送信されるＬＰＰ ＰＡＤメッセージが、より低次のトランスポートプロトコルによって許容される最大サイズ閾値を超える場合、Ｅ－ＳＭＬＣは、ＬＰＰ ＰＡＤメッセージをセグメント化し、アクション４３０－１において第１のセグメントを送信し得る。この場合、Ｅ－ＳＭＬＣ１１０は、ブロック４１０のために使用されるのと同じ（および図２に例示されるような）セグメント化手順を利用でき、または、最後のＬＰＰメッセージセグメントを示すためのＬＰＰトランザクション終了の指示を使用したことに基づいて、より簡単なセグメント化手順を使用できる。図４はより簡単なＬＰＰセグメント化手順を示すが、図４の他の実施形態では、図２およびブロック４１０に例示されるセグメント化手順が使用され得る。より簡単なセグメント化手順を用いて、Ｅ－ＳＭＬＣ１１０は、ｅｎｄＴｒａｎｓａｃｔｉｏｎパラメータがＦＡＬＳＥに設定された状態でアクション４３０－１のように第１のＬＰＰメッセージセグメントおよび各々の後続のＬＰＰメッセージセグメントを送信し、ｅｎｄＴｒａｎｓａｃｔｉｏｎフラグがＴＲＵＥに設定された状態でアクション４３０－ｍにおいて最後の（第ｍの）ＬＰＰメッセージセグメントを送信する。アクション４３０－ｍにおけるＬＰＰトランザクションの終了の指示により、ＵＥ１０２は、全てのＬＰＰメッセージセグメントが受信されたことを知ることができ、次いで、提供された支援データを取得するために全てのＬＰＰメッセージセグメントの内容を組み立て直すことができる。

【0077】

[0081] 図５は、支援データを要求してそれをＵＥ１０２に提供するためにＬＰＰメッセージセグメント化がどのように使用され得るかの例を示す、ＵＥ１０２とＥ－ＳＭＬＣ１１０との間の位置特定セッションの部分のシグナリングフロー５００の図である。図５は、「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」フラグおよび「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」フラグがここでは、ＵＥ１０２によって要求される全ての支援データがＥ－ＳＭＬＣ１１０によっていつ配信されたかをＵＥ１０２に示すために使用されることを除き、図４と同様である。

【0078】

[0082] シグナリングフロー５００の中のブロック５１０において、ＵＥ１０２は、アクション５２０－１および５２０－ｎにおいてＬＰＰ支援データ要求（ＲＡＤ）メッセージをＥ－ＳＭＬＣ１１０に送信し、アクション５２０－１は２より大きいｎに対してｎ－２回繰り返される。ブロック５１０並びにアクション５２０－１および５２０－ｎは、図４のブロック４１０並びにアクション４１０－１および４１０－ｎに対応し得る。

【0079】

[0083] ブロック５３０において、Ｅ－ＳＭＬＣ１１０は、ブロック５１０において要求された支援データの一部または全てを含むＬＰＰ支援データ提供（ＰＡＤ）メッセージをＵＥ１０２に返すことによって応答する。アクション４３０－１および４３０－ｍに対して図４のように、Ｅ－ＳＭＬＣ１１０は、支援データをセグメント化し、ｅｎｄＴｒａｎｓａｃｔｉｏｎパラメータがＦＡＬＳＥに設定された状態でアクション５４０－１のように第１のＬＰＰメッセージセグメントおよび各々の後続のＬＰＰメッセージセグメントを送信し、ｅｎｄＴｒａｎｓａｃｔｉｏｎフラグがＴＲＵＥに設定された状態でアクション５４０－ｍにおいて最後の（第ｍの）ＬＰＰメッセージセグメントを送信する。しかしながら、図４とは異なり、Ｅ－ＳＭＬＣは、アクション５４０－１および５４０－ｍにおいて送信される各ＬＰＰメッセージセグメントに、図２について説明されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドも含める。ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドは、アクション５４０－１のｍ－１回の反復のために送信されるｍ－１個のＬＰＰメッセージセグメントに対して「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ ｔｈｅ Ｗａｙ」を示すように設定され、アクション５４０－ｍにおいて送信される最後の（第ｍの）ＬＰＰメッセージセグメントに対して「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」を示すように設定される。例えば、ブロック５３０におけるアクションは、支援データがＥ－ＳＭＬＣ１１０によって定期的にＵＥ１０２に提供され、ｅｎｄＴｒａｎｓａｃｔｉｏｎフラグがアクション５４０－ｍにおいてＦＡＬＳＥ（ＴＲＵＥではなく）に設定されるときに使用され得る。ＵＥ１０２は、アクション５４０－ｍの後に全ての支援データが受信されていると決定するために、受信されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを使用でき、例えば、位置測定結果または位置推定を取得するのを助けるために（例えば、図３について説明されたように）、受信された支援データを使用できる。

【0080】

[0084] 図６は、位置情報をＥ－ＳＭＬＣ１１０に提供するためにＬＰＰメッセージセグメント化がどのように使用され得るかの例を示す、ＵＥ１０２とＥ－ＳＭＬＣ１１０との間の位置特定セッションの部分のシグナリングフロー６００の図である。例えば、シグナリングフロー６００は、ＬＰＰメッセージセグメント化が使用されるとき、シグナリングフロー３００におけるアクション３３０、３５５－１、および３５５ーｎをサポートするために使用され得る。

【0081】

[0085] シグナリングフロー６００の中のアクション６１０において、Ｅ－ＳＭＬＣ１１０は、固定された定期的な間隔で、位置測定結果および／または位置推定をＥ－ＳＭＬＣ１１０に提供することをＵＥ１０２に要求するために、ＬＰＰ位置情報要求（ＲＬＩ）メッセージをＥ－ＳＭＬＣ１１０に送信する。

【0082】

[0086] ブロック６２０－１において、ＵＥ１０２は、アクション６１０において要求された位置測定結果および／または位置推定の一部もしくは全てを含むＬＰＰ位置情報提供（ＰＬＩ）メッセージをＥ－ＳＭＬＣ１１０に返すことによって応答する。図６において、ブロック６２０－１において送信されるべきＬＰＰ ＰＬＩメッセージが、より低次のトランスポートプロトコルによって許容される最大サイズ閾値を超えると仮定される。結果として、ＵＥ１０２がＥ－ＳＭＬＣ１１０へのＬＰＰメッセージのセグメント化をサポートすることと、Ｅ－ＳＭＬＣ１１０がＵＥ１０２から受信されたＬＰＰメッセージのセグメント化をサポートすること（例えば、図３のアクション３１５のようにＥ－ＳＭＬＣ１１０によってＵＥ１０２に送信されるＬＰＰ能力要求メッセージにおいて示されるように）とを仮定すると、ＵＥ１０２は、（例えば、図２について説明されたように）意図されたＬＰＰ ＰＬＩメッセージをｎ（ｎ≧２）個のＬＰＰ ＰＬＩメッセージセグメントへとセグメント化する。ＵＥ１０２は次いで、アクション６３０－１において第１のＬＰＰ ＰＬＩメッセージセグメントを送信し、ｎ＞２である場合にアクション６３０－１をｎ－２回繰り返すことによって第２から第ｎ－１のＬＰＰ ＰＬＩメッセージセグメントを送信し、アクション６３０－ｎにおいて最後の（第ｎの）ＬＰＰ ＰＬＩメッセージセグメントを送信する。アクション６３０－１において送信される第１のＬＰＰ ＰＬＩメッセージセグメントに対して、および、最後の１つを除く各々の後続のＬＰＰメッセージセグメントに対して、ＬＰＰ ＰＬＩメッセージセグメントは、図２について説明されたように、「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」に設定されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含む。アクション６３０－ｎにおいて送信される最後のＬＰＰ ＰＬＩメッセージセグメントは、「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」に設定されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含む。ブロック６２０－１において送信されるＬＰＰメッセージセグメントの各々はまた、図６に示されるように、別個のＬＰＰシーケンス番号およびＦＡＬＳＥに設定されたｅｎｄＴｒａｎｓａｃｔｉｏｎフラグを含み得る。Ｅ－ＳＭＬＣ１１０は、「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」フラグが含まれることに基づいて、アクション６３０－１において送信される第１のＬＰＰ ＰＬＩメッセージセグメントと、最後の１つを除く各々の後続のＬＰＰメッセージセグメントとを記憶でき、「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」フラグが含まれることからＥ－ＳＭＬＣ１１０によって認識され得るアクション６３０－ｎにおいて最後のＬＰＰメッセージセグメントを受信した後で、全てのＬＰＰ ＰＬＩメッセージセグメントの内容を組み立て直すことができる。組み立て直されるＬＰＰ ＰＬＩメッセージの内容は、ＵＥ１０２の位置を決定するためにＥ－ＳＭＬＣ１１０によって使用され得る（例えば、図３のブロック３６０－１におけるように）。

【0083】

[0087] ＵＥ１０２は、アクション６１０においてＥ－ＳＭＬＣ１１０によって要求されるように、後続の固定された定期的な間隔で、さらなる位置測定結果および／または位置推定をＥ－ＳＭＬＣ１１０に送信し得る。より低次のトランスポートプロトコルによって許容される最大サイズ閾値を超えるであろうＬＰＰ ＰＬＩメッセージにより、セグメント化が使用される必要があるとき、ブロック６２０－１に対するアクションと同様のアクションがＵＥ１０２によって行われ得る。位置測定結果の最後のセットおよび／または最後の位置推定が、セグメント化を使用してＥ－ＳＭＬＣ１１０へＵＥ１０２によって送信される必要があるとき、ＵＥ１０２は、ブロック６２０－ｐのためのアクション６４０－１および６４０－ｍを行い得る。図６における標識は、ＵＥ１０２が定期的な位置測定結果および／または位置推定のｐ（ｐ≧２）個の別個のセットをＥ－ＳＭＬＣ１１０に返すことと、最後の（第ｐの）セットがｍ（ｍ≧２）個の別個のＬＰＰ ＰＬＩメッセージセグメントへのセグメント化を必要とすることとを仮定する。アクション６３０－１から６３０－ｎにおいて送信されるｎ個のＬＰＰ ＰＬＩメッセージセグメントと同様に、ｍ個のＬＰＰ ＰＬＩメッセージセグメントがアクション６４０－１から６４０－ｍにおいて送信される。これは、アクション６４０－１のｍ－１回の反復のために送信される最初のｍ－１個のＬＰＰ ＰＬＩメッセージセグメントに対して「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」に設定されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドが含まれることと、アクション６４０－ｍにおいて送信された最後の（第ｍの）ＬＰＰ ＰＬＩメッセージセグメントに対して「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」に設定されたＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドが含まれることとを含む。しかしながら、ブロック６２０－１とは異なり、ＴＲＵＥに設定されたｅｎｄＴｒａｎｓａｃｔｉｏｎフラグが、アクション６４０－ｍにおいて送信される最後の（第ｍの）ＬＰＰ ＰＬＩメッセージセグメントに含まれる。ブロック６２０－１について上で説明されたように、Ｅ－ＳＭＬＣ１１０は、ＴＲＵＥに設定された「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」フラグまたはｅｎｄＴｒａｎｓａｃｔｉｏｎフラグが含まれることからＥ－ＳＭＬＣ１１０によって認識され得る、最後の第ｍのＬＰＰメッセージセグメントをアクション６４０ーｍにおいて受信した後で、全てのＬＰＰ ＰＬＩメッセージセグメントの内容を組み立て直すことができる。組み立て直されるＬＰＰ ＰＬＩメッセージの内容は、ＵＥ１０２の最後の位置を決定するためにＥ－ＳＭＬＣ１１０によって使用され得る（例えば、図３のブロック３６０-ｎにおけるように）。

【0084】

[0088] 図２～図６に関して上で説明されたようなＬＰＰメッセージセグメント化をサポートするＵＥ１０２またはＥ－ＳＭＬＣ１１０は、ＬＰＰメッセージまたはＬＰＰメッセージセグメントの送信者によってもたらされる起こり得るエラーを検出してそれから回復するために、ＬＰＰメッセージセグメント化が使用されているときにエラー検出手順を利用する必要があり得る。Ｒ１からＲ８と標識された、エラーを検出してそれから回復するための規則の例示的なセットが、以下で説明される。これらの規則は、以下で「受信者」と呼ばれるＵＥ１０２またはＥ－ＳＭＬＣ１１０によって、以下で示される順序で適用されることがあり、ＵＥ１０２またはＥ－ＳＭＬＣ１１０は、送信者からＬＰＰメッセージまたはＬＰＰメッセージセグメントを受信しており、起こり得るエラーを決定するためにメッセージまたはメッセージセグメントを処理している。

【0085】

[0089] 規則Ｒ１：３ＧＰＰ ＴＳ ３６．３５５においてＬＰＰについて定義されるＡＳＮ．１符号化に従って、ＬＰＰメッセージまたはメッセージセグメントの復号を試みる。（ｉ）復号エラーに遭遇する場合、（ｉｉ）受信されたメッセージまたはメッセージセグメントがＬＰＰエラーまたは中止メッセージであると受信者が決定できない場合、（ｉｉｉ）受信者がＬＰＰセッションおよびＬＰＰトランザクションＩＤを決定できる場合、（ｉｖ）受信されたメッセージがＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含む場合、および、（ｖ）受信者がこのＬＰＰセッションおよびＬＰＰトランザクションＩＤに対して以前にメッセージセグメントを記憶していた場合、受信者は、このＬＰＰセッションおよびＬＰＰトランザクションＩＤについて、全ての記憶されているＬＰＰメッセージセグメントを廃棄するものとする。加えて、条件（ｉ）および（ｉｉ）が満たされるとき、受信者は、受信されたメッセージを廃棄し、エラー検出手順を停止し、ＬＰＰエラーメッセージを送信者に返し、受信されたＬＰＰトランザクションＩＤが復号されたならば受信されたＬＰＰトランザクションＩＤを、およびエラーのタイプを含めるものとする。

【0086】

[0090] 規則Ｒ２：メッセージが以前に受信されたメッセージの複製である場合、受信されたメッセージを廃棄し、エラー検出手順を停止する。

【0087】

[0091] 規則Ｒ３：ＬＰＰトランザクションＩＤが、同じＬＰＰセッションについて受信者においてまだ進行中である手順のＬＰＰトランザクションＩＤと一致する場合、および、メッセージタイプが手順の現在の状態について無効である場合、（ｉ）進行中の手順を中止し、（ｉｉ）ＬＰＰエラーメッセージを送信者に返して、受信されたＬＰＰトランザクションＩＤおよびエラーのタイプを含め、（ｉｉｉ）メッセージがＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含み、受信者がこのセッションおよびＬＰＰトランザクションＩＤについてＬＰＰトランザクションセグメントを以前に記憶していた場合、このＬＰＰセッションおよびＬＰＰトランザクションＩＤについて全ての記憶されているＬＰＰメッセージセグメントを廃棄し、（ｉｖ）受信されたメッセージを廃棄してエラー検出手順を停止する。

【0088】

[0092] 規則Ｒ４：メッセージがＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含み、受信者がこのＬＰＰセッションおよびＬＰＰトランザクションＩＤについてＬＰＰメッセージセグメントを以前に記憶しており、受信されたメッセージタイプが記憶されているメッセージタイプと異なる場合、（ｉ）ＬＰＰエラーメッセージを送信者に返し、受信されたＬＰＰトランザクションＩＤおよびエラーのタイプを含め、（ｉｉ）このＬＰＰセッションおよびＬＰＰトランザクションＩＤについて受信されたメッセージおよび全ての記憶されているＬＰＰメッセージセグメントを廃棄し、（ｉｉｉ）エラー検出手順を停止できる。

【0089】

[0093] 規則Ｒ５：メッセージがＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含む場合、およびＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドが値「ｍｏｒｅ Ｍｅｓｓａｇｅｓ Ｏｎ Ｔｈｅ Ｗａｙ」を有する場合、受信されたメッセージを記憶する。ある実現形態オプションとして、ＬＰＰ支援データ提供メッセージまたはＬＰＰ位置情報提供メッセージの受信者は、メッセージセグメントを記憶する代わりに、受信されたメッセージセグメントを処理し得る。

【0090】

[0094] 規則Ｒ６：メッセージがＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドを含む場合、およびＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドが値「ｎｏ Ｍｏｒｅ Ｍｅｓｓａｇｅｓ」を有する場合、受信されたメッセージについて、並びにこのセッションおよびＬＰＰトランザクションＩＤに対する任意の記憶されているＬＰＰメッセージセグメントについて、エラー検出および他の処理を続ける。

【0091】

[0095] 規則Ｒ７：メッセージタイプがＬＰＰ能力要求であり、要求される情報の一部がサポートされない場合、送信者への通常の応答において提供され得る任意の情報を返す。

【0092】

[0096] 規則Ｒ８：メッセージタイプがＬＰＰ支援データ要求またはＬＰＰ位置情報要求であり、要求された情報の一部または全てがサポートされない場合、送信者への通常の応答において提供され得る任意の情報を返し、これは、受信者によってサポートされない他の情報についての指示を含む。

【0093】

[0097] 図７は、一実施形態による、位置特定セッションにおいてＬＰＰメッセージのサイズを制限する方法のプロセスフロー図７００である。本明細書に添付される他の図面のように、図７は非限定的な例として与えられる。代替の実施形態は、図７に示されるように機能を追加し、省略し、合成し、並べ替え、分離し、および／または別様に変更し得る。方法は、ＵＥ１０２などのＵＥによって、または、Ｅ－ＳＭＬＣ１１０、Ｈ－ＳＬＰ１１８、もしくはＬＭＦなどのＬＳによって行われ得る。図７のブロックのうちの１つまたは複数において説明される機能を行うための手段は、図９に示されるＵＥ１０２などのモバイルデバイス、および／もしくは、図１０に示されるコンピュータシステム１０００などのコンピュータシステム１０００の、ソフトウェア構成要素並びに／またはハードウェア構成要素を含むことができ、これらの両方が以下でより詳細に説明される。

【0094】

[0098] 方法はブロック７１０において開始でき、ここで、第１のＬＰＰメッセージが第１のデバイスから第２のデバイスに送信され、第１のＬＰＰメッセージは、第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む。上で述べられたように、ＵＥとＬＳの両方が、セグメント化されたＬＰＰメッセージを送信および／または受信し得る。従って、いくつかの実施形態では、第１のデバイスはＥ－ＳＭＬＣ（例えば、Ｅ－ＳＭＬＣ１１０）またはＬＭＦを備えることがあり、第２のデバイスはＵＥ（例えば、ＵＥ１０２）を備えることがある。代わりに、第１のデバイスはＵＥ（例えば、ＵＥ１０２）を備えることがあり、第２のデバイスはＥ－ＳＭＬＣ（例えば、Ｅ－ＳＭＬＣ１１０）またはＬＭＦを備えることがある。

【0095】

[0099] 前に述べられたように、異なるＬＰＰメッセージは、セグメント化されることがあり、および／または、望まれるようにセグメント化されたメッセージを送信および／または受信するための能力を示すことがある。いくつかの実施形態では、第１のＬＰＰメッセージは、ＬＰＰ能力要求メッセージ（例えば、図３のアクション３１５における）、ＬＰＰ能力提供メッセージ（例えば、図３のアクション３２０における）、またはＬＰＰ位置情報要求メッセージを備え得る。

【0096】

[0100] ブロック７１０において説明される機能を行うための手段は、例えば、図９に示されており以下でより詳細に説明されるような、バス９０５、処理ユニット９１０、ワイヤレス通信インターフェース９３０、ワイヤレス通信アンテナ９３２、メモリ９６０、および／もしくはＵＥ１０２の他の構成要素、または、図１０に示されており以下でより詳細に説明されるような、バス１００５、処理ユニット１０１０、通信サブシステム１０３０、ワーキングメモリ１０３５、オペレーティングシステム１０４０、アプリケーション１０４５、および／もしくはコンピュータシステム１０００の他の構成要素を含み得る。

【0097】

[0101] ブロック７２０において、機能は、ブロック７１０における第１のＬＰＰメッセージ送信の後で、第２のデバイスから第１のデバイスにおいて、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える複数のＬＰＰメッセージセグメントを受信することを含む。ここで、１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントは、それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を（例えば、ＬＰＰ ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールド）に含める。加えて、最後のＬＰＰメッセージセグメントは、最後のＬＰＰメッセージセグメントが最後であることの指示を（例えば、ＬＰＰ ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドに）含める。ブロック７２０は、（ｉ）図２のアクション２３０、２４０－ａ、２４０－ｂ、および２５０、（ｉｉ）図４のアクション４２０－１および４２０－ｎ、（ｉｉｉ）図４のアクション４３０－１および４３０－ｍ、（ｉｖ）図５のアクション５２０－１および５２０－ｎ、（ｖ）図５のアクション５４０－１および５４０－ｍ、（ｖｉ）図６のアクション６３０－１および６３０－ｎ、並びに／または、（ｖｉｉ）図６のアクション６４０－１および６４０－ｍのうちのいずれかに対応し得る。

【0098】

[0102] いくつかの実施形態では、例えば、複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントは、同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備える。いくつかの事例では、同じＬＰＰメッセージタイプは、ＬＰＰ能力提供メッセージタイプ、ＬＰＰ支援データ提供メッセージタイプ、ＬＰＰ支援データ要求メッセージタイプ、ＬＰＰ位置情報要求メッセージタイプ、またはＬＰＰ位置情報提供メッセージタイプを備え得る。

【0099】

[0103] いくつかの実施形態はさらに、第１のデバイスによって、（例えば、以前に説明された規則Ｒ５の実現形態オプションとして許容されるように）それぞれのＬＰＰメッセージセグメントが受信されるときに複数のＬＰＰメッセージセグメントの各ＬＰＰメッセージセグメントを処理することを備えることがあり、この処理は同じＬＰＰメッセージタイプに基づく。加えて、または代わりに、実施形態はさらに、第１のデバイスに、１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントを記憶することと、第１のデバイスによって、（例えば図２および規則Ｒ５について前に説明されたように）最後のＬＰＰメッセージセグメントが受信された後で複数のＬＰＰメッセージセグメントを処理することとを備えることがあり、この処理は同じＬＰＰメッセージタイプに基づく。例えば、処理することは、（ｉ）同じＬＰＰメッセージタイプがＬＰＰ位置情報提供メッセージのためのメッセージタイプである場合、ＬＳにおいてＵＥの位置を計算し（例えば、図３のブロック３６０－１および３６０－ｎのように）、または、（ｉｉ）（例えば、図３のブロック３５０－１のように）同じＬＰＰメッセージタイプがＬＰＰ支援データ提供メッセージのためのものである場合、ＵＥにおいて位置測定結果を取得し、および／もしくはＵＥの位置を計算するために支援データを使用することを備え得る。

【0100】

[0104] ブロック７２０において説明される機能を行うための手段は、例えば、図９に示されており以下でより詳細に説明されるような、バス９０５、処理ユニット９１０、ワイヤレス通信インターフェース９３０、ワイヤレス通信アンテナ９３２、メモリ９６０、および／もしくはＵＥ１０２の他の構成要素、または、図１０に示されており以下でより詳細に説明されるような、バス１００５、処理ユニット１０１０、通信サブシステム１０３０、ワーキングメモリ１０３５、オペレーティングシステム１０４０、アプリケーション１０４５、および／もしくはコンピュータシステム１０００の他の構成要素を含み得る。

【0101】

[0105] 図７に示される方法の代替の実施形態は、１つまたは複数の追加の機能を含み得る。例えば、いくつかの事例では、ブロック７１０において第１のＬＰＰメッセージを送信する前に、第１のデバイスは、第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示（例えば、ＬＰＰ ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドの中の）を含む第２のＬＰＰメッセージを第２のデバイスから受信し得る。第２のＬＰＰメッセージは、一態様におけるＬＰＰ能力要求メッセージ（例えば、図３のアクション３１５について説明されたような）であり得る。

【0102】

[0106] 図７に示される方法の別の態様では、第１のデバイスは、（例えば、図２について前に説明されたように）複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を記憶し得る。複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を記憶した後で、第１のデバイスは、複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信におけるエラーを決定し得る。エラーを決定した後で、第１のデバイスは、記憶された複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を廃棄し得る。例えば、廃棄することは、規則Ｒ１、Ｒ３、および／またはＲ４について前に説明されたようなものであり得る。この態様では、図７の方法はさらに、（例えば、規則Ｒ１、Ｒ３、およびＲ４について前に説明されたように）エラーの決定を示すメッセージを、第１のデバイスから第２のデバイスに送信することを備え得る。この態様では、第１のデバイスによって複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信においてエラーを決定することは、例えば、規則Ｒ４について前に説明されたように、第１のデバイスにおいて受信された複数のＬＰＰメッセージセグメントのうちの少なくとも１つが、複数のＬＰＰメッセージセグメントの最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数とは異なるメッセージタイプを有すると決定することを備え得る。代わりに、この態様では、第１のデバイスによって複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信においてエラーを決定することは、規則Ｒ３について前に説明されたように、第１のデバイスにおいて受信された複数のＬＰＰメッセージセグメントのうちの少なくとも１つが、複数のＬＰＰメッセージセグメントのための手順の現在の状態に対する無効なメッセージタイプを有すると決定することを備え得る。

【0103】

[0107] 図８は、一実施形態による、位置特定セッションにおいてＬＰＰメッセージのサイズを制限する別の方法のプロセスフロー図８００である。代替の実施形態は、図８に示されるように機能を追加し、省略し、合成し、並べ替え、分離し、および／または別様に変更し得る。図８に示される方法は、ＵＥ１０２などのＵＥによって、または、Ｅ－ＳＭＬＣ１１０、Ｈ－ＳＬＰ１１８、もしくはＬＭＦなどのＬＳによって行われ得る。図８のブロックのうちの１つまたは複数において説明される機能を行うための手段は、図９に示されるＵＥ１０２などのモバイルデバイス、および／もしくは、図１０に示されるコンピュータシステム１０００などのコンピュータシステムの、ソフトウェア構成要素並びに／またはハードウェア構成要素を含むことができ、これらの両方が以下でより詳細に説明される。

【0104】

[0108] ブロック８１０において、機能は、第２のデバイスにおいて第１のデバイスから、第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを受信することを備える。やはりここで、第１のＬＰＰメッセージはＬＰＰメッセージの任意のタイプのうちの１つであり得る。いくつかの実施形態では、例えば、第１のＬＰＰメッセージは、ＬＰＰ能力要求メッセージ（例えば、図３のアクション３１５における）、ＬＰＰ能力提供メッセージ（例えば、図３のアクション３２０における）、またはＬＰＰ位置情報要求メッセージを備える。その上、第１のデバイスはＥ－ＳＭＬＣ（例えば、Ｅ－ＳＭＬＣ１１０）またはＬＭＦを備えることがあり、第２のデバイスはＵＥ（例えば、ＵＥ１０２）を備えることがある。代わりに、第１のデバイスはＵＥ（例えば、ＵＥ１０２）を備えることがあり、第２のデバイスはＥ－ＳＭＬＣ（例えば、Ｅ－ＳＭＬＣ１１０）またはＬＭＦを備えることがある。

【0105】

[0109] ブロック８１０において説明される機能を行うための手段は、例えば、図９に示されるように、および以下でより詳細に説明されるように、バス９０５、処理ユニット９１０、ワイヤレス通信インターフェース９３０、ワイヤレス通信アンテナ９３２、メモリ９６０、および／またはＵＥ１０２の他の構成要素を含み得る。ブロック８１０において説明される機能を行うための手段は、さらに、または代わりに、例えば、図１０に示されるように、および以下でより詳細に説明されるように、バス１００５、処理ユニット１０１０、通信サブシステム１０３０、ワーキングメモリ１０３５、オペレーティングシステム１０４０、アプリケーション１０４５、および／またはコンピュータシステム１０００の他の構成要素を含み得る。

【0106】

[0110] ブロック８２０において、機能は、ブロック８１０において第１のメッセージを受信した後で、見込まれるＬＰＰメッセージのサイズがある閾値を超えるであろうことを第２のデバイスによって決定することを備える。この閾値は、例えば、上で説明されたような、トランスポートプロトコルによって課されるサイズの制約に基づいて決定され得る。さらに、上で述べられたように、見込まれるＬＰＰメッセージは、見込まれるＬＰＰメッセージのサイズが閾値を超えるであろうことを決定するために、作成される必要がないことがある。見込まれるＬＰＰメッセージのサイズがある閾値を超えるであろうと決定したことに応答して、ブロック８２０はさらに、見込まれるＬＰＰメッセージをセグメント化することを第２のデバイスによって決定することを備え得る。見込まれるＬＰＰメッセージをセグメント化することの第２のデバイスによる決定は、第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの、ブロック８１０において受信された指示に一部基づき得る。いくつかの実施形態では、ブロック８２０は図２のブロック２２５に対応し得る。

【0107】

[0111] ブロック８２０において説明される機能を行うための手段は、例えば、図９に示されており以下でより詳細に説明されるような、バス９０５、処理ユニット９１０、メモリ９６０、および／もしくはＵＥ１０２の他の構成要素、または、図１０に示されており以下でより詳細に説明されるような、バス１００５、処理ユニット１０１０、ワーキングメモリ１０３５、オペレーティングシステム１０４０、アプリケーション１０４５、および／もしくはコンピュータシステム１０００の他の構成要素を含み得る。

【0108】

[0112] ブロック８３０において、複数のＬＰＰメッセージセグメントは第２のデバイスから第１のデバイスに送信される。ここで、ＬＰＰメッセージセグメントは、見込まれるＬＰＰメッセージに対応する（例えば、それと同一の、またはそれに一致する）情報を備える。複数のＬＰＰメッセージセグメントはさらに、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える。ここで、１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントは、それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を（例えば、ＬＰＰ ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールド）に含める。加えて、最後のＬＰＰメッセージセグメントは、最後のＬＰＰメッセージセグメントが最後であることの指示を（例えば、ＳｅｇｍｅｎｔａｔｉｏｎＩｎｆｏフィールドに）含める。これらの指示は、上で説明されたように、各ＬＰＰメッセージセグメント内でフラグまたはパラメータ値として提供され得る。

【0109】

[0113] ブロック８３０において送信される複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントは、見込まれるＬＰＰメッセージと同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージであることがあり、および／または、同じＬＰＰトランザクションＩＤを搬送することがある。例えば、見込まれるＬＰＰメッセージがＬＰＰ位置情報提供メッセージである場合、各ＬＰＰメッセージセグメントは、ＬＰＰ位置情報提供メッセージを備え得る。いくつかの実施形態では、同じＬＰＰメッセージタイプは、ＬＰＰ能力提供メッセージタイプ、ＬＰＰ支援データ提供メッセージタイプ、ＬＰＰ支援データ要求メッセージタイプ、ＬＰＰ位置情報要求メッセージタイプ、またはＬＰＰ位置情報提供メッセージタイプを備える。いくつかの実施形態では、ブロック８３０は、（ｉ）図２のアクション２３０、２４０－ａ、２４０－ｂ、および２５０、（ｉｉ）図４のアクション４２０－１および４２０－ｎ、（ｉｉｉ）図４のアクション４３０－１および４３０－ｍ、（ｉｖ）図５のアクション５２０－１および５２０－ｎ、（ｖ）図５のアクション５４０－１および５４０－ｍ、（ｖｉ）図６のアクション６３０－１および６３０－ｎ、並びに／または、（ｖｉｉ）図６のアクション６４０－１および６４０－ｍのうちのいずれかに対応し得る。

【0110】

[0114] ブロック８３０において説明される機能を行うための手段は、例えば、図９に示されるように、および以下でより詳細に説明されるように、バス９０５、処理ユニット９１０、ワイヤレス通信インターフェース９３０、ワイヤレス通信アンテナ９３２、メモリ９６０、および／またはＵＥ１０２の他の構成要素を含み得る。ブロック８３０において説明される機能を行うための手段は、さらに、または代わりに、例えば、図１０に示されるように、および以下でより詳細に説明されるように、バス１００５、処理ユニット１０１０、通信サブシステム１０３０、ワーキングメモリ１０３５、オペレーティングシステム１０４０、アプリケーション１０４５、および／またはコンピュータシステム１０００の他の構成要素を含み得る。

【0111】

[0115] 図８に示される方法の代替の実施形態は、１つまたは複数の追加の機能を含み得る。例えば、いくつかの事例では、ブロック８１０において第１のＬＰＰメッセージを受信する前に、第２のデバイスは、第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを第１のデバイスに送信し得る。例えば、第２のＬＰＰメッセージは、図３のアクション３１５におけるような、ＬＰＰ能力要求メッセージであり得る。

【0112】

[0116] 図８の方法の別の追加の態様では、第２のデバイスは、複数のＬＰＰメッセージセグメントのうちの少なくとも１つの受信において、第１のデバイスによるエラーの決定を示すメッセージ（例えば、ＬＰＰエラーメッセージ）を第１のデバイスから受信し得る。この態様では、エラーの決定を示すメッセージを受信したことに応答して、第２のデバイスは、複数のＬＰＰメッセージセグメントと関連付けられるＬＰＰセッションを中止し得る。

【0113】

[0117] 図２～図８に関連して本明細書でこれまでに説明された解決法の潜在的な問題は、エラーが受信者（例えば、ＵＥ１０２またはＥ－ＳＭＬＣ１１０）によって受信されたＬＰＰメッセージセグメントにおいて検出されるときに、受信されたメッセージセグメントと任意の以前の受信されたメッセージセグメントの両方が、図７並びに規則Ｒ１、Ｒ３、およびＲ４について前に説明されたように、受信者によって廃棄され得ることである。エラーメッセージ（例えば、ＬＰＰエラーメッセージ）も、ＬＰＰメッセージセグメントの送信者に返され得る。しかしながら、受信者が次いで、同じセグメント化されたＬＰＰメッセージシーケンスについて送信者から別の新しいＬＰＰメッセージセグメントを受信する場合、受信者は、新しいトランザクションおよび新しいセグメント化されるＬＰＰメッセージの一部として、新しいＬＰＰメッセージセグメントを受け入れ得る。例えば、これは、送信者がＬＰＰ肯定応答を使用しておらず、受信者からエラーメッセージを受信する前にいくつかのＬＰＰメッセージセグメントを受信者にすでに送信していた場合に、起こり得る。このことは、どのＬＰＰメッセージセグメントが受け入れられたか、およびどれが受信者によって廃棄されたかを送信者が知らないことを含む、エラーにつながり得る。

【0114】

[0118] この問題を避けるために、各ＬＰＰメッセージセグメントは、これが第１のセグメントであるか、後続の最後ではないセグメントであるか、または最後のセグメントであるかを示す指示を（例えば、ＬＰＰ ＳｅｍｅｎｔａｔｉｏｎＩｎｆｏフィールドに）含め得る。エラーが第１のＬＰＰメッセージセグメントまたは後続の（最後の、または最後ではない）ＬＰＰメッセージセグメントにおいて受信者によって検出され、受信者がそれでも第１のＬＰＰメッセージセグメントを有する場合、受信者は、エラーのあるＬＰＰメッセージセグメントと、以前に説明されたような任意の以前に受信され記憶されたＬＰＰメッセージセグメントとを廃棄できる。しかしながら、以前の解決法とは異なり、後続の（最後の、または最後ではない）ＬＰＰメッセージセグメントを示すＬＰＰメッセージセグメントが受信され、受信者がすでに記憶されている第１のＬＰＰメッセージセグメントを有しない場合、受信者は、任意の他のエラーが検出されるかどうかにかかわらず、受信されたＬＰＰメッセージセグメントを廃棄できる。加えて、肯定応答が送信者により要求された場合、肯定応答以外のどのような指示も送信者に返されなくてよい。解決法のこの修正により、受信者は、より以前のＬＰＰメッセージセグメントを受信者に廃棄させたエラーがより以前のＬＰＰメッセージセグメントについて検出された後で、セグメント化されたＬＰＰメッセージのより後のセグメントを誤って受信して受け入れるのを避けることができる。

【0115】

[0119] 修正された解決法により、「第１のメッセージ」、「最後ではない後続のメッセージ」、または「最後のメッセージ」のうちの１つを示すことができる、新しいパラメータがＬＰＰメッセージに含まれ得る。このパラメータは、ＬＰＰメッセージのセグメント化についてのみ含まれ、セグメント化されないＬＰＰメッセージに対しては含まれないことがある。パラメータ「第１のメッセージ」がＬＰＰメッセージに含まれる場合、これが第１のＬＰＰメッセージセグメントであることと、さらなるＬＰＰメッセージセグメントが後に続くこととを、受信エンティティに示し得る。パラメータ「最後ではない後続のメッセージ」がＬＰＰメッセージに含まれる場合、これが後続のＬＰＰメッセージセグメントであることと、さらなるＬＰＰメッセージセグメントが後に続くこととを、受信エンティティに示し得る。パラメータ「最後のメッセージ」がＬＰＰメッセージに含まれる場合、これが最後のＬＰＰメッセージセグメントであることと、これ以上のＬＰＰメッセージセグメントが後に続かないこととを、受信エンティティに示し得る。セグメント化されたＬＰＰメッセージの送信および／または受信をサポートするためのＵＥとＬＳの能力の指示を含む、修正された解決法の他の態様は、図２～図８に関連して以前に説明されたものと同じであり、または同様であり得る。

【0116】

[0120] 図９は、上で説明され図１～図８において説明される実施形態で説明されたように利用され得る、ＵＥ１０２の実施形態を示す。図９は、様々な構成要素の一般化された図を与えることのみが意図されており、それらの構成要素のいずれかまたは全てが適宜に利用され得ることに留意されたい。言い換えると、ＵＥは機能が大きく変動し得るので、ＵＥは図９に示される構成要素の一部分のみを含むことがある。いくつかの事例では、図９によって示されている構成要素が、単一の物理デバイスに局所化されてよく、および／または、異なる物理的位置に配設され得る様々なネットワーク化されたデバイス間に分散されることがあることに留意されたい。

【0117】

[0121] バス９０５を介して電気的に結合され得る（または、適宜に、他の方法で通信していることがある）ハードウェア要素を備えるＵＥ１０２が示されている。ハードウェア要素は、限定はされないが、１つまたは複数の汎用プロセッサ、（デジタル信号処理（ＤＳＰ）チップ、グラフィックスアクセラレーションプロセッサ、特定用途向け集積回路（ＡＳＩＣ）などの）１つまたは複数の専用プロセッサ、および／または本明細書で説明された方法のうちの１つまたは複数を行うように構成され得る他の処理構造または手段を備え得る、処理ユニット９１０を含み得る。図９に示されているように、いくつかの実施形態は、所望の機能に応じて別個のＤＳＰ９２０を有し得る。ＵＥ１０２はまた、１つまたは複数の入力デバイス９７０を備えることがあり、これは、限定はされないが、１つまたは複数のタッチスクリーン、タッチパッド、マイクロフォン、ボタン、ダイヤル、スイッチなどを備え得る、１つまたは複数の入力デバイス９７０と、限定はされないが、１つまたは複数のディスプレイ、発光ダイオード（ＬＥＤ）、スピーカーなどを備え得る、１つまたは複数の出力デバイス９１５とを備え得る。

【0118】

[0122] ＵＥ１０２はまた、ワイヤレス通信インターフェース９３０を含むことがあり、これは、限定はされないが、モデム、ネットワークカード、赤外線通信デバイス、ワイヤレス通信デバイス、および／またはチップセット（Ｂｌｕｅｔｏｏｔｈデバイス、ＩＥＥＥ８０２．１１デバイス、ＩＥＥＥ８０２．１５．４デバイス、Ｗｉ－Ｆｉデバイス、ＷｉＭＡＸデバイス、セルラー通信施設など）などを備えることがあり、これらは、ＵＥ１０２が図１に関して上で説明されたネットワークおよびＲＡＴを介して通信することを可能にし得る。ワイヤレス通信インターフェース９３０は、データが、ネットワーク、ＬＳ、ワイヤレスアクセスポイント、ワイヤレス基地局、他のコンピュータシステム、および／または本明細書で説明される他の電子デバイスと通信されることを可能にし得る。通信は、ワイヤレス信号９３４を送信するおよび／または受信する１つまたは複数のワイヤレス通信アンテナ９３２を介して行われ得る。

【0119】

[0123] 所望される機能に応じて、ワイヤレス通信インターフェース９３０は、基地局（例えば、図１のｅＮＢ１０４および１０６）、および、１つまたは複数のワイヤレスネットワークに属する、またはそれと関連付けられるワイヤレスデバイスおよびアクセスポイントなどの他の地上トランシーバと通信するための、別個のトランシーバを備え得る。これらのワイヤレスネットワークは、様々なネットワークタイプを備え得る。例えば、ＷＷＡＮは、ＣＤＭＡネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、シングルキャリア周波数分割多元接続（ＳＣ－ＦＤＭＡ）ネットワーク、ＷｉＭＡＸ（ＩＥＥＥ８０２．１６）ネットワークなどであり得る。ＣＤＭＡネットワークは、ｃｄｍａ２０００、広帯域ＣＤＭＡ（ＷＣＤＭＡ）などの１つまたは複数の無線アクセス技術（ＲＡＴ）を実現し得る。ｃｄｍａ２０００は、ＩＳ－９５規格、ＩＳ－２０００規格、および／またはＩＳ－８５６規格を含む。ＴＤＭＡネットワークは、ＧＳＭ、デジタルアドバンストモバイルフォンシステム（Ｄ－ＡＭＰＳ：Digital Advanced Mobile Phone System）、または何らかの他のＲＡＴを実現し得る。ＯＦＤＭＡネットワークは、ＬＴＥ、ＬＴＥアドバンスト、５Ｇ、ＮＲなどを利用し得る。ＬＴＥ、ＬＴＥアドバンスト、ＮＲ、ＧＳＭ、およびＷ－ＣＤＭＡ（登録商標）は、３ＧＰＰからの文書に記載されている（または記載されつつある）。ｃｄｍａ２０００は、「第３世代パートナーシッププロジェクト２」（３ＧＰＰ２）と称する団体からの文書に記載されている。３ＧＰＰおよび３ＧＰＰ２の文書は公的に入手可能である。ＷＬＡＮはまた、ＩＥＥＥ８０２．１１ｘネットワークであることがあり、ＷＰＡＮは、Ｂｌｕｅｔｏｏｔｈネットワーク、ＩＥＥＥ８０２．１５ｘネットワーク、または他の何らかのタイプのネットワークであることがある。また、本明細書で説明される技法は、ＷＷＡＮ、ＷＬＡＮ、および／またはＷＰＡＮの任意の組合せのために使用され得る。

【0120】

[0124] ＵＥ１０２はさらに、センサ９４０を含むことができる。そのようなセンサは、限定はされないが、１つまたは複数の加速度計、ジャイロスコープ、カメラ、磁力計、高度計、マイクロフォン、近接度センサ、光センサ、気圧計などを備え得る。とりわけ、位置測定結果を取得するための、および／またはＬＳに通信され得る他のタイプの位置情報を取得するための、センサ９４０の一部または全てが利用され得る。

【0121】

[0125] ＵＥ１０２の実施形態はまた、ＳＰＳアンテナ９８２を使用して１つまたは複数のＳＰＳ衛星から信号９８４を受信可能であるＳＰＳ受信機９８０を含むことがあり、いくつかの実現形態では、ＳＰＳアンテナ９８２はアンテナ９３２と組み合わされることがある。ＳＰＳ受信機９８０を使用するＵＥ１０２の測位は、本明細書で説明される技法を補足するために、および／または組み込むために利用されることがあり、例えば、ＵＥ１０２によって位置情報を取得するために使用されることがある。ＳＰＳ受信機９８０は、ＧＮＳＳ（例えば、全地球測位システム（ＧＰＳ））、Ｇａｌｉｌｅｏ、ＧＬＯＮＡＳＳ、日本上空の準天頂衛星システム（ＱＺＳＳ）、インド上空のインド地域航法衛星システム（ＩＲＮＳＳ）、中国上空の北斗などの、ＳＰＳシステムのＳＰＳ ＳＶ（例えば、図１のＳＶ１６０）からの信号の測定をサポートし得る。その上、ＳＰＳ受信機９８０は、１つまたは複数の全地球および／または地域航法衛星システムと関連付けられるかまたはさもなければそれとともに使用することが可能にされ得る、様々なオーグメンテーションシステム（例えば、衛星ベースオーグメンテーションシステム（ＳＢＡＳ：Satellite Based Augmentation System））とともに使用され得る。限定ではなく例として、ＳＢＡＳは、例えば、ワイドエリアオーグメンテーションシステム（ＷＡＡＳ：Wide Area Augmentation System）、欧州静止ナビゲーションオーバーレイサービス（ＥＧＮＯＳ：European Geostationary Navigation Overlay Service）、多機能衛星オーグメンテーションシステム（ＭＳＡＳ：Multi -functional Satellite Augmentation System）、ＧＰＳ支援ジオオーグメンテッドナビゲーションまたはＧＰＳおよびジオオーグメンテッドナビゲーションシステム（GPS Aided Geo Augmented NavigationまたはGPS and Geo Augmented Navigation）などの、完全性情報、差分補正などを提供するオーグメンテーションシステムを含み得る。従って、本明細書で使用されるＳＰＳは、１つまたは複数の全地球および／もしくは地域航法衛星システム、並びに／または、オーグメンテーションシステムの任意の組合せを含むことがあり、ＳＰＳ信号は、ＳＰＳ、ＳＰＳ様の信号、および／またはそのような１つまたは複数のＳＰＳと関連付けられた他の信号を含むことがある。

【0122】

[0126] ＵＥ１０２は、メモリ９６０をさらに含み、および／またはそれと通信していることがある。メモリ９６０は、限定はされないが、ローカルストレージおよび／またはネットワークアクセス可能ストレージと、ディスクドライブと、ドライブアレイと、光ストレージデバイスと、ランダムアクセスメモリ（「ＲＡＭ」）および／またはプログラム可能、フラッシュ更新可能などであり得る読取り専用メモリ（「ＲＯＭ」）などのソリッドステートストレージデバイスとを備え得る。そのようなストレージデバイスは、限定はされないが、様々なファイルシステム、データベース構造などを含む、任意の適切なデータストアを実現するように構成され得る。メモリ９６０は、とりわけ、データベース、リンクされたリスト、または任意の他のタイプのデータ構造を使用してＬＳから受信された（例えば、本明細書で前に説明されたようにＬＰＰメッセージセグメント化を使用して受信された）ＡＤを記憶するために使用され得る。いくつかの実施形態では、ワイヤレス通信インターフェース９３０は、加えて、または代わりに、メモリを備え得る。

【0123】

[0127] ＵＥ１０２のメモリ９６０はまた、オペレーティングシステム、デバイスドライバ、実行可能ライブラリ、および／もしくは１つまたは複数のアプリケーションプログラムなどの他のコードを含む、ソフトウェア要素（図示せず）を備えることができ、１つまたは複数のアプリケーションプログラムは、様々な実施形態によって提供されるコンピュータプログラムを備え、並びに／または、本明細書で説明されるような、他の実施形態によって提供される方法を実現するように、および／もしくはシステムを構成するように設計され得る。単なる例として、上で論じられたＵＥ１０２の機能に関して説明された１つまたは複数の手順は、ＵＥ１０２（および／またはＵＥ１０２内の処理ユニット）によって実行可能なコードおよび／または命令として実現され得る。ある態様では、次いで、そのようなコードおよび／または命令は、説明された方法に従って１つまたは複数の動作を行うように汎用コンピュータ（または他のデバイス）を構成し、および／または適応させるために使用され得る。

【0124】

[0128] 図１０は、上の実施形態において説明されたように、ＬＳの機能を提供するために全体または一部が使用され得る、コンピュータシステム１０００の実施形態を示す。従って、例えば、本明細書で説明されるように、コンピュータシステム１０００は、Ｅ－ＳＭＬＣ１１０、Ｈ－ＳＬＰ１１８、またはＬＭＦに対応し得る。図１０は、様々な構成要素の一般化された図を与えることのみが意図されており、それらの構成要素のいずれかまたは全てが適宜に利用され得ることに留意されたい。図１０は、従って、個々のシステム要素が、比較的分離された方法または比較的より統合された方法で、どのように実現され得るかを概括的に示している。加えて、図１０において示された構成要素が、単一のデバイスに局所化されることがあり、および／または、異なる物理的位置に配設され得る様々なネットワーク化されたデバイス間に分散されることがあることに留意されたい。

【0125】

[0129] バス１００５を介して電気的に結合され得る（または、適宜に、別様に通信していることがある）ハードウェア要素を備えるコンピュータシステム１０００が示されている。ハードウェア要素は、限定はされないが、１つまたは複数の汎用プロセッサ、（デジタル信号処理チップ、グラフィックスアクセラレーションプロセッサなどの）１つまたは複数の専用プロセッサ、および／または本明細書で説明される方法のうちの１つまたは複数を行うように構成され得る他の処理構造を備え得る、処理ユニット１０１０を含み得る。コンピュータシステム１０００はまた、限定はされないが、マウス、キーボード、カメラ、マイクロフォンなどを備え得る１つまたは複数の入力デバイス１０１５と、限定はされないが、ディスプレイデバイス、プリンタなどを備え得る１つまたは複数の出力デバイス１０２０とを備え得る。

【0126】

[0130] コンピュータシステム１０００はさらに、限定はされないが、ローカルストレージおよび／もしくはネットワークアクセス可能ストレージを備えることができ、並びに／または、限定はされないが、ディスクドライブ、ドライブアレイ、光ストレージデバイス、ランダムアクセスメモリ（「ＲＡＭ」）および／もしくはプログラム可能、フラッシュ更新可能などであり得る読取り専用メモリ（「ＲＯＭ」）などのソリッドステートストレージデバイスなどを備え得る、１つまたは複数の非一時的ストレージデバイス１０２５をさらに含み得る（および／または、それらと通信していることがある）。そのようなストレージデバイスは、限定はされないが、様々なファイルシステム、データベース構造などを含む、任意の適切なデータストアを実現するように構成され得る。そのようなデータストアは、本明細書で説明されるように１つまたは複数のデバイスに送信されるべきメッセージおよび／または他の情報を記憶して管理するために使用され得る、データベースおよび／または他のデータ構造を含み得る。

【0127】

[0131] コンピュータシステム１０００は、ワイヤレス通信インターフェース１０３３によって管理され、制御されるワイヤレス通信技術、並びに有線技術（イーサネット（登録商標）、同軸通信、ユニバーサルシリアルバス（ＵＳＢ）など）を備え得る、通信サブシステム１０３０も含み得る。通信サブシステムは、モデム、ネットワークカード（ワイヤレスまたは有線）、赤外線通信デバイス、ワイヤレス通信デバイス、および／またはチップセットを備えることがあり、これらは、コンピュータシステム１０００が、ＵＥ１０２、他のコンピュータシステム、および／または本明細書で説明される任意の他の電子デバイスを含む、それぞれのネットワーク上の、またはそれぞれのネットワークからアクセス可能な任意のデバイスに、本明細書で説明される通信ネットワークのいずれかまたは全てで通信することを可能にし得る。従って、通信サブシステム１０３０は、本明細書の実施形態において説明されるシグナリングおよびメッセージを受信して送信するために使用され得る。

【0128】

[0132] 多くの実施形態では、コンピュータシステム１０００はさらに、上で説明されたように、ＲＡＭまたはＲＯＭデバイスを備え得る、ワーキングメモリ１０３５を備える。ワーキングメモリ１０３５内に位置するものとして示されている、ソフトウェア要素は、様々な実施形態によって提供されるコンピュータプログラムを備え得る、並びに／または、本明細書で説明されるように、他の実施形態によって提供される、方法を実現するように、および／もしくはシステムを構成するように設計され得る、オペレーティングシステム１０４０、デバイスドライバ、実行可能ライブラリ、および／または１つまたは複数のアプリケーション１０４５などの他のコードを備え得る。単なる例として、上で論じされた方法に関して説明された１つまたは複数の手順は、コンピュータ（および／またはコンピュータ内の処理ユニット）によって実行可能なコードおよび／または命令として実現されることがあり、ある態様では、次いで、そのようなコードおよび／または命令は、説明された技法に従って１つまたは複数の動作を行うように汎用コンピュータ（または他のデバイス）を構成し、および／または適応させるために使用されることがある。

【0129】

[0133] これらの命令および／またはコードのセットは、上で説明されたストレージデバイス１０２５などの非一時的コンピュータ可読記憶媒体に記憶され得る。いくつかの場合には、記憶媒体は、コンピュータシステム１０００などのコンピュータシステム内に組み込まれ得る。他の実施形態では、記憶媒体は、コンピュータシステムとは別個（例えば、光ディスクなどの取外し可能媒体）であることがあり、並びに／または、記憶媒体が、その上に記憶された命令／コードで汎用コンピュータをプログラムし、構成し、および／もしくは適応させるために使用され得るようなインストールパッケージで提供され得る。これらの命令は、コンピュータシステム１０００によって実行可能である実行可能コードの形態をとることがあり、並びに／または、（例えば、様々な一般に利用可能なコンパイラ、インストールプログラム、圧縮／解凍ユーティリティなどのいずれかを使用して）コンピュータシステム１０００上でコンパイルおよび／もしくはインストールしたときに実行可能コードの形態をとる、ソースコードおよび／もしくはインストール可能コードの形態をとり得る。

【0130】

[0134] かなりの変形が、具体的な要件に従って行われ得ることが当業者には明らかであろう。例えば、カスタマイズされたハードウェアも使用され得ることがあり、および／または、特定の要素が、ハードウェア、（アプレットなどのポータブルソフトウェアを含む）ソフトウェア、またはその両方で実現されることがある。さらに、ネットワーク入力／出力デバイスなどの、他のコンピューティングデバイスへの接続が利用され得る。

【0131】

[0135] 添付の図を参照すると、メモリを備え得る構成要素は、非一時的機械可読媒体を備え得る。本明細書で使用される「機械可読媒体」および「コンピュータ可読媒体」という用語は、機械を特定の様式で動作させるデータを与えることに関与する任意の記憶媒体を指す。上記で与えられた実施形態では、様々な機械可読媒体が、実行のために処理ユニットおよび／または他のデバイスに命令／コードを与えることに関与し得る。加えて、または代わりに、機械可読媒体は、そのような命令／コードを記憶および／または搬送するために使用され得る。多くの実現形態では、コンピュータ可読媒体は、物理および／または有形記憶媒体である。そのような媒体は、限定はされないが、不揮発性媒体、揮発性媒体、および伝送媒体を含む、多くの形態をとり得る。コンピュータ可読媒体の一般的な形態は、例えば、磁気および／または光媒体、穴のパターンをもつ任意の他の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ－ＥＰＲＯＭ、任意の他のメモリチップもしくはカートリッジ、以下で説明されるような搬送波、または、コンピュータが命令および／またはコードをそれから読み取ることができる任意の他の媒体を含む。

【0132】

[0136] 本明細書で説明される方法、システム、およびデバイスは例である。様々な実施形態は、適宜に様々な手順または構成要素を省略し、置換し、または追加し得る。例えば、いくつかの実施形態に関して説明される特徴は、様々な他の実施形態において組み合わされ得る。実施形態の異なる態様および要素が、同様にして組み合わされ得る。本明細書で提供される図の様々な構成要素は、ハードウェアおよび／またはソフトウェアで具現化され得る。また、技術は発展し、従って、要素の多くは例であり、それらの例は本開示の範囲をそれらの特定の例に限定しない。

【0133】

[0137] 本明細書全体にわたって、「１つの例」、「ある例」、「いくつかの例」、または「例示的な実現形態」への言及は、特徴および／または例に関連して説明される特定の特徴、構造、または特性が、特許請求される主題の少なくとも１つの特徴および／または例に含まれ得ることを意味する。従って、本明細書全体にわたる様々な箇所における「一例では」、「ある例では、」「いくつかの例では」、もしくは「ある実現形態では」という語句または他の同様の語句の出現は、必ずしも全てが同じ特徴、例、および／または制限を指すとは限らない。さらに、それらの特定の特徴、構造、または特性は、１つまたは複数の例および／または特徴において組み合わされ得る。

【0134】

[0138] 本明細書で説明される多くの機能に対して、特定の手段が、そのような機能を行うことが可能であるものとしても記述されていることに留意されたい。しかしながら、機能は開示される手段に限定されないことを理解されたい。本明細書で説明されるそれらの手段に加えて、またはその代わりに、同様の機能を行うための代替的な手段が使用され得ることを当業者は諒解するであろう。

【0135】

[0139] 本明細書に含まれる詳細な説明のいくつかの部分は、特定の装置または専用コンピューティングデバイスもしくはプラットフォームのメモリ内に記憶された、２値デジタル信号に対する演算のアルゴリズムまたは記号表現に関して提示された。この特定の明細書の文脈では、特定の装置などの用語は、プログラムソフトウェアからの命令に従って特定の動作を行うようにプログラムされた汎用コンピュータを含む。アルゴリズムの説明または記号表現は、信号処理または関連技術の当業者が、自身の仕事の本質を他の当業者に伝達するために使用する技法の例である。アルゴリズムは、本明細書では、また一般に、所望の結果につながる自己矛盾のない一連の演算または同様の信号処理であると考えられる。この文脈では、演算または処理は物理量の物理的操作を伴う。一般に、必ずしもそうとは限らないが、そのような量は、記憶、転送、結合、比較、または他の方法で操作されることが可能な電気信号または磁気信号の形態をとり得る。主に一般的な用法という理由で、そのような信号をビット、データ、値、要素、記号、文字、項、数、数字などと呼ぶことが時々便利であることがわかっている。しかしながら、これらおよび同様の用語は全て、適切な物理量に関連付けられるべきものであり、便利なラベルにすぎないことを理解されたい。別段に明記されていない限り、本明細書の説明から明らかなように、本明細書全体にわたって、「処理する」、「計算する（computing）」、「計算する（calculating）」、「決定する」などの用語を利用する説明は、専用コンピュータ、専用計算装置または同様の専用電子コンピューティングデバイスなどの、特定の装置の動作またはプロセスを指すことを諒解されたい。従って、本明細書の文脈では、専用コンピュータまたは同様の専用電子コンピューティングデバイスは、専用コンピュータまたは同様の専用電子コンピューティングデバイスのメモリ、レジスタ、または他の情報記憶デバイス、送信デバイス、またはディスプレイデバイス内の、電子的または磁気的な物理量として一般に表される信号を操作または変換することが可能である。

【0136】

[0140] 上記の詳細な説明では、特許請求される主題の完全な理解を与えるために多数の具体的な詳細が記載された。しかしながら、特許請求される主題は、これらの具体的な詳細を伴わずに実施され得ることが当業者により理解されよう。他の事例では、特許請求される主題を不明瞭にしないように、当業者に知られているであろう方法および装置は、詳細に説明されていない。

【0137】

[0141] 本明細書で使用される「および」、「または」、および「および／または」という用語は、そのような用語が使用される文脈に少なくとも部分的に依存することも予想される様々な意味を含み得る。一般に、「または」がＡ、ＢまたはＣなどのリストを関連付けるために使用される場合、ここで包含的な意味で使用されるＡ、Ｂ、およびＣを意味し、並びにここで排他的な意味で使用されるＡ、ＢまたはＣを意味することが意図される。さらに、本明細書で使用される「１つまたは複数」という用語は、単数形の任意の特徴、構造、もしくは特性について説明するために使用され得るか、または複数の特徴、構造もしくは特性、または特徴、構造もしくは特性の何らかの他の組合せについて説明するために使用され得る。ただし、これは例示的な例にすぎないこと、および特許請求する主題はこの例に限定されないことに留意されたい。

【0138】

[0142] 現在例示的な特徴と考えられることが例示され説明されたが、特許請求する主題から逸脱することなく、様々な他の変更が行われることがあり、均等物が代用されることがあることが、当業者には理解されよう。さらに、本明細書で説明される中心の概念から逸脱することなく、特許請求される主題の教示に特定の状況を適合させるために多くの変更が行われ得る。

【0139】

[0143] 従って、特許請求される主題は、開示された特定の例に限定されず、そのような特許請求される主題はまた、添付の特許請求の範囲内に入る全ての態様とそれらの均等物とを含み得ることが意図される。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
位置特定セッションにおけるロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージのサイズを制限するための方法であって、
第１のデバイスから第２のデバイスに、前記第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを送信することと、
前記第１のＬＰＰメッセージの前記送信の後で、前記第２のデバイスから前記第１のデバイスにおいて、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える複数のＬＰＰメッセージセグメントを受信することとを備え、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、前記それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、
前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であることの指示を含む、方法。
［Ｃ２］
前記第１のデバイスがエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備え、前記第２のデバイスがユーザ機器（ＵＥ）を備え、または、
前記第１のデバイスがＵＥを備え、前記第２のデバイスがＥ－ＳＭＬＣもしくはＬＭＦを備える、Ｃ１に記載の方法。
［Ｃ３］
前記第１のＬＰＰメッセージが、ＬＰＰ能力要求メッセージ、ＬＰＰ能力提供メッセージ、またはＬＰＰ位置情報要求メッセージを備える、Ｃ１に記載の方法。
［Ｃ４］
前記第１のＬＰＰメッセージを送信する前に、前記第１のデバイスが、前記第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを前記第２のデバイスから受信する、Ｃ１に記載の方法。
［Ｃ５］
前記第２のＬＰＰメッセージがＬＰＰ能力要求メッセージを備える、Ｃ４に記載の方法。
［Ｃ６］
前記複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントが、同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備える、Ｃ１に記載の方法。
［Ｃ７］
前記同じＬＰＰメッセージタイプが、ＬＰＰ能力提供メッセージタイプ、ＬＰＰ支援データ提供メッセージタイプ、ＬＰＰ支援データ要求メッセージタイプ、ＬＰＰ位置情報要求メッセージタイプ、またはＬＰＰ位置情報提供メッセージタイプを備える、Ｃ６に記載の方法。
［Ｃ８］
前記第１のデバイスにおいて、前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントを記憶することと、
前記第１のデバイスによって、前記最後のＬＰＰメッセージセグメントが受信された後で前記複数のＬＰＰメッセージセグメントを処理することとをおよびさらに備え、前記処理することが前記同じＬＰＰメッセージタイプに基づく、Ｃ６に記載の方法。
［Ｃ９］
前記第１のデバイスにおいて、前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を記憶することと、
前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数を記憶した後で、前記第１のデバイスによって、前記複数のＬＰＰメッセージセグメントのうちの少なくとも１つの前記受信におけるエラーを決定することと、
前記エラーを決定したことに応答して、前記第１のデバイスによって、前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数を廃棄することとをさらに備える、Ｃ１に記載の方法。
［Ｃ１０］
前記エラーの前記決定を示すメッセージを、前記第１のデバイスから前記第２のデバイスに送信することをさらに備える、Ｃ９に記載の方法。
［Ｃ１１］
前記複数のＬＰＰメッセージセグメントのうちの前記少なくとも１つの前記受信における前記エラーを前記決定することが、前記第１のデバイスにおいて受信された前記複数のＬＰＰメッセージセグメントのうちの前記少なくとも１つが、前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数とは異なるメッセージタイプを有すると決定することを備える、Ｃ９に記載の方法。
［Ｃ１２］
複数のＬＰＰメッセージセグメントのうちの少なくとも１つの前記受信における前記エラーを決定することが、前記第１のデバイスにおいて受信された前記複数のＬＰＰメッセージセグメントのうちの前記少なくとも１つが、前記複数のＬＰＰメッセージセグメントのための手順の現在の状態に対する無効なメッセージタイプを有すると決定することを備える、Ｃ９に記載の方法。
［Ｃ１３］
位置特定セッションにおけるロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージのサイズを制限するための方法であって、
第１のデバイスから第２のデバイスにおいて、前記第１のデバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを受信することと、
前記第１のＬＰＰメッセージの前記受信の後で、見込まれるＬＰＰメッセージのサイズがある閾値を超えるであろうことを決定することと、
前記第２のデバイスから前記第１のデバイスに、前記見込まれるＬＰＰメッセージに対応する情報を備える複数のＬＰＰメッセージセグメントを送信することとを備え、前記複数のＬＰＰメッセージセグメントが、１つまたは複数の最後ではないＬＰＰメッセージセグメントと最後のＬＰＰメッセージセグメントとを備え、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、前記それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、
前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であることの指示を含む、方法。
［Ｃ１４］
前記第１のデバイスがエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備え、前記第２のデバイスがユーザ機器（ＵＥ）を備え、または、
前記第１のデバイスがＵＥを備え、前記第２のデバイスがＥ－ＳＭＬＣもしくはＬＭＦを備える、Ｃ１３に記載の方法。
［Ｃ１５］
前記第１のＬＰＰメッセージが、ＬＰＰ能力要求メッセージ、ＬＰＰ能力提供メッセージ、またはＬＰＰ位置情報要求メッセージを備える、Ｃ１３に記載の方法。
［Ｃ１６］
前記複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントが、前記見込まれるＬＰＰメッセージと同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備える、Ｃ１３に記載の方法。
［Ｃ１７］
前記同じＬＰＰメッセージタイプが、ＬＰＰ能力提供メッセージタイプ、ＬＰＰ支援データ提供メッセージタイプ、ＬＰＰ支援データ要求メッセージタイプ、ＬＰＰ位置情報要求メッセージタイプ、またはＬＰＰ位置情報提供メッセージタイプを備える、Ｃ１６に記載の方法。
［Ｃ１８］
前記第１のＬＰＰメッセージを受信する前に、前記第２のデバイスが、前記第２のデバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを前記第１のデバイスに送信する、Ｃ１３に記載の方法。
［Ｃ１９］
前記第２のＬＰＰメッセージがＬＰＰ能力要求メッセージを備える、Ｃ１８に記載の方法。
［Ｃ２０］
前記第２のデバイスにおいて前記第１のデバイスから、前記複数のＬＰＰメッセージセグメントのうちの少なくとも１つの前記受信におけるエラーの決定を示すメッセージを受信することと、
前記エラーの前記決定を示す前記メッセージを受信したことに応答して、前記複数のＬＰＰメッセージセグメントと関連付けられるＬＰＰセッションを中止することとをさらに備える、Ｃ１３に記載の方法。
［Ｃ２１］
セグメント化されたロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージを受信するためのデバイスであって、
通信インターフェースと、
メモリと、
前記通信インターフェースおよび前記メモリと通信可能に結合される１つまたは複数の処理ユニットとを備え、前記処理ユニットが、前記デバイスに、
前記通信インターフェースを介して送信デバイスへ、前記デバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを送信させ、
前記第１のＬＰＰメッセージの前記送信の後で、前記通信インターフェースを介して、１つまたは複数の最後ではないＬＰＰメッセージセグメントおよび最後のＬＰＰメッセージセグメントを備える複数のＬＰＰメッセージセグメントを前記送信デバイスから受信させるように構成され、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、前記それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、
前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であることの指示を含む、デバイス。
［Ｃ２２］
前記デバイスがエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備え、前記送信デバイスがユーザ機器（ＵＥ）を備え、または、
前記デバイスがＵＥを備え、前記送信デバイスがＥ－ＳＭＬＣもしくはＬＭＦを備える、Ｃ２１に記載のデバイス。
［Ｃ２３］
前記１つまたは複数の処理ユニットが、前記第１のＬＰＰメッセージを送信する前に、前記送信デバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを前記送信デバイスから受信するように構成される、Ｃ２１に記載のデバイス。
［Ｃ２４］
前記１つまたは複数の処理ユニットがさらに、前記デバイスに、同じＬＰＰメッセージタイプのための良く形成されたＬＰＰメッセージを備える前記複数のＬＰＰメッセージセグメントの中の各ＬＰＰメッセージセグメントを受信させるように構成される、Ｃ２１に記載のデバイス。
［Ｃ２５］
前記１つまたは複数の処理ユニットがさらに、前記デバイスに、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントを前記メモリ内に記憶させ、
前記最後のＬＰＰメッセージセグメントが受信された後で前記複数のＬＰＰメッセージセグメントを処理させるように構成され、前記処理することが前記同じＬＰＰメッセージタイプに基づく、Ｃ２４に記載のデバイス。
［Ｃ２６］
前記１つまたは複数の処理ユニットがさらに、前記デバイスに、
前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの１つまたは複数を前記メモリ内に記憶させ、
前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数を記憶した後で、前記複数のＬＰＰメッセージセグメントのうちの少なくとも１つの前記受信におけるエラーを決定させ、
前記エラーを決定したことに応答して、前記複数のＬＰＰメッセージセグメントの前記最後ではないＬＰＰメッセージセグメントのうちの前記１つまたは複数を廃棄させるように構成される、Ｃ２１に記載のデバイス。
［Ｃ２７］
セグメント化されたロングタームエボリューション（ＬＴＥ）測位プロトコル（ＬＰＰ）メッセージを送信するためのデバイスであって、
通信インターフェースと、
メモリと、
前記通信インターフェースおよび前記メモリと通信可能に結合される１つまたは複数の処理ユニットとを備え、前記処理ユニットが、前記デバイスに、
前記通信インターフェースを介して、受信デバイスから、前記受信デバイスがセグメント化されたＬＰＰメッセージを受信可能であることの指示を含む第１のＬＰＰメッセージを受信させ、
前記第１のＬＰＰメッセージの前記受信の後で、見込まれるＬＰＰメッセージのサイズがある閾値を超えるであろうことを決定させ、
前記受信デバイスへ、前記通信インターフェースを介して、前記見込まれるＬＰＰメッセージに対応する情報を備える複数のＬＰＰメッセージセグメントを送信させるように構成され、前記複数のＬＰＰメッセージセグメントが、１つまたは複数の最後ではないＬＰＰメッセージセグメントと最後のＬＰＰメッセージセグメントとを備え、
前記１つまたは複数の最後ではないＬＰＰメッセージセグメントの各々の最後ではないＬＰＰメッセージセグメントが、前記それぞれの最後ではないＬＰＰメッセージセグメントが最後ではないことの指示を含み、
前記最後のＬＰＰメッセージセグメントが、前記最後のＬＰＰメッセージセグメントが最後であることの指示を含む、デバイス。
［Ｃ２８］
前記受信デバイスがエンハンストサービングモバイルロケーションセンター（Ｅ－ＳＭＬＣ）もしくは位置管理機能（ＬＭＦ）を備え、前記デバイスがユーザ機器（ＵＥ）を備え、または、
前記受信デバイスがＵＥを備え、前記デバイスがＥ－ＳＭＬＣもしくはＬＭＦを備える、Ｃ２７に記載のデバイス。
［Ｃ２９］
前記１つまたは複数の処理ユニットがさらに、前記デバイスに、前記第１のＬＰＰメッセージを受信する前に、前記デバイスがセグメント化されたＬＰＰメッセージを送信することが可能であることの指示を含む第２のＬＰＰメッセージを前記受信デバイスへ送信させるように構成される、Ｃ２７に記載のデバイス。
［Ｃ３０］
前記１つまたは複数の処理ユニットがさらに、前記デバイスに、
前記受信デバイスから、前記通信インターフェースを介して、前記複数のＬＰＰメッセージセグメントのうちの少なくとも１つの前記受信におけるエラーの決定を示すメッセージを受信させ、
前記エラーの前記決定を示す前記メッセージを受信したことに応答して、前記複数のＬＰＰメッセージセグメントと関連付けられるＬＰＰセッションを中止させるように構成される、Ｃ２７に記載のデバイス。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】