TW201521482A

TW201521482A - 藉由一代表網頁即時通訊（ＷｅｂＲＴＣ）多媒體用戶端應用程式之基於用戶端之ＷｅｂＲＴＣ代理伺服器選擇性地多工傳入之ＷｅｂＲＴＣ流量及／或解多工傳出之ＷｅｂＲＴＣ流量

Info

Publication number: TW201521482A
Application number: TW103131809A
Authority: TW
Inventors: Giridhar Dhati Mandyam; Vijay Anandrao Suryavanshi; Kirankumar Bhoja Anchan
Original assignee: Qualcomm Inc
Priority date: 2013-09-16
Filing date: 2014-09-15
Publication date: 2015-06-01
Also published as: CN105556923B; US20150078295A1; EP3047624B1; US9467480B2; JP2016537920A; JP6423439B2; EP3047624A1; WO2015038997A1; KR20160055823A; CN105556923A

Abstract

在一實施例中，一第一UE上之一第一WebRTC代理伺服器模組自該第一UE上之一第一WebRTC多媒體用戶端應用程式接收一經多工串流。該第一WebRTC代理伺服器模組解多工成至少第一經解經多工串流及第二經解經多工串流。該第一WebRTC代理伺服器模組經由具有QoS之一第一鏈路集合將該第一經解多工串流發送至一第二UE上之一第二WebRTC代理伺服器模組，且在一第二鏈路集合上將一第二經解多工串流發送至該第二WebRTC代理伺服器模組。該第二WebRTC代理伺服器模組再多工該第一經解多工串流及該第二經解多工串流以獲得該經多工串流之一原始或壓縮版本，且接著將該經再多工串流遞送至該第二UE上之一第二WebRTC多媒體用戶端應用程式。

Description

藉由一代表網頁即時通訊(WebRTC)多媒體用戶端應用程式之基於用戶端之WebRTC代理伺服器選擇性地多工傳入之WebRTC流量及/或解多工傳出之WebRTC流量

依據35 U.S.C.§119之優先權主張

本專利申請案主張2013年9月16日由與本申請案同樣的本發明人申請之名為「藉由一代表網頁即時通訊(WEBRTC)多媒體用戶端應用程式之基於用戶端之WEBRTC代理伺服器選擇性地多工傳入之WEBRTC流量及/或解多工傳出之WEBRTC流量(SELECTIVELY MULTPLEXING INCOMING WEBRTC TRAFFIC AND/OR DE-MULTIPLEXING OUTGOING WEBRTC TRAFFIC BY A CLIENT-BASED WEBRTC PROXY ON BEHALF OF A WEBRTC MULTIMEDIA CLIENT APPLICATION)」之臨時申請案第61/878,510號之優先權，該申請案被指派給其受讓人且全文在此以引用方式明確地併入本文中。

本發明之實施例係關於藉由一代表網頁即時通訊(WebRTC)多媒體用戶端應用程式之基於用戶端之WebRTC代理伺服器選擇性地多工傳入之WebRTC流量及/或解多工傳出之WebRTC流量。

無線通訊系統已經由各種代而發展，包括第一代類比無線電話服務(1G)、第二代(2G)數位無線電話服務(包括臨時2.5G及2.75G網路)及第三代(3G)及第四代(4G)高速資料/具備網際網路能力之無線服務。目前存在許多不同類型的在使用中之無線通訊系統，包括蜂巢式系統及個人通訊服務(PCS)系統。已知之蜂巢式系統之實例包括蜂巢式類比進階行動電話系統(AMPS)，及基於分碼多重存取(CDMA)、分頻多重存取(FDMA)、分時多重存取(TDMA)、TDMA之全球行動存取系統(Global System for Mobile access，GSM)變化之數位蜂巢式系統，以及使用TDMA及CDMA兩種技術之較新的混合數位通訊系統。

最近，長期演進(LTE)已被開發為用於行動電話及其他資料終端之高速資料之無線通訊之無線通訊協定。LTE係基於GSM，且包括來自各種GSM相關協定(諸如，用於GSM演進之增強型資料速率(EDGE))及諸如高速封包存取(HSPA)之通用行動電信系統(UMTS)協定之貢獻。

全球網頁聯盟(W3C)連同網際網路工程工作小組(IETF)在2011年開始開發被稱為網頁即時通訊(WebRTC)之網頁開發者技術。WebRTC為准許瀏覽器(或端點)參加與一或多個其他端點之同級間(P2P)即時通訊，而不管該等端點之相對位置(例如，不管各別端點是否處於同一器件上、處於同一專用網路中，兩者皆處於相異網路位址轉譯(NAT)及/或防火牆之後，等等)之協定。

WebRTC利用即時輸送協定(RTP)以用於即時媒體之傳輸。RTP為可充當用於許多不同媒體類型之輸送協定之靈活性協定。此等媒體類型可廣泛分類為映射至音訊或視訊，或可藉由指明諸如相關聯音訊或視訊編碼解碼器、頻寬要求、音訊或視訊解析度等等之資訊而更特定的。此外，在網格會議模型中，可P2P發送多媒體串流以實現基於用戶端之音訊混合或視訊合成。

因為經由WebRTC而通訊之端點可由限制各別端點之間的端對端連接之數目之一或多個NAT及/或防火牆分離，所以WebRTC允許經由單一IP位址及埠之RTP串流之多工。部分地歸因於此限制，現有WebRTC規範推薦使用彼多工以用於RTP及RTP控制協定(RTCP)通訊。當多個類型之串流係經由一個IP位址及埠而多工時，將經微分化服務品質(QoS)提供至不同類型之媒體變得較有挑戰性。

在一實施例中，一第一UE上之一第一WebRTC代理伺服器模組自該第一UE上之一第一WebRTC多媒體用戶端應用程式接收一經多工串流。該第一WebRTC代理伺服器模組解多工成至少第一經解經多工串流及第二經解經多工串流。該第一WebRTC代理伺服器模組將該第一經解多工串流經由具有QoS之一第一鏈路集合而發送至一第二UE上之一第二WebRTC代理伺服器模組，且在一第二鏈路集合上將一第二經解多工串流發送至該第二WebRTC代理伺服器模組。該第二WebRTC代理伺服器模組將該第一經解多工串流及該第二經解多工串流再多工以獲得該經多工串流之一原始或壓縮版本，且接著將該經再多工串流遞送至該第二UE上之一第二WebRTC多媒體用戶端應用程式。

100‧‧‧無線通訊系統

104‧‧‧空中介面

106‧‧‧空中介面

108‧‧‧空中介面

120‧‧‧無線電存取網路(RAN)

125‧‧‧存取點

140‧‧‧核心網路

140A‧‧‧演進型封包系統(EPS)或長期演進(LTE)網路/核心網路

140B‧‧‧高速率封包資料(HRPD)核心網路

170‧‧‧應用程式伺服器

175‧‧‧網際網路

200A‧‧‧基地台(BS)

200B‧‧‧節點B

200D‧‧‧演進型節點B/eNodeB

200E‧‧‧基地收發器台(BTS)

205A‧‧‧基地台(BS)

205B‧‧‧節點B

205D‧‧‧演進型節點B/eNodeB

205E‧‧‧基地收發器台(BTS)

210A‧‧‧基地台(BS)

210B‧‧‧節點B

210D‧‧‧演進型節點B/eNodeB

210E‧‧‧基地收發器台(BTS)

215A‧‧‧基地台控制器(BSC)

215B‧‧‧無線電網路控制器(RNC)

215D‧‧‧行動性管理實體(MME)

215E‧‧‧增強型基地台控制器(eBSC)及增強型封包控制功能(ePCF)

220A‧‧‧封包控制功能(PCF)

220B‧‧‧伺服通用封包無線電服務(GPRS)支援節點(SGSN)

220D‧‧‧行動性管理實體(MME)

220E‧‧‧高速率封包資料(HRPD)伺服閘道器(HSGW)

225A‧‧‧封包資料伺服節點(PDSN)

225B‧‧‧閘道器通用封包無線電服務(GPRS)支援節點(GGSN)

225D‧‧‧本籍用戶伺服器(HSS)

225E‧‧‧鑑認、授權及帳戶處理(AAA)伺服器

230D‧‧‧伺服閘道器(S-GW)

230E‧‧‧封包資料伺服節點(PDSN)/外籍代理(FA)

235D‧‧‧封包資料網路閘道器(P-GW)

240D‧‧‧策略及計費規則功能(PCRF)

300A‧‧‧使用者設備(UE)

300B‧‧‧使用者設備(UE)

302‧‧‧平台

305A‧‧‧天線

305B‧‧‧觸控式螢幕顯示器

306‧‧‧收發器

308‧‧‧特殊應用積體電路(ASIC)

310‧‧‧應用程式設計介面(API)

310A‧‧‧顯示器

310B‧‧‧周邊按鈕

312‧‧‧記憶體

314‧‧‧區域資料庫

315A‧‧‧按鈕

315B‧‧‧周邊按鈕

320A‧‧‧小鍵盤

320B‧‧‧周邊按鈕

325B‧‧‧周邊按鈕

330B‧‧‧前面板按鈕

400‧‧‧通訊器件

405‧‧‧經組態以接收及/或傳輸資訊之邏輯

410‧‧‧經組態以處理資訊之邏輯

415‧‧‧經組態以儲存資訊之邏輯

420‧‧‧經組態以呈現資訊之邏輯

425‧‧‧經組態以接收區域使用者輸入之邏輯

1100‧‧‧第一使用者設備(UE)

1105‧‧‧第一網頁即時通訊(WebRTC)多媒體用戶端應用程式

1110‧‧‧伺服網路

1115‧‧‧網路位址轉譯(NAT)/防火牆

1120‧‧‧伺服網路

1125‧‧‧第二使用者設備(UE)

1130‧‧‧第二網頁即時通訊(WebRTC)多媒體用戶端應用程式

1200‧‧‧第一使用者設備(UE)

1205‧‧‧第一網頁即時通訊(WebRTC)多媒體用戶端應用程式

1210‧‧‧第一網頁即時通訊(WebRTC)代理伺服器模組

1215‧‧‧伺服網路

1215A‧‧‧伺服網路

1215B‧‧‧伺服網路

1220‧‧‧網路位址轉譯(NAT)/防火牆

1225‧‧‧第二使用者設備(UE)

1230‧‧‧第二網頁即時通訊(WebRTC)多媒體用戶端應用程式

1235‧‧‧第二網頁即時通訊(WebRTC)代理伺服器模組

A9‧‧‧連接

A10‧‧‧介面

A11‧‧‧介面

A11‧‧‧連接

A12‧‧‧介面

A13‧‧‧介面

A16‧‧‧介面

DE-MUX1‧‧‧第一經解多工網頁即時通訊(WebRTC)串流

DE-MUX2‧‧‧第二經解多工網頁即時通訊(WebRTC)串流

Gxa‧‧‧介面

H1‧‧‧介面

H2‧‧‧介面

MUX‧‧‧經多工串流

S2a‧‧‧介面

S101‧‧‧介面

S103‧‧‧介面

STa‧‧‧介面

將易於獲得本發明之實施例之較完整瞭解及其許多伴隨之優點，此係因為會在結合隨附圖式考慮時藉由參考以下【實施方式】來較好地理解本發明之實施例，僅僅出於說明本發明而非限制本發明之方式來呈現該等隨附圖式，且在該等隨附圖式中：圖1說明根據本發明之一實施例的無線通訊系統之高階系統架構。

圖2A說明根據本發明之一實施例的用於1×EV-DO網路之無線電存取網路(RAN)以及核心網路之一封包交換式部分的實例組態。

圖2B說明根據本發明之一實施例的3G UMTS W-CDMA系統內之RAN及通用封包無線電服務(GPRS)核心網路之封包交換式部分的實例組態。

圖2C說明根據本發明之一實施例的3G UMTS W-CDMA系統內之RAN及GPRS核心網路之封包交換式部分的另一實例組態。

圖2D說明根據本發明之一實施例的RAN及基於演進型封包系統(EPS)或長期演進(LTE)網路之核心網路之封包交換式部分的實例組態。

圖2E說明根據本發明之一實施例的連接至EPS或LTE網路且亦連接至高速率封包資料(HRPD)核心網路之封包交換式部分的增強型HRPD RAN之實例組態。

圖3說明根據本發明之實施例的使用者設備(UE)之實例。

圖4說明根據本發明之一實施例的包括經組態以執行功能性之邏輯之通訊器件。

圖5說明根據本發明之一實施例的用戶端應用程式起始方向QoS管理程序的更詳細實施實例。

圖6A說明根據本發明之一實施例的用於給定UE之圖5之處理程序的實例實施，該給定UE在由如圖2A中之1x EV-DO網路(舊版HRPD)或如圖2E中之eHRPD網路伺服的同時聯結半雙工PTT工作階段。

圖6B說明根據本發明之一實施例的用於給定UE之圖5之處理程序的實例實施，該給定UE在由如圖2B或圖2C中之W-CDMA網路伺服的同時聯結半雙工PTT工作階段。

圖6C說明根據本發明之一實施例的用於給定UE之圖5之處理程序的實例實施，該給定UE在由如圖2D中之LTE網路伺服的同時起始半雙工PTT工作階段。

圖7A至圖7B係有關根據本發明之一實施例的類似於圖5但代替 UE用戶端應用程式在應用程式伺服器170處予以實施的選擇性QoS控制程序。

圖7C說明根據本發明之一實施例的用於聯結半雙工PTT工作階段之給定UE(呼叫發起者或呼叫目標)之LTE網路內之圖7B的實例實施。

圖8A說明根據本發明之一實施例的核心網路起始方向QoS管理程序的更詳細實施實例。

圖8B分別說明根據本發明之一實施例的圖8A之更詳細實施，藉以更明確地參考LTE特定及W-CDMA特定之分量及訊息。

圖8C說明根據本發明之一實施例的用於為由某其他UE發起之半雙工PTT工作階段之呼叫目標的給定UE之W-CDMA網路內之圖8B的實例實施。

圖8D說明根據本發明之一實施例的用於為半雙工PTT工作階段之呼叫發起者之給定UE之LTE網路內之圖8B的實例實施。

圖9A說明根據本發明之一實施例的QoS管理程序，藉以在RAN及核心網路處區域地管理GBR資源。

圖9B分別說明根據本發明之一實施例的圖9A之更詳細實施，藉以更明確地參考LTE特定分量及訊息。

圖10A至圖10B說明根據本發明之實施例的分別關於W-CDMA及EV-DO架構之以RAN起始計時器為基礎之方向QoS流管理程序。

圖11說明用於兩個UE之間的網頁即時通訊(WebRTC)工作階段之習知流量流。

圖12A說明根據本發明之一實施例的用於由同一伺服網路伺服之兩個UE之間的WebRTC工作階段之流量流。

圖12B說明根據本發明之一實施例的用於由不同伺服網路伺服之兩個UE之間的WebRTC工作階段之流量流。

圖13說明根據本發明之一實施例的針對WebRTC工作階段設置 QoS鏈路，接著在WebRTC工作階段中在源UE處進行解多工的處理程序。

圖14說明根據本發明之一實施例的基於用於UE發起之WebRTC工作階段之以伺服器為基礎之NW起始QoS程序的圖13之處理程序的LTE特定實施。

圖15說明根據本發明之一實施例的基於UE起始QoS程序之圖13之處理程序的LTE特定實施。

圖16說明根據本發明之一實施例的基於另一NW起始QoS程序之圖13之處理程序之一部分的實例實施。

圖17係有關根據本發明之一實施例的針對WebRTC工作階段設置QoS鏈路，接著在WebRTC工作階段中在目標UE處進行再多工的高階處理程序。

本發明之態樣揭示於以下描述以及有關本發明之特定實施例之相關圖式中。可設計出替代實施例而不脫離本發明之範疇。另外，本發明之眾所熟知之元件將不加以詳細描述或將被省略以便不混淆本發明之相關細節。

詞「例示性」及/或「實例」在本文中用以意謂「充當一實例、個例，或說明」。本文中被描述為「例示性」及/或「實例」之任何實施例未必被解釋為比其他實施例較佳或有利。同樣地，術語「本發明之實施例」並不要求本發明之所有實施例皆包括所論述之特徵、優點或操作模式。

另外，許多實施例係關於待由(例如)計算器件之元件執行之動作序列來描述。將認識到，本文所描述之各種動作可藉由特定電路(例如，特殊應用積體電路(ASIC))、藉由一或多個處理器執行之程式指令或藉由兩者之組合來執行。另外，可認為本文所描述之此等動作序列完全體現於任何形式之電腦可讀儲存媒體內，該電腦可讀儲存媒體儲存有在執行時將使一相關聯之處理器執行本文所描述之功能性的電腦指令之對應集合。因此，本發明之各種態樣可以許多不同形式體現，其皆已被預期在所主張主題之範疇內。另外，對於本文所描述之實施例中每一者，任何此等實施例之對應形式可在本文中被描述為(例如)「經組態以執行所描述動作之邏輯」。

在本文中被稱作使用者設備(UE)之用戶端器件可為行動的或靜止的，且可與無線電存取網路(RAN)通訊。如本文所使用，術語「UE」可被可互換地稱作「存取終端機」或「AT」、「無線器件」、「用戶器件」、「用戶終端機」、「用戶台」、「使用者終端機」或UT、「行動終端機」、「行動台」，及其變化。通常，UE可經由RAN與核心網路通訊，且經由核心網路UE可與諸如網際網路之外部網路連接。當然，連接至核心網路及/或網際網路之其他機構亦有可能用於UE，諸如經由有線存取網路、WiFi網路(例如，基於IEEE 802.11等等)等等。UE可由包括(但不限於)PC卡、緊密快閃器件、外部或內部數據機、無線或有線電話等等之數個類型之器件中任一者體現。UE可將信號發送至RAN所經由的通訊鏈路被稱為上行鏈路頻道(例如，反向流量頻道、反向控制頻道、存取頻道等等)。RAN可將信號發送至UE所經由的通訊鏈路被稱為下行鏈路或前向鏈路頻道(例如，傳呼頻道、控制頻道、廣播頻道、前向流量頻道等等)。如本文所使用，術語流量頻道(TCH)可指上行鏈路/反向或下行鏈路/前向流量頻道。

