本發(fā)明涉及數(shù)據(jù)業(yè)務(wù)領(lǐng)域，尤其涉及一種數(shù)據(jù)業(yè)務(wù)的處理方法及裝置。

背景技術(shù)：

隨著長期演進(Long Term Evolution，LTE)網(wǎng)絡(luò)的部署，移動網(wǎng)絡(luò)流量將出現(xiàn)爆發(fā)性增長，移動核心網(wǎng)面臨潛在的巨大流量壓力。為應(yīng)對流量增長挑戰(zhàn)，部署面向無線網(wǎng)絡(luò)的內(nèi)容分發(fā)網(wǎng)絡(luò)(Content Distribution Network，CDN)服務(wù)節(jié)點，即移動內(nèi)容分發(fā)網(wǎng)絡(luò)(Mobile CDN，MCDN)服務(wù)節(jié)點，為緩解核心網(wǎng)流量壓力提供了思路。

LTE網(wǎng)絡(luò)環(huán)境下，演進的分組核心網(wǎng)(Evolved Packet Core，EPC)成為MCDN服務(wù)節(jié)點的主要放置位置?，F(xiàn)有的相關(guān)技術(shù)中，將MCDN服務(wù)節(jié)點部署在EPC的重要網(wǎng)元服務(wù)網(wǎng)關(guān)(Serving Gate Way，SGW)中，這樣在進行數(shù)據(jù)業(yè)務(wù)時，用戶終端會通過基站向MME發(fā)起業(yè)務(wù)請求，然后由MME分析用戶請求類型，若符合MCDN服務(wù)類型，則轉(zhuǎn)發(fā)至MCDN服務(wù)節(jié)點，然后在MCDN服務(wù)節(jié)點中檢索是否有匹配資源，若有則返回被請求內(nèi)容。若沒有還可以通過在MCDN服務(wù)節(jié)點網(wǎng)絡(luò)內(nèi)的其他MCDN服務(wù)節(jié)點來查找該匹配資源，即先通過資源查詢檢索目錄確定所需資源所在的MCDN服務(wù)節(jié)點，然后將該請求轉(zhuǎn)發(fā)至可提供數(shù)據(jù)的MCDN服務(wù)節(jié)點。

上述過程中，用戶終端的業(yè)務(wù)請求都需要通過基站和MME的轉(zhuǎn)發(fā)才能到MCDN服務(wù)節(jié)點，增加了MME的工作量，并且確定所需資源所在的MCDN服務(wù)節(jié)點是通過檢索資源查詢目錄實現(xiàn)的，隨著網(wǎng)絡(luò)資源數(shù)量不斷膨脹，這必然導(dǎo)致檢索效率的下降，同時這種集中式的管理也會限制MCDN服務(wù)節(jié)點網(wǎng)絡(luò)的規(guī)模。

技術(shù)實現(xiàn)要素：

有鑒于此，本發(fā)明實施例期望提供一種數(shù)據(jù)業(yè)務(wù)的處理方法，可以提高業(yè)務(wù)處理效率。

為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的：

一種數(shù)據(jù)業(yè)務(wù)的處理方法，所述方法包括：

向具有移動內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN服務(wù)功能的基站發(fā)送配置的緩存策略和路由策略；

其中，所述緩存策略用于指示所述基站需要緩存在緩存庫CS中的數(shù)據(jù)包，所述路由策略用于所述基站更新轉(zhuǎn)發(fā)信息表FIB。

上述方案中，所述方法還包括：

接收所述基站上報的攜帶有內(nèi)容名的請求包；

根據(jù)回源策略確定所述請求包對應(yīng)的回源點，向所述基站發(fā)送所述回源點IP；或者，根據(jù)回源策略確定所述請求包對應(yīng)的回源點，向所述回源點發(fā)送所述請求包，接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包；并將所述數(shù)據(jù)包發(fā)送給基站；所述回源點包括內(nèi)容中心或內(nèi)容源。

上述方案中，所述方法還包括：

接收第三方設(shè)備發(fā)送的內(nèi)容注入請求，所述內(nèi)容注入請求中攜帶有注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址；

向基站發(fā)送內(nèi)容注入通知，所述內(nèi)容注入通知包括所述注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址。

上述方案中，所述內(nèi)容注入請求中還包括注入基站ID，則所述向基站發(fā)送內(nèi)容注入通知，包括：向所述注入基站ID標(biāo)識的基站發(fā)送內(nèi)容注入通知；

或者，所述向基站發(fā)送內(nèi)容注入通知，包括：向自主分配的基站發(fā)送內(nèi)容注入通知。

上述方案中，所述方法還包括：

接收第三方終端發(fā)送的內(nèi)容刪除請求，所述內(nèi)容刪除請求中攜帶有刪除內(nèi) 容名；

向存儲有所述刪除內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)的基站，發(fā)送內(nèi)容刪除通知，所述內(nèi)容刪除通知包括所述刪除內(nèi)容名。

一種數(shù)據(jù)業(yè)務(wù)的處理方法，所述方法包括：

接收內(nèi)容中心網(wǎng)絡(luò)CCN控制器發(fā)送緩存策略和路由策略；所述緩存策略用于通知需要緩存在緩存庫CS中的數(shù)據(jù)包；

根據(jù)所述路由策略更新轉(zhuǎn)發(fā)信息表FIB；

接收攜帶有第一內(nèi)容名及其對應(yīng)內(nèi)容數(shù)據(jù)的數(shù)據(jù)包，在所述第一內(nèi)容名與預(yù)存的緩存庫CS匹配不成功，與預(yù)存的未決請求表PIT匹配成功時，將所述數(shù)據(jù)包轉(zhuǎn)發(fā)給用戶終端，并根據(jù)所述緩存策略判斷是否對所述數(shù)據(jù)包進行緩存；

若是，則緩存到所述CS中；若不是，則丟棄所述數(shù)據(jù)包；

接收攜帶有第二內(nèi)容名的請求包，在所述第二內(nèi)容名與預(yù)存CS和PIT都匹配不成功，與更新后的轉(zhuǎn)發(fā)信息表FIB匹配成功時，將所述請求包發(fā)送給所述更新后的FIB中匹配成功的下一跳接口。

上述方案中，在接收攜帶有第二內(nèi)容名的請求包后，所述方法還包括：

在所述第二內(nèi)容名與預(yù)存的CS、PIT和FIB都未匹配成功時，將所述請求包發(fā)送給所述CCN控制器；

