特許7556977 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 華為技術有限公司の特許一覧

特許7556977アクセス制御方法および装置、ならびに通信システム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9

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

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

(11)【特許番号】

(24)【登録日】2024-09-17

(45)【発行日】2024-09-26

(54)【発明の名称】アクセス制御方法および装置、ならびに通信システム

(51)【国際特許分類】

H04W 48/08 20090101AFI20240918BHJP

H04W 4/48 20180101ALI20240918BHJP

H04W 48/02 20090101ALI20240918BHJP

【ＦＩ】

H04W48/08

H04W4/48

H04W48/02

【請求項の数】 51

(21)【出願番号】P 2022558282

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

(65)【公表番号】

(43)【公表日】2023-05-01

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

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

(87)【国際公開日】2021-09-30

【審査請求日】2022-11-17

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩＴＥＣＨＮＯＬＯＧＩＥＳＣＯ．，ＬＴＤ．

【住所又は居所原語表記】ＨｕａｗｅｉＡｄｍｉｎｉｓｔｒａｔｉｏｎＢｕｉｌｄｉｎｇ，Ｂａｎｔｉａｎ，ＬｏｎｇｇａｎｇＤｉｓｔｒｉｃｔ，Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８１２９，Ｐ．Ｒ．Ｃｈｉｎａ

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村進

(72)【発明者】

【氏名】▲劉▼ 航

(72)【発明者】

【氏名】▲張▼ ▲興▼新

(72)【発明者】

【氏名】▲楊▼ 常青

【審査官】本橋史帆

(56)【参考文献】

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

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

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

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

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

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

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

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

【請求項1】

第1のデバイスによって実行されるアクセス制御方法であって、
前記第1のデバイスのステータスが第1のステータスであると判定するステップであって、前記第1のステータスは、少なくとも1つの第3のデバイスの所定の動作状態に基づいて決定される、ステップと、
前記第1のステータスに基づいて決定された第1のインジケーション情報を送信するステップであって、前記第1のインジケーション情報が、前記第1のデバイスへの少なくとも1つの第2のデバイスのアクセスが許可されるかどうかを示すために使用される、ステップとを含む、アクセス制御方法。

【請求項2】

前記第1のステータスが、システム準備状態および車載デバイスアクセス状態のうちの少なくとも1つを含み、前記第1のインジケーション情報が、前記少なくとも1つの第2のデバイスのアクセスが許可されないことを示すために使用され、前記システム準備状態または前記車載デバイスアクセス状態は、前記少なくとも1つの第3のデバイスが前記第1のデバイスにアクセスしていること、または、前記少なくとも1つの第3のデバイスがセルフチェックを実行していることを示すために使用され、または
前記第1のステータスが、システム実行状態およびアクセス許可状態のうちの少なくとも1つを含み、前記第1のインジケーション情報が、前記第2のデバイスのアクセスが許可されることを示すために使用され、前記システム実行状態または前記アクセス許可状態は、前記少なくとも1つの第3のデバイスが前記第1のデバイスにアクセスしたことを示すために使用される請求項1に記載のアクセス制御方法。

【請求項3】

前記第1のインジケーション情報が、前記少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される請求項1または2に記載のアクセス制御方法。

【請求項4】

前記第1のインジケーション情報が、デバイスタイプ情報を含み、前記少なくとも1つの第2のデバイスのデバイスタイプが、前記デバイスタイプ情報によって示される少なくとも1つのデバイスタイプに属する請求項1から3のいずれか一項に記載のアクセス制御方法。

【請求項5】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項4に記載のアクセス制御方法。

【請求項6】

前記第1のインジケーション情報が、優先順位情報を含み、前記少なくとも1つの第2のデバイスの優先順位が、前記優先順位情報によって示される少なくとも1つの優先順位に属する請求項1から4のいずれか一項に記載のアクセス制御方法。

【請求項7】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項6に記載のアクセス制御方法。

【請求項8】

前記第1のインジケーション情報が、第1の時間情報を含み、前記第1の時間情報が、前記少なくとも1つの第2のデバイスが第1の時間の範囲内に前記第1のデバイスにアクセスすることを許可されないことを示すために使用される請求項4から6のいずれか一項に記載のアクセス制御方法。

【請求項9】

前記第1の時間の範囲が、第1の基準フレームに対する時間領域オフセット、または第1のシグナリングに対する時間領域オフセットである請求項8に記載のアクセス制御方法。

【請求項10】

前記第1のインジケーション情報が、リソースインジケーション情報を含み、前記リソースインジケーション情報が、前記少なくとも1つの第3のデバイスのために使用されるリソースを示し、または前記リソースインジケーション情報によって示される前記リソースが、前記少なくとも1つの第2のデバイスのために使用されない請求項1から9のいずれか一項に記載のアクセス制御方法。

【請求項11】

前記リソースインジケーション情報によって示される前記リソースと、前記少なくとも1つの第3のデバイスのデバイスタイプおよび/または優先順位との間に対応関係が存在する請求項10に記載のアクセス制御方法。

【請求項12】

第2のデバイスによって実行されるアクセス方法であって、
第1のデバイスから、前記第1のデバイスの第1のステータスに基づいて決定された第1のインジケーション情報を受信するステップであって、前記第1のステータスは、少なくとも1つの第3のデバイスの所定の動作状態に基づいて決定される、ステップと、
前記第1のインジケーション情報に基づいて、前記第1のデバイスへの前記第2のデバイスのアクセスが許可されるかどうかを判定するステップとを含む、アクセス方法。

【請求項13】

前記第1のインジケーション情報が、前記少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される請求項12に記載のアクセス方法。

【請求項14】

前記第1のインジケーション情報が、デバイスタイプ情報を含み、前記第2のデバイスのデバイスタイプが、前記デバイスタイプ情報によって示される少なくとも1つのデバイスタイプに属する請求項12または13に記載のアクセス方法。

【請求項15】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項14に記載のアクセス方法。

【請求項16】

前記第1のインジケーション情報が、優先順位情報を含み、前記第2のデバイスの優先順位が、前記優先順位情報によって示される少なくとも1つの優先順位に属する請求項12から15のいずれか一項に記載のアクセス方法。

【請求項17】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項16に記載のアクセス方法。

【請求項18】

前記第1のインジケーション情報が、第1の時間情報を含み、前記第1の時間情報が、前記第2のデバイスが第1の時間の範囲内に前記第1のデバイスにアクセスすることを許可されないことを示すために使用される請求項12から17のいずれか一項に記載のアクセス方法。

【請求項19】

前記第1の時間の範囲が、第1の基準フレームに対する時間領域オフセット、または第1のシグナリングに対する時間領域オフセットである請求項18に記載のアクセス方法。

【請求項20】

前記第1のインジケーション情報が、リソースインジケーション情報を含み、前記リソースインジケーション情報が、前記少なくとも1つの第3のデバイスのために使用されるリソースを示し、または前記リソースインジケーション情報によって示される前記リソースが、前記第2のデバイスのために使用されない請求項12から19のいずれか一項に記載のアクセス方法。

【請求項21】

前記リソースインジケーション情報によって示される前記リソースと、前記少なくとも1つの第3のデバイスのデバイスタイプおよび/または優先順位との間に対応関係が存在する請求項20に記載のアクセス方法。

【請求項22】

前記第1のインジケーション情報が、ブール変数または列挙変数を含む請求項12から21のいずれか一項に記載のアクセス方法。

【請求項23】

前記第1のデバイスが、制御ドメインコックピットCDCであり、前記第3のデバイスが、車載デバイスであり、前記第2のデバイスが、非車載デバイスである請求項13に記載のアクセス方法。

【請求項24】

前記第2のデバイスが、モバイル電話である請求項23に記載のアクセス方法。

【請求項25】

アクセス制御のための第1のデバイスであって、
前記第1のデバイスのステータスが第1のステータスであると判定するように構成された処理ユニットであって、前記第1のステータスは、少なくとも1つの第3のデバイスの所定の動作状態に基づいて決定される、処理ユニットと、
前記第1のステータスに基づいて決定された第1のインジケーション情報を送信するように構成された送信ユニットであって、前記第1のインジケーション情報が、前記第1のデバイスへの少なくとも1つの第2のデバイスのアクセスが許可されるかどうかを示すために使用される、送信ユニットとを含む、第1のデバイス。

【請求項26】

【請求項27】

前記第1のインジケーション情報が、前記少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される請求項25に記載の第1のデバイス。

【請求項28】

前記第1のインジケーション情報が、デバイスタイプ情報を含み、前記少なくとも1つの第2のデバイスのデバイスタイプが、前記デバイスタイプ情報によって示される少なくとも1つのデバイスタイプに属する請求項25から27のいずれか一項に記載の第1のデバイス。

【請求項29】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項28に記載の第1のデバイス。

【請求項30】

前記第1のインジケーション情報が、優先順位情報を含み、前記少なくとも1つの第2のデバイスの優先順位が、前記優先順位情報によって示される少なくとも1つの優先順位に属する請求項25から28のいずれか一項に記載の第1のデバイス。

【請求項31】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項30に記載の第1のデバイス。

【請求項32】

前記第1のインジケーション情報が、第1の時間情報を含み、前記第1の時間情報が、前記少なくとも1つの第2のデバイスが第1の時間の範囲内に前記第1のデバイスにアクセスすることを許可されないことを示すために使用される請求項28から30のいずれか一項に記載の第1のデバイス。

【請求項33】

前記第1の時間の範囲が、第1の基準フレームに対する時間領域オフセット、または第1のシグナリングに対する時間領域オフセットである請求項32に記載の第1のデバイス。

【請求項34】

前記第1のインジケーション情報が、リソースインジケーション情報を含み、前記リソースインジケーション情報が、前記少なくとも1つの第3のデバイスのために使用されるリソースを示し、または前記リソースインジケーション情報によって示される前記リソースが、前記少なくとも1つの第2のデバイスのために使用されない請求項25から33のいずれか一項に記載の第1のデバイス。

【請求項35】

前記リソースインジケーション情報によって示される前記リソースと、前記少なくとも1つの第3のデバイスのデバイスタイプおよび/または優先順位との間に対応関係が存在する請求項34に記載の第1のデバイス。

【請求項36】

受信ユニットと、処理ユニットとを含む第2のデバイスであって、
前記受信ユニットが、第1のデバイスから、前記第1のデバイスの第1のステータスに基づいて決定された第1のインジケーション情報を受信するように構成され、前記第1のステータスは、少なくとも1つの第3のデバイスの所定の動作状態に基づいて決定される、
前記処理ユニットが、前記第1のインジケーション情報に基づいて、前記第1のデバイスへの第2のデバイスのアクセスが許可されるかどうかを判定するように構成される第2のデバイス。

【請求項37】

前記第1のインジケーション情報が、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される請求項36に記載の第2のデバイス。

【請求項38】

前記第1のインジケーション情報が、デバイスタイプ情報を含み、前記第2のデバイスのデバイスタイプが、前記デバイスタイプ情報によって示される少なくとも1つのデバイスタイプに属する請求項36または37に記載の第2のデバイス。

【請求項39】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項38に記載の第2のデバイス。

【請求項40】

前記第1のインジケーション情報が、優先順位情報を含み、前記第2のデバイスの優先順位が、前記優先順位情報によって示される少なくとも1つの優先順位に属する請求項36から39のいずれか一項に記載の第2のデバイス。

【請求項41】

前記第1のインジケーション情報が、アクセスインジケーション情報をさらに含み、前記アクセスインジケーション情報が、前記第1のデバイスへのアクセスが許可されるかどうかを示すために使用される請求項40に記載の第2のデバイス。

【請求項42】

前記第1のインジケーション情報が、第1の時間情報を含み、前記第1の時間情報が、前記第2のデバイスが第1の時間の範囲内に前記第1のデバイスにアクセスすることを許可されないことを示すために使用される請求項36から41のいずれか一項に記載の第2のデバイス。

【請求項43】

前記第1の時間の範囲が、第1の基準フレームに対する時間領域オフセット、または第1のシグナリングに対する時間領域オフセットである請求項42に記載の第2のデバイス。

【請求項44】