圖1說明根據本發明之一實施例的無線通訊系統100之高階系統架構。該無線通訊系統100含有UE 1……N。UE 1……N可包括蜂巢式電話、個人數位助理(PDA)、呼叫器、膝上型電腦、桌上型電腦，等等。舉例而言，在圖1中，UE 1……2被說明為蜂巢式呼叫電話，UE 3……5被說明為蜂巢式觸控式螢幕電話或智慧型手機，且UE N被說明為桌上型電腦或PC。

參看圖1，UE 1……N經組態以經由實體通訊介面或層(圖1中被展示為空中介面104、106、108)及/或直接有線連接而與存取網路(例如，RAN 120、存取點125等等)通訊。空中介面104及106可遵守給定蜂巢式通訊協定(例如，CDMA、EVDO、eHRPD、GSM、EDGE、W-CDMA、LTE，等等)，，而空中介面108可遵守無線IP協定(例如，IEEE 802.11)。RAN 120包括經由空中介面(諸如，空中介面104及106)而伺服UE之複數個存取點。RAN 120中之存取點可被稱作存取節點或AN、存取點或AP、基地台或BS、節點B、eNode B，等等。此等存取點可為陸地存取點(或接地站)，或衛星存取點。RAN 120經組態以連接至核心網路140，該核心網路140可執行多種功能，包括橋接由RAN 120伺服之UE與由RAN 120或完全不同RAN伺服之其他UE之間的電路切換(CS)呼叫，且亦可調解封包交換式(PS)資料與諸如網際網路175之外部網路之交換。網際網路175包括數個路由代理及處理代理(為方便起見圖1中未展示)。在圖1中，UE N被展示為直接連接至網際網路175(亦即，諸如經由以WiFi或802.11為基礎之網路之乙太網路連接而與核心網路140分離)。網際網路175藉此可運行以橋接經由核心網路140而在UE N與UE 1……N之間的封包交換式資料通訊。圖1亦展示與RAN 120分離之存取點125。存取點125可獨立於核心網路140而連接至網際網路175(例如，經由諸如FiOS、有線電視數據機等等之光學通訊系統)。空中介面108可經由局域無線連接(諸如，在一實例中之IEEE 802.11)而伺服UE 4或UE 5。UE N被展示為桌上型電腦，其具有至網際網路175之有線連接，諸如至數據機或路由器之直接連接，數據機或路由器可對應於存取點125自身(例如，對於具有有線連接性及無線連接性兩者之WiFi路由器)。

參看圖1，應用程式伺服器170被展示為連接至網際網路175、核心網路140，或其兩者。應用程式伺服器170可被實施為複數個結構上分離伺服器，或替代地其可對應於單一伺服器。如將在下文更詳細地描述，應用程式伺服器170經組態以支援一或多個通訊服務(例如，網際網路語音通訊協定(VoIP)工作階段、即按即說(PTT)工作階段、群組通訊工作階段、社會網路連接服務等等)以用於可經由核心網路140及/或網際網路175而連接至應用程式伺服器170之UE。

下文中關於圖2A至圖2D提供用於RAN 120及核心網路140之協定特定實施之實例，以幫助更詳細地解釋無線通訊系統100。詳言之，RAN 120及核心網路140之組件對應於與支援封包交換式(PS)通訊相關聯之組件，藉以舊版電路交換(CS)組件亦可存在於此等網路中，但任何舊版CS特定組件在圖2A至圖2D中未明確地展示。

圖2A說明根據本發明之一實施例的用於CDMA2000 1x演進資料最佳化(EV-DO)網路中之封包交換式通訊之RAN 120及核心網路140的實例組態。參看圖2A，RAN 120包括經由有線回程介面而耦接至基地台控制器(BSC)215A之複數個基地台(BS)200A、205A及210A。受到單一BSC控制之BS之群組被集體地稱作子網路。如由一般熟習此項技術者將瞭解，RAN 120可包括多個BSC及子網路，且出於方便起見在圖2A中展示單一BSC。BSC 215A在核心網路140內經由A9連接而與封包控制功能(PCF)220A通訊。PCF 220A執行用於BSC 215A之關於封包資料之某些處理功能。PCF 220A在核心網路140內經由A11連接而與封包資料伺服節點(PDSN)225A通訊。PDSN 225A具有多種功能，包括管理點對點(PPP)工作階段、充當本籍代理(HA)及/或外籍代理(FA)，且在功能方面類似於GSM及UMTS網路中之閘道器通用封包無線電服務(GPRS)支援節點(GGSN)(下文更詳細地予以描述)。PDSN 225A將核心網路140連接至諸如網際網路175之外部IP網路。

圖2B說明根據本發明之一實施例的3G UMTS W-CDMA系統內之 RAN 120及經組態為GPRS核心網路之核心網路140之封包交換式部分的實例組態。參看圖2B，RAN 120包括經由有線回程介面而耦接至無線電網路控制器(RNC)215B之複數個節點B 200B、205B及210B。類似於1×EV-DO網路，受到單一RNC控制之節點B之群組被集體地稱作子網路。如由一般熟習此項技術者將瞭解，RAN 120可包括多個RNC及子網路，且出於方便起見在圖2B中展示單一RNC。RNC 215B負責傳信、建立及拆除核心網路140中之伺服GRPS支援節點(SGSN)220B與由RAN 120伺服之UE之間的載送頻道(亦即，資料頻道)。若實現鏈路層加密，則RNC 215B亦加密內容，之後將其轉遞至RAN 120以供經由空中介面進行傳輸。RNC 215B之功能在此項技術中為吾人所熟知，且出於簡潔起見將不對其進行進一步論述。

在圖2B中，核心網路140包括上文所提及之SGSN 220B(且潛在地亦包括數個其他SGSN)及一GGSN 225B。通常，GPRS為用於GSM中以用於路由IP封包之協定。GPRS核心網路(例如，GGSN 225B及一或多個SGSN 220B)為GPRS系統之集中部分，且亦提供對以W-CDMA為基礎之3G存取網路之支援。GPRS核心網路為向GSM及W-CDMA網路中之IP封包服務提供行動性管理、工作階段管理及輸送之GSM核心網路(亦即，核心網路140)之整合式部分。

GPRS穿隧協定(GTP)為GPRS核心網路之界定之IP協定。GTP為允許GSM或W-CDMA網路之最終使用者(例如，UE)到處移動同時繼續連接至網際網路175(好像來自GGSN 225B處之一個位置一樣)之協定。此係藉由將各別UE之資料自UE之當前SGSN 220B傳送至正處置各別UE之回話之GGSN 225B來達成。

GTP之三種形式係由GPRS核心網路使用；即，(i)GTP-U、(ii)GTP-C及(iii)GTP'(GTP質數)。GTP-U係用於將使用者資料傳送於用於每一封包資料協定(PDP)內容脈絡之分離隧道中。GTP-C係用於控制傳信(例如，PDP內容脈絡之設置及刪除、GSN可達成性之驗證、諸如在用戶自一SGSN移動至另一SGSN時之更新或修改，等等)。GTP'係用於計費資料自GSN至計費功能之傳送。

參看圖2B，GGSN 225B充當GPRS基幹網路(未圖示)與網際網路175之間的介面。GGSN 225B自來自SGSN 220B之GPRS封包擷取具有相關聯之封包資料協定(PDP)格式(例如，IP或PPP)之封包資料，且在對應封包資料網路上發送出封包。在另一方向上，傳入之資料封包係藉由連接至UE之GGSN引導至SGSN 220B，SGSN 220B管理且控制由RAN 120伺服之目標UE之無線電存取載送(RAB)。藉此，GGSN 225B將目標UE之當前SGSN位址及其相關聯設定檔儲存於位置暫存器中(例如，PDP內容脈絡內)。GGSN 225B負責IP位址指派且為用於已連接UE之預設路由器。GGSN 225B亦執行鑑認及計費功能。

SGSN 220B在一實例中表示核心網路140內之許多SGSN中之一者。每一SGSN負責資料封包在相關聯地理服務區域內自及至UE之遞送。SGSN 220B之任務包括封包路由及傳送、行動性管理(例如，附著/拆離及位置管理)、邏輯鏈路管理，以及鑑認及計費功能。SGSN 220B之位置暫存器將向SGSN 220B註冊之所有GPRS使用者之位置資訊(例如，當前小區、當前VLR)及使用者設定檔(例如，用於封包資料網路中之IMSI、PDP位址)(例如)儲存於用於每一使用者或UE之一或多個PDP內容脈絡內。因此，SGSN 220B負責(i)自GGSN 225B解穿隧下行鏈路GTP封包；(ii)朝向GGSN 225B之上行鏈路隧道IP封包；(iii)在UE在SGSN服務區域之間移動時進行行動性管理，及(iv)對行動用戶計費。如由一般熟習此項技術者將瞭解，惟(i)至(iv)除外，相比於經組態以用於W-CDMA網路之SGSN，經組態以用於GSM/EDGE網路之SGSN具有稍微不同功能性。

