基于web客户端的会话的服务质量的利记博彩app

基于web客户端的会话的服务质量的利记博彩app
【专利说明】
[0001] 根据35U.S.C. § 119的优先权要求
[0002] 本专利申请要求于2013年2月5日提交的题为"QUALITY OF SERVICE FOR WEB CLIENT BASED SESSIONS(基于web客户端的会话的服务质量）"的美国临时专利申请 No. 61/760, 789的权益，该临时申请已被转让给本申请受让人并由此通过援引明确地整体 纳入于此。
技术领域
[0003] 本文所描述的各个实施例涉及为使用某些无线网络技术的web客户端启用服务 质量（QoS)能力，这些无线网络技术在其他情况下缺乏在蜂窝网络中支持QoS的能力。
[0004] 背景
[0005]无线通信系统已经过了数代的发展，包括第一代模拟无线电话服务（IG)、第二代 (2G)数字无线电话服务（包括过渡的2. 5G和2. 75G网络）、以及第三代（3G)和第四代（4G) 高速数据/具有因特网能力的无线服务。目前在用的有许多不同类型的无线通信系统，包 括蜂窝以及个人通信服务（PCS)系统。已知蜂窝系统的示例包括蜂窝模拟高级移动电话系 统（AMPS)，以及基于码分多址（CDM)、频分多址（FDM)、时分多址（TDM)、TDM的全球移 动接入系统（GSM)变型的数字蜂窝系统，以及使用TDM和CDM技术两者的更新的混合数 字通信系统。
[0006] 最近，长期演进（LTE)已发展成为用于移动电话和其他数据终端的高速数据无线 通信的无线通信协议。LTE是基于GSM的，且包括来自各种GSM相关协议的贡献，这些相关协 议诸如增强数据率GSM演进（EDGE)、以及通用移动电信系统（UMTS)协议（诸如高速分组接 入（HSPA))。在这些以及其他上下文中，在网络（诸如lxEV-D0、基于UMTS的W-CDMA、LTE 和eHRPD)上操作的会话可在为其保留保证的质量水平（其被称为服务质量（QoS))的信道 (例如，无线电接入承载、流等）上被支持。例如，在特定信道上建立给定水平的QoS可提供 该信道上的最小保证比特率（GBR)、最大延迟、抖动、等待时间、比特差错率（BER)等中的一 者或多者。可为与实时或流送通信会话（诸如IP语音（VoIP)会话、群通信会话（例如，即 按即说会话等）、在线游戏、IPTV等等）相关联的信道保留（或设立）QoS资源以帮助确保 这些会话的无缝端到端分组传输。在某些情形中，用于在用户装备（UE)或其他合适的移动 设备上运行的高优先级应用的调度常开（GBR)服务可能期望改善容量（例如，UE和/或提 供常开服务的网络上的容量）并且进一步改善资源网络使用。例如，实时通信往往需要常 开服务来确保双向IP通信。然而，使用HTML、叠层样式表（CSS)、JavaScript(JS)和其他 web客户端的应用当前缺乏在使用某些普遍技术（诸如用于VoIP的WebRTC解决方案、视频 电话、和流送服务、以及其他技术）的蜂窝网络中利用QoS的能力。相应地，这些以及其他 web客户端可能在无线网络中遭遇差劣的语音、视频和其他媒体质量体验，这是因为在不能 提供QoS时可能产生的较高的损耗、未保证的带宽、高抖动、或其他性能降级。
[0007] 概述
[0008] 以下给出了与本文所公开的一个或多个方面和/或实施例相关的简化概述。如 此，以下概述既不应被视为与所有构想的方面和/或实施例相关的详尽纵览，以下概述也 不应被认为标识与所有构想的方面和/或实施例相关的关键性或决定性要素或描绘与任 何特定方面和/或实施例相关联的范围。相应地，以下概述仅具有在以下给出的详细描述 之前以简化形式呈现与本文所公开的一个或多个方面和/或实施例相关联的某些概念的 目的。
[0009] 根据本公开的一个方面，可在蜂窝网络（例如，LTE、UMTS、lxEV-D0、Wi-Fi等）上 为使用WebRTC、RTCWeb和在其他情况下缺乏利用QoS的能力的其他普遍web技术的web客 户端启用QoS能力，以便于为VoIP、视频、媒体、和使用在其他情况下缺乏在蜂窝网络上利 用QoS的能力的某些web技术的其他数据服务支持高效率和高性能。如此，启用QoS的web 客户端可在无线网络中接收保证的性能，而不论蜂窝网络负载如何，这可转换成非常低的 等待时间，低抖动，低数据损耗，以及使用要求保证的质量水平的应用的web客户端的较佳 用户体验。例如，如将在以下进一步详细描述的，在蜂窝网络中通过WebRTC或其他合适的 web技术支持的web客户端呼叫或会话的QoS激活可以是网络发起的（例如，在LTE、UMTS、 eHRPD或其他类似无线网络上）、显式地设备发起的（例如，在lxEV-DO、LTE、UMTS、eHRPD、 Wi-Fi或其他类似无线网络上）、和/或隐式地设备发起的（例如，在任何合适的无线网络 或其他空中接口上）。
[0010] 根据本公开的一个方面，可为使用WebRTC或其他合适的web技术进行通信的UE 启用QoS能力的示例性架构可包括位于呼叫方浏览器与被呼叫方浏览器之间的媒体路径 中用于支持网络发起的、显式的设备发起的、和/或隐式的设备发起的QoS设立的媒体服务 器。在一个实施例中，呼叫方浏览器和被呼叫方浏览器可初始地使用web套接字、HTTP、或 其他合适的web技术来联系信令服务器以设立信令信道，并且信令服务器随后可在呼叫建 立阶段指派一个或多个WebRTC对等连接。例如，WebRTC对等连接通常可允许两个用户通 过信令服务器协调的信令信道从浏览器到浏览器直接地通信。每个客户端（例如，呼叫方 浏览器和被呼叫方浏览器）随后可作为对等端点建立与媒体服务器的WebRTC连接。
[0011] 根据本公开的一个方面，为了支持网络发起的QoS设立，媒体服务器可确定是否 要为与呼叫方浏览器和/或被呼叫方浏览器建立的媒体路径激活QoS。例如，在一个实施例 中，媒体服务器可执行网络地址转译（NAT)发现以确定与呼叫方浏览器和/或被呼叫方浏 览器同其建立的WebRTC连接相关联的IP地址和端口，其中NAT发现可指示与该WebRTC连 接相关联的服务或应用类型。如此，如果媒体服务器确定该WebRTC连接涉及要求某些QoS 保证的服务或应用类型（例如，语音、视频或流送媒体服务），则媒体服务器可为与呼叫方 浏览器和/或被呼叫方浏览器建立的WebRTC连接激活恰适的QoS水平以在相应媒体路径 上发起QoS。例如，如果媒体服务器与呼叫方浏览器和/或被呼叫方浏览器之间的媒体路径 是在LTE网络上创建的，则媒体服务器可提供与对应于为其激活QoS的呼叫方浏览器和/ 或被呼叫方浏览器中的一者或多者的IP地址和端口相关联的演进分组系统（EPS)承载的 恰适QoS类标识符（QCI)，其中QCI通常可定义相关联EPS承载的一组QoS参数（例如，最 小GBR、最大延迟等）以确保对应的媒体路径在LTE回程基础设施内的所有组件处接收到优 先对待。类似地，如果媒体服务器与呼叫方浏览器和/或被呼叫方浏览器之间的媒体路径 是在eHRPD网络上创建的，则媒体服务器可向eHRPD网络基础设施组件提供对应于为其激 活QoS的呼叫方浏览器和/或被呼叫方浏览器中的一者或多者的恰适QoS参数以及IP地 址和端口以确保对应的媒体路径接收到恰适的优先对待。
[0012] 根据本公开的一个方面，媒体服务器由此通常可作为应用服务器操作以通过核心 蜂窝网络基础设施和/或因特网来支持用于可连接至媒体服务器的浏览器的通信服务，从 而在VoIP会话、PTT会话、群通信会话、社交联网服务或者其他要求高性能或效率的服务期 间为使用核心网下的IP承载资源的应用利用QoS。例如，为了满足与WebRTC或其他基于 web的会话中交换的信令和数据相关联的严格端到端等待时间或其他QoS要求，媒体服务 器可与蜂窝网络基础设施通信以经由Rx接口（例如，策略和计费规则功能与被用来交换应 用级会话信息的应用功能之间的参考点）为WebRTC流激活QoS。在一个实施例中，所激活 的QoS随后可被用来将信令和数据话务的优先级排序排在位于演进型B节点（eNodeB)与 服务网关（S-GW)之间的蜂窝网络基础设施中的路由器处的其他应用话务之前，由此减小 了与经优先级排序的信令和数据话务相关联的回程延迟。相应地，媒体服务器可经由恰适 的蜂窝网络基础设施路由或以其他方式转发呼叫方浏览器与被呼叫方浏览器之间的话务 以利用与呼叫方浏览器和被呼叫方浏览器之间的话务相关联的被激活的QoS。
[0013] 根据本公开的一个方面，可为使用web技术进行通信的UE启用QoS能力的另一示 例性架构可包括如上所述将与信令服务器和媒体服务器相关联的功能性组合的服务器。然 而，本领域技术人员将领会，组合信令和媒体服务器功能性的服务器可包括分开的多个服 务器来处置呼叫方浏览器和被呼叫方浏览器之间的信令和媒体路径。
[0014] 根据本公开的一个方面，为了支持显式的客户端发起的QoS设立，WebRTC组件可 提供应用可用来指定启用QoS的某些能力的应用编程接口（API)。如此，API可一般性地启 用应用来指定可包括带宽和服务类型（例如，对话语音、视频流、流送数据、交互数据、尽力 服务等）等的能力。此外，如果应用将在LTE或EV-DO/eHRPD蜂窝网络上通信，则经由所提 供的API指定的服务类型可进一步包括QCI或QoS简档标识符和接入点名称（APN)，其中 UMTS蜂窝网络可将APN映射到其中使用的恰适IP地址。如此，在一个实施例中，应用可使 用API来指定在经由WebRTC组件发起呼叫时所请求的服务是否要求QoS并且在要求QoS 的情况下进一步指定QoS类型。替换地，在一个实施例中，应用可在与WebRTC栈组件初始 化之际预先确定所要求的Q〇S，WebRTC栈组件可与各种空中接口驱动器集成以与恰适的蜂 窝网络基础设施协商恰适的QoS。再进一步，作为发起呼叫之时的补充或替换，WebRTC栈组 件可在接收到呼叫之时为恰适流激活QoS(例如，基于该呼叫是否与语音、视频、数据流送 等相关联）。
[0015] 根据本公开的一个方面，为了支持隐式的客户端发起的Q0S设立，可采用与以上 关于网络发起的QoS设立相同或基本相似的呼叫建立和媒体交换通信流，不同之处在于媒 体服务器（或组合信令和媒体服务器功能性的服务器）不发起QoS设立规程。替换地，在 客户端应用始发呼叫时，应用可使用WebRTC栈组件来指示正建立对驻留的客户端软件（例 如，高层操作系统组件、内核、高级移动订户软件等）的呼叫。在一个实施例中，作为信令交 换的一部分，客户端应用可确定被分配支持呼叫的服务器可用来随后监视对应IP流并检 测其上的任何数据活动的IP地址、端口、协议或其他合适的连接数据。相应地，响应于在具 有某些QoS要求的对应IP流上检测到数据活动，客户端应用可指令驻留的客户端软件激活 对应IP流上的QoS。例如，在一个实施例中，客户端应用可向驻留的客户端软件提供所有恰 适的用于IP流的QoS描述符以及所需的QoS类型，该驻留的客户端软件随后可与蜂窝网络 通信以针对该呼叫激活恰适的QoS。
[0016]与本文所公开的各方面和实施例相关联的其他目标和优点基于所附附图和详细 描述对于本领域技术人员将是显而易见的。
[0017] 附图简述
[0018] 对本发明的各方面及其许多伴随优点的更完整领会将因其在参考结合附图考虑 的以下详细描述时变得更好理解而易于获得，附图仅出于解说目的被给出而不对本发明构 成任何限定，并且其中：
[0019]图1解说了根据本公开的一个方面的无线通信系统的高级系统架构。
[0020] 图2A解说了根据本公开的一个方面的lxEV-DO网络的无线电接入网（RAN)和核 心网分组交换部分的示例配置。
[0021] 图2B解说了根据本公开的一个方面的3GUMTSW-CDMA系统内的RAN和通用分组 无线电服务（GPRS)核心网分组交换部分的示例配置。
[0022] 图2C解说了根据本公开的一个方面的3GUMTSW-CDM系统内的RAN和GPRS核 心网分组交换部分的另一示例配置。
[0023] 图2D解说了根据本公开的一个方面的基于演进分组系统（EPS)或长期演进（LTE) 网络的RAN和核心网分组交换部分的示例配置。
[0024] 图2E解说了根据本公开的一个方面的连接至EPS或LTE网络的增强型高速率分 组数据（HRPD)RAN以及还有HRH)核心网的分组交换部分的示例配置。
[0025] 图3解说了根据本公开的一个方面的用户装备（UE)的示例。
[0026] 图4解说了根据本公开的一个方面的包括被配置成执行功能性的逻辑的通信设 备。
[0027] 图5解说了根据本公开的一个方面的示例性服务器。
[0028] 图6解说了可支持UE之间的对等（P2P)WebRTC通信的常规架构。
[0029] 图7A-7C解说了根据本公开的一个方面的可为使用WebRTC进行通信的UE启用 QoS的示例性架构。
[0030] 图8A-8B解说了根据本公开的一个方面的为WebRTC客户端启用网络发起的QoS 的示例性通信流。
[0031] 图9A-9B解说了根据本公开的一个方面的为WebRTC客户端启用客户端发起的QoS 的示例性通信流。
[0032] 详细描述
[0033] 在以下描述和相关的附图中公开了各个方面。可以设计替换方面而不会脱离本公 开的范围。另外，本公开中众所周知的元素将不被详细描述或将被省去以免湮没本公开的 相关细节。
[0034] 措辞"示例性"和/或"示例"在本文中用于意指"用作示例、实例或解说"。本文 描述为"示例性"和/或"示例"的任何方面不必被解释为优于或胜过其他方面。类似地， 术语"本公开的各方面"不要求本公开的所有方面都包括所讨论的特征、优点或操作模式。
[0035] 此外，以将由例如计算设备的元件执行的动作序列的方式描述许多方面。将认识 到，本文描述的各种动作能由专用电路（例如，专用集成电路（ASIC))、由正被