電信網(wǎng)絡(luò)中的不顯眼內(nèi)容壓縮的制作方法
【專利摘要】一種電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)，其能操作成路由IP數(shù)據(jù)報(bào)并且壓縮支持壓縮的層7協(xié)議的請(qǐng)求響應(yīng)的IP數(shù)據(jù)報(bào)，其中每個(gè)響應(yīng)數(shù)據(jù)報(bào)包括數(shù)據(jù)和限定數(shù)據(jù)的第一字節(jié)的序列號(hào)的報(bào)頭。該實(shí)施點(diǎn)進(jìn)一步包括數(shù)據(jù)報(bào)檢查模塊，用于根據(jù)壓縮策略確定數(shù)據(jù)可壓縮性。它進(jìn)一步包括：數(shù)據(jù)壓縮模塊，用于響應(yīng)于可壓縮性確定來壓縮數(shù)據(jù)；和報(bào)頭修改模塊，用于修改壓縮IP數(shù)據(jù)報(bào)中的報(bào)頭來考慮之前的IP數(shù)據(jù)報(bào)中的字節(jié)計(jì)數(shù)減少以確保響應(yīng)中相鄰壓縮IP數(shù)據(jù)報(bào)之間的序列號(hào)連續(xù)性。實(shí)施點(diǎn)進(jìn)一步包括通信模塊，其能操作成將壓縮IP數(shù)據(jù)報(bào)傳送到第一請(qǐng)求端點(diǎn)、從第一端點(diǎn)接收它們的接收的確認(rèn)以及響應(yīng)于所述確認(rèn)的接收而生成對(duì)應(yīng)未壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)用于由通信模塊傳送到第二端點(diǎn)。
【專利說明】電信網(wǎng)絡(luò)中的不顯眼內(nèi)容壓縮
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及在電信網(wǎng)絡(luò)中的端點(diǎn)之間的雙向通信中路由的IP數(shù)據(jù)報(bào)的壓縮，這些IP數(shù)據(jù)報(bào)輸送支持壓縮的層7協(xié)議(例如HTTP/1.1)的響應(yīng)(層級(jí)在開放系統(tǒng)互連(OSI)參考模型的意義上理解)。
【背景技術(shù)】
[0002]近年來移動(dòng)數(shù)據(jù)計(jì)劃和移動(dòng)寬帶(MBB)的日益流行結(jié)合例如智能電話等具有像計(jì)算機(jī)的能力的廉價(jià)終端(也泛稱為“用戶設(shè)備”或“UE”)的可用性已經(jīng)使對(duì)電信網(wǎng)絡(luò)的需求增加，特別從帶寬容量和服務(wù)質(zhì)量(QoS)方面來看。提供移動(dòng)接入的電信網(wǎng)絡(luò)的網(wǎng)絡(luò)運(yùn)營(yíng)商和移動(dòng)設(shè)備制造商是在力求找到滿足這些日益增加的需求的技術(shù)方案那些人之中。
[0003]圖1是電信網(wǎng)絡(luò)的簡(jiǎn)化圖示，該電信網(wǎng)絡(luò)包括移動(dòng)數(shù)據(jù)網(wǎng)絡(luò)10，其可以使UE 20(例如，智能電話)經(jīng)由代理服務(wù)器40連接到互聯(lián)網(wǎng)30，使得UE 20能夠下載內(nèi)容并且用別的方式與連接到互聯(lián)網(wǎng)30的web服務(wù)器50通信。
[0004]為了提高電信網(wǎng)絡(luò)(例如在圖1中示出的那個(gè))中的帶寬可用性，跨越網(wǎng)絡(luò)的業(yè)務(wù)可以通過采用支持壓縮的通信協(xié)議而減少。然而，壓縮業(yè)務(wù)的決定由通信中牽涉的端點(diǎn)(例如，在客戶端-服務(wù)器架構(gòu)中充當(dāng)客戶端的UE 20和充當(dāng)服務(wù)器的web服務(wù)器50，或在對(duì)等架構(gòu)中的對(duì)等物)做出，而沒有在通信中調(diào)解來影響該決定的電信數(shù)據(jù)網(wǎng)絡(luò)的余地。
[0005]在下面的境況下，在端點(diǎn)之間提供數(shù)據(jù)通信以能夠迫使在應(yīng)用級(jí)(即層7，如在OSI參考模型的意義上理解的)處的壓縮(即不必壓縮完整的數(shù)據(jù)流/內(nèi)容(或者，也就是說，沒有隧道傳輸))，這對(duì)于電信網(wǎng)絡(luò)將是可取的:
一對(duì)于已經(jīng)內(nèi)置對(duì)壓縮的支持的協(xié)議的有效載荷業(yè)務(wù)(內(nèi)容)；以及一對(duì)于在支持壓縮內(nèi)容的選項(xiàng)時(shí)已決定不這樣做的客戶端和服務(wù)器(或通信對(duì)等物，視情況而定)。
[0006]遵循這些指導(dǎo)，可以考慮能經(jīng)受有力壓縮的協(xié)議?！俺谋緜鬏攨f(xié)議”HTTP可能是最有名的情況并且將因此在下面論述。使用HTTP作為基礎(chǔ)的其他應(yīng)用層協(xié)議(例如SOAP或XML-RPC)或基于web的服務(wù)(例如“Dropbox”或“Twitter”)在用于迫使壓縮的方案中也可視為候選。
[0007]根據(jù)現(xiàn)今的移動(dòng)業(yè)務(wù)報(bào)告，基于HTTP的業(yè)務(wù)在移動(dòng)數(shù)據(jù)網(wǎng)絡(luò)中傳送的數(shù)據(jù)占據(jù)相當(dāng)大比例。HTTP是在萬維網(wǎng)中用作數(shù)據(jù)通信的基礎(chǔ)的應(yīng)用級(jí)協(xié)議。根據(jù)UE 20 (或在可以使用UE 20連接到移動(dòng)網(wǎng)絡(luò)的任何其他裝置中)中的哪個(gè)HTTP客戶端(典型地，web瀏覽器)可以聯(lián)系HTTP服務(wù)器(例如，web服務(wù)器50)并且請(qǐng)求HTTP服務(wù)器50所存儲(chǔ)的信息中的一些或備選地對(duì)HTTP服務(wù)器50發(fā)送信息用于稍后處理，HTTP起到請(qǐng)求-響應(yīng)協(xié)議的作用(使用客戶端-服務(wù)器模型)。除其他外，對(duì)于來自web服務(wù)器50的信息的請(qǐng)求典型地利用HTTP GET方法，而到web服務(wù) 器50的上傳可使用HTTP POST或GET方法。
[0008]HTTP支持內(nèi)容壓縮，其理解為使端點(diǎn)通信來發(fā)送并且接收壓縮內(nèi)容以優(yōu)化底層帶寬資源的使用并且稍后向采用未壓縮(并且等于原始)格式的互聯(lián)網(wǎng)協(xié)議族中的上層呈現(xiàn)該信息的能力。更具體地，例如支持內(nèi)容壓縮的HTTP等協(xié)議通過限定允許端點(diǎn)指示它從另一個(gè)端點(diǎn)接收規(guī)定壓縮格式的壓縮內(nèi)容的意愿(或偏好)所需要的控制信令以及允許端點(diǎn)提供它發(fā)送到另一個(gè)端點(diǎn)的內(nèi)容是否被壓縮的指示并且如果這樣的話則使用壓縮格式所需要的控制信令而這樣做。
[0009]從而，UE 20起到HTTP客戶端的作用，其實(shí)現(xiàn)當(dāng)前版本的HTTP(即HTTP/1.1)并且愿意接受采用包含壓縮、封裝數(shù)據(jù)的IP數(shù)據(jù)報(bào)形式的壓縮內(nèi)容，在發(fā)送到web服務(wù)器50的請(qǐng)求中在“接受-編碼(Accept-Encoding)”報(bào)頭中包括命名它所支持的壓縮方案的列表。例如，下面的由HTTP客戶端發(fā)送的HTTP請(qǐng)求的“接受-編碼”報(bào)頭示出客戶端支持“gzip”和“deflate”方案兩者:
接受-編碼:gzip> deflate
質(zhì)量值(所謂的“q值”)可以用于表達(dá)偏好。例如，在下面示例中，客戶端對(duì)“gzip”表達(dá)優(yōu)于“deflate”的偏好。
[0010]接受-編碼:gzip；q=l.0, deflate ；q=0.5, * ；q=0 如果web服務(wù)器50 (或充當(dāng)服務(wù)器并且接收請(qǐng)求的任何HTTP實(shí)體)支持HTTP客戶端20所提出的壓縮方案中的任一個(gè)，它可根據(jù)該方案決定壓縮答復(fù)中的內(nèi)容。web服務(wù)器50絕沒有義務(wù)對(duì)內(nèi)容進(jìn)行任何壓縮，并且基于它的內(nèi)部配置、內(nèi)部能力、網(wǎng)絡(luò)或處理負(fù)載和/或其他因素而這樣做。
[0011]如果web服務(wù)器50選擇壓縮內(nèi)容，它將在它的響應(yīng)的“內(nèi)容-編碼(Content-Encoding)”報(bào)頭中包括使用的方案。例如,下面的示例可以用于通知HTTP客戶端20內(nèi)容已經(jīng)使用“gzip”方案而壓縮:
內(nèi)容-編碼:gzip
當(dāng)客戶端20支持壓縮并且服務(wù)器50選擇發(fā)送壓縮內(nèi)容時(shí)，HTTP內(nèi)容壓縮在減少HTTP的帶寬使用方面很好地起作用。在該方面中，大部分的現(xiàn)代web瀏覽器(無論是在傳統(tǒng)的個(gè)人計(jì)算機(jī)中還是在現(xiàn)代移動(dòng)終端中實(shí)現(xiàn))支持HTTP內(nèi)容壓縮。在RFC 2616 (1999年6月，“超文本傳輸協(xié)議一 HTTP/1.1”)中提供HTTP內(nèi)容壓縮的進(jìn)一步的細(xì)節(jié)。
[0012]在圖1的示例中，宣告支持的壓縮方案取決于HTTP客戶端20，并且發(fā)送壓縮或未壓縮的內(nèi)容取決于HTTP服務(wù)器50。如上文指出的，由HTTP服務(wù)器50做出的關(guān)于是否壓縮它向HTTP客戶端20發(fā)送的數(shù)據(jù)的決定可取決于服務(wù)器的配置或其他內(nèi)部因素(例如，處理器負(fù)載，因?yàn)閴嚎s數(shù)據(jù)內(nèi)容消耗處理資源)或可能外部因素(例如，本地網(wǎng)絡(luò)段)。從而，一般，壓縮數(shù)據(jù)內(nèi)容可被HTTP客戶端20接受的指示(例如，包括在由客戶端20發(fā)送的HTTP請(qǐng)求中的“接受-編碼”報(bào)頭)不一定迫使HTTP服務(wù)器50用壓縮數(shù)據(jù)內(nèi)容答復(fù)客戶端20，當(dāng)客戶端接收HTTP響應(yīng)中的未壓縮數(shù)據(jù)內(nèi)容時(shí)也不在客戶端20中引起錯(cuò)誤。相反，HTTP服務(wù)器50可以根據(jù)本地策略/狀態(tài)和/或通過它當(dāng)前的數(shù)據(jù)(例如，數(shù)據(jù)內(nèi)容的壓縮在服務(wù)器50中可不被允許，或請(qǐng)求的數(shù)據(jù)內(nèi)容可未由服務(wù)器50采用壓縮格式存儲(chǔ)并且它的處理資源可在它答復(fù)客戶端的請(qǐng)求時(shí)過載，等)的格式來作用。
[0013]已知的內(nèi)容壓縮方案(例如，HTTP數(shù)據(jù)業(yè)務(wù)的壓縮)具有不能被電信網(wǎng)絡(luò)(例如，在圖1中示出的移動(dòng)電信網(wǎng)絡(luò)10)以不顯眼的方式實(shí)施的缺點(diǎn)；例如，在不使用通常稱為代理(例如web代理，其是設(shè)置成在HTTP客戶端與HTTP服務(wù)器之間運(yùn)行的基于HTTP的數(shù)據(jù)業(yè)務(wù)中調(diào)解的服務(wù)器)的應(yīng)用級(jí)中介的情況下，如將在下文論述的。[0014]例如，因?yàn)樵趫D1中示出的HTTP服務(wù)器50大體上將定位在擁有被HTTP客戶端20使用來訪問信息的電信網(wǎng)絡(luò)10的網(wǎng)絡(luò)運(yùn)營(yíng)商的網(wǎng)絡(luò)域外部(大體上定位在互聯(lián)網(wǎng)的另一個(gè)域中)，電信網(wǎng)絡(luò)10將不具有影響可以由HTTP服務(wù)器50做出的決定的工具，并且更準(zhǔn)確地，由HTTP服務(wù)器50做出的關(guān)于某些數(shù)據(jù)內(nèi)容是否要交付給HTTP客戶端20的決定要被壓縮。
[0015]在圖1的示例中，可出現(xiàn)下面的情形:
-HTTP客戶端20支持內(nèi)容壓縮(例如，HTTP內(nèi)容壓縮)；并且-HTTP服務(wù)器50由于例如靜態(tài)配置(正確或不正確的)、基于局部知識(shí)的動(dòng)態(tài)決定、防止服務(wù)器使本地資源專用于壓縮內(nèi)容的局部過載等因素而決定不發(fā)送壓縮的內(nèi)容。
[0016]因此，只要終止和/或起始于附連到電信網(wǎng)絡(luò)10的用戶終端(UE)的數(shù)據(jù)流的數(shù)據(jù)包未被壓縮，充當(dāng)客戶端來訪問數(shù)據(jù)內(nèi)容的UE 20所使用的電信網(wǎng)絡(luò)10的節(jié)點(diǎn)(例如，在圖1中圖示的電信網(wǎng)絡(luò)10的核心網(wǎng)絡(luò)節(jié)點(diǎn)和無線電接入節(jié)點(diǎn))的傳送資源上的負(fù)載將增加。在移動(dòng)數(shù)據(jù)網(wǎng)絡(luò)10上游的電信網(wǎng)絡(luò)部件(在圖1中由“互聯(lián)網(wǎng)30”指示)中將出現(xiàn)相似的問題。
[0017]可以在網(wǎng)絡(luò)中引入Web代理(例如在圖1中示出的代理服務(wù)器40)來迫使壓縮。然而，標(biāo)準(zhǔn)代理服務(wù)器和透明代理兩者在它們需要對(duì)客戶端配置的改變(在標(biāo)準(zhǔn)web代理的情況下，其中每個(gè)客戶端必須配置成使用給定代理以便有力地壓縮業(yè)務(wù))或可擾亂HTTP協(xié)議的功能性的意義上是侵入性技術(shù)。
[0018]Web代理(標(biāo)準(zhǔn)和透明兩者)實(shí)現(xiàn)TCP連接建立的轉(zhuǎn)移(攔截)。當(dāng)web代理不應(yīng)訪問傳輸層(即，層4)信息時(shí)，這因?yàn)槟康牡豂P地址和端口與目標(biāo)URL之間的映射(如由客戶端實(shí)現(xiàn)的)可不匹配代理所選擇的那個(gè)而引入問題。此外，因?yàn)榭蛻舳藶g覽器認(rèn)為它正與服務(wù)器而不是代理談話，TCP連接建立的攔截造成面向連接的驗(yàn)證方案(例如NTLM)問題。與web代理的使用關(guān)聯(lián)的眾所周知的問題在RFC 3143 (2001年6月，“已知的HTTP代理/高速緩存問題”)中闡述。
[0019]總的來說，在電信網(wǎng)絡(luò)上交付未壓縮數(shù)據(jù)內(nèi)容可以使網(wǎng)絡(luò)節(jié)點(diǎn)中的至少一些(例如被移動(dòng)終端所利用的無線電接入資源、分組核心資源和/或電信網(wǎng)絡(luò)的其他部件)的傳送容量過載，由此減少網(wǎng)絡(luò)容量。網(wǎng)絡(luò)的不同段將不同地受到影響，但一般，未壓縮數(shù)據(jù)的傳送將總是對(duì)網(wǎng)絡(luò)的傳送資源具有負(fù)面影響。數(shù)據(jù)壓縮可以幫助減輕該問題。然而，用于迫使數(shù)據(jù)壓縮的已知方案(特別地牽涉代理(例如，web代理和高速緩存服務(wù)器)的使用的那些)具有許多缺點(diǎn)，如上文解釋的。