接收所述CCN控制器返回的回源點IP，根據(jù)所述回源點IP向回源點發(fā)送所述請求包，接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包；

或者，接收所述CCN控制器返回的所述請求包對應(yīng)的數(shù)據(jù)包。

上述方案中，所述方法還包括：

接收所述CCN控制器發(fā)送的內(nèi)容注入通知，所述內(nèi)容注入通知包括注入內(nèi)容名以及注入內(nèi)容所在內(nèi)容源的IP地址；

根據(jù)所述內(nèi)容源的IP地址獲取所述注入內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，在所述CS中緩存所述注入內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。

上述方案中，接收所述CCN控制器發(fā)送的內(nèi)容刪除通知，所述內(nèi)容刪除通知中攜帶有刪除內(nèi)容名；

刪除所述CS中所述刪除內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。

上述方案中，所述將所述數(shù)據(jù)包轉(zhuǎn)發(fā)給用戶終端或者將所述請求包發(fā)送給所述更新后的FIB中匹配成功的下一跳接口時，通過X2接口進行轉(zhuǎn)發(fā)。

一種CCN控制器，所述控制器包括：

第一發(fā)送單元，用于向具有移動內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN服務(wù)功能的基站發(fā)送配置的緩存策略和路由策略；其中，所述緩存策略用于指示所述基站需要緩存在緩存庫CS中的數(shù)據(jù)包，所述路由策略用于所述基站更新轉(zhuǎn)發(fā)信息表FIB。

上述方案中，所述控制器還包括：第一接收單元和第一處理單元，其中，

第一接收單元，用于接收所述基站上報的攜帶有內(nèi)容名的請求包；

第一處理單元，用于根據(jù)回源策略確定所述第一接收單元接收的請求包對應(yīng)的回源點；所述回源點包括內(nèi)容中心或內(nèi)容源；

所述第一發(fā)送單元，還用于向所述基站發(fā)送所述第一處理單元確定的回源點IP；或者，向所述第一處理單元確定的回源點發(fā)送所述請求包；

所述第一接收單元，還用于接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包；

所述第一發(fā)送單元，還用于將所述第一接收單元接收到的數(shù)據(jù)包發(fā)送給基站；

所述第一接收單元，還用于接收第三方設(shè)備發(fā)送的內(nèi)容注入請求，所述內(nèi)容注入請求中攜帶有注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址；

所述第一發(fā)送單元，還用于向基站發(fā)送內(nèi)容注入通知，所述內(nèi)容注入通知包括所述注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址；

所述第一接收單元，還用于接收第三方終端發(fā)送的內(nèi)容刪除請求，所述內(nèi)容刪除請求中攜帶有刪除內(nèi)容名；

所述第一發(fā)送單元，還用于向存儲有所述第一接收單元接收到的刪除內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)的基站，發(fā)送內(nèi)容刪除通知，所述內(nèi)容刪除通知包括所述刪除內(nèi)容名。

上述方案中，所述內(nèi)容注入請求中還包括注入基站ID，則所述第一發(fā)送單 元，具體用于向所述注入基站ID標(biāo)識的基站發(fā)送內(nèi)容注入通知；

或者，所述第一發(fā)送單元，具體用于向自主分配的基站發(fā)送內(nèi)容注入通知。

一種具有移動內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN服務(wù)功能的基站，所述基站包括：

第二接收單元，用于接收內(nèi)容中心網(wǎng)絡(luò)CCN控制器發(fā)送緩存策略和路由策略；所述緩存策略用于通知需要緩存在緩存庫CS中的數(shù)據(jù)包；

第二處理單元，用于根據(jù)所述第二接收單元接收到的路由策略更新轉(zhuǎn)發(fā)信息表FIB；

第二接收單元，還用于接收攜帶有第一內(nèi)容名及其對應(yīng)內(nèi)容數(shù)據(jù)的數(shù)據(jù)包；

所述第二發(fā)送單元，用于在所述第一內(nèi)容名與預(yù)存的緩存庫CS匹配不成功，與預(yù)存的未決請求表PIT匹配成功時，將所述數(shù)據(jù)包轉(zhuǎn)發(fā)給用戶終端；

所述第二處理單元，還用于在所述第一內(nèi)容名與預(yù)存的緩存庫CS匹配不成功，與預(yù)存的未決請求表PIT匹配成功時，根據(jù)所述第二接收單元接收到的緩存策略判斷是否對所述數(shù)據(jù)包進行緩存；若是，則緩存到所述CS中；若不是，則丟棄所述數(shù)據(jù)包；

第二接收單元，還用于接收攜帶有第二內(nèi)容名的請求包；

所述第二發(fā)送單元，還用于在所述第二內(nèi)容名與預(yù)存CS和PIT都匹配不成功，與更新后的轉(zhuǎn)發(fā)信息表FIB匹配成功時，將所述第二接收單元接收到的請求包發(fā)送給所述更新后的FIB中匹配成功的下一跳接口。

上述方案中，所述第二發(fā)送單元，還用于在所述第二內(nèi)容名與預(yù)存的CS、PIT和FIB都未匹配成功時，將所述第二接收單元接收到的請求包發(fā)送給所述CCN控制器；

所述第二接收單元，還用于接收所述CCN控制器返回的回源點IP；

所述第二發(fā)送單元，還用于根據(jù)所述第二接收單元接收到的回源點IP向回源點發(fā)送所述請求包；

所述第二接收單元，還用于接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包；或者，所述第二接收單元，還用于接收所述CCN控制器返回的所述請求包對應(yīng)的數(shù)據(jù)包。

所述第二接收單元，還用于接收所述CCN控制器發(fā)送的內(nèi)容注入通知，所述內(nèi)容注入通知包括注入內(nèi)容名以及注入內(nèi)容所在內(nèi)容源的IP地址；

所述第二處理單元，還用于根據(jù)所述第二接收單元接收的內(nèi)容源的IP地址獲取所述注入內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，在所述CS中緩存所述注入內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)；

所述第二接收單元，還用于接收所述CCN控制器發(fā)送的內(nèi)容刪除通知，所述內(nèi)容刪除通知中攜帶有刪除內(nèi)容名；

所述第二處理單元，還用于刪除所述CS中所述第二接收單元接收的刪除內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。