前記第1のインジケーション情報が、リソースインジケーション情報を含み、前記リソースインジケーション情報が、前記少なくとも1つの第3のデバイスのために使用されるリソースを示し、または前記リソースインジケーション情報によって示される前記リソースが、前記第2のデバイスのために使用されない請求項36から43のいずれか一項に記載の第2のデバイス。

【請求項45】

前記リソースインジケーション情報によって示される前記リソースと、前記少なくとも1つの第3のデバイスのデバイスタイプおよび/または優先順位との間に対応関係が存在する請求項44に記載の第2のデバイス。

【請求項46】

前記第1のインジケーション情報が、ブール変数または列挙変数を含む請求項36から45のいずれか一項に記載の第2のデバイス。

【請求項47】

前記第1のデバイスが、制御ドメインコックピットCDCであり、前記第3のデバイスが、車載デバイスであり、前記第2のデバイスが、非車載デバイスである請求項37に記載の第2のデバイス。

【請求項48】

前記第2のデバイスが、モバイル電話である請求項47に記載の第2のデバイス。

【請求項49】

コンピュータ命令を含み、前記コンピュータ命令が少なくとも1つのプロセッサによって実行されるとき、請求項1から24のいずれか一項に記載の方法が実施されるコンピュータストレージ媒体。

【請求項50】

請求項25から35のいずれか一項に記載の第1のデバイスを含む通信システム。

【請求項51】

請求項36から48のいずれか一項に記載の第2のデバイスをさらに含む請求項50に記載の通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、通信の分野に関し、詳細には、近距離通信、たとえば、コックピットドメイン通信(cockpit domain communication)のために特に使用される差別化されたアクセス制御(differentiated access control)の方法および装置ならびに通信デバイスに関する。

【背景技術】

【0002】

BluetoothおよびWi-Fiなどの近距離通信テクノロジーは、人々の日常生活において非常に重要な役割を担う。車両(vehicle)がますます使用され、より普及するにつれて、近距離通信テクノロジーの機能が、より目立つようになる。科学技術の発展に伴い、車両の先進運転支援システム(advanced driving assistance system、ADAS)および自動運転システム(automated driving system、ADS)は、絶えず進化する。将来、車両の運転は、機械によって実施される可能性が極めて高く、その結果、人は、手および足を使って運転する必要がなくなる。ユーザの輸送デバイスであることに加えて、車両は、日常生活の生活空間の1つである。スマートコックピットテクノロジーを使用することによって、大量の機能、たとえば、豊富なエンターテインメント活動、オーディオおよびビデオの再生、ならびにオフィス環境が、車両内の人々に提供され得る。結果として、人々は、車両内で仕事をしたり、カスタマイズされたオーディオおよびビデオエンターテインメントサービスを楽しんだり、カスタマイズされた走行体験をしたりすることができる。

【0003】

現在、スマートコックピットは、主に、コックピットドメインコントローラ(cockpit domain controller、CDC)、車載デバイス、および非車載デバイスを含む。CDCは、主に有線で車載デバイスに接続され、CDCは、主にワイヤレスで非車載デバイスに接続される。しかし、CDCが有線で車載デバイスに接続されるので、この方法では大量のケーブルが必要とされ、したがって、コストが高い。車両内の狭いスペースのために、車載デバイスの量が増えるにつれて、配線が難しくなる。ケーブルの配線および高いコストは、スマートコックピットテクノロジーの開発の制約となる。したがって、CDCと車載デバイスまたは非車載デバイスとをワイヤレスで接続することが、解決すべき緊急の課題となる。

【発明の概要】

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

【0004】

本出願の実施形態は、ユニバーサル送信(universal transmission)の分野に適用されるアクセス制御方法を提供する。システムステータス情報またはアクセスインジケーション情報を運ぶ情報要素が、現在のシステム状態を示すために送信され、その結果、前述の情報を受信した後、非車載デバイスが、ランダムアクセス要求を開始するべきかどうかを判定する。非車載デバイスのアクセスは、特定のフェーズにおいて制限される。これは、CDCによる車載デバイスのステータスのチェックおよび車載デバイスのアクセスに対して、このフェーズにおいて非車載デバイスによって実行されるランダムアクセス要求の開始によって引き起こされる影響を回避する。また、これは、車載デバイスが正常に実行されることが可能であり、いくつかの基本的なサービスが正常に実行されることが可能であることを保証する。

【0005】

第1の態様によれば、本出願は、アクセス制御方法を提供する。方法は、第1のデバイスのステータスが第1のステータスであると判定するステップと、第1のインジケーション情報を送信するステップであって、第1のインジケーション情報が、第1のデバイスへの少なくとも1つの第2のデバイスのアクセスが許可されるかどうかを示すために使用される、ステップとを含む。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信される。第1のインジケーション情報は、マスタ情報ブロック(master information block、MIB)、システム情報ブロック(system information block、SIB)、またはブロードキャストフレーム(broadcast frame)であってよい。MIBは、物理ブロードキャストチャネル(physical broadcast channel、PBCH)上で運ばれてよい。SIBは、通常、無線リソース制御(radio resource control、RRC)シグナリングに含まれる。任意選択で、第1のインジケーション情報は、ブロードキャストによって送信される。

【0006】

可能な実装において、第1のステータスは、システム準備状態および車載デバイスアクセス状態のうちの少なくとも1つを含み、第1のインジケーション情報は、少なくとも1つの第2のデバイスのアクセスが許可されないことを示すために使用され、または第1のステータスは、システム実行状態およびアクセス許可状態のうちの少なくとも1つを含み、第1のインジケーション情報は、第2のデバイスのアクセスが許可されることを示すために使用される。システム準備状態および/または車載デバイスアクセス状態は、車載デバイスが制御ドメインコックピット(control domain cockpit)CDCにアクセスしていること、または車載デバイスがセルフチェックを実行していることを示すために使用されてよく、したがって、非車載デバイスは、これらの種類のシステム状態に基づいて、制御ドメインコックピットCDCにアクセスしないことを選択する。システム実行状態および/またはアクセス許可状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしたことを示すために使用されてよい。この場合、非車載デバイスは、制御ドメインコックピットCDCにアクセスすることを許可されてよい。

【0007】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0008】

可能な実装において、第1のインジケーション情報は、デバイスタイプ情報を含み、少なくとも1つの第2のデバイスのデバイスタイプは、デバイスタイプ情報によって示される少なくとも1つのデバイスタイプに属する。さらに、第2のデバイスは、デバイスタイプ情報に基づいて、第1のデバイスにアクセスするべきかどうかを判定する。

【0009】

可能な実装において、第1のインジケーション情報は、アクセスインジケーション情報をさらに含み、アクセスインジケーション情報は、第1のデバイスへのアクセスが許可されるかどうかを示すために使用される。

【0010】

可能な実装において、第1のインジケーション情報は、優先順位情報を含み、少なくとも1つの第2のデバイスの優先順位は、優先順位情報によって示される少なくとも1つの優先順位に属する。

【0011】

可能な実装において、第1のインジケーション情報は、アクセスインジケーション情報をさらに含み、アクセスインジケーション情報は、第1のデバイスへのアクセスが許可されるかどうかを示すために使用される。さらに、第2のデバイスは、優先順位情報およびアクセスインジケーション情報に基づいて、第1のデバイスにアクセスするべきかどうかを判定する。

【0012】

可能な実装において、第1のインジケーション情報は、第1の時間情報を含み、第1の時間情報は、第1のデバイスへの少なくとも1つの第2のデバイスのアクセスが第1の時間の範囲内に許可されないことを示すために使用される。

【0013】

【0014】

可能な実装において、第1のインジケーション情報は、リソースインジケーション情報を含み、リソースインジケーション情報は、少なくとも1つの第3のデバイスのために使用されるリソースを示し、またはリソースインジケーション情報によって示されるリソースは、少なくとも1つの第2のデバイスのために使用されない。

【0015】

可能な実装においては、リソースインジケーション情報によって示されるリソースと、少なくとも1つの第3のデバイスのデバイスタイプおよび/または優先順位との間に対応関係が存在する。

【0016】

可能な実装において、第1のインジケーション情報は、ブール変数または列挙変数を含む。確かに、代替的に、任意のその他の等価な種類の変数が、含まれてよい。

【0017】

可能な実装において、デバイスタイプは、車載デバイスおよび非車載デバイスのうちの少なくとも1つを含む。

【0018】

第2の態様によれば、本出願は、アクセス方法を提供する。方法は、第1のデバイスから第1のインジケーション情報を受信するステップと、第1のインジケーション情報に基づいて、第1のデバイスへの第2のデバイスのアクセスが許可されるかどうかを判定するステップとを含む。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信されてよい。たとえば、システムメッセージは、システムブロードキャストメッセージであってよい。第1のインジケーション情報は、MIB、SIB、またはブロードキャストフレームであってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリングに含まれる。

【0019】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0020】

【0021】

【0022】

【0023】

【0024】

【0025】

【0026】

【0027】

【0028】

【0029】

可能な実装において、CDCは、制御ドメインコックピットまたは制御ドメインコックピットCDCとも呼ばれ、第1のデバイスは、制御ドメインコックピットCDCであり、第3のデバイスは、車載デバイスであり、第2のデバイスは、非車載デバイスである。

【0030】

可能な実装において、第2のデバイスは、モバイル電話である。

【0031】

第3の態様によれば、本出願は、アクセス制御装置を提供する。アクセス制御装置は、第1のデバイスであってよく、または第1のデバイス内のチップまたは集積回路であってよい。たとえば、アクセス制御装置は、制御ドメインコックピットCDCであり、またはアクセス制御装置は、制御ドメインコックピットCDC内のチップもしくは集積回路である。確かに、アクセス制御装置は、代替的に、モバイル電話、タブレットコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ(ultra-mobile personal computer、UMPC)、ネットブック、セルラ電話、携帯情報端末(personal digital assistant、PDA)、拡張現実(augmented reality、AR)デバイス、仮想現実(virtual reality、VR)デバイス、人工知能(artificial intelligence、AI)デバイス、ウェアラブルデバイス、車載デバイス、スマートホームデバイス、および/またはスマートシティデバイスであってよい。第1のデバイスの特定の種類は、本出願のこの実施形態において限定されない。装置は、第1のデバイスのステータスが第1のステータスであると判定するように構成された処理ユニットと、第1のインジケーション情報を送信するように構成された送信ユニットであって、第1のインジケーション情報が、第1のデバイスへの少なくとも1つの第2のデバイスのアクセスが許可されるかどうかを示すために使用される、送信ユニットとを含む。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信される。第1のインジケーション情報は、MIB、SIB、またはブロードキャストフレーム(broadcast frame)であってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリングに含まれる。任意選択で、第1のインジケーション情報は、ブロードキャストによって送信される。

【0032】

可能な実装において、第1のステータスは、システム準備状態および車載デバイスアクセス状態のうちの少なくとも1つを含み、第1のインジケーション情報は、少なくとも1つの第2のデバイスのアクセスが許可されないことを示すために使用され、または第1のステータスは、システム実行状態およびアクセス許可状態のうちの少なくとも1つを含み、第1のインジケーション情報は、第2のデバイスのアクセスが許可されることを示すために使用される。システム準備状態および/または車載デバイスアクセス状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしていること、または車載デバイスがセルフチェックを実行していることを示すために使用されてよく、したがって、非車載デバイスは、これらの種類のシステム状態に基づいて、制御ドメインコックピットCDCにアクセスしないことを選択する。システム実行状態および/またはアクセス許可状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしたことを示すために使用されてよい。この場合、非車載デバイスは、制御ドメインコックピットCDCにアクセスすることを許可されてよい。

【0033】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0034】

【0035】

【0036】

【0037】

【0038】

【0039】

【0040】

【0041】

【0042】

【0043】

可能な実装において、デバイスタイプは、車載デバイスおよび非車載デバイスのうちの少なくとも1つを含む。

【0044】

