УСТРОЙСТВО И СПОСОБ ПЕРЕДАЧИ ДАННЫХ ЭКСТРЕННОГО ВЫЗОВА В СЕТЯХ БЕСПРОВОДНОЙ СВЯЗИ Российский патент 2014 года по МПК H04W4/00 H04L29/06 

По настоящей заявке испрашивается приоритет на основании патентной заявки США №12/368,947, поданной 10 февраля 2009 года под тем же названием, содержание которой в полном объеме включено в настоящий документ посредством ссылки.

Часть описания настоящего изобретения содержит материал, являющийся объектом защиты авторских прав. Владелец авторских прав не возражает против воспроизведения кем-либо данного патентного документа или описания в том виде, в котором оно подано в патентное ведомство, но при этом все авторские права защищены.

Область техники, к которой относится изобретение

Настоящее изобретение относится в целом к области систем беспроводной связи. Более конкретно, в одном примерном аспекте настоящее изобретение относится к передаче данных экстренного вызова или аналогичных данных в сети беспроводной связи.

Уровень техники

Цифровые системы беспроводной связи, например системы сотовой мобильной связи, предоставляют пользователям как службы связи реального времени, так и службы связи, функционирующие не в режиме реального времени. Службы связи реального времени включают, например, голосовые телефонные вызовы и видеовызовы, а службы связи, функционирующие не в режиме реального времени, включают различные типы служб обмена сообщениями (например, SMS, MMS, электронная почта) или интерактивных служб (например, «чат»). Цифровая сотовая мобильная связь может быть реализована либо в системе связи с коммутацией каналов (сеть с коммутацией каналов, circuit switching), либо в системе связи с коммутацией пакетов (сеть с коммутацией пакетов, packet switching). Вызовы в сети с коммутацией каналов требуют создания канала или непрерывного соединения до начала осуществления обмена пользовательскими данными, например обмена цифровыми данными. Сети с коммутацией каналов соединяют один терминал по сети (сетям) сотовой мобильной связи и базовой сети (магистральной линии связи) с коммутацией каналов с другим терминалом. Установка соединения осуществляется между вовлеченными элементами сети посредством различных известных протоколов управления. После того как соединение установлено, цифровые пользовательские данные, передаваемые одним терминалом в сеть сотовой мобильной связи, проводятся по маршруту соединения в сети в другой терминал. В течение периода соединения коммутируемые каналы остаются неизменными, во время вызова нельзя выполнять изменения для модификации маршрутизации вызова.

Вызовы в сети с коммутацией пакетов (например, вызовы при передаче голоса по IP-протоколу, VoIP) в отличие от вызовов в сети с коммутацией каналов не имеют «жестких» соединений. Вместо этого маршрутизация вызовов в сети с коммутацией пакетов осуществляется гибким образом на уровне сети, при этом лежащий в основе маршрут передачи не задан заранее и может динамически изменяться. Вызовы в сети с коммутацией пакетов формируются в пакеты и передаются по частям посредством «облака» элементов сети, поэтому каждый пакет данных содержит маршрутизируемый сетевой адрес (например, IP-адрес или адрес Интернет-протокола) как исходного, так и целевого терминалов. В типовой реализации сети с коммутацией пакетов в каждый передаваемый пакет данных может встраиваться информация о маршрутизации Интернет-протокола. Такая маршрутизация обычно называется IP-маршрутизацией. На уровне сети IP-маршрутизация не имеет соединений, однако для вызовов в сети с коммутацией пакетов до передачи данных может понадобиться (и обычно осуществляется) установить соединение на уровне приложения/сеанса для согласования различных параметров, например типа, качества, формата, кодирования данных для обмена и/или качества, ширины полосы, а также других параметров нижележащих транспортных потоков.

Сети с коммутацией каналов и сети с коммутацией пакетов имеют несколько выраженных отличий, относящихся непосредственно к их структуре и способу функционирования. Как указано выше, вызовы в сети с коммутацией каналов используют постоянный канал в течение всего времени работы, поэтому вызовы в сети с коммутацией каналов имеют довольно постоянные временные параметры (так как передача данных происходит по одному и тому же маршруту с постоянными параметрами передачи) для передачи данных с определенными допусками. Кроме того, вызов в сети с коммутацией каналов по своему характеру линейный, то есть каждая передача следует за предшествующей ей передачей. Вызов в сети с коммутацией пакетов существенно отличается от модели сети с коммутацией каналов из-за гибкой маршрутизации пакетов, передаваемых адресату, непостоянной ширины полосы или пропускной способности и переменной задержки в группе промежуточных узлов, с помощью которых маршрутизируются данные. Поэтому при вызове в сети с коммутацией пакетов временные параметры и задержка для пакетов данных изменяются в широком диапазоне. Соответственно, пакеты данных, содержащие данные реального времени, например голосовые данные или видеоданные, как правило, встраиваются в протокол, который обеспечивает извлечение информации о временных параметрах (синхронизации).

Например, широко используемый протокол передачи в реальном времени (RTP, Real Time Transport Protocol) в том числе содержит такую информацию о временных параметрах и широко используется для передачи в реальном времени голосовых данных и видеоданных в сетях сотовой мобильной связи с коммутацией пакетов. И протокол RTP, и протокол RTCP (Real-Time Control Protocol, протокол управления передачей в реальном времени) предназначены для использования в системах, в которых предъявляются более широкие требования по транспортному уровню, например адресации, обнаружению ошибок и/или механизмам исправления ошибок. Самыми распространенными протоколами, в которые внедряются пакеты RTP и RTCP, являются протокол UDP (User Datagram Protocol) и протокол TCP (Transport Control Protocol). Протокол TCP отличается в том числе тем, что обеспечивает надежную передачу и качество обслуживания (QoS, quality of service) с механизмами исправления ошибок, тогда как протокол UDP не предоставляет таких возможностей. Дополнительная функциональность протокола TCP требует большего объема передаваемой служебной информации, а также наличия «памяти состояния» в компонентах сети. Протокол UDP проще и имеет большую эффективность, но может допускать потерю данных и изменение параметров в зависимости от канала связи. Протокол UDP не требует какого-либо начального согласования связи для передачи или приема сегмента, поэтому протокол UDP также может быть в целом отнесен к протоколам, не имеющим соединений. Протокол RTP, как правило, используется в комбинации с протоколом UDP, так как данные протоколы имеют дополняющие друг друга особенности. В большинстве случаев повышенная надежность протокола TCP является избыточной в протоколе RTP, а дополнительное время, необходимое для обеспечения точной доставки, нивелирует все преимущества исправления ошибок (в большинстве систем с протоколом RTP опаздывающие пакеты отбрасываются).

Экстренные вызовы и другие вызовы с высоким приоритетом

В сотовых сетях мобильной связи обслуживание в нормальном режиме (например, голосовой вызов) осуществляется только в определенных предварительных условиях. Эти предварительные условия включают аутентификацию пользователя (для определения его личности), авторизацию пользователя для конкретных служб, проверку статуса учетной записи пользователя, а также возможности или готовности оператора предоставить пользователю требуемые ресурсы. В зависимости от имеющихся в сети условий, а также состояния мобильного терминала относительно данных предварительных условий (то есть аутентификации, авторизации и проверки учетной записи), момент времени установки вызова может быть отложен, или вызов может быть полностью отклонен. В случае вызова высокого приоритета (например, экстренного вызова, осуществляемого с целью запроса экстренной помощи, например при пожаре, необходимости медицинской помощи или вызове полиции) экстренному вызову может быть присвоен более высокий приоритет с целью предотвращения задержки или отклонения.

Экстренный вызов может быть либо запрошен, либо детектирован. Либо терминал в запросе установки вызова указывает на то, что ему необходимо установить экстренный вызов, либо в другом случае сеть может определить, что целевой адрес представляет собой запрос экстренной службы (например, пользователь набирает номер 911 и т.п.). В любом из случаев после приема запроса на установление экстренного вызова сеть присваивает данному запросу высокий приоритет и ускоряет обработку. В дополнение к установке экстренного вызова сеть может начать другие процедуры для предоставления терминальной точке дополнительной информации об источнике экстренного вызова (например, географического положения и т.п.). Во многих сотовых сетях определены экстренные вызовы, которые могут быть установлены с минимумом предварительных условий (например, устранения необходимости аутентификации пользователя и т.п.).

Экстренные вызовы ECall и расширенный вызов 911 (расширенный вызов экстренной службы)

В соответствии с различными указаниями соответствующих разрабатывающих стандарты организаций и государственных органов другой класс экстренных вызовов включает так называемые экстренные вызовы ECall (Европа) или расширенные вызовы 911 (Е911) (Северная Америка), причем последние дополнительно включают вызовы Wireless Е911 и VoIP Е911. Указанные вызовы описаны, например, в документе Европейской комиссии «Memorandum of Understanding for Realisation of Interoperable In-Vehicle eCall», eSafety forum и eCall Driving Group от 28 мая 2004 г. и соответствующих стандартах реализации, которые в полном объеме включены в данный документ по ссылке и в которых описаны европейские системы экстренного вызова eCall.

В указанной европейской системе, например, экстренный вызов eCall представляет собой экстренный вызов из встроенной в транспортное средство системы (In-Vehicle System, IVS), формируемый либо вручную находящимися в транспортном средстве людьми, либо автоматически системой IVS после детектирования такого события, как автомобильная авария. Вызов eCall передается из системы IVS по сети мобильной связи второго (2G) или третьего (3G) поколения в пункт обеспечения общественной безопасности (Public Safety Answering Point, PSAP). Вместе с экстренным вызовом в пункт PSAP передается минимальный блок данных (MSD, minimum set of data), который описывает соответствующую ситуацию, например информация, автоматически формируемая или получаемая автомобилем. Информация, включаемая в MSD, может содержать местоположение автомобиля с высокой точностью (обычно определяемое с помощью приемопередатчика встроенной глобальной навигационной спутниковой системы (GNSS)), количество человек в транспортном средстве, перевернулся ли автомобиль в результате аварии и т.п. Следует отметить, что вызовы eCall или Е911, реализованные в уровне техники, осуществляются в сети с коммутацией каналов.

Формат примерного блока MSD показан на фиг.1. Как показано, размер MSD 100 может изменяться, так как часть элементов информации в блоке MSD являются опциональными. Более конкретно, от содержания поля 102 «Опциональные данные» требуется всего лишь, чтобы оно представляло собой код XML (Extensible Markup Language), а длина поля может изменяться в пределах заданного диапазона. Однако максимальный размер MSD 100 составляет 140 (сто сорок) байтов.

Другой альтернативой блоку MSD является полный блок данных (FSD, full set of data), который может передаваться, если лежащим в основе транспортным механизмом разрешена передача данных экстренного вызова eCall большего размера. Поэтому используемый в настоящем документе термин «данные экстренного вызова eCall (данные eCall)» относится к блокам MSD, FSD или любым другим данным, которые передаются (и могут быть объединены с голосовыми данными) по соединению вызова eCall.

Для передачи данных (например, блока MSD или FSD) существуют несколько потенциальных вариантов. Данные варианты включают: (i) службу коротких сообщений (SMS); (ii) сигнализацию пользователь-пользователь (UUS, user to user signaling); (iii) неструктурированные данные по дополнительным услугам (USSD); (iv) данные сети с коммутацией каналов глобальной системы мобильной связи (GSM); (v) двухтональный многочастотный набор (DTMF); и (vi) внутриполосный модем/сигнализацию. Однако эти решения не обеспечивают достаточных возможностей для своевременной передачи минимального блока данных в комбинации с экстренным вызовом и без перенаправления или изменения маршрутизации в сети с коммутацией пакетов. Следовательно, необходимы улучшенное устройство и способы, устраняющие указанные недостатки.

Раскрытие изобретения

Настоящее изобретение решает поставленную задачу посредством предоставления улучшенных устройства и способов для передачи экстренного или аналогичного вызова в сети беспроводной связи (например, сотовой связи).

В первом аспекте изобретения предлагается способ осуществления экстренного вызова в сети, реализованной с возможностью функционирования с коммутацией пакетов. В одном варианте осуществления сеть обеспечивает функционирование по существу в реальном времени с коммутацией пакетов, а экстренный вызов включает составной поток, содержащий первый поток и один или большее количество вторых потоков. Первый поток предоставляют по существу непрерывным образом, а составной поток формируют с использованием по меньшей мере первого потока и одного или большего количества вторых потоков. Устанавливают сеанс, реализуемый с возможностью маршрутизации составного потока, который передается посредством указанного сеанса.

В одном варианте сеанс включает сеанс реального времени, установленный с использованием протокола инициализации сеанса.

В другом варианте первый поток состоит из множества голосовых пакетов, а один или большее количество вторых потоков включают множество пакетов данных. По существу непрерывный поток предоставляют посредством по существу непрерывного кодирования голосового сигнала с получением голосовых пакетов.

Еще в одном варианте предоставление одного или большего количества вторых потоков осуществляют по существу прерывистым или непостоянным образом, при этом при таком предоставлении предоставляют данные из по меньшей мере одного источника лишь периодически или с перерывами.