本發(fā)明實施例提供了一種數(shù)據(jù)業(yè)務(wù)的處理方法，通過將MCDN服務(wù)功能部署在基站上，由這些基站構(gòu)成CCN，各基站間通過X2接口采用CCN通信模式進行通信，由CCN控制器管控CCN中的各基站。這樣基站可以直接處理用戶終端的數(shù)據(jù)請求業(yè)務(wù)，采用基于內(nèi)容的路由可以有效避免頻繁的請求上報，降低核心網(wǎng)工作負(fù)擔(dān)，提高業(yè)務(wù)處理效率，并且CCN是一種基于內(nèi)容的通信網(wǎng)絡(luò)，可以提高面向內(nèi)容通信的效率。另外，基站規(guī)模更大，可以部署規(guī)模更大的MCDN服務(wù)功能網(wǎng)絡(luò)，提高覆蓋范圍。

附圖說明

圖1為本發(fā)明實施例1提供的一種實現(xiàn)數(shù)據(jù)業(yè)務(wù)的處理方法的系統(tǒng)架構(gòu)框圖；

圖2為本發(fā)明實施例1提供的一種數(shù)據(jù)業(yè)務(wù)的處理方法的流程示意圖；

圖3為本發(fā)明實施例2提供的數(shù)據(jù)業(yè)務(wù)的處理方法中的一種回源方法的流程示意圖；

圖4為本發(fā)明實施例2提供的數(shù)據(jù)業(yè)務(wù)的處理方法中的另一種回源方法的流程示意圖；

圖5為本發(fā)明實施例2提供的一種數(shù)據(jù)業(yè)務(wù)的處理方法中的進行內(nèi)容注入的流程示意圖；

圖6為本發(fā)明實施例2提供的一種數(shù)據(jù)業(yè)務(wù)的處理方法中的進行內(nèi)容刪除的流程示意圖；

圖7為本發(fā)明實施例3提供的一種CCN控制器的結(jié)構(gòu)框圖；

圖8為本發(fā)明實施例3提供的一種具有MCDN服務(wù)功能的基站的結(jié)構(gòu)框圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述。

本發(fā)明實施例提供的數(shù)據(jù)業(yè)務(wù)處理方法采用的是內(nèi)容中心網(wǎng)絡(luò)(Content-centric Networking，CCN)通信模式，CCN是采用以內(nèi)容(信息)為中心的通信模式來構(gòu)建的一種網(wǎng)絡(luò)，它解除了內(nèi)容與位置之間的耦合關(guān)系，用戶不需要關(guān)心從哪臺服務(wù)器獲取內(nèi)容，而只需關(guān)心內(nèi)容本身。在通信過程中，CCN中的所有CCN節(jié)點均可以基于內(nèi)容的名字進行路由和轉(zhuǎn)發(fā)，并對經(jīng)過自身的數(shù)據(jù)內(nèi)容進行緩存，以便后續(xù)有相同內(nèi)容請求的用戶直接從本地緩存獲取該內(nèi)容。

在現(xiàn)有的內(nèi)容中心網(wǎng)絡(luò)中，傳輸?shù)臄?shù)據(jù)業(yè)務(wù)有興趣包(Interest)和數(shù)據(jù)包(Date)兩種，興趣包由內(nèi)容請求用戶發(fā)出，其攜帶被請求的內(nèi)容名。數(shù)據(jù)包與興趣包相對應(yīng)，用于響應(yīng)內(nèi)容請求用戶發(fā)出的興趣包，其攜帶被請求的內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。此外內(nèi)容中心網(wǎng)絡(luò)中的每個CCN節(jié)點都維護三張表：緩存庫(Cache Store，CS)、未決請求表(Pending Interest Table，PIT)和轉(zhuǎn)發(fā)信息表(Forwarding Information Base)。CS用于緩存經(jīng)過該CCN節(jié)點的數(shù)據(jù)包中的內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)，以便于在本次通信結(jié)束后，緩存下來的內(nèi)容數(shù)據(jù)仍然可以為其它有相同內(nèi)容請求的用戶服務(wù)；PIT用于記錄已經(jīng)轉(zhuǎn)發(fā)但尚未被響應(yīng)的興趣包的內(nèi)容名及該興趣包到達(dá)接口，以便于相應(yīng)的數(shù)據(jù)包原路返回；FIB與傳統(tǒng)TCP/IP網(wǎng)絡(luò)中的IP路由表功能類似，用于提供下一跳的轉(zhuǎn)發(fā)接口。

當(dāng)CCN中的一個CCN節(jié)點收到興趣包時，該CCN節(jié)點首先會用該興趣 包中的內(nèi)容名匹配CS，如果CS中已經(jīng)緩存了該內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)(即緩存命中)，則直接沿興趣包的到達(dá)路徑轉(zhuǎn)發(fā)該內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)并丟棄該興趣包。如果CS中沒有該內(nèi)容名(即緩存未命中)，則進一步匹配PIT，如果有PIT中有與該興趣包相同的內(nèi)容名，表明已有用戶有相同的內(nèi)容請求，本CCN節(jié)點還沒接收到對應(yīng)的內(nèi)容數(shù)據(jù)，則在PIT中匹配上的內(nèi)容名條目中增加該興趣包的到達(dá)接口，并丟棄興趣包。如果PIT也沒有匹配，表明沒有用戶有相同的內(nèi)容請求，則查找FIB，找到所有下一跳轉(zhuǎn)發(fā)的匹配端口，向這些端口轉(zhuǎn)發(fā)該興趣包(興趣包的到達(dá)接口不再轉(zhuǎn)發(fā))，并在PIT中記錄興趣包的到達(dá)接口；如果FIB也沒有匹配條目，則丟棄興趣包或者轉(zhuǎn)發(fā)給默認(rèn)的設(shè)備。

與興趣包相比，數(shù)據(jù)包的處理過程相對簡單。當(dāng)CCN節(jié)點收到數(shù)據(jù)包時，會對數(shù)據(jù)包的內(nèi)容名字段進行匹配，首先匹配CS，如果緩存有相同的內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)，則直接丟棄該數(shù)據(jù)包；如果沒有，繼續(xù)將該數(shù)據(jù)包中攜帶的內(nèi)容名與PIT中的條目匹配。若匹配上，則向記錄的條目上該內(nèi)容名對應(yīng)的到達(dá)接口轉(zhuǎn)發(fā)該數(shù)據(jù)包，并將該數(shù)據(jù)包緩存至CS，如果PIT中沒有匹配的條目，直接丟棄數(shù)據(jù)包。