第4の態様によれば、本出願は、アクセス装置を提供する。アクセス装置は、第2のデバイスであってよく、または第2のデバイス内のチップまたは集積回路であってよい。たとえば、アクセス装置は、車載デバイスまたは非車載デバイス内のチップまたは集積回路である。確かに、アクセス装置は、代替的に、モバイル電話、タブレットコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、ノートブックコンピュータ、UMPC、ネットブック、セルラ電話、PDA、ARデバイス、VRデバイス、AIデバイス、ウェアラブルデバイス、車載デバイス、スマートホームデバイス、および/またはスマートシティデバイスであってよい。第1のデバイスの特定の種類は、本出願のこの実施形態において限定されない。装置は、受信ユニットおよび処理ユニットを含む。受信ユニットは、第1のデバイスから第1のインジケーション情報を受信するように構成される。処理ユニットは、第1のインジケーション情報に基づいて、第1のデバイスへの第2のデバイスのアクセスが許可されるかどうかを判定するように構成される。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信されてよい。たとえば、システムメッセージは、システムブロードキャストメッセージであってよい。第1のインジケーション情報は、MIB、SIB、またはブロードキャストフレームであってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリングに含まれる。

【0045】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0046】

【0047】

【0048】

【0049】

【0050】

【0051】

【0052】

【0053】

【0054】

【0055】

可能な実装において、第1のデバイスは、制御ドメインコックピットCDCであり、第3のデバイスは、車載デバイスであり、第2のデバイスは、非車載デバイスである。

【0056】

可能な実装において、第2のデバイスは、モバイル電話である。

【0057】

第5の態様によれば、本出願は、コンピュータストレージ媒体を提供し、コンピュータストレージ媒体は、コンピュータ命令を含む。コンピュータ命令が少なくとも1つのプロセッサによって実行されるとき、第1の態様および第2の態様の方法が実施される。

【0058】

第6の態様によれば、本出願は、コンピュータプログラム製品を提供する。コンピュータプログラム製品に含まれるプログラムコードが電子デバイス内のプロセッサによって実行されるとき、第1の態様および第2の態様における方法が実施される。

【0059】

第7の態様によれば、本出願は、通信システムを提供する。システムは、第3の態様の任意の実装に係るアクセス制御装置を含む。

【0060】

可能な実装においては、第4の態様の任意の実装に係るアクセス装置がさらに含まれる。

【0061】

本出願は、アクセス制御方法および装置、ならびに通信システムを提供する。システムステータス情報、時間の閾値、および/またはアクセスインジケーション情報を運ぶ情報要素が、現在のシステム状態を示すために送信され、その結果、非車載デバイスが前述の新しい情報を受信した後、非車載デバイスは、ランダムアクセス要求を開始するべきかどうかを判定する。これは、CDCによる車載デバイスのステータスのチェックおよび車載デバイスのアクセスに対して、このフェーズにおいて非車載デバイスによって実行されるランダムアクセス要求の開始によって引き起こされる影響を回避する。また、これは、車載デバイスが正常に実行されることが可能であり、いくつかの基本的なサービスが正常に実行されることが可能であることを保証する。

【図面の簡単な説明】

【0062】

【図1】本出願の実施形態に係る応用のシナリオの概略図である。

【図2】本出願の実施形態に係るCDCと、車載デバイスと、非車載デバイスとの間の情報交換の図である。

【図3】本出願の実施形態に係るCDCと、車載デバイスと、非車載デバイスとの間の別の種類の情報交換の図である。

【図4】本出願の実施形態に係るCDCと、車載デバイスと、非車載デバイスとの間のさらに別の種類の情報交換の図である。

【図5】本出願の実施形態に係るアクセス制御方法の流れ図である。

【図6】本出願の実施形態に係る別のアクセス制御方法の流れ図である。

【図7】本出願の実施形態に係るアクセス制御装置の概略図である。

【図8】本出願の実施形態に係るアクセス装置の概略図である。

【図9】本出願の実施形態に係る通信システムの概略図である。

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

【0063】

以下で、本出願の実施形態の技術的なソリューションを本出願の実施形態の添付の図面を参照して説明する。

【0064】

説明を容易にするために、車両に適用されるスマートコックピットのシナリオが、本出願を説明するための例として使用される。しかし、本出願は、車両のシナリオに限定されない。本出願のソリューションは、別のシナリオの近距離通信に使用されてもよい。図1は、本出願の実施形態に係る応用の筋書きの概略図である。図1に示されるように、このシナリオは、主に車両内のスマートコックピット環境に存在し、スマートコックピット環境は、CDC、車載デバイス、および非車載デバイスを含んでよい。車載デバイスおよび非車載デバイスは、異なる属性を有する2種類のノードである。車載デバイスは、車載マイク、車載スピーカ、および車載スクリーンなどの車両内の任意の電子デバイスを含んでよいがこれらに限定されない。通常、車載デバイスは、車両製造業者(vehicle/car manufacturer)によって統合される。車載デバイスおよびCDCの統合は、通常、1つの車両製造業者によって実行されるので、車載デバイスとCDCとの間の接続関係は固定的である。固定的な接続関係は、たとえば、固定的なトポロジーの通信関係である場合がある。確かに、車載デバイスとCDCとの間の固定的な接続関係は、有線接続またはワイヤレス接続であってよい。非車載デバイスは、車両に属さない任意の可搬型電子デバイス、たとえば、モバイル電話、ヘッドセット、ウェアラブルデバイス、タブレットコンピュータ、ノートブックコンピュータ、デジタルカメラ、携帯情報端末(personal digital assistant、PDA)、またはラップトップ(laptop)コンピュータを含んでよいがこれらに限定されない。CDCは、車載デバイスおよび非車載デバイスに有線またはワイヤレスで接続されて、車載デバイスおよび非車載デバイスを制御または管理し、スマートコックピット環境のための様々な機能を提供する。

【0065】

車両が、地上を車輪で移動する輸送手段であり、自動車、スクーター、トラック、バスなどを含むがこれらに限定されないことは理解されるであろう。CDCは、車両内に設置されたインフォテインメント製品に接続され、車両内のインフォテインメント製品を制御する。機能面では、CDCは、人が車載インフォテインメント設備および関連デバイスを制御することを可能にし、車両と外部環境との間の情報通信を実施するために使用される場合もある。CDCが、通常、制御ドメインコックピットまたは制御ドメインコックピットCDCと呼ばれることは理解されるであろう。本出願において使用される「CDC」、「制御ドメインコックピットCDC」、および「制御ドメインコックピット」は、すべて同じ意味を有する。

【0066】

ワイヤレス接続の場合、制御ドメインコックピットCDCは、無線リソースの全体的な管理および調整を担い、データ送信のために様々な種類のデバイスを配置する必要がある。車載デバイスおよび制御ドメインコックピットCDCは、通常、1つの車両製造業者によって統合されるので、制御ドメインコックピットCDCの関連情報は、車載デバイスに予め構成されている場合があり、車載デバイスの関連情報は、制御ドメインコックピットCDCに予め構成されている場合がある。たとえば、車載デバイスは、車両のプロパティを有し、したがって、車載デバイスは、認証およびアクセスを迅速に実行することができる。しかし、非車載デバイスの存在は不確かであり、非車載デバイスと制御ドメインコックピットCDCとの間には予め構成された関連情報はほとんどない。非車載デバイスが制御ドメインコックピットCDCに接続されるとき、接続および通信を成功させるためには、通常、発見、アソシエーション、およびセキュリティ認証などの手順が必要とされる。したがって、車載デバイスおよびコックピットCDCが電源をオンにされるときに、どのようにして優先的に車載デバイスのステータスを保証し、制御ドメインコックピットCDCとの接続を確立すべきかは、解決される必要がある問題である。通常、電源をオンにされるとき、制御ドメインコックピットCDCが、システムブロードキャストメッセージを送信し、その結果、すべての車載デバイスまたは非車載デバイスは、接続を開始することができる。しかし、この場合、制御ドメインコックピットCDCは、優先的に車載デバイスのステータスをチェックするかまたは知り、車載デバイスとの接続を確立するべきである。非車載デバイスのアクセスによって引き起こされるこのプロセスの中断は、制御ドメインコックピットCDCによって予測されない。

【0067】

したがって、本出願においては、制御ドメインコックピットCDCのステータスが判定され、次いで、ステータスがシステムブロードキャストメッセージの情報要素内で運ばれ、ブロードキャストによって非車載デバイスに送信され、その結果、非車載デバイスが、アクセスを実行すべきかどうかを、制御ドメインコックピットCDCのステータスに基づいて判定する。このようにして、車載デバイスによる制御ドメインコックピットCDCへのアクセスが、非車載デバイスのアクセスに影響されないことが保証される。したがって、車載デバイスが正常に実行され、基本的なサービス機能を実施することが、優先的に保証される。

【0068】

本出願における「XX情報」および「XXメッセージ」が同じ意味を有することは、理解されるであろう。

【0069】

以下で、本出願の実施形態の技術的なソリューションを本出願の実施形態の添付の図面を参照して詳細に説明する。

【0070】

図2は、本出願の実施形態に係る制御ドメインコックピットCDCと、車載デバイスと、非車載デバイスとの間の情報交換の図である。

【0071】

本出願は、通信システムに関し、システムは、マスタノードおよびスレーブノードを含む。

【0072】

マスタノードおよびスレーブノードは、論理的な機能によって区別される2種類のノードである。マスタノードは、スレーブノードを管理する。マスタノードは、リソースをスケジューリングすることができ、スレーブノードのための時間周波数リソースのスケジューリングを担う。スレーブノードは、マスタノードによってスケジューリングされた時間周波数リソースを使用してマスタノードと通信する。マスタノードは、アクセス制御装置、たとえば、制御ドメインコックピットCDC、またはアクセス制御機能を有する別の装置であってよい。スレーブノードは、アクセス装置、たとえば、車載デバイスまたは非車載デバイスであってよい。

【0073】

当業者は、本出願の技術的ソリューションが、本出願において提供される通信方法を適用することができる任意の種類の第1のデバイス、第2のデバイス、および第3のデバイスに適用されることが可能であり、第2のデバイスおよび第3のデバイスが、第1のデバイスと通信することができる異なる種類のデバイスであることを知るであろう。

【0074】

本出願は、図1に示されたスマートコックピット環境に適用されることが可能であり、同様のデバイスの関係が存在するスマートホーム環境、スマートオフィス環境、または同様のデバイスの関係が存在する任意のその他の環境に適用されることも可能である。たとえば、環境内のデバイスは、モバイル電話、タブレットコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、ノートブックコンピュータ、UMPC、ネットブック、セルラ電話、PDA、ARデバイス、VRデバイス、AIデバイス、ウェアラブルデバイス、車載デバイス、スマートホームデバイス、および/またはスマートシティデバイスであってよい。第1のデバイス、第2のデバイス、および第3のデバイスの特定の種類は、本出願の実施形態において限定されない。

【0075】

本出願の以下の実施形態においては、第1のデバイスと、第2のデバイスと、第3のデバイスとの間のインタラクションが、主に、制御ドメインコックピットCDCと、車載デバイスと、非車載デバイスとの間のインタラクションを例として用いることによって説明されることに留意されたい。しかし、本出願において、第1のデバイスは、制御ドメインコックピットCDCに限定されず、第2のデバイスは、非車載デバイスに限定されず、第3のデバイスは、車載デバイスに限定されない。以下の実施形態においては、制御ドメインコックピットCDCが第1のデバイスによって置き換えられてよく、車載デバイスが第3のデバイスによって置き換えられてよく、非車載デバイスが第2のデバイスによって置き換えてられてよいことは、理解されるであろう。

【0076】

通常、車両が始動された後、制御ドメインコックピットCDCおよび車載デバイスが電源をオンにされ、起動されることが図2から知られ得る。

【0077】

S201. 第1のインジケーションメッセージを送信する。

【0078】

制御ドメインコックピットCDCが、第1のインジケーションメッセージを送信し、その結果、車載デバイスまたは非車載デバイスが、第1のインジケーションメッセージを受信し、対応する動作を実行する。

【0079】