Еще в одном варианте составной поток, первый поток и один или большее количество вторых потоков пакетируют, а составной поток формируют путем перемежения одного или большего количества пакетов первого потока с одним или большим количеством пакетов второго потока.

Еще в одном варианте осуществления перемежение осуществляют с использованием алгоритма мультиплексирования.

Еще в одном варианте осуществления формирование составного потока с использованием по меньшей мере первого потока и одного или большего количества вторых потоков осуществляют посредством размещения по меньшей мере части первого потока во множестве пакетов протокола RTP, размещения по меньшей мере части одного или большего количества вторых потоков во множестве пакетов протокола RTCP и перемежения пакетов протокола RTP с пакетами протокола RTCP.

В другом варианте сеть включает сотовую сеть, совместимую с системой 3GPP IMS, а сеанс устанавливают с использованием протокола инициализации сеанса (SIP).

Во втором аспекте изобретения предлагается устройство для осуществления экстренного вызова в сети, реализованной с возможностью функционирования с коммутацией пакетов. В одном варианте осуществления устройство включает микрофон (выполненный с возможностью непрерывного захвата и цифрового разложения голоса на множество первых пакетов), один или большее количество датчиков, выполненных с возможностью кодирования одного или большего количества параметров, связанных с устройством или платформой, на которой установлено устройство, с получением одного или большего количества вторых пакетов, радиопередатчик, выполненный с возможностью передачи множества пакетов по беспроводной сети, вычислительное устройство, соединенное с возможностью обмена данными с радиопередатчиком, и машиночитаемое устройство, содержащее носитель информации, выполненный с возможностью хранения компьютерной программы, содержащей множество инструкций. Указанное множество инструкций при исполнении вычислительным устройством формирует множество пакетов для передачи по меньшей мере частично из перемежения множества первых пакетов с одним или большим количеством вторых пакетов. Указанные инструкции также устанавливают сеанс, обеспечивающий возможность маршрутизации прошедших перемежение множества первых пакетов и одного или большего количества вторых пакетов без их сохранения, и передают прошедшее перемежение множество пакетов посредством радиопередатчика.

В одном варианте формирование множества пакетов для передачи включает формирование множества третьих пакетов, получаемых из прошедших перемежение множества первых пакетов и одного или большего количества вторых пакетов.

В другом варианте устройство дополнительно включает радиоприемник, выполненный с возможностью приема множества пакетов из беспроводной сети, и громкоговоритель, выполненный с возможностью цифрового синтеза голоса из принятого множества пакетов.

Еще в одном варианте устройство дополнительно содержит подсистему громкоговорителя, приемное устройство, выполненное с возможностью приема множества пакетов из беспроводной сети, и устройство разделения, выполненное с возможностью разделения множества пакетов, принятых из сети, на компоненту голоса и компоненту данных. Устройство для разделения выполнено с возможностью передачи компоненты голоса в подсистему громкоговорителя, определения статуса приема одного или большего количества вторых пакетов по компоненте данных.

Еще в одном варианте устройство находится по существу в транспортном средстве, выполненном с возможностью перемещения одного или большего количества находящихся в нем людей.

Еще в одном варианте устройство содержит приемник для спутникового определения местоположения (например, GPS-приемник). В число одного или большего количества датчиков могут входить: (i) акселерометр, выполненный с возможностью определения столкновения; (ii) акселерометр, выполненный с возможностью определения опрокидывания транспортного средства; и (iii) датчик, выполненный с возможностью определения заполнения транспортного средства.

В другом варианте беспроводная сеть представляет собой сотовую сеть, совместимую с требованиями подсистемы мультимедийной базовой сети IP (IMS) 3GPP, а сеанс устанавливается с использованием протокола инициализации сеанса (SIP).

Еще в одном варианте перемежение множества первых пакетов с одним или большим количеством вторых пакетов включает перемежение множества пакетов протокола RTP с одними или большим количеством пакетов протокола RTCP, причем один или большее количество пакетов протокола RTCP содержат минимальный блок данных (MSD).

В третьем аспекте изобретения предлагается сетевое устройство, выполненное с возможностью приема экстренного вызова в сети с коммутацией пакетов. В одном варианте осуществления устройство включает сетевой интерфейс, выполненный с возможностью приема первого и второго множества пакетов посредством сети протокола IP, соединенной с возможностью обмена данными с указанным устройством, вычислительное устройство, соединенное с возможностью обмена данными с указанным интерфейсом, и машиночитаемое устройство, содержащее носитель информации, выполненный с возможностью хранения компьютерной программы, содержащей множество инструкций. Указанное множество инструкций при исполнении вычислительным устройством принимает запрос сеанса связи (обеспечивающего возможность выполнения передачи первого и второго множества пакетов), устанавливает сеанс, принимает первое и второе множество пакетов посредством указанного сеанса, извлекает пользовательские данные по существу реального времени из первого множества пакетов и извлекает данные, относящиеся к экстренной ситуации, из второго множества пакетов.

В одном варианте сетевое устройство дополнительно содержит аудиомодуль, включающий громкоговоритель и выполненный с возможностью воспроизведения с помощью громкоговорителя аудиоинформации, полученной из извлеченных пользовательских данных по существу реального времени.

В другом варианте сеть с коммутацией пакетов включает подсистему мультимедийной базовой сети IP (IMS) 3GPP, а сеанс устанавливается с использованием по меньшей мере протокола инициализации сеанса (SIP).

В другом варианте первое и второе множество пакетов представляют собой прошедшие перемежение пакеты протокола RTP и пакеты протокола RTCP соответственно.

Еще в одном варианте по меньшей мере часть пакетов протокола RTCP содержат минимальный блок данных (MSD). Еще в одном варианте данные, относящиеся к экстренной ситуации, содержат минимальный блок данных (MSD).

Еще в одном варианте сетевое устройство является частью пункта обеспечения общественной безопасности (PSAP).

В четвертом аспекте изобретения предлагается способ осуществления высокоприоритетного вызова в сети, реализованной с возможностью функционирования с коммутацией пакетов. В одном варианте осуществления способ включает предоставление по существу непрерывного потока пользовательских данных и множества данных, относящихся к высокоприоритетному событию. По меньшей мере часть потока пользовательских данных размещают в первой пакетированной структуре протокола, и по меньшей мере часть данных, относящихся к высокоприоритетному событию, размещают во второй пакетированной структуре протокола. Первую и вторую структуры протокола перемежают и составной поток передают по сети посредством сеанса связи.

В одном варианте высокоприоритетный вызов представляет собой экстренный вызов, а данные, относящиеся к высокоприоритетному событию, включают минимальный блок данных (MSD).

В другом варианте сеть представляет собой сотовую сеть третьего поколения (3G), а передача выполняется путем предварительной установки по меньшей мере одного сеанса посредством протокола установки сеанса.

В другом варианте первый пакетированный протокол представляет собой протокол передачи в реальном времени, а второй пакетированный протокол включает протокол управления в реальном времени.

Еще в одном варианте способ инициируют по существу автоматически посредством передающего устройства, расположенного по существу в наземном транспортном средстве, как следствие данного события. Это событие может включать, например, (i) столкновение транспортного средства; (ii) опрокидывание транспортного средства и/или (iii) пожар в транспортном средстве.

Еще в одном варианте данные пользователя содержат как видеоданные, так и голосовые данные.

Еще в одном варианте данные, относящиеся к высокоприоритетному событию, содержат данные о по существу точном местоположении для первого объекта в момент вызова, при этом указанные данные не основаны исключительно на сетевом адресе.

В пятом аспекте изобретения предлагается телекоммуникационное устройство, выполненное с возможностью передачи экстренных вызовов. В одном варианте осуществления при передаче используется надежный транспорт с пакетированным протоколом и один или большее количество экстренных вызовов передаются в объект, выполненный с возможностью приема пакетированных данных из сети и с возможностью обработки данных. Устройство включает радиопередатчик и устройство, соединенное с возможностью связи с передатчиком и выполненное с возможностью осуществления передачи пакетированных данных по сети. Пакетированные данные включают первые пакеты, содержащие пользовательские данные по существу реального времени, и вторые пакеты, перемеженные с первыми пакетами и содержащие данные, относящиеся к экстренной ситуации, причем первый и второй пакеты имеют формат, соответствующий разным протоколам. Каждый из указанных разных протоколов поддерживает требования качества обслуживания для обеспечения вышеупомянутого надежного транспорта.

В одном варианте данные, относящиеся к экстренной ситуации, включают данные о точном местоположении для данного телекоммуникационного устройства в момент вызова (которые могут быть основаны на сетевом адресе или могут не быть основаны на нем).

В шестом аспекте изобретения предлагается способ маршрутизации экстренного вызова от источника к адресату. В одном варианте осуществления в способе определяют, доступны ли как маршрут с коммутацией каналов, так и маршрут с коммутацией пакетов для маршрутизации вызова, при этом, если доступны оба маршрута, оценивают по меньшей мере один из маршрутов по меньшей мере по одному выбранному критерию. На основании, по меньшей мере частично, этой оценки выбирают один из маршрутов и маршрутизируют вызов по выбранному маршруту. Вызов маршрутизируют по маршруту с коммутацией пакетов, если доступен только маршрут с коммутацией пакетов.

В другом аспекте изобретения предлагается сетевой контроллер и соответствующий способ маршрутизации данных экстренного вызова в беспроводной сети со множеством режимов (например, с коммутацией каналов и коммутацией пакетов). В одном варианте осуществления сетевой контроллер содержит логику, выполненную с возможностью определения того, какой из двух вариантов (коммутация пакетов или коммутация каналов) оптимален, на основании одного или большего количества критериев и последующей маршрутизации данных в соответствующей системе связи. Например, по техническим или другим причинам система связи с коммутацией каналов может быть недоступна, при этом будет выбран экстренный вызов eCall в системе связи с коммутацией пакетов.

Еще в одном аспекте настоящего изобретения предлагается машиночитаемое устройство, включающее носитель информации. В некоторых вариантах это устройство представляет собой жесткий диск (HDD), CD-ROM или интегральную схему памяти программ или данных (1С) и хранит одну или большее количество компьютерных программ, реализующих различные аспекты описанной в настоящем документе функциональности.

Другие признаки и преимущества настоящего изобретения станут очевидны специалистами в данной области техники, ознакомленными с прилагаемыми чертежами и подробным описанием примерных вариантов осуществления, приведенным ниже.

Краткое описание чертежей

Фиг.1 представляет собой схему структуры пакета, соответствующей пакету минимального блока данных (MSD) из уровня техники.

Фиг.2 представляет собой блок-схему, иллюстрирующую один вариант осуществления обобщенной операции экстренного вызова для встраивания данных экстренного вызова в голосовой вызов реального времени в соответствии с изобретением.

Фиг.2А представляет собой блок-схему, иллюстрирующую один вариант осуществления операции определения/выбора системы связи для маршрутизации данных экстренного вызова в соответствии с изобретением.

Фиг.3 представляет собой общий пакет транспортного протокола реального времени (RTP) из уровня техники.

Фиг.3A представляет собой один примерный вариант реализации формата пакета протокола передачи в реальном времени (RTP), пригодного для реализации службы экстренного вызова для встроенной в транспортное средство системы (IVS) в соответствии с изобретением.

Фиг.3B представляет собой другой примерный вариант реализации формата пакета протокола передачи в реальном времени (RTP), пригодного для реализации службы экстренного вызова для встроенной в транспортное средство системы (IVS), на которой показаны несколько примерных задаваемых полей, имеющих заранее определенные величины.

Фиг.3C представляет собой еще один примерный вариант реализации формата пакета протокола передачи в реальном времени (RTP), пригодного для реализации службы экстренного вызова для встроенной в транспортное средство системы (IVS), на которой показано поле, служащее для установки порядка пакетов.

Фиг.3D представляет собой один вариант реализации расширенного формата пакета протокола передачи в реальном времени (RTP), пригодного для реализации службы экстренного вызова для встроенной в транспортное средство системы (IVS).

Фиг.4 представляет собой графическую иллюстрацию примерного варианта осуществления операции установления вызова на основании протокола инициализации сеанса (SIP) согласно настоящему изобретению, пригодной для реализации службы экстренного вызова для системы IVS.

Фиг.5 представляет собой графическую схему примера осуществления сотовой системы PSAP, осуществляющей связь с системой IVS с использованием способов и устройств в соответствии с одним вариантом осуществления настоящего изобретения.

Фиг.6А представляет собой функциональную схему одного варианта осуществления устройства PSAP в соответствии с настоящим изобретением.

Фиг.6B представляет собой функциональную схему одного варианта осуществления устройства IVS, расположенного в наземном транспортном средстве (автомобиле) в соответствии с настоящим изобретением.

Осуществление изобретения

Далее приводятся ссылки на чертежи, на которых одинаковые ссылочные номера позиций относится к одинаковым элементам.