本發(fā)明實施例提供的系統(tǒng)架構(gòu)中，將采用上述的CCN網(wǎng)絡(luò)架構(gòu)，將MCDN服務(wù)功能下沉至基站側(cè)，構(gòu)成上述的CCN節(jié)點。具體的，如圖1所示，本系統(tǒng)架構(gòu)共分為兩層：下層為邊緣接入層，由部署了MCDN服務(wù)功能的增強型基站(eNodeB)作為下層中的CCN節(jié)點，基站(本發(fā)明實施例中的基站都是部署了MCDN服務(wù)功能的基站)之間通過X2接口互聯(lián)，實現(xiàn)數(shù)據(jù)的傳輸。上層為控制層，由CCN控制器構(gòu)成，CCN控制器集中管控下層中部署了MCDN服務(wù)功能的基站，對接傳統(tǒng)IP網(wǎng)絡(luò)的CDN調(diào)度控制系統(tǒng)，并提供網(wǎng)絡(luò)能力開放接口，向第三方業(yè)務(wù)提供部分網(wǎng)絡(luò)管理權(quán)限。

本實施例提供了一種數(shù)據(jù)業(yè)務(wù)處理方法，應(yīng)用于CCN控制器一側(cè)，本實施例方法的處理流程包括以下步驟：

步驟101、向具有移動內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN服務(wù)功能的基站發(fā)送配置的緩存策略和路由策略。

CCN控制器主要用于集中管控具有MCDN服務(wù)功能的基站，這些基站構(gòu)成了下層的CCN，所述基站就相當(dāng)于所述CCN中的一個CCN節(jié)點，所述基站中也維護三張表：CS、PIT和FIB；這三張表用于記錄節(jié)點中緩存的內(nèi)容數(shù)據(jù)，指導(dǎo)處理請求包和數(shù)據(jù)包。其中，所述CS用于緩存經(jīng)過該基站的符合緩存策略的數(shù)據(jù)包中的內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)，以便于在本次通信結(jié)束后，緩存下來的內(nèi)容數(shù)據(jù)仍然可以為其它有相同內(nèi)容請求的用戶服務(wù)；PIT用于記錄已經(jīng)轉(zhuǎn)發(fā)但尚未被響應(yīng)的請求包的內(nèi)容名及該請求包的到達(dá)接口，以便于相應(yīng)的數(shù)據(jù)包原路返回；FIB用于記錄內(nèi)容名對應(yīng)的下一跳轉(zhuǎn)發(fā)接口，一個內(nèi)容名對應(yīng)的下一跳轉(zhuǎn)發(fā)接口可以有一個也可以有多個。

基站在將數(shù)據(jù)包緩存到CS時，需要按照一定的緩存策略來緩存，另外，F(xiàn)IB中記錄的內(nèi)容名對應(yīng)的下一跳轉(zhuǎn)發(fā)接口是根據(jù)路由策略確定的。這里所述的緩存策略和路由策略都是由CCN控制器配置的，所述CCN控制器可以采集各基站中緩存的內(nèi)容數(shù)據(jù)的分布情況以及基站的狀態(tài)信息，配置路由策略，規(guī)定好各基站中某個內(nèi)容名對應(yīng)的下一跳轉(zhuǎn)發(fā)接口，當(dāng)基站構(gòu)成的CCN網(wǎng)絡(luò)中有新的內(nèi)容被緩存或有內(nèi)容被刪除時，CCN控制器就會根據(jù)被緩存的新的內(nèi)容所在的基站或被刪除內(nèi)容所在的基站，重新配置路由策略。所述CCN控制器也可以配置基站中的緩存策略，所述緩存策略用于指示所述基站需要緩存在CS中的數(shù)據(jù)包。CCN控制器配置好緩存策略和路由策略后，就可以向相應(yīng)的基站發(fā)送所述緩存策略和路由策略。

在這里需要說明的是，CCN控制器除了可以為基站配置緩存策略和路由策略外，還可以監(jiān)測各基站的健康度狀態(tài)，采集各基站的運行和服務(wù)狀態(tài)，實現(xiàn)對下層中各基站的拓?fù)涔芾?、其他配置管理、性能管理、告警管理，支撐由基站?gòu)成的CCN的正常有序運行。CCN控制器還可以采集、整合基站生成的用戶訪問等日志信息，并可根據(jù)需求二次加工，支撐對業(yè)務(wù)運營狀態(tài)、用戶訪問行為的分析。CCN控制器收集日志信息后，還可以根據(jù)運營需求生成各類報表，分析資源分布狀態(tài)、內(nèi)容服務(wù)狀態(tài)、流量分布情況等，為資源調(diào)整、系統(tǒng)優(yōu)化、業(yè)務(wù)開展提供參考。

本發(fā)明實施例還提供了一種數(shù)據(jù)業(yè)務(wù)的處理方法，應(yīng)用于基站一側(cè)，如圖2所示，本實施例方法的處理流程包括以下步驟：

步驟201、接收內(nèi)容中心網(wǎng)絡(luò)CCN控制器發(fā)送緩存策略和路由策略。

CCN控制器為基站配置好緩存策略和路由策略，就會將緩存策略和路由策略發(fā)送給基站，基站就接收該緩存策略和路由策略。

步驟202、根據(jù)所述路由策略更新FIB。

所述路由策略中規(guī)定的是基站中某個內(nèi)容名對應(yīng)的下一跳轉(zhuǎn)發(fā)接口，所述基站中維護以下三張表：CS、PIT和FIB，F(xiàn)IB中記錄的就是內(nèi)容名對應(yīng)的下一跳轉(zhuǎn)發(fā)接口，基站接收到所述路由策略后，就可以根據(jù)路由策略來更新該FIB。

步驟203、接收攜帶有第二內(nèi)容名的請求包，按照CCN通信模式進行請求包處理流程。

本實施方法中具有MCDN服務(wù)功能的基站構(gòu)成了CCN，各基站之間采用CCN通信模式，一個基站就相當(dāng)于CCN中的一個CCN節(jié)點，各基站中都維持三張表：CS、PIT和FIB，這三張表的功能與現(xiàn)有技術(shù)中相同，在此不再贅述。

本實施例方法中處理的數(shù)據(jù)業(yè)務(wù)包括請求包和數(shù)據(jù)包。用戶終端在有業(yè)務(wù)請求時，可以直接將攜帶有第二內(nèi)容名的請求包發(fā)送給基站，所述第二內(nèi)容名即用戶終端請求的內(nèi)容名。