任意選択で、第1のインジケーションメッセージは、システムメッセージ(system information)内で運ばれてよく、またはブロードキャストによって送信されてよい。たとえば、システムメッセージは、システムブロードキャストメッセージであってよい。本出願の以下の説明においては、システムブロードキャストメッセージが、例として使用される。ある程度、第1のインジケーションメッセージは、システムブロードキャストメッセージと考えられてよい。システムブロードキャストメッセージは、MIB、SIB、またはブロードキャストフレームであってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリング上で運ばれる。本明細書では、本出願のすべての実施形態において、第1のインジケーション情報がシステムメッセージ内でのみ運ばれるかまたはブロードキャストによって送信されるというような制限はなく、第1のインジケーション情報が別の種類のシグナリングを使用することによって送信されてもよいことに留意されたい。

【0080】

概して、媒体アクセス制御(media access control、MAC)レイヤのフレームは、管理フレーム(management frame)とデータフレーム(data frame)とに分類される。データフレームは、マスタノードとスレーブノードとの間で交換されるサービスデータを運ぶために使用される。マスタノードおよびスレーブノードが互いに通信する前に、セキュリティ認証およびリソース割り振りなどの対応する動作が通信リンク上で実行され得るように、まず、マスタノードとスレーブノードとの間の通信リンクが確立される必要がある。管理フレームは、たとえば、マスタノードとスレーブノードとの間の接続の確立および解放、セキュリティ認証の実行、通信リソースの割り振りの実行、ハイバネーションおよびウェイクアップの有効化を含め、主に、スレーブノードを管理するためにマスタノードによって使用される。上述の管理機能が実施されるとき、スレーブノードによってマスタノードに送信されるメッセージも管理フレーム内で運ばれる必要があることは、理解されるであろう。

【0081】

MACフレームの受信端の観点から見て、MACフレームは、ブロードキャストフレーム、マルチキャストフレーム、およびユニキャストフレームに分類されてよい。ユニキャストフレームは、単一の受信端に送信されるMACフレームであり、マルチキャストフレームは、受信端のグループに送信されるMACフレームであり、ブロードキャストフレームは、すべての受信端に送信されるMACフレームである。確かに、第1のインジケーションメッセージを送信する方法が本出願において限定されず、第1のインジケーションメッセージがブロードキャスト、マルチキャスト、ユニキャスト、または任意のその他の等価な方法で送信されてよいことは、理解されるであろう。

【0082】

一部の実施形態においては、制御ドメインコックピットCDCがシステムブロードキャストメッセージを送信する前に、制御ドメインコックピットCDCは、さらにシステムステータスを判定し、次いで、車載デバイスまたは非車載デバイスのための対応するリソースを割り振ってよい。第1のインジケーションメッセージは、インジケーション情報を運び、インジケーション情報は、車載デバイスまたは非車載デバイスのために割り振られたリソースであってよく、車載デバイスまたは非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかを示すために使用される情報である。

【0083】

一部の例において、インジケーション情報は、車載デバイスまたは非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかを示すことによって表されてよい。たとえば、車載デバイスAに送信される第1のインジケーションメッセージが、「制御ドメインコックピットCDCへのアクセスが許可される」ことを表す情報を運ぶか、または非車載デバイスBに送信される第1のインジケーションメッセージが、「制御ドメインコックピットCDCへのアクセスが許可されない」ことを表す情報を運ぶ。情報は、情報要素またはいくつかのビットによって表されてよい。別の例として、インジケーション情報は、システムステータスインジケーション情報であってよい。システムステータスインジケーション情報を受信した後、車載デバイスまたは非車載デバイスは、システムステータスに基づいて、制御ドメインコックピットCDCへのアクセスが許可されるかどうかを判定してよい。

【0084】

たとえば、制御ドメインコックピットCDCが電源をオンされるときに、制御ドメインコックピットCDCは、制御ドメインコックピットCDC上で現在実行されているシステムのシステムステータスを判定し、次いで、第1のインジケーションメッセージを生成してよい。第1のインジケーションメッセージは、システムステータスインジケーション情報を運んでよい。システムステータスインジケーション情報は、制御ドメインコックピットCDC上で実行されるシステムのシステムステータスを示すために使用されるステータスインジケーション用に使用される要素であってよい。例において、システムステータスインジケーション情報は、ブール変数であってよい。たとえば、1ビットの異なる状態が、異なるインジケーションを表す場合がある。別の例において、システムステータスインジケーション情報は、代替的に、列挙型であってよい。確かに、当業者は、システムステータスインジケーション情報が、代替的に、任意のその他の等価なデータ型であってよいことを知っているはずである。これは、本出願の本明細において限定されない。

【0085】

確かに、一部のその他の例において、インジケーション情報は、代替的に、リソース、たとえば、時間領域リソース、周波数領域リソース、コード領域リソース、時間周波数リソース、または任意のその他の等価なリソースとして表されてよい。これは、本出願の本明細において限定されない。対応するリソースが車載デバイスまたは非車載デバイスに割り振られるとき、それは、車載デバイスまたは非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されることを意味する。割り振られた対応するリソースが車載デバイスまたは非車載デバイスの応答リソースとして使用されてよく、したがって、車載デバイスまたは非車載デバイスが割り振られたリソース上で応答情報を送信することは、理解されるであろう。

【0086】

たとえば、アクセスを実行するべきデバイスの対応する応答リソースを割り振るとき、制御ドメインコックピットCDCは、アクセスを実行するべき各デバイスの対応する応答リソースを決定してよい。応答リソースは、特定の決定された時間周波数リソースであってよい。対応するデバイスが決定された時間周波数リソース上で制御ドメインコックピットCDCに応答情報を送信することができることを保証するために、各デバイスに、対応する時間周波数リソースが割り振られる。応答情報は、アクセスするデバイスのデバイスステータスを示す場合がある。したがって、第1のインジケーションメッセージは、応答リソースとアクセスするデバイスとの間の対応関係をさらに運んでよい。例において、応答リソースとアクセスするデバイスとの間の対応関係は、明示的である場合がある。たとえば、応答リソースとアクセスするデバイスとの対応関係は、システムブロードキャストメッセージ内で直接運ばれる。確かに、別の例において、応答リソースとアクセスするデバイスとの間の対応関係は、暗黙的である場合がある。たとえば、アクセスするデバイスは、予め構成された識別子(たとえば、ID)、システムブロードキャストメッセージ内で示された時間周波数リソース、および予め設定されたルールに基づいて、アクセスするデバイスの応答リソースを取得してよい。言い換えると、アクセスデバイスは取得し、予め構成された識別子(たとえば、ID)、システムブロードキャストメッセージ内で示された時間周波数リソース、および応答リソースは、予め設定されたルールまたはマッピング関係を満たす。予め設定されたルールは、プロトコルにおいて事前に合意されてよく、および/または、予め構成された識別子は、アクセスするデバイスが工場から納入される前に構成されてよく、もしくはアクセスするデバイスが制御デバイスコックピットCDCに前回接続するときにアクセスするデバイスのために制御ドメインコックピットCDCによって構成されてよい。確かに、構成された応答リソースは、代替的に、制御ドメインコックピットCDCおよびアクセスするデバイスによって事前にネゴシエーションされてよく、制御ドメインコックピットCDCは、応答メッセージについての情報を運ぶためにシステムブロードキャストメッセージを使用しない。対応するアクセスするデバイスは、ネゴシエーションされた応答メッセージに基づいて、対応する時間周波数リソース上で制御ドメインコックピットCDCにアクセスするデバイスのデバイスステータスを直接示してよい。

【0087】

一部のその他の実施形態において、制御ドメインコックピットCDCは、アクセスを実行するべき端末デバイスをさらにグループ化する場合がある。アクセスを実行するべき端末デバイスが車載デバイスである場合があり、または非車載デバイスである場合があることは、理解されるであろう。たとえば、デバイスは、デバイスの位置またはデバイスのデバイスタイプに基づいてグループ化されてよい。通常、同じ位置にある車載デバイスおよび非車載デバイスは、同じグループに分類されない。言い換えると、同じグループ内の端末デバイスは、すべて、車載デバイス、または非車載デバイス、または同じ予め設定された種類のデバイスである。任意選択で、各グループは、対応するマルチキャストアドレスを有する。確かに、グループ化が任意の基準に従って実行されてよいことは、理解されるであろう。これは、本出願の本明細において限定されない。

【0088】

制御ドメインコックピットCDCは、同じ特徴を有する端末デバイスをグループにグループ化する。車載デバイスが、例として使用される。スマートコックピット環境内の後列のスピーカおよびマイクが、1つのグループに分類されてよく、スマートコックピット環境内の前列のスピーカおよびマイクが、別のグループに分類されてよく、以下同様である。別の例として、スマートコックピット環境内のすべての位置のスピーカが、1つのグループに分類され、すべての位置のマイクが、1つのグループに分類され、以下同様である。次いで、制御ドメインコックピットCDCは、デバイスの各グループに対応する応答リソースを割り振る。割り振られた応答リソースは、グループ内のすべての端末デバイスによって使用される。各グループに割り振られた対応するリソースに関して、グループ内の端末デバイスが、特定のルールに従って、グループに割り振られた応答リソースから端末デバイスの応答リソースをさらに決定してよいことは、理解されるであろう。同様に、同様のグループ化の様式が、非車載デバイスに対して実施されてよい。

【0089】

別の例において、グループは、配列の形態であってよい。たとえば、スピーカまたはマイクは、配列内にあってよい。通常、配列内の複数の端末デバイスの物理的位置は近く、配列内の端末デバイスを管理する中央ノードが存在する。配列に関しては、配列が割り振られた応答リソース上で配列内のデバイスのステータスをフィードバックすることができるように、1つの配列に1つの応答リソースが割り振られてよい。

【0090】

例においては、車載デバイスが電源をオンにされた後、車載デバイスのセルフチェックが、車載デバイスに予め構成されたプログラムまたは命令に基づいて実行されてよい。車載デバイスのセルフチェックが、主に損傷またはエラーなどの問題が車載デバイス上で発生するかどうかをチェックして、車載デバイスが正常に実行され得ることを保証するために車載デバイスによって実行されることは、理解されるであろう。予め構成された情報は、車載デバイスに予め記憶された構成情報であってよい。例において、車載デバイスの構成情報は、車両が工場から納入される前に構成されてよく、または確かに、車載デバイスが電源をオンにされる前に別の方法で予め構成されてよい。

【0091】

一部の例において、アクセスを実行するべきデバイスは、車載デバイスである。車載デバイスの例外が発生する確率は非常に低いので、車載デバイスまたは非車載デバイスの対応する応答リソースを割り振るときに、制御ドメインコックピットCDCは、そのデバイスステータスが異常である車載デバイスのみを応答リソースを使用するよう構成してよく、その結果、異常なデバイスのみが、応答リソース上で制御ドメインコックピットCDCにデバイスステータスを送信する。

【0092】

S202. 第1のインジケーションメッセージを受信し、対応するリソースをさらに決定する。

【0093】

車載デバイスに関して、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージを受信した後、車載デバイスは、第1のインジケーションメッセージに基づいて、制御ドメインコックピットCDCへのアクセスが許可されるかどうかを判定してよい。車載デバイスが、第1のインジケーションメッセージから、車載デバイスに対応する応答リソースを取得してよい場合、車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるとみなされてよい。応答リソースとアクセスするデバイスとの対応関係が明示的である場合、各車載デバイスは、第1のインジケーションメッセージから車載デバイスに対応する応答リソースを直接取得してよいことは、理解されるであろう。確かに、応答リソースとアクセスするデバイスとの間の対応関係が暗黙的である場合、各車載デバイスは、予め構成された識別子(たとえば、ID)、システムブロードキャストメッセージ内で示された時間周波数リソース、および予め設定されたルールに基づいて計算によって、アクセスするデバイスの応答リソースを取得してよい。異なる端末デバイスに対応する応答リソースが異なっていてよく、すなわち、制御ドメインコックピットCDCが異なる端末デバイスの応答リソースをそれぞれ割り振ってよく、または応答リソースが同じであってよく、すなわち、異なる端末デバイスが同じ応答リソースを共有することは、理解されるであろう。

【0094】

一部の例においては、第1のインジケーションメッセージを受信した後、車載デバイスは、応答メッセージを生成してよい。

【0095】