В настоящем документе описаны в том числе способы и устройства для предоставления полезных данных, связанных с высокоприоритетным вызовом. В одном варианте осуществления данные представляют собой минимальный блок данных (MSD), внедренный в пакеты протокола управления передачей в реальном времени (RTCP), содержащие поток голосовых данных экстренного вызова (eCall). Описанные устройства и способы предназначены для надежной передачи данных блока MSD из терминала (IVS) в пункт обеспечения общественной безопасности (PSAP) путем использования того же транспортного соединения, что и для голосовых данных. Кроме того, при необходимости пакеты данных блока MSD могут быть модифицированы или изменены, но пакеты голосовых данных могут оставаться неизменными.

В одном аспекте изобретение также обеспечивает естественное преобразование имеющейся сотовой сети из сети с коммутацией каналов (CS) в сеть с коммутацией пакетов (PS) без необходимости существенных изменений для поддержки инфраструктуры служб экстренного вызова. Кроме того, такая реализация подходит для различных типов систем как в системах связи с коммутацией каналов, так и в системах связи с коммутацией пакетов.

В одном варианте осуществления используются соединения для передачи голоса (или других данных реального времени) с коммутацией пакетов, уже использующие протокол RTP для синхронизации, упаковки и других целей. Более конкретно, в потоки пакетов протокола RTP периодически встраиваются пакеты протокола управления передачей в реальном времени (RTCP), при этом такие пакеты протокола RTCP предоставляют каждому участнику адекватную информацию о других участниках, включая такие параметры, как качество приема и описание источников.

В другом варианте для пакетов данных блока MSD используются такие преимущества транспорта данных с коммутацией пакетов, как надежная передача данных, исправление ошибок, повторная передача и/или восстановление данных. В отличие от других способов упаковки данных с голосом, в которых обычно присоединяют поток данных с целью добавления к потоку голосовых данных до него или после него, в контексте протокола RTCP используется «перемежение» (interspersing), то есть поток данных перемежается с голосовым потоком, что позволяет реализовать такие возможности, как постоянное обновление блока MSD, многократная повторная передача блока MSD и т.п.

В другом аспекте описанные устройства и способы в частности пригодны для функционирования в существующей системе сотовой сети. Ввиду ограничений, накладываемых сотовой сетью, должны соблюдаться временные ограничения для передачи стандартных данных экстренного вызова eCall. Преимуществом является то, что для поддержки различных кодированных голосовых данных или других технологий не требуется изменять существующий стек протоколов. Несмотря на то, что настоящее изобретение обеспечивает изменение неголосовых данных посредством компонентов сети, такое изменение не обязательно для правильной работы системы. Более важным является то, что голосовые данные остаются разбитыми на пакеты (пакетированными) и могут передаваться без изменения, что позволяет избежать ошибок, случайных или вызванных перекодировкой или другими подобными операциями.

Еще в одном предпочтительном аспекте маршрутизация данных осуществляется сквозным образом между соответствующими системами (например, системой IVS и пунктом PSAP в случае экстренного вызова eCall), при этом для маршрутизации данных не требуются какие-либо дополнительные компоненты сети или устройства хранения. В отличие от других способов, используемых для передачи данных (которые в целом относятся к описанному выше способу «сохранить и передать»), данные, передаваемые в дополнение к экстренному вызову eCall, могут выполнять требования к временным параметрам и могут передаваться сразу же без ненужного изменения маршрута (например, в домашнюю сеть для пользователя).

Далее подробно описаны примерные варианты осуществления настоящего изобретения. Несмотря на то что указанные варианты осуществления главным образом описаны в контексте связи между примерной встроенной в транспортное средством системой (IVS) и пунктом обеспечения общественной безопасности (PSAP), понятно, что принципы настоящего изобретения могут применяться в системах, отличающихся от систем IVS и пункта PSAP. Например, пользовательское оборудование (UE) текущего поколения, например сотовый телефон 3G, может формировать информацию, необходимую для эффективной передачи данных экстренного вызова eCall в приемное устройство (например, оператору Е911).

Кроме того, настоящее изобретение не ограничено какой-либо сферой или системой (например, экстренным вызовом eCall или Е911 и т.п.) и может применяться практически в любой подобной системе.

Кроме того, несмотря на то что настоящее описание приведено в контексте транспортного протокола реального времени (RTP) и протокола управления передачей реального времени (RTCP) (см. документ RFC 3550 под названием «Протокол RTP: транспортный протокол для прикладных систем реального времени», июль 2003 года, который в полном объеме включен в настоящий документ посредством ссылки), понятно, что в различных вариантах осуществления изобретения могут быть использованы другие протоколы, что должно быть очевидным для специалиста в данной области техники, знакомого с настоящим описанием. Например, в настоящим изобретении могут использоваться в том числе протокол RTSP (см. документ RFC 2326 под названием «Протокол потоковой передачи данных в реальном времени (RTSP)», март 1998 г., который в полном объеме включен в настоящий документ посредством ссылки), протокол SRTP (см. документ RFC 3711 под названием «Безопасный протокол передачи в реальном времени (SRTP)», март 2004 г., который в полном объеме включен в настоящий документ), протокол SCTP (см. документ RFC 4960 под названием «Протокол управления потоковой передачей данных», сентябрь 2007 г., который в полном объеме включен в настоящий документ посредством ссылки») и/или протокол ZRTP (см. документ «ZRTP: Media Path Key Agreement for Secure RTP - draft-zimmermann-avt-zrtp-10» от 25 октября 2008 г., который также в полном объеме включен в настоящий документ посредством ссылки).

Кроме того, несмотря на то что некоторые варианты осуществления изобретения описаны в контексте наземных транспортных средств, таких как автомобили или грузовики, изобретение этим не ограничивается и может применяться для других транспортных или иных средств, включая в том числе поезда, самолеты, суда и мотоциклы.

Способы

На фиг.2 показан первый вариант осуществления обобщенной операции 200 для передачи данных (например, минимального блока данных или блока MSD), перемеженных с голосовым пакетным потоком, таким образом, что в сети с коммутацией пакетов поддерживается высокоприоритетный вызов (например, экстренный вызов eCall, определенный ниже). Используемый в настоящем документе термин «высокий приоритет» («высокоприоритетный») в целом относится в том числе к вызовам или другим передачам данных, имеющим большую срочность или приоритет, чем остальной трафик. Одним из примеров высокоприоритетного вызова является экстренный вызов полиции, пожарной службы, медицинской помощи и т.п. Другой пример высокоприоритетного вызова может относится к вызовам (даже стандартным вызовам) между сотрудниками правоохранительных органов, пожарных частей, государственными организациями, военнослужащими и т.п. или любыми другими людьми или группами, имеющими более высокий ранг или необходимость доступа к средству связи.

Используемый в настоящем документе термин «экстренный вызов eCall» относится в том числе к экстренным вызовам и услугам, описанным в том числе в документе 3GPP TS 23.167 V8.1.0 (сентябрь 2008 г.) под названием «Техническая спецификация - проект партнерства третьего поколения. Групповые услуги и системы. Сеансы экстренной связи мультимедийных подсистем IP (IMS) (издание 8)», который в полном объеме включен в настоящий документ посредством ссылки и в котором описаны услуги «стадии 2» для экстренных служб в мультимедийной базовой подсети IP (IMS), включая элементы, необходимые для поддержки экстренных служб IP Multimedia (IM). В рекомендациях Комитета по телекоммуникациям Международного союза электросвязи (ITU-T) 1.130, которые в полном объеме включены в настоящий документ посредством ссылки, описан состоящий из трех стадий способ классификации телекоммуникационных услуг, а в рекомендациях ITU-T Q.65, которые в полном объеме включены в настоящий документ посредством ссылки, определена стадия 2 указанного способа. В документе TS 23.167 V8.1 также рассмотрены аспекты сети доступа, имеющие важное значение для предоставления экстренных служб IMS. Другие спецификации организации по стандартизации 3GPP, относящиеся к экстренным службам IMS, включают TS 23.228 (система IMS в целом), TS 23.234 (описано взаимодействие 3GPP/WLAN) и TS 23.271 (службы местоположения), каждая из которых в полном объеме включена в настоящий документ посредством ссылки. Спецификация TS 25.301, которая также в полном объеме включена в настоящий документ посредством ссылки, содержит общее описание наземной сети радиодоступа UMTS.

К другим спецификациям, не являющимся спецификациями организации по стандартизации 3GPP, относящимся к экстренным службам IMS, относятся 3GPP2 cdma2000 HRPD IP-CAN, как указано в документах 3GPP2 C.S0024-A и 3GPP2 X.S0011, каждый из которых в полном объеме включен в настоящий документ посредством ссылки.

На шаге 202 операции 200 осуществляют высокоприоритетный вызов. В одном примерном варианте осуществления вызов автоматически инициируется клиентским устройством или пользовательским устройством и ему назначается статус экстренного вызова, как, например, в случае, когда транспортное средство автоматически инициирует экстренный вызов при обнаружении аварии. Используемые в настоящем документе термины «клиентское устройство» и «пользовательское устройство» могут включать в том числе сотовые телефоны, смартфоны (например, iPhone™), персональные компьютеры (PC), например iMac™, Mac Pro™, Mac Mini™ или MacBook™, а также миникомпьютеры, в том числе настольные компьютеры, переносные компьютеры, а также такие мобильные устройства, как карманные компьютеры, карманные персональные компьютеры (PDA), видеокамеры, телевизионные приставки, персональные мультимедийные устройства (PMD), встроенные в транспортное средство системы или любые комбинации указанных выше устройств.

Еще в одном варианте вызов осуществляется пользователем, например пользователем, осуществляющим экстренный вызов с целью запроса помощи.

Момент, в который (а также используемый при этом механизм) вызову назначается статус экстренного, может зависеть от способа осуществления вызова или сети, в которой осуществляется вызов. В одном варианте статус экстренного вызова немедленно отмечается осуществляющей вызов стороной, например, путем включения данных, указывающих на такой статус (например, поля данных, имеющего заданную величину, установленный флаг и т.п.), например, в заголовке сообщения. В другом случае вызов может осуществляться как специальный вызов. Например, при экстренных вызовах с коммутацией каналов (в соответствии со спецификацией 3GPP TS 24.008, которая в полном объеме включена в настоящий документ посредством ссылки) объект управления вызовом передает сообщение установления экстренного вызова для установки вызова (в отличие от передачи сообщения установления для нормальных вызовов). В другом примере при экстренных вызовах IMS (в соответствии с документом 3GPP TS 24.229, в полном объеме включенном в настоящий документ посредством ссылки) пользовательское устройство UE использует службу универсального имени ресурса (URN) со службой верхнего уровня «sos» (как указано в документе RFC 5031, включенном в полном объеме в настоящий документ посредством ссылки). В других альтернативных вариантах осуществления для определения статуса экстренного вызова используются один или несколько компонентов информации о маршрутизации соединения. В одном таком варианте статус экстренного вызова назначается сетевым объектом, например, когда пакет перехватывается и обрабатывается как экстренный вызов ввиду его информации о маршрутизации (например, источника или адресата, когда пользователь или пользовательское устройство осуществляет вызов заданного номера, например 911).

На шаге 204 операции 200 инициируют доступ к сети. В одном примерном варианте осуществления процедуры аутентификации и авторизации, используемые обычно для сотовых служб, обходятся или ускоряются. Сеть может либо получить указание из системы IVS о том, что вызову следует присвоить статус экстренного, или сеть может определить на основании информации о маршрутизации, что вызову следует присвоить приоритет экстренного вызова. Кроме того, такой доступ может быть основан на соединении или же может относится к типу, не основанному на соединении. Такой сетевой доступ может инициироваться с использованием любого из распространенных транспортов. Используемый в настоящем документе термин «транспорт» относится в том числе к любому транспортному протоколу, обеспечивающему возможность передачи данных по физическому интерфейсу (PHY), например протокол управления передачей (TCP), протокол дейтаграмм пользователя (UDP), протокол управления перегрузкой дейтаграмм (DCCP), протокол передачи в реальном времени/протокол управления передачей в реальном времени (RTP/RTCP), а также протокол управления потоковой передачей (SCTP). Такой сетевой доступ далее называется транспортным потоком и включает, как минимум, один или большее количество пакетов, содержащих такие данные, как локальный источник, локальный адресат, поле контрольной суммы и поле данных. Локальный источник представляет собой в примерном варианте осуществления сетевой адрес системы IVS, а локальный адресат представляет собой адрес пункта PSAP (не обязательно центр маршрутизации).

На шаге 206 в транспортном потоке устанавливается или добавляется уровень протокола передачи в реальном времени (например, протокол RTP, RTSP и т.п.). Как подробно описано ниже, такой протокол передачи в реальном времени включает, как минимум, информацию, которая после преобразования указывает на конкретное время и/или последовательность событий во времени (например, пакеты с соответствующими величинами времени или индексами).

На шаге 208 указанной операции формируют два или большее количество потоков, по меньше мере один из которых представляет собой машиночитаемый поток данных, и по меньшей мере один из которых представляет собой оцифрованное (например, сжатое) представление голоса или любых подобных полезных (пользовательских) данных. Используемый в настоящем документе термин «поток» может использоваться для обозначения как по существу непрерывного, так и прерывистого (например, периодического или имеющего перерывы) потока данных.