RAN 120(例如或UMTS系統架構中之UTRAN)經由無線電存取網路應用程式部分(RANAP)協定而與SGSN 220B通訊。RANAP經由Iu介面(Iu-ps)運用諸如訊框中繼或IP之傳輸協定進行操作。SGSN 220B經由Gn介面與GGSN 225B通訊，該Gn介面為SGSN 220B與其他SGSN(未圖示)及內部GGSN(未圖示)之間的以IP為基礎之介面且使用上文所界定之GTP協定(例如，GTP-U、GTP-C、GTP'，等等)。在圖2B之實施例中，SGSN 220B與GGSN 225B之間的Gn攜載GTP-C及GTP-U兩者。雖然未在圖2B中展示，但Gn介面亦由網域名稱系統(DNS)使用。GGSN 225B經由具有IP協定之Gi介面直接地或經由無線應用協定(WAP)閘道器而連接至公用資料網路(PDN)(未圖示)，且又連接至網際網路175。

圖2C說明根據本發明之一實施例的3G UMTS W-CDMA系統內之RAN 120及經組態為GPRS核心網路之核心網路140之一封包交換部分的另一實例組態。類似於圖2B，核心網路140包括SGSN 220B及GGSN 225B。然而，在圖2C中，直接隧道為Iu模式中之允許SGSN 220B在PS域內在RAN 120與GGSN 225B之間建立直接使用者平面隧道GTP-U的可選功能。具有直接隧道能力之SGSN(諸如，圖2C中之SGSN 220B)可基於每GGSN及每RNC而組態SGSN 220B是否可使用直接使用者平面連接。圖2C中之SGSN 220B處置控制平面傳信且做出是否建立直接隧道之決策。當釋放經指派用於PDP內容脈絡之RAB(亦即，保存PDP內容脈絡)時，在GGSN 225B與SGSN 220B之間建立GTP-U隧道以便能夠處置下行鏈路封包。

圖2D說明根據本發明之一實施例的RAN 120及基於演進型封包系統(EPS)或LTE網路之核心網路140之封包交換式部分的實例組態。參看圖2D，不同於圖2B至圖2C所展示之RAN 120，EPS/LTE網路中之RAN 120係運用複數個演進型節點B(ENodeB或eNB)200D、205D及210D予以組態，而不用來自圖2B至圖2C之RNC 215B予以組態。此係因為EPS/LTE網路中之ENodeB在RAN 120內無需分離控制器(亦即，RNC 215B)來與核心網路140通訊。換言之，來自圖2B至圖2C之RNC 215B之一些功能性係建置至圖2D中之RAN 120之每一各別eNodeB中。

在圖2D中，核心網路140包括複數個行動性管理實體(MME)215D及220D、一本籍用戶伺服器(HSS)225D、一伺服閘道器(S-GW)230D、一封包資料網路閘道器(P-GW)235D，及一策略及計費規則功能(PCRF)240D。圖2D說明此等組件、RAN 120及網際網路175之間的網路介面，且將其在表1(下文)中界定如下：

現在將描述圖2D之RAN 120與核心網路140中所展示之組件的高階描述。然而，此等組件各自在此項技術中自各種3GPP TS標準為吾人所熟知，且本文中所含有之描述不意欲為藉由此等組件執行之所有功能性之詳盡描述。

參看圖2D，MME 215D及220D經組態以管理用於EPS承載之控制平面傳信。MME功能包括：非存取層(NAS)傳信、NAS傳信安全性、用於技術間及技術內交遞之行動性管理、P-GW及S-GW選擇，及隨著MME改變用於交遞之MME選擇。

參看圖2D，S-GW 230D為終止朝向RAN 120之介面之閘道器。對於與用於以EPS為基礎之系統之核心網路140相關聯的每一UE，在給定時間點處，存在單一S-GW。用於以GTP為基礎及以代理伺服器行動IPv6(PMIP)為基礎兩者之S5/S8之S-GW 230D之功能包括：行動性錨定點、封包路由及轉遞，及基於相關聯EPS載送之QoS類別識別符(QCI)而設定DiffServ碼點(DSCP)。

參看圖2D，P-GW 235D為終止朝向封包資料網路(PDN)(例如，網際網路175)之SGi介面之閘道器。若UE正存取多個PDN，則可存在用於彼UE之一個上P-GW；然而，通常針對彼UE並未同時地支援S5/S8連接性與Gn/Gp連接性之混合。P-GW功能針對以GTP為基礎之S5/S8兩者包括：封包濾波(藉由深封包檢測)、UE IP位址分配、基於相關聯EPS載送之QCI而設定DSCP；考量網路業者間計費；如3GPP TS 23.203中所定義之上行鏈路(UL)及下行鏈路(DL)載送繫結，如3GPP TS 23.203中所定義之UL載送繫結驗證。P-GW 235D使用E-UTRAN、GSM/EDGE無線電存取網路(GERAN)或UTRAN中任一者提供至僅具備GERAN/UTRAN能力之UE及具備E-UTRAN能力之UE之PDN連接性。P-GW 235D經由S5/S8介面僅使用E-UTRAN而提供至具備E-UTRAN能力之UE之PDN連接性。

參看圖2D，PCRF 240D為以EPS為基礎之核心網路140之策略及計費控制元件。在一非漫遊情境中，在HPLMN中存在與UE之網際網路協定連接性存取網路(IP-CAN)工作階段相關聯之單一PCRF。該PCRF終止Rx介面及Gx介面。在具有流量之局域突破之漫遊情境中，可存在與UE之IP-CAN工作階段相關聯之兩個PCRF：本籍PCRF(H-PCRF)為駐留於HPLMN內之PCRF；及受訪PCRF(V-PCRF)為駐留於受訪VPLMN內之PCRF。在3GPP TS 23.203中更詳細地描述PCRF，且因而出於簡潔起見將不對其進行進一步描述。在圖2D中，應用程式伺服器170(例如，其可在3GPP術語中被稱作AF)被展示為經由網際網路175而連接至核心網路140，或替代地經由Rx介面而直接連接至PCRF 240D。通常，應用程式伺服器170(或AF)為向核心網路提供使用IP載送資源(例如，UMTS PS域/GPRS域資源/LTE PS資料服務)之應用程式之元件。應用程式功能之一個實例為IP多媒體子系統(IMS)核心網路子系統之代理伺服器呼叫工作階段控制功能(P-CSCF)。AF使用Rx參考點以將工作階段資訊提供至PCRF 240D。經由蜂巢式網路提供IP資料服務之任何其他應用程式伺服器亦可經由Rx參考點連接至PCRF 240D。

圖2E說明根據本發明之一實施例的經組態為連接至EPS或LTE網路140A且亦連接至增強型高速率封包資料(HRPD)核心網路140B之封包交換式部分的HRPD RAN之RAN 120的實例組態。類似於上文關於圖2D所描述之核心網路，核心網路140A為EPS或LTE核心網路。

在圖2E中，eHRPD RAN包括連接至增強型BSC(eBSC)及增強型PCF(ePCF)215E之複數個基地收發器台(BTS)200E、205E及210E。eBSC/ePCF 215E可經由S101介面連接至EPS核心網路140A內之MME 215D或220D中之一者，且經由A10及/或A11介面連接至HRPD伺服閘道器(HSGW)220E以用於與EPS核心網路140A中之其他實體介接(例如，經由S103介面與S-GW 230D介接、經由S2a介面與P-GW 235D介接、經由Gxa介面與PCRF 240D介接，經由STa介面與3GPP AAA伺服器(圖2D中未明確地展示)介接，等等)。HSGW 220E在3GPP2中被定義為提供HRPD網路與EPS/LTE網路之間的交互工作。如將瞭解，eHRPD RAN及HSGW 220E經組態有不可用於舊版HRPD網路中之至EPC/LTE網路之介面功能性。

返回轉向至eHRPD RAN，除了與EPS/LTE網路140A介接以外，eHRPD RAN亦可與諸如HRPD網路140B之舊版HRPD網路介接。如將瞭解，HRPD網路140B為諸如來自圖2A之EV-DO網路之舊版HRPD網路之實例實施。舉例而言，eBSC/ePCF 215E可經由A12介面與鑑認、授權及帳戶處理(AAA)伺服器225E介接，或經由A10或A11介面與PDSN/FA 230E介接。PDSN/FA 230E又連接至HA 235A，可經由該HA235A而存取網際網路175。在圖2E中，未明確地描述某些介面(例如，A13、A16、H1、H2，等等)，但出於完整性起見展示該等介面且熟悉HRPD或eHRPD的一般熟習此項技術者將理解該等介面。

參看圖2B至圖2E，應瞭解，LTE核心網路(例如，圖2D)及與eHRPD RAN及HSGW介接之HRPD核心網路(例如，圖2E)在某些狀況下可支援網路起始服務品質(QoS)(例如，藉由P-GW、GGSN、SGSN，等等)。

圖3說明根據本發明之實施例的UE之實例。參看圖3，UE 300A被說明為呼叫電話，且UE 300B被說明為觸控式螢幕器件(例如，智慧型手機、平板電腦，等等)。如圖3所展示，如在此項技術中為吾人所知，UE 300A之外部殼體經組態有一天線305A、顯示器310A、至少一按鈕315A(例如，PTT按鈕、電源按鈕、音量控制按鈕，等等)及一小鍵盤320A，與其他組件。又，如在此項技術中為吾人所知，UE 300B之外部殼體經組態有一觸控式螢幕顯示器305B、周邊按鈕310B、315B、320B及325B(例如，電源控制按鈕、音量或振動控制按鈕、飛行模式雙態觸發按鈕，等等)、至少一前面板按鈕330B(例如，首頁按鈕，等等)，與其他組件。雖然未明確地展示為UE 300B之部分，但UE 300B可包括建置至UE 300B之外部殼體中的一或多個外部天線及/或一或多個整合式天線，其包括(但不限於)WiFi天線、蜂巢式天線、衛星定位系統(SPS)天線(例如，全球定位系統(GPS)天線)，等等。

雖然諸如UE 300A及300B之UE之內部組件可以不同硬體組態體現，但用於內部硬體組件之基本高階UE組態在圖3中被展示為平台302。該平台302可接收並執行自RAN 120傳輸之最終可來自核心網路140、網際網路175及/或其他遠端伺服器及網路(例如，應用程式伺服器170、網頁URL，等等)的軟體應用程式、資料及/或命令。該平台302亦可在無RAN相互作用的情況下獨立地執行局域儲存之應用程式。該平台302可包括一收發器306，該收發器306可操作地耦接至特殊應用積體電路(ASIC)308，或其他處理器、微處理器、邏輯電路或其他資料處理器件。ASIC 308或其他處理器執行應用程式設計介面(API)310層，該應用程式設計介面(API)310層與無線器件之記憶體312中之任何駐留程式介接。記憶體312可包含唯讀記憶體或隨機存取記憶體(RAM及ROM)、EEPROM、快閃卡，或為電腦平台所共用之任何記憶體。平台302亦可包括一區域資料庫314，該區域資料庫314可儲存未主動地用於記憶體312中之應用程式，以及其他資料。區域資料庫314通常為快閃記憶體晶胞，但如在此向技術中為吾人所知，可為任何次級儲存器件，諸如磁性媒體、EEPROM、光學媒體、磁帶、軟碟或硬碟，或其類似者。

因此，本發明之一實施例可包括一包括執行本文所描述之功能之能力的UE(例如，UE 300A、300B，等等)。如熟習此項技術者將瞭解，各種邏輯元件可以離散元件、執行於處理器上之軟體模組，或軟體及硬體之任何組合體現以達成本文所揭示之功能性。舉例而言，可合作性地使用所有ASIC 308、記憶體312、API 310及區域資料庫314，以載入、儲存及執行本文所揭示之各種功能，且因此可經由各種元件分配用以執行此等功能之邏輯。或者，該功能性可併入至一個離散組件中。因此，圖3中之UE 300A及300B之特徵應被認為僅僅係說明性的，且本發明不限於所說明特徵或配置。

UE 300A及/或300B與RAN 120之間的無線通訊可基於不同技術，諸如，CDMA、W-CDMA、分時多重存取(TDMA)、分頻多重存取(FDMA)、正交分頻多工(OFDM)、GSM，或可用於無線通訊網路或資料通訊網路中之其他協定。如前文中所論述且在此項技術中為吾人所知，可使用多種網路及組態將語音傳輸及/或資料自RAN傳輸至UE。因此，本文所提供之說明不意欲限制本發明之實施例，且僅僅用以輔助本發明之實施例之態樣之描述。

圖4說明包括經組態以執行功能性之邏輯的通訊器件400。該通訊器件400可對應於上文所提及之通訊器件中任一者，其包括(但不限於)UE 300A或300B、RAN 120(例如，BS 200A至210A、BSC 215A、節點B 200B至210B、RNC 215B、eNodeB 200D至210D，等等)之任何組件、核心網路140(例如，PCF 220A、PDSN 225A、SGSN 220B、GGSN 225B、MME 215D或220D、HSS 225D、S-GW 230D、P-GW 235D、PCRF 240D)之任何組件，與核心網路140及/或網際網路175耦接之任何組件(例如，應用程式伺服器170)，等等。因此，通訊器件400可對應於經組態以經由圖1之無線通訊系統100而與一或多個其他實體通訊(或促進與一或多個其他實體之通訊)的任何電子器件。

參看圖4，該通訊器件400包括經組態以接收及/或傳輸資訊之邏輯405。在一實例中，若通訊器件400對應於無線通訊器件(例如，UE 300A或300B、BS 200A至210A中之一者、節點B 200B至210B中之一者、eNodeB 200D至210D中之一者，等等)，則經組態以接收及/或傳輸資訊之邏輯405可包括無線通訊介面(例如，藍芽、WiFi、2G、CDMA、W-CDMA、3G、4G、LTE，等等)，諸如無線收發器及相關聯硬體(例如，RF天線、數據機(MODEM)、調變器及/或解調器，等等)。在一實例中，經組態以接收及/或傳輸資訊之邏輯405可對應於有線通訊介面(例如，串聯連接、USB或火線(Firewire)連接、供可存取網際網路175之乙太網路連接，等等)。因此，若通訊器件400對應於某一類型之以網路為基礎之伺服器(例如，PDSN、SGSN、GGSN、S-GW、P-GW、MME、HSS、PCRF、應用程式170，等等)，則經組態以接收及/或傳輸資訊之邏輯405可在一實例中對應於將以網路為基礎之伺服器經由乙太網路協定連接至其他通訊實體的乙太網路卡。在另一實例中，經組態以接收及/或傳輸資訊之邏輯405可包括通訊器件400可藉以監視其局域環境的感測或量測硬體(例如，加速計、溫度感測器、光感測器、用於監視局域RF信號之天線，等等)。經組態以接收及/或傳輸資訊之邏輯405亦可包括軟體，該軟體在經執行時，該軟體准許經組態以接收及/或傳輸資訊之邏輯405之相關聯硬體執行其接收及/或傳輸功能。然而，經組態以接收及/或傳輸資訊之邏輯405並不單獨對應於軟體，且經組態以接收及/或傳輸資訊之邏輯405至少部分地依賴於硬體以達成其功能性。

參看圖4，通訊器件400進一步包括經組態以處理資訊之邏輯410。在一實例中，經組態以處理資訊之邏輯410可包括至少一處理器。可藉由經組態以處理資訊之邏輯410執行之處理類型之實例實施包括(但不限於)執行判定、建立連接、在不同資訊選項之間作出選擇、執行相關於資料之評估、與耦接至通訊器件400之感測器相互作用以執行量測操作、將資訊自一格式轉換至另一格式(例如，在不同協定之間諸如.wmv至.avi等等)，等等。舉例而言，包括於經組態以處理資訊之邏輯410中的處理器可對應於通用處理器、數位信號處理器(DSP)、ASIC、場可程式化閘陣列(FPGA)或其他可程式化邏輯器件、離散閘或電晶體邏輯、離散硬體組件、或其經設計以執行本文所描述之功能的任何組合。通用處理器可為微處理器，但在替代例中，處理器可為任何習知處理器、控制器、微控制器或狀態機。處理器亦可被實施為計算器件之組合，例如，一DSP與一微處理器之組合、複數個微處理器、結合DSP核心之一或多個微處理器，或任何其他此組態。經組態以處理資訊之邏輯410亦可包括軟體，該軟體在經執行時，該軟體准許經組態以處理資訊之邏輯410的相關聯硬體執行其處理功能。然而，經組態以處理資訊之邏輯410並不單獨對應於軟體，且經組態以處理資訊之邏輯410至少部分地依賴於硬體以達成其功能性。

參看圖4，通訊器件400進一步包括經組態以儲存資訊之邏輯415。在一實例中，經組態以儲存資訊之邏輯415可包括至少一非暫時性記憶體及相關聯硬體(例如，記憶體控制器，等等)。舉例而言，包括於經組態以儲存資訊之邏輯415中的非暫時性記憶體可對應於RAM記憶體、快閃記憶體、ROM記憶體、EPROM記憶體、EEPROM記憶體、暫存器、硬碟、抽取式磁碟、CD-ROM，或此項技術中已知的任何其他形式之儲存媒體。經組態以儲存資訊之邏輯415亦可包括軟體，該軟體在被執行時，該軟體准許經組態以儲存資訊之邏輯415的相關聯硬體執行其儲存功能。然而，經組態以儲存資訊之邏輯415並不單獨對應於軟體，且經組態以儲存資訊之邏輯415至少部分地依賴於硬體以實現其功能性。

參看圖4，通訊器件400進一步視情況包括經組態以呈現資訊之邏輯420。在一實例中，經組態以呈現資訊之邏輯420可包括至少一輸出器件及相關聯硬體。舉例而言，輸出器件可包括視訊輸出器件(例如，顯示屏幕、可攜載視訊資訊之埠(諸如，USB、HDMI，等等))、音訊輸出器件(例如，揚聲器、可攜載音訊資訊之埠(諸如，麥克風插口、USB、HDMI，等等))、振動器件及/或可藉以格式化資訊以用於由使用者或通訊器件400之操作員輸出或實際上輸出的任何其他器件。舉例而言，若通訊器件400對應於如圖3所展示之UE 300A或UE 300B，則經組態以呈現資訊之邏輯420可包括UE 300A之顯示器310A或UE 300B之觸控式螢幕顯示器305B。在另一實例中，對於某些通訊器件，諸如不具有區域使用者之網路通訊器件(例如，網路交換器或路由器、遠端伺服器，等等)，可省略經組態以呈現資訊之邏輯420。經組態以呈現資訊之邏輯420亦可包括軟體，該軟體在經執行時，該軟體准許經組態以呈現資訊之邏輯420的相關聯硬體執行其呈現功能。然而，經組態以呈現資訊之邏輯420不單獨對應於軟體，且經組態以呈現資訊之邏輯420至少部分地依賴於硬體以達成其功能性。

參看圖4，通訊器件400進一步視情況包括經組態以接收區域使用者輸入之邏輯425。在一實例中，經組態以接收區域使用者輸入之邏輯425可包括至少一使用者輸入器件及相關聯硬體。舉例而言，使用者輸入器件可包括按鈕、觸控式螢幕顯示器、鍵盤、攝影機、音訊輸入器件(例如，麥克風或可攜載音訊資訊之埠(諸如，麥克風插口，等等))，及/或可藉以自使用者或通訊器件400之操作員接收資訊的任何其他器件。舉例而言，若通訊器件400對應於如圖3所展示之UE 300A或UE 300B，則經組態以接收區域使用者輸入之邏輯425可包括小鍵盤320A、按鈕315A或310B至325B中任一者、觸控式螢幕顯示器305B，等等。在另一實例中，對於某些通訊器件，諸如不具有區域使用者之網路通訊器件(例如，網路交換器或路由器、遠端伺服器，等等)，可省略經組態以接收區域使用者輸入之邏輯425。經組態以接收區域使用者輸入之邏輯425亦可包括軟體，該軟體在經執行時，該軟體准許經組態以接收區域使用者輸入之邏輯425的相關聯硬體執行其輸入接收功能。然而，經組態以接收區域使用者輸入之邏輯425不單獨對應於軟體，且經組態以接收區域使用者輸入之邏輯425至少部分地依賴於硬體以達成其功能性。

參看圖4，雖然在圖4中將經組態邏輯405至425展示為分離或相異區塊，但應瞭解，各別經組態邏輯藉以執行其功能性之硬體及/或軟體可部分地重疊。舉例而言，用以促進經組態邏輯405至425之功能性的任何軟體可儲存於與經組態以儲存資訊之邏輯415相關聯的非暫時性記憶體中，使得經組態邏輯405至425部分地基於由經組態以儲存資訊之邏輯415所儲存的軟體操作而各自執行其功能性(亦即，在此狀況下，軟體執行)。同樣地，可由其他經組態邏輯不定期地借位或使用與經組態邏輯中之一者直接相關聯的硬體。舉例而言，可在由經組態以接收及/或傳輸資訊之邏輯405傳輸之前，經組態以處理資訊之邏輯410的處理器將資料格式化成適當格式，使得經組態以接收及/或傳輸資訊之邏輯405部分地基於與經組態以處理資訊之邏輯410相關聯的硬體(亦即，處理器)操作而執行其功能性(亦即，在此狀況下，資料傳輸)。

通常，除非明確地另外陳述，否則如貫穿本發明所使用之片語「經組態以……之邏輯」意欲調用至少部分地運用硬體實施之實施例，且不意欲映射為獨立於硬體之僅軟體實施。又，應瞭解，各種區塊中之經組態邏輯或「經組態以……之邏輯」不限於特定邏輯閘或元件，而是大體上係指執行本文所描述之功能性的能力(經由硬體抑或硬體及軟體之組合)。因此，不管是否共用詞「邏輯」，如各種區塊中所說明之經組態邏輯或「經組態以……之邏輯」未必被實施為邏輯閘或邏輯元件。自下文更詳細描述之實施例的檢視，各種區塊中之邏輯之間的其他相互作用或合作對於一般熟習此項技術者將變得清楚。

經由諸如圖2A中之1x EV-DO、圖2B至圖2C中之以UMTS為基礎之W-CDMA、圖2D中之LTE及圖2E中之eHRPD之網路進行操作之工作階段可在供預留保證品質層級(其被稱作服務品質(QoS))之頻道(例如，RAB、流，等等)上予以支援。舉例而言，在一特定頻道上建立給定QoS層級可提供彼頻道上之最小保證位元速率(GBR)、最大延遲、抖動、潛時、位元誤差速率(BER)等等中之一或多者。QoS資源可經預留(或經設置)用於與即時或串流通訊工作階段相關聯之頻道，該等即時或串流通訊工作階段諸如，網際網路語音通訊協定(VoIP)工作階段、群組通訊工作階段(例如，PTT工作階段，等等)、線上遊戲、IP TV等等，以幫助確保用於此等工作階段之無縫端對端封包傳送。

通常，當設置或啟動QoS載送以用於與特定應用程式相關聯之通訊工作階段(例如，VoIP、PTT，等等)(其在本文中被表示為App*)時，在上行鏈路頻道及下行鏈路頻道兩者上設置QoS歷時該通訊工作階段之整個持續時間。然而，如由一般熟習此項技術者應瞭解，參與App*通訊工作階段之給定UE上之用戶端應用程式可不具有高優先級流量以在上行鏈路頻道及下行鏈路頻道兩者上傳輸及/或接收以用於連續地及/或同時地進行通訊工作階段。

舉例而言，在半雙工App*通訊工作階段(例如，1：1或直接呼叫，或諸如PTT之群組呼叫)中，發言權擁有者(floorholder)可具有高優先級流量以在上行鏈路頻道上進行傳輸(亦即，至非發言權擁有者)，但該發言權擁有者歸因於App*工作階段之半雙工性質而通常將不具有高優先級流量以在下行鏈路頻道上進行接收。相似地，在上文所提及之半雙工App*通訊工作階段中，非發言權擁有者可具有高優先級流量以在下行鏈路頻道上進行接收(亦即，自發言權擁有者)，但該(該等)非發言權擁有者歸因於App*工作階段之半雙工性質而通常將不具有高優先級流量以在上行鏈路頻道上進行傳輸。另外，在半雙工 App*工作階段期間，存在無人擁有發言權(例如，在任一方向上皆不具有高優先級流量，惟發言權請求除外)之時間。轉向全雙工App*通訊工作階段(例如，1：1或直接呼叫)，呼叫中之給定方可使其工作階段靜音或可僅僅不說話，使得該給定方不具有高優先級流量以在上行鏈路頻道上進行傳輸。如應瞭解，在上文所提及之半雙工或全雙工App*工作階段之至少一部分期間，貫穿App*通訊工作階段連續地預留用於在兩個方向上(亦即，上行鏈路及下行鏈路)之各別工作階段參與者之QoS可為效率低的，此係因為每一QoS預留會縮減系統100之總資源容量。

因此，本發明之實施例係關於基於預期高優先級流量在App*通訊工作階段期間流動(或實際上正流動)之方向(例如，上行鏈路及/或下行鏈路)而以動態方式選擇性地增加或減低至用於該App*通訊工作階段的上行鏈路頻道及/或下行鏈路頻道之QoS資源之分配。詳言之，下文所描述之本發明之實施例係有關經組態以藉由橫越上文在圖2A至圖2E所展示的核心網路中之一或多者之應用程式伺服器170而仲裁的以QoS為基礎之通訊工作階段。

舉例而言，在以QoS為基礎之App*通訊工作階段對應於經由圖2A所展示之1x EV-DO核心網路而在一或多個UE之間進行調解的VoIP工作階段之狀況下，由應用程式伺服器170管理之每一VoIP工作階段可與潛在地被分配QoS之三個(3個)流(亦即，一呼叫設置傳信流、一呼叫中傳信流及一媒體流量流)相關聯。該1x EV-DO核心網路未認識到作為可預留參數之GBR QoS，使得在RAN 120處實施用於EV-DO之QoS設置。

在另一實例中，在以QoS為基礎之App*通訊工作階段對應於經由圖2B或圖2C所展示之以UMTS為基礎之W-CDMA核心網路而在一或多個UE之間進行調解的VoIP工作階段之狀況下，每一VoIP工作階段可經組態有一「交互式」流量類別QoS且可在RAN 120處(亦即，UTRAN)且經由空中介面藉由組態MAC-es/MAC-hs GBR且使用用於UL之未經排程傳輸授予來接收GBR QoS。與上文關於1x EV-DO核心網路之實例相似，GBR QoS資源未被預留且不可在圖2B至圖2C之W-CDMA核心網路中經組態以用於「交互式」流量類別(僅RAN 120)，此係因為W-CDMA核心網路並未認識到作為可預留參數之GBR QoS，使得僅邏輯連接得以維持。或者，當使用「交談式」流量類別來代替「交互式」流量類別時，GBR QoS資源可藉由UE及W-CDMA核心網路兩者予以協商/修改。通常，VoIP工作階段在W-CDMA中使用「交談式」流量類別。

在另一實例中，在以QoS為基礎之App*通訊工作階段對應於經由圖2D所展示之LTE核心網路而在一或多個UE之間進行調解的VoIP工作階段之狀況下，由應用程式伺服器170管理之該等VoIP工作階段使用為「1」之QoS類別識別符(QCI)或一特殊應用QCI以用於在專用應用程式特定PDN連接(被表示為PDN_App*)上之App* GBR QoS載送(被表示為QCI_App*)，且需要甚至在UE處於RRC閒置狀態時維持S5連接或在RRC閒置至已連接轉變之後快速地設置S5連接。因此，不同於圖2A之1x EV-DO核心網路及圖2B至圖2C之W-CDMA核心網路，圖2D之LTE核心網路藉此除了RAN 120處以外亦支援核心網路140處之GBR QoS。

將在下文中更詳細地描述之本發明之實施例各自經組態以用於在來自圖2A至圖2B之核心網路中之一或多者內操作，如在表2(下文)中被概述如下：

圖5說明根據本發明之一實施例的用戶端應用程式起始方向QoS管理程序的更詳細實施實例。如表2(上文)中所解釋，可在圖2A之1x EV-DO核心網路、圖2B至圖2C之W-CDMA核心網路(在「交談式」流量類別係用於工作階段的情況下)、圖2D之LTE核心網路及/或圖2E之eHRPD核心網路中來實施用戶端應用程式起始方向QoS管理程序(亦即，來自表2之1號)。圖5對此等核心網路類型中任一者係通用的，而圖6A至圖6C展示用於將圖5之程序映射至個別核心網路類型之更詳細流程圖。

參看圖5，用於給定UE上之App*之用戶端應用程式判定起始App*通訊工作階段(例如，VoIP工作階段、PTT工作階段，等等)(500)。500之判定可基於由給定UE之操作員起始通訊工作階段之請求，在此狀況下，給定UE為起始之UE。或者，500之判定可基於在給定UE處所接收之通知由某其他實體起始App*通訊工作階段之呼叫通知訊息，在此狀況下，給定UE為目標UE。在圖5之實施例中，假定App*用戶端應用程式正在給定UE上執行且經組態以處置與App*通訊工作階段(例如，VoIP工作階段、PTT工作階段，等等)相關聯之用戶端側操作。

在505處，App*用戶端應用程式判定待起始之App*通訊工作階段是為半雙工抑或全雙工。若App*用戶端應用程式在505處判定App*通訊工作階段係半雙工(例如，PTT呼叫)，則App*用戶端應用程式判定給定UE當前是否具有對半雙工App*工作階段之發言權(或是否為半雙工App*工作階段之當前發言權擁有者)(510)。若App*用戶端應用程式在510處判定給定UE具有發言權，則App*用戶端應用程式判定是否建立上行鏈路(UL)QoS資源之臨限位準(例如，經設定至臨限值日期速率或kpbs之GBR)以用於支援藉由用於半雙工App*工作階段之給定UE之上行鏈路媒體傳輸(515)。如應瞭解，對半雙工App*工作階段之發言權擁有者很可能在UL頻道上傳輸高優先級媒體以供分配至作為非發言權擁有者或收聽者的參與該半雙工App*工作階段之目標UE，使得來自該發言權擁有者之在UL頻道上之QoS可改良用於該半雙工App*工作階段之工作階段品質。如將在下文中關於圖6A至圖6C更詳細地解釋，515之上行鏈路QoS資源判定可包括(i)在給定UE係由如圖2A中之1x EV-DO網路或如圖2E中之eHRPD網路伺服的情況下，判定是否設置用於UL媒體流量流之QoS，(ii)在給定UE係由如圖2B至圖2C中之W-CDMA網路或如圖2D中之LTE網路伺服的情況下，判定UL媒體載送是否經組態有至少一臨限值GBR以用於支援半雙工工作階段。

若給定UE上之App*用戶端應用程式在515處判定用於半雙工App*工作階段之臨限值UL QoS資源尚未經設置，則給定UE在520處請求啟動及/或增加UL QoS資源。舉例而言，若給定UE係由如圖2A中之1x EV-DO網路伺服，則給定UE可在520處請求啟動用於UL媒體流量流之QoS。在另一實例中，若給定UE係由如圖2B至圖2C中之W-CDMA網路或如圖2D中之LTE網路伺服，則給定UE可在520處請求將其於其UL媒體載送上之當前GBR修改成較高GBR(例如，X_App* kpbs，其中X_App* kpbs對應於用於App*通訊工作階段之應用程式特定動態資料速率)。

另外，若在510處判定給定UE具有對半雙工App*工作階段之發言權，則應瞭解，給定UE可無需用於下行鏈路(DL)媒體之QoS。因此，除了在515至520處選擇性地設置或增加用於UL頻道之QoS(必要時)以外，給定UE亦將在525至530處選擇性地拆除或縮減用於App*載送之DL頻道之現有QoS資源(必要時)。因此，App*用戶端應用程式判定是否建立DL QoS資源之臨限位準以用於支援在用於半雙工App*工作階段之給定UE處之DL媒體接收(525)。如將在下文中關於圖6A至圖6C更詳細地解釋，525之DL QoS資源判定可包括(i)在給定UE係由如圖2A中之1x EV-DO網路或如圖2E中之eHRPD網路伺服的情況下，判定是否設置用於DL媒體流量流之QoS，(ii)在給定UE係由如圖2B至圖2C中之W-CDMA網路或如圖2D中之LTE網路伺服的情況下，判定DL App*媒體載送是否經組態有至少一臨限值GBR。

若給定UE上之App*用戶端應用程式判定在525處已設置用於半雙工App*工作階段之臨限值DL QoS資源，則該給定UE上之App*用戶端應用程式在530處請求撤銷啟動及/或減低DL QoS資源。舉例而言，若給定UE係由如圖2A中之1x EV-DO網路或如圖2E中之eHRPD網路伺服，則給定UE可在530處請求撤銷啟動或關斷用於DL媒體流量流之QoS。在另一實例中，若給定UE係由如圖2B至圖2C中之W-CDMA網路或如圖2D中之LTE網路伺服，則該給定UE上之App*用戶端應用程式可在530處請求將其於其DL媒體載送上之當前GBR修改成較低GBR。

仍參看圖5且返回轉向至510之半雙工發言權擁有者判定，若App*用戶端應用程式在510處判定給定UE不具有發言權，則App*用戶端應用程式判定另一工作階段參與者是否擁有發言權(亦即，是否正經由用於半雙工App*工作階段之DL頻道來接收來自某實體之媒體)(535)。如應瞭解，用於半雙工App*工作階段之非發言權擁有者(或目標UE)很可能待在DL上接收高優先級媒體，使得用於非發言權擁有者或目標UE之DL頻道上之QoS可改良用於該半雙工App*工作階段之工作階段品質。因此，若App*用戶端應用程式在535處判定另一實體擁有發言權(亦即，正在用於半雙工App*工作階段之給定UE處接收媒體)，則App*用戶端應用程式判定是否建立DL QoS資源之臨限位準以用於支援用於半雙工工作階段之給定UE處之DL媒體接收(540)(類似於525)。

若給定UE上之App*用戶端應用程式判定在540處用於半雙工App*工作階段之臨限值DL QoS資源尚未經設置，則該給定UE上之App*用戶端應用程式在545處請求啟動及/或增加DL QoS資源。舉例而言，若給定UE係由如圖2A中之1x EV-DO網路或如圖2E中之eHRPD網路伺服，則給定UE可在545處請求啟動用於DL媒體流量流之QoS。在另一實例中，若給定UE係由如圖2B至圖2C中之W-CDMA網路或如圖2D中之LTE網路伺服，則該給定UE上之App*用戶端應用程式可在545處請求將其於其DL媒體載送上之當前GBR修改成較高GBR(例如，X_App* kpbs)。

另外，若在510處判定給定UE不具有對半雙工App*工作階段之發言權，則應瞭解，給定UE可無需用於UL媒體之QoS。因此，除了在540至545處選擇性地設置用於DL頻道之QoS(必要時)以外，給定UE亦將在550至555處選擇性地拆除或縮減用於UL頻道之現有QoS資源(必要時)。因此，App*用戶端應用程式判定是否建立UL QoS資源之臨限位準以用於支援在用於半雙工工作階段之給定UE處之UL媒體接收(550)(類似於520)。

若給定UE上之App*用戶端應用程式在550處判定已設置用於半雙工App*工作階段之臨限值UL QoS資源，則給定UE在555處請求撤銷啟動及/或減低UL QoS資源。舉例而言，若給定UE係由如圖2A中之1x EV-DO網路或如圖2E中之eHRPD網路伺服，則給定UE上之App*用戶端應用程式可在555處請求撤銷啟動或關斷用於UL媒體流量流之QoS。在另一實例中，若給定UE係由如圖2B至圖2C中之W-CDMA網路或如圖2D中之LTE網路伺服，則該給定UE上之App*用戶端應用程式可在555處請求將其於其UL媒體載送上之當前GBR修改成較低GBR(例如，1kpbs，或某其他標稱資料速率)。

仍參看圖5且返回轉向至535之判定，藉以App*用戶端應用程式在510處判定給定UE自身並不擁有發言權之後判定是否存在另一發言權擁有者，若App*用戶端應用程式在535處判定無人擁有發言權，則App*用戶端應用程式判定減低或撤銷啟動用於半雙工App*工作階段之DL QoS資源及UL QoS資源兩者(至少地直至工作階段參與者中之一者被授予發言權為止)(560)。因此，在560之後，處理程序前進至525至530及550至555兩者，其中減低及/或撤銷啟動DL QoS資源及UL QoS資源(必要時)。

仍參看圖5且返回轉向至505之雙工判定，若App*用戶端應用程式判定通訊工作階段係全雙工(例如，VoIP呼叫)而非半雙工，則App*用戶端應用程式判定用於全雙工App*工作階段之音訊是否靜音(565)。如應瞭解，若音訊靜音，則給定UE之操作員正收聽全雙工App*工作階段中之另一(另外若干)UE，但實際上不想要其自有音訊傳達至該另一(該等另外)UE。若App*用戶端應用程式在565處判定全雙工App*工作階段並未靜音，則啟動或增加用於全雙工App*工作階段之UL QoS資源及DL QoS資源兩者(必要時)(570)。舉例而言，在一實例中，570可對應於515至520及550至555之執行。否則，若App*用戶端應用程式在565處判定全雙工App*工作階段靜音，則處理程序前進至540至555，其中增加或啟動DL QoS資源(必要時)且減低或撤銷啟動UL QoS資源(必要時)。

圖6A說明根據本發明之一實施例的用於給定UE之圖5之處理程序的實例實施，該給定UE在由如圖2A中之1x EV-DO網路(舊版HRPD)或如圖2E中之eHRPD網路伺服的同時聯結半雙工App* PTT工作階段。參看圖6A，當給定UE處於閒置狀態時，App*用戶端應用程式判定起始App* PTT呼叫(600A)(例如，回應於PTT按鈕推動)，且App*用戶端應用程式判定該給定UE具有發言權(605A)(例如，類似於圖5中之500至515)。在假定給定UE仍未具有用於其用於App* PTT呼叫之UL媒體流之QoS設置的情況下，給定UE上之App*用戶端應用程式請求用於其用於App* PTT呼叫的UL媒體流而非DL媒體流之QoS啟動。此情形在圖6A中被展示，藉以給定UE傳輸指示UL媒體QoS流(而非DL媒體QoS流)之ReservationOnRequest訊息(615A)。因此，RAN 120設置用於UL媒體流之UL QoS預留(藉由620A至640A之間的傳信來展示，其將由熟悉1x EV-DO的一般熟習此項技術者易於理解)，同時留下DL QoS預留用於處於經暫時中止狀態之DL媒體流(例如，類似於圖5之515至530)。雖然圖6A中未明確地展示，但給定UE上之App*用戶端應用程式可在640A之後作為發言權擁有者開始傳輸媒體。

參看圖6A，給定UE上之App*用戶端應用程式最終釋放發言權(645A)，且App*用戶端應用程式判定另一UE具有對App* PTT工作階段之發言權(650A)(類似於圖5之510及535)。因此，給定UE接通用於DL媒體流之DL QoS預留(655A至660A)，且給定UE拆除用於UL媒體流之UL QoS預留(665A至670A)，此類似於圖5之540至555。

參看圖6A，另一UE最終釋放發言權(675A)，且App*用戶端應用程式判定無UE具有對App* PTT工作階段之發言權(680A)(類似於圖5之535及560)。因此，給定UE上之App*用戶端應用程式拆除用於DL媒體流之DL QoS預留及用於UL媒體流之UL QoS預留兩者(680A至690A)，此類似於圖5之525至530及550至555。

雖然圖6A係有關給定UE為對App* PTT呼叫之發起者之實例，但應瞭解，圖6A可經修改以適應給定UE代替地為關於App* PTT呼叫之呼叫目標之情境。在圖6A之呼叫目標實施中，呼叫目標UE上之App*用戶端應用程式經由呼叫通知訊息(代替如600A中之PTT按鈕推動)而感知App* PTT呼叫，且呼叫目標UE作為非發言權擁有者(代替如圖6A中之發言權擁有者)將開始App* PTT呼叫。除了此等差異以外，可針對呼叫目標UE以與圖6A相似的方式管理用於App*媒體QoS流之UL QoS及DL QoS。又，雖然圖6A中未明確地展示，但圖6A可擴展以便涵蓋來自圖5之額外使用狀況，諸如全雙工實例(例如，來自圖5之565、570等等)來代替圖6B中之半雙工工作階段實例。另外，雖然圖6A係在給定UE閒置(亦即，不具有流量頻道(TCH))時在600A處起始App* PTT呼叫的情況下予以描述，但應瞭解，圖6A可經修改使得在給定UE已經被分配TCH(或經由經預建立TCH而被通知給給定UE(目標UE實施))時在該給定UE處起始App* PTT呼叫。

圖6B說明根據本發明之一實施例的用於給定UE之圖5之處理程序的實例實施，該給定UE在由如圖2B或圖2C中之W-CDMA網路伺服的同時聯結半雙工App* PTT工作階段。參看圖6B，給定UE正在CELL_PCH或URA_PCH狀態下操作(600B)，且App*用戶端應用程式接收與由某其他UE發起之App* PTT呼叫相關聯之傳呼(605B)(例如，回應於另一UE處之PTT按鈕推動)，此情形增進給定UE對RAN 120執行小區更新程序(610B)，以便轉變成CELL_DCH狀態(615B)，以接收PTT通知訊息(未圖示)且設置用於App* PTT工作階段之RAB(620B)。詳言之，在620B處，RAN 120在用於將支援App* PTT工作階段之媒體RAB之UL及DL兩者上分配至少一臨限值GBR(例如，X_App* kpbs)。

參看圖6B，假定App*用戶端應用程式判定另一UE具有對App* PTT工作階段之發言權(625B)(類似於圖5之510及535)。因此，因為已經在620B處向給定UE分配臨限值GBR，所以App*用戶端應用程式判定將分配給DL媒體載送之GBR維持處於X_App* kpbs，但縮減分配給UL媒體載送之GBR(例如，至1kpbs或某其他標稱位準)，此類似於圖5之540至555。圖6B中在630B至670B之間的傳信中展示至UL媒體載送之GBR縮減，且此傳信將由熟悉UMTS及/或W-CDMA的一般熟習此項技術者易於理解。

雖然圖6B係有關給定UE為用於App* PTT呼叫之呼叫目標UE之實例，但應瞭解，圖6B可經修改以適應給定UE代替地為App* PTT呼叫之呼叫發起者之情境。在圖6B之呼叫發起者實施中，呼叫發起者UE上之App*用戶端應用程式可經由PTT按鈕推動(代替如605B中之傳呼/通知程序)而感知App* PTT呼叫，且呼叫發起者UE作為發言權擁有者(代替如圖6B中之非發言權擁有者)將開始App* PTT呼叫。除了此等差異以外，可針對呼叫目標UE以與圖6B相似的方式管理用於App*媒體QoS流之UL QoS及DL QoS。又，雖然圖6B中未明確地展示，但圖6B可擴展以便涵蓋來自圖5之額外使用狀況，諸如全雙工實例(例如，來自圖5之565、570等等)來代替圖6B中之半雙工工作階段實例。另外，雖然圖6B係在基於在給定UE處於URA_PCH/CELL_PCH狀態時所接收之傳呼而在605B處起始App* PTT呼叫的情況下予以描述，但應瞭解，圖6B可經修改使得在給定UE已經處於CELL_DCH狀態(或當在CELL_DCH狀態中時在給定UE處偵測到用於App*之PTT按鈕推動，以用於起始之UE實施)時得到用於App* PTT工作階段之呼叫通知之App* PTT呼叫)。