【發(fā)明內(nèi)容】

[0020]本發(fā)明的
【發(fā)明者】已經(jīng)設(shè)想采用不需要對(duì)通信端點(diǎn)(無論是客戶端-服務(wù)器架構(gòu)中的客戶端和服務(wù)器，還使對(duì)等網(wǎng)絡(luò)中的對(duì)等物)的配置的任何改變的優(yōu)雅、不顯眼方式壓縮電信系統(tǒng)中的業(yè)務(wù)的方法，其允許在對(duì)現(xiàn)有的通信沒有影響并且沒有來自端點(diǎn)的任何協(xié)作的情況下壓縮業(yè)務(wù)。如將在下面解釋的，方法允許以動(dòng)態(tài)且自動(dòng)的方式提高電信網(wǎng)絡(luò)的資源的使用，其不具有上文 標(biāo)識(shí)的代理服務(wù)器的使用所固有的缺點(diǎn)中的至少一些。
[0021 ] 更具體地，本發(fā)明在一個(gè)方面中提供在電信網(wǎng)絡(luò)中的第一端點(diǎn)與電信網(wǎng)絡(luò)中的第二端點(diǎn)之間的雙向通信中由策略實(shí)施點(diǎn)路由IP數(shù)據(jù)報(bào)并且根據(jù)數(shù)據(jù)壓縮策略壓縮由該第二端點(diǎn)傳送到第一端點(diǎn)的響應(yīng)的IP數(shù)據(jù)報(bào)的方法。每個(gè)IP數(shù)據(jù)報(bào)包括數(shù)據(jù)的字節(jié)序列和限定IP數(shù)據(jù)報(bào)中的數(shù)據(jù)的第一字節(jié)的序列號(hào)的報(bào)頭。響應(yīng)是層7協(xié)議的，其支持壓縮，其中層級(jí)在開放系統(tǒng)互連OSI參考模型的意義上理解。方法包括確定由第二端點(diǎn)發(fā)送的IP數(shù)據(jù)報(bào)是否未被壓縮但可以通過在接收的IP數(shù)據(jù)報(bào)中的至少一個(gè)中檢查層7協(xié)議的控制信息(其超出IP數(shù)據(jù)報(bào)中的IP5元組而定位)而根據(jù)數(shù)據(jù)壓縮策略來壓縮。接收的IP數(shù)據(jù)報(bào)中的至少一些中的數(shù)據(jù)響應(yīng)于確定接收的IP數(shù)據(jù)報(bào)未被壓縮但可以被壓縮而壓縮，由此生成壓縮IP數(shù)據(jù)報(bào)用于傳送到第一端點(diǎn)。修改壓縮的IP數(shù)據(jù)報(bào)中的報(bào)頭來考慮由其中的數(shù)據(jù)壓縮引起的一個(gè)或多個(gè)之前的IP數(shù)據(jù)報(bào)中的字節(jié)的數(shù)量中的減少以便確保在由第二端點(diǎn)傳送到第一端點(diǎn)的響應(yīng)中相鄰壓縮IP數(shù)據(jù)報(bào)之間的所述序列號(hào)的連續(xù)性。壓縮的IP數(shù)據(jù)報(bào)傳送到第一端點(diǎn)并且從第一端點(diǎn)接收壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)。響應(yīng)于所述確認(rèn)的接收，生成對(duì)應(yīng)未壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)用于傳送到第二端點(diǎn)。對(duì)應(yīng)的未壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)然后傳送到第二端點(diǎn)。
[0022]從而，在本發(fā)明的實(shí)施例中，在所謂的用于確定由第二端點(diǎn)發(fā)送的IP數(shù)據(jù)報(bào)是否未被壓縮但可以被壓縮的“深度包檢查”(DPI)之后，由策略實(shí)施點(diǎn)(在適當(dāng)?shù)那闆r下，根據(jù)壓縮策略)向從第二端點(diǎn)路由到第一端點(diǎn)的IP數(shù)據(jù)報(bào)應(yīng)用壓縮，使得壓縮內(nèi)容通過端點(diǎn)之間的單個(gè)TCP連接而傳送，其的完整性被保留。因此與在上文提到的迫使內(nèi)容壓縮的基于代理的方案(其中需要代理與每個(gè)端點(diǎn)之間的獨(dú)立連接的建立并且促發(fā)了上文論述的問題)不同，沒有出現(xiàn)端點(diǎn)之間TCP連接的攔截。
[0023]數(shù)據(jù)壓縮過程對(duì)于端點(diǎn)的透明度通過i)修改壓縮IP數(shù)據(jù)報(bào)中的報(bào)頭來解釋由其中的數(shù)據(jù)壓縮引起的一個(gè)或多個(gè)之前的IP數(shù)據(jù)報(bào)中的字節(jié)數(shù)量中的減少以便確保響應(yīng)中相鄰壓縮IP數(shù)據(jù)報(bào)之間的序列號(hào)的連續(xù)性；以及ii)將由第一端點(diǎn)的壓縮IP數(shù)據(jù)報(bào)的接收確認(rèn)轉(zhuǎn)換成用于傳送到第二端點(diǎn)的對(duì)應(yīng)未壓縮IP數(shù)據(jù)報(bào)的接收確認(rèn)而實(shí)現(xiàn)。從而，來自第二端點(diǎn)的TCP流(其因?yàn)?壓縮過程而出現(xiàn))內(nèi)的數(shù)據(jù)的字節(jié)數(shù)量中的減少對(duì)兩個(gè)端點(diǎn)可以隱藏。這樣，數(shù)據(jù)通過端點(diǎn)之間的TCP連接的傳遞如從每個(gè)端點(diǎn)的角度所預(yù)期的那樣行進(jìn)，其中第一端點(diǎn)接收并且正確地確認(rèn)壓縮內(nèi)容的字節(jié)的接收，并且第二端點(diǎn)傳送并且接收未壓縮內(nèi)容的字節(jié)的接收的正確確認(rèn)。TCP連接的完整性連同重傳、復(fù)制和分段從而可以保
&3甶O
[0024]除上文提到的迫使壓縮的基于代理的方案的缺點(diǎn)外，一旦獲得與客戶端的請(qǐng)求有關(guān)的總(完整)數(shù)據(jù)內(nèi)容，將代理服務(wù)器(例如，web代理或高速緩存服務(wù)器)或任何其他種類的應(yīng)用級(jí)中介置于端點(diǎn)之間的通信的數(shù)據(jù)路徑中趨于在該中介必須進(jìn)行數(shù)據(jù)內(nèi)容高速緩存用于執(zhí)行后續(xù)壓縮的情況下引入額外的傳送延遲。
[0025]為了減小這樣的傳送延遲，在本發(fā)明的實(shí)施例(其中由第二端點(diǎn)傳送的響應(yīng)包括響應(yīng)報(bào)頭和內(nèi)容，該響應(yīng)報(bào)頭包括指示響應(yīng)中的內(nèi)容的長(zhǎng)度的內(nèi)容長(zhǎng)度指示符)中，在接收的IP數(shù)據(jù)報(bào)中的數(shù)據(jù)可通過以下來壓縮:從響應(yīng)去除內(nèi)容長(zhǎng)度指示符；在接收響應(yīng)的最后IP數(shù)據(jù)報(bào)之前壓縮響應(yīng)的接收IP數(shù)據(jù)報(bào)中的數(shù)據(jù)；以及使壓縮數(shù)據(jù)編碼成數(shù)據(jù)塊來生成編碼的壓縮響應(yīng)用于傳送到第一端點(diǎn)，該編碼的壓縮響應(yīng)包括已經(jīng)應(yīng)用編碼的指示。壓縮接收數(shù)據(jù)報(bào)中的數(shù)據(jù)的該過程避免在可以開始?jí)嚎s之前等待接收完整(未被壓縮)的響應(yīng)或其相當(dāng)大的部分的需要，由此允許響應(yīng)的流壓縮由路由在端點(diǎn)中起始和/或終止的IP數(shù)據(jù)報(bào)的流的策略實(shí)施點(diǎn)進(jìn)行，并且被指派來對(duì)這些流實(shí)施QoS策略(如由QoS參數(shù)確定的)。這樣，數(shù)據(jù)可以“在運(yùn)行中(on the fly)”被壓縮，其中第一端點(diǎn)接收塊中的壓縮數(shù)據(jù)。
[0026]例如，在HTTP/1.1響應(yīng)的IP數(shù)據(jù)報(bào)被路由和壓縮并且響應(yīng)包括內(nèi)容-長(zhǎng)度報(bào)頭的情況下，接收的IP數(shù)據(jù)報(bào)中的數(shù)據(jù)可通過以下來壓縮:從響應(yīng)去除內(nèi)容-長(zhǎng)度(Content-Length)報(bào)頭；執(zhí)行HTTP兼容壓縮算法以在接收響應(yīng)的最后IP數(shù)據(jù)報(bào)之前壓縮接收IP數(shù)據(jù)報(bào)中的數(shù)據(jù)；以及對(duì)壓縮數(shù)據(jù)應(yīng)用成塊傳遞編碼來生成傳遞編碼響應(yīng)，其包括傳遞-編碼(Transfer-Encoding)報(bào)頭用于傳送到第一端點(diǎn)。因?yàn)镠TTP業(yè)務(wù)占據(jù)在移動(dòng)網(wǎng)絡(luò)中存在的總數(shù)據(jù)業(yè)務(wù)的相當(dāng)大的百分比，HTTP/1.1業(yè)務(wù)以實(shí)現(xiàn)HTTP所使用的帶寬中的減少這樣的方式的處理可以在沒有額外投入的情況下增加網(wǎng)絡(luò)的容量，從而允許改進(jìn)移動(dòng)網(wǎng)絡(luò)中的資源分配。
[0027]根據(jù)另一個(gè)方面，本發(fā)明提供電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)，其能操作成在電信網(wǎng)絡(luò)中的第一端點(diǎn)與該電信網(wǎng)絡(luò)中的第二端點(diǎn)之間采用雙向通信來路由IP數(shù)據(jù)報(bào)并且能操作成根據(jù)數(shù)據(jù)壓縮策略來壓縮由該第二端點(diǎn)傳送到該第一端點(diǎn)的響應(yīng)的IP數(shù)據(jù)報(bào)。響應(yīng)中的每個(gè)IP數(shù)據(jù)報(bào)包括數(shù)據(jù)的字節(jié)序列和限定IP數(shù)據(jù)報(bào)中的數(shù)據(jù)的第一字節(jié)的序列號(hào)的報(bào)頭。響應(yīng)是支持壓縮的層7協(xié)議的，其中層級(jí)在開放系統(tǒng)互連OSI參考模型的意義上理解。電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)包括數(shù)據(jù)報(bào)檢查模塊，其能操作成確定從第二端點(diǎn)發(fā)送并且被策略實(shí)施點(diǎn)接收的IP數(shù)據(jù)報(bào)是否未被壓縮但可以通過在接收的IP數(shù)據(jù)報(bào)中的至少一個(gè)中檢查層7協(xié)議的控制信息(其超出IP數(shù)據(jù)報(bào)中的IP5元組而定位)而根據(jù)數(shù)據(jù)壓縮策略來壓縮。電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)進(jìn)一步包括數(shù)據(jù)壓縮模塊，其能操作成響應(yīng)于數(shù)據(jù)報(bào)檢查模塊確定接收的IP數(shù)據(jù)報(bào)未被壓縮但可以壓縮而壓縮接收的IP數(shù)據(jù)報(bào)中的至少一些中的數(shù)據(jù)，由此生成壓縮IP數(shù)據(jù)報(bào)用于傳送到第一端點(diǎn)。電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)還包括:報(bào)頭修改模塊，其能操作成修改壓縮IP數(shù)據(jù)報(bào)中的報(bào)頭來考慮由數(shù)據(jù)壓縮模塊在其中的數(shù)據(jù)壓縮所引起的一個(gè)或多個(gè)之前的IP數(shù)據(jù)報(bào)中字節(jié)數(shù)量中的減少以便確保由第二端點(diǎn)傳送到第一端點(diǎn)的響應(yīng)中相鄰壓縮IP數(shù)據(jù)報(bào)之間的所述序列號(hào)的連續(xù)性；和通信模塊，其能操作成將壓縮IP數(shù)據(jù)報(bào)傳送到第一端點(diǎn)并且從其處接收壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)。報(bào)頭修改模塊進(jìn)一步能操作成響應(yīng)于由通信模塊接收所述確認(rèn)而生成對(duì)應(yīng)的未壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)以由通信模塊傳送到第二端點(diǎn)。
【專利附圖】