基站具有MCDN服務(wù)功能，即基站中存儲有很多內(nèi)容數(shù)據(jù)可以為用戶提供內(nèi)容分發(fā)，這些內(nèi)容數(shù)據(jù)以內(nèi)容名對應(yīng)內(nèi)容數(shù)據(jù)的形式存儲在CS里；基站在接收到請求包后，可以先將所述第二內(nèi)容名與預(yù)存的CS進行匹配，若所述CS中緩存有該第二內(nèi)容名則匹配成功即緩存命中，所述基站就可以直接丟棄該請求包并將CS中第二內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)發(fā)送給相應(yīng)的用戶終端。若所述CS中沒有緩存該第二內(nèi)容名則匹配不成功即緩存未命中，所述基站就將所述第二內(nèi)容名與預(yù)存的PIT進行匹配。

所述PIT中記錄的是已經(jīng)轉(zhuǎn)發(fā)但尚未被響應(yīng)的請求包的內(nèi)容名及該請求包到達(dá)接口，故若所述PIT中緩存有該第二內(nèi)容名即匹配成功，表明此時已有用戶終端發(fā)送過相同的請求包，本基站正在等待接收對應(yīng)的數(shù)據(jù)包，則在PIT中 匹配上的內(nèi)容名條目中增加該請求包的到達(dá)接口，并丟棄該請求包。若所述PIT中沒有緩存該第二內(nèi)容名即匹配不成功，表明還沒有接收過相同的請求包，則將所述第二內(nèi)容名與預(yù)存的FIB進行匹配。

FIB中記錄的是各內(nèi)容名對應(yīng)的下一跳轉(zhuǎn)發(fā)接口，若所述FIB中緩存有該第二內(nèi)容名即匹配成功，表明基站構(gòu)成的CCN網(wǎng)絡(luò)內(nèi)存儲有該第二內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，此時，基站就可以通過X2接口將所述請求包發(fā)送給FIB中匹配成功的第二內(nèi)容名對應(yīng)的下一跳接口。即接收攜帶有第二內(nèi)容名的請求包，在所述第二內(nèi)容名與預(yù)存CS和PIT都匹配不成功，與更新后的FIB匹配成功時，將所述請求包發(fā)送給所述更新后的FIB中匹配成功的下一跳接口。

上述處理流程都與現(xiàn)有技術(shù)中CCN節(jié)點處理興趣包的流程相同，與現(xiàn)有技術(shù)中不同的是，在所述第二內(nèi)容名與預(yù)存的CS、PIT和FIB都未匹配成功時，表明基站構(gòu)成的CCN網(wǎng)絡(luò)內(nèi)么沒有存儲該第二內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，基站需要將所述請求包發(fā)送給所述CCN控制器，而不是現(xiàn)有技術(shù)中的直接丟棄或轉(zhuǎn)發(fā)到默認(rèn)接口。

步驟204、接收攜帶有第一內(nèi)容名及其對應(yīng)內(nèi)容數(shù)據(jù)的數(shù)據(jù)包，按照CCN通信模式進行數(shù)據(jù)包處理流程。

基站在接收到請求內(nèi)容名為第一內(nèi)容名的請求包后，如果本基站中沒有緩存請求包對應(yīng)的內(nèi)容數(shù)據(jù)，則本基站會根據(jù)FIB的匹配結(jié)果將請求包轉(zhuǎn)發(fā)給緩存有對應(yīng)內(nèi)容數(shù)據(jù)的其他基站；由其他基站將所述請求包對應(yīng)的數(shù)據(jù)包返回給本基站；所述數(shù)據(jù)包中攜帶有第一內(nèi)容名及其對應(yīng)內(nèi)容數(shù)據(jù)。

本基站在接收到所述請求包對應(yīng)的數(shù)據(jù)包后，會先將第一內(nèi)容名與預(yù)存的CS進行匹配，若所述CS中緩存有該第一內(nèi)容名即匹配成功，表明所述基站之前已接收到該數(shù)據(jù)包，此時所述基站就可以直接丟棄該數(shù)據(jù)包。若所述CS中沒有緩存該第一內(nèi)容名即匹配不成功，則所述基站就將所述第一內(nèi)容名與預(yù)存的PIT進行匹配。

所述PIT中記錄的是已經(jīng)轉(zhuǎn)發(fā)但尚未被響應(yīng)的請求包的內(nèi)容名及該請求包到達(dá)接口，故若所述PIT中緩存有該第一內(nèi)容名即匹配成功，表明之前本基站 未接收到第一內(nèi)容名對應(yīng)的數(shù)據(jù)包，則在PIT中匹配上的記錄該第一內(nèi)容名對應(yīng)的各個到達(dá)接口發(fā)送該數(shù)據(jù)包；并刪除所述第一內(nèi)容名對應(yīng)的各個到達(dá)接口條目。若所述PIT中沒有緩存該第一內(nèi)容名即匹配不成功，表明已接收過所述數(shù)據(jù)包，此時將所述數(shù)據(jù)包丟棄。

上述處理流程都與現(xiàn)有技術(shù)中CCN節(jié)點處理數(shù)據(jù)包的流程相同，與現(xiàn)有技術(shù)不同的是，在向第一內(nèi)容名對應(yīng)的各個到達(dá)接口發(fā)送該數(shù)據(jù)包時，是根據(jù)所述緩存策略判斷是否對所述數(shù)據(jù)包進行緩存；若是，則緩存到所述CS中；若不是，則丟棄所述數(shù)據(jù)包。而不是現(xiàn)有技術(shù)中的只要經(jīng)過本基站的未緩存的數(shù)據(jù)包都緩存到CS中。

實施例2

本發(fā)明實施例提供了一種數(shù)據(jù)業(yè)務(wù)處理方法，如圖3所示，為內(nèi)容回源方法，本實施例方法的處理流程包括以下步驟：

步驟301、基站向CCN控制器上報攜帶有內(nèi)容名的請求包，CCN控制器接收所述基站上報的攜帶有內(nèi)容名的請求包。

基站接收到請求包后，在請求包中攜帶的內(nèi)容名與預(yù)存的CS、PIT和FIB都未匹配成功時，表明基站構(gòu)成的CCN網(wǎng)絡(luò)內(nèi)沒有存儲該內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，基站需要將所述請求包發(fā)送給所述CCN控制器。

步驟302、所述CCN控制器根據(jù)回源策略確定所述請求包對應(yīng)的回源點，向所述基站發(fā)送所述回源點IP，所述基站接收所述CCN控制器返回的回源點IP。