圖6C說明根據本發明之一實施例的用於給定UE之圖5之處理程序的實例實施，該給定UE在由如圖2D中之LTE網路伺服的同時起始半雙工App* PTT工作階段。參看圖6C，給定UE正在無線電資源已連接(RRC)閒置模式中操作(600C)，且App*用戶端應用程式判定起始半雙工App*PTT工作階段(例如，回應於給定UE上之PTT按鈕推動)(605C)。給定UE接著對RAN 120(亦即，伺服給定UE之eNodeB，諸如，eNodeB 205D)執行RCC連接設置及服務請求程序(610C)，以便轉變成RRC已連接狀態(615C)，且設置非GBR EPS載送及專用GBR EPS載送以用於半雙工App*PTT工作階段之媒體(620C)。詳言之，在620C處，eNodeB 205D在UL及DL兩者上基於自MME 215B接收之QoS針對將支援App* PTT工作階段之App* GBR媒體載送分配至少一臨限值GBR(例如，X_App* kpbs)。

參看圖6C，假定App*用戶端應用程式判定給定UE將以發言權開始半雙工App* PTT工作階段(625C)(例如，類似於圖5中之500至515)。因為給定UE已經具有用於其UL媒體載送之QoS設置(例如，在620C處藉由eNodeB 205D分配給UL媒體載送之GBR之X_App* kpbs)，所以給定UE上之App*用戶端應用程式請求用於DL媒體載送之QoS自X_App* kpbs縮減至低於GBR臨限值之kpbs位準(例如，標稱kpbs層級，諸如，1kpbs)。圖6C中在630C至665C之間的傳信中展示至DL媒體載送之GBR縮減，且此傳信將由熟悉LTE的一般熟習此項技術者易於理解。