【附圖說明】
[0028]現(xiàn)在將僅通過示例的方式參考附圖詳細(xì)解釋本發(fā)明的實(shí)施例，其中:
圖1示出使移動(dòng)終端連接到Web服務(wù)器的常規(guī)電信網(wǎng)絡(luò)；
圖2示出根據(jù)本發(fā)明的第一實(shí)施例的電信系統(tǒng)，其包括策略決定點(diǎn)(PDP)和策略實(shí)施點(diǎn)(PEP)；
圖3圖示能夠起到在圖2中示出的PEP和/或PDP作用的可編程計(jì)算機(jī)硬件的示例；圖4和5是圖示由在圖2中示出的設(shè)備進(jìn)行來進(jìn)行網(wǎng)絡(luò)業(yè)務(wù)的不顯眼流壓縮的處理操作的流程圖；
圖6總結(jié)由根據(jù)本發(fā)明的第一實(shí)施例的PEP進(jìn)行的關(guān)鍵處理操作；
圖7圖示可由根據(jù)第一實(shí)施例的PEP進(jìn)行的HTTP響應(yīng)的流壓縮； 圖8示出根據(jù)本發(fā)明的第二實(shí)施例的電信系統(tǒng)，其包括PDP和PEP ;以及 圖9圖示可在本發(fā)明的實(shí)施例中采用的通信協(xié)議P的某些特征?！揪唧w實(shí)施方式】
[0029][實(shí)施例1]
圖2示出根據(jù)本發(fā)明的第一實(shí)施例的電信系統(tǒng)100，該電信系統(tǒng)100包括電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)(PEP) 100，其設(shè)置成采用在采用運(yùn)行web瀏覽器HTTP的客戶終端300 (例如，智能電話)的形式的第一端點(diǎn)與第二端點(diǎn)(其采取web服務(wù)器400的形式)之間路由TCP/IP業(yè)務(wù)。該web服務(wù)器400大體上將屬于遠(yuǎn)程網(wǎng)絡(luò)域，其可以經(jīng)由互聯(lián)網(wǎng)通過電信網(wǎng)絡(luò)的通信資源而達(dá)到。接入網(wǎng)絡(luò)和電信網(wǎng)絡(luò)的核心網(wǎng)絡(luò)節(jié)點(diǎn)的細(xì)節(jié)以及所述電信網(wǎng)絡(luò)與web服務(wù)器400之間的另外的網(wǎng)絡(luò)(一個(gè)或多個(gè))互配的細(xì)節(jié)為了簡(jiǎn)單起見而未在圖2中圖示。
[0030]在圖2中示出的策略實(shí)施點(diǎn)PEP 200是網(wǎng)絡(luò)節(jié)點(diǎn)，其起到路由在通信端點(diǎn)中起始和/或終止的數(shù)據(jù)包流的作用并且設(shè)置成為那些流實(shí)施接納策略并且基于策略信息和QoS參數(shù)(其通常從策略決定點(diǎn)(PDP) 500接收)對(duì)接納的流實(shí)施QoS策略，盡管這些數(shù)據(jù)中的一些可以在PEP 200內(nèi)本地配置也如此。QoS參數(shù)可以包括:例如QoS類標(biāo)識(shí)符(QCI)，其可以是用作PEP中的控制包轉(zhuǎn)發(fā)處理的參考的標(biāo)量(例如，調(diào)度權(quán)重、接納閾值、隊(duì)列管理閾值、QoS信令，等)；或分配和保留優(yōu)先級(jí)(ARP)，其可以包括關(guān)于包流的優(yōu)先級(jí)和搶占(pre-emption)的信息(并且其可以確定例如在擁擠的情形下用于丟棄或維持包流的優(yōu)先級(jí))。PEP 200的特定示例(其將在下面描述)是在如由3GPP規(guī)范TS 23.203中描述的“PCC架構(gòu)”中實(shí)現(xiàn)所謂的“PCEF”功能性的電信節(jié)點(diǎn)。
[0031]在圖2中示出的PEP 200根據(jù)優(yōu)選實(shí)施例是網(wǎng)絡(luò)節(jié)點(diǎn)，其進(jìn)一步設(shè)置成對(duì)在客戶終端300中終止(或，在UE 300充當(dāng)服務(wù)器的情況下，起始于客戶端300)的數(shù)據(jù)流的數(shù)據(jù)包實(shí)施至少一個(gè)數(shù)據(jù)壓縮策略，該策略可選地存儲(chǔ)在rop 500中。PEP 200和rop 500操作地連接在一起使得存儲(chǔ)在rop 500中的至少一個(gè)數(shù)據(jù)壓縮策略可以被PEP 200檢索并且在它的操作期間被實(shí)施來壓縮來自web服務(wù)器400的內(nèi)容。
[0032]PEP 200的部件和它們的功能關(guān)系也在圖2中示出。PEP 200包括數(shù)據(jù)報(bào)檢查模塊210、數(shù)據(jù)壓縮模塊220、通信模塊230和報(bào)頭修改模塊240。設(shè)置成根據(jù)已知技術(shù)進(jìn)行QoS實(shí)施功能性(并且可以包括例如用于包隊(duì)列管理過濾和歸類的模塊)的PEP 200的其他部件為了簡(jiǎn)單起見而未在圖2中圖示。
[0033]在本實(shí)施例中，數(shù)據(jù)報(bào)檢查模塊210、數(shù)據(jù)壓縮模塊220和報(bào)頭修改模塊240包括可編程信號(hào)處理硬件，其實(shí)現(xiàn)可形成計(jì)算機(jī)程序、模塊、對(duì)象或由此可執(zhí)行的指令序列的至少一部分的規(guī)程。這些規(guī)則在被信號(hào)處理硬件執(zhí)行時(shí)壓縮并且用別的方式處理客戶終端300與web服務(wù)器400之間傳遞的過程業(yè)務(wù)(經(jīng)由通信模塊210)以便提供由web服務(wù)器400在客戶終端300的請(qǐng)求時(shí)發(fā)送到客戶終端300的內(nèi)容的不顯眼和透明壓縮，如將在下面解釋的。
[0034]其中可實(shí)現(xiàn)PEP 200的通用種類的可編程信號(hào)處理設(shè)備的示例在圖3中示出。示出的信號(hào)處理設(shè)備600除通信模塊230外還包括處理器610、工作存儲(chǔ)器620和存儲(chǔ)計(jì)算機(jī)可讀指令的指令存儲(chǔ)630，該計(jì)算 機(jī)可讀指令在被處理器610執(zhí)行時(shí)促使處理器610在進(jìn)行下文描述的處理操作來處理客戶終端300與web服務(wù)器400之間的通信中的包并且以便以高效且不顯眼的方式進(jìn)行由web服務(wù)器400提供的內(nèi)容的流壓縮方面起到PEP 200的作用。[0035]指令存儲(chǔ)630是數(shù)據(jù)存儲(chǔ)裝置，該數(shù)據(jù)存儲(chǔ)裝置可包括例如采用ROM、磁性計(jì)算機(jī)存儲(chǔ)裝置(例如，硬盤)或光盤形式的非易失性存儲(chǔ)器，其可預(yù)先加載有計(jì)算機(jī)可讀指令。備選地，指令存儲(chǔ)630可包括易失性存儲(chǔ)器(例如，DRAM或SRAM)，并且計(jì)算機(jī)可讀指令可以例如計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)640 (例如光盤,例如CD-ROM、DVD-ROM,等)或攜帶計(jì)算機(jī)可讀指令的計(jì)算機(jī)可讀信號(hào)650等計(jì)算機(jī)程序產(chǎn)品輸入到此。
[0036]工作存儲(chǔ)器620起到暫時(shí)存儲(chǔ)數(shù)據(jù)來支持根據(jù)存儲(chǔ)在指令存儲(chǔ)630中存儲(chǔ)的處理邏輯而執(zhí)行的處理操作的作用。如在圖3中示出的，通信模塊230設(shè)置成與處理器610通信以便致使信號(hào)處理設(shè)備600能夠處理接收的信號(hào)并且傳達(dá)它的處理結(jié)果。
[0037]處理器610、工作存儲(chǔ)器620和指令存儲(chǔ)630 (在適當(dāng)?shù)赜杀绢I(lǐng)域內(nèi)技術(shù)人員所熟知的技術(shù)編程時(shí))在一起的組合660構(gòu)成在圖2中示出的PEP 200的數(shù)據(jù)報(bào)檢查模塊210、數(shù)據(jù)壓縮模塊220和報(bào)頭修改模塊240。組合660還進(jìn)行在本文描述的PEP 200的其他操作。[0038]在本實(shí)施例中，PDP 500是有權(quán)做出關(guān)于在附連到電信網(wǎng)絡(luò)的客戶終端300中終止和/或起始于它的數(shù)據(jù)流的數(shù)據(jù)包并且要由路由數(shù)據(jù)包的PEP 200實(shí)施的策略決定的網(wǎng)絡(luò)節(jié)點(diǎn)。在本實(shí)施例中，PDP 500作為獨(dú)立于PEP 200的網(wǎng)絡(luò)節(jié)點(diǎn)(例如設(shè)置成經(jīng)由任何適合的工具(例如，LAN或互聯(lián)網(wǎng))而與實(shí)現(xiàn)PEP 200的服務(wù)器通信的獨(dú)立服務(wù)器)的部分而提供。然而，PDP 500的功能可備選地或另外由PEP 200的硬件提供；例如，一個(gè)或多個(gè)數(shù)據(jù)壓縮策略可存儲(chǔ)在圖3中示出的信號(hào)處理設(shè)備的指令存儲(chǔ)640中。
[0039]由本實(shí)施例的PEP 200進(jìn)行來處理流數(shù)據(jù)的操作將參考圖4和5描述。
[0040]首先參考圖4，在步驟SlO中，客戶終端300建立到web服務(wù)器400的TCP連接并且向web服務(wù)器400發(fā)送HTTP請(qǐng)求,從而請(qǐng)求web服務(wù)器400向客戶終端300發(fā)送某些請(qǐng)求內(nèi)容(例如，與存儲(chǔ)在服務(wù)器400中的特定URL關(guān)聯(lián)的內(nèi)容)。PEP 200將HTTP請(qǐng)求路由到web服務(wù)器400。
[0041]在步驟S20中，PEP 200的數(shù)據(jù)報(bào)檢查模塊210進(jìn)行DPI來確定客戶終端的請(qǐng)求是否符合支持作為可選特征的內(nèi)容壓縮的適合通信協(xié)議。在本實(shí)施例中，HTTP/1.1被視為這樣的協(xié)議的示例。如果請(qǐng)求在步驟S20中確定為不是HTTP/1.1請(qǐng)求，則PEP 200確定它將不壓縮對(duì)于請(qǐng)求的任何響應(yīng)的內(nèi)容，并且在客戶端300與服務(wù)器400之間流動(dòng)的數(shù)據(jù)包通過未更改的PEP 200而行進(jìn)，從而繞過它的壓縮機(jī)構(gòu)。
[0042]PEP 200進(jìn)行DPI以通過在接收的IP數(shù)據(jù)報(bào)中的至少一個(gè)中檢查層7協(xié)議的控制信息(其超出IP數(shù)據(jù)報(bào)中的IP 5元組而定位)來識(shí)別通信協(xié)議。在利用互聯(lián)網(wǎng)協(xié)議作為用于數(shù)據(jù)傳送的網(wǎng)絡(luò)(間)-級(jí)協(xié)議的數(shù)據(jù)通信中，已知IP 5元組包括:源傳輸端口(即，關(guān)于源的OSI層4信息)、源IP地址(即，關(guān)于源的OSI層3信息)、目的地傳輸端口(即，關(guān)于目的地的OSI層4信息)、目的地IP地址卿，關(guān)于目的地的OSI層3信息)和通過IP協(xié)議(例如，TCP、UDP，等)的協(xié)議的標(biāo)識(shí)符。這些信息元素定位在IP數(shù)據(jù)報(bào)的開始處。本質(zhì)上，DPI包括檢查并且分析超出那些信息元素的IP數(shù)據(jù)報(bào)的內(nèi)容，即包括對(duì)應(yīng)于在IP數(shù)據(jù)報(bào)內(nèi)輸送的上層通信層的有效載荷。
[0043]另一方面，如果數(shù)據(jù)報(bào)檢查模塊210在步驟S20中確定請(qǐng)求是HTTP/1.1請(qǐng)求，過程行進(jìn)到步驟S40，其中數(shù)據(jù)報(bào)檢查模塊210確定客戶終端300是否支持內(nèi)容壓縮。如果客戶終端300已經(jīng)向web服務(wù)器400指示它接受HTTP請(qǐng)求中的接受-編碼報(bào)頭中的壓縮內(nèi)容的意愿，有力壓縮對(duì)于客戶終端300確定為可接受的，否則過程行進(jìn)到步驟S30并且繞過PEP 200的壓縮機(jī)構(gòu)。
[0044]在步驟S50中，web服務(wù)器400接收HTTP請(qǐng)求并且通過朝客戶終端300發(fā)送包含請(qǐng)求內(nèi)容的HTTP響應(yīng)而作出響應(yīng)。
[0045]然后，在步驟S60中，朝客戶終端300路由HTTP響應(yīng)的PEP 200對(duì)HTTP響應(yīng)的一個(gè)或多個(gè)IP數(shù)據(jù)報(bào)進(jìn)行DPI。更具體地，數(shù)據(jù)報(bào)檢查模塊210確定HTTP響應(yīng)的IP數(shù)據(jù)報(bào)(其已經(jīng)由web服務(wù)器400發(fā)送并且由PEP 200的通信模塊230接收)未被壓縮但可以根據(jù)存儲(chǔ)在I3DP 500中的至少一個(gè)數(shù)據(jù)壓縮策略來壓縮。為了做出該確定，數(shù)據(jù)報(bào)檢查模塊210采用DPI技術(shù)來檢查HTTP控制信息，其超出IP數(shù)據(jù)報(bào)中的IP 5元組而定位。特別地，HTTP內(nèi)容-類型(Content-Type)報(bào)頭的值連同內(nèi)容-編碼報(bào)頭在響應(yīng)中的缺乏可以用于識(shí)別未壓縮內(nèi)容。在步驟S60中，數(shù)據(jù)報(bào)檢查模塊210還檢查IP數(shù)據(jù)報(bào)中的內(nèi)容-類型報(bào)頭并且做出被指示的內(nèi)容類型(例如，text/html、text/javascript、text/css,等)的記錄。
[0046]如果HTTP響應(yīng)的內(nèi)容在步驟S60中確定為不適合于壓縮，過程行進(jìn)到步驟S30并且繞過PEP 200的壓縮機(jī)構(gòu)，否則過程繼續(xù)到步驟S70。
[0047]在步驟S70中，數(shù)據(jù)報(bào)檢查模塊210在步驟S60中識(shí)別的內(nèi)容類型的基礎(chǔ)上確定由web服務(wù)器400交付的內(nèi)容是否應(yīng)被PEP 200壓縮。如果確定內(nèi)容不應(yīng)被壓縮，則過程行進(jìn)到步驟S30并且繞過PEP 200的壓縮機(jī)構(gòu)，否則數(shù)據(jù)報(bào)檢查模塊210在步驟S80中確定PEP 200配置成應(yīng)用的壓縮方法是否被客戶終端300支持。如果配置的壓縮方法與客戶端300兼容，則web服務(wù)器的響應(yīng)的流壓縮在步驟S90中進(jìn)行，否則過程行進(jìn)到步驟S30并且繞過PEP 200的壓縮機(jī)構(gòu)。
[0048]在本實(shí)施例中，步驟S70和S80中的確定由數(shù)據(jù)報(bào)檢查模塊210根據(jù)存儲(chǔ)在I3DP500中的一個(gè)或多個(gè)壓縮策略做出，該一個(gè)或多個(gè)壓縮策略可以從I3DP 500傳送到PEP200，或可以在PEP 200中本地配置。數(shù)據(jù)壓縮策略可基于客戶終端300的記錄，其已經(jīng)在對(duì)web服務(wù)器400的請(qǐng)求中包括客戶終端300能夠?qū)嚎s的IP數(shù)據(jù)報(bào)解壓縮來提取其中的數(shù)據(jù)的指示。
[0049]另外或備選地，數(shù)據(jù)壓縮策略可基于存儲(chǔ)的與客戶終端300關(guān)聯(lián)的簡(jiǎn)檔數(shù)據(jù)或它的標(biāo)識(shí)符中的任一個(gè)，其可以指示客戶終端300是否能夠?qū)嚎s的IP數(shù)據(jù)報(bào)解壓縮來提取其中的數(shù)據(jù)或起初未被壓縮的內(nèi)容是否要對(duì)于所述終端壓縮。在該情況下，可詢問rop 500來確定與客戶終端300有關(guān)的簡(jiǎn)檔數(shù)據(jù)(例如，基于由所述客戶端提交的標(biāo)識(shí)符，其由電信網(wǎng)絡(luò)中的節(jié)點(diǎn)與對(duì)應(yīng)的簡(jiǎn)檔數(shù)據(jù)有關(guān)地存儲(chǔ)，并且其可以確定在識(shí)別的客戶端中起始或終止的數(shù)據(jù)流的某些處理)是否指示客戶終端300根據(jù)所述簡(jiǎn)檔中的數(shù)據(jù)而能夠?qū)嚎s的IP數(shù)據(jù)報(bào)解壓縮，或起初未被壓縮的內(nèi)容是否要被壓縮。
[0050]除上文的選項(xiàng)中的任一個(gè)或兩個(gè)外或作為其的另外備選方案，數(shù)據(jù)壓縮策略可基于限定允許接收IP數(shù)據(jù)報(bào)包含的數(shù)據(jù)的類型的信息。
[0051]在本實(shí)施例中，步驟S70和S80中的確定由數(shù)據(jù)報(bào)檢查模塊210參考存儲(chǔ)在I3DP500中的壓縮策略表而做出，該壓縮策略表形成PEP的部分(盡管I3DP 500可備選地是PEP200外部但可被PEP 200訪問的外部網(wǎng)絡(luò)節(jié)點(diǎn)，如上文指出的)。在做出的步驟S70和S80中的確定的基礎(chǔ)上，表中的信息包括(除其他信息外)客戶終端300是否接受壓縮內(nèi)容、起初由web服務(wù)器400交付的內(nèi)容的類型的指示、起初由web服務(wù)器400交付的內(nèi)容是否已經(jīng)被壓縮以及要應(yīng)用于內(nèi)容的壓縮技術(shù)(如有的話)的指示。
[0052]例如，在本實(shí)施例中，策略表基于內(nèi)容-類型、內(nèi)容-編碼和傳遞-編碼報(bào)頭，如在下頁的表1中示出的(可由rop 500存儲(chǔ)的與端點(diǎn)有關(guān)聯(lián)的其他簡(jiǎn)檔數(shù)據(jù)為了清楚起見而被省略)。
【權(quán)利要求】
1.一種電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)(200 ;2000)，其能操作成在電信網(wǎng)絡(luò)中的第一端點(diǎn)(300)與所述電信網(wǎng)絡(luò)中的第二端點(diǎn)(400)之間的雙向通信中路由IP數(shù)據(jù)報(bào)并且能操作成根據(jù)數(shù)據(jù)壓縮策略來壓縮由所述第二端點(diǎn)(400)傳送到所述第一端點(diǎn)(300)的響應(yīng)的IP數(shù)據(jù)報(bào)，每個(gè)IP數(shù)據(jù)報(bào)包括數(shù)據(jù)的字節(jié)序列和限定所述IP數(shù)據(jù)報(bào)中的數(shù)據(jù)的第一字節(jié)的序列號(hào)的報(bào)頭，所述響應(yīng)是支持壓縮的層7協(xié)議的，其中層級(jí)在開放系統(tǒng)互連OSI參考模型的意義上理解，所述電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)(200 ；2000)包括: 數(shù)據(jù)報(bào)檢查模塊(210)，其能操作成確定從所述第二端點(diǎn)(400)發(fā)送并且被所述策略實(shí)施點(diǎn)(200 ;2000)接收的IP數(shù)據(jù)報(bào)是否未被壓縮但能通過在接收的IP數(shù)據(jù)報(bào)中的至少一個(gè)中檢查所述層7協(xié)議的控制信息而根據(jù)所述數(shù)據(jù)壓縮策略來壓縮，所述控制信息超出IP數(shù)據(jù)報(bào)中的IP5元組而定位； 數(shù)據(jù)壓縮模塊(220)，其能操作成響應(yīng)于所述數(shù)據(jù)報(bào)檢查模塊(210)確定接收的IP數(shù)據(jù)報(bào)未被壓縮但能壓縮而壓縮接收的IP數(shù)據(jù)報(bào)中的至少一些中的數(shù)據(jù)，由此生成壓縮IP數(shù)據(jù)報(bào)用于傳送到所述第一端點(diǎn)(300)； 報(bào)頭修改模塊(240)，其能操作成修改壓縮IP數(shù)據(jù)報(bào)中的報(bào)頭來考慮由所述數(shù)據(jù)壓縮模塊(220)對(duì)在其中的數(shù)據(jù)壓縮所引起的一個(gè)或多個(gè)之前的IP數(shù)據(jù)報(bào)中字節(jié)數(shù)量中的減少以便確保由所述第二端點(diǎn)(400)傳送到所述第一端點(diǎn)(300)的響應(yīng)中的相鄰壓縮IP數(shù)據(jù)報(bào)之間的所述序列號(hào)的連續(xù)性；和 通信模塊(230)，其能操作成將壓縮IP數(shù)據(jù)報(bào)傳送到所述第一端點(diǎn)(300)并且從其處接收所述壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)， 其中所述報(bào)頭修改模塊(240)進(jìn)一步能操作成響應(yīng)于由所述通信模塊(230)接收所述確認(rèn)而生成對(duì)應(yīng)的未壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)以由所述通信模塊傳送到所述第二端點(diǎn)(400)。
2.如權(quán)利要求1所述的電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)，其中所述響應(yīng)包括響應(yīng)報(bào)頭和內(nèi)容，并且所述響應(yīng)報(bào)頭包括指示所述響應(yīng)中的內(nèi)容的長(zhǎng)度的內(nèi)容長(zhǎng)度指示符，并且其中所述數(shù)據(jù)壓縮模塊(220)進(jìn)一步能操作成: 從所述響應(yīng)去除所述內(nèi)容長(zhǎng)度指示符； 在由所述電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)(200 ;2000)接收所述響應(yīng)的最后IP數(shù)據(jù)報(bào)之前壓縮所述響應(yīng)的接收IP數(shù)據(jù)報(bào)中的數(shù)據(jù)；以及 使壓縮數(shù)據(jù)編碼成數(shù)據(jù)塊來生成編碼的壓縮響應(yīng)用于由所述通信模塊(230 )傳送到所述第一端點(diǎn)(300)，所述編碼的壓縮響應(yīng)包括已經(jīng)應(yīng)用編碼的指示。
3.如權(quán)利要求1或2所述的電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)，其能操作成路由并且壓縮HTTP/1.1響應(yīng)的IP數(shù)據(jù)報(bào)，其中所述響應(yīng)包括內(nèi)容-長(zhǎng)度報(bào)頭，并且其中所述數(shù)據(jù)壓縮模塊(220)能操作成: 從所述響應(yīng)去除所述內(nèi)容-長(zhǎng)度報(bào)頭； 執(zhí)行HTTP兼容壓縮算法以在由所述電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)(200 ;2000)接收所述響應(yīng)的最后IP數(shù)據(jù)報(bào)之前壓縮接收的IP數(shù)據(jù)報(bào)中的數(shù)據(jù)；以及 對(duì)壓縮數(shù)據(jù)應(yīng)用成塊傳遞編碼來生成傳遞編碼響應(yīng)，所述傳遞編碼響應(yīng)包括傳遞-編碼報(bào)頭用于傳送到所述第一端點(diǎn)(300 )。
4.如上述權(quán)利要求中任一項(xiàng)所述的電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)，其中所述數(shù)據(jù)壓縮策略基于以下中的至少一個(gè): 所述第一端點(diǎn)(300)使所述第一端點(diǎn)(300)能夠?qū)嚎sIP數(shù)據(jù)報(bào)解壓縮以提取其中的數(shù)據(jù)的指示包括在對(duì)所述第二端點(diǎn)(400)的請(qǐng)求中的記錄； 指示所述第一端點(diǎn)(300)能夠?qū)嚎sIP數(shù)據(jù)報(bào)解壓縮以提取其中的數(shù)據(jù)或指示要傳送到所述第一端點(diǎn)(300)的起初未被壓縮的IP數(shù)據(jù)能被壓縮的所述第一端點(diǎn)的存儲(chǔ)簡(jiǎn)檔數(shù)據(jù)；以及 限定允許接收的IP數(shù)據(jù)報(bào)包含的數(shù)據(jù)的類型的信息。
5.一種策略和計(jì)費(fèi)控制PCC架構(gòu)電信網(wǎng)絡(luò)的策略和計(jì)費(fèi)實(shí)施功能PCEF節(jié)點(diǎn)(2000)，其包括如上述權(quán)利要求中任一項(xiàng)實(shí)施的電信網(wǎng)絡(luò)策略實(shí)施點(diǎn)(200)，其中所述PCEF節(jié)點(diǎn)(2000)能操作成經(jīng)由Gx接口與策略和計(jì)費(fèi)規(guī)則功能PCRF節(jié)點(diǎn)(5000)通信來獲得數(shù)據(jù)壓縮策略。
6.一種在電信網(wǎng)絡(luò)中的第一端點(diǎn)(300)與所述電信網(wǎng)絡(luò)中的第二端點(diǎn)(400)之間的雙向通信中由策略實(shí)施點(diǎn)(200，2000)路由IP數(shù)據(jù)報(bào)并且根據(jù)數(shù)據(jù)壓縮策略壓縮由所述第二端點(diǎn)(400)傳送到所述第一端點(diǎn)(300)的響應(yīng)的IP數(shù)據(jù)報(bào)的方法，每個(gè)IP數(shù)據(jù)報(bào)包括數(shù)據(jù)的字節(jié)序列和限定所述IP數(shù)據(jù)報(bào)中的數(shù)據(jù)的第一字節(jié)的序列號(hào)的報(bào)頭，所述響應(yīng)是支持壓縮的層7協(xié)議，其中層級(jí)在開放系統(tǒng)互連OSI參考模型的意義上理解，所述方法包括: 確定(S60 ；S200)由所述第二端點(diǎn)(400)發(fā)送的IP數(shù)據(jù)報(bào)是否未被壓縮但能通過在接收的IP數(shù)據(jù)報(bào)中的至少一個(gè)中檢查所述層7協(xié)議的控制信息而根據(jù)所述數(shù)據(jù)壓縮策略來壓縮，所述控制信息 超出所述IP數(shù)據(jù)報(bào)中的IP5元組而定位；響應(yīng)于確定接收的IP數(shù)據(jù)報(bào)未被壓縮但能被壓縮來壓縮(SI 10 ;S210)所述接收的IP數(shù)據(jù)報(bào)中的至少一些中的數(shù)據(jù)，由此生成壓縮IP數(shù)據(jù)報(bào)用于傳送到所述第一端點(diǎn)(300)；修改(S130 ;S220)壓縮的IP數(shù)據(jù)報(bào)中的報(bào)頭來考慮其中的數(shù)據(jù)壓縮所引起的一個(gè)或多個(gè)之前的IP數(shù)據(jù)報(bào)中的字節(jié)的數(shù)量中的減少以便確保在由所述第二端點(diǎn)(400)傳送到所述第一端點(diǎn)(300)的響應(yīng)中的相鄰壓縮IP數(shù)據(jù)報(bào)之間的所述序列號(hào)的連續(xù)性； 將所述壓縮的IP數(shù)據(jù)報(bào)傳送(S140 ；S230)到所述第一端點(diǎn)(300)并且從其處接收所述壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)； 響應(yīng)于所述確認(rèn)的接收，生成(S150 ;S240)對(duì)應(yīng)的未壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)用于傳送到所述第二端點(diǎn)(400);以及 將所述對(duì)應(yīng)的未壓縮IP數(shù)據(jù)報(bào)的接收的確認(rèn)傳送(S160;S250)到所述第二端點(diǎn)(400)。
7.如權(quán)利要求6所述的方法，其中所述響應(yīng)包括響應(yīng)報(bào)頭和內(nèi)容，并且所述響應(yīng)報(bào)頭包括指示所述響應(yīng)中的內(nèi)容的長(zhǎng)度的內(nèi)容長(zhǎng)度指示符，并且其中接收的IP數(shù)據(jù)報(bào)中的數(shù)據(jù)通過以下來壓縮: 從所述響應(yīng)去除(SlOO)所述內(nèi)容長(zhǎng)度指示符； 在接收所述響應(yīng)的最后IP數(shù)據(jù)報(bào)之前壓縮(Slio)所述響應(yīng)的接收IP數(shù)據(jù)報(bào)中的數(shù)據(jù)；以及 使壓縮數(shù)據(jù)編碼(S120)成數(shù)據(jù)塊來生成編碼的壓縮響應(yīng)用于傳送到所述第一端點(diǎn)(300),所述編碼的壓縮響應(yīng)包括已經(jīng)應(yīng)用編碼的指示。
8.如權(quán)利要求6或7所述的方法，其中HTTP/1.1響應(yīng)的IP數(shù)據(jù)報(bào)被路由和壓縮，其中所述響應(yīng)包括內(nèi)容-長(zhǎng)度報(bào)頭，并且其中所述接收的IP數(shù)據(jù)報(bào)中的數(shù)據(jù)通過以下來壓縮: 從所述響應(yīng)去除(SlOO)所述內(nèi)容-長(zhǎng)度報(bào)頭； 執(zhí)行(S110)HTTP兼容壓縮算法以在接收所述響應(yīng)的最后IP數(shù)據(jù)報(bào)之前壓縮所述接收的IP數(shù)據(jù)報(bào)中的數(shù)據(jù)；以及 對(duì)壓縮數(shù)據(jù)應(yīng)用成塊傳遞編碼(S120)來生成傳遞編碼響應(yīng)，所述傳遞編碼響應(yīng)包括傳遞-編碼報(bào)頭用于傳送到所述第一端點(diǎn)(300)。
9.如權(quán)利要求6-8中任一項(xiàng)所述的方法，其中所述數(shù)據(jù)壓縮策略基于以下中的至少一個(gè): 所述第一端點(diǎn)(300)使所述第一端點(diǎn)(300)能夠?qū)嚎sIP數(shù)據(jù)報(bào)解壓縮以提取其中的數(shù)據(jù)的指示包括在對(duì)所述第二端點(diǎn)(400)的請(qǐng)求中的記錄； 指示所述第一端點(diǎn)(300)能夠?qū)嚎sIP數(shù)據(jù)報(bào)解壓縮以提取其中的數(shù)據(jù)或指示要傳送到所述第一端點(diǎn)(300)的起初未被壓縮的IP數(shù)據(jù)能被壓縮的所述第一端點(diǎn)(300)的存儲(chǔ)簡(jiǎn)檔數(shù)據(jù)；以及 限定允許接收的IP數(shù)據(jù)報(bào)包含的數(shù)據(jù)的類型的信息。
10.如權(quán)利要求6-9中任一項(xiàng)所述的方法，其中所述策略實(shí)施點(diǎn)是策略和計(jì)費(fèi)控制PCC架構(gòu)電信網(wǎng)絡(luò)的策略和計(jì)費(fèi)實(shí)施功能PCEF節(jié)點(diǎn)(2000)。
11.一種存儲(chǔ)計(jì)算機(jī)程序指令的計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)(640)，所述計(jì)算機(jī)程序指令在被處理器(610)執(zhí)行時(shí)促使所述處理器(610)進(jìn)行如在權(quán)利要求6-10中的至少一個(gè)中闡述的方法。
12.—種攜帶計(jì)算機(jī)程序指令的信號(hào)(650)，所述計(jì)算機(jī)程序指令在被處理器(610)執(zhí)行時(shí)促使所述處理器(610)進(jìn)行如在權(quán)利要求6-10中的至少一個(gè)中闡述的方法。
【文檔編號(hào)】H04L29/08GK103907327SQ201180074566
【公開日】2014年7月2日 申請(qǐng)日期:2011年11月3日 優(yōu)先權(quán)日:2011年11月3日
【發(fā)明者】I.戈奇加西亞 申請(qǐng)人:瑞典愛立信有限公司