RU2504111C2 - Устройство и способ передачи данных экстренного вызова в сетях беспроводной связи - Google Patents

Устройство и способ передачи данных экстренного вызова в сетях беспроводной связи Download PDF

Info

Publication number
RU2504111C2
RU2504111C2 RU2011137008/08A RU2011137008A RU2504111C2 RU 2504111 C2 RU2504111 C2 RU 2504111C2 RU 2011137008/08 A RU2011137008/08 A RU 2011137008/08A RU 2011137008 A RU2011137008 A RU 2011137008A RU 2504111 C2 RU2504111 C2 RU 2504111C2
Authority
RU
Russia
Prior art keywords
packets
data
network
protocol
stream
Prior art date
Application number
RU2011137008/08A
Other languages
English (en)
Other versions
RU2011137008A (ru
Inventor
Мартин ХАНС
Original Assignee
Эппл Инк.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=41800687&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=RU2504111(C2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Эппл Инк. filed Critical Эппл Инк.
Publication of RU2011137008A publication Critical patent/RU2011137008A/ru
Application granted granted Critical
Publication of RU2504111C2 publication Critical patent/RU2504111C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H04M3/5116—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing for emergency applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/50—Connection management for emergency connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
    • H04M2207/18—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place wireless networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2242/00—Special services or facilities
    • H04M2242/04—Special services or facilities for emergency applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

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

Description

По настоящей заявке испрашивается приоритет на основании патентной заявки США №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, содержащих кодированные голосовые кадры. Затем в запланированный момент времени (T1) первый пакет прокола 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. Эти интервалы в одном варианте осуществления имеют периодический характер, однако это не является обязательным требованием. Использование постоянного интервала времени (T2) упростит обработку пакетов протокола 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 определяет, что подтверждение не принято корректно и/или вовремя. Поэтому затем в запланированный момент времени (T2) на шаге 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, предлагаемой в настоящем изобретении, может обеспечивать большую гибкость для абонента. Возможности разделения различных услуг могут включать дополнительные услуги, например аварийное открытие замков дверей, отслеживание с помощью передатчика (например, в случае угона), определение координат/направлений и другие экстренные услуги, предоставляемые абоненту.
Понятно, что, несмотря на то что определенные аспекты изобретения описаны со ссылкой на определенный порядок шагов способа, это описание является всего лишь обобщенным примером реализации способа и в соответствии с требованиями конкретной задачи данный порядок может быть изменен. В определенных условиях некоторые шаги могут оказаться ненужными или опциональными. Кроме того, некоторые шаги или функции могут быть добавлены к описанным вариантам осуществления или может быть изменен порядок осуществления двух или более шагов. Все подобные изменения считаются входящими в описанное предлагаемое изобретение.
Несмотря на то что в приведенном выше подробном описании показаны, раскрыты и выделены новые признаки изобретения в различных вариантах осуществления, понятно, что специалистами в данной области техники без выхода за границы изобретения могут быть выполнены различные исключения, подстановки и изменения в предлагаемом устройстве или способе. Приведенное выше описание соответствует наилучшему варианту осуществления изобретения, как известно на настоящий момент. Данное описание не является ограничительным и должно рассматриваться как иллюстрация общих принципов изобретения. Объем охраны должен определяться по формуле изобретения.

Claims (39)

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, отличающееся тем, что данные о точном местоположении не основаны исключительно на сетевом адресе.
RU2011137008/08A 2009-02-10 2010-02-09 Устройство и способ передачи данных экстренного вызова в сетях беспроводной связи RU2504111C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/368,947 US8265022B2 (en) 2009-02-10 2009-02-10 Apparatus and methods for transmission of emergency call data over wireless networks
US12/368,947 2009-02-10
PCT/US2010/023680 WO2010093646A1 (en) 2009-02-10 2010-02-09 Apparatus and mehtods for transmission of emergency call data over wireless networks

Publications (2)

Publication Number Publication Date
RU2011137008A RU2011137008A (ru) 2013-03-20
RU2504111C2 true RU2504111C2 (ru) 2014-01-10

Family

ID=41800687

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2011137008/08A RU2504111C2 (ru) 2009-02-10 2010-02-09 Устройство и способ передачи данных экстренного вызова в сетях беспроводной связи

Country Status (10)

Country Link
US (4) US8265022B2 (ru)
EP (2) EP2396947A1 (ru)
JP (2) JP6086466B2 (ru)
KR (1) KR101321204B1 (ru)
CN (2) CN102362476B (ru)
AU (2) AU2010213911C1 (ru)
BR (1) BRPI1008545B1 (ru)
CA (1) CA2752582C (ru)
RU (1) RU2504111C2 (ru)
WO (1) WO2010093646A1 (ru)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2544786C2 (ru) * 2013-06-03 2015-03-20 Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) Способ формирования защищенной системы связи, интегрированной с единой сетью электросвязи в условиях внешних деструктивных воздействий
RU2674251C2 (ru) * 2016-04-07 2018-12-06 Фольксваген Акциенгезельшафт Способ передачи информации относительно экстренного случая между мобильным оконечным устройством и пунктом управления экстренной службы
RU2696254C1 (ru) * 2016-01-07 2019-08-01 Телефонактиеболагет Лм Эрикссон (Пабл) Способ передачи сообщений об использовании исключений узлам опорной сети связи
RU201122U1 (ru) * 2020-09-09 2020-11-27 Общество с ограниченной ответственностью «Новые инженерные технологии» Устройство тестирования средства вызова экстреннных служб
RU2766437C1 (ru) * 2021-06-17 2022-03-15 Общество с ограниченной ответственностью "Научно-Технический Центр ПРОТЕЙ" Способ обработки информации о чрезвычайных ситуациях коммутационным оборудованием

Families Citing this family (145)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9848447B2 (en) 2007-06-27 2017-12-19 Ford Global Technologies, Llc Method and system for emergency notification
CA2753973C (en) * 2009-03-03 2013-10-08 Leon Hong In-vehicle system (ivs) control of emergency data communications
US8903351B2 (en) 2009-03-06 2014-12-02 Ford Motor Company Method and system for emergency call handling
CN102576486A (zh) * 2009-08-26 2012-07-11 大陆汽车有限责任公司 用于网络访问装置的紧急应对的系统和方法
US10264029B2 (en) * 2009-10-30 2019-04-16 Time Warner Cable Enterprises Llc Methods and apparatus for packetized content delivery over a content delivery network
US9519728B2 (en) 2009-12-04 2016-12-13 Time Warner Cable Enterprises Llc Apparatus and methods for monitoring and optimizing delivery of content in a network
JP5506362B2 (ja) * 2009-12-15 2014-05-28 キヤノン株式会社 送信装置、送信方法
US8433454B2 (en) * 2010-01-26 2013-04-30 Acumentrics Corporation Method and system for modifying operation according to detected orientation
US8903354B2 (en) 2010-02-15 2014-12-02 Ford Global Technologies, Llc Method and system for emergency call arbitration
EP2375849B1 (en) * 2010-03-29 2015-08-12 Vodafone Holding GmbH Connection management for M2M device in a mobile communication network
CN103081378B (zh) * 2010-07-22 2015-05-27 Lg电子株式会社 发送和接收空闲状态下的非移动性移动站的下行链路数据的方法和设备
GB201016079D0 (en) * 2010-09-24 2010-11-10 St Microelectronics Res & Dev Apparatus & method
JP5682208B2 (ja) 2010-10-04 2015-03-11 ソニー株式会社 通信装置、通信制御方法及び通信システム
EP2453627B1 (en) * 2010-11-12 2018-03-28 Vodafone GmbH Packet switched eCall connection
US8644301B2 (en) * 2010-11-29 2014-02-04 Clearwire Ip Holdings Llc Systems and methods of supporting emergency communications
EP2464149A1 (en) * 2010-12-07 2012-06-13 Research In Motion Limited Emergency communication using images
US20120190324A1 (en) 2011-01-25 2012-07-26 Ford Global Technologies, Llc Automatic Emergency Call Language Provisioning
AU2011359439B2 (en) * 2011-02-17 2016-05-05 Telefonaktiebolaget L M Ericsson (Publ) Devices, methods, and computer programs for detecting potential displacement of a wireless transceiver
US8818325B2 (en) 2011-02-28 2014-08-26 Ford Global Technologies, Llc Method and system for emergency call placement
US8768293B1 (en) * 2011-05-09 2014-07-01 Google Inc. Automatically establishing a telephonic connection between devices
US8849237B2 (en) * 2011-05-11 2014-09-30 Qualcomm Incorporated Priority registration for in-vehicle emergency call service
US8923802B2 (en) * 2011-05-11 2014-12-30 Qualcomm Incorporated Home network roaming management for eCall-only subscribers
US8989697B2 (en) * 2011-05-11 2015-03-24 Qualcomm Incorporated Priority registration for in-vehicle emergency call service
US20120294143A1 (en) * 2011-05-19 2012-11-22 Renesas Mobile Corporation Enabling circuit-switched services during mobility management congestion control
CN102833701B (zh) * 2011-06-15 2017-05-10 中兴通讯股份有限公司 多模终端的短信发送方法及多模终端
RU2598819C9 (ru) 2011-06-17 2016-11-27 Кассидиан Коммьюникейшнз, Инк. Системы, устройства и способы для совместного и распределенного управления экстренными мультимедийными данными
US9179362B2 (en) * 2011-08-25 2015-11-03 Texas Instruments Incorporated Systems and methods for networking coding using Reed-Solomon codes
CN103037191B (zh) * 2011-09-30 2015-08-26 瑞昱半导体股份有限公司 电子装置以及网络存取模块
CN103167487A (zh) * 2011-12-12 2013-06-19 芯讯通无线科技（上海）有限公司 无线通讯模块、数据通讯系统及远程传输加密数据的方法
KR101532117B1 (ko) * 2011-12-13 2015-06-29 에릭슨엘지엔터프라이즈 주식회사 인증 실패 후 응급 호 지원시스템 및 방법
WO2013091228A1 (zh) * 2011-12-23 2013-06-27 华为技术有限公司 一种紧急呼叫场景下传输最小数据集的方法、装置及系统
US9654954B2 (en) * 2012-01-26 2017-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Providing an IMS voice session via a packet switch network and an emergency voice session via a circuit switch network
CN104081820A (zh) * 2012-01-27 2014-10-01 瑞典爱立信有限公司 利用单无线电语音呼叫连续性从电路交换接入网络的优先呼叫切换
CN102595511B (zh) * 2012-02-20 2014-11-19 南京邮电大学 一种面向临近空间平台与卫星集成通信系统的呼叫允许方法
US8594616B2 (en) 2012-03-08 2013-11-26 Ford Global Technologies, Llc Vehicle key fob with emergency assistant service
ES2723174T3 (es) * 2012-04-11 2019-08-22 Gemalto M2M Gmbh Módulo de comunicación, sistema y método para la comunicación inalámbrica
US8938230B2 (en) * 2012-06-18 2015-01-20 General Motors Llc Method of communicating between a vehicle and a telematics subscription service
US20140035949A1 (en) * 2012-08-03 2014-02-06 Tempo Ai, Inc. Method and apparatus for enhancing a calendar view on a device
US10194284B2 (en) * 2012-09-12 2019-01-29 Digit International Inc. Embedded communication in message based transports
US20140082645A1 (en) 2012-09-14 2014-03-20 Peter Stern Apparatus and methods for providing enhanced or interactive features
US9521526B2 (en) * 2012-09-28 2016-12-13 Qualcomm Incorporated Controlling the transfer of telematics data using session related signaling
US20140111357A1 (en) 2012-10-22 2014-04-24 Ford Global Technologies, Llc Method and Apparatus for Alarm Control
US9143978B2 (en) * 2012-12-07 2015-09-22 At&T Intellectual Property I, L.P. Network congestion prevention and/or mitigation
US8848726B1 (en) * 2013-01-24 2014-09-30 The Intellisis Corporation I/O data interface for packet processors
US9049584B2 (en) 2013-01-24 2015-06-02 Ford Global Technologies, Llc Method and system for transmitting data using automated voice when data transmission fails during an emergency call
KR101453979B1 (ko) * 2013-01-28 2014-10-28 주식회사 팬택 음성 명령에 의한 데이터 송수신 방법, 단말 및 시스템
US9688246B2 (en) 2013-02-25 2017-06-27 Ford Global Technologies, Llc Method and apparatus for in-vehicle alarm activation and response handling
WO2014143776A2 (en) 2013-03-15 2014-09-18 Bodhi Technology Ventures Llc Providing remote interactions with host device using a wireless device
CN103227802B (zh) * 2013-05-24 2016-06-01 江苏物联网研究发展中心 基于udp/tcp协议的多元数据传输方法
US20150043446A1 (en) * 2013-08-12 2015-02-12 Qualcomm Incorporated Method and apparatus for coexistence of device to device and lte wan communication using single communication chain
AU2013398384B2 (en) 2013-08-23 2017-04-13 Motorola Solutions, Inc. Method of and system for controlling communications between a personal communications device and a public safety network in an emergency
US9391879B2 (en) 2013-09-25 2016-07-12 Airbus Ds Communications, Inc. Mixed media call routing
US20150109997A1 (en) 2013-10-21 2015-04-23 Alexander Sirotkin Apparatus, system and method of interfacing between a cellular manager and a wlan access device
US10367649B2 (en) * 2013-11-13 2019-07-30 Salesforce.Com, Inc. Smart scheduling and reporting for teams
US20160019360A1 (en) 2013-12-04 2016-01-21 Apple Inc. Wellness aggregator
US8929856B1 (en) 2014-02-07 2015-01-06 Cassidian Communications, Inc. Emergency services routing proxy cluster management
US9337958B2 (en) * 2014-02-21 2016-05-10 Sogics Corporation Limited Data transmissions over a voice channel
US20150264548A1 (en) * 2014-03-11 2015-09-17 Via Telecom, Inc. Ecall system and method
CN106465252B (zh) * 2014-05-16 2019-11-01 株式会社Ntt都科摩 用户装置、通信控制装置以及发信拒绝控制方法
JP6652935B2 (ja) * 2014-05-30 2020-02-26 アップル インコーポレイテッドＡｐｐｌｅ Ｉｎｃ． 健康データアグリゲータ
US10313506B2 (en) 2014-05-30 2019-06-04 Apple Inc. Wellness aggregator
US10528569B2 (en) * 2014-06-26 2020-01-07 Hewlett Packard Enterprise Development Lp Dataset browsing using additive filters
US9838858B2 (en) 2014-07-08 2017-12-05 Rapidsos, Inc. System and method for call management
BR112017000648A2 (pt) * 2014-07-23 2017-11-14 Qualcomm Inc chamadas de emergência iniciadas por veículo
KR101776098B1 (ko) 2014-09-02 2017-09-07 애플 인크. 신체적 활동 및 운동 모니터
US9942739B2 (en) 2014-09-19 2018-04-10 Rapidsos, Inc. Method and system for emergency call management
US9555814B2 (en) * 2014-09-29 2017-01-31 Ford Global Technologies, Llc Unexpected thermal event assist
US9681282B2 (en) * 2014-10-08 2017-06-13 Qualcomm Incorporated Techniques for supporting telematics-enhanced emergency calls from mobile phones
KR102256988B1 (ko) * 2014-10-13 2021-05-26 현대모비스 주식회사 복수개의 모듈들을 구비하는 차량 기기의 업데이트 장치 및 방법
EP3235274A4 (en) * 2014-12-18 2018-07-04 Qualcomm Incorporated Techniques to support emergency calls with over-the-top service provider
EP3998762A1 (en) 2015-02-02 2022-05-18 Apple Inc. Device, method, and graphical user interface for establishing a relationship and connection between two devices
WO2016144385A1 (en) 2015-03-08 2016-09-15 Apple Inc. Sharing user-configurable graphical constructs
TWI649212B (zh) * 2015-04-03 2019-02-01 佳能股份有限公司 液體排放設備、壓印設備及部件製造方法
US10249123B2 (en) 2015-04-09 2019-04-02 Ford Global Technologies, Llc Systems and methods for mobile phone key fob management
US10098021B2 (en) * 2015-05-28 2018-10-09 Apple Inc. VoLTE quality of service enhancement with preconditions
US10275116B2 (en) 2015-06-07 2019-04-30 Apple Inc. Browser with docked tabs
US9838108B2 (en) 2015-06-18 2017-12-05 International Business Machines Corporation IP based real-time communications over a mobile network
US10356091B2 (en) * 2015-07-14 2019-07-16 Ujet, Inc. Communication enhancement methods
CN105208077A (zh) * 2015-08-13 2015-12-30 深圳市中兴物联科技有限公司 车辆信息传输装置和方法
EP4321088A3 (en) 2015-08-20 2024-04-24 Apple Inc. Exercise-based watch face
WO2017045109A1 (en) * 2015-09-14 2017-03-23 Qualcomm Incorporated Position determination of a mobile device in an emergency
CN108476260A (zh) 2015-11-02 2018-08-31 快速求救公司 用于紧急响应的态势感知的方法和系统
US9641563B1 (en) * 2015-11-10 2017-05-02 Ricoh Company, Ltd. Electronic meeting intelligence
US10250431B2 (en) * 2015-11-24 2019-04-02 Carbyne Ltd. System and methods thereof for optimizing communication between a civilian and different dispatchers
WO2018092120A1 (en) * 2016-11-21 2018-05-24 Carbyne Ltd. A system and method for optimizing communication between civilian and different dispatchers
JP6587918B2 (ja) * 2015-11-27 2019-10-09 京セラ株式会社 電子機器、電子機器の制御方法、電子機器の制御装置、制御プログラム及び電子機器システム
EP3391632A4 (en) 2015-12-17 2019-06-12 Rapidsos Inc. DEVICES AND METHOD FOR EFFICIENT EMERGENCY CALL
WO2017112820A1 (en) * 2015-12-22 2017-06-29 Rapidsos, Inc. Systems and methods for robust and persistent emergency communications
US10499229B2 (en) * 2016-01-24 2019-12-03 Qualcomm Incorporated Enhanced fallback to in-band mode for emergency calling
US9986404B2 (en) 2016-02-26 2018-05-29 Rapidsos, Inc. Systems and methods for emergency communications amongst groups of devices based on shared data
CN105846885B (zh) * 2016-03-21 2018-10-12 南京邮电大学 基于流量预测的geo卫星信道分配策略
CN109417692A (zh) 2016-04-26 2019-03-01 快速求救公司 用于紧急通信的系统和方法
AU2017262647A1 (en) 2016-05-09 2018-12-20 Rapidsos, Inc. Systems and methods for emergency communications
CN105957400B (zh) * 2016-06-01 2018-04-10 杨星 一种用于综合感知碰撞预警的车辆信息采集方法
AU2017100667A4 (en) 2016-06-11 2017-07-06 Apple Inc. Activity and workout updates
US10873786B2 (en) 2016-06-12 2020-12-22 Apple Inc. Recording and broadcasting application visual output
US10382475B2 (en) * 2016-07-01 2019-08-13 Genesys Telecommunications Laboratories, Inc. System and method for preventing attacks in communications
US10701206B2 (en) 2016-07-01 2020-06-30 Genesys Telecommunications Laboratories, Inc. System and method for contact center communications
US10861320B2 (en) 2016-08-22 2020-12-08 Rapidsos, Inc. Predictive analytics for emergency detection and response management
DE112017001823B4 (de) 2017-01-25 2024-02-22 Kyocera Corporation Drahtloskommunikationsvorrichtung, verfahren zum steuern einer drahtloskommunikationsvorrichtung und drahtloskommunikationssystem
US9969344B1 (en) 2017-02-17 2018-05-15 Robert Bosch Gmbh Methods and systems for providing accident information
CN107135496B (zh) * 2017-04-17 2020-10-23 青岛海信移动通信技术股份有限公司 移动数据业务自恢复方法、装置和移动终端
US10242554B2 (en) * 2017-04-18 2019-03-26 Carbyne Ltd. System and method thereof for automatically routing a communication request addressed to a public safety answering point (PSAP) to a suitable dispatch unit
WO2018200418A1 (en) 2017-04-24 2018-11-01 Rapidsos, Inc. Modular emergency communication flow management system
US10432355B2 (en) 2017-06-09 2019-10-01 Microsoft Technology Licensing, Llc Enhanced error protection for high priority communication sessions
US10104237B1 (en) 2017-09-21 2018-10-16 T-Mobile Usa, Inc. Mitigating attacks on emergency telephone services
US10701542B2 (en) 2017-12-05 2020-06-30 Rapidsos, Inc. Social media content for emergency management
CN108133584A (zh) * 2017-12-20 2018-06-08 东风汽车集团有限公司 一种基于卫星导航系统的车载紧急呼叫系统
JP6916385B2 (ja) 2017-12-29 2021-08-11 ブラックベリー リミテッドＢｌａｃｋＢｅｒｒｙ Ｌｉｍｉｔｅｄ 緊急電話番号をプロビジョニングするための方法およびシステム
US10820181B2 (en) 2018-02-09 2020-10-27 Rapidsos, Inc. Emergency location analysis system
US10477349B2 (en) 2018-02-13 2019-11-12 Charter Communications Operating, Llc Apparatus and methods for device location determination
US11374992B2 (en) * 2018-04-02 2022-06-28 OVNIO Streaming Services, Inc. Seamless social multimedia
WO2019204228A1 (en) 2018-04-16 2019-10-24 Rapidsos, Inc. Emergency data management and access system
DK180171B1 (en) 2018-05-07 2020-07-14 Apple Inc USER INTERFACES FOR SHARING CONTEXTUALLY RELEVANT MEDIA CONTENT
EP3803774A4 (en) 2018-06-11 2022-03-09 Rapidsos, Inc. SYSTEMS AND USER INTERFACES FOR EMERGENCY DATA INTEGRATION
US11917514B2 (en) 2018-08-14 2024-02-27 Rapidsos, Inc. Systems and methods for intelligently managing multimedia for emergency response
KR102110191B1 (ko) * 2018-08-22 2020-05-13 주식회사텔러스 확장 사고 정보를 전송하는 차량 긴급 구난 장치 및 그 방법
US10977927B2 (en) 2018-10-24 2021-04-13 Rapidsos, Inc. Emergency communication flow management and notification system
US10757602B2 (en) 2018-12-07 2020-08-25 Ford Global Technologies, Llc Connection history-based retry throttling
US11059534B2 (en) * 2018-12-18 2021-07-13 GM Global Technology Operations LLC Nondeterministic assembly system and method
WO2020172612A1 (en) 2019-02-22 2020-08-27 Rapidsos, Inc. Systems & methods for automated emergency response
US10904938B2 (en) * 2019-03-12 2021-01-26 Ford Global Technologies, Llc Circuit-switched domain response to packet-switched domain failure
FR3094605B1 (fr) * 2019-03-28 2021-02-26 Psa Automobiles Sa Transmission par un véhicule terrestre d’une information de retournement dans un message d’urgence
FR3094607B1 (fr) * 2019-03-28 2021-02-26 Psa Automobiles Sa Transmission par un véhicule terrestre d’un indicateur de gravité dans un message d’urgence
FR3094604B1 (fr) * 2019-03-28 2021-02-26 Psa Automobiles Sa Transmission par un véhicule terrestre d’une information de langage dans un message d’urgence
WO2020205033A1 (en) 2019-03-29 2020-10-08 Rapidsos, Inc. Systems and methods for emergency data integration
US11146680B2 (en) 2019-03-29 2021-10-12 Rapidsos, Inc. Systems and methods for emergency data integration
CN110198279B (zh) 2019-04-16 2022-05-20 腾讯科技（深圳）有限公司 一种转发媒体包的方法及转发服务器
CN110300093A (zh) * 2019-05-05 2019-10-01 安康鸿天科技股份有限公司 一种基于数据通信规约触发ims通信的方法
FR3096545B1 (fr) * 2019-05-21 2021-04-23 Psa Automobiles Sa Transmission par un véhicule d’une information sur un état du véhicule dans un message d’urgence
US11228891B2 (en) 2019-07-03 2022-01-18 Rapidsos, Inc. Systems and methods for emergency medical communications
FR3099865A1 (fr) * 2019-08-06 2021-02-12 Psa Automobiles Sa Transmission par un véhicule terrestre d’une information d’immersion du véhicule dans un message d’urgence
US11070670B1 (en) * 2020-01-16 2021-07-20 RapidDeploy, Inc. Platform for emergency event subscriptions
CN112055350B (zh) * 2020-08-11 2022-06-03 博泰车联网科技(上海)股份有限公司 一种紧急求援方法及装置
EP3979222A1 (de) * 2020-09-25 2022-04-06 Manuel Eckert Verfahren und system zur übermittlung positionsbezogener notrufe von bzw. aus fahrzeugen zu einer leitstelle und zur kommunikation zwsichen fahrzeuginsassen und einer leitstelle
CN112738713A (zh) * 2020-12-28 2021-04-30 上海汽车工业(集团)总公司 MSD数据包位置获取方法、eCALL呼叫方法、存储介质和系统
US11330664B1 (en) 2020-12-31 2022-05-10 Rapidsos, Inc. Apparatus and method for obtaining emergency data and providing a map view
JP2022119428A (ja) * 2021-02-04 2022-08-17 本田技研工業株式会社 運転支援装置
DE102021201552A1 (de) 2021-02-18 2022-08-18 Volkswagen Aktiengesellschaft Verfahren und Notrufeinrichtung zur Übertragung von Notfalldaten
WO2022245669A1 (en) 2021-05-15 2022-11-24 Apple Inc. User interfaces for group workouts
JP7476854B2 (ja) * 2021-06-08 2024-05-01 トヨタ自動車株式会社 情報処理装置、プログラム及び情報処理方法
DE102021206508A1 (de) 2021-06-24 2022-12-29 Volkswagen Aktiengesellschaft Verfahren zum Betreiben einer elektronischen Recheneinrichtung, elektronische Recheneinrichtung sowie Kraftfahrzeug
KR20230054064A (ko) * 2021-10-15 2023-04-24 삼성전자주식회사 전자 장치 및 이에 의한 긴급 콜 발신 방법
US20230147896A1 (en) * 2021-11-10 2023-05-11 Cariad Se Onboard vehicle data collaboration for analysis and response
DE102022112235A1 (de) 2022-05-16 2023-11-16 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum übertragen einer information, fahrzeug zum ausführen des verfahrens, backend zum ausführen des verfahrens sowie computerprogramme zum ausführen des verfahrens

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6563910B2 (en) * 2001-02-26 2003-05-13 Royal Thoughts, Llc Emergency response information distribution
RU2002129896A (ru) * 2000-04-10 2004-03-10 Нокиа Корпорейшн (Fi) Телефонные услуги в сетях мобильной связи с интернет-протоколом
RU2248680C2 (ru) * 1998-08-20 2005-03-20 Квэлкомм Инкорпорейтед Система и способ предоставления приоритетного доступа к каналу в системе сотовой телефонной связи
RU2259642C2 (ru) * 2001-04-27 2005-08-27 Нокиа Корпорейшн Способ и система для обработки сеанса экстренной связи с сетевой идентификацией
WO2006103374A2 (fr) * 2005-03-31 2006-10-05 France Telecom Procede de doublage de messages vocaux par des messages textuels dans un reseau de communication par paquets
US20070189246A1 (en) * 2006-02-13 2007-08-16 Lajos Molnar Buffering multimedia mobile devices and methods to operate the same

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6390953A (ja) 1986-10-06 1988-04-21 Nippon Telegr & Teleph Corp <Ntt> マルチメデイア通信装置
JP3231130B2 (ja) 1993-03-24 2001-11-19 日本放送協会 ディジタル情報受信装置
US6049551A (en) 1995-08-16 2000-04-11 Starguide Digital Networks, Inc. Method and apparatus for dynamic allocation of transmission bandwidth resources and for transmission of multiple audio signals with a video signal
US8032808B2 (en) * 1997-08-08 2011-10-04 Mike Vargo System architecture for internet telephone
US6628666B1 (en) 1998-03-30 2003-09-30 Genesys Telecomm Lab Inc Managing bandwidth on demand for internet protocol messaging with capability for transforming telephony calls from one media type to another media type
JP2002291022A (ja) * 2001-03-23 2002-10-04 Toshiba Corp 位置情報センター、携帯端末、位置情報システム、および通話方法
JP2003037623A (ja) * 2001-07-23 2003-02-07 Philips Japan Ltd Ｍｐｅｇネットワーク上におけるダイレクトｒｔｐ伝送方法及びシステム
JP3923835B2 (ja) * 2001-07-24 2007-06-06 株式会社エヌ・ティ・ティ・ドコモ 通信システム、ゲートウェイ、データ中継方法、プログラムおよび記録媒体
JP2003051889A (ja) 2001-08-06 2003-02-21 Matsushita Electric Ind Co Ltd 通信システム、通信方法およびそのプログラム
JP3757857B2 (ja) * 2001-12-12 2006-03-22 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
US7130280B2 (en) * 2002-01-30 2006-10-31 Lucent Technologies Inc. Enhanced call service packet data terminal
JP3796750B2 (ja) * 2002-04-05 2006-07-12 ソニー株式会社 情報送信装置および方法、情報受信装置および方法、記録媒体、並びにプログラム
US7251488B2 (en) * 2002-06-28 2007-07-31 Interdigital Technology Corporation Method and system for coordinating services in integrated WLAN-cellular systems
US7738509B2 (en) * 2002-12-27 2010-06-15 General Motors Llc Method and system for inband emergency notification for voice calls
WO2004077798A2 (en) * 2003-02-26 2004-09-10 V.Enable, Inc. Automatic control of simultaneous multimodality and controlled multimodality on thin wireless devices
FI20030967A (fi) * 2003-06-27 2004-12-28 Nokia Corp Yhteysasetusten valinta
JP2005033612A (ja) 2003-07-08 2005-02-03 Nec Corp 携帯電話機、位置情報送信方法および位置情報受信方法
US8068436B2 (en) * 2003-10-15 2011-11-29 Microsoft Corporation Methods and systems for estimating network available bandwidth using packet pairs and spatial filtering
JP2005141359A (ja) 2003-11-05 2005-06-02 Matsushita Electric Ind Co Ltd 発呼サーバー、通報装置およびプログラム
EP1745615B1 (en) 2004-05-10 2009-12-09 Telefonaktiebolaget LM Ericsson (publ) Method and telecommunication system for initiating an enhanced communication connection
DE602005002819T2 (de) * 2004-12-23 2008-07-17 Lucent Technologies Inc. Verfahren zum Identifizieren von RTP- (Real Time Protocol) und RTCP- (Real Time Control Protocol) Paketen auf Basis einer Paketeigenschaft
JP2006191297A (ja) 2005-01-05 2006-07-20 Sogo Keibi Hosho Co Ltd 監視システム、監視方法
JP2006211097A (ja) 2005-01-26 2006-08-10 Inventec Multimedia & Telecom Corp 公衆交換電話網接続支援のブィーオーアイピーターミナル
US7545916B2 (en) * 2005-02-28 2009-06-09 At&T Intellectual Property I Methods of placing emergency calls using data networks
KR101100198B1 (ko) * 2005-04-11 2011-12-28 엘지전자 주식회사 멀티모드 단말에서의 초기 설정 및 링크 설정 방법
US20060274729A1 (en) 2005-06-03 2006-12-07 Michael Self Apparatus and method for connecting a voice over IP telephone subscriber to the 911 emergency network
DE102005027247B4 (de) * 2005-06-13 2013-11-07 Intel Mobile Communications GmbH Kommunikationseinrichtungen, Verfahren zum Bilden einer Transportprotokoll-Nachricht und Verfahren zum Verarbeiten einer Transportprotokoll-Nachricht
US20070003024A1 (en) * 2005-06-22 2007-01-04 Cml Emergency Services Inc. Network emergency call taking system and method
US8532606B2 (en) * 2005-10-07 2013-09-10 Lg Electronics Inc. Method and system for providing an emergency location service using interoperability between IMS core and access network
US20070136793A1 (en) * 2005-12-08 2007-06-14 International Business Machines Corporation Secure access to a common session in a composite services delivery environment
US8165606B2 (en) * 2005-12-22 2012-04-24 Kyocera Corporation Apparatus, system, and method for location information management in a portable communication device
CN101401386A (zh) * 2006-01-10 2009-04-01 捷讯研究有限公司 在包括ims的网络环境中将来电呼叫路由到合适的域的系统和方法
JP4637757B2 (ja) 2006-01-30 2011-02-23 京セラ株式会社 移動体通信システム、基地局装置及び基地局装置の制御方法
JP2007235753A (ja) * 2006-03-02 2007-09-13 Oki Electric Ind Co Ltd ネットワーク蓄積型システム、その伝送装置および蓄積サーバ
CN100579278C (zh) * 2006-03-03 2010-01-06 华为技术有限公司 紧急呼叫方法、系统及呼叫会话控制功能实体
WO2007113809A2 (en) * 2006-03-30 2007-10-11 Saban Asher S Protecting children and passengers with respect to a vehicle
US8180316B2 (en) 2006-06-12 2012-05-15 West Corporation Automatic routing of in-vehicle emergency calls to automatic crash notification services and to public safety answering points
US20070293263A1 (en) * 2006-06-14 2007-12-20 Hossein Eslambolchi Method and apparatus for providing multi-system cellular communications
JP4704977B2 (ja) * 2006-08-21 2011-06-22 富士通株式会社 緊急通報受付システム
US20080253321A1 (en) * 2006-12-27 2008-10-16 Sr Telecom Inc. Air link bandwidth allocation for voice over ip communications
WO2008083978A1 (en) * 2007-01-10 2008-07-17 Tomtom International B.V. Improved navigation device and method
WO2008132199A1 (en) * 2007-04-26 2008-11-06 Telefonaktiebolaget Lm Ericsson (Publ) Improved codec negotiation
CN101175248B (zh) * 2007-09-28 2011-04-20 中兴通讯股份有限公司 Ip多媒体子系统集中控制业务的紧急呼叫系统及方法
US7991382B1 (en) * 2007-11-08 2011-08-02 Sprint Spectrum L.P. Method for communicating indoor location to an emergency service system
US8351973B2 (en) * 2008-06-13 2013-01-08 Telefonaktiebolaget L M Ericsson (Publ) Short message service (SMS) over service access point identifier 0 (SAPI-0)
US8630259B2 (en) * 2008-08-04 2014-01-14 Qualcomm Incorporated PDCP behaviour at handover and connection re-establishment
US8249019B2 (en) * 2008-08-26 2012-08-21 Futurewei Technologies, Inc. System and method for SR-VCC of IMS emergency sessions
US8737989B2 (en) 2008-08-29 2014-05-27 Apple Inc. Methods and apparatus for machine-to-machine based communication service classes
EP2361468B1 (en) * 2008-09-26 2015-12-23 Telefonaktiebolaget Lm Ericsson (Publ) Congestion control method and devices
US8103287B2 (en) 2008-09-30 2012-01-24 Apple Inc. Methods and apparatus for resolving wireless signal components
CN102457933B (zh) * 2010-10-29 2015-06-24 富士通株式会社 无线网络设备、无线网络系统和路由选择控制方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2248680C2 (ru) * 1998-08-20 2005-03-20 Квэлкомм Инкорпорейтед Система и способ предоставления приоритетного доступа к каналу в системе сотовой телефонной связи
RU2002129896A (ru) * 2000-04-10 2004-03-10 Нокиа Корпорейшн (Fi) Телефонные услуги в сетях мобильной связи с интернет-протоколом
US6563910B2 (en) * 2001-02-26 2003-05-13 Royal Thoughts, Llc Emergency response information distribution
RU2259642C2 (ru) * 2001-04-27 2005-08-27 Нокиа Корпорейшн Способ и система для обработки сеанса экстренной связи с сетевой идентификацией
WO2006103374A2 (fr) * 2005-03-31 2006-10-05 France Telecom Procede de doublage de messages vocaux par des messages textuels dans un reseau de communication par paquets
US20070189246A1 (en) * 2006-02-13 2007-08-16 Lajos Molnar Buffering multimedia mobile devices and methods to operate the same

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2544786C2 (ru) * 2013-06-03 2015-03-20 Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) Способ формирования защищенной системы связи, интегрированной с единой сетью электросвязи в условиях внешних деструктивных воздействий
RU2696254C1 (ru) * 2016-01-07 2019-08-01 Телефонактиеболагет Лм Эрикссон (Пабл) Способ передачи сообщений об использовании исключений узлам опорной сети связи
RU2674251C2 (ru) * 2016-04-07 2018-12-06 Фольксваген Акциенгезельшафт Способ передачи информации относительно экстренного случая между мобильным оконечным устройством и пунктом управления экстренной службы
US10182320B2 (en) 2016-04-07 2019-01-15 Volkswagen Ag Method of transmitting information regarding an emergency between a mobile terminal and an emergency management site
RU201122U1 (ru) * 2020-09-09 2020-11-27 Общество с ограниченной ответственностью «Новые инженерные технологии» Устройство тестирования средства вызова экстреннных служб
RU2766437C1 (ru) * 2021-06-17 2022-03-15 Общество с ограниченной ответственностью "Научно-Технический Центр ПРОТЕЙ" Способ обработки информации о чрезвычайных ситуациях коммутационным оборудованием