雖然圖6C係有關給定UE為對App* PTT呼叫之發起者之實例，但應瞭解，圖6A可經修改以適應給定UE代替地為用於App* PTT呼叫之呼叫目標之情境。在圖6C之呼叫目標實施中，呼叫目標UE上之App*用戶端應用程式經由呼叫通知訊息(代替如605C中之PTT按鈕推動)而感知App* PTT呼叫，且呼叫目標UE作為非發言權擁有者(代替如圖6C中之發言權擁有者)將開始App* PTT呼叫。除了此等差異以外，可針對呼叫目標UE以與圖6C相似的方式管理用於App*媒體QoS流之UL QoS及DL QoS。又，雖然圖6C中未明確地展示，但圖6C可擴展以便涵蓋來自圖5之額外使用狀況，諸如全雙工實例(例如，來自圖5之 565、570等等)來代替圖6C中之半雙工工作階段實例。另外，雖然圖6C係在給定UE處於RCC閒置狀態中時在605C處起始App* PTT呼叫的情況下予以描述，但應瞭解，圖6C可經修改使得在處於RRC已連接狀態中時(或當處於RRC已連接狀態中時向給定UE通知，用於目標UE實施)在給定UE處起始App* PTT呼叫。

雖然圖5至圖6C係關於用於在App*通訊工作階段之UL及DL頻道上進行選擇性QoS控制之UE側或以用戶端應用程式為基礎之程序予以描述，但圖7A至圖7B係有關在應用程式伺服器170處(例如，經組態以仲裁App*通訊工作階段之伺服器)來代替參與App*通訊工作階段之UE予以實施的相似選擇性QoS控制程序。如表2(上文)中所解釋，可在圖2D之LTE核心網路中實施應用程式伺服器輔助方向QoS管理程序(亦即，來自表2之2號)，但該應用程式伺服器輔助方向QoS管理程序可不能夠在圖2A之1x EV-DO核心網路或圖2B至圖2C之W-CDMA核心網路或圖2E之eHRPD網路中進行標準相容實施。

為了精簡圖7A之描述，圖7A之700至770係分別類似於圖5之500至570，惟下文中所提及除外。圖5之全部內容在參與App*通訊工作階段之給定UE處予以實施，而圖7A係在經組態以仲裁App*通訊工作階段之應用程式伺服器170處予以實施。圖5表示藉由一個特定UE處之App*用戶端應用程式執行之程序，而圖7A表示可針對參與通訊工作階段之每一UE在應用程式伺服器170處執行之程序(但在至少一個實施例中，應用程式伺服器170針對參與UE中每一者無需執行圖7A之處理程序)。雖然圖5中之給定UE上之App*用戶端應用程式可在圖5之500處基於使用者請求或給定UE處之呼叫通知訊息之接收而判定起始App*通訊工作階段，但圖7A之700處之應用程式伺服器170可基於來自起始之UE之呼叫請求訊息及/或來自目標UE之指示對所通知App*通訊工作階段之接受之呼叫接受訊息而判定起始App*通訊工作階段。另外，應瞭解，全雙工App*工作階段中之一些UE可使其工作階段靜音，且其他UE可不使其工作階段靜音，且一些UE可為對半雙工App*工作階段之發言權擁有者，且其他UE可為非發言權擁有者。因此，圖7A所展示之各種決策區塊可引起對藉由應用程式伺服器170評估之UE中每一者採取不同程序路徑。最後，因為圖7A程序係與LTE相關，所以圖7A所展示之各種QoS評估及修改可映射至LTE特定核心網路元件。舉例而言，720處的增加用於App* GBR QoS載送之UL QoS之請求可對應於自應用程式伺服器170發佈至PCRF 240D或P-GW 235D的將App* GBR QoS載送上之UL GBR提昇至X_App* kpbs之請求，730處的減低App* GBR QoS載送上之DL QoS之請求可對應於自應用程式伺服器170發佈至PCRF 240D或P-GW 235D的將App* GBR QoS載送上之DL GBR減低至低於GBR臨限值之kpbs(例如，1kpbs或某其他標稱資料速率)之請求，等等。除了此等差異以外，圖7A之剩餘操作類似於圖5，且圖7A之LTE實施可類似於圖6C，惟某些操作係自給定UE移動至應用程式伺服器170(且潛在地針對更多UE予以執行)除外。圖7B之700B至770B分別說明圖7A之700至770之更詳細實施，藉此參考LTE特定分量及訊息。

圖7C說明根據本發明之一實施例的用於聯結半雙工App* PTT工作階段之給定UE(呼叫發起者或呼叫目標)之LTE網路內之圖7B的實例實施。參看圖7C，應用程式伺服器170判定設置對給定UE之半雙工App* PTT呼叫(700C)(例如，如在圖7B之700B及705B中)，且應用程式伺服器170判定給定UE具有發言權，且藉此設定用於UL App* GBR載送之最大位元速率(MBR)，具有發言權之UL App* GBR載送將DL GBR設定成等於低kpbs，諸如1kpbs(705C)(例如，如在圖7B之710B至730B中)。牢記此等假定，710C至760C之傳信展示可如何實施UL及DL App* GBR載送設定之LTE特定實例。舉例而言，在715C處， PCRF 240D被展示為執行用以將由應用程式伺服器170提供之MBS映射至用於達成所指明MBS之合適GBR值的邏輯之LTE核心網路組件，該GBR值在本文中被表示為X_App*。又，725至750C之間所展示之傳信涵蓋已經在UL及DL上設置App* GBR載送之情境，且亦涵蓋App* GBR載送尚未經設置之情境。若已設置App* GBR載送，則在725C處，UL App* GBR載送保持處於X_App* kpbs，而DL App* GBR載送經由更新載送請求訊息而縮減至1kpbs(或某其他標稱kpbs)。若App* GBR載送尚未經設置，則在725C處將UL App* GBR載送設置用於X_App* kpbs，而經由產生載送請求訊息將DL App* GBR載送設定成標稱kpbs。同樣地，若尚未設置App* GBR載送，則在730C處使用載送設置請求訊息，且若已設置App* GBR載送，則在730C處使用載送修改請求訊息。同樣地，若尚未設置App* GBR載送，則在750C處使用產生載送回應訊息，且若已設置App* GBR載送，則在750C處使用更新載送回應訊息。圖7C中所展示之剩餘傳信係獨立於App* GBR載送之開始狀態，且將由熟悉LTE的一般熟習此項技術者易於理解。雖然圖7C特定於半雙工PTT工作階段，但應易於瞭解，圖7C可如何經修改以適應除了PTT以外的全雙工工作階段或半雙工工作階段。

圖8A說明根據本發明之一實施例的核心網路起始方向QoS管理程序的更詳細實施實例。如表2(上文)所解釋，核心網路起始方向QoS管理程序(亦即，來自表2之3號)可在圖2B至圖2C之W-CDMA核心網路中予以實施(在「交談式」流量類別係用於工作階段的情況下)及/或在圖2D之LTE核心網路中予以實施，但可不能夠在圖2A之1x EV-DO核心網路或圖2E之eHRPD網路中進行標準相容實施。舉例而言，在W-CDMA或UMTS實施中，GGSN 225B或SGSN 220B可執行圖8A之處理程序，且在LTE實施中，P-GW 235D或S-GW 230D可執行圖8A之處理程序。

參看圖8A，回應於用於App*通訊工作階段(例如，半雙工工作階段、全雙工工作階段，等等)之GBR媒體載送之設置之偵測，核心網路140起動監視App* GBR媒體載送上之UL及DL流量之資料非作用中計時器(800)。在任一狀況下，如將在下文所解釋，一旦App* GBR媒體載送經啟動以用於App*工作階段，資料非作用中計時器即開始執行。

在805處，核心網路140判定在用於通訊工作階段之App* GBR媒體載送上是否偵測到UL或DL流量。詳言之，核心網路140在805處判定是否在UL或DL方向上偵測到與用於App*通訊工作階段之存取點名稱(APN)相關聯之App*流量(亦即，App*_APN)。若在805處藉由核心網路140偵測到UL或DL流量，則重設用於供偵測到流量之每一方向(UL及/或DL)之流量非作用中計時器(810)。在815處，對於流量非作用中計時器仍執行(亦即，尚未過期)之每一方向(UL及/或DL)，核心網路140判定是否已設置用於在各別方向上之App* GBR媒體載送之臨限值GBR(例如，類似於圖5之515、525、540及550)。若否，則核心網路140在供相關聯流量非作用中計時器仍執行且尚不具有臨限值GBR的每一方向(UL或DL)上增加GBR(例如，至X_App* kpbs)(820)。如應瞭解，可經由端對端通訊而向UE告知關於820之QoS調整(或GBR增加)，如下文在圖8C中在855C至890C之間及/或在圖8D中在850D至865D之間所展示。

參看圖8A，核心網路140監視UL及DL流量非作用中計時器以判定UL及DL流量非作用中計時器是否過期(825)。若在825處偵測到過期，則核心網路140判定是否已設置用於偵測到過期之各別方向上之App* GBR媒體載送之臨限值GBR(例如，類似於圖5之515、525、540及550)。若是，則核心網路140在偵測到過期且具有臨限值GBR的每一方向(UL或DL)上減低GBR(例如，至1kpbs或某其他標稱位準)(835)，在此之後，核心網路140監視(805)在835處減低之方向頻道上是否得到新流量，且核心網路140亦可繼續監視對於在835處未減低之另一方向頻道是否發生過期(825)(若存在的話)。如應瞭解，可經由端對端通訊而向UE告知關於830之QoS調整(或GBR減低)，如下文在圖8C中在855C至890C之間及/或在圖8D中在850D至865D之間所展示。圖8B之800B至835B分別說明圖8A之800至835之更詳細實施，藉以更明確地參考LTE特定及W-CDMA特定之分量及訊息。

圖8C說明根據本發明之一實施例的用於為由某其他UE發起之半雙工App* PTT工作階段之呼叫目標的給定UE之W-CDMA網路內之圖8B的實例實施。參看圖8C，800C至820C分別對應於來自圖6B之600B至620B。在825C處，SGSN 220B起動且維持UL及DL流量非作用中計時器(如在圖8B之800B至820B中)。在某一時刻，假定SGSN 220B之UL流量非作用中計時器過期(830C)(例如，如在圖8C之825B中)。因此，SGSN 220B經由對GGSN 225B之835C及840C之傳信而將其於App* UL GBR載送上之GBR縮減至標稱位準，諸如，1kpbs。在845C處，GGSN 225B起動(在820C處提出App* GBR載送之後)且自825C維持獨立於SGSN 220B之計時器之UL及DL流量非作用中計時器(如在圖8B之800B至820B中)。因此，GGSN 225B增進RAN 120以經由855C至895C之間的傳信而將App* UL GBR載送上之GBR縮減至標稱位準，諸如，1kpbs。雖然圖8C特定於半雙工PTT工作階段，但應易於瞭解圖8C可如何經修改以適應除了PTT以外的全雙工工作階段或半雙工工作階段。又，雖然圖8C係特定於呼叫目標UE，但應易於瞭解圖8C可如何經修改以用於呼叫發起者UE(例如，代替在805C處接收傳呼、偵測PTT按鈕推動，等等)。又，雖然圖8C展示給定UE當處於URA_PCH/CELL_PCH狀態中時在805C處接收傳呼，但在一替代實施中，該給定UE可替代地當處於CELL_DCH狀態中時接收PTT呼叫通知。

圖8D說明根據本發明之一實施例的用於為半雙工App* PTT工作階段之呼叫發起者之給定UE之LTE網路內之圖8B的實例實施。參看圖8D，800D至820D分別對應於來自圖6C之600C至620C。在825D處，S-GW 230D起動且維持UL及DL流量非作用中計時器(如在圖8B之800B至820B中)。在某一時刻，假定S-GW 220B之DL流量非作用中計時器過期(830D)(例如，如在圖8C之825B中)。因此，S-GW 230D將其與App* DL GBR載送上之GBR縮減至標稱位準，諸如，1kpbs，且向P-GW/PCRF 235D/240D通知縮減(835D)。在840D處，P-GW/PCRF 235D/240D起動(在820D處提出App* GBR之後)且自825D維持獨立於S-GW 230D之計時器之UL及DL流量非作用中計時器(如在圖8B之800B至820B中)。在某一時刻，假定由P-GW/PCRF 235D/240D 225B維持之DL流量非作用中計時器過期(845D)(例如，如在圖8C之825B中)。因此，P-GW/PCRF 235D/240D增進伺服eNodeB 205D經由850D至874D之間的傳信而將App* DL GBR載送上之GBR縮減至標稱位準，諸如，1kpbs。雖然圖8D特定於半雙工PTT工作階段，但應易於瞭解圖8D可如何經修改以適應除了PTT以外的全雙工工作階段或半雙工工作階段。又，雖然圖8D係特定於呼叫發起者UE，但應易於瞭解圖8D可如何經修改以用於呼叫目標UE(例如，代替在805D處之PTT按鈕推動，可得到用於App*工作階段之PTT傳呼或呼叫通知訊息)。又，雖然圖8D展示給定UE自RCC閒置狀態起始App* PTT工作階段，但在一替代實施中，該給定UE亦可在已經處於RCC已連接狀態中時起始App* PTT工作階段。

圖9A說明根據本發明之一實施例的藉以在RAN 120及核心網路140處區域地管理GBR資源之QoS管理程序的更詳細實施實例。如表2(上文)所解釋，藉以在RAN 120及核心網路140處區域地管理GBR資源之QoS管理程序(亦即，來自表2之4號)可在圖2D之LTE核心網路中予以實施，但可不能夠在圖2A之1x EV-DO核心網路或圖2B至圖2C之W-CDMA核心網路或圖2E之eHRPD網路中進行標準相容實施。

參看圖9A，回應於偵測到用於App*通訊工作階段(例如，半雙工App*工作階段、全雙工App*工作階段，等等)之App* GBR媒體載送之設置，用於參與該通訊工作階段之特定UE之RAN 120及核心網路140(例如，S-GW 230D以及P-GW 235D)兩者內之伺服eNodeB起動監視App* GBR媒體載送上之UL及DL流量之資料非作用中計時器(900)。通常，圖9A對應於LTE實施，其類似於圖8A，惟RAN 120亦維持UL及DL流量非作用中計時器以用於控制UL及DL頻道上之QoS資源(例如，GBR)除外。換言之，RAN 120及LTE核心網路組件獨立地執行其各別計時器且進行其自有GBR或QoS調整，使得RAN 120與LTE核心網路之間的協調(例如，傳信訊息)無需用以實施不同實體處之QoS調整；亦即，每一LTE組件可基於其自有流量非作用中計時器而獨立地或單向地作出QoS決策。如應瞭解，此情形意謂每一LTE組件可以一獨立方式改變GBR或QoS，使得無需向具有經調整QoS之載送被指派至之UE(或用戶端器件)告知在核心網路處所實施之QoS調整，但UE仍將感知藉由RAN 120關於其空中介面資源而實施之QoS調整。因此，除了雙RAN及核心網路實施以外，圖9A之900至935分別類似於圖8A之800至835，且出於簡潔起見將不對其進行進一步描述。圖9B之900B至935B分別說明圖9A之900至935之更詳細實施，藉以更明確地參考LTE特定分量及訊息。

圖10A至圖10B說明根據本發明之實施例的分別關於W-CDMA及EV-DO架構之以RAN起始計時器為基礎之方向QoS流管理程序。如表2(上文)所解釋，以RAN起始計時器為基礎之方向QoS流管理程序(亦即，來自表2之5號)可在圖2B至圖2C之W-CDMA核心網路中予以實施 (在「交互式」流量類別係用於工作階段的情況下，圖10A所展示)，或可在圖2A之1x EV-DO核心網路中予以實施(圖10B所展示)，但可不能夠在圖2D之LTE網路中進行標準相容實施。

參看描述W-CDMA特定實施之圖10A，回應於偵測到用於通訊工作階段(例如，半雙工App*工作階段、全雙工App*工作階段，等等)之App*資料RAB之設置，RAN 120(亦即，UTRAN)起動監視App*資料RAB上之UL及DL流量之資料非作用中計時器(1000A)。詳言之，App*資料RAB在1000A處經組態有「交互式」流量類別、傳信指示(「是」)及ARP屬性，或替代地App*資料RAB可經組態有「交談式」流量類別(在RAN 120能夠經重新組態成使得可修改與「交談式」流量類別相關聯之GBR參數的情況下)。

在1005A處，RAN 120判定在用於通訊工作階段之App*資料RAB上是否偵測到UL或DL流量。詳言之，RAN 120在1005A處判定在UL或DL方向上是否偵測到用於App*通訊工作階段之流量。若在1005A處藉由RAN 120偵測到UL或DL流量，則重設用於供偵測到流量之每一方向(UL及/或DL)之流量非作用中計時器(1010A)。在1015A處，對於流量非作用中計時器仍執行(亦即，尚未過期)之每一方向(UL及/或DL)，RAN 120判定是否已設置用於在各別方向上之App*資料RAB之臨限值GBR(例如，類似於圖5之515、525、540及550)。舉例而言，在1015A處，RAN 120可檢查MAC-es/MAC-hs GBR在資料RAB之UL及/或DL上是否經設定至X_App* kpbs。若否，則RNC 215B請求RAN 120內之伺服節點B在供相關聯流量非作用中計時器仍執行且尚不具有臨限值GBR的每一方向(UL或DL)上增加GBR(例如，至X_App* kpbs)(1020A)。如應瞭解，可向UE告知關於1020A之QoS調整(或GBR增加)，此係因為QoS調整係關於空中介面資源(亦即，UE與RAN 120之間的連接)予以實施。

參看圖10A，在1025A處，RAN 120進一步判定在App*資料RAB上偵測到UL資料流量的情況下，伺服節點B檢查App*資料RAB是否經組態有用以支援用於UL之GBR之未經排程傳輸授予(1025A)。若是，則為了設置用於App*資料RAB之伺服節點B處之UL GBR，沒有必要進行進一步動作(1030A)。若否，則伺服節點B重新組態App*資料RAB以用於UL上之未經排程傳輸授予(1035A)。