CCN控制器接收到基站上報的請求包之后，就知曉其下層的CCN中沒有存儲請求包對應(yīng)的內(nèi)容數(shù)據(jù)，此時就需要進行回源找到該內(nèi)容數(shù)據(jù)，在重定向模式下，所述CCN控制器會根據(jù)回源策略確定該請求包的回源方式是向內(nèi)容中心回源還是源站回源，即確定該請求包的回源點是內(nèi)容中心還是內(nèi)容源；確定好回源點后，所述CCN控制器就會將回源點IP發(fā)送給基站，由基站發(fā)起回源。

在這里需要說明的是，回源策略時CCN控制器通過綜合下層CCN網(wǎng)絡(luò)鏈路狀態(tài)，節(jié)點負(fù)載等信息配置的，根據(jù)該回源策略可以確定出最優(yōu)的回源點。

步驟303、基站根據(jù)所述回源點IP向回源點發(fā)送所述請求包。

基站接收到所述回源點IP后，就可以發(fā)起回源，根據(jù)回源點IP向回源點發(fā)送所述請求包。

步驟304、基站接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包。

若所述回源點是內(nèi)容中心，則基站向內(nèi)容中心發(fā)送所述請求包，所述內(nèi)容中心為CDN的內(nèi)容中心，里面存儲有網(wǎng)絡(luò)中的各種內(nèi)容資源，若所述內(nèi)容中心中存儲有所述請求包攜帶的內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，則所述內(nèi)容中心會直接將攜帶有內(nèi)容名以及對應(yīng)的內(nèi)容數(shù)據(jù)的數(shù)據(jù)包返回給基站；若所述內(nèi)容中心中沒有存儲所述請求包攜帶的內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，則所述內(nèi)容中心會查找到所述內(nèi)容名對應(yīng)的內(nèi)容源，并向內(nèi)容源發(fā)送所述請求包，從所述內(nèi)容源中獲取到所述請求包對應(yīng)的數(shù)據(jù)包，并將所述數(shù)據(jù)包返回給基站。

若所述回源點是內(nèi)容源，則基站向內(nèi)容源發(fā)送所述請求包，所述內(nèi)容源中存儲有所述請求包攜帶的內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，則所述內(nèi)容源會直接將攜帶有內(nèi)容名以及對應(yīng)的內(nèi)容數(shù)據(jù)的數(shù)據(jù)包返回給基站。

上述在內(nèi)容源或內(nèi)容中心中進行回源的方法為現(xiàn)有的回源流程，在此不再贅述。

步驟302-304是在重定向模式下進行回源，CCN控制器還可以在代理模式下進行回源，如圖4所示，其具體的其流程包括以下步驟：

步驟302a、CCN控制器根據(jù)回源策略確定所述請求包對應(yīng)的回源點，向所述回源點發(fā)送所述請求包。

CCN控制器接收到基站上報的請求包之后，就知曉其下層的CCN中沒有存儲請求包對應(yīng)的內(nèi)容數(shù)據(jù)，此時就需要進行回源找到該內(nèi)容數(shù)據(jù)，在重定向模式下，所述CCN控制器會根據(jù)回源策略確定該請求包的回源方式是向內(nèi)容中心回源還是源站回源，即確定該請求包的回源點是內(nèi)容中心還是內(nèi)容源；確定好回源點后，所述CCN控制器就會發(fā)起回源，向所述回源點發(fā)送所述請求包。

步驟303a、CCN控制器接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包。

內(nèi)容中心或內(nèi)容源將所述請求包對應(yīng)的數(shù)據(jù)包返回給CCN控制器的過程 具體可以參考步驟303中的描述。

步驟304a、CCN控制器將所述數(shù)據(jù)包發(fā)送給基站；所述基站接收所述CCN控制器返回的所述請求包對應(yīng)的數(shù)據(jù)包。

CCN控制器接收到回源點返回的數(shù)據(jù)包后，就會將所述數(shù)據(jù)包發(fā)送給基站。

這樣，基站將請求包上報給CCN控制器后，CCN控制器可以采用重定向模式(步驟302-304)或代理模式(步驟302a-304a)使得基站獲取到該請求包對應(yīng)的數(shù)據(jù)包。

基站獲得所述數(shù)據(jù)包后，對數(shù)據(jù)包的處理流程具體可參考步驟204中的描述。此種情況下，通常是所述數(shù)據(jù)包中的內(nèi)容名與預(yù)存的緩存庫CS匹配不成功，與預(yù)存的PIT匹配成功，此時基站就會將所述數(shù)據(jù)包轉(zhuǎn)發(fā)給用戶終端，并根據(jù)所述緩存策略判斷是否對所述數(shù)據(jù)包進行緩存；若是，則緩存到所述CS中；若不是，則丟棄所述數(shù)據(jù)包。

由于新緩存了一個數(shù)據(jù)包，故所述CCN控制器就會更新配置出針對該新的數(shù)據(jù)包的路由策略，并發(fā)送給相應(yīng)的各個基站，由各個基站據(jù)此更新維護FIB。

本發(fā)明實施例還提供了一種數(shù)據(jù)業(yè)務(wù)處理方法，如圖5所示，為內(nèi)容注入方法，本實施例方法的處理流程包括以下步驟：

步驟501、CCN控制器接收第三方設(shè)備發(fā)送的內(nèi)容注入請求。

上述流程中描述的都是通過CCN控制器集中管控下層基站的方法，本實施例方法提供的CCN控制器在增強網(wǎng)絡(luò)管控能力的同時，也實現(xiàn)了網(wǎng)絡(luò)能力的開放，通過提供CCN控制器跟第三方設(shè)備的接口可以實現(xiàn)第三方設(shè)備對具有MCDN服務(wù)功能的基站的內(nèi)容管理。第三方設(shè)備的操作人員可以通過管理平臺查看指定基站內(nèi)緩存的內(nèi)容數(shù)據(jù)并可根據(jù)需求通過CCN控制器執(zhí)行內(nèi)容注入、刪除等操作。

第三方設(shè)備的操作人員想要在基站中注入內(nèi)容時，可以通過第三方設(shè)備向所述CCN控制器發(fā)送內(nèi)容注入請求，所述內(nèi)容注入請求中攜帶有注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址。

步驟502、CCN控制器向基站發(fā)送內(nèi)容注入通知，所述基站接收所述CCN 控制器發(fā)送的內(nèi)容注入通知，

