СИСТЕМА СВЯЗИ ДЛЯ СОЗДАНИЯ СЕАНСА СВЯЗИ В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ
COMMUNICATION SYSTEM FOR COMMUNICATION SESSION ESTABLISHING IN REAL TIME

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Данное изобретение в целом относится к области организации сетей данных. В частности, изобретение относится к усовершенствованной системе передачи данных.
ОПИСАНИЕ УРОВНЯ ТЕХНИКИ
В настоящее время пользователи Интернет могут осуществлять связь при помощи многообразия разных клиентских приложений, включая приложения обмена сообщениями в режиме реального времени (например, приложения обмена мгновенными сообщениями или «чаты») и двусторонние видеоприложения в режиме реального времени. Например, некоторые клиентские приложения (такие как, например, клиент «Qik», разработанный Qik, Inc.) предоставляют пользователям возможность участия в двустороннем живом видеочате через сети сотовых телефонов 3G и 4G.
Фиг.1a-b иллюстрируют примерную конфигурацию, при которой два мобильных устройства 101-102 участвуют в двустороннем видеочате. Фиг.1a иллюстрирует маршрутизацию данных управления/сигнализации, используемую для создания двустороннего видеосоединения, а фиг.1b иллюстрирует мультимедийные данные (т.е. фактические видеопотоки), передаваемые между двумя мобильными устройствами 101-102. Управление/сигнализация, как правило, переносится при помощи протокола управления передачей (TCP) или протокола пользовательских дейтаграмм (UDP) транспортного уровня сети, а мультимедийные данные, как правило, переносятся при помощи UDP транспортного уровня сети.
Как иллюстрируется, путь, по которому проходят как данные управления/сигнализации, так и мультимедийные данные, включает в себя телефонную подсеть 105, которая может быть стандартной беспроводной сотовой сетью (например, такой как сеть 3G или 4G). Телефонная подсеть 105 соединена со служебной подсетью 115 через маршрутизатор 110. Служебная подсеть является сетью данных, используемой для поддержки мобильного потока данных и маршрутизации потока данных по Интернет 125 через внешний межсетевой экран 120. Телефонная подсеть 105 и служебная подсеть 115 обслуживаются поставщиком (провайдером) беспроводных услуг, таким как T-Mobile™, AT&T™, или Verizon™.
В настоящее время, для того чтобы обеспечить возможность видеобесед в режиме реального времени между мобильными устройствами 101-102, каждое из мобильных устройств должно быть соединено через Интернет 125 с общим набором потоковых серверов 150. Каждое мобильное устройство 101-102 открывает свой собственный сокет дейтаграмм UDP к потоковым серверам 105, и затем потоковые серверы осуществляют маршрутизацию дейтаграмм, содержащих видеоконтент, через соответствующие сокеты дейтаграмм. Например, потоковые серверы 150 осуществляют маршрутизацию видео, принимаемого от мобильного устройства 101, через соединение через сокет дейтаграмм мобильного устройства 102 и наоборот.
Один недостаток данной конфигурации состоит в том, что из-за того, что каждое мобильное устройство 101-102 должно соединиться с потоковым сервером через Интернет 125, может быть внесена значительная задержка. Следовательно, желательно иметь более эффективный способ осуществления маршрутизации видео между мобильными устройствами 101-102.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Лучшее понимание настоящего изобретения может быть получено из рассмотрения нижеследующего подробного описания совместно с нижеследующими чертежами, на которых:
Фиг.1a-b иллюстрируют используемые в настоящее время методики для создания видеосеансов в режиме реального времени между двумя мобильными устройствами.
Фиг.2a-b иллюстрируют методики для улучшения показателей задержки путем размещения серверов-ретрансляторов по периметру сети поставщика услуг в соответствии с одним вариантом осуществления изобретения.
Фиг.3 иллюстрирует сервер-ретранслятор, размещенный на периметре сети поставщика услуги, осуществляющий маршрутизацию видеоконтента между мобильным устройством, соединенным через соединение WiFi, и мобильным устройством, соединенным через сотовое соединение (например, соединение 3G или 4G).
Фиг.4a-b иллюстрируют два разных варианта осуществления, в которых несколько серверов-ретрансляторов используются для установления связи между мобильными устройствами.
ПОДРОБНОЕ ОПИСАНИЕ
В нижеследующем описании, в целях объяснения, многочисленные конкретные подробности изложены с целью обеспечения исчерпывающего понимания описываемых ниже вариантов осуществления изобретения. Тем не менее специалисту в соответствующей области техники будет очевидно, что варианты осуществления изобретения могут быть воплощены на практике без некоторых из этих конкретных подробностей. Например, варианты осуществления изобретения описываются ниже в контексте видеоприложений реального времени, при этом лежащие в основе изобретения принципы не ограничиваются каким-либо типом мультимедийной связи. Дополнительно, несмотря на то, что представленное ниже рассмотрение сконцентрировано на конкретных сетях поставщика услуг, лежащие в основе изобретения принципы применимы к реализациям на любых видах сетей радиосвязи. В заключение, в некоторых случаях, широко известные структуры и устройства показаны в виде структурной схемы, чтобы избежать затенения лежащих в основе принципов вариантов осуществления изобретения.
Один вариант осуществления изобретения повышает качество восприятия для конечного пользователя при выполнении видеосеансов в режиме реального времени посредством размещения ряда внутрисетевых ретрансляторов по периметру сетей поставщика услуг. В частности, как иллюстрируется на Фиг.2a-b, в данном варианте осуществления сервер-ретранслятор выполнен с возможностью осуществления связи через служебную подсеть 115, внутри межсетевого экрана 120, соединяющего служебную подсеть 115 с Интернет 125.
Фиг.2a иллюстрирует маршрутизацию данных управления/сигнализации, используемую для создания ретрансляционного соединения. Клиентские приложения, установленные на мобильных устройствах 101-102, обнаруживают эти внутрисетевые сервер(ы)-ретранслятор(ы) 151 во время данной фазы управления/сигнализации. В одном варианте осуществления каждый внутрисетевой сервер-ретранслятор 151 регистрируется в потоковых серверах 150 при помощи исходящего соединения. В одном варианте осуществления мобильное устройство 101, инициирующее видеосеанс, исходно соединяется с потоковыми серверами 150, которые затем предоставляют сетевую информацию, требуемую для соединения с сервером-ретранслятором (например, IP адрес и порт), обоим клиентам 101-102.
В одном варианте осуществления потоковыми серверами 150 выбирается сервер-ретранслятор 151, который находится относительно «ближе» к одному или обоим мобильным устройствам 101, 102 в сети. Следует отметить, что близость сервера-ретранслятора 151 к мобильным устройствам 101, 102 может определяться на основе сетевой информации, предоставляемой потоковыми серверами 150 (например, TCP/IP адресов мобильных устройств и/или сервера-ретранслятора 151). Местоположение каждого сервера-ретранслятора может регистрироваться в потоковых серверах 150, и потоковые серверы 150 могут использовать данную информацию для определения наилучшего сервера-ретранслятора для обслуживания каждого запроса. Другая информация, такая как текущая загруженность каждого из серверов-ретрансляторов 151, также может быть учтена при принятии решения.
Как только у двух мобильных устройств 101-102 есть сетевая информация, они соединяются с сервером(ами)-ретранслятором(ами) 151, который создает видеосеанс в режиме реального времени между устройствами, как иллюстрируется на Фигуре 2b. В одном варианте осуществления мультимедийные соединения между мобильными устройствами 101-102 и сервером-ретранслятором 151 содержат сокеты дейтаграмм UDP. Сервер(ы)-ретранслятор(ы) 151 принимает видеоконтент, упакованный в дейтаграммы, от мобильного устройства 101 через первый сокет дейтаграмм UDP, и осуществляет маршрутизацию дейтаграмм через второй сокет дейтаграмм UDP к мобильному устройству 102, которое затем извлекает и декодирует видеоконтент из дейтаграмм UDP. Обратно, сервер(ы)-ретранслятор(ы) 151 принимает видео, упакованное в дейтаграммы, от мобильного устройства 102 через второй сокет дейтаграмм UDP, и осуществляет маршрутизацию дейтаграмм через первый сокет дейтаграмм UDP к мобильному устройству 101, которое затем извлекает и декодирует видеоконтент из дейтаграмм UDP.
В одном варианте осуществления маршрутизатор 110 является широко известным устройством для маршрутизации сетевых пакетов до соответствующих получателей, как идентифицируется адресом получателя, хранящимся в каждом заголовке пакета. Например, мобильные устройства 101, 102 могут использовать TCP/IP адрес потоковых серверов 150 при отправке запросов соединения в потоковые серверы 150. Маршрутизатор 110 затем выполнит маршрутизацию запросов соответствующим получателям.
При сравнении вариантов осуществления изобретения, показанных на фиг.2a-b, с реализацией, показанной на фиг.1a-b, преимущества очевидны. Поскольку мультимедийным потокам не требуется проходить через внешний межсетевой экран 120 и через Интернет 125, значительно сокращается задержка, тем самым повышается QoE для конечного пользователя. В качестве примера, а не ограничения, настоящее тестирование показывает сокращение задержки с 252 мс до 110 мс.
Несмотря на то что описанный выше вариант осуществления использует дейтаграммы UDP, следует отметить, что лежащие в основе изобретения принципы не ограничиваются какими-либо конкретными сетевыми проколами связи.
Фиг.3 иллюстрирует то, каким образом сервер(ы)-ретранслятор(ы) 151 также может быть использован для создания двустороннего видеосеанса между мобильным устройством 102, соединенным через соединение WiFi, и мобильным устройством 101, соединенным через сотовое соединение (например, соединение 3G или 4G). В данном варианте осуществления, одно из двух устройств может исходно контактировать с потоковыми серверами 150 для создания видеосеанса. Потоковые серверы 150 затем могут уведомить вызываемую сторону и предоставить сетевую информацию, требуемую обоим мобильным устройствам 101-102 для соединения с сервером-ретранслятором 151. Сервер-ретранслятор 151 затем осуществляет управление видеосеансом в режиме реального времени, как описано выше (например, создавая сокеты дейтаграмм UDP с каждым из соответствующих устройств 101-102). Для осуществления связи с мобильным устройством 102, соединенным через WiFi, сервер-ретранслятор 151 открывает проход 160 UDP через внешний сетевой экран 120. Методики для создания прохода UDP через сетевой экран хорошо известны, и, вследствие этого, не будут здесь подробно описаны.
В конкретной реализации, показанной на фиг.3, мобильное устройство 102 соединено через линию связи WiFi через WLAN 127 предприятия, которая соединена с Интернет 125 через NAT/сетевой экран предприятия. Несмотря на то что это может представлять собой общую конфигурацию, такая конфигурация не требуется для удовлетворения лежащих в основе изобретения принципов.
В одном варианте осуществления несколько серверов-ретрансляторов может быть установлено в приемлемых местоположениях по всему периметру сети поставщика услуг. Дополнительно, несколько серверов-ретрансляторов может использоваться для обеспечения связи между служебными подсетями разных поставщиков услуги.
Фиг.4a иллюстрирует один вариант осуществления, в котором сервер-ретранслятор 151 и сервер-ретранслятор 152 осуществляют связь друг с другом для осуществления маршрутизации дейтаграмм UDP между мобильными устройствами 101 и 102. Как и в предыдущих вариантах осуществления, мобильное устройство 101, инициирующее соединение, может сначала контактировать с потоковыми серверами 150. В ответ, потоковые серверы 150 предоставляют мобильному устройству 101 сетевую информацию, требуемую для соединения с сервером-ретранслятором 151, а мобильному устройству 102 - сетевую информацию, требуемую для соединения с сервером-ретранслятором 152. После соединения серверы-ретрансляторы 151-152 затем создают сокет дейтаграмм UDP друг с другом для осуществления маршрутизации трафика дейтаграмм UDP, содержащего видеоданные.
Фиг.4b иллюстрирует альтернативную реализацию, в которой сервер-ретранслятор 151 принимает трафик дейтаграмм UDP, содержащий видеоданные, от мобильного устройства 101 и осуществляет его маршрутизацию к мобильному устройству 102, а второй сервер-ретранслятор 152 принимает трафик дейтаграмм UDP, содержащий видеоданные, от мобильного устройства 102 и осуществляет его маршрутизацию к мобильному устройству 101. Как и в описанных выше вариантах осуществления, может потребоваться исходное соединение с потоковыми серверами 150 для извлечения сетевой информации, требуемой для соединения с двумя серверами-ретрансляторами 151-152.
Несмотря на то что серверы-ретрансляторы 151-152 сконфигурированы в служебной подсети в представленном выше рассмотрении, в других вариантах осуществления некоторые серверы-ретрансляторы могут быть сконфигурированы в телефонной подсети 105-106. В таком случае, если оба мобильные устройства соединены с одной и той же подсетью, то сервер-ретранслятор в этой подсети может быть использован для соединения устройств. Тем не менее, если мобильные устройства находятся в разных телефонных подсетях, то может быть выбран сервер-ретранслятор в служебной подсети 115.
В вышеприведенном описании изобретение было описано со ссылкой на его конкретные примерные варианты осуществления. Очевидно, что в их отношении могут быть выполнены разнообразные модификации, не отступая от более широкой сущности и объема изобретения, определяемого нижеследующей формулой изобретения. Описание и чертежи, соответственно, должны рассматриваться в духе иллюстрации, а не в духе ограничения.
Варианты осуществления изобретения могут включать в себя различные этапы, как изложено выше. Этапы могут быть воплощены в машиноисполняемых инструкциях, которые предписывают процессору специализированного или общего назначения выполнять определенные этапы. В качестве альтернативы, эти этапы могут быть выполнены конкретными компонентами аппаратного обеспечения, которые содержат прошитую логику для выполнения этапов, или посредством любого сочетания программируемых компьютерных компонентов и отдельных компонентов аппаратного обеспечения. Элементы настоящего изобретения также могут быть предоставлены в качестве машиночитаемого носителя информации для хранения машиноисполняемого программного кода. Машиночитаемый носитель информации может включать в себя, но не ограничивается, гибкие дискеты, оптические диски, CD-ROM, и магнитооптические диски, ROM, RAM, EPROM, EEPROM, магнитные или оптические карты, или другой тип среды/машиночитаемого носителя информации, пригодного для хранения электронного программного кода.
На всем протяжении вышеприведенного описания, в целях объяснения, многочисленные конкретные подробности были изложены с целью обеспечения исчерпывающего понимания изобретения. Тем не менее специалисту в соответствующей области техники будет очевидно, что изобретение может быть воплощено на практике без некоторых из этих конкретных подробностей. Например, специалистам в соответствующей области техники будет вполне очевидно то, что описанные здесь функциональные модули и способы могут быть реализованы в качестве программного обеспечения, аппаратного обеспечения или любого их сочетания. Более того, несмотря на то, что некоторые варианты осуществления описываются здесь в контексте клиента приложения P2P, лежащие в основе изобретения принципы могут быть реализованы в виде серверного приложения или любого другого вида клиентского приложения. Соответственно, объем и сущность изобретения должны определяться нижеследующей формулой изобретения.