參看圖10A，RAN 120監視UL及DL流量非作用中計時器以判定UL及DL流量非作用中計時器是否過期(1040A)。若在1040A處偵測到過期，則RAN 120判定是否已設置用於偵測到過期之各別方向上之GBR媒體載送之臨限值GBR(1045A)(例如，類似於圖5之515、525、540及550)。舉例而言，在1045A處，RAN 120可檢查MAC-es/MAC-hs GBR在App*資料RAB之UL及/或DL上是否經設定至X_App* kpbs。若未設置在過期方向上用於UL或DL之臨限值GBR，則處理程序返回至1005A。否則，若設置在過期方向上用於UL或DL之臨限值GBR，則RNC 215B請求RAN 120內之伺服節點B在相關聯流量非作用中計時器過期且具有臨限值GBR的每一方向(UL或DL)上減低GBR(例如，至X_App* kpbs)(1050A)。如應瞭解，可向UE告知關於1050A之QoS調整(或GBR減低)，此係因為QoS調整係關於空中介面資源(亦即，UE與RAN 120之間的連接)予以實施。

參看圖10A，在1055A處，若用於資料RAB之UL流量非作用中計時器在1040A處過期，則伺服節點B檢查App*資料RAB是否經組態有用以支援用於UL之GBR之未經排程傳輸授予(1055A)。若否，則沒有必要進行進一步動作(1060A)。若是，則伺服節點B重新組態App*資料RAB以用於UL上之經排程傳輸授予(1065A)。

轉向描述1x EV-DO特定實施之圖10B，回應於偵測到用於App*通訊工作階段(例如，半雙工工作階段、全雙工工作階段，等等)之媒體QoS流之設置，RAN 120起動監視App*媒體QoS流上之UL及DL流量之資料非作用中計時器(1000B)。

在1005B處，RAN 120判定在用於通訊工作階段之App*媒體QoS流上是否偵測到UL或DL流量。若在1005B處藉由RAN 120偵測到UL或DL流量，則重設用於供偵測到流量之每一方向(UL及/或DL)之流量非作用中計時器(1010B)。在1015B處，對於流量非作用中計時器仍執行(亦即，尚未過期)之每一方向(UL及/或DL)，RAN 120判定是否已設置或接通用於在各別方向上之App*媒體QoS流之QoS(例如，類似於圖5之515、525、540及550)。若是，則處理程序返回至1005B。若否，則RAN 120發送ReservationOnMessage以在偵測到活動之方向上啟動App*媒體QoS流(1020B)。如應瞭解，可向UE告知關於1020B之QoS流啟動，此係因為QoS流啟動係關於空中介面資源(亦即，UE與RAN 120之間的連接)予以實施。

參看圖10B，RAN 120監視UL及DL流量非作用中計時器以判定UL及DL流量非作用中計時器是否過期(1025B)。若在1025B處偵測到過期，則RAN 120判定是否已設置或接通用於偵測到過期之各別方向上之App*媒體QoS流之QoS(1030B)(例如，類似於圖5之515、525、540及550)。若是，則處理程序返回至1005B。否則，若設置用於在相關聯流量非作用中計時器已過期之方向上之App*媒體QoS流之QoS，則RAN 120發送ReservationOffMessage以在偵測到過期之方向上撤銷啟動媒體QoS流(1035B)。如應瞭解，可向UE告知關於1035B之QoS流撤銷啟動，此係因為QoS流撤銷啟動係關於空中介面資源(亦即，UE與RAN 120之間的連接)予以實施。

因為經由WebRTC而通訊之端點可由限制各別端點之間的端對端連接之數目之一或多個NAT及/或防火牆分離，所以WebRTC允許經由單一IP位址及埠之RTP串流之多工。部分地歸因於此限制，現有WebRTC規範推薦使用彼多工以用於RTP及RTP控制協定(RTCP)通訊。當多個類型之串流係經由一個IP位址及埠號而多工時，將經微分化服務品質(QoS)提供至不同類型之媒體變得較有挑戰性。

舉例而言，在非WebRTC視訊會議工作階段中，使音訊串流保持與視訊串流分離係典型的，藉以將音訊串流分配給QoS鏈路且將視訊串流分配給非QoS鏈路。此係因為音訊串流通常消耗比視訊串流小的頻寬，且因為視訊串流可受到程序幫助，該等程序諸如，接收器處之錯誤隱藏策略、前向錯誤校正碼之使用、降低視訊解析度，等等。

用於獲得用於WebRTC中之不同媒體類型之QoS微分法的習知途徑為停用瀏覽器自身中之多工。然而，此情形需要對瀏覽器進行修改，且亦假定瀏覽器將能夠建立用於不同媒體類型之多個端對端連接(亦即，相異IP位址及埠號)。

用於獲得用於WebRTC中之不同媒體類型之QoS差異之其他習知途徑應為允許3GPP界定之QoS啟用流量流觸發IP封包差異服務碼點標記(DSCP)標記或允許3GPP界定之QoS啟用流量流觸發RTP同步源(SSRC)。然而，此等習知途徑中每一者在3GPP標準中改變，其作為結果將影響封包濾波及流量流模板。

又另一習知途徑係使瀏覽器自身利用上述UE起始QoS特徵，藉以UE上之瀏覽器將試圖設置至少用於音訊媒體之QoS鏈路及旁路多工。然而，此途徑需要瀏覽器以及WebRTC API兩者之改變以准許待由用於觸發UE起始QoS特徵之應用程式類型來識別流。

本發明之實施例係有關在無需對WebRTC多媒體用戶端應用程式(例如，瀏覽器)及/或對3GPP傳信或網路設計進行修改的情況下獲得用於利用WebRTC之通訊工作階段之QoS差異。在高階處，下文所描述之本發明之實施例向UE供應代理伺服器模組，該代理伺服器模組選擇性地自自WebRTC多媒體用戶端應用程式獲得的經多工RTP串流解多工某些媒體分量，且亦選擇性地將傳入之媒體再多工成由WebRTC多媒體用戶端應用程式預期之經多工格式。

圖11說明用於兩個UE之間的WebRTC工作階段之習知流量流。參看圖11，第一UE 1100(或UE 1)經供應有第一WebRTC多媒體用戶端應用程式1105，諸如，行動瀏覽應用程式。WebRTC多媒體用戶端應用程式1105將媒體(例如，音訊、視訊等等)多工成用於WebRTC工作階段之單一經多工串流(「MUX」)，且接著經由單一IP位址及埠號而將一或多個RTP/RTPC封包內之經多工串流遞送至伺服網路1110(例如，WiFi網路、RAN 120等等)。伺服網路1110使用NAT/防火牆穿越技術以穿通或開放經由NAT/防火牆1115之連接，以便將經多工串流遞送至伺服網路1120。伺服網路1120將經多工串流自UE 1遞送至第二UE 1125(或UE 2)，該第二UE 1125經供應有第二WebRTC多媒體用戶端應用程式1130，諸如，另一行動瀏覽應用程式。如應瞭解，因為第一WebRTC多媒體用戶端應用程式1105藉由預設產生MUX，所以MUX亦將在如下情境中使用：其中UE 1及2兩者係由同一伺服網路伺服使得UE 1與2之間的通訊在不具有NAT/防火牆穿越的情況下係可能的。

圖12A說明根據本發明之一實施例的用於由同一伺服網路伺服之兩個UE之間的WebRTC工作階段之流量流。參看圖12A，第一UE 1200(或UE 1)經供應有第一WebRTC多媒體用戶端應用程式1205(或第一WebRTC端點)，諸如，行動瀏覽應用程式。UE 1亦經供應有第一WebRTC代理伺服器模組1210。如將在下文更詳細地描述，第一WebRTC代理伺服器模組1210經組態以選擇性地自第一WebRTC多媒體用戶端應用程式1205嘗試傳輸之單一經多工串流(「MUX」)解多工媒體之部分，且亦將藉由另一UE上之另一WebRTC代理伺服器模組而解多工的多個傳入之媒體串流「再」多工成單一經多工串流以用於遞送至第一WebRTC多媒體用戶端應用程式1205。

參看圖12A，在一實例中，第一WebRTC多媒體用戶端應用程式1205可以與來自圖11之WebRTC多媒體用戶端應用程式1105相似方式(或甚至相同方式)經組態。換言之，圖12A之實施例並不嚴格地需要對供操作之現有WebRTC多媒體用戶端應用程式之任何改變，且WebRTC端點可繼續「正常地」操作，同時依賴於WebRTC代理伺服器模組1210實施用於利用QoS鏈路之媒體串流之選擇性解多工及/或再多工(若可用)。

因此，第一WebRTC多媒體用戶端應用程式1205將媒體(例如，音訊、視訊等等)多工成用於WebRTC工作階段之單一經多工串流(「MUX」)，且嘗試將一或多個RTP/RTPC封包內之MUX傳輸至伺服網路1110(例如，WiFi網路、RAN 120等等)。然而，在圖12A中，代替將MUX傳輸至伺服網路(如在圖11中)，WebRTC代理伺服器模組1210截獲MUX以供特定處置(亦即，解多工)。

更具體言之，在圖12A中，假定UE 1能夠獲得QoS鏈路(例如，經由如將在下文關於圖13至圖17更詳細地論述之代理伺服器起始、UE起始及/或NW起始之QoS獲取程序)及非QoS鏈路兩者。如本文所使用，術語「非QoS」鏈路可指具有零QoS(或GBR)之任何連接、載送或頻道，或替代地可指具有小於供界定QoS鏈路之QoS臨限值同時仍高於零的QoS(或GBR)之「中間」位準之連接、載送或頻道(藉以QoS鏈路具有大於或等於該臨限值之QoS位準)。

第一WebRTC代理伺服器模組1210應用QoS規則集合以識別已經藉由第一WebRTC多媒體用戶端應用程式1205而多工成經多工串流的較高優先級媒體。表3(下文)提供根據本發明之實施例的可藉由第一WebRTC代理伺服器模組1210強制執行而作為選擇性解多工程序之部分的QoS規則之幾個實例：

關於表3(上文)，應瞭解，某些非音訊資料可基於某些規則而映射至QoS鏈路而非非QoS鏈路，諸如在QoS鏈路上可得到足夠QoS的情況下在靜寂週期或音訊活動週期期間將非音訊資料移動至QoS鏈路，且此等相同規則(在上文之表3中予以概述)亦可用作用於判定哪些媒體類型經解多工以用於在QoS鏈路上而非非QoS鏈路上進行傳輸之QoS規則集合之部分。因此，QoS鏈路上所傳輸之媒體無需嚴格地限於音訊，而是亦可包括某些較高優先級類型之視訊媒體及/或非視訊檔案媒體。

返回轉向至圖12A，若第一WebRTC代理伺服器模組1210基於QoS規則集合而能夠識別存在於經多工串流內之較高優先級媒體，則該第一WebRTC代理伺服器模組1210自較低優先級媒體(例如，大容量視訊媒體等等)解多工(或剝離)較高優先級媒體(例如，音訊媒體及/或有限量之視訊媒體，諸如，視訊控制圖框、I圖框等等)。應瞭解，功能上，亦可自經多工串流剝離(或解多工)較低優先級媒體，只要第一WebRTC代理伺服器模組1210產生包括較高優先級媒體之第一經解多工WebRTC串流(「DE-MUX1」)及包括較低優先級媒體之第二經解多工WebRTC串流(「DE-MUX2」)即可。第一WebRTC代理伺服器模組1210在QoS鏈路上將DE-MUX1傳輸至伺服網路1215，且在非QoS鏈路上將DE-MUX2傳輸至伺服網路1215。

在一另外實施例中，自MUX產生DE-MUX1及DE-MUX2之解多工操作可包括轉碼。若為此狀況，則作為提供/回覆交換之部分(例如，圖14之1435中、圖15之1540中，等等)，由具備WebRTC能力之瀏覽器支援之編碼解碼器(例如，G.711、Opus等等)可由WebRTC代理伺服器模組1210選擇。舉例而言，若需要頻譜效率，則可選擇G.711(其為基本上經壓縮擴展PCM)以用於轉碼頻譜有效率窄頻帶編碼解碼器，諸如AMR-NB。另一方面，若需要頻譜效率及音訊品質兩者，則可選擇寬頻帶Opus編碼解碼器模式中之一者以用於轉碼至AMR-WB。在一實例中，若VoLTE係用以支援WebRTC工作階段，則可藉由預設而選擇Opus以用於VoLTE載送。

參看圖12A，假定第二UE 1225(或UE 2)經供應有第二WebRTC多媒體用戶端應用程式1230(或第二WebRTC端點)及第二WebRTC代理伺服器模組1235，該第二WebRTC多媒體用戶端應用程式1230及該第二WebRTC代理伺服器模組1235可各自以與UE 1上之第一WebRTC多媒體用戶端應用程式1205及第一WebRTC代理伺服器模組1210相似的方式(或甚至相同的方式)予以組態。進一步假定類似於UE 1，UE 2能夠獲得QoS鏈路(例如，經由如將在下文關於圖13至圖17更詳細地論述之UE起始或NW起始之QoS獲取程序)及非QoS鏈路兩者。

在圖12A之實施例中，UE 1及UE 2兩者係藉由同一伺服網路1215伺服，使得DE-MUX1及DE-MUX2無需穿越NAT/防火牆1220。取而代之，伺服網路1215在UE 2之QoS鏈路上將DE-MUX1傳輸至UE 2，且在UE 2之非QoS鏈路上將DE-MUX2傳輸至UE 2。第二WebRTC代理伺服器模組1210接收DE-MUX1及DE-MUX2，且接著「再」多工DE-MUX1及DE-MUX2以重新建構或重新構成經多工串流(「MUX」)，該經多工串流最初係藉由第一WebRTC多媒體用戶端應用程式1205提供至第一WebRTC代理伺服器模組1210。換言之，第二WebRTC代理伺服器模組1235反轉藉由第一WebRTC代理伺服器模組1210執行之解多工程序以便重新建構MUX。第二WebRTC代理伺服器模組1235接著將經重新建構(或經再多工)MUX提供至WebRTC多媒體用戶端應用程式1230。

如由一般熟習此項技術者應瞭解，QoS係用以部分地傳送用於圖12A中之WebRTC工作階段之媒體(例如，音訊媒體、較高優先級視訊媒體，等等)之部分，此係因為UE 1及2兩者皆由同一伺服網路1215伺服且可獲得端對端QoS。此情形在圖11中係不可能的，此係因為WebRTC多媒體用戶端應用程式通常將預設至交換MUX，而不設置用於MUX內之經多工媒體之任何部分之QoS。

圖12B說明根據本發明之一實施例的用於由不同伺服網路伺服之兩個UE之間的WebRTC工作階段之流量流。圖12B類似於圖12A，惟圖12A中之單一伺服網路1215係用兩個相異伺服網路1215A及1215B替換除外，該兩個相異伺服網路1215A及1215B分別伺服UE 1及UE 2且係由NAT/防火牆1220分離。

在圖12B中，因為伺服網路1215A不伺服UE 2，所以伺服網路1215A並不將DE-MUX1及/或DE-MUX2直接傳輸至UE 2。取而代之，伺服網路1215A使用NAT/防火牆穿越技術以穿通或開放經由NAT/防火牆1220之至少一連接，以便將DE-MUX1及DE-MUX2遞送至伺服網路1215B。在一實例中，伺服網路1215A可將DE-MUX1及DE-MUX2集束成單一串流，使得單一IP位址及埠號可用以將DE-MUX1及DE-MUX2兩者傳遞至伺服網路1215B，藉以伺服網路1215B接著解集束該單一串流以重新構成DE-MUX1及DE-MUX2。或者，伺服網路1215A可僅僅使用兩個相異IP位址及埠號以用於DE-MUX1及DE-MUX2。在任何狀況下，即使在自伺服網路1215A至伺服網路1215B之集群上不可得到QoS，亦可至少在伺服網路內獲得QoS使得端對端WebRTC媒體傳送之一部分被分配QoS。

伺服網路1215B在UE 2之QoS鏈路上將DE-MUX1傳輸至UE 2，且在UE 2之非QoS鏈路上將DE-MUX2傳輸至UE 2。第二WebRTC代理伺服器模組1210接收DE-MUX1及DE-MUX2，且接著「再」多工DE-MUX1及DE-MUX2以重新建構或重新構成經多工串流(「MUX」)，該經多工串流最初係藉由第一WebRTC多媒體用戶端應用程式1205提供至第一WebRTC代理伺服器模組1210。換言之，第二WebRTC代理伺服器模組1235反轉藉由第一WebRTC代理伺服器模組1210執行之解多工程序以便重新建構MUX(例如，MUX之原始版本或MUX之不同版本，諸如，MUX之經壓縮或經縮減解析度版本(其包括來自原始MUX 之媒體分量中之一些或全部之壓縮版本)，等等)。第二WebRTC代理伺服器模組1235接著將經重新建構(或經再多工)MUX提供至WebRTC多媒體用戶端應用程式1230。

關於圖12A至圖12B之WebRTC串流所描述之解多工及再多工操作係基於UE 1及2能夠獲得QoS鏈路以攜載較高優先級經解多工WebRTC流或DE-MUX1而進行。在圖12A至圖12B中，僅僅假定QoS鏈路可用，但通常WebRTC多媒體用戶端應用程式不試圖獲取用於MUX之QoS，此係部分因為MUX包括通常將不接收QoS之成份(諸如，大容量視訊內容)且亦因為WebRTC多媒體用戶端應用程式甚至未必具有用以識別其各別UE處可得到之QoS資源之能力。

牢記此，圖13至圖17說明根據本發明之實施例的結合上文所描述之解多工及/或再多工操作而針對WebRTC工作階段選擇性建立QoS的處理程序。詳言之，圖13說明根據本發明之一實施例的針對WebRTC工作階段設置QoS鏈路，接著在WebRTC工作階段中在源UE處進行解多工的高階處理程序。

關於圖13，傳信在供應於給定UE處之WebRTC多媒體用戶端應用程式(例如，來自圖12A或圖12B之第一WebRTC多媒體用戶端應用程式1205或第二WebRTC多媒體用戶端應用程式1230)、供應於給定UE處之WebRTC代理伺服器模組、伺服給定UE之RAN 120、核心網路140及/或應用程式伺服器170之間交換，該傳信指示涉及給定UE之WebRTC工作階段之起始或潛在起始(1300)。基於來自1300之傳信，給定UE上之WebRTC代理伺服器模組、RAN 120、核心網路140及/或應用程式伺服器170起始QoS設置程序以用於分別在1305、1310、1315或1320處將QoS鏈路分配至給定UE。