В одной реализации указанной выше операции для оцифровки пользовательского голоса, принимаемого аналоговым микрофоном, используется голосовой кодер (вокодер) с линейным предсказанием (CELP), например ACELP, QCELP, RCELP, LD-CELP (например, G.728) и т.п. Машиночитаемый поток данных остается читаемым и перезаписываемым другими компонентами сети, причем цифровое представление голоса защищено от изменения другими компонентами сети.

На шаге 210 указанной операции два потока перемежают для передачи по сети с использованием протокола передачи в реальном времени. Более конкретно, в одном варианте данные из машиночитаемого потока данных внедряют в один или большее количество пакетов RTCP, которые затем вставляют или перемежают в поток пакетных пользовательских данных (например, пакеты RTP, содержащие указанный выше оцифрованный голос). Перемежение может осуществляться с использованием любого из подходов, используемых в области обработки цифровой информации, включая такие способы, как мультиплексирование данных (например, когда для распределения одного потока данных в одном или большем количестве других потоков используется мультиплексор или перемежитель) и/или присоединение (например, когда данные присоединяются или другим образом прикрепляются к существующему потоку).

На шаге 212 начинают сеанс, в котором передаются перемеженные потоки, содержащие комбинацию машиночитаемых данных и цифровое представление голоса. Для установки этого сеанса могут использоваться различные механизмы, включая, например, основанный на сеансе протокол, такой как протокол SIP (описанный в настоящем документе ниже). Сеанс осуществляется по одному сетевому соединению, причем сетевой канал имеет исходную оконечную точку (система IVS) и целевую оконечную точку (пункт PSAP). Несмотря на то что канал в сети может формироваться с использованием промежуточных узлов между множеством соединений транспортного уровня, канал остается одинаковым как для машиночитаемых данных, так и для оцифрованного представления голоса. То есть канал между оконечными точками может изменяться, но всегда одинаков для машиночитаемых данных и оцифрованного голоса или других полезных данных.

Кроме того, в реальном времени осуществляют многопоточный сеанс, и преимущества, касающиеся статуса экстренного вызова, обеспечиваются как для голоса, так и данных.

При приеме в пункте PSAP два или большее количество потоков данных разделяют, например, посредством демультиплексирования, при этом маршрутизируют пакеты на основании данных, содержащихся в заголовках пакетов, которые их идентифицируют (например, пакет RTCP или пакет RTP), из чего следует, к какому потоку относится каждый пакет, или посредством других хорошо известных механизмов. Поток машиночитаемых данных обрабатывается для определения, по меньше мере частично, одного или большего количества параметров, относящихся к системе IVS. Цифровое представление голоса восстанавливают в звуковой сигнал для передачи, хранения и/или проигрывания оператору или системе распознавания голоса.

Следует понимать, что, несмотря на то что в приведенных вариантах осуществления используется поток машиночитамых данных вместе с оцифрованным голосом, изобретение может с таким же успехом применяться в случае, когда дополнительная компонента потока не является оцифрованным голосом, а представляет собой другой тип оцифрованного контента (например, другое информационное содержание, такое как видео, файловые данные и т.п.), то есть изобретение не ограничивается только голосовыми данными. Например, одно из устройств или датчиков системы IVS (описанной более подробно ниже) может содержать камеру, которая может формировать поток пакетов графических данных или видеоданных, которые при необходимости могут передаваться в пункт PSAP.

Следует также отметить, что голос и/или видео могут быть получены пассивно или без ведома пользователя, например, когда транспортное средство было угнано, и встроенный микрофон и/или камера используется для передачи голосовых/видеоданных в пункт PSAP или другую систему без ведома угонщика.

Кроме того, в некоторых вариантах осуществления изобретения может иметь смысл использовать протокол RTCP даже без RTP-контента. Такие варианты осуществления могут быть реализованы без полезной нагрузки как таковой, например в случае вызова, который инициируется автоматически и передает только заранее заданные данные, связанные с событием (например, система обнаружения и сообщения об угоне, которая передает идентификационный номер автомобиля (VIN), местоположение, получаемое системой AGPS, и т.п.).

Кроме того, передача любых полезных данных может представлять собой один из типов межмашинной передачи (М2М, machine-to-machine), описание одного примерного варианта реализации которой в системе беспроводной (например, сотовой) связи см., например, в одновременно находящейся на рассмотрении заявке США того же заявителя №12/231,095, поданной 29 августа 2008 года, «Способы и устройство для обслуживания на основании межмашинной передачи данных», которая в полном объеме включена в настоящий документ посредством ссылки. Кроме того, несмотря на то что межмашинная передача данных может обеспечивать основу полезной информации в настоящем изобретении, следует понимать, что классификация данного вызова как экстренного (или в общем случае имеющего высокий приоритет), так и межмашинного может использоваться как основа для различной обработки вызова и осуществления маршрутизации, описанных выше. Например, вызовам, которые являются и межмашинными, и экстренными по своему характеру, может присваиваться меньший приоритет, чем пользовательским вызовам, так как предполагается, что экстренная ситуация, связанная с машиной (то есть инициатором вызова), имеет меньший приоритет, чем спасение человеческой жизни. Однако это справедливо не всегда, как, например, в случае, когда «машина» в системе М2М, инициирующая вызов, представляет собой машину, связанную с важной частью инфраструктуры, которая может неблагоприятно повлиять на человеческую жизнь, например трансформатор электрической распределительной подстанции, связанный с большим городом или больницей, датчик напряжения/тензодатчик моста, указывающий на приближающийся отказ и т.п. Поэтому настоящее изобретение предусматривает использование не только части данных, внедренной в пакеты RTCP или подобные пакеты, но также межмашинных данных (то есть сформированных инициирующей машиной, относящейся к родительскому устройству, и внедренных в пакеты RTP или пакеты полезных данных) в качестве основы для разделения обработки вызовов, назначения приоритетов и/или маршрутизации.

На фиг.2А показан один вариант осуществления способа определения и выбора сетей с коммутацией каналов и сетей с коммутацией пакетов. Несмотря на то что настоящее изобретение, в частности, выполнено с возможностью работы в сети с коммутацией пакетов, тем не менее могут возникать случаи, в которых также может быть доступно обслуживание в сети с коммутацией каналов. Поэтому в другом варианте изобретения не просто по умолчанию используют передачу в сети с коммутацией пакетов, а используют логику выбора или оценки до решения о выполнении экстренного вызова с использованием одной или другой системы связи. Эта логика может быть реализована, например, в сетевом устройстве (например, контроллере маршрутизации вызова), или в самом клиентском устройстве (например, системе IVS), или и там, и там.

Как показано на фиг.2А, первый шаг 252 способа 250 представляет собой определение того, доступны ли и маршрут с коммутацией каналов, и маршрут с коммутацией пакетов для маршрутизации вызова. Эти данные могут быть жестко заданы (например, на основании инфраструктуры сети и поэтому неизменны) или в другом варианте могут быть основаны на одном или большем количестве индикаторов состояния. Например, транспорт на основе коммутации каналов может быть включен как часть инфраструктуры сети, однако такой транспорт может быть в данный момент недоступен (например, из-за технического обслуживания, отказа оборудования или очень высокой нагрузки/перегрузки).

На шаге 254, если доступны и маршрут в системе связи с коммутацией каналов, и маршрут в системе связи с коммутацией пакетов, то затем логика выбора оценивает по меньшей мере один из маршрутов по меньшей мере по одному критерию выбора (шаг 256). Например, в одном варианте оцениваются оба маршрута по перегрузке (которая указывается посредством задержки передачи пакетов в системе связи с коммутацией пакетов, например, по опозданию пакетов или длительным задержкам в установке сквозного канала в системе связи с коммутацией каналов). В другом варианте оценка может включать применение иерархического подхода, например оценку только системы связи с коммутацией пакетов по перегрузке и при удовлетворительном результате - использование системы связи с коммутацией пакетов, а в противном случае - использование системы связи с коммутацией каналов. Также могут быть использованы более одного критерия оценки, например перегрузка/задержка, надежность, пропускная способность/объем полезных данных и т.п. Специалистам в данной области техники, знакомым с настоящим описанием, будут очевидны множество разных схем и критериев оценки.

На шаге 258 выбирают один из двух маршрутов (или оба в зависимости от приоритета вызова и потенциальной надежности/задержки) на основании указанной выше оценки на шаге 256, и на шаге 260 осуществляют маршрутизацию вызова в выбранной системе (системах) связи.

Описанные выше примерные способы, показанные на фиг.2 и 2А, подчеркивают множество преимуществ настоящего изобретения по сравнению с перечисленными ранее существующими решениями для передачи данных (то есть службой коротких сообщений (SMS), сигнализацией пользователь-пользователь (UUS), неструктурированными данными по дополнительным услугам (USSD), данными сети с коммутацией каналов глобальной системы мобильной связи (GSM), двухтональным многочастотным набором (DTMF) и внутриполосным модемом/сигнализацией). Более конкретно, в службе SMS используется ненадежная передача сообщений размером 140 байтов по сотовой сети из одного терминала в другой. SMS-сообщения обрабатываются в сети с использованием системы хранения и передачи для улучшения управления ресурсами сети, однако главный недостаток службы SMS заключается в том, что короткие сообщения маршрутизируются в SMS-центр домашней сети пользователя, в то время как экстренные вызовы eCalls предпочтительно должны обрабатываться в гостевой сети (для предоставления услуг связи для абонентов в роуминге). Для находящегося в роуминге пользователя, инициирующего в данный момент экстренный вызов, SMS-сообщения маршрутизируются перед доставкой в свою домашнюю сеть для хранения. Непрямое управление SMS-маршрутизацией требует существенных изменений для интеграции с другими механизмами экстренных вызовов (eCall). Другим недостатком службы SMS является ее сравнительная ненадежность. Служба SMS не гарантирует доставку и не указывает время доставки, при этом обратная связь от получателя к отправителю опциональна и может быть несвоевременной или ненадежной. Наконец, служба SMS зависит от наличия в мобильном устройстве модуля идентификации абонента (SIM) для аутентификации. Каждый из указанных недостатков устранен посредством описанной в настоящем документе технологии.

Таким же образом, служба UUS представляет собой еще одну службу, которая обеспечивает сигнализацию пользователь-пользователь посредством небольших фрагментов данных в течение процесса установления вызова или сразу после него. Служба UUS ограничивает объем передаваемых данных. В службах UUS некоторых типов блок MSD необходимо было бы уменьшить до тридцати двух (32) байтов. Кроме того, служба UUS не используется операторами широко, а модернизация существующего сетевого оборудования является дорогой и сложной. Служба UUS является службой, которая реализуется как часть протокола управления вызовом, и доступна только для вызовов в системе связи с коммутацией каналов или в протоколах с фиксированной линией связи, как в цифровой сети с интегрированным обслуживанием (ISDN). В настоящее время в сетях с коммутацией пакетов указанная служба недоступна, а ее использование для экстренных вызовов запрещено операторами сети.

Служба USSD похожа на службу UUS и имеет некоторые сходные признаки. Служба USSD обеспечивает передачу ста восьмидесяти (180) байтов информации или более. Служба USSD может работать независимо или в любой момент для поддержки текущего вызова. Во многом, как и в службах UUS и SMS, в службе USSD передача данных маршрутизируется в домашнюю сеть, таким образом изменения в службе USSD для управления экстренными вызовами eCall в роуминге должны перенаправлять экстренный вызов eCall в гостевую сеть. Использование службы USSD, как и службы UUS, для экстренных вызовов в настоящее время запрещено. Служба USSD также реализована как часть протоколов системы связи с коммутацией каналов и доступна только для вызовов в сотовых сетях с коммутацией каналов (и недоступна в системах связи с коммутацией пакетов).

Другие существующие способы передачи данных с коммутацией каналов, которые не подходят для экстренных вызовов, включают сеть передачи данных GSM с коммутацией каналов и двухтональный многочастотный набор (DTMF). Сеть передачи данных GSM с коммутацией каналов может передавать данные на скорости передачи 9,6 кбит/с в системе связи с коммутацией каналов. К сожалению, время установки вызова в сети передачи данных GSM с коммутацией каналов превышает требования службы экстренных вызовов eCall и сеть передачи данных GSM с коммутацией каналов может работать только в системе связи с коммутацией каналов (в основе сети GSM лежит сеть с коммутацией каналов). Двухтональный многочастотный набор мог бы вероятно использоваться для очень медленной передачи блоков MSD, однако передача ста восьмидесяти (180) байтов заняла бы более тридцати шести (36) секунд. Кроме того, двухтональный многочастотный набор ненадежен и не обеспечивает исправление ошибок.