各車載デバイスに関して、対応する応答リソースを取得した後、車載デバイスは、車載デバイスの応答メッセージを生成してよい。応答メッセージは、デバイスステータス情報を含む。デバイスステータス情報は、端末デバイスのデバイスステータス、たとえば、正常な状態または異常な状態を示すために使用される。確かに、一部の例において、デバイスステータス情報は、0および1によって表されてよい。たとえば、1がデバイスの正常な状態を示し、0がデバイスの異常な状態を示す。確かに、一部のその他の例においては、0がデバイスの正常な状態を示し、1がデバイスの異常な状態を示す。確かに、値、文字、または単語などの任意のその他の等価な形態が、置き換えのために使用されてよい。これは、本出願の本明細において限定されない。

【0096】

応答メッセージがデバイスのIDをさらに含んでよいことは、理解されるであろう。

【0097】

一部の例においては、異常な状態のデバイスのみが報告されることが、二者のプロトコルで合意される場合があることは、理解されるであろう。この場合、応答メッセージは、デバイスIDのみを含んでよく、デバイスIDを受信した後に、CDCは、デバイスが異常な状態であることを知る場合がある。同様に、代替的に、正常な状態のデバイスのみが報告されることがプロトコルで合意されてよく、詳細は本明細書において再び説明されない。

【0098】

一部の例において、デバイスは、デバイスIDとデバイスステータスとの両方を報告してよい。デバイス1が正常な状態である場合、応答メッセージは、デバイス1のIDを示し、状態が正常であることを示してよい。デバイス2が異常な状態である場合、応答メッセージは、デバイス2のIDを示し、状態が異常であることを示してよい。たとえば、「状態が正常である」または「状態が異常である」などの情報が、情報要素またはいくつかのビットによって表されてよい。

【0099】

一部の例において、CDCは、異常な状態のデバイスのみに応答メッセージを報告することを要求する。デバイス1およびデバイス2が1つのグループに分類され、共有された応答リソースが割り振られ、グループアドレスがID 1であると仮定される。デバイス1は、正常な状態であり、デバイス2は、異常な状態である。この場合、デバイス2は、リソース上で、デバイス2のIDまたはデバイス2が属するグループアドレスID 1を送信してよい。

【0100】

制御ドメインコックピットCDCが車載デバイスをグループ化する場合、デバイスグループは、配列の形態であってよい。配列内の複数の車載デバイスに関しては、配列内のデバイスのデバイスステータスを示すために、1つの応答メッセージが共同で生成される。たとえば、1が配列内のデバイスの正常な状態を示し、0が配列内のデバイスの異常な状態を示す。確かに、一部のその他の例においては、0が配列内のデバイスの正常な状態を示し、1が配列内のデバイスの異常な状態を示す。

【0101】

配列内のデバイスのステータスに関しては、配列内のすべてのデバイスが正常な状態である場合、デバイスグループ内のデバイスが正常な状態であるとみなされ、配列内の任意の量のデバイスが異常な状態である場合、配列内のデバイスが異常な状態であるとみなされる。確かに、別の例において、配列内のデバイスの状態は、代替的に、配列内の正常なデバイスまたは異常なデバイスの割合に基づいて判定されてよい。たとえば、正常なデバイスまたは異常なデバイスの割合が予め設定された割合の閾値より高いとき、配列内のデバイスが異常な状態であるとみなされ、そうでない場合、配列内のデバイスが正常な状態であるとみなされる。確かに、配列内のデバイスの状態は、代替的に、配列内の異常なデバイスの量に基づいて判定されてよい。たとえば、配列内の異常デバイスの量が予め設定された量の閾値を超える場合、配列内のデバイスが異常な状態であるとみなされ、それ以外の場合、配列内のデバイスが正常な状態であるとみなされる。配列内のデバイスのステータスが任意の同等の方法で判定されてよいことは、明らかである。これは、本出願の本明細において限定されない。

【0102】

一部の例においては、車載デバイスが応答メッセージを生成するとき、車載デバイスのデバイスIDがさらに運ばれてよい。複数の車載デバイスが配列を形成する場合、応答メッセージは、配列アドレスおよびマルチキャストアドレスの少なくとも一方をさらに運んでよい。

【0103】

一部のその他の例において、応答リソースは、複数の車載デバイスによって共有されてよい。異常な状態のデバイスに関して、デバイスは、応答リソース上でデバイスのIDを送信してよく、したがって、制御ドメインコックピットCDCが応答メッセージを受信するとき、制御ドメインコックピットCDCは、どの車載デバイスが異常な状態であるかを判定する。通常、制御ドメインコックピットCDCと車載デバイスとの両方が1つの車両製造業者によって製造され、1つの車両に組み込まれるので、制御ドメインコックピットCDCは、車載デバイスのIDを予め記憶してよい。

【0104】

通常、車載デバイスの故障率は低く、2つのデバイスが同時に異常な状態である確率も低いので、共有された応答リソースを複数の車載デバイスに割り振ることが適切であることは、理解されるであろう。

【0105】

S203. 対応するリソース上で応答メッセージを送信する。このステップは任意選択であり、そのアクセスが許可され、応答メッセージを送信することができる車載デバイスのみのためのものであることに留意されたい。そのアクセスが許可されない車載デバイスは、応答メッセージを送信する必要がない。

【0106】

任意選択で、対応する応答情報を生成した後、車載デバイスは、車載デバイスに対応する応答リソース上で制御ドメインコックピットCDCに応答メッセージを送信してよい。

【0107】

S204. 応答メッセージを受信し、第2のインジケーションメッセージをさらに生成する。

【0108】

S204の実行は、S203の実行に対応する。応答メッセージを受信した後、制御ドメインコックピットCDCがシステムステータスを再決定してよいことは、理解されるであろう。制御ドメインコックピットCDCが応答メッセージを受信しない場合、システムステータスは、再決定される必要がない場合がある。確かに、別の例において、代替的に、制御ドメインコックピットCDCは、車載デバイスによって送信された応答メッセージが受信されるかどうかを判定することなく、システムステータスを周期的、半周期的、または非周期的に決定してよい。

【0109】

車載デバイスによって送信された応答メッセージを受信した後、対応する応答リソースが異なる車載デバイスまたは配列に割り振られる場合、制御ドメインコックピットCDCは、異なる応答リソースに基づいて、どの車載デバイスまたは配列が応答メッセージを送信するかを判定してよい。次いで、応答メッセージ内のデバイスステータスまたは配列内のデバイスのステータスに基づいて、車載デバイスまたは配列が異常な状態であるかどうかが判定される。確かに、制御ドメインコックピットCDCが時間周波数リソースを異なる車載デバイスにそれぞれ割り振ってない場合、応答情報は、デバイスIDをさらに運ぶ。したがって、どの車載デバイスまたはデバイスグループが異常な状態であるかが、デバイスIDに基づいて判定されてよい。

【0110】

車載デバイスのデバイスステータスを判定した後、制御ドメインコックピットCDCは、システムステータスを再決定し、新しいシステムステータスに基づいて第2のインジケーションメッセージを決定してよい。第2のインジケーションメッセージは、新しいシステムブロードキャストメッセージである。新しいシステムブロードキャストメッセージの種類は、S201におけるシステムブロードキャストメッセージの種類と同じかまたは異なる。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0111】

制御ドメインコックピットCDCが応答メッセージを受信し、すべての予想される車載デバイスが正常な状態であると判定する場合、制御ドメインコックピットCDCがシステムステータスを再決定し、第2のインジケーションメッセージを送信することによって、非車載デバイスのアクセスを許可してよいことは、理解されるであろう。

【0112】

確かに、制御ドメインコックピットCDCによって予想される車載デバイスが異常な状態であるか、またはその他の処理が実行される必要がある場合、制御ドメインコックピットCDCは、システムステータスを再決定しない場合がある。システムブロードキャストメッセージは通常周期的に送信されるので、非車載デバイスは、引き続き第1のインジケーションメッセージの命令に従った動作を実行する。

【0113】

応答メッセージを受信することおよびシステムステータスを再決定することが、互いにある程度関連付けられてよく、または互いに独立していてよいことは、理解されるであろう。

【0114】

例において、システムステータスは、システム準備状態、車載デバイスアクセス状態、システム実行状態、およびアクセス許可状態のうちの1つを含んでよい。確かに、別の例においては、別の可能なシステム状態がさらに含まれてよい。これは、本出願において限定されない。システム準備状態および/または車載デバイスアクセス状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしていること、または車載デバイスがセルフチェックを実行していることを示すために使用されてよく、したがって、非車載デバイスは、これらの種類のシステム状態に基づいて、制御ドメインコックピットCDCにアクセスしないことを選択する。システム実行状態および/またはアクセス許可状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしたことを示すために使用されてよい。この場合、非車載デバイスは、制御ドメインコックピットCDCにアクセスすることを許可されてよい。

【0115】

当業者は、制御ドメインコックピットCDCが車載デバイスのステータスを判定するプロセスが、車載デバイスが制御ドメインコックピットCDCにアクセスするプロセスともみなされてよいことを理解するであろう。車載デバイスから送信される応答メッセージは、ある程度、車載デバイスのアクセス要求メッセージとみなされてよい。

【0116】

S201に戻る。制御ドメインコックピットCDCが第1のインジケーションメッセージを送信した後、非車載デバイスも、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージを受信してよい。したがって、S201の後に、以下のステップがさらに実行されてよい。

【0117】

S205. 第1のインジケーションメッセージを受信する。

【0118】

非車載デバイスに関しては、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージが受信され、たとえば、第1のインジケーションメッセージがシステムブロードキャストメッセージであるとき、システムブロードキャストメッセージに基づいて、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかが判定される。例においては、制御ドメインコックピットCDC上で現在実行されているシステムのシステムステータスが、システムブロードキャストメッセージ内で運ばれるシステムステータスインジケーション情報に基づいて判定されてよく、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかが、システムステータスに基づいて判定される。確かに、別の例においては、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージが、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかを直接示す場合、第1のインジケーションメッセージ内の情報に基づいて、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されない場合、S207が実行されてよく、または非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可される場合、S208が実行されてよい。

【0119】

S206. システムステータスが予め設定されたシステム状態であるかどうかを判定する。このステップは任意選択であり、第1のインジケーションメッセージがシステムステータスインジケーション情報を含む場合にのみ適用されることに留意されたい。第1のインジケーションメッセージがアクセスが許可されるかどうかを直接示すために使用される情報を含む場合、システムステータスは、判定される必要がない。

【0120】

具体的に言えば、S205において、非車載デバイスは、システムステータスが予め設定されたシステム状態であるかどうかを判定する。

【0121】

例においては、予め設定されたシステム状態がシステム準備状態または車載デバイスアクセス状態である場合、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されないと判定され、S207が実行され、そうでない場合、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されると判定され、S208が実行される。確かに、システムステータスは、代替的に、任意のその他の等価なシステム状態であってよい。これは、本出願の本明細において限定されない。しかし、この例においてシステムステータスが予め設定されたシステム状態であるとき、車載デバイスがデバイスアクセスを実行していることは理解されるであろう。

【0122】

別の例においては、予め設定されたシステム状態がシステム実行状態またはアクセス許可状態である場合、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されると判定され、S208が実行され、そうでない場合、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されないと判定され、S207が実行される。確かに、システムステータスは、代替的に、任意のその他の等価なシステム状態であってよい。これは、本出願の本明細において限定されない。この例においてシステムステータスが予め設定されたシステム状態であるとき、車載デバイスがデバイスアクセスを完了したことは理解されるであろう。

【0123】

S207. 非車載デバイスがランダムアクセス要求を開始することを禁止する。

【0124】

非車載デバイスは、制御ドメインコックピットCDCへのランダムアクセス要求を開始することを禁止される。

【0125】

S208. 非車載デバイスがランダムアクセス要求を開始することを許可する。

【0126】

非車載デバイスは、制御ドメインコックピットCDCへのランダムアクセス要求を開始することを許可される。

【0127】

本出願においては、システムブロードキャストメッセージが、システムステータスインジケーション情報を運ぶ。車載デバイスがセルフチェックを実行しているかまたは制御ドメインコックピットCDCへの接続を確立しているとき、非車載デバイスは、ランダムアクセス要求を開始することを禁止される。これは、制御ドメインコックピットCDCによる車載デバイスのステータスのチェックおよび車載デバイスのアクセスに対して、このフェーズにおいて非車載デバイスによって実行されるランダムアクセス要求の開始によって引き起こされる影響を回避する。このようにして、車載デバイスが正常に実行されることが可能であり、いくつかの基本的なサービスが正常に実行されることが可能であることが保証される。