在一實例中，在1300中，WebRTC工作階段可由給定UE發起，在此狀況下，1300之傳信在1305處可包括用於UE起始之QoS的由 WebRTC多媒體用戶端應用程式產生且由WebRTC代理伺服器模組截獲之工作階段起始訊息。在此狀況下，1305稍微類似於上文關於圖5至圖6C所描述的UE起始之QoS程序，且在下文中特定地關於圖14中之WebRTC解多工實施而更詳細地加以描述。或者，可在WebRTC工作階段係由不同UE發起之情境中實施1305的UE起始之QoS程序。在此狀況下，用於WebRTC工作階段之工作階段通知訊息及/或由WebRTC多媒體用戶端應用程式傳輸之工作階段接受訊息可由給定UE處之WebRTC代理伺服器模組使用以用於觸發UE起始之QoS程序。

在另一實例中，1305未必被實施為UE起始之QoS程序，藉此給定UE觸發RAN 120及/或核心網路140代表其自身設置QoS。取而代之，在另一LTE特定實施例中，WebRTC代理伺服器模組可改為在另一端點係VoLTE相容及/或正執行其自有WebRTC代理伺服器模組時協商端對端VoLTE連接。以此方式建立端對端VoLTE連接限定用於WebRTC之QoS載送協商之靈活性，而且消除實施UE起始及/或NW起始之QoS程序之需要。如本文所使用，用於QoS設置之端對端VoLTE實施被稱作「代理伺服器起始之」QoS程序。

在另一實例中，在1300中，WebRTC工作階段可由給定UE發起，在此狀況下，1300之傳信可包括由WebRTC多媒體用戶端應用程式產生且由WebRTC代理伺服器模組截獲之工作階段起始訊息。WebRTC代理伺服器模組接著將訊息發送至應用程式伺服器170以增進應用程式伺服器170在1320處實施NW起始之QoS程序，其引起將QoS鏈路分配至給定UE。在此狀況下，1320稍微類似於上文關於圖7A至圖7C所描述之以伺服器為基礎之NW起始之QoS程序，且在下文中特定關於圖15中之WebRTC解多工實施更詳細地予以描述。或者，可在WebRTC工作階段係由不同UE發起之情境中實施1320之以伺服器為基礎之NW起始之QoS程序。在此狀況下，用於WebRTC工作階段之工作階段通知訊息及/或由WebRTC多媒體用戶端應用程式傳輸之工作階段接受訊息可由給定UE處之WebRTC代理伺服器模組使用以用於將訊息觸發至應用程式伺服器170，此情形增進應用程式伺服器170開始以伺服器為基礎之NW起始之QoS程序。

在另一實例中，在1300中，不管給定UE是否為WebRTC工作階段之發起者，RAN 120及/或核心網路140皆可評估應用程式識別資訊及/或可執行深封包檢測以用於在1310及/或1315處觸發NW起始之QoS程序。舉例而言，WebRTC工作階段可被解譯為觸發RAN 120及/或核心網路處之QoS設置之App*工作階段，如上文關於圖8A至圖10B所描述。在另一實例中，可經由深封包檢測藉由RAN 120及/或核心網路140來檢測WebRTC流量中任一者。在此狀況下，若RAN 120及/或核心網路140將工作階段識別為涉及WebRTC，則RAN 120及/或核心網路140可觸發NW起始之QoS程序以用於將QoS鏈路分配至給定UE。1310及1315之態樣稍微類似於上文關於圖8A至圖10B所描述之NW起始之QoS程序，且在下文中特定關於圖16中之WebRTC解多工實施更詳細地予以描述。

因此，在實施1305、1310、1315及/或1320之後，將QoS鏈路及非QoS鏈路兩者分配至給定UE。WebRTC多媒體用戶端應用程式獲得不同類型(例如，音訊、視訊等等)之媒體以供在WebRTC工作階段期間進行傳輸(1330)，且WebRTC多媒體用戶端應用程式將不同類型之媒體多工成多工串流(「MUX」)(1335)。雖然試圖傳輸MUX，但取而代之，MUX係由給定UE上之WebRTC代理伺服器模組截獲(1340)。WebRTC代理伺服器模組執行上文所描述之QoS規則集合以識別在MUX內所含有之較高優先級媒體(例如，音訊媒體、有限量視訊媒體，等等)(1345)。WebRTC代理伺服器模組接著解多工在1345處所識別之較高優先級媒體以產生包括較高優先級媒體之第一經解多工 WebRTC串流(「DE-MUX1」)及包括任何剩餘較低優先級媒體之第二經解多工WebRTC串流(「DE-MUX2」)(1350)。WebRTC代理伺服器模組經由QoS鏈路將DE-MUX1傳輸至RAN 120(1355)，且WebRTC代理伺服器模組亦在非QoS鏈路上將DE-MUX2傳輸至RAN 120(1360)。雖然未在圖13中明確地展示，但DE-MUX1及DE-MUX2可接著被傳達至如圖12A至圖12B中之目標UE(圖13中未圖示)且亦在下文中關於圖17更詳細地予以描述。

參看圖14，當給定UE上之WebRTC網頁瀏覽應用程式(「瀏覽器」)發送呼叫起始訊息(該呼叫起始訊息係由WebRTC代理伺服器模組截獲)(1405)時，給定UE係處於RRC閒置狀態中(1400)。呼叫起始訊息之接收觸發WebRTC代理伺服器模組將專屬訊息發送至應用程式伺服器170以請求應用程式伺服器170觸發NW-起始之QoS程序(1410)。回應於專屬訊息，應用程式伺服器170經由至P-GW 235D及PCRF 240D之Rx連接而起始載送協商(1415)。

返回轉向至給定UE，呼叫起始訊息之接收亦觸發給定UE執行RRC設置程序以用於將給定UE自RRC閒置狀態轉變至RRC已連接狀態(1420)。當RRC設置在1420處完成時，使得給定UE進入RRC已連接狀態(1425)，且WebRTC代理伺服器模組將連接指示遞送至瀏覽器(1430)。就此而言，給定UE具有非GBR載送(亦即，非QoS鏈路)，但仍未具有QoS鏈路，此係因為載送協商尚未完成(1432)。瀏覽器及WebRTC代理伺服器模組執行提供/回覆交換(1435)(例如，藉以WebRTC代理伺服器模組可選擇待用於DE-MUX1及/或DE-MUX2之轉碼編碼解碼器)，在此之後瀏覽器開始組態媒體以供在WebRTC工作階段期間進行傳輸(1440)。

返回轉向至網路，P-GW 235D將更新載送請求發送至MME 215D(1445)，MME 215D將載送修改請求發送至eNB 205D(1450)，其增進eNB 205D及給定UE重新組態RRC連接(1455)(例如，RRC連接重新組態/完成)。eNB 205D接著將載送修改回應傳輸回至MME 215D，且MME 215D將更新載送回應傳輸回至P-GW 235D。雖然以不同方式觸發，但1445至1465稍微類似於圖7C之725C至750C。又，若WebRTC工作階段為App*工作階段，則經建立用於GBR載送之GBR可如圖7C之735C一樣以特定用於App*(或在此狀況下，WebRTC)之QoS組態來組態。

在經由1445至1465之傳信獲得GBR載送(或QoS鏈路)之後，瀏覽器開始將MUX(例如，具有供傳輸之經多工媒體分量之RTP/RTCP封包串流)發送至WebRTC代理伺服器模組(1470)，該WebRTC代理伺服器模組解多工MUX以產生DE-MUX1及DE-MUX2且接著在GBR載送上傳輸DE-MUX1(1475)，且在非GBR載送上傳輸DE-MUX2(1480)。

圖15說明根據本發明之一實施例的基於UE起始之QoS程序之圖13之處理程序的LTE特定實施。

參看圖15，當給定UE上之WebRTC網頁瀏覽應用程式(「瀏覽器」)發送呼叫起始訊息(該呼叫起始訊息係由WebRTC代理伺服器模組截獲)(1505)時，給定UE係處於RRC閒置狀態中(1500)。呼叫起始訊息觸發給定UE以執行RRC設置程序以用於將給定UE自RRC閒置狀態轉變至RRC已連接狀態(1510)。當RRC設置在1510處完成時，給定UE進入RRC已連接狀態(1515)，且WebRTC代理伺服器模組將連接指示遞送至瀏覽器(1520)。就此而言，給定UE具有非GBR載送(亦即，非QoS鏈路)，但仍未具有QoS鏈路，此係因為載送協商尚未完成(1525)。

在圖15之實施例中，WebRTC代理伺服器模組判定執行UE起始之QoS程序以獲得QoS鏈路。在一實例中，若如圖14中之NW起始之QoS程序未能獲得QoS鏈路，則UE起始之QoS程序可用作後饋機制。舉例而言，雖然圖15中未圖示，但WebRTC代理伺服器模組可發送專屬訊息(如在圖14之1410中)且接著起動計時器，且若在計時器之過期之前未獲得QoS鏈路，則WebRTC代理伺服器模組可接著執行UE起始之QoS程序。或者，WebRTC代理伺服器模組可自動判定執行UE起始之QoS程序，而不等待基於工作階段類型為WebRTC而首先嘗試NW起始之QoS程序。

在任何狀況下，不管WebRTC代理伺服器模組如何達成實施UE起始之QoS程序之決策，皆藉由將請求載送資源修改訊息自給定UE經由eNB 205D傳輸至MME 215D來實施UE起始之QoS程序(1530)。1530之請求載送資源修改訊息經組態以請求GBR載送用於WebRTC工作階段之音訊媒體分量(例如，且潛在地亦用於其他媒體分量，諸如，有限量視訊媒體及/或檔案內容)。MME 215D接收請求載送資源修改訊息且經由S-GW 230D而將載送資源命令遞送至P-GW 235D(1535)。就此而言，1540至1585實質上分別對應於圖14之1435至1480，惟1540至1585係由由給定UE遞送至LTE核心網路140之訊息觸發，而1435至1480係由由應用程式伺服器170遞送至LTE核心網路140之訊息觸發除外。

圖16說明根據本發明之一實施例的基於另一NW起始QoS程序之圖13之處理程序之一部分的實例實施。參看圖16，基於圖13之1300處交換之傳信，RAN 120及/或核心網路140觸發用於給定UE之QoS鏈路之設置，而不具有自應用程式伺服器170(如在圖14中)或給定UE自身(如在圖15中)提供的進行此之顯式請求。取而代之，RAN 120及/或核心網路140評估傳信自身以偵測RAN 120及/或核心網路140是否應代表給定UE搶先設置QoS鏈路(1600)(例如，類似於圖13之1310及/或1315)。

詳言之，RAN 120及/或核心網路140可識別出所建立之工作階段為WebRTC，則此識別可增進RAN 120及/或核心網路140觸發NW起始之QoS程序。可以數個方式執行工作階段之識別為WebRTC工作階段。舉例而言，WebRTC應用程式可對應於上文詳細地描述之App*，使得可基於應用程式-識別資訊(例如，APN等等)來識別工作階段之WebRTC性質。在另一實例中，RAN 120及/或核心網路140可對在WebRTC工作階段之設置期間交換之一或多個傳信封包執行深封包檢測，且深封包檢測可用以推斷出工作階段為WebRTC工作階段。1600處所評估之傳信可與上行鏈路及/或下行鏈路傳信流量相關聯。

雖然圖13聚焦於在WebRTC工作階段中之源UE處發生之解多工，但圖17係有關針對WebRTC工作階段設置QoS鏈路，接著是工作階段中之目標UE處之再多工之高階處理程序。當然，WebRTC中之UE可為用於雙向媒體工作階段之源UE及目標UE兩者，使得圖13及圖17之處理程序可在源UE及目標UE兩者處並行地實施。

參看圖17，1700至1725對應於1300至1325，且出於簡潔起見將不對其進行進一步描述。在1725之後，核心網路140自另一UE(例如，由與圖12A中相同的核心網路140伺服或與圖12B中不同的伺服網路伺服)獲得DE-MUX1及DE-MUX2。在1730處，核心網路140經由RAN 120在QoS鏈路上將DE-MUX1傳輸至給定UE且在非QoS鏈路上將DE-MUX2傳輸至給定UE(1730)。WebRTC代理伺服器模組截獲DE-MUX1及DE-MUX2之後將其遞送至WebRTC多媒體用戶端應用程式(1735)，且WebRTC代理伺服器模組再多工DE-MUX1及DE-MUX2以重新建構MUX(1740)。換言之，如上文所描述，WebRTC代理伺服器模組藉由反轉藉由另一UE上之WebRTC代理伺服器模組執行之解多工以重新獲得如由另一UE上之WebRTC多媒體用戶端應用程式最初製備之MUX來重新建構MUX。WebRTC代理伺服器模組接著將MUX遞送至給定UE上之WebRTC多媒體用戶端應用程式(1745)。

另外，雖然圖14至圖16描述關於如何針對「解」多工內容脈絡中之給定UE建立QoS鏈路的圖13之處理程序的詳細實施，但應瞭解，此等相同QoS設置程序可用於關於「再」多工內容脈絡之圖17之內容脈絡中。換言之，1700至1725之間所建立之QoS鏈路可經由以伺服器為基礎之NW起始之QoS程序予以設置(如圖14中)，經由UE起始QoS程序予以設置(如圖15中)，及/或藉由獨立於以伺服器為基礎之觸發之NW起始QoS程序予以設置(如圖16中)。又，如上文所提及，同一UE可並行地執行圖13及圖17兩者之處理程序，使得提供於給定UE處之WebRTC代理伺服器模組可負責負責多工傳出之MUX(如圖13中)，同時亦再多工傳入之經解多工串流以便自另一UE重新建構傳入之MUX(如圖17中)。

另外，雖然圖12A至圖17之實施例涉及「原始」或「源」MUX及「經再多工」或「經重新建構」MUX，但應瞭解，MUX之原始及重建構版本可相同地或替代地稍微不同(例如，經重新建構MUX可經壓縮以便相比於原始MUX歸因於轉碼或其他因素具有用於某些媒體分量之較低解析度，等等)。

另外，雖然圖12A至圖17之實施例通常涉及兩個(2個)經解多工串流(亦即，DE-MUX1及DE-MUX2)，但應瞭解，其他實施例可有關三個(3個)或多個三個經解多工串流(例如，DE-MUX3、DE-MUX4等等)，此取決於可用QoS及/或非QoS鏈路之數目。舉例而言，若UE存取具有高QoS之第一QoS鏈路、具有低QoS之第二QoS鏈路及非QoS鏈路，則WebRTC代理伺服器模組可產生具有高優先級媒體之DE-MUX1、具有中間優先級媒體之DE-MUX2及具有低優先級媒體之DE- MUX3。WebRTC代理伺服器模組可接著在第一QoS鏈路上發送DE-MUX1，在第二QoS鏈路上發送DE-MUX2且在非QoS鏈路上發送DE-MUX3，等等。

在另一實例中，QoS鏈路可對應於第一鏈路集合，且非QoS鏈路可對應於第二鏈路集合。第一鏈路集合可包括一或多個QoS鏈路，且第二鏈路集合可包括一或多個非QoS鏈路。第一鏈路集合中之每一鏈路可攜載DE-MUX串流，且第二鏈路集合中之每一鏈路亦可攜載DE-MUX串流。通常，較高優先級媒體係經由第一鏈路集合上之DE-MUX串流予以傳輸，而較低優先級媒體係經由第二鏈路集合上之DE-MUX串流予以傳輸。因此，在UE存取多個QoS鏈路及/或多個非QoS鏈路之情境下，UE可利用此等多個鏈路以發送多個DE-MUX串流(或冗餘地發送甚至同一DE-MUX串流)。藉此，當額外鏈路(QoS及/或非QoS)可用時，實施例不限於在QoS鏈路上所發送之單一DE-MUX串流及非QoS鏈路上所發送之單一DE-串流。詳言之，可攜載關於前述「額外」DE-MUX串流中任一者的來自MUX之額外經解多工媒體分量。同樣地，在目標UE處，「額外」DE-MUX串流中任一者可連同DE-MUX1及DE-MUX2予以再多工以重新建構MUX。

在本發明之另一實施例中，有可能不多工或待部分多工瀏覽器起始之多媒體流量。換言之，來自WebRTC多媒體用戶端應用程式之輸出無需為MUX，而是可為非MUX1及非MUX2(亦即，兩個未經多工RTP串流)MUX1及MUX2(例如，兩個經部分多工RTP串流)，或非MUX1及MUX1(例如，未經多工RTP串流及經多工RTP串流)。在此等狀況下，WebRTC代理伺服器模組仍可處置各別RTP串流至非QoS及QoS鏈路之映射。作為一實例，假定多方視訊呼叫，其中瀏覽器經由一個RTP串流發送/接收音訊流量，且亦經由另一RTP串流發送/接收多個視訊軌跡(其中視訊軌跡將對呼叫中之每一參與者係唯一的)。 WebRTC代理伺服器模組可感知UE存取QoS及非QoS鏈路兩者，但瀏覽器(或WebRTC多媒體用戶端應用程式)未必具有偵測此資訊之能力。因此，WebRTC多媒體用戶端應用程式可為在WebRTC代理伺服器模組(代替執行解多工操作)僅僅將各別RTP串流映射至適當鏈路(亦即，QoS鏈路或非鏈路)時無需解多工之RTP串流。

雖然上述實施例主要已參考CDMA2000網路中之1x EV-DO架構、W-雖然上述實施例主要已參考CDMA2000網路中之1x EV-DO架構、W-CDMA或UMTS網路中之GPRS架構及/或以LTE為基礎之網路中之EPS架構予以描述，但應瞭解，其他實施例可有關其他類型之網路架構及/或協定。

熟習此項技術者應理解，可使用多種不同技藝與技術中任一者來表示資訊與信號。舉例而言，可由電壓、電流、電磁波、磁場或磁粒子、光場或光粒子或其任何組合表示遍及以上描述可能參考的資料、指令、命令、資訊、信號、位元、符號及碼片。

另外，熟習此項技術者應瞭解，結合本文所揭示之實施例所描述的各種說明性邏輯區塊、模組、電路及演算法步驟可被實施為電子硬體、電腦軟體或兩者之組合。為了清楚地說明硬體與軟體之此可互換性，各種說明性組件、區塊、模組、電路及步驟已在上文大體按其功能性加以描述。將此功能性是實施為硬體抑或軟體取決於特定應用及強加於整個系統之設計約束。熟習此項技術者可針對每一特定應用以變化之方式實施所描述功能性，但此等實施決策不應被解譯為造成對本發明之範疇的脫離。