Сигнализация с помощью внутриполосного модема представляет собой используемый в настоящее время способ, имеющий некоторый коммерческий успех в системе OnStar™, используемой в США. Блок MSD передается внутри полосы в начале вызова с использованием установочного голосового соединения. Маршрутизация и адресация не представляют проблем для сети, и блок MSD всегда принимается пунктом обеспечения общественной безопасности (PSAP). К сожалению, для декодирования данных блока MSD из голосового потока требуются дополнительные усилия как терминала IVS, так и пункта PSAP. Кроме того, в некоторых сетях сеть должна осуществлять перекодировку голосовых данных из одного голосового кодека в другой из-за потенциальной несочетаемости поддерживаемых голосовых кодеков между системой IVS и пунктом PSAP. Процесс перекодировки может внести ошибки в блок MSD данных экстренного вызова eCall или даже закончиться неуспешно, если при перекодировании возникнут нераспознаваемые артефакты передаваемых данных, встроенные в голосовой поток.

Таким образом, очевидны множество преимуществ описанной в настоящем документе технологии по сравнению с существующими и традиционными технологиями.

Пакетный протокол RTCP АРР

В одной примерной реализации в настоящем изобретении предусмотрено размещение данных, подлежащих передаче (например, минимального блока данных (MSD)), в пакетах протокола управления передачей в реальном времени (RTCP), передаваемых по голосовому соединению экстренного вызова eCall. Временные параметры и частота пакетов RTCP описана в том числе в документе «RTP, Audio and Video for the lnternet» Colin Perkins; Addison-Wesley, 2003 ISBN 0-672-32249-8 2003, который в полном объеме включен в настоящий документ посредством ссылки, а также в указанном выше документе RFC 3550.

Для большинства реализаций протокола RTP требуется небольшой объем служебных данных. Более конкретно, для эффективной передачи отправителями в реальном времени может использоваться некоторая информация, относящаяся к качеству приема у получателя. Кроме того, получателям может требоваться информация о других участниках сеанса, такая информация может включать, например, информацию о том, являются ли другие участники отправителями, получателями или и теми, и другими. Также периодически передаются данные управления. Соответствующий протокол управления RTP (RTCP) определяет и описывает, как и когда эта дополнительная информация управления добавляется как встроенные данные в поток пакетов пользовательских данных протокола RTP. Таким образом, протокол RTCP повышает количество пакетов и объем данных, которые передаются, по сравнению с другими вариантами. Однако сигнализация протокола RTCP, как правило, потребляет менее пяти (5%) процентов от общего объема потока данных реального времени.

Для двунаправленного голосового соединения, работающего на скорости 12,8 кбит/с, между системой IVS и PSAP можно ожидать, что пакеты RTCP будут отправляться приблизительно один раз каждую секунду. В начале соединения первый пакет RTCP будет отправлен через половину этого интервала (0,5 секунды).

Протоколом RTCP определены пять типов пакетов, к которым относятся: (1) сообщения получателя, (2) сообщения отправителя, (3) описания источника, (4) сообщения управления членством и (5) прикладные пакеты (АРР). В то время как пакеты первых четырех типов имеют определенную структуру и не имеют возможности расширения структуры пакета, пакеты АРР определены гибким образом с возможностью размещения индивидуальной для приложения информации. Соответственно, в одном варианте осуществления настоящего изобретения пакет АРР протокола RTCP используется для передачи блока MSD из встроенной в транспортное средство системы (IVS) в пункт обеспечения общественной безопасности (PSAP).