Also Published As

Publication number Publication date
EP3076691A1 (en) 2016-10-05
AU2010213911A1 (en) 2011-09-08
JP6086466B2 (ja) 2017-03-01
AU2010213911B2 (en) 2014-04-24
CN104580218B (zh) 2018-07-20
CA2752582A1 (en) 2010-08-19
BRPI1008545A2 (pt) 2016-03-15
US8265022B2 (en) 2012-09-11
KR20110117225A (ko) 2011-10-26
WO2010093646A1 (en) 2010-08-19
US10873844B2 (en) 2020-12-22
CN102362476B (zh) 2014-12-10
CN104580218A (zh) 2015-04-29
BRPI1008545B1 (pt) 2021-03-09
JP2012517771A (ja) 2012-08-02
RU2011137008A (ru) 2013-03-20
US20100202368A1 (en) 2010-08-12
AU2010213911C1 (en) 2016-07-21
JP2015173482A (ja) 2015-10-01
US9220002B2 (en) 2015-12-22
EP2396947A1 (en) 2011-12-21
US9900758B2 (en) 2018-02-20
AU2014204558B2 (en) 2015-12-24
AU2014204558A1 (en) 2014-08-07
KR101321204B1 (ko) 2013-10-23
CN102362476A (zh) 2012-02-22
US20180167797A1 (en) 2018-06-14
EP3076691B1 (en) 2021-03-24
CA2752582C (en) 2016-10-18
JP6086508B2 (ja) 2017-03-01
US20130003611A1 (en) 2013-01-03
US20150029836A1 (en) 2015-01-29

Similar Documents

Publication Publication Date Title
RU2504111C2 (ru) Устройство и способ передачи данных экстренного вызова в сетях беспроводной связи
CA2791350C (en) Answering or releasing emergency calls from a map display for an emergency services platform
CN108476086B (zh) 用于紧急呼叫的增强型后退到带内模式
US20070070962A1 (en) Communication networks for establishing communication sessions between a registered internet protocol (IP) device and one or more subscribing IP devices and methods and computer program products for operating the same
WO2019027538A1 (en) NETWORK ELEMENT FOR ENHANCED SMS EMERGENCY CALL
WO2011140882A1 (zh) 紧急短消息的实现方法和系统
JP5251394B2 (ja) 通信システムおよび呼制御方法
CN102548025B (zh) 一种降低移动VoIP呼叫建立时延方法
WO2019027537A1 (en) USER EQUIPMENT FOR ENHANCED SMS EMERGENCY CALL