在移動(dòng)通信網(wǎng)絡(luò)中發(fā)送/接收流服務(wù)數(shù)據(jù)的裝置和方法
【技術(shù)領(lǐng)域】
[0001] 本公開設(shè)及用于在移動(dòng)通信網(wǎng)絡(luò)中發(fā)送/接收服務(wù)數(shù)據(jù)的裝置和方法。更加具體 來說，本公開設(shè)及用于在移動(dòng)通信網(wǎng)絡(luò)中發(fā)送/接收流服務(wù)數(shù)據(jù)的裝置和方法。
【背景技術(shù)】
[0002] 在移動(dòng)通信網(wǎng)絡(luò)中，用戶設(shè)備化E)具有移動(dòng)性，所W移動(dòng)通信網(wǎng)絡(luò)必須總是檢測(cè) UE的位置，并且無縫地將從外部網(wǎng)絡(luò)接收的數(shù)據(jù)傳送到肥。
[0003] 在移動(dòng)通信網(wǎng)絡(luò)中，為了提供無縫的服務(wù)，UE在從特定節(jié)點(diǎn)B移動(dòng)到其它節(jié)點(diǎn)即寸 執(zhí)行切換，并且在移動(dòng)到不同服務(wù)供應(yīng)商的其它網(wǎng)絡(luò)時(shí)執(zhí)行漫游操作。移動(dòng)通信網(wǎng)絡(luò)中管 理肥的位置的操作是肥移動(dòng)性管理操作。
[0004] 將參考圖1描述根據(jù)現(xiàn)有技術(shù)在移動(dòng)通信網(wǎng)絡(luò)中的集中式移動(dòng)管理操作。
[0005] 圖1示意性地示出根據(jù)現(xiàn)有技術(shù)在移動(dòng)通信網(wǎng)絡(luò)中的集中式移動(dòng)管理操作。
[0006] 參照?qǐng)D1，圖1中的移動(dòng)通信網(wǎng)絡(luò)是使用基于分層網(wǎng)絡(luò)結(jié)構(gòu)的集中式移動(dòng)管理方案 的移動(dòng)通信網(wǎng)絡(luò)。
[0007] 移動(dòng)通信網(wǎng)絡(luò)包括分組數(shù)據(jù)網(wǎng)絡(luò)110、通用移動(dòng)電信系統(tǒng)(UMTS)網(wǎng)絡(luò)120W及第S 代合作伙伴(3GPP)系統(tǒng)結(jié)構(gòu)演進(jìn)(SAE)網(wǎng)絡(luò)130。
[000引 UMTS網(wǎng)絡(luò)120包括網(wǎng)關(guān)通用分組無線服務(wù)支持節(jié)點(diǎn)(GGSN) 121、服務(wù)通用分組無線 服務(wù)支持節(jié)點(diǎn)（SGSN) 122、UMTS陸地?zé)o線接入網(wǎng)絡(luò)(UTRAN) 123 W及肥128和129eUTRAN 123 包括無線網(wǎng)絡(luò)控制器(RNC) 124與節(jié)點(diǎn)B(Node 6)125、126和127。
[0009] SAE網(wǎng)絡(luò)130包括分組數(shù)據(jù)網(wǎng)絡(luò)-網(wǎng)關(guān)(P-GW) 131、服務(wù)網(wǎng)關(guān)(S-GW) 132、演進(jìn)UTRAN 化-UTRAN)133W及肥137、138和139。E-UTRAN133包括演進(jìn)節(jié)點(diǎn)B(eNodeB)l：M、135和136。
[0010] 在使用如圖1所示的集中方案的移動(dòng)通信網(wǎng)絡(luò)中，管理移動(dòng)性的移動(dòng)代理位于核 屯、網(wǎng)絡(luò)中。移動(dòng)代理管理對(duì)于UE的綁定信息，并且處理對(duì)于UE的數(shù)據(jù)通訊（traffic)。在 UMTS網(wǎng)絡(luò)120中，GGSN 121成為集中式移動(dòng)代理。在3GPP SAE網(wǎng)絡(luò)130中，P-QV 131成為集中 式移動(dòng)代理。
[0011] 在如圖1所述的集中式移動(dòng)管理方案中，發(fā)生W下情況。
[0012] 在第一情況下，路由路徑的效率低下，并且運(yùn)將在下面進(jìn)行描述。
[0013] 在UE中接收的通訊和從UE發(fā)送的通訊二者都應(yīng)當(dāng)經(jīng)過集中式移動(dòng)代理。但是，即 使其它肥物理上在相關(guān)肥附近，如果相關(guān)肥直接與其它肥直接通信而不經(jīng)過集中式移動(dòng)代 理，相關(guān)肥可W經(jīng)歷相對(duì)較短的通信延遲。
[0014] 在第二情況下，集中式移動(dòng)代理的錯(cuò)誤可能發(fā)生，并且將在下面進(jìn)行描述。
[001引在集中式移動(dòng)管理方案中，所有通訊都經(jīng)過集中式移動(dòng)代理。因而，如果在集中式 移動(dòng)代理中存在錯(cuò)誤，則對(duì)于整個(gè)移動(dòng)通信網(wǎng)絡(luò)的通信可能擁痕。
[0016] 在第=情況下，通訊被集中到核屯、網(wǎng)絡(luò)，并且運(yùn)將在下面進(jìn)行描述。
[0017] 在集中式移動(dòng)管理方案中，對(duì)于全部UE的通訊被集中到核屯、網(wǎng)絡(luò)，因此由于核屯、 網(wǎng)絡(luò)中就用于網(wǎng)絡(luò)和設(shè)備的可量測(cè)性的通訊開銷而發(fā)生負(fù)擔(dān)。因此，服務(wù)供應(yīng)商必須擴(kuò)展 包括在核屯、網(wǎng)絡(luò)中的網(wǎng)絡(luò)和設(shè)備。更具體來說，因?yàn)橐苿?dòng)通信網(wǎng)絡(luò)已經(jīng)演進(jìn)到第五代（5G) 移動(dòng)通信網(wǎng)絡(luò)，所W核屯、網(wǎng)絡(luò)的負(fù)擔(dān)將由于無線接入技術(shù)的發(fā)展而顯著地提高。
[0018] 已經(jīng)提出了分布式移動(dòng)管理方案W便解決存在于集中式移動(dòng)管理方案中的情況。 分布式移動(dòng)管理方案適于移動(dòng)通信網(wǎng)絡(luò)結(jié)構(gòu)從分層結(jié)構(gòu)化ierarcMcal structure)演進(jìn) 為平面結(jié)構(gòu)(flat structure)的趨勢(shì)。分布式移動(dòng)管理方案不分配移動(dòng)代理功能給核屯、網(wǎng) 絡(luò)，而是分配移動(dòng)代理功能給無線接入網(wǎng)絡(luò)。
[0019] 將參考圖2描述根據(jù)現(xiàn)有技術(shù)的在移動(dòng)通信網(wǎng)絡(luò)中的分布式移動(dòng)管理操作。
[0020] 圖2示意性地示出根據(jù)現(xiàn)有技術(shù)在移動(dòng)通信網(wǎng)絡(luò)中的分布式移動(dòng)管理操作。
[0021] 參照?qǐng)D2,圖2中的移動(dòng)通信網(wǎng)絡(luò)是使用基于互聯(lián)網(wǎng)工程任務(wù)組（internet engineering task force, IETF)中提出的代理移動(dòng)網(wǎng)際協(xié)議（pro巧 mobile internet protocol，PMIP)的分布式移動(dòng)管理方案的移動(dòng)通信網(wǎng)絡(luò)。
[0022] 移動(dòng)通信網(wǎng)絡(luò)包括互聯(lián)網(wǎng)211、相應(yīng)節(jié)點(diǎn)（CN)I 215、接入路由器(AR)I 216、AR2 217、AR3 218、AR4 219、肥 220和CN2 22UAR1 216、AR2 217、AR3 218和AR4 219中的每一 個(gè)包括移動(dòng)接入網(wǎng)關(guān)(MAG)/本地移動(dòng)錯(cuò)(LMA)功能。互聯(lián)網(wǎng)211包括路由器(例如，路由器 212、路由器213和路由器214)。
[0023] 在圖2中，相應(yīng)于如圖1中所示的集中式移動(dòng)代理的LMA位于多個(gè)AR/MAG中。每當(dāng)改 變聯(lián)結(jié)點(diǎn)(PoA)時(shí)，肥220被從LMS分配一新網(wǎng)際協(xié)議(IP)地址，并且使用從相關(guān)的化A分配 的地址建立新會(huì)話。
[0024] 如果肥220接入ARl 216,則肥220使用從相關(guān)的LMA分配的地址與CNl 215建立 會(huì)話流#1。如果肥220接入AR3 218,則UE 220使用從相關(guān)的LMA分配的地址與CN2 221建立 會(huì)話流#2。位于各個(gè)AR的LMA執(zhí)行發(fā)送在各個(gè)會(huì)話中接收的分組到肥220的操作。
[00巧]如果肥220改變PoA,則錯(cuò)定各個(gè)會(huì)話的LMA必須知道用于UE 220的新化AW便保 證IP會(huì)話連續(xù)性。IP會(huì)話連續(xù)性指的是即使改變化A，UE也可W無縫地接收從老會(huì)話接收的 數(shù)據(jù)。
[0026] 在圖2中，為了發(fā)送從會(huì)話流#1和會(huì)話流#2接收的數(shù)據(jù)，錯(cuò)定各個(gè)會(huì)話的LMA建立 具有位于用于肥220的當(dāng)前化A處的MAG的隧道，并且通過所建立的隧道轉(zhuǎn)送數(shù)據(jù)。對(duì)此，每 個(gè)LMA必須知道當(dāng)前分配給肥220的IP地址。每個(gè)LMA可W通過錯(cuò)LMA和新化A之間的綁定更 新操作知道IP地址。例如，如果化A根據(jù)肥220移動(dòng)而變化，則相關(guān)的MAG必須發(fā)送關(guān)于新分 配給錯(cuò)定肥220的會(huì)話的LMA的IP地址的信息。
[0027] 因?yàn)橐苿?dòng)通信網(wǎng)絡(luò)已經(jīng)被快速地演進(jìn)并且智能電話已經(jīng)進(jìn)入廣泛使用，所W對(duì)于 移動(dòng)數(shù)據(jù)的使用也得到了快速增加。具體來說，移動(dòng)通訊當(dāng)中視頻通訊的比例是最高的，并 且根據(jù)Cisco視覺網(wǎng)絡(luò)索引數(shù)據(jù)，預(yù)期在2014年視頻通訊占整個(gè)移動(dòng)通訊的66%。
[0028] 在移動(dòng)通信網(wǎng)絡(luò)中，最為廣泛使用的視頻流服務(wù)是提供于YouTube(寶網(wǎng)站的服 務(wù)和提供于Netflix運(yùn)}網(wǎng)站的服務(wù)。Yo山'ube網(wǎng)站和化tf Iix網(wǎng)站提供基于HTTP的視頻流服 務(wù)。基于HTTP的視頻流服務(wù)偏好傳統(tǒng)的視頻流協(xié)議的原因?qū)⒃谙旅孢M(jìn)行描述。
[0029] 首先，基于HTTP的視頻流服務(wù)的費(fèi)用低于傳統(tǒng)視頻流協(xié)議的費(fèi)用?；贖TTP的視 頻流服務(wù)使用HTTP協(xié)議下載數(shù)據(jù)。結(jié)果，基于HTTP的視頻流服務(wù)不向UE請(qǐng)求特定協(xié)議并且 服務(wù)器僅僅提供網(wǎng)絡(luò)服務(wù)。
[0030] 第二，與傳統(tǒng)視頻流協(xié)議相比，基于HTTP的視頻流服務(wù)可W容易地通過防火墻。當(dāng) 前，多個(gè)網(wǎng)站使用防火墻阻斷除了公知的端口之外的端口。傳統(tǒng)的流協(xié)議使用用戶數(shù)據(jù)報(bào) 協(xié)議(UDP) W便使用特定端口，所W存在傳統(tǒng)的流協(xié)議將被防火墻阻斷的高概率。相反，基 于HTTP的視頻流服務(wù)使用公知的端口 80。從而，基于HTTP的視頻流服務(wù)可W容易地通過防 火墻。
[0031] 第=，為了降低服務(wù)器的負(fù)荷或者提供快速的數(shù)據(jù)傳輸，已經(jīng)普遍地使用代理服 務(wù)器或者高速緩存服務(wù)器，并且容易使用代理服務(wù)器或者高速緩存服務(wù)器，因?yàn)楹?jiǎn)單網(wǎng)絡(luò) 服務(wù)器對(duì)于提供基于HTTP的視頻流服務(wù)是必需的。
[0032] 同時(shí)，最廣泛使用的基于HTTP的視頻流協(xié)議包括HTTP漸進(jìn)式下載(progressive download, PU 協(xié)議和 HTTP 自適應(yīng)流（adaptive streaming ,AS)協(xié)議。HTTP 化協(xié)議和 HTTP AL協(xié)議在肥的通信狀態(tài)被報(bào)告給服務(wù)器并且服務(wù)器提供服務(wù)質(zhì)量(QoS)的方面不同于一般 HTTP協(xié)議，但是其它方面類似于一般HTTP協(xié)議。
[0033] 將參考圖3描述根據(jù)現(xiàn)有技術(shù)的、在移動(dòng)通信網(wǎng)絡(luò)中使用基于HTTP的視頻流協(xié)議 發(fā)送/接收數(shù)據(jù)的過程。
[0034] 圖3示意地示出根據(jù)現(xiàn)有技術(shù)、在移動(dòng)通信網(wǎng)絡(luò)中使用基于HTTP的視頻流協(xié)議發(fā) 送/接收數(shù)據(jù)的過程。
[00巧]參照?qǐng)D3,移動(dòng)通信網(wǎng)絡(luò)包括UE 311和服務(wù)器312。祀311在操作313中與服務(wù)器 312建立傳輸控制協(xié)議(TCP)會(huì)話。TCP會(huì)話包括IP地址、源端口和目的地端口。在TCP會(huì)話 中，IP地址被設(shè)置為"IP1"，源端口被設(shè)置為"4160"，并且目的地端口被設(shè)置為巧0"。肥311 在操作314中使用HTTP GET消息基于數(shù)據(jù)塊向服務(wù)器312請(qǐng)求特定流文件（Itag = 34)和特 定數(shù)據(jù)范圍（范圍= 13-1781759) Jtag和所述范圍中的每一個(gè)都是請(qǐng)求統(tǒng)一資源標(biāo)識(shí)符 化 RI)。
[0036] 在從肥311接收到HTTP GET消息之后，服務(wù)器312在操作315發(fā)送HTTP 2000K消息 到肥311，并且在操作316中與HTTP 2000K消息一起發(fā)送肥311請(qǐng)求的數(shù)據(jù)到肥31 IdHTTP 2000K消息包括內(nèi)容-長(zhǎng)度字段和連接字段。包括在HTTP 2000K消息中的連接字段的字段值 被設(shè)置為"保持活動(dòng)狀態(tài)化e邱-alive)"，所WTCP會(huì)話直到相應(yīng)于一個(gè)數(shù)據(jù)塊(chunk)的數(shù) 據(jù)傳輸完成才被釋放。HTTP 2000K消息和下一數(shù)據(jù)傳輸在操作317中變成一個(gè)數(shù)據(jù)塊（例 如，數(shù)據(jù)塊#1)。數(shù)據(jù)傳輸多次被執(zhí)行，并且運(yùn)是為什么圖3中的一個(gè)數(shù)據(jù)塊的大小大約 1.7MB的原因。
[0037] 肥311在操作318中使用HTTP GET消息基于數(shù)據(jù)塊向服務(wù)器312請(qǐng)求特定流文件 (Itag = 34)和特定數(shù)據(jù)范圍（范圍= 1781760-3563519)。在從UE 311接收到HTTP GET消息 之后，服務(wù)器312在操作319中發(fā)送HTTP2000K消息到肥311。包括在HTTP 2000K消息中了連 接字段的字段值被設(shè)置為"保持活動(dòng)狀態(tài)"，所WTCP會(huì)話直到相應(yīng)于一個(gè)數(shù)據(jù)塊的數(shù)據(jù)傳 輸完成才被釋放。HTTP 2000K消息和下一數(shù)據(jù)傳輸在操作321中變成一個(gè)數(shù)據(jù)塊(例如，數(shù) 據(jù)塊#2)。數(shù)據(jù)傳輸多次被執(zhí)行，并且運(yùn)是為什么圖3中的一個(gè)數(shù)據(jù)塊的大小大約1.7MB的原 因。
[003引用運(yùn)種方法，執(zhí)行數(shù)據(jù)發(fā)送/接收，肥311最后在操作322中使用HTTP GET消息基 于數(shù)據(jù)塊向服務(wù)器312請(qǐng)求特定流文件（Itag = 34)和特定數(shù)據(jù)范圍（范圍=26726400-28508159)。在從肥311接收到HTTP GET消息之后，服務(wù)器312在操作323中發(fā)送HTTP 2000K 消息到肥311，并且在操作324中與HTTP 2000K消息一起向肥311發(fā)送UE 311請(qǐng)求的數(shù)據(jù)。 包括在HTTP 2000K消息中的連接字段的字段值被設(shè)置為"保持活動(dòng)狀態(tài)"，所WTCP會(huì)話直 到相應(yīng)于一個(gè)數(shù)據(jù)塊的數(shù)據(jù)傳輸完成才被釋放。HTTP 2000K消息和下一數(shù)據(jù)傳輸在操作 325中變成一個(gè)數(shù)據(jù)塊(例如，最后一個(gè)數(shù)據(jù)塊）。數(shù)據(jù)傳輸多次被執(zhí)行，并且運(yùn)是為什么圖3 中的上次個(gè)數(shù)據(jù)塊的大小大約1.7MB的原因。
[0039] 在發(fā)送所有數(shù)據(jù)塊之后，如果在預(yù)設(shè)時(shí)間（例如，30秒）期間不存在通過利用UE 311建立的TCP會(huì)話的分組發(fā)送/接收則服務(wù)器312發(fā)送FIN消息到肥311，所W在操作326釋 放在肥311與服務(wù)器312之間建立的TCP會(huì)話。
[0040] 如上所述，UE 311基于數(shù)據(jù)塊請(qǐng)求數(shù)據(jù)傳輸?shù)椒?wù)器312,并且服務(wù)器312響應(yīng)于 到UE 311的數(shù)據(jù)傳輸請(qǐng)求發(fā)送數(shù)據(jù)。肌TP 2000K消息可W通過設(shè)置連接字段的字段值為 "保持活動(dòng)狀態(tài)"來使用TCP會(huì)話基于數(shù)據(jù)塊發(fā)送所有數(shù)據(jù)。
[0041] 同時(shí)，基于流協(xié)議的HTTP是無狀態(tài)的服務(wù)。服務(wù)器不知道關(guān)于UE的信息和與提供 視頻流服務(wù)相關(guān)的諸如會(huì)話信息運(yùn)樣的信息，并且每當(dāng)UE請(qǐng)求發(fā)送數(shù)據(jù)到服務(wù)器時(shí)，UE必 須通知服務(wù)器UE請(qǐng)求的數(shù)據(jù)文件名字W及關(guān)于UE想要接收的數(shù)據(jù)部分的信息。因?yàn)榛诹?協(xié)議的HTTP在高層中保證肥的移動(dòng)性，所W基于流協(xié)議的HTTP不請(qǐng)求IP會(huì)話連續(xù)性。
[0042] 而且，在分布式移動(dòng)管理方案中，為了保證IP會(huì)話連續(xù)性，每當(dāng)肥改變PoA時(shí)UE通 過綁定更新操作將肥的新化A注冊(cè)到錯(cuò)AR。然后，目標(biāo)是肥的通訊基于隧道通過舊的錯(cuò)AR被 傳遞到當(dāng)前錯(cuò)AR。
[0043] 但是，該數(shù)據(jù)通訊轉(zhuǎn)移方案可能沒有為UE提供路徑優(yōu)化的優(yōu)點(diǎn)。運(yùn)是為什么在相 對(duì)長(zhǎng)的時(shí)間期間提供視頻流服務(wù)的原因。具體來說，如果用戶隨著在諸如公交車或者車輛 之類的移動(dòng)工具上乘坐而移動(dòng)，則從舊的錯(cuò)AR到當(dāng)前化A的距離將變得很長(zhǎng)，所W將在相對(duì) 較長(zhǎng)的時(shí)間期間提供視頻流服務(wù)。
[0044] 將參考圖4描述在根據(jù)相關(guān)技術(shù)的移動(dòng)通信網(wǎng)絡(luò)使用分布式移動(dòng)管理方案管理UE 的移動(dòng)性的情況下可能發(fā)生的狀況。
[0045] 圖4示意性地示出在移動(dòng)通信網(wǎng)絡(luò)根據(jù)現(xiàn)有技術(shù)使用分布式移動(dòng)管理方案管理肥 的移動(dòng)性的情況中可能發(fā)生的狀況。
[0046] 參照?qǐng)D4,移動(dòng)通信網(wǎng)絡(luò)包括CNl 411、互聯(lián)網(wǎng)412、AR1 413、AR2 414、AR3 415、AR4 416 和肥 417。
[0047] 在圖4中，假定通過ARl 413建立與CNl 411的視頻通訊的TCP會(huì)話的肥417連續(xù)地 移動(dòng)，并且當(dāng)前通過設(shè)置AR4 416為化A接收到視頻通訊。
[004引在圖4