【0128】

図3は、本出願の実施形態に係るCDCと、車載デバイスと、非車載デバイスとの間の別の種類の情報交換の図である。

【0129】

図2のS201において説明されたシステムステータスを判定する様式の代わりに、別の場合には、時間の閾値を設定する方法が使用されてよい。たとえば、S301が実行されてよい。

【0130】

S301. 第1のインジケーションメッセージを送信する。

【0131】

制御ドメインコックピットCDCが第1のインジケーションメッセージを送信し、その結果、非車載デバイスが第1のインジケーションメッセージを受信した後、非車載デバイスは、制御ドメインコックピットCDCへのアクセスが許可されるかどうかを判定する。任意選択で、第1のインジケーションメッセージは、システムブロードキャストメッセージであってよい。確かに、第1のインジケーションメッセージを送信する様式が本出願において限定されず、第1のインジケーションメッセージがブロードキャスト、マルチキャスト、または任意のその他の等価な様式で送信されてよいことは、理解されるであろう。本出願が、主に、制御ドメインコックピットCDCによる車載デバイスのステータスのチェックおよび車載デバイスのアクセスに対して、このフェーズにおいて非車載デバイスによって実行されるランダムアクセス要求の開始によって引き起こされる影響をどのようにして回避するべきかを説明することは理解されるであろう。したがって、車載デバイスは、第1のインジケーションメッセージ内の時間閾値情報を無視してよい。確かに、一部の例において、車載デバイスは、代替的に、時間閾値情報に基づいて、制御ドメインコックピットCDCにアクセスすべきかどうかを判定してよい。

【0132】

一部の実施形態において、第1のインジケーションメッセージは、時間閾値情報を運んでよい。時間閾値情報は、時間の閾値を示すために使用される時間領域インジケーション情報であってよい。時間閾値情報は、システムフレーム番号(system frame number、SFN)、または特定の決まった基準フレームからのオフセットであってよい。たとえば、決まった基準フレームは、第1の基準フレームであってよい。決まった基準フレームは、フレーム0であってよく、確かに、代替的に任意のその他の基準フレームであってよい。確かに、時間の閾値は、代替的に、特定の値または時間の範囲であってよい。これは、本出願の本明細において限定されない。

【0133】

任意の実装において、時間閾値情報は、システムフレーム番号であってよい。システムフレーム番号256を例とする。現在のシステムフレーム番号がシステムフレーム番号256以下であると非車載デバイスが判定するとき、非車載デバイスは、アクセスを開始することを許可されない。

【0134】

別の任意の実装において、時間閾値情報は、特定の決まった基準フレームに対する1つまたは複数の時間領域オフセットであってよい。たとえば、時間領域オフセットは、256msであってよい。決まった基準フレームは、ヘッドユニットCDCと車載デバイスもしくは非車載デバイスとの間で事前にネゴシエーションもしくは合意されてよく、またはプロトコルで定義されてよい。たとえば、決まった基準フレームは、64番のフレームであり、単一のフレームの時間の長さは、0.5msであると仮定される。現在のフレーム番号が20であり、現在の絶対的時間が10msであると仮定される。非車載デバイスは、絶対的時間256ms + 64×0.5 = 288ms以内にアクセスを開始することを許可されない。

【0135】

さらに別の任意の実装において、時間閾値情報は、代替的に、第1のシグナリングに対する時間領域オフセットであってよい。時間領域オフセットは、特定の時間の範囲内にランダムアクセスの開始が許可されないことを示す時間の閾値であってよい。

【0136】

第1のシグナリングは、制御ドメインコックピットCDCと非車載デバイスとの間で事前に合意もしくはネゴシエーションされた特定のシグナリング、またはプロトコルで定義された特定のシグナリングであってよい。特定のRRCシグナリングを例とする。RRCシグナリングは、SIBを含む。たとえば、SIBは、周期的に送信されてよい。SIBが特定の決まった時間に送信されるとき、可能な実装において、非車載デバイスは、制御ドメインコックピットCDCがSIBを送信した後の特定の時間枠内にアクセスを開始することを許可されない可能性があり、その理由は、制御ドメインコックピットCDCが、この時間の期間に別の問題を処理する必要がある場合があるからである。この場合、CDCがSIBを送信する瞬間 + [時間領域オフセット1, 時間領域オフセット2]以降、端末は、時間枠[CDCがSIBを送信する瞬間 + 時間領域オフセット1, CDCがSIBを送信する瞬間 + 時間領域オフセット2]内にCDCへのランダムアクセスを開始することを許可されない。RRCシグナリングが管理フレーム内で運ばれてよいことは、理解されるであろう。[時間領域オフセット1, 時間領域オフセット2]は、情報要素またはいくつかのビットによって表されてよいことに留意されたい。

【0137】

別の例として、可能な実装において、非車載デバイスは、特定のRRCシグナリング(たとえば、第1のRRCシグナリング)を取得した後の特定の時間枠内にアクセスを開始することを許可されない可能性があり、その理由は、制御ドメインコックピットCDCが、この時間の期間に別の問題を処理する必要がある場合があるからである。たとえば、非車載デバイスが第1のRRCシグナリングを成功裏に受信する瞬間が第1の瞬間である場合、端末は、時間枠[第1の瞬間 + 時間領域オフセット1, 第1の瞬間 + 時間領域オフセット2]内に制御ドメインコックピットCDCへのランダムアクセスを開始することを許可されない。RRCシグナリングが制御フレーム内で運ばれてよいことは、理解されるであろう。

【0138】

時間閾値情報が1つの時間領域オフセットまたは複数の時間領域オフセットであってよいことは、理解されるであろう。

【0139】

車載デバイスがセルフチェックを実行するかまたは制御ドメインコックピットCDCにアクセスするときに、車載デバイスが非車載デバイスのアクセスによって影響されないことを保証するために、第1のインジケーションメッセージ内で運ばれる時間閾値情報は、非車載デバイスのためのものであってよい。例においては、異なる非車載デバイスのために異なる時間の閾値が設定されてよい。確かに、複数の非車載デバイスを含むデバイスグループが存在する場合、デバイスグループは、配列の形態であってよい。代替的に、異なる非車載デバイスの配列のために異なる時間の閾値が設定されてよい。これは、本出願の本明細において限定されない。別の例において、システムブロードキャストメッセージ内の時間の閾値の表現形式は、明示的であってよく、または確かに暗黙的であってよい。その実施プロセスに関しては、S201を参照されたい。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0140】

時間の閾値の設定に関して、制御ドメインコックピットCDCが、車載デバイスによって実行されたセルフチェックのステータス、または制御ドメインコックピットCDCとの接続の確立のステータスに基づいて設定されてよい。

【0141】

S202およびS203は、S301の後に実行される。図3のS202およびS203の実施プロセスは、図2のS202およびS203の実施プロセスと同じである。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0142】

S302が、S203の後に実行されてよい。

【0143】

S302. 応答メッセージを受信し、第2のインジケーションメッセージをさらに生成する。

【0144】

S302の実行は、S203の実行に対応する。応答メッセージを受信した後、制御ドメインコックピットCDCが異なる非車載デバイスの時間の閾値をリセットしてよいことは、理解されるであろう。制御ドメインコックピットCDCが応答メッセージを受信しない場合、時間の閾値は、リセットされる必要がない場合がある。別の例において、代替的に、制御ドメインコックピットCDCは、車載デバイスによって送信された応答メッセージが受信されるかどうかを判定することなく、時間の閾値を周期的、半周期的、または非周期的に設定してよい。

【0145】

特に、応答メッセージが受信された後、時間の閾値は、リセットされてよい。応答メッセージを受信することおよび時間の閾値をリセットすることが、互いにある程度関連付けられてよく、または互いに独立していてよいことは、理解されるであろう。

【0146】

車載デバイスによって送信された応答メッセージを受信した後、制御ドメインコックピットCDCは、車載デバイスのデバイスステータスを判定し、車載デバイスのデバイスステータスに基づいて時間の閾値をリセットする。次いで、第2のインジケーションメッセージが、新しい時間の閾値に基づいて決定され得る。第2のインジケーションメッセージは、新しいシステムブロードキャストメッセージである。新しいシステムブロードキャストメッセージの種類は、S301におけるシステムブロードキャストメッセージの種類と同じかまたは異なる。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0147】

S301に戻る。制御ドメインコックピットCDCが第1のインジケーションメッセージを送信した後、非車載デバイスも、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージを受信してよい。したがって、S301の後に、以下のステップがさらに実行されてよい。

【0148】

S303. 第1のインジケーションメッセージを受信する。

【0149】

非車載デバイスに関しては、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージが受信され、たとえば、第1のインジケーションメッセージがシステムブロードキャストメッセージであるとき、システムブロードキャストメッセージに基づいて、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかが判定される。例においては、非車載デバイスのために制御ドメインコックピットCDCによって設定された時間の閾値が、システムブロードキャストメッセージ内で運ばれる時間閾値情報に基づいて判定されてよく、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかが、非車載デバイスの時間の閾値に基づいて判定される。確かに、別の例においては、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージが、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかを直接示す場合、第1のインジケーションメッセージ内の情報に基づいて、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されない場合、S207が実行されてよく、または非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可される場合、S208が実行されてよい。

【0150】

S304. 現在の瞬間が時間の閾値に達するかどうかを判定する。このステップは任意選択であり、第1のインジケーションメッセージが時間閾値情報を含む場合にのみ適用されることに留意されたい。第1のインジケーションメッセージがアクセスが許可されるかどうかを直接示す場合、時間の閾値が時間の閾値に達するかどうかが判定される必要はない。

【0151】

特に、非車載デバイスが、現在の瞬間が時間の閾値に達するかどうかを判定する。

【0152】

例においては、現在の瞬間が時間の閾値によって指定された時間に達する場合、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されないと判定され、S207が実行され、そうでない場合、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されると判定され、S208が実行される。確かに、時間の閾値は、システムフレーム番号、または特定の決まった基準フレームからのオフセットであってよい。

【0153】

S207およびS208の実施プロセスは、図2のS207およびS208の実施プロセスと同じである。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0154】

本出願においては、非車載デバイスが予め設定された時間の閾値が到達される前にランダムアクセス要求を開始することを禁止されるか、または非車載デバイスが予め設定された時間の閾値が到達された後にランダムアクセス要求を開始することを許可されることを保証するために、システムブロードキャストメッセージが、時間閾値情報を運ぶ。これは、CDCによる車載デバイスのステータスのチェックおよび車載デバイスのアクセスに対して、このフェーズにおいて非車載デバイスによって実行されるランダムアクセス要求の開始によって引き起こされる影響を回避する。このようにして、車載デバイスが正常に実行されることが可能であり、いくつかの基本的なサービスが正常に実行されることが可能であることが保証される。

【0155】

図4は、本出願の実施形態に係るCDCと、車載デバイスと、非車載デバイスとの間のさらに別の種類の情報交換の図である。

【0156】

図2のS201において説明されたシステムステータスを判定する様式および図3のS301において説明された時間の閾値を設定する様式の代わりに、さらに別の場合には、アクセスインジケーション情報を設定する様式が使用されてよい。たとえば、S401が実行されてよい。

【0157】

S401. 第1のインジケーションメッセージを送信する。

【0158】

制御ドメインコックピットCDCが第1のインジケーションメッセージを送信し、その結果、車載デバイスまたは非車載デバイスが第1のインジケーションメッセージを受信した後、車載デバイスまたは非車載デバイスは、制御ドメインコックピットCDCへのアクセスが許可されるかどうかを判定する。任意選択で、第1のインジケーションメッセージは、システムブロードキャストメッセージであってよい。確かに、第1のインジケーションメッセージを送信する様式が本出願において限定されず、第1のインジケーションメッセージがブロードキャスト、マルチキャスト、または任意のその他の等価な様式で送信されてよいことは、理解されるであろう。