所述CCN控制器接收到內(nèi)容注入請求時，若所述內(nèi)容注入請求中還包括注入基站ID，則表明所述第三方設(shè)備指定要將相應(yīng)的注入內(nèi)容緩存到該基站ID標(biāo)識的基站中，此時，所述CCN控制器就會向所述注入基站ID標(biāo)識的基站發(fā)送內(nèi)容注入通知。若所述內(nèi)容注入請求中沒有注入基站ID，則表明所述第三方設(shè)備未指定基站，此時，CCN控制器可以自主選擇一個基站來發(fā)送所述內(nèi)容注入通知。示例的，所述CCN控制器可以選擇一個緩存內(nèi)容最少的基站來發(fā)送所述內(nèi)容注入通知。所述內(nèi)容注入通知包括所述注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址。

步驟503、基站根據(jù)所述內(nèi)容源的IP地址獲取所述注入內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，在所述CS中緩存所述注入內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。

基站接收到所述內(nèi)容注入通知后，就會從所述內(nèi)容源的IP地址處的內(nèi)容源中獲取所述注入內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)。獲取所述注入內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)后，就會將所述注入內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)緩存到所述CS中。這樣就完成了內(nèi)容的注入。

所述基站將所述注入內(nèi)容數(shù)據(jù)緩存后，可以向所述CCN控制器發(fā)送注入結(jié)果通知，通知所述CCN控制器其已完成對該注入內(nèi)容的注入。當(dāng)然，所述基站可能還會因為某些原因不能將相應(yīng)內(nèi)容緩存，此時所述基站可以向所述CCN控制器發(fā)送注入結(jié)果通知，通知所述CCN控制器其未完成對該注入內(nèi)容的注入。

由于新緩存了一個數(shù)據(jù)包，故所述CCN控制器就會更新配置出針對該新的數(shù)據(jù)包的路由策略，并發(fā)送給相應(yīng)的各個基站，由各個基站據(jù)此更新維護FIB。

本發(fā)明實施例還提供了一種數(shù)據(jù)業(yè)務(wù)處理方法，如圖6所示，為內(nèi)容刪除方法，本實施例方法的處理流程包括以下步驟：

步驟601、CCN控制器接收第三方設(shè)備發(fā)送的內(nèi)容刪除請求。

第三方設(shè)備的操作人員想要刪除某基站中緩存的內(nèi)容數(shù)據(jù)時，可以通過第三方設(shè)備向所述CCN控制器發(fā)送內(nèi)容刪除請求，所述內(nèi)容刪除請求中攜帶有刪除內(nèi)容名。

步驟602、CCN控制器向存儲有所述刪除內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)的基站，發(fā)送內(nèi)容刪除通知；基站接收所述CCN控制器發(fā)送的內(nèi)容刪除通知。

所述CCN控制器接收到內(nèi)容刪除請求時，就會先查找獲得存儲有所述刪除內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)的基站，然后向該基站發(fā)送內(nèi)容刪除通知，所述內(nèi)容刪除通知包括所述刪除內(nèi)容名。

步驟603、基站刪除所述CS中所述刪除內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。

基站接收到所述內(nèi)容刪除通知后，就會從CS中匹配獲得所述刪除內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，然后將素數(shù)CS中緩存的刪除內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)刪除，這樣就完成了相應(yīng)內(nèi)容的刪除。

所述基站將相應(yīng)的內(nèi)容數(shù)據(jù)刪除后，可以向所述CCN控制器發(fā)送刪除結(jié)果通知，通知所述CCN控制器其已完成對該指定內(nèi)容的刪除。當(dāng)然，所述基站可能還會因為某些原因不能將相應(yīng)內(nèi)容刪除，此時所述基站可以向所述CCN控制器發(fā)送注入結(jié)果通知，通知所述CCN控制器其未完成對該內(nèi)容的刪除。

由于刪除了一個數(shù)據(jù)包，故所述CCN控制器就會更新配置出新的路由策略，即將所述刪除內(nèi)容名對應(yīng)的下一跳接口刪除，并發(fā)送給相應(yīng)的各個基站，由各個基站據(jù)此刪除其FIB中所述刪除內(nèi)容名對應(yīng)的下一跳接口。

本實施例方法中，CCN控制器實現(xiàn)了與第三方設(shè)備的通信，由于用戶信息、網(wǎng)絡(luò)狀態(tài)信息對第三方設(shè)備越來越重要，CCN控制器可以根據(jù)具體需求將信息整合適配提供給第三方設(shè)備，實現(xiàn)和第三方設(shè)備的交互。而第三方設(shè)備可以根據(jù)CCN控制器提供的網(wǎng)絡(luò)狀態(tài)、節(jié)點負(fù)載、內(nèi)容熱度等信息定制緩存策略等，獨立配置基站的緩存策略，可提高基站的MCDN服務(wù)能力。CCN控制器還可以分析第三方設(shè)備的業(yè)務(wù)運營狀態(tài)、內(nèi)容分布情況、資源占用情況、用戶訪問行為等，以便管理員及第三方設(shè)備的用戶掌握業(yè)務(wù)運營情況，并對運營策略和維護策略做出針對性的調(diào)整。

本實施例提供的數(shù)據(jù)業(yè)務(wù)處理方法，通過將MCDN服務(wù)功能部署在基站上，由這些基站構(gòu)成CCN，各基站間通過X2接口采用CCN通信模式進行通信，由CCN控制器管控CCN中的各基站，這樣基站可以直接處理用戶終端的數(shù)據(jù)請 求業(yè)務(wù)，采用基于內(nèi)容的路由可以有效避免頻繁的請求上報，降低核心網(wǎng)工作負(fù)擔(dān)，并且基站規(guī)模更大，可以部署規(guī)模更大的MCDN服務(wù)功能網(wǎng)絡(luò)，提高覆蓋范圍，并且CCN是一種基于內(nèi)容的通信網(wǎng)絡(luò)，可以提高面向內(nèi)容通信的效率。

實施例3、

本發(fā)明實施例提供了一種CCN控制器，如圖7所示，所述控制器包括：第一發(fā)送單元701，其中，

第一發(fā)送單元701，用于向具有移動內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN服務(wù)功能的基站發(fā)送配置的緩存策略和路由策略；其中，所述緩存策略用于指示所述基站需要緩存在緩存庫CS中的數(shù)據(jù)包，所述路由策略用于所述基站更新轉(zhuǎn)發(fā)信息表FIB。