可藉由通用處理器、數位信號處理器(DSP)、特殊應用積體電路(ASIC)、場可程式化閘陣列(FPGA)或經設計以執行本文中所描述之功能之其他可程式邏輯器件、離散閘或電晶體邏輯、離散硬體組件或其任何組合來實施或執行結合本文所揭示之實施例所描述的各種說明性邏輯區塊、模組及電路。通用處理器可為微處理器，但在替代例中，處理器可為任何習知處理器、控制器、微控制器或狀態機。處理器亦可被實施為計算器件之組合，例如，一DSP與一微處理器之組合、複數個微處理器、結合DSP核心之一或多個微處理器，或任何其他此組態。

結合本文所揭示之實施例而描述之方法、序列及/或演算法可直接以硬體、以由處理器執行之軟體模組或以其兩者之組合體現。軟體模組可駐留於RAM記憶體、快閃記憶體、ROM記憶體、EPROM記憶體、EEPROM記憶體、暫存器、硬碟、抽取式磁碟、CD-ROM，或此項技術中已知之任何其他形式之儲存媒體中。例示性儲存媒體耦接至處理器，使得處理器可自儲存媒體讀取資訊並將資訊寫入至儲存媒體。在替代例中，儲存媒體可與處理器成一體式。處理器及儲存媒體可駐留於ASIC中。ASIC可駐留於使用者終端機(例如，UE)中。在替代例中，處理器及儲存媒體可作為離散組件駐留於使用者終端機中。

在一或多個例示性實施例中，可以硬體、軟體、韌體或其任何組合來實施所描述之功能。若以軟體實施，則該等功能可作為一或多個指令或程式碼而儲存於電腦可讀媒體上或經由該電腦可讀媒體而傳輸。電腦可讀媒體包括電腦儲存媒體及通訊媒體兩者，通訊媒體包括促進電腦程式自一處傳送至另一處之任何媒體。儲存媒體可為可由電腦存取之任何可用媒體。借助於實例而非限制，此等電腦可讀媒體可包含RAM、ROM、EEPROM、CD-ROM或其他光碟儲存器、磁碟儲存器或其他磁性儲存器件，或可用以攜載或儲存呈指令或資料結構之形式之所要程式碼且可由電腦存取的任何其他媒體。又，任何連接被適當地稱為電腦可讀媒體。舉例而言，若使用同軸電纜、光纖纜線、雙絞線、數位用戶線(DSL)或諸如紅外線、無線電及微波之無線技術而自網站、伺服器或其他遠端源傳輸軟體，則同軸電纜、光纖纜線、雙絞線、DSL或諸如紅外線、無線電及微波之無線技術包括於媒體之定義中。如本文所使用之磁碟及光碟包括緊密光碟(CD)、雷射光碟、光學光碟、數位多功能光碟(DVD)、軟碟及blu-ray光碟，其中磁碟通常以磁性方式再生資料，而光碟用雷射以光學方式再生資料。以上各者之組合亦應包括於電腦可讀媒體之範疇內。

雖然前述揭示內容展示本發明之說明性實施例，但應注意，可在不脫離如由附加申請專利範圍所界定之本發明之範疇的情況下，在本文中作出各種改變及修改。無需以任何特定次序執行根據本文中所描述之本發明之實施例的方法項之功能、步驟及/或動作。此外，儘管可以單數形式描述或主張本發明之元件，但除非明確地陳述對單數形式之限制，否則亦預期複數形式。

Claims

一種操作一使用者設備(UE)處之參加一網頁即時通訊(WebRTC)工作階段之一WebRTC代理伺服器模組之方法，其包含：獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；在該WebRTC工作階段期間，自一WebRTC多媒體用戶端應用程式獲得該WebRTC多媒體用戶端應用程式試圖遞送至一目標UE上之一目標WebRTC多媒體用戶端應用程式之一經多工串流，該經多工串流包括至少一第一媒體分量及一第二媒體分量；解多工該經多工串流以產生包括該第一媒體分量之一第一經解多工串流及包括該第二媒體分量之一第二經解多工串流；在來自該第一鏈路集合之一第一鏈路上將該第一經解多工串流傳輸至一伺服網路以供遞送至該目標UE；及在來自該第二鏈路集合之一第二鏈路上將該第二經解多工串流傳輸至該伺服網路以供遞送至該目標UE。
如請求項1之方法，其中該第二鏈路集合中之每一鏈路經分配零QoS或大於零QoS且小於該臨限位準之QoS的一中間位準之QoS。
如請求項2之方法，其中該第二鏈路集合中之至少一個鏈路經分配零QoS。
如請求項2之方法，其中該第二鏈路集合中之至少一個鏈路經分配該中間位準之QoS。
如請求項2之方法，其中該臨限位準之QoS包括用於該第一鏈路集合中之每一鏈路之至少一給定保證位元速率(GBR)，其中該第二鏈路集合中之每一鏈路具有零GBR及/或低於該給定GBR之一GBR。
如請求項1之方法，其中該第一鏈路集合僅包括該第一鏈路且該第二鏈路集合僅包括該第二鏈路。
如請求項1之方法，其中該第一鏈路集合包括該第一鏈路及至少一個額外鏈路，其中該第二鏈路集合僅包括該第二鏈路，其中該經多工串流進一步包括至少一個額外媒體分量，且該解多工進一步解多工該經多工串流以產生包括該至少一個額外媒體分量之至少一個額外經解多工串流，該方法進一步包含：在來自該第一鏈路集合之該至少一個額外鏈路上將該至少一個額外經解多工串流傳輸至該伺服網路以供遞送至該目標UE。
如請求項1之方法，其中該第二鏈路集合包括該第二鏈路及至少一個額外鏈路，其中該第一鏈路集合僅包括該第一鏈路，其中該經多工串流進一步包括至少一個額外媒體分量，且該解多工進一步解多工該經多工串流以產生包括該至少一個額外媒體分量之至少一個額外經解多工串流，該方法進一步包含：在來自該第二鏈路集合之該至少一個額外鏈路上將該至少一個額外經解多工串流傳輸至該伺服網路以供遞送至該目標UE。
如請求項1之方法，其中該第一鏈路集合包括該第一鏈路及至少一個額外鏈路，其中該第二鏈路集合包括該第二鏈路及一或多個額外鏈路，其中該經多工串流進一步包括至少一個額外媒體分量，且該解多工進一步解多工該經多工串流以產生包括該至少一個額外媒體分量之至少一個額外經解多工串流，其中該經多工串流進一步包括一或多個額外媒體分量，且該解多工進一步解多工該經多工串流以產生包括該一或多個額外媒體分量之一或多個額外經解多工串流，該方法進一步包含：在來自該第一鏈路集合之該至少一個額外鏈路上將該至少一個額外經解多工串流傳輸至該伺服網路以供遞送至該目標UE；及在來自該第二鏈路集合之該一或多個額外鏈路上將該一或多個額外經解多工串流傳輸至該伺服網路以供遞送至該目標UE。
如請求項1之方法，其中該第一媒體分量包括用於該WebRTC工作階段之音訊媒體，且該第二媒體分量包括用於該WebRTC工作階段之視訊媒體。
如請求項1之方法，其中該第一媒體分量包括用於該WebRTC工作階段之音訊媒體及較高優先級視訊媒體，且該第二媒體分量包括用於該WebRTC工作階段之較低優先級視訊媒體。
如請求項1之方法，其中該UE及該目標UE各自係由該伺服網路伺服，且其中該UE與該目標UE之間的一端對端連接基於該UE及該目標UE各自由該伺服網路伺服而不穿越網路間網路位址轉譯(NAT)及/或一網路間防火牆。
如請求項1之方法，其中該目標UE係由不同於伺服該UE之該伺服網路的另一伺服網路伺服，且其中該UE與該目標UE之間的一端對端連接基於該UE及該目標UE係由不同伺服網路伺服而穿越網路間網路位址轉譯(NAT)及/或一網路間防火牆。
一種操作一使用者設備(UE)處之參加一網頁即時通訊(WebRTC) 工作階段之一WebRTC代理伺服器模組之方法，其包含：獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；在該WebRTC工作階段期間，在來自該第一鏈路集合之一第一鏈路上自一伺服網路接收一第一串流且在來自該第二鏈路集合之一第二鏈路上自該伺服網路接收一第二串流，該第一串流及該第二串流包括一源UE處之一源WebRTC多媒體用戶端應用程式試圖遞送至該UE上之一WebRTC多媒體用戶端應用程式的一經多工串流之經解多工部分；再多工該第一串流及該第二串流以產生該經多工串流之一重建構版本；及將該經再多工串流遞送至該WebRTC多媒體用戶端應用程式。
如請求項14之方法，其中該第二鏈路集合中之每一鏈路經分配零QoS或大於零QoS且小於該臨限位準之QoS的一中間位準之QoS。
如請求項15之方法，其中該第二鏈路集合中之至少一個鏈路經分配零QoS。
如請求項15之方法，其中該第二鏈路集合中之至少一個鏈路經分配該中間位準之QoS。
如請求項15之方法，其中該臨限位準之QoS包括用於該第一鏈路集合中之每一鏈路之至少一給定保證位元速率(GBR)，其中該第二鏈路集合中之每一鏈路具有零GBR及/或低於該給定GBR之一GBR。
如請求項14之方法，其中該第一鏈路集合僅包括該第一鏈路且該第二鏈路集合僅包括該第二鏈路。
如請求項14之方法，其中該第一鏈路集合包括該第一鏈路及至少一個額外鏈路，其中該第二鏈路集合僅包括該第二鏈路，該方法進一步包含：在該至少一個額外鏈路上自該伺服網路接收至少一個額外串流，該至少一個額外串流包括來自該經多工串流之至少一個額外經解多工部分，其中該再多工對該至少一個額外串流連同該第一串流及該第二串流再多工以產生該經多工串流之該重建構版本。
如請求項14之方法，其中該第二鏈路集合包括該第二鏈路及至少一個額外鏈路，其中該第一鏈路集合僅包括該第二鏈路，該方法進一步包含：在該至少一個額外鏈路上自該伺服網路接收至少一個額外串流，該至少一個額外串流包括來自該經多工串流之至少一個額外經解多工部分，其中該再多工對該至少一個額外串流連同該第一串流及該第二串流再多工以產生該經多工串流之該重建構版本。
如請求項14之方法，其中該第一鏈路集合包括該第一鏈路及至少一個額外鏈路，其中該第二鏈路集合包括該第二鏈路及一或多個額外鏈路，該方法進一步包含：在該至少一個額外鏈路上自該伺服網路接收至少一個額外串流，該至少一個額外串流包括來自該經多工串流之至少一個額外經解多工部分；及在該一或多個額外鏈路上自該伺服網路接收一或多個額外串流，該一或多個額外串流包括來自該經多工串流之一或多個額外經解多工部分，其中該再多工對該至少一個額外串流及該一或多個額外串流連同該第一串流及該第二串流再多工以產生該經多工串流之該重建構版本。
如請求項14之方法，其中該第一串流包括用於該WebRTC工作階段之音訊媒體，且該第二串流包括用於該WebRTC工作階段之視訊媒體。
如請求項14之方法，其中該第一串流包括用於該WebRTC工作階段之音訊媒體及較高優先級視訊媒體，且該第二串流包括用於該WebRTC工作階段之較低優先級視訊媒體。
如請求項14之方法，其中該UE及該源UE各自係由該伺服網路伺服，且其中該UE與該源UE之間的一端對端連接基於該UE及該源UE各自由該伺服網路伺服而不穿越網路間網路位址轉譯(NAT)及/或一網路間防火牆。
如請求項14之方法，其中該源UE係由不同於伺服該UE之該伺服網路的另一伺服網路伺服，且其中該UE與該源UE之間的一端對端連接基於該UE及該源UE係由不同伺服網路伺服而穿越網路間網路位址轉譯(NAT)及/或一網路間防火牆。
如請求項14之方法，其中該經多工串流之該重建構版本相同於藉由該源WebRTC多媒體用戶端應用程式產生之該經多工串流。
如請求項14之方法，其中該經多工串流之該重建構版本係修改自藉由該源WebRTC多媒體用戶端應用程式產生之該經多工串流。
如請求項28之方法，其中該重建構版本經壓縮及/或相對於由該源WebRTC多媒體用戶端應用程式產生之該經多工串流以一較低解析度來組態。
一種經組態以執行參加一網頁即時通訊(WebRTC)工作階段之一WebRTC代理伺服器模組之使用者設備(UE)，其包含：用於獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合之構件，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；用於在該WebRTC工作階段期間，自一WebRTC多媒體用戶端應用程式獲得該WebRTC多媒體用戶端應用程式試圖遞送至一目標UE上之一目標WebRTC多媒體用戶端應用程式之一經多工串流之構件，該經多工串流包括至少一第一媒體分量及一第二媒體分量；用於解多工該經多工串流以產生包括該第一媒體分量之一第一經解多工串流及包括該第二媒體分量之一第二經解多工串流之構件；用於在來自該第一鏈路集合之一第一鏈路上將該第一經解多工串流傳輸至一伺服網路以供遞送至該目標UE之構件；及用於在來自該第二鏈路集合之一第二鏈路上將該第二經解多工串流傳輸至該伺服網路以供遞送至該目標UE之構件。
一種經組態以執行參加一網頁即時通訊(WebRTC)工作階段之一WebRTC代理伺服器模組之使用者設備(UE)，其包含：用於獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合之構件，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；用於在該WebRTC工作階段期間，在來自該第一鏈路集合之一第一鏈路上自一伺服網路接收一第一串流且在來自該第二鏈路集合之一第二鏈路上自該伺服網路接收一第二串流之構件，該第一串流及該第二串流包括一源UE處之一源WebRTC多媒體用戶端應用程式試圖遞送至該UE上之一WebRTC多媒體用戶端應用程式的一經多工串流之經解多工部分；用於再多工該第一串流及該第二串流以產生該經多工串流之一重建構版本之構件；及用於將該經再多工串流遞送至該WebRTC多媒體用戶端應用程式之構件。
一種經組態以執行參加一網頁即時通訊(WebRTC)工作階段之一WebRTC代理伺服器模組之使用者設備(UE)，其包含：經組態以獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合之邏輯，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；經組態以在該WebRTC工作階段期間，自一WebRTC多媒體用戶端應用程式獲得該WebRTC多媒體用戶端應用程式試圖遞送至一目標UE上之一目標WebRTC多媒體用戶端應用程式之一經多工串流之邏輯，該經多工串流包括至少一第一媒體分量及一第二媒體分量；經組態以解多工該經多工串流以產生包括該第一媒體分量之一第一經解多工串流及包括該第二媒體分量之一第二經解多工串流之邏輯；經組態以在來自該第一鏈路集合之一第一鏈路上將該第一經解多工串流傳輸至一伺服網路以供遞送至該目標UE之邏輯；及經組態以在來自該第二鏈路集合之一第二鏈路上將該第二經解多工串流傳輸至該伺服網路以供遞送至該目標UE之邏輯。
一種經組態以執行參加一網頁即時通訊(WebRTC)工作階段之一WebRTC代理伺服器模組之使用者設備(UE)，其包含：經組態以獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合之邏輯，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；經組態以在該WebRTC工作階段期間，在來自該第一鏈路集合之一第一鏈路上自一伺服網路接收一第一串流且在來自該第二鏈路集合之一第二鏈路上自該伺服網路接收一第二串流之邏輯，該第一串流及該第二串流包括一源UE處之一源WebRTC多媒體用戶端應用程式試圖遞送至該UE上之一WebRTC多媒體用戶端應用程式的一經多工串流之經解多工部分；經組態以再多工該第一串流及該第二串流以產生該經多工串流之一重建構版本之邏輯；及經組態以將該經再多工串流遞送至該WebRTC多媒體用戶端應用程式之邏輯。
一種非暫時性電腦可讀媒體，其含有儲存於其上之指令該等指令在藉由一使用者設備(UE)執行時使該UE執行操作，該使用者設備(UE)經組態以執行參加一網頁即時通訊(WebRTC)工作階段之一WebRTC代理伺服器模組，該等指令包含：用以使該UE獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合的至少一個指令，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；用以使該UE在該WebRTC工作階段期間，自一WebRTC多媒體用戶端應用程式獲得該WebRTC多媒體用戶端應用程式試圖遞送至一目標UE上之一目標WebRTC多媒體用戶端應用程式之一經多工串流的至少一個指令，該經多工串流包括至少一第一媒體分量及一第二媒體分量；用以使該UE解多工該經多工串流以產生包括該第一媒體分量之一第一經解多工串流及包括該第二媒體分量之一第二經解多工串流的至少一個指令；用以使該UE在來自該第一鏈路集合之一第一鏈路上將該第一經解多工串流傳輸至一伺服網路以供遞送至該目標UE的至少一個指令；及用以使該UE在來自該第二鏈路集合之一第二鏈路上將該第二經解多工串流傳輸至該伺服網路以供遞送至該目標UE的至少一個指令。
一種非暫時性電腦可讀媒體，其含有儲存於其上之指令，該等指令在藉由一使用者設備(UE)執行時使該UE執行操作，該使用者設備(UE)經組態以執行參加一網頁即時通訊(WebRTC)工作階段之一WebRTC代理伺服器模組，該等指令包含：用以使該UE獲得一第一鏈路集合及不同於該第一鏈路集合的一第二鏈路集合的至少一個指令，其中該第一鏈路集合中之每一鏈路被分配至少一臨限位準之服務品質(QoS)；用以使該UE在該WebRTC工作階段期間，在來自該第一鏈路集合之一第一鏈路上自一伺服網路接收一第一串流且在來自該第二鏈路集合之一第二鏈路上自該伺服網路接收一第二串流的至少一個指令，該第一串流及該第二串流包括一源UE處之一源WebRTC多媒體用戶端應用程式試圖遞送至該UE上之一WebRTC多媒體用戶端應用程式的一經多工串流之經解多工部分；用以使該UE再多工該第一串流及該第二串流以產生該經多工串流之一重建構版本的至少一個指令；及用以使該UE將該經再多工串流遞送至該WebRTC多媒體用戶端應用程式的至少一個指令。