【0159】

一部の実施形態において、システムブロードキャストメッセージは、アクセスインジケーション情報を運んでよい。アクセスインジケーション情報は、デバイスタイプおよびアクセス関係についてのマッピングテーブルである場合があり、言い換えると、アクセスインジケーション情報は、デバイスタイプとアクセス関係との間のマッピング関係を示す場合がある。マッピングテーブルまたはマッピング関係は、どの種類のデバイスがランダムアクセス要求を開始することができ、どの種類のデバイスがランダムアクセス要求を開始することを禁止されるかを示すために使用される。例において、デバイスタイプは、車載デバイスおよび非車載デバイスに分類されてよく、またはマイク、スピーカ、モバイル電話などに分類されてよく、または制御ドメインコックピットCDCに以前接続された車載デバイスもしくは制御ドメインコックピットCDCに接続されたことがない車載デバイスなどに分類されてよい。デバイスタイプは、対応するタイプインデックスまたは番号によって示される場合もある。これは、本出願の本明細において限定されない。

【0160】

デバイスタイプおよびアクセス関係についてのマッピングテーブルは、明示的または暗黙的であってよい。たとえば、明示的な対応表、たとえば、表1が、構成されてよい。本出願の解決策におけるすべての表は、対応関係を反映するように意図されており、対応関係の表現形式に過ぎないことに留意されたい。対応関係を反映することができる任意のその他の表現形式が、表と置き換わってよい。本出願において、表は、すべての可能な表現形式の一般化である。

【表1】

【0161】

0はアクセスが許可されることを示し、1はアクセスが許可されないことを示すと仮定される。車載マイクおよび車載スピーカのアクセスは許可され、モバイル電話のアクセスは許可されないことが、表1から知られ得る。確かに、応答するデバイスの種類がデバイスタイプインジケーション情報によって示されてもよいことは、理解されるであろう。たとえば、「000」が車載マイクを特定するために使用される場合、{000, 0}が、車載マイクがアクセスすることを許可されることを示す場合がある。

【0162】

デバイスタイプおよびアクセス関係についてのマッピングテーブルが、たとえば、プロトコルの合意に基づく暗黙的なものである場合、どの種類のデバイスがアクセスすることを許可されるかを示すために、ビットマップ(bitmap)が使用されてよい。通常、プロトコルの合意に従って、ビットマップの各ビットが、デバイスタイプを特定してよい。ビットマップの長さは3ビットであり、各ビットが、順に、車載マイク、車載スピーカ、モバイル電話に対応すると仮定される。ビットマップ{001}が送信されるとき、そのビットマップは、車載マイクおよび車載スピーカのアクセスが許可され、モバイル電話のアクセスが許可されないことを示す。確かに、別の例においては、代替的に、1がアクセスが許可されることを示す場合があり、0がアクセスが許可されないことを示す場合があり、または任意のその他の数が等価な置き換えのために使用される場合がある。これは、本出願の本明細において限定されない。

【0163】

例においては、さらに、異なる種類のデバイスは、異なるデバイス優先順位であってよい。デバイスタイプおよびアクセス関係についてのマッピングテーブルは、デバイス優先順位およびアクセス関係に基づくマッピングテーブルによって置き換えられてよい。マッピングテーブルは、異なる優先順位のデバイスがランダムアクセス要求を開始することを許可されるかどうかを示すために使用される。確かに、異なる種類のデバイスが同じデバイス優先順位であってよいことは、理解されるであろう。任意選択で、デバイス優先順位は、アクセス優先順位であってもよい。通常、より優先順位の高いデバイスは、よりアクセス優先順位が高い場合がある。たとえば、車載マイクおよび車載スピーカの優先順位は1であり、モバイル電話の優先順位は2である。第1のインジケーションメッセージ内で運ばれるデバイス優先順位が1である場合、車載マイクおよび車載スピーカのアクセスが許可される。

【0164】

別の例においては、複数の非車載デバイスを含むデバイスグループが存在する場合、デバイスグループは、配列の形態であってよい。異なる非車載デバイスの配列に関して、デバイスタイプおよびアクセス関係についてのマッピングテーブル、またはデバイス優先順位およびアクセス関係に基づくマッピングテーブルが、設定されてよい。これは、本出願の本明細において限定されない。別の例において、システムブロードキャストメッセージ内のアクセスインジケーション情報の表現形式は、明示的であってよく、または確かに暗黙的であってよい。その実施プロセスに関しては、S201を参照されたい。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0165】

S202およびS203は、S401の後に実行される。図4のS202およびS203の実施プロセスは、図2のS202およびS203の実施プロセスと同じである。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0166】

S402が、S203の後に実行されてよい。

【0167】

S402. 応答メッセージを受信し、第2のインジケーションメッセージをさらに生成する。

【0168】

S402の実行は、S203の実行に対応する。制御ドメインコックピットCDCが応答メッセージを受信し、すべての予想される車載デバイスが正常な状態であると判定する場合、理解されるであろう。この場合、制御ドメインコックピットCDCは、アクセスインジケーション情報をリセットし、第2のインジケーションメッセージを送信することによって、非車載デバイスのアクセスを許可してよい。確かに、制御ドメインコックピットCDCによって予想される車載デバイスが異常な状態であるか、またはその他の処理が実行される必要がある場合、制御ドメインコックピットCDCは、アクセスインジケーション情報をリセットしない場合がある。システムブロードキャストメッセージは通常周期的に送信されるので、非車載デバイスは、引き続き第1のインジケーションメッセージの命令に従った動作を実行する。

【0169】

車載デバイスによって送信された応答メッセージを受信した後、制御ドメインコックピットCDCは、車載デバイスのデバイスステータスを判定し、車載デバイスのデバイスステータスに基づいてアクセスインジケーション情報をリセットする。次いで、第2のインジケーションメッセージが、新しいインジケーション情報に基づいて決定され得る。第2のインジケーションメッセージは、新しいシステムメッセージである。新しいシステムメッセージの種類は、S301におけるシステムブロードキャストメッセージの種類と同じかまたは異なる。説明を容易にするために、詳細は、本明細書において再度説明されない。

【0170】

S401に戻る。制御ドメインコックピットCDCが第1のインジケーションメッセージを送信した後、非車載デバイスも、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージを受信してよい。したがって、S401の後に、以下のステップがさらに実行されてよい。

【0171】

S403. 第1のインジケーションメッセージを受信する。

【0172】

非車載デバイスに関しては、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージが受信され、たとえば、第1のインジケーションメッセージがシステムブロードキャストメッセージであるとき、システムブロードキャストメッセージに基づいて、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかが判定される。例においては、非車載デバイスのデバイスタイプおよびアクセス関係が、システムブロードキャストメッセージ内で運ばれるアクセスインジケーション情報に基づいて判定されてよく、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかが、デバイスタイプおよびアクセス関係に基づいて判定される。確かに、別の例においては、制御ドメインコックピットCDCによって送信された第1のインジケーションメッセージが、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されるかどうかを直接示す場合、第1のインジケーションメッセージ内の情報に基づいて、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されない場合、S207が実行されてよく、または非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可される場合、S208が実行されてよい。

【0173】

S404. アクセスインジケーション情報が予め設定された条件を満たすかどうかを判定する。このステップは任意選択であり、第1のインジケーションメッセージがアクセスインジケーション情報を含む場合にのみ適用されることに留意されたい。第1のインジケーションメッセージがアクセスが許可されるかどうかを直接示す場合、アクセスインジケーション情報が予め設定された条件を満たすかどうかが判定される必要はない。

【0174】

具体的に言えば、非車載デバイスは、S403において判定されるデバイスタイプおよびアクセス関係に基づいて、非車載デバイスのデバイスタイプがランダムアクセス要求を開始することを許可されるかどうかを判定する。

【0175】

例においては、非車載デバイスのデバイスタイプがランダムアクセス要求の開始を許可しない場合、非車載デバイスがドメインコックピットCDCにアクセスすることを許可されないと判定され、S207が実行され、または非車載デバイスのデバイスタイプがランダムアクセス要求の開始を許可する場合、非車載デバイスが制御ドメインコックピットCDCにアクセスすることを許可されると判定され、S208が実行される。

【0176】

【0177】

本出願においては、そのデバイスタイプが予め設定された条件を満たすデバイスのみがランダムアクセス要求を送信することを許可され、そのデバイスタイプが予め設定された条件を満たさないデバイスがランダムアクセス要求を送信することを禁止されることを保証するために、システムブロードキャストメッセージが、アクセスインジケーション情報を運ぶ。これは、CDCによる車載デバイスのステータスのチェックおよび車載デバイスのアクセスに対して、非車載デバイスによって実行されるランダムアクセス要求の開始によって引き起こされる影響を回避する。このようにして、車載デバイスが正常に実行されることが可能であり、いくつかの基本的なサービスが正常に実行されることが可能であることが保証される。

【0178】

確かに、当業者は、図3において設定された時間の閾値および図4において設定されたアクセスインジケーション情報が、図2において判定されたシステムステータスと一緒に使用されてよいことに気付くはずである。確かに、制御ドメインコックピットCDCが車載デバイスおよび非車載デバイスのアクセスを制御することができるように、時間の閾値、アクセスインジケーション情報、およびシステムステータスのいずれか1つまたは2つが選択されてよい。

【0179】

図5は、本出願の実施形態に係るアクセス制御方法の流れ図である。

【0180】

図5に示されるように、本出願は、アクセス制御方法を提供する。図2から図4のインタラクションプロセスは、この方法を使用することによって実施されてよい。方法は、以下のステップを含み得る。

【0181】

S501. 第1のデバイスのステータスが第1のステータスであると判定する。

【0182】

S502. 第1のインジケーション情報を送信する。第1の指示情報は、第1のデバイスへの少なくとも1つの第2のデバイスのアクセスが許可されるかどうかを示すために使用される。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信されてよい。たとえば、システムメッセージは、システムブロードキャストメッセージであってよい。第1のインジケーション情報は、MIB、SIB、またはブロードキャストフレームであってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリングに含まれる。

【0183】

可能な実装において、第1のステータスは、システム準備状態および車載デバイスアクセス状態のうちの少なくとも1つを含み、第1のインジケーション情報は、少なくとも1つの第2のデバイスのアクセスが許可されていないことを示すために使用され、または第1のステータスは、システム実行状態およびアクセス許可状態のうちの少なくとも1つを含み、第1のインジケーション情報は、第2のデバイスのアクセスが許可されることを示すために使用される。システム準備状態および/または車載デバイスアクセス状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしていること、または車載デバイスがセルフチェックを実行していることを示すために使用されてよく、したがって、非車載デバイスは、これらの種類のシステム状態に基づいて、制御ドメインコックピットCDCにアクセスしないことを選択する。システム実行状態および/またはアクセス許可状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしたことを示すために使用されてよい。この場合、非車載デバイスは、制御ドメインコックピットCDCにアクセスすることを許可されてよい。

【0184】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0185】

【0186】

【0187】

可能な実装において、第1のインジケーション情報は、優先順位情報を含み、少なくとも1つの第2のデバイスの優先順位は、優先順位情報によって示される少なくとも1つの優先順位に属する。第1のインジケーション情報は、アクセスインジケーション情報をさらに含み、アクセスインジケーション情報は、第1のデバイスへのアクセスが許可されるかどうかを示すために使用される。さらに、第2のデバイスは、優先順位情報およびアクセスインジケーション情報に基づいて、第1のデバイスにアクセスするべきかどうかを判定する。

【0188】

可能な実装において、第1のインジケーション情報は、第1の時間情報を含み、第1の時間情報は、少なくとも1つの第2のデバイスが第1の時間の範囲内に第1のデバイスにアクセスすることを許可されないことを示すために使用される。

【0189】

【0190】

【0191】

【0192】

【0193】

可能な実装において、デバイスタイプは、車載デバイスおよび非車載デバイスのうちの少なくとも1つを含む。

【0194】

図6は、本出願の実施形態に係る別のアクセス制御方法の流れ図である。

【0195】

図6に示されるように、本出願は、別のアクセス制御方法を提供する。図2から図4のインタラクションプロセスは、この方法を使用することによって実施されてよい。方法は、以下のステップを含み得る。