Как показано на фиг.3, формат пакета 300 АРР протокола RTP уровня техники состоит из нескольких элементов информации. Более конкретно, первый элемент 302 информации идентифицирует версию [V] протокола, при этом в текущей версии протоколов RTP и RTCP эта величина, как правило, задается равной двум (в двоичной системе представлена как 10#b). Второй элемент 304 информации представляет собой бит заполнения [Р], который определяет, содержит ли этот отдельный пакет протокола RTCP несколько дополнительных октетов заполнения в конце, которые не являются частью информации управления, но включены в поле длины. Последний октет заполнения представляет собой количество октетов заполнения, которые должны быть проигнорированы. Например, если пакет 300 АРР протокола RTP содержит восемь (8) октетов, последний октет включает биты с 56 по 63. В другом примере, если длина равна восьми (12) октетам, последний октет включает биты с 88 по 95.

Третий элемент 306 информации представляет собой подтип, который может использоваться как подтип для обеспечения определения группы пакетов АРР под одним уникальным именем или для любых индивидуальных для приложения данных.

Четвертый элемент 308 информации представляет собой тип пакета [РТ], который указывает пакет АРР протокола RTCP, и в этом примере обозначен величиной [204] (представленной в двоичной системе как 11001100#b).

Пятый элемент 310 информации представляет собой поле длины [length] пакета протокола RTCP в слове длиной 32 бита минус один (1), которая включает заголовок и любое заполнение.

Шестой элемент 312 информации представляет собой поле имени [name], которое определяет группу пакетов АРР протокола RTCP, определенных одним и тем же пользователем и/или используемых для одной и той же цели.

Седьмой элемент 314 информации представляет собой индивидуальные для приложения данные [application-dependant data], которые представляют собой поле с необозначенным концом, которое используется приложением (то есть не используется для обработки RTCP АРР). Одно специфическое требование для длины индивидуальных для приложения данных заключается в том, что оно должно быть кратно тридцати двум (32) битам, так чтобы точно входить в границы слова в 32 бита.

На фиг.3A-D показаны различные варианты осуществления примерных форматов пакетов 350 АРР протокола RTP, используемых для встраивания данных экстренного вызова в соответствии с настоящим изобретением. Подобно пакетам из уровня техники, показанным на фиг.3, первый элемент 352 информации идентифицирует версию [V] протокола, при этом в текущей версии протоколов RTP и RTCP эта величина, как правило, задается равной двум (в двоичной системе представлена как 10#b).

Таким же образом второй элемент 354 информации представляет собой бит заполнения [Р], который определяет, содержит ли этот отдельный пакет протокола RTCP несколько дополнительных октетов заполнения в конце, которые не являются частью информации управления, но включены в поле длины.

Третий элемент представляет собой поле подтипа (описанное подробнее ниже).

Четвертый элемент 358 информации представляет собой тип пакета [РТ], который указывает пакет АРР протокола RTCP, и в этом примере обозначен величиной [204] (представленной в двоичной системе как 11001100#b).

Пятый элемент 360 информации представляет собой поле длины [length] пакета протокола RTCP слове длиной 32 бита минус один (1), которая включает заголовок и любое заполнение.

На фиг.3A и фиг.3B показаны примерные варианты осуществления пакетов АРР протокола RTCP. Для оптимального использования существующего формата 350 пакета АРР протокола RTCP все определенные экстренным вызовом eCall пакеты содержат общую строковую величину (например, «eCal») в поле 362 имени (см. фиг.3A). Кроме того, величины поля 356 подтипа, определенные для службы экстренного вызова eCall, могут дифференцировать разные типы данных, например минимальный блок данных (MSD), полный блок данных (FSD) и т.п. В другом варианте при других реализациях в поле 362 имени может указываться и пакет, характерный для экстренного вызова eCall, и тип данных, содержащихся в пакете. Поле 356 подтипа может при этом использоваться для других целей, например первых пяти битов блока MSD или блока FSD (как показано на фиг.3B).

Пакеты протокола RTP и RTCP передаются в настоящем варианте осуществления посредством транспортного протокола UDP, который, как описано выше, не гарантирует отправителю корректный прием отправленного пакета (в отличие от протокола TCP). В некоторых случаях может быть необходимо предоставить подтверждение (АСК) получателем, указывающее, (i) принят ли пакет целым и вовремя, или (ii) ситуацию отказа (например, пакет поврежден, опоздал или утрачен). В одном примерном варианте осуществления пакеты АРР протокола RTCP могут использоваться для подтверждения успешного приема получателем. Следует отметить, что во всех пакетах АРР протокола RTCP (как показано на фиг.3A-D), формат протокола RTCP обеспечивает простую передачу подтверждений посредством определения величины поля 356 подтипа или соответствующей величины поля 362 имени.

Как показано на фиг.3C и фиг.3D, еще в одном варианте осуществления получатель данных экстренного вызова eCall (например, пункт PSAP) может быть выполнен с возможностью подтверждения определенного сообщения экстренного вызова eCall, если отправителем (например, IVS) передано более одного сообщения. Добавление номера пакета в поле 356 подтипа и ссылки, привязывающей номер пакета к соответствующему сообщению подтверждения, обеспечивает надлежащий прием по порядку и разделение множества сообщений. Передача номера пакета может осуществляться посредством, например, поля 356 подтипа, как показано на фиг.3C, либо для пакета данных экстренного вызова eCall, либо для соответствующего ему пакета подтверждения. В другом варианте номер пакета может быть включен в поле 364 индивидуальных для приложения данных, как показано на фиг.3D.

В дополнительном варианте осуществления пункт PSAP может иметь возможность запрашивать обновление данных экстренного вызова eCall у системы IVS. Сообщение обновления может иметь формат, подобный пакетам подтверждения (или любой формат пакета, пригодный для передачи из пункта PSAP в систему IVS). Запросы обновления также могут содержать указание на информацию, которая должна быть обновлена, такие обновления могут использоваться, например, для получения определенных динамических условий. В одном таком варианте для уменьшения объема служебной информации передается только запрошенная информация (или информация, изменившаяся с момента последнего запроса). Кроме того, эта информация может быть встроена в поле 364 индивидуальных для пользователя данных или иное место, если необходимо.

Еще в одном варианте осуществления могут быть выполнены требования более быстрой передачи для определенных частей данных экстренного вызова путем разделения ста сорока (140) байтов данных на первую часть, которая передается в первом пакете протокола RTCP, и вторую часть, которая передается в одном или большем количестве пакетов протокола RTCP отдельно от первой части. Могут использоваться любые комбинации длины первой и второй части данных. В одном таком примере первый пакет может содержать первые пять элементов информации блока MSD, которые вместе не превышают тридцать восемь (38) байтов, а вторая часть может содержать остальную часть, объем которой составляет до ста шести (106) байтов. Меньший первый пакет передается очень быстро, а второй оставшийся пакет может быть передан в следующем сеансе передачи протокола RTCP, запланированном в системе IVS.

Кроме того, в добавление к описанным выше вариантам осуществления мобильная сотовая сеть, поддерживающая более одного механизма экстренного вызова eCall, также может поддерживать различные форматы сообщений для указания на то, какой механизм экстренного вызова eCall должен использоваться. Такое указание происходило бы при установке вызова для идентификации механизма, применимого для конкретного сеанса экстренного вызова eCall.

В другом варианте согласование механизма также может осуществляться при установлении вызова. Одним из распространенных протоколов, используемых для описания и инициализации информации о сеансе, является хорошо известный протокол инициализации сеанса (SIP). Мультимедийная подсистема базовой сети IP (IMS) представляет собой сетевую архитектуру, основанную на протоколе SIP, при этом подсистема IMS определяет способы установки, управления и завершения сеанса в мобильной сотовой сети. Более конкретно, вызовы в системе связи с коммутацией пакетов (PS), как правило, согласуются и устанавливаются в подсистеме IMS с использованием протокола SIP до фактической передачи каких-либо данных. См. в том числе документ 3GPP TS 23.228 V8.6.0 (сентябрь 2008) «Техническая спецификация - Проект - партнерства третьего поколения. Групповые услуги и системы. Мультимедийная IP подсистема (IMS). Стадия 2 (издание 8)», который в полном объеме включен в настоящий документ посредством ссылки. В протоколе SIP для определения параметров, связанных с данным сеансом, используется протокол описания сеанса (SDP, session description protocol).

В протоколе SIP можно добавлять «а-line» (строку атрибута) в описании сеанса для указания на то, какой механизм сигнализации данных экстренного вызова eCall используется. Например, в системе, в которой доступны два поддерживаемых формата (например, внутриполосная сигнализация по протоколу RTCP и голосовой кодек), дескрипторы строки атрибута могут обозначать два отдельных типа потока:

a=eCallDataTxMechanism:lnBandRTCP

a=eCallDataTxMechanism:lnBandVCodec

При соответствующем отклике происходит выбор одного из двух вариантов потока на основании, например, логики выбора в сети. Выбор может быть основан, например, на характерных характеристиках вызывающего устройства, оптимизации сети или критерии работы, задержке и т.п.

Однако следует отметить, что в конкретном случае протокола SIP первичный протокол SIP RFC (RFC 3261) не поддерживает назначение приоритетов ресурсам, но существует дополнительный документ RFC (RFC 4412 под названием «Приоритет ресурсов связи для протокола инициации сеанса (SIP)», датированный февралем 2006 года и включенный в полном объеме в настоящий документ), который разработан для расширения возможностей протокола SIP с целью обеспечения назначения приоритетов вызова. Более конкретно, в документе RFC 4412 определены два новых поля заголовка протокола SIP, которые позволяют устройству запрашивать высокоприоритетную обработку вызова последующими элементами.

Описание примера осуществления изобретения

В приведенном ниже примере подробнее описана реализация структуры пакета и форматов сообщения указанного выше протокола RTCP АРР, используемого для инициации и обработки экстренного вызова eCall с применением как голосовых, так и внутриполосных потоков данных сигнализации.

В соответствии с одним вариантом осуществления для инициации вызова с коммутацией пакетов встроенная в транспортное средство система (IVS) устанавливает связь с базовой станцией. В некоторых многорежимных системах системе IVS может требоваться идентифицировать себя как устройство с коммутацией пакетов (например, когда перекрываются сети с коммутацией каналов и пакетов или когда доступны оба варианта). Базовая станция выделяет системе IVS адресный физический ресурс трафика (например, временной интервал, полосу частот, кодовую область и т.п.) и логический канал. Назначение логического канала позволяет системе IVS осуществлять связь с мультимедийной подсистемой базовой сети IP (IMS) посредством логического канала, который передается посредством назначенного адресного физического ресурса трафика.

Система IVS инициирует вызов пункта PSAP с использованием протокола инициализации сеанса (SIP). Перед обменом голосом или данными экстренного вызова eCall в установленном сеансе должен быть осуществлен обмен сообщениями, показанный на фиг.4. Следует отметить, что с целью упрощения описания при передаче сообщений на фиг.4 подробно не показан весь контент сообщений протокола SIP.

Как показано в примере на фиг.4, система IVS передает первоначальный запрос 402 SIP INVITE (запрос-приглашение), внедренный в пакет протокола IP с соответствующими заголовками протоколов IP и UDP. Запрос SIP INVITE включает целевой адрес вызываемого терминала (например, PSAP) и указывает на то, что вызываемый терминал приглашается для участия в сеансе вызова (например, экстренного вызова eCall). На фиг.4 также показаны специальные строки атрибута, используемые в описании сеанса сообщения SIP INVITE и описанные выше. Примерный запрос SIP INVITE, показанный на фиг.4, включает указанные выше строки атрибута для передачи связанных с экстренной ситуацией данных в качестве сигнализации внутриполосного голосового кодека или внутриполосного протокола RTCP в соответствии с настоящим изобретением.

Как правило, базовая станция отправляет запрос INVITE в различные объекты сети для осуществления управления доступом, авторизации и учета. В случае экстренного вызова eCall объекты сети выборочно пропускают или заранее осуществляют этапы доступа, авторизации и учета частично или полностью. Этот выбор также может динамически изменяться на основании типа или приоритета вызова, например для экстренного вызова все указанные этапы могут пропускаться, а для неэкстренного вызова, имеющего высокий приоритет, могут выполняться некоторые из указанных этапов для достижения определенных целей (например, для передачи данных с высоким приоритетом между сотрудниками правоохранительных органов может использоваться аутентификация для предотвращения перехвата или подобных атак).

После того как пункт PSAP локализован и принял запрос INVITE, из пункта PSAP может дополнительно передаваться отклик 403 SIP RINGING.

После того как пункт PSAP принял экстренный вызов eCall, он передает отклик 404 SIP 200 ОК. После приема отклика 404 200 ОК система IVS отправляет сообщение 406 подтверждения SIP АСК для подтверждения отклика ОК. Отклик 404 200 ОК содержит выбор обеих опций, которые выбрал пункт PSAP. Как показано, пункт PSAP выбрал сигнализацию протокола RTCP. В этот момент вызов установлен, и может быть осуществлена передача перемеженных голосовых и других данных реального времени.

Передача данных блока MSD

Как показано на фиг.5, после завершения установления сеанса (например, при передаче по протоколу SIP, показанной на фиг.4, успешно определен сеанс, включающий компоненты голоса и данных) осуществляют примерную операцию 500 обмена сообщениями между системой IVS и пунктом PSAP. Обмен голосовыми данными начинается на шаге 502а, 502b путем передачи пакетов протокола RTP, содержащих кодированные голосовые кадры. Затем в запланированный момент времени (T₁) первый пакет прокола RTCP передают на шаге 504. Этот пакет в одном варианте осуществления содержит пакет 350 АРР протокола RTCP, как описано выше со ссылкой на фиг.3A-3D.

В одном примерном варианте осуществления изобретения на шаге 504 задают следующие элементы информации в первом пакете АРР (2) протокола RTCP: (i) Name 362=eCal, (ii) Subtype 356=MSD-Data и (iii) PacketNumber (первые восемь (8) битов поля 364 индивидуального для приложения)=0 (ноль). Остальная часть поля 364 индивидуального для приложения содержит оставшийся блок MSD.

После того как первый пакет АРР (2) протокола RTCP сформирован, через последующие интервалы формируются другие пакеты протокола RTCP. Эти интервалы в одном варианте осуществления имеют периодический характер, однако это не является обязательным требованием. Использование постоянного интервала времени (T₂) упростит обработку пакетов протокола RTCP между системой IVS и пунктом PSAP. Между периодической передачей пакетов протокола RTCP могут продолжать передаваться голосовые пакеты протокола RTP, как показано на шагах 502c, 502d, 502e и т.п.

В приведенном варианте осуществления сформированные пакеты протокола RTCP содержат пакеты АРР для данных экстренного вызова eCall до тех пор, пока не принято подтверждение успешного приема из пункта PSAP. Как показано на фиг.5, пункт PSAP принимает первый пакет АРР (2) протокола RTCP на шаге 504, пункт PSAP формирует пакет АРР (3) протокола RTCP на шаге 506 в ответ на получение первого пакета АРР (2) протокола RTCP для подтверждения успешного приема. Пакет АРР (3) протокола RTCP (АСК, подтверждение) передается со следующими предлагаемыми заданными элементами информации: Name 362=«eCal»; Subtype 356=АСК, PacketNumber (первые восемь (8) битов поля 364 индивидуального для приложения)=0 (ноль) для подтверждения пакета 0, остальная часть поля индивидуального для приложения пуста.

В примере на фиг.5 подтверждение АСК (3), передаваемое на шаге 506, утеряно из-за отказа или помех в эфире (см. знак «X» на шаге 506). Система IVS ожидает последующего подтверждения, поэтому система IVS определяет, что подтверждение не принято корректно и/или вовремя. Поэтому затем в запланированный момент времени (T₂) на шаге 508 отправляется второй пакет АРР (4) протокола RTCP, содержащий следующие элементы информации: Name 362=«eCal»; (2) Subtype 356=MSD-Data, PacketNumber (первые восемь (8) битов поля 364 индивидуального для приложения)=«1» (один), остальная часть поля индивидуального для приложения содержит блок MSD. Этот пакет принимается и подтверждается посредством пункта PSAP на шаге 510 с помощью пакета АРР (5) протокола RTCP, содержащего: Name 362=«eCal»; Subtype 356=АСК, PacketNumber (первые восемь (8) битов поля 364 индивидуального для приложения)=1 (один) для подтверждения пакета 1, остальная часть поля индивидуального для приложения пуста. После успешного приема подтверждения системой IVS передачу данных экстренного вызова eCall прекращают, и на шаге 502е продолжается обмен голосовыми пакетами.

Процедура запроса обновления

На фиг.5 также показана дополнительная процедура запроса обновления. Более конкретно, на шаге 512, пункт PSAP запрашивает обновление блока MSD. В некоторых случаях пункт PSAP может потребовать обновление из-за того, что информация в блоке MSD может динамически изменяться. Соответственно, на шаге 512 отправляется пакет АРР (6) протокола RTCP, содержащий следующие элементы информации: (i) Name 362=«eCal», (ii) Subtype 356=UPDT и (iii) PacketNumber (первые восемь (8) битов поля 364 индивидуального для приложения). Остальная часть поля индивидуального для приложения пуста.

Система IVS отвечает на запрос на шаге 514 посредством обновленного пакета АРР (7) протокола RTCP, который включает следующую информацию: Name 362=«eCal», Subtype 356=MSD-Data, PacketNumber=2 (два). Остальная часть поля индивидуального для приложения содержит обновленный блок MSD.

В другом варианте осуществления пакет АРР (6) протокола RTCP запроса обновления, отправленный на шаге 512, может инициировать запрос проверки доступности блока FSD и, если он доступен, пакет АРР (7) протокола RTCP, отправленный на шаге 514, может также указывать на данные FSD-Data в поле Subtype (и содержать блок FSD в поле индивидуальном для приложения). Также подразумевается, что система IVS продолжает передавать пакеты блока MSD, подобные передаваемым на шагах 504 и 508, до тех пор, пока информация в самом последнем вычисленном блоке MSD отличается от последнего отправленного блока MSD, хотя может применяться другая логика или критерий (например, отсутствие изменений в последовательных пакетах или интервалах и т.п.).

Сегментированные пакеты

В другой реализации данные экстренного вызова eCall могут сегментироваться на более чем один пакет протокола RTCP. Например, элементы информации пакета (2) протокола RTCP, отправляемые на шаге 504, могут быть изменены так, чтобы первый пакет был образован следующей информацией: Name 362=«eCal», Subtype 356=MSD-Data-Segmented, PacketNumber=0 (ноль), поле SegmentNumber=0 (ноль), а остальная часть поля индивидуального для приложения содержит первые тридцать восемь (38) байтов блока MSD.

После этого формируется второй сегментированный пакет, содержащий: Name 362=«eCal», Subtype 356=MSD-Data-Segmented, PacketNumber=0 (ноль), поле SegmentNumber=1 (один), а остальная часть поля индивидуального для приложения содержит остальную часть блока MSD. На шаге 506 сообщение подтверждения подтверждает полный пакет 0 (то есть оба сегмента) только после того, как оба сегмента приняты пунктом PSAP. Подтверждение должно указывать подтверждаемые пакеты и/или сегменты. Соответственно, в одном варианте подтверждение может содержать и номер пакета, и номер сегмента. Если система IVS не получила никакого подтверждения, она формирует новый блок MSD (содержащий оба сегмента).

Пример сетевого устройства

На фиг.6а показан пример сетевого устройства 600 (например, подсистемы пункта обеспечения общественной безопасности (PSAP)), используемого при реализации способов в соответствии с настоящим изобретением.

Приведенный вариант осуществления устройства 600 включает один или большее количество серверных модулей, соединенных с центральной базой 604 данных и содержащих вычислительное устройство 606, оперативное запоминающее устройство (память) 608, источник 610 питания и внешний сетевой интерфейс 612. Используемый в настоящем документе термин «сетевой интерфейс» или «интерфейс», как правило, относится к любому сигнальному интерфейсу, интерфейсу передачи данных или программному интерфейсу с компонентом, сетью или способом, включая в том числе шину FireWire (например, FW400, FW800 и т.п.), шину USB (например, USB2), сеть Ethernet (например, 10/100, 10/100/1000 (Gigabit Ethernet), 10-Gig-E, etc.), MoCA, интерфейс Serial ATA (например, SATA, e-SATA, SATAN), Ultra-ATA/DMA, Coaxsys (например, TVnet™), радиочастотный тюнер (например, внутриполосный или внеполосный, проводной модем и т.п.), сети WiFi (802.11a, b, g, n), WiMAX (802.16), PAN (802.15), IrDA и другие разновидности сетей.

Серверные модули, показанные на фиг.6а, соединены внешней шиной 614 в одной из конфигураций.

Как показано, центральная база 604 данных может быть разделена между множеством отдельных машин, но функционировать как одна логически единая база данных. Центральная база данных содержит перечень уникальных идентификаторов и соответствующие текущие и ретроспективные данные (например, минимальный блок данных или блок MSD), хранящиеся в машиночитаемом носителе информации (например, жестком диске /RAID-массивах, флеш-памяти и т.п.).

Вычислительная подсистема 606 может содержать микропроцессор (CPU), цифровой сигнальный процессор, RISC-ядро, программируемую логическую матрицу типа FPGA, и/или множество компонентов обработки. Используемые в настоящем документе термины «микропроцессор» или «цифровое вычислительное устройство» подразумевают в целом все типы цифровых вычислительных устройств, включая в том числе цифровые сигнальные процессоры (DSP), компьютеры с архитектурой сокращенного набора команд (RISC), универсальные процессоры (CISC), микропроцессоры, логические матрицы (например, FPGA), программируемые логические устройства, реконфигурируемые вычислительные структуры (RCF), матричные процессоры, безопасные микропроцессоры и специализированные интегральные схемы (ASIC). Такие цифровые вычислительные устройства могут содержаться в одном кристалле интегральной схемы или могут быть распределены по множеству компонентов.

Вычислительная подсистема также может содержать внутреннюю кэшпамять 606А. Вычислительная подсистема соединена с логической центральной базой 604 данных, локальной подсистемой 608 памяти и внешним сетевым интерфейсом 612, например, для осуществления связи с локальными или удаленными объектами, например, посредством сетевых протоколов или протоколов передачи данных.

Подсистема 608 запоминающего устройства может включать один или большее количество компонентов памяти, которые могут содержать, например, энергонезависимые (например, ROM, FLASH и т.п.) и энергозависимые (например, RAM, DDR-RAM, QDR-RAM и т.п.) компоненты. Понятно, что термин память (запоминающее устройство) может включать любой тип интегральной схемы или другого запоминающего устройства, выполненного с возможностью хранения цифровых данных, включая в том числе постоянное запоминающее устройство (ROM), PROM, EEPROM, DRAM, SDRAM, DDR/2 SDRAM, EDO/FPMS, RLDRAM, SRAM, флеш-память (например, NAND/NOR) и PSRAM. Подсистема памяти также может содержать устройство 608А с прямым доступом к памяти (DMA), хорошо известное в области вычислительной техники, для обеспечения более быстрого доступа к данным.

Показанная подсистема 610 управления электропитанием (PMS) обеспечивает питание для серверного модуля и может содержать интегральную схему и/или множество дискретных электрических компонентов. Используемый в настоящем документе термин «интегральная схема» (1С) относится ко всем типам устройств, имеющих любую степень интеграции (включая в том числе ультрабольшую степень интеграции, сверхбольшую степень интеграции и высокую степень интеграции) независимо от технологии и материалов подложки (включая в том числе Si, SiGe, CMOS и GaAs). Интегральные схемы могут включать, например, устройства памяти (например, DRAM, SRAM, DDRAM, EEPROM/Flash и ROM), цифровые вычислительные устройства, однокристальные устройства, матрицы FPGA, специализированные интегральные схемы ASIC, АЦП, ЦАП, приемопередатчики, контроллеры запоминающих устройств, а также любые их комбинации.

С целью обеспечения бесперебойной работы устройства при необходимости также может использоваться система восстановления или резервирования (включая источник бесперебойного питания или ИБП, не показанный).

Описанное устройство также может быть выполнено с возможностью прямого или косвенного обмена данными с другим устройством (например, другими устройствами экстренной службы оператора сети, сетевыми мостами, шлюзами и т.п.) так, чтобы информация, относящаяся к экстренным ситуациям, могла легко передаваться по сети в целом и при необходимости даже в сети других типов.

Пример устройства IVS

На фиг.6b показан пример клиентского устройства 650 в соответствии с настоящим изобретением. В приведенном варианте осуществления клиентское устройство включает встроенную в транспортное средство систему (IVS) 650, хотя понятно, что также могут использоваться и другие типы устройств.

Показанное устройство 650 IVS включает в том числе корпус, радиомодуль 652, выполненный по меньшей мере с возможностью передачи и приема данных по сотовой сети, узел 654 микрофона и громкоговорителя, предназначенный для приема голосового сигнала от людей, находящихся в транспортном средстве, и воспроизведения нисходящих или обратных сигналов, один или большее количество датчиков 656, выполненных с возможностью сбора данных, относящихся к состоянию транспортного средства, и вычислительное устройство 658, которое выполнено с возможностью инициирования соединения с сотовой сетью по радиосвязи и передачи голосовых потоков и потоков данных в соответствии с описанными выше способами и протоколами.

Устройство 650 также может включать видеоподсистему или подсистему камеры (не показаны), которая может собирать графические данные и передавать эти данные в вычислительную подсистему 658 для пакетирования и передачи по сети в качестве еще одного потока реального времени, так же как при описанной выше передаче голоса. Кроме того, голосовой поток и видеопоток могут быть временно связаны так, чтобы воспроизводиться согласованно, например посредством стандарта ITU Н.323 или подобного протокола, хорошо известного специалистам в области передачи пакетированных данных, который обеспечивает синхронизацию голоса и видео.

Протокол управления и функция перемежения голосовых данных, описанная выше, могут по необходимости быть реализованы в различной степени в клиенте (или в другом варианте в специальном или многофункциональном устройстве, осуществляющем связь с клиентом). В представленном варианте осуществления такой функционал реализован в программном обеспечении, хотя также предполагаются программно-аппаратные/аппаратные варианты осуществления. Используемый в настоящем документе термин «программное обеспечение» и «компьютерная программа» может включать том числе любую последовательность распознаваемых человеком или машиной шагов, которые выполняют определенную функцию. Такая программа может быть описана практически на любом языке программирования или среде, включая, например, C/C++, Fortran, COBOL, PASCAL, язык ассемблера, языках разметки (например, HTML, SGML, XML, VoXML) и т.п., a также объектно-ориентированных средах, таких как стандартная архитектура брокеров объектных запросов (CORBA), Java™ (включая J2ME, Java Beans и т.п.), Binary Runtime Environment (BREW) и т.п.

В одном варианте осуществления устройства 650 один или большее количество датчиков, выполненных с возможностью сбора данных, относящихся к состоянию транспортного средства, дополнительно включают: (i) приемник 656А системы глобального позиционирования (GPS) (и) один или большее количество акселерометров 656 В, расположенных в шасси и предназначенных для определения столкновения и/или положения шасси, и (iii) датчики 656С для определения заполнения транспортного средства. Приемник GPS определяет относительно точное местоположение транспортного средства в любой данный момент времени, а акселерометры определяют возникновение столкновения или другого события (например, опрокидывания). Данные о заполнении могут использоваться в том числе для определения того, находились ли люди в транспортном средстве в момент события (что позволяет изменить приоритет, если людей не было), а также количества людей (что позволяет, например, отправлять соответствующее количество аварийно-спасательных машин или количество обслуживающего персонала). При необходимости также могут использоваться другие датчики, включая, например, датчик напряжения/тензодатчик для определения деформации различных компонентов транспортного средства, датчики температуры и других параметров окружающей среды для определения условий окружающей среды, в которых находится транспортное средство (например, состояние затопление, пожара и т.п.) и так далее. Эти дополнительные датчики также могут формировать входные или полезные данные для любой исходящей передачи данных.

Подсистема 656А радиопередачи/модема включает цифровой модуль основной полосы частот, аналоговый модуль основной полосы частот, приемный каскад (RX) и передающий каскад (ТХ). Устройство дополнительно включает узел антенны и модуль дуплексной связи, который может включать простой переключатель для коммутации антенн. Переключатель также может включать дискретный компонент. Несмотря на то что в настоящем документе описана конкретная конструкция, в некоторых вариантах осуществления некоторые компоненты могут быть исключены или же могут быть объединены друг с другом (например, приемный радиокаскад и передающий радиокаскад радиочастоты могут быть объединены, как в цифровой радиосвязи третьего поколения), что очевидно специалистам в данной области техники, знакомым с настоящим описанием.

Дополнительно может быть предусмотрена система 654 пользовательского интерфейса, которая может содержать любое количество хорошо известных модулей ввода/вывода, включая в том числе сенсорный экран, ЖК-экран, подсветку и т.п. Понятно, что в системе IVS в целом предусмотрены как минимум средства для формирования голосового потока или другое средство отбора звука из транспортного средства (то есть микрофон) и средство для формирования звукового сообщения (то есть громкоговоритель), предназначенные для обеспечения связи. Следует понимать, что в некоторых случаях подсистема ввода/вывода может использоваться лишь для контроля, например в случае, когда люди в транспортном средстве находятся без сознания и не могут говорить, или для пассивного контроля посредством оператора сети или правоохранительных органов (например, когда транспортное средство оборудовано «бесшумной» сигнализацией, которую пассажир может активировать при угоне автомобиля, похищении и т.п.).

Приведенный вариант осуществления устройства включает подсистему 658 микропроцессора приложений с одним или большим количеством вычислительных устройств, например цифровым сигнальным процессором, микропроцессором/CPU, RISC-ядром, программируемой логической матрицей или множеством вычислительных компонентов, выполненных на одной или нескольких подложках. Вычислительная подсистема также может содержать внутреннюю кэш-память. Вычислительная подсистема соединена с возможностью обмена данными с подсистемой памяти, содержащей память, которая может включать, например, компоненты SRAM, флеш-память и SDRAM. В подсистеме памяти может быть реализовано одно или несколько аппаратных средств с прямым доступом к памяти для ускорения доступа к данным, что хорошо известно в данной области техники.

В одном примерном устройстве система IVS выполнена с возможностью реализации внутренней логики (например, посредством алгоритма, хранящегося в памяти для программ) для инициации экстренного вызова eCall в пункте PSAP. Когда экстренный вызов eCall установлен, пункт IVS передает непрерывный голосовой или другой полезный трафик, перемеженный с данными, считываемыми с указанных выше датчиков, распределенных по транспортному средству. Управление голосовыми (или полезными) данными и данными датчиков осуществляется вычислительной подсистемой.

В одном таком варианте осуществления экстренный вызов eCall инициируется автоматически одним или большим количеством датчиков 656 транспортного средства, определившими столкновение, как, например, в случае, когда акселерометр определил величину ускорения, превышающую заданную пороговую величину (что должно указывать на столкновение). В качестве триггера такого экстренного вызова может служить любое количество других случаев, включая, например, резкое падение температуры окружающей среды (что указывает на погружение в воду), переворачивание транспортного средства (опрокидывание), резкое увеличение температуры под капотом или внутри транспортного средства (возможный пожар двигателя или другой пожар, удушение, например в жаркий день при закрытых окнах), отсутствие движения в транспортном средстве при работающем двигателе (потенциально указывает на то, что водитель находится без сознания из-за медицинских или других условий) и т.п. В другом варианте осуществления экстренный вызов eCall инициируется одним из людей, находящихся в транспортном средстве, например когда транспортному средству необходима буксировка.

Подсистема радиосвязи (радиомодема) инициирует сотовый вызов и устанавливает транспортный уровень для обеспечения передачи сообщений в сети, а также линию радиосвязи в реальном времени. Управление вызовом может осуществляться либо в подсистеме радиосвязи, либо в вычислительной подсистеме. В ответ на инициацию сотового вызова подсистемой радиосвязи объекты сети должны предоставлять предпочтительные и срочные процедуры обработки, как описано выше.

После установки экстренного вызова eCall формируются два или более потоков. По меньшей мере один из этих потоков представляет собой поток голосового вызова, формируемый узлом микрофона пользовательского интерфейса, а остальные потоки формируются каждым из контрольных датчиков для передачи в качестве потока данных, например, время от времени или однократно. Вычислительная подсистема передает указанные потоки с подсистему радиосвязи, как описано выше.

Кроме того, должно быть понятно, что, несмотря на то что описанный примерный вариант осуществления клиентского устройства 650 имеет приемник GPS (или AGPS) для определения местоположения, могут использоваться другие технологии либо вместо приемника GPS, либо совместно с ним. Например, для определения данных о местоположении мобильного устройства в соответствии с изобретением могут использоваться способы и устройство для определения положения в сети с одной частотой (SFN), например сети WiMAX, описанные в одновременно находящейся на рассмотрении заявке США того же заявителя №12/286,646, поданной 30 сентября 2008 года, «Способы и устройство для разложения компонентов радиосигнала», которая в полном объеме включена в настоящий документ посредством ссылки. Более конкретно, в указанной заявке описаны способы и устройство, позволяющие беспроводной сети формировать данные, которые могут использоваться приемником (например, пользовательским устройством UE) для разложения вкладов каждого передатчика, чтобы определить его местоположение без привлечения внешних устройств, например спутников GPS. В одном варианте осуществления беспроводная сеть включает сеть с одной частотой (SFN) и в данные встроен уникальный идентификатор базовой станции, закодированный таким образом, что пользовательское устройство UE может вычислять характеристики канала (например, задержку и направление приема) для триангуляции своего местоположения.

Кроме того, так как иногда система GPS не может работать, когда приемник находится в помещении или закрыт такими конструкциями, как тоннели, переезды и т.п., способы определения местоположения, основанные на сотовой сети, могут использоваться в качестве резервного варианта для GPS (или наоборот), или два способа могут использоваться для подтверждения друг друга с целью обеспечения отправки служб экстренной связи и т.п. по точному местоположению (когда человек, находящийся в транспортном средстве, не может говорить или не знает точного местонахождения).

Существующая технология сотовой связи даже без указанных выше технологий GPS или SFN тем не менее может определять по меньшей мере соту в сети, с которой в настоящее время связана мобильная станция или пользовательское устройство UE. Поэтому эта информация также может использоваться либо для определения местоположения, либо подтверждения еще одного местоположения или местоположения, вычисленного другой системой. Например, если система IVS снабжена датчиком погружения и известно лишь местоположение соты или базовой станции, с которой система IVS осуществляла связь в последний раз, эта информация может использоваться пунктом PSAP/оператором аварийно-спасательной службы для получения грубой оценки местоположения транспортного средства (то есть поиска водоемов в пределах покрытия данной конкретной соты). Такая информация (например, идентификатор местоположения соты и т.п.) может включаться в данные, отправляемые в пункт PSAP, с использованием описанных в настоящем документе способов (например, поля привязки местоположения и т.п.).

Способы ведения бизнеса

Еще в одном аспекте изобретения описаны способы ведения бизнеса, относящегося к описанным выше услугам экстренного вызова в сети с коммутацией пакетов.

В одном варианте осуществления возможности радиосвязи, предоставляемые изобретением, могут использоваться с целью извлечения прибыли оператором сети и/или третьими сторонами. Например, производитель устройства или поставщик услуг могут выделяться среди других благодаря возможности предоставления услуги экстренного вызова в сети с коммутацией пакетов или каналов, либо в обеих сетях. Указанные выше возможности системы IVS также могут использоваться в качестве основы для более высокой цены, благодаря предоставлению клиентам гарантии того, что их транспортное средство сможет осуществить экстренный вызов в случае аварии независимо от положения и/или тарифного плана. Абоненты по всей видимости будут платить больше либо при увеличении первоначальной цены, либо при увеличении абонентской платы за такие возможности.

Еще в одном аспекте вспомогательный характер службы передачи пакетированных данных в реальном времени для экстренных вызовов в системе IVS, предлагаемой в настоящем изобретении, может обеспечивать большую гибкость для абонента. Возможности разделения различных услуг могут включать дополнительные услуги, например аварийное открытие замков дверей, отслеживание с помощью передатчика (например, в случае угона), определение координат/направлений и другие экстренные услуги, предоставляемые абоненту.

Понятно, что, несмотря на то что определенные аспекты изобретения описаны со ссылкой на определенный порядок шагов способа, это описание является всего лишь обобщенным примером реализации способа и в соответствии с требованиями конкретной задачи данный порядок может быть изменен. В определенных условиях некоторые шаги могут оказаться ненужными или опциональными. Кроме того, некоторые шаги или функции могут быть добавлены к описанным вариантам осуществления или может быть изменен порядок осуществления двух или более шагов. Все подобные изменения считаются входящими в описанное предлагаемое изобретение.

Несмотря на то что в приведенном выше подробном описании показаны, раскрыты и выделены новые признаки изобретения в различных вариантах осуществления, понятно, что специалистами в данной области техники без выхода за границы изобретения могут быть выполнены различные исключения, подстановки и изменения в предлагаемом устройстве или способе. Приведенное выше описание соответствует наилучшему варианту осуществления изобретения, как известно на настоящий момент. Данное описание не является ограничительным и должно рассматриваться как иллюстрация общих принципов изобретения. Объем охраны должен определяться по формуле изобретения.

Изобретение относится к беспроводной связи. Технический результат - определение приоритетности экстренных вызовов. Предлагаются способы и устройства для передачи полезных данных, связанных с высокоприоритетным вызовом, например экстренным вызовом. В одном варианте осуществления указанные данные содержат данные (например, блок MSD или блок FSD), внедренные в один или большее количество пакетов протокола передачи в реальном времени, например пакетов протокола управления передачей в реальном времени (RTCP), которые проходят перемежение с потоком голосовых данных или данных пользователя (передаваемых, например, в пакетах протокола RTP) экстренного вызова. Описанные устройства и способы предназначены для надежной передачи части данных из инициирующего терминала (например, системы, установленной в транспортном средстве) в пункт обеспечения общественной безопасности (PSAP) путем использования того же транспортного соединения, что и для данных пользователя. 4 н. и 35 з.п.ф-лы, 12 ил.

1. Способ осуществления экстренного вызова в сети, реализованной с возможностью функционирования по существу в реальном времени с коммутацией пакетов, при этом экстренный вызов включает составной поток, содержащий первый поток и один или большее количество вторых потоков, включающий следующие шаги:
предоставление первого потока по существу непрерывным образом;
предоставление одного или большего количества вторых потоков;
формирование составного потока с использованием по меньшей мере первого потока и одного или большего количества вторых потоков;
установку сеанса, причем данный сеанс дополнительно реализован с возможностью маршрутизации составного потока; и
передачу составного потока посредством указанного сеанса.

2. Способ по п.1, отличающийся тем, что указанный сеанс включает сеанс реального времени, установленный с использованием протокола инициализации сеанса.

3. Способ по п.1, отличающийся тем, что первый поток состоит из множества голосовых пакетов, а один или большее количество вторых потоков состоят из множества пакетов данных.

4. Способ по п.3, отличающийся тем, что предоставление потока по существу непрерывным образом включает по существу непрерывное кодирование голосового сигнала с получением голосовых пакетов.

5. Способ по п.1, отличающийся тем, что предоставление одного или большего количества вторых потоков осуществляют по существу прерывистым или непостоянным образом.

6. Способ по п.5, отличающийся тем, что предоставление потока по существу прерывистым образом включает предоставление данных из по меньшей мере одного источника лишь периодически или с перерывами.

7. Способ по п.6, отличающийся тем, что указанные данные содержат данные о местоположении и по меньшей мере один источник содержит GPS-приемник.

8. Способ по п.1, отличающийся тем, что составной поток, первый поток и один или большее количество вторых потоков пакетированы.

9. Способ по п.8, отличающийся тем, что шаг формирования включает формирование основного потока путем перемежения одного или большего количества пакетов первого потока с одним или большим количеством пакетов второго потока.

10. Способ по п.9, отличающийся тем, что перемежение осуществляют с использованием алгоритма мультиплексирования.

11. Способ по п.1, отличающийся тем, что формирование составного потока с использованием по меньшей мере первого потока и одного или большего количества вторых потоков включает:
размещение по меньшей мере части первого потока во множестве пакетов протокола RTP;
размещение по меньшей мере части одного или большего количества вторых потоков во множестве пакетов протокола RTCP; и
перемежение пакетов протокола RTP с пакетами протокола RTCP.

12. Способ по п.1, отличающийся тем, что сеть включает сотовую сеть, совместимую с системой 3GPP IMS, а сеанс устанавливают с использованием протокола инициализации сеанса (SIP).

13. Способ по п.1, отличающийся тем, что дополнительно включает следующие шаги:
размещение по меньшей мере части первого потока в первой пакетированной структуре протокола;
размещение одного или большего количества вторых потоков во второй пакетированной структуре протокола; и
перемежение первой и второй структур протокола с формированием по меньшей мере части составного потока до указанного шага передачи;
причем первый поток содержит по существу непрерывный поток пользовательских данных; и
по меньшей мере часть одного или большего количества вторых потоков относятся к высокоприоритетному событию.

14. Способ по п.13, отличающийся тем, что данные, относящиеся к высокоприоритетному событию, содержат минимальный блок данных (MSD).

15. Способ по п.13, отличающийся тем, что сеть содержит сотовую сеть третьего поколения (3G), а передача включает предварительную установку по меньшей мере одного сеанса посредством протокола установки сеанса.

16. Способ по п.15, отличающийся тем, что первый пакетированный протокол включает протокол передачи в реальном времени, а второй пакетированный протокол включает протокол управления в реальном времени.

17. Способ по п.13, отличающийся тем, что способ инициируют по существу автоматически посредством передающего устройства, расположенного по существу в наземном транспортном средстве, как следствие указанного события.

18. Способ по п.17, отличающийся тем, что указанное событие выбрано из следующей группы: (i) столкновение; (ii) опрокидывание транспортного средства; и (iii) пожар в транспортном средстве.

19. Способ по п.13, отличающийся тем, что пользовательские данные содержат как видеоданные, так и голосовые данные.

20. Способ по п.13, отличающийся тем, что данные, относящиеся к высокоприоритетному событию, содержат данные о по существу точном местоположении для первого объекта в момент вызова.

21. Способ по п.20, отличающийся тем, что данные о точном местоположении не основаны исключительно на сетевом адресе.

22. Устройство для осуществления экстренного вызова в сети, реализованной с возможностью функционирования с коммутацией пакетов, содержащее
микрофон, выполненный с возможностью непрерывного захвата и цифрового разложения голоса на множество первых пакетов;
один или большее количество датчиков, выполненных с возможностью кодирования одного или большего количества параметров, связанных с устройством или платформой, на которой установлено устройство, с получением одного или большего количества вторых пакетов;
радиопередатчик, выполненный с возможностью передачи множества пакетов по беспроводной сети;
вычислительное устройство, соединенное с возможностью обмена данными с радиопередатчиком; и
машиночитаемое устройство, содержащее носитель информации, выполненный с возможностью хранения компьютерной программы, содержащей множество инструкций, причем указанное множество инструкций при исполнении вычислительным устройством:
формирует множество пакетов для передачи по меньшей мере частично из перемежения множества первых пакетов с одним или большим количеством вторых пакетов;
устанавливает сеанс, обеспечивающий возможность маршрутизации прошедших перемежение множества первых пакетов и одного или большего количества вторых пакетов; и
передает прошедшие перемежение множество пакетов посредством радиопередатчика.

23. Устройство по п.22, отличающееся тем, что формирование множества пакетов для передачи включает формирование множества третьих пакетов, получаемых из прошедших перемежение множества первых пакетов и одного или большего количества вторых пакетов.

24. Устройство по п.22, отличающееся тем, что дополнительно содержит радиоприемник, выполненный с возможностью приема множества пакетов из беспроводной сети; и
громкоговоритель, выполненный с возможностью цифрового синтеза голоса из принятого множества пакетов.

25. Устройство по п.22, отличающееся тем, что дополнительно содержит подсистему громкоговорителя, приемное устройство, выполненное с возможностью приема множества пакетов из беспроводной сети, и устройство разделения, выполненное с возможностью разделения множества пакетов, принятых из сети, на компоненту голоса и компоненту данных, причем устройство разделения также выполнено с возможностью
(i) передачи компоненты голоса в подсистему громкоговорителя;
(ii) определения статуса приема одного или большего количества вторых пакетов по компоненте данных.

26. Устройство по п.22, отличающееся тем, что находится по существу в транспортном средстве, выполненном с возможностью перемещения одного или большего количества находящихся в нем людей.

27. Устройство по п.26, отличающееся тем, что содержит приемник для спутникового определения местоположения, а в число одного или большего количества датчиков входят один или большее количество из следующих датчиков:
(i) акселерометр, выполненный с возможностью определения столкновения;
(ii) акселерометр, выполненный с возможностью определения опрокидывания транспортного средства; и
(iii) датчик, выполненный с возможностью определения заполнения транспортного средства.

28. Устройство по п.22, отличающееся тем, что беспроводная сеть включает сотовую сеть, совместимую с требованиями подсистемы мультимедийной базовой сети IP (IMS) 3GPP, а сеанс устанавливается с использованием протокола инициализации сеанса (SIP).

29. Устройство по п.22, отличающееся тем, что перемежение множества первых пакетов с одним или большим количеством вторых пакетов включает перемежение множества пакетов протокола RTP с одним или большим количеством пакетов протокола RTCP, причем один или большее количество пакетов протокола RTCP содержат минимальный блок данных (MSD).

30. Сетевое устройство, выполненное с возможностью приема экстренного вызова в сети с коммутацией пакетов, содержащее
сетевой интерфейс, выполненный с возможностью приема первого и второго множества пакетов посредством сети протокола IP, соединенной с возможностью обмена данными с указанным устройством;
вычислительное устройство, соединенное с возможностью обмена данными с указанным интерфейсом; и
машиночитаемое устройство, содержащее носитель информации, выполненный с возможностью хранения компьютерной программы, содержащей множество инструкций, причем указанное множество инструкций при исполнении вычислительным устройством:
принимает запрос сеанса связи, обеспечивающего возможность выполнения передачи первого и второго множества пакетов;
устанавливает сеанс;
принимает первое и второе множество пакетов посредством указанного сеанса;
извлекает пользовательские данные по существу реального времени из первого множества пакетов; и
извлекает данные, относящиеся к экстренной ситуации, из второго множества пакетов.

31. Сетевое устройство по п.30, отличающееся тем, что дополнительно содержит аудиомодуль, включающий громкоговоритель и выполненный с возможностью воспроизведения с помощью громкоговорителя аудиоинформации, полученной из извлеченных пользовательских данных по существу реального времени.

32. Сетевое устройство по п.30, отличающееся тем, что сеть с коммутацией пакетов включает подсистему мультимедийной базовой сети IP (IMS) 3GPP, а сеанс устанавливается с использованием по меньшей мере протокола инициализации сеанса (SIP).

33. Сетевое устройство по п.30, отличающееся тем, что первое и второе множество пакетов содержат прошедшие перемежение пакеты протокола RTP и пакеты протокола RTCP соответственно.

34. Сетевое устройство по п.33, отличающееся тем, что по меньшей мере часть пакетов протокола RTCP содержит минимальный блок данных (MSD).

35. Сетевое устройство по п.30, отличающееся тем, что данные, относящиеся к экстренной ситуации, содержат минимальный блок данных (MSD).

36. Сетевое устройство по п.30, отличающееся тем, что содержит пункт обеспечения общественной безопасности (PSAP).

37. Телекоммуникационное устройство, выполненное с возможностью передачи экстренных вызовов с использованием надежного транспорта с пакетированным протоколом в объект, выполненный с возможностью приема пакетированных данных из сети и с возможностью обработки данных, содержащее
радиопередатчик; и
устройство, соединенное с возможностью связи с передатчиком и выполненное с возможностью осуществления передачи пакетированных данных по сети, причем пакетированные данные включают первые пакеты, содержащие пользовательские данные по существу реального времени, и вторые пакеты, перемеженные с первыми пакетами и содержащие данные, относящиеся к экстренной ситуации;
причем первый и второй пакеты имеют формат, соответствующий разным протоколам; и
каждый из указанных разных протоколов поддерживает требования качества обслуживания для обеспечения надежности.

38. Телекоммуникационное устройство по п.37, отличающееся тем, что данные, относящиеся к экстренной ситуации, включают данные о точном местоположении для данного телекоммуникационного устройства в момент вызова.

39. Телекоммуникационное устройство по п.38, отличающееся тем, что данные о точном местоположении не основаны исключительно на сетевом адресе.