可選的，如圖7所示，所述控制器還包括：第一接收單元702和第一處理單元703，其中，

第一接收單元702，用于接收所述基站上報的攜帶有內(nèi)容名的請求包；

第一處理單元703，用于根據(jù)回源策略確定所述第一接收單元702接收的請求包對應(yīng)的回源點；所述回源點包括內(nèi)容中心或內(nèi)容源；

所述第一發(fā)送單元701，還用于向所述基站發(fā)送所述第一處理單元703確定的回源點IP；或者，向所述第一處理單元703確定的回源點發(fā)送所述請求包；

所述第一接收單元702，還用于接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包；

所述第一發(fā)送單元701，還用于將所述第一接收單元702接收到的數(shù)據(jù)包發(fā)送給基站。

所述第一接收單元702，用于接收第三方設(shè)備發(fā)送的內(nèi)容注入請求，所述內(nèi)容注入請求中攜帶有注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址；所述第一發(fā)送單元701，還用于向基站發(fā)送內(nèi)容注入通知，所述內(nèi)容注入通知包括所述注入內(nèi)容名及注入內(nèi)容所在內(nèi)容源的IP地址。

所述內(nèi)容注入請求中還包括注入基站ID，則所述第一發(fā)送單元701，具體用于向所述注入基站ID標(biāo)識的基站發(fā)送內(nèi)容注入通知；或者，所述第一發(fā)送單元701，具體用于向自主分配的基站發(fā)送內(nèi)容注入通知。

所述第一接收單元702，用于接收第三方終端發(fā)送的內(nèi)容刪除請求，所述內(nèi)容刪除請求中攜帶有刪除內(nèi)容名；所述第一發(fā)送單元701，還用于向存儲有所述第一接收單元702接收到的刪除內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)的基站，發(fā)送內(nèi)容刪除通知，所述內(nèi)容刪除通知包括所述刪除內(nèi)容名。

本發(fā)明實施例還提供了一種具有MCDN服務(wù)功能的基站，如圖8所示，所述基站包括：第二接收單元801，第二處理單元802，第二發(fā)送單元803，其中，

第二接收單元801，用于接收內(nèi)容中心網(wǎng)絡(luò)CCN控制器發(fā)送緩存策略和路由策略；所述緩存策略用于通知需要緩存在緩存庫CS中的數(shù)據(jù)包；

第二處理單元802，用于根據(jù)所述第二接收單元801接收到的路由策略更新轉(zhuǎn)發(fā)信息表FIB；

第二接收單元801，還用于接收攜帶有第一內(nèi)容名及其對應(yīng)內(nèi)容數(shù)據(jù)的數(shù)據(jù)包；

第二發(fā)送單元803，用于在所述第一內(nèi)容名與預(yù)存的緩存庫CS匹配不成功，與預(yù)存的未決請求表PIT匹配成功時，將所述數(shù)據(jù)包轉(zhuǎn)發(fā)給用戶終端；

所述第二處理單元802，還用于在所述第一內(nèi)容名與預(yù)存的緩存庫CS匹配不成功，與預(yù)存的未決請求表PIT匹配成功時，根據(jù)所述第二接收單元801接收到的緩存策略判斷是否對所述數(shù)據(jù)包進行緩存；若是，則緩存到所述CS中；若不是，則丟棄所述數(shù)據(jù)包；

第二接收單元801，還用于接收攜帶有第二內(nèi)容名的請求包；

所述第二發(fā)送單元803，還用于在所述第二內(nèi)容名與預(yù)存CS和PIT都匹配不成功，與更新后的轉(zhuǎn)發(fā)信息表FIB匹配成功時，將所述第二接收單元801接收到的請求包發(fā)送給所述更新后的FIB中匹配成功的下一跳接口。

可選的，所述第二發(fā)送單元803，還用于在所述第二內(nèi)容名與預(yù)存的CS、PIT和FIB都未匹配成功時，將所述第二接收單元801接收到的請求包發(fā)送給所述CCN控制器；

所述第二接收單元801，還用于接收所述CCN控制器返回的回源點IP；

所述第二發(fā)送單元803，還用于根據(jù)所述第二接收單元801接收到的回源 點IP向回源點發(fā)送所述請求包；

所述第二接收單元801，還用于接收所述回源點返回的所述請求包對應(yīng)的數(shù)據(jù)包；

或者，所述第二接收單元801，還用于接收所述CCN控制器返回的所述請求包對應(yīng)的數(shù)據(jù)包。

可選的，所述第二接收單元801，還用于接收所述CCN控制器發(fā)送的內(nèi)容注入通知，所述內(nèi)容注入通知包括注入內(nèi)容名以及注入內(nèi)容所在內(nèi)容源的IP地址；

所述第二處理單元802，還用于根據(jù)所述第二接收單元801接收的內(nèi)容源的IP地址獲取所述注入內(nèi)容名對應(yīng)的內(nèi)容數(shù)據(jù)，在所述CS中緩存所述注入內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。

可選的，所述第二接收單元801，還用于接收所述CCN控制器發(fā)送的內(nèi)容刪除通知，所述內(nèi)容刪除通知中攜帶有刪除內(nèi)容名；

所述第二處理單元802，還用于刪除所述CS中所述第二接收單元801接收的刪除內(nèi)容名及其對應(yīng)的內(nèi)容數(shù)據(jù)。

可選的，所述第二發(fā)送單元803，具體用于通過X2接口進行轉(zhuǎn)發(fā)；所述第二接收單元801，具體用于通過X2接口進行接收。

在實際應(yīng)用中，本實施例中所述的第一發(fā)送單元701，第一接收單元702和第一處理單元703，可以由CCN控制器上的中央處理器(CPU)、微處理器(MPU)、數(shù)字信號處理器(DSP)或現(xiàn)場可編程門陣列(FPGA)、調(diào)制解調(diào)器等器件實現(xiàn)本實施例中所述的第二接收單元801，第二處理單元802，第二發(fā)送單元803可以由基站上的中央處理器(CPU)、微處理器(MPU)、數(shù)字信號處理器(DSP)或現(xiàn)場可編程門陣列(FPGA)、調(diào)制解調(diào)器等器件實現(xiàn)。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計算機程序產(chǎn)品。因此，本發(fā)明可采用硬件實施例、軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器和光學(xué)存儲 器等)上實施的計算機程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備(系統(tǒng))、和計算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導(dǎo)計算機或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計算機或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。