【0196】

S601. 第1のデバイスから第1のインジケーション情報を受信する。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信される。たとえば、システムメッセージは、システムブロードキャストメッセージであってよい。第1のインジケーション情報は、MIB、SIB、またはブロードキャストフレームであってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリングに含まれる。

【0197】

S602. 第1のインジケーション情報に基づいて、第1のデバイスへの第2のデバイスのアクセスが許可されるかどうかを判定する。

【0198】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0199】

【0200】

【0201】

【0202】

【0203】

可能な実装において、第1の時間の範囲は、第1の基準フレームに対する時間領域オフセット、または第1のシグナリングに対する時間領域オフセットである。第1の基準フレームは、制御ドメインコックピットCDCと非車載デバイスとの間で事前に合意もしくはネゴシエーションされた第1のシステムフレーム番号であってよく、またはプロトコルで定義された第1のシステムフレーム番号であってよい。第1のシグナリングは、制御ドメインコックピットCDCと非車載デバイスとの間で事前に合意もしくはネゴシエーションされた特定のシグナリングであってよく、またはプロトコルで定義された特定のシグナリングであってよい。たとえば、第1のシグナリングは、RRCシグナリングであってよい。1つまたは複数の時間領域オフセットが、存在する場合がある。可能な実装において、第1のインジケーション情報は、リソースインジケーション情報を含み、リソースインジケーション情報は、少なくとも1つの第3のデバイスのために使用されるリソースを示し、またはリソースインジケーション情報によって示されるリソースは、少なくとも1つの第2のデバイスのために使用されない。

【0204】

【0205】

【0206】

【0207】

可能な実装において、第2のデバイスは、モバイル電話である。

【0208】

図7は、本出願の実施形態に係るアクセス制御装置の概略図である。

【0209】

図7に示されるように、本出願は、アクセス制御装置700を提供する。アクセス制御装置700は、第1のデバイス、たとえば、制御ドメインコックピットCDCであってよく、またはアクセス制御装置は、第1のデバイス内のチップ、内部コンポーネントなどであってよい。確かに、アクセス制御装置は、代替的に、モバイル電話、タブレットコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ(ultra-mobile personal computer、UMPC)、ネットブック、セルラ電話、携帯情報端末(personal digital assistant、PDA)、拡張現実(augmented reality、AR)デバイス、仮想現実(virtual reality、VR)デバイス、人工知能(artificial intelligence、AI)デバイス、ウェアラブルデバイス、車載デバイス、スマートホームデバイス、および/またはスマートシティデバイスであってよい。第1のデバイスの特定の種類は、本出願のこの実施形態において限定されない。

【0210】

アクセス制御装置700は、図2から図4のインタラクションプロセスを実施してよい。アクセス制御装置700は、第1のデバイスのステータスが第1のステータスであると判定するように構成された処理ユニット701と、第1のインジケーション情報を送信するように構成された送信ユニット702であって、第1のインジケーション情報が、第1のデバイスへの少なくとも1つの第2のデバイスのアクセスが許可されるかどうかを示すために使用される、送信ユニット702とを含む。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信される。第1のインジケーション情報は、MIB、SIB、またはブロードキャストフレーム(broadcast frame)であってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリングに含まれる。任意選択で、第1のインジケーション情報は、ブロードキャストによって送信される。

【0211】

可能な実装において、第1のステータスは、システム準備状態および車載デバイスアクセス状態のうちの少なくとも1つを含み、第1のインジケーション情報は、少なくとも1つの第2のデバイスのアクセスが許可されないことを示すために使用され、または第1のステータスは、システム実行状態およびアクセス許可状態のうちの少なくとも1つを含み、第1のインジケーション情報は、第2のデバイスのアクセスが許可されることを示すために使用される。システム準備状態および車載デバイスアクセス状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしていること、または車載デバイスがセルフチェックを実行していることを示すために使用されてよく、したがって、非車載デバイスは、これらの種類のシステム状態に基づいて、制御ドメインコックピットCDCにアクセスしないことを選択する。システム実行状態およびアクセス許可状態は、車載デバイスが制御ドメインコックピットCDCにアクセスしたことを示すために使用されてよい。この場合、制御ドメインコックピットCDCへの非車載デバイスのアクセスが許可される。

【0212】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0213】

【0214】

【0215】

【0216】

【0217】

【0218】

【0219】

【0220】

【0221】

可能な実装において、デバイスタイプは、車載デバイスおよび非車載デバイスのうちの少なくとも1つを含む。

【0222】

図8は、本出願の実施形態に係るアクセス装置の概略図である。

【0223】

図8に示されるように、本出願は、アクセス装置800を提供する。アクセス装置800は、第2のデバイスもしくは第3のデバイス、たとえば、車載デバイスもしくは非車載デバイスであってよく、またはアクセス装置は、第2のデバイスもしくは第3のデバイス内のチップ、内部コンポーネントなど、たとえば、車載デバイスもしくは非車載デバイス内のチップもしくは内部コンポーネントであってよい。確かに、アクセス装置は、代替的に、モバイル電話、タブレットコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、ノートブックコンピュータ、UMPC、ネットブック、セルラ電話、PDA、ARデバイス、VRデバイス、AIデバイス、ウェアラブルデバイス、車載デバイス、スマートホームデバイス、および/またはスマートシティデバイスであってよい。第1のデバイスの特定の種類は、本出願のこの実施形態において限定されない。

【0224】

アクセス装置800は、図2から図4のインタラクションプロセスを実施するように構成されてよい。アクセス装置800は、受信ユニット801および処理ユニット802を含む。受信ユニット801は、第1のデバイスから第1のインジケーション情報を受信するように構成される。処理ユニット802は、第1のインジケーション情報に基づいて、第1のデバイスへの第2のデバイスのアクセスが許可されるかどうかを判定するように構成される。任意選択で、第1のインジケーション情報は、システムメッセージ内で運ばれるか、またはブロードキャストによって送信されてよい。たとえば、システムメッセージは、システムブロードキャストメッセージであってよい。第1のインジケーション情報は、MIB、SIB、またはブロードキャストフレームであってよい。MIBは、PBCH上で運ばれてよい。SIBは、通常、RRCシグナリングに含まれる。

【0225】

可能な実装において、第1のインジケーション情報は、少なくとも1つの第3のデバイスのアクセスが許可されるかどうかを示すために使用される。

【0226】

【0227】

【0228】

【0229】

【0230】

【0231】

【0232】

【0233】

【0234】

【0235】

可能な実装において、第2のデバイスは、モバイル電話である。

【0236】

図9は、本出願の実施形態に係る通信システムの概略図である。

【0237】

図9に示されるように、本出願は、通信システム900を提供する。通信システム900は、図7に示されたアクセス制御装置700を含む。

【0238】

アクセス制御装置700は、少なくとも1つのプロセッサと、通信インターフェースとを含む。さらに、アクセス制御装置700は、少なくとも1つのメモリをさらに含んでよい。任意選択で、アクセス制御装置700のプロセッサ、メモリ、および通信インターフェースは、バスを通じた通信接続を確立してよい。通信インターフェースは、少なくとも1つのプロセッサに情報の入力および/または出力を提供する。

【0239】

少なくとも1つのプロセッサは、中央演算処理装置(central processing unit、CPU)、グラフィックス処理ユニット(graphics processing unit、GPU)、およびデジタル信号プロセス(digital signal process、DSP)チップのうちの少なくとも1つを含んでよい。

【0240】

メモリは、ランダムアクセスメモリ(random-access memory、RAM)などの揮発性メモリ(volatile memory)を含む場合があり、またはメモリは、読み出し専用メモリ(read-only memory、ROM)、フラッシュメモリ、ハードディスクドライブ(hard disk drive、HDD)、もしくはソリッドステートドライブ(solid state drive、SSD)などの不揮発性メモリ(non-volatile memory)をさらに含む場合があり、またはメモリ2002は、上述の種類のメモリの組み合わせをさらに含む場合がある。

【0241】

少なくとも1つのプロセッサは、メモリに結合され、メモリ内の命令を読み、実行するように構成される。プロセッサが実行されるとき、プロセッサは、命令を実行し、その結果、プロセッサは、アクセス制御装置700の機能を実施することができる。

【0242】

可能な実装において、アクセス制御装置700は、図7の機能を実施することができるチップ、または図7の機能を実施することができる車両であってよい。

【0243】

可能な実装において、通信システム900は、図8に示されたアクセス装置800をさらに含む。

【0244】

アクセス装置800は、プロセッサと、メモリと、通信インターフェースと、バスとを含む。アクセス装置800のプロセッサ、メモリ、および通信インターフェースは、バスを通じた通信接続を確立してよい。

【0245】

プロセッサは、中央演算処理装置(central processing unit、CPU)であってよい。

【0246】

【0247】

プロセッサは、メモリに結合され、メモリ内の命令を読み、実行するように構成される。プロセッサが実行されるとき、プロセッサは、命令を実行し、その結果、プロセッサは、アクセス装置800の機能を実施することができる。

【0248】

可能な実装において、アクセス装置800は、図8の機能を実施することができるチップであってよい。

【0249】

本出願は、輸送デバイスまたはインテリジェントデバイス、たとえば、無人航空機、自動車、無人搬送車(automated guided vehicle)、またはロボットをさらに提供する。輸送デバイスまたはインテリジェントデバイスは、上述のアクセス制御装置を含む。さらに、任意選択で、輸送デバイスは、上述のアクセス装置をさらに含む。

【0250】

本出願は、アクセス制御方法および装置、ならびに通信システムを提供する。システムステータス情報、時間の閾値、および/またはアクセスインジケーション情報を運ぶシステムブロードキャストメッセージが送信され、その結果、非車載デバイスがシステムブロードキャストメッセージを受信した後、非車載デバイスは、システムステータス情報、時間の閾値、および/またはアクセスインジケーション情報に基づいて、ランダムアクセス要求を開始するべきかどうかを判定する。これは、CDCによる車載デバイスのステータスのチェックおよび車載デバイスのアクセスに対して、このフェーズにおいて非車載デバイスによって実行されるランダムアクセス要求の開始によって引き起こされる影響を回避する。このようにして、車載デバイスが正常に実行されることが可能であり、いくつかの基本的なサービスが正常に実行されることが可能であることが保証される。

【0251】

当業者は、上述の1つまたは複数の例において、本出願の実施形態において説明された機能がハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせによって実装される場合があることを知っているはずである。機能がソフトウェアによって実装されるとき、機能は、コンピュータ可読媒体に記憶されるか、またはコンピュータ可読媒体内の1つもしくは複数の命令もしくはコードとして送信される場合がある。コンピュータ可読媒体は、コンピュータストレージ媒体および通信媒体を含み、通信媒体は、ある場所から別の場所へのコンピュータプログラムの送信を容易にする任意の媒体を含む。ストレージ媒体は、汎用コンピュータまたは専用コンピュータによってアクセスされ得る任意の利用可能な媒体であってよい。

【0252】

本明細書において開示された実施形態に記載の方法またはアルゴリズムのステップは、ハードウェア、プロセッサによって実行されるソフトウェアモジュール、またはこれらの組み合わせによって実装される場合がある。ソフトウェアモジュールは、ランダムアクセスメモリ(RAM)、メモリ、読み出し専用メモリ(ROM)、電気的プログラマブルROM、電気的消去可能プログラマブルROM、レジスタ、ハードディスクドライブ、リムーバブルディスク、CD-ROM、または当技術分野においてよく知られている任意のその他の形態のストレージ媒体内に構成されてよい。

【0253】

上述の特定の実装において、本出願の目的、技術的解決策、および有益な効果が、さらに詳細に説明されている。上述の説明は、本出願の特定の実装であるに過ぎず、本出願の保護範囲を限定するように意図されていないことを理解されたい。本出願の技術的解決策に基づいてなされたすべての修正、均等な置き換え、改善などは、本出願の保護範囲に収まる。

【符号の説明】

【0254】

700 アクセス制御装置
701 処理ユニット
702 送信ユニット
800 アクセス装置
801 受信ユニット
802 処理ユニット
900 通信システム

【図1】