專利名稱：業(yè)務(wù)流加密處理方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種業(yè)務(wù)流加密處理方法及系統(tǒng)。
背景技術(shù)：
微波接入全球互通(Worldwide Interoperability for Microwave Access,簡(jiǎn)稱 為WiMAX)作為新一代的寬帶無(wú)線接入技術(shù)，提供了完善的安全機(jī)制來(lái)保證運(yùn)營(yíng)商和用戶 的利益。例如，802. 16e協(xié)議提供空口數(shù)據(jù)加密傳輸機(jī)制，保證在開(kāi)放的無(wú)線環(huán)境下數(shù)據(jù)傳 輸?shù)臋C(jī)密性，可以有效防止敏感信息被非法竊取。WiMAX系統(tǒng)中數(shù)據(jù)在空口的傳輸是基于連接的，每個(gè)連接都具有特定的服務(wù)質(zhì)量 (Quality ofkrvice，簡(jiǎn)稱為QoQ屬性。每條激活的業(yè)務(wù)流和業(yè)務(wù)傳輸連接一一對(duì)應(yīng)。業(yè) 務(wù)流的Qos屬性在接入時(shí)由認(rèn)證授權(quán)計(jì)費(fèi)(Authentication Authorization Accounting, 簡(jiǎn)稱為AAA)服務(wù)器(Server)分配下來(lái)并發(fā)送給基站(Base Mation，簡(jiǎn)稱為BS)，BS在建 立業(yè)務(wù)流時(shí)使用。如果某個(gè)用戶的某條業(yè)務(wù)流具有高的安全需求，需要加密傳輸數(shù)據(jù)，例 如，預(yù)配置兩條盡力而為(Best Effort，簡(jiǎn)稱為BE)業(yè)務(wù)流的用戶A和預(yù)配置兩條主動(dòng)授 予服務(wù)(Unsolicited Grant krvice，簡(jiǎn)稱為UGS)業(yè)務(wù)流的用戶B，用戶A對(duì)數(shù)據(jù)在空口 傳輸?shù)陌踩砸筝^高，而用戶B沒(méi)有要求；或者預(yù)配置了多條業(yè)務(wù)流的用戶C (包含BE和 UGS)，對(duì)其UGS業(yè)務(wù)傳輸?shù)臄?shù)據(jù)具有較高的安全需求，而對(duì)BE業(yè)務(wù)流上傳輸?shù)臄?shù)據(jù)沒(méi)有安 全性要求。現(xiàn)有的NWG網(wǎng)絡(luò)協(xié)議中R3和R6消息接口中沒(méi)有對(duì)業(yè)務(wù)流的安全需求進(jìn)行描述， 不便于實(shí)現(xiàn)基于連接的加密數(shù)據(jù)傳輸需求。如果業(yè)務(wù)流(連接)的安全需求在BS描述或 者配置，BS作為一個(gè)分布式的接入點(diǎn)，事先并不知曉用戶信息和及其連接的Qos屬性，所以 在基站并不能根據(jù)用戶的信息和QoS屬性來(lái)配置特定用戶的特定業(yè)務(wù)流的安全需求。

發(fā)明內(nèi)容
針對(duì)相關(guān)技術(shù)中基站不能根據(jù)用戶的信息和QoS屬性來(lái)配置業(yè)務(wù)安全需求的問(wèn) 題而提出本發(fā)明，為此，本發(fā)明的主要目的在于提供一種業(yè)務(wù)流加密處理方案，以解決上述 問(wèn)題。為了實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的一個(gè)方面，提供了 一種業(yè)務(wù)流加密處理方法。根據(jù)本發(fā)明的業(yè)務(wù)流加密處理方法包括認(rèn)證授權(quán)計(jì)費(fèi)服務(wù)器AAA Server向認(rèn) 證授權(quán)計(jì)費(fèi)客戶端AAA Client發(fā)送用于指示業(yè)務(wù)流是否需要加密的指示信息；AAA Client 向業(yè)務(wù)流授權(quán)錨點(diǎn)Anchor SFA發(fā)送指示信息；Anchor SFA將指示信息發(fā)送給基站；基站根 據(jù)指示信息對(duì)業(yè)務(wù)流進(jìn)行加密或不加密處理。優(yōu)選地，AAA Server向AAA Client發(fā)送指示信息包括:kkk krver在接入接 受Access Acc印t消息中攜帶指示信息；AAA Server將Access Acc印t消息發(fā)送給AAA Client。優(yōu)選地，AAA krver在Access Acc印t消息中攜帶指示信息包括在AccessAccept消息的服務(wù)質(zhì)量描述符QoS-Descriptor的子類型/長(zhǎng)度/數(shù)值格式TLV中增加 TLV，增加的TLV用于指示業(yè)務(wù)流是否需要加密。優(yōu)選地，AAA Client向Anchor SFA發(fā)送指示信息包括AAA Client在資源預(yù)留 請(qǐng)求RR-Req消息的業(yè)務(wù)流參數(shù)中攜帶指示信息；AAA Client將RR-Req消息發(fā)送給Anchor SFA。

優(yōu)選地，Anchor SFA將指示信息發(fā)送給基站包括=Anchor SFA在發(fā)送給基站的數(shù) 據(jù)通道登記請(qǐng)求Path_Reg_Req消息的業(yè)務(wù)流參數(shù)中攜帶指示信息。優(yōu)選地，基站根據(jù)指示信息對(duì)業(yè)務(wù)流進(jìn)行加密處理包括基站確定一個(gè)安全聯(lián)盟 SA ；基站將SA的標(biāo)識(shí)ID與業(yè)務(wù)流進(jìn)行關(guān)聯(lián)，并將與業(yè)務(wù)流關(guān)聯(lián)的SA的ID發(fā)送移動(dòng)臺(tái)；基 站和/或移動(dòng)臺(tái)使用ID對(duì)應(yīng)的SA對(duì)業(yè)務(wù)流的數(shù)據(jù)流進(jìn)行加密和/或解密。為了實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的另一方面，還提供了 一種業(yè)務(wù)流加密處理系統(tǒng)。根據(jù)本發(fā)明的業(yè)務(wù)流加密處理系統(tǒng)，包括AAA Server、AAAClient、Anchor SFA, 基站；AAA Server向AAA Client發(fā)送用于指示業(yè)務(wù)流是否需要加密的指示信息；AAA Client向Anchor SFA發(fā)送指示信息；Anchor SFA將指示信息發(fā)送給基站；基站根據(jù)指示信 息對(duì)業(yè)務(wù)流進(jìn)行加密或不加密處理。優(yōu)選地，AAA Server包括第一設(shè)置模塊，用于在Access Acc印t消息中設(shè)置指示 信息；第一發(fā)送模塊，用于將Access Acc印t消息發(fā)送給AAA Client。優(yōu)選地，第一設(shè)置模塊用于在Access Accept消息的QoS-Descriptor的子TLV中 增加TLV，增加的TLV用于指示業(yè)務(wù)流是否需要加密。優(yōu)選地，AAA Client包括第二設(shè)置模塊，用于在RR-Req消息的業(yè)務(wù)流參數(shù)中攜 帶指示信息；第二發(fā)送模塊，用于將RR-Req消息發(fā)送給Anchor SFA。通過(guò)本發(fā)明，采用在AAA Server上對(duì)業(yè)務(wù)流安全需求進(jìn)行配置，并發(fā)送給基站，解 決了相關(guān)技術(shù)中基站不能根據(jù)用戶的信息和QoS屬性來(lái)配置業(yè)務(wù)流安全需求的問(wèn)題，進(jìn)而 實(shí)現(xiàn)了根據(jù)用戶信息和QoS屬性配置業(yè)務(wù)流的安全需求。本發(fā)明的其它特征和優(yōu)點(diǎn)將在隨后的說(shuō)明書(shū)中闡述，并且，部分地從說(shuō)明書(shū)中變 得顯而易見(jiàn)，或者通過(guò)實(shí)施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點(diǎn)可通過(guò)在所寫(xiě)的說(shuō)明 書(shū)、權(quán)利要求書(shū)、以及附圖中所特別指出的結(jié)構(gòu)來(lái)實(shí)現(xiàn)和獲得。


此處所說(shuō)明的附圖用來(lái)提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本申請(qǐng)的一部分，本發(fā) 明的示意性實(shí)施例及其說(shuō)明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定。在附圖中圖1是根據(jù)本發(fā)明實(shí)施例的業(yè)務(wù)流加密處理方法的流程圖；圖2是根據(jù)本發(fā)明實(shí)施例的建立加密的業(yè)務(wù)流的流程圖；圖3是根據(jù)本發(fā)明實(shí)施例的業(yè)務(wù)流加密處理系統(tǒng)的結(jié)構(gòu)框圖。
具體實(shí)施例方式需要說(shuō)明的是，在不沖突的情況下，本申請(qǐng)中的實(shí)施例及實(shí)施例中的特征可以相 互組合。下面將參考附圖并結(jié)合實(shí)施例來(lái)詳細(xì)說(shuō)明本發(fā)明。在以下實(shí)施例中，在附圖的流程圖示出的步驟可以在諸如一組計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以 不同于此處的順序執(zhí)行所示出或描述的步驟。根據(jù)本發(fā)明的實(shí)施例，提供了一種業(yè)務(wù)流加密方法，圖1是根據(jù)本發(fā)明實(shí)施例的 業(yè)務(wù)流加密方法的流程圖，如圖1所示，該方法包括如下的步驟S102至步驟S108 步驟S102，AAA krver向AAA Client發(fā)送用于指示業(yè)務(wù)流是否需要加密的 指示信息。由于AAA krver本身就是一個(gè)記錄用戶Qos信息的集中點(diǎn)，在此處可以根 據(jù)AAA krver上記錄的信息來(lái)設(shè)置業(yè)務(wù)是否需要加密。需要說(shuō)明的，AAA Client作 為與AAA krver進(jìn)行交互的模塊，可以設(shè)置在業(yè)務(wù)流授權(quán)錨點(diǎn)(Anchor Service Flow Authorization，簡(jiǎn)稱為Anchor SFA)的內(nèi)部，也可以設(shè)置于其他網(wǎng)元之中。步驟S104，AAA Client向Anchor SFA(或稱為描點(diǎn)數(shù)據(jù)通道功能實(shí)體Anchor DPF)發(fā)送指示信息。步驟S106，Anchor SFA將指示信息發(fā)送給基站。步驟S108，基站根據(jù)指示信息對(duì)業(yè)務(wù)流進(jìn)行加密或不加密處理。下面以業(yè)務(wù)流需要加密為例，結(jié)合業(yè)務(wù)流的建立流程對(duì)上述步驟做詳細(xì)的說(shuō)明。圖2是根據(jù)本發(fā)明實(shí)施例的建立加密的業(yè)務(wù)流的流程圖，如圖2所示，該流程包括 如下步驟步驟S201，在初始可擴(kuò)展鑒權(quán)協(xié)議(ExtensibleAuthentication Protocol，簡(jiǎn)稱 為ΕΑΡ)鑒權(quán)成功后，AAA krver向AAA客戶端(Client)發(fā)送R3接入接受(Access Accept) 消息，該消息中攜帶有指示業(yè)務(wù)流是否需要加密的指示信息，其中，AAA Client也可以稱為 lAilE# (Authenticator) 。iftit;lft，AAA Server njL^MjlAccess AcceptAAA Client 發(fā)送用于指示業(yè)務(wù)流是否需要加密的指示信息，可以通過(guò)其他消息發(fā)送該指示信息，例如， 通過(guò)一個(gè)新定義的消息，在此Access Accept消息只是對(duì)能夠攜帶指示信息的消息的一個(gè) 舉例說(shuō)明，但并不限于此，只要是能夠攜帶用于指示業(yè)務(wù)流是否需要加密的指示信息的消 息都可以起到相同的作用。當(dāng)然，使用Access Acc印t消息實(shí)現(xiàn)較為容易。優(yōu)選地，在使用Access Accept消息的攜帶上述指示信息的情況下，可以在Access Accept消息的服務(wù)質(zhì)量描述符(QoS-Descriptor)的子TLV中增加新的TLV安全級(jí)別 (Security Level)(在通信流域中，按照“數(shù)據(jù)類型、數(shù)據(jù)長(zhǎng)度、數(shù)據(jù)數(shù)值”的格式組織數(shù)據(jù) 的，用英文表示就是“Type類型，Length長(zhǎng)度，Value值”，簡(jiǎn)稱TLV格式)，大小為1個(gè)字節(jié)。 Security Level的意義見(jiàn)表1，O表明用戶對(duì)在此業(yè)務(wù)流上傳輸?shù)臄?shù)據(jù)無(wú)安全性要求；1表 明用戶對(duì)在此業(yè)務(wù)流上傳輸?shù)臄?shù)據(jù)有安全性要求。需要說(shuō)明的，可以使用該消息中其他字 節(jié)的來(lái)指示業(yè)務(wù)流是否需要加密，下面以TLV Security Level為例進(jìn)行說(shuō)明。表 1
TLV名類型長(zhǎng)度Μ/Ο意義Security Level待定1 byteO0:無(wú)安全要求； 1:有安全要求； 為了更好的對(duì)本實(shí)施例進(jìn)行說(shuō)明，在此首先對(duì)安全聯(lián)盟(Security Alliance，簡(jiǎn) 稱為SA)流量加密密鑰(Traffic Encryption Key，簡(jiǎn)稱為TEK)進(jìn)行說(shuō)明。
在SA TEK三步握手階段，移動(dòng)臺(tái)(Mobile Station，簡(jiǎn)稱為MS)和BS協(xié)商生成具 有加密屬性的安全聯(lián)盟SA，其中，在data crypt type描述了加解密算法。MS用密鑰請(qǐng)求 (Key-Request)、密鑰回復(fù)(Key-R印Iy)消息完成此SA的TEK交互，成功之后MS和BS之間 擁有相同的TEK密鑰。TEK是用來(lái)加解密業(yè)務(wù)流數(shù)據(jù)的密鑰。步驟S202，在業(yè)務(wù)流建立階段，Authenticator發(fā)送RR_Req消息給SFA，RR_ Req中每條業(yè)務(wù)流參數(shù)攜帶新增的TLV Security Level.需要說(shuō)明的，在該步驟中， Authenticator可以在RR_Req消息中攜帶用于指示每條業(yè)務(wù)流是否需要加密的指示信息 (TLV Security Level是對(duì)該指示信息的舉例說(shuō)明)，也可以在其他消息中攜帶上述指示信 肩、ο

步驟S203，SFA發(fā)送數(shù)據(jù)通道登記請(qǐng)求Path_Reg_Req消息給BS，Path_Reg_Req中 每條業(yè)務(wù)流參數(shù)中新增TLV Security Level。在該步驟中，SFA可以在Path_Reg_Req消 息中攜帶上述指示信息，當(dāng)然，可以在其他消息中攜帶上述指示信息，在本實(shí)施例中，Path, Reg.Req消息只是對(duì)此的一個(gè)解釋說(shuō)明。步驟S204，針對(duì)每條業(yè)務(wù)流中的Security Level值，如果Security Level為0， 那么表明在此條業(yè)務(wù)流上傳輸?shù)臄?shù)據(jù)不必要加密，所以不必為此條業(yè)務(wù)流關(guān)聯(lián)加密屬性 的安全聯(lián)盟SA，那么DSA_Req中的SAID可以為OxFFFF(表明不和加密的SA關(guān)聯(lián))；如果 SecurityLevel為1，那么表明在此條業(yè)務(wù)流上傳輸?shù)臄?shù)據(jù)具有安全需求，需要加密傳輸。 BS根據(jù)策略，從三步握手階段協(xié)商生成的SA中選擇數(shù)據(jù)加密類型(Date Crypt Type)非O 的一個(gè)SA，將其SAID與此條業(yè)務(wù)流關(guān)聯(lián)起來(lái)，并通過(guò)DSA_Req消息攜帶給MS。建立具有安全屬性的業(yè)務(wù)流的其余步驟，和現(xiàn)有業(yè)務(wù)流建立過(guò)程一致，在此不再 贅述。在此之后，BS接收到具有安全需求(即，需要加密)業(yè)務(wù)流的數(shù)據(jù)流，則查找到此業(yè) 務(wù)流關(guān)聯(lián)到的SA(包括對(duì)應(yīng)的TEK)，然后，用該SA中data crypt type指定的加密算法，采 用TEK加密媒體數(shù)據(jù)，并組裝MAC PDU, PDU頭中的EC比特置1，表明此MAC PDU是經(jīng)過(guò)加 密的，通過(guò)空口發(fā)送到MS。MS接收到MAC PDU，識(shí)別EC位為1，判定為加密包。根據(jù)PDU頭 中的連接信息查找到對(duì)應(yīng)的SA，用SA中data crypt type指定的解密算法，采用TEK解密 媒體數(shù)據(jù)。同理，MS在接收到具有安全需求的業(yè)務(wù)流的數(shù)據(jù)流時(shí)使用類似的處理即可，在 此不再贅述。通過(guò)上述步驟S201至步驟S204，在網(wǎng)元AAA Server中，每條業(yè)務(wù)流參數(shù)配置的 Security Level，決定在空口傳輸?shù)臄?shù)據(jù)是否需要以加密的方式傳輸。在AAA Server，運(yùn) 營(yíng)商可以基于用戶配置特定的Qos屬性，那么同樣可以基于用戶的連接配置特定的安全屬 性。與上述實(shí)施例相對(duì)應(yīng)，還提供了一種業(yè)務(wù)流加密處理系統(tǒng)，包括AAA Server,AAA Client、Anchor SFA、基站、在該系統(tǒng)中，AAA Server向AAA Client發(fā)送用于指示業(yè)務(wù)流是 否需要加密的指示信息；AAA Client向Anchor SFA發(fā)送指示信息；Anchor SFA將指示信息 發(fā)送給基站；基站根據(jù)指示信息對(duì)業(yè)務(wù)流進(jìn)行加密或不加密處理。圖3是根據(jù)本發(fā)明實(shí)施例的業(yè)務(wù)流加密處理系統(tǒng)的結(jié)構(gòu)框圖，如圖3所示，AAA Server包括第一設(shè)置模塊32，該模塊用于在Access Acc印t消息中設(shè)置指示信息；第一發(fā) 送模塊34，該模塊用于將Access Acc印t消息發(fā)送給AAA Client。優(yōu)選地，第一設(shè)置模塊32用于在Access Acc印t消息的QoS-Descriptor的子TLV中增加TLV，增加的TLV用于指示業(yè)務(wù)流是否需要加密。如圖3所示，AAA Client包括第二設(shè)置模塊36，該模塊用于在資源預(yù)留請(qǐng)求 RR-Req消息的業(yè)務(wù)流參數(shù)中攜帶指示信息；第二發(fā)送模塊38，該模塊用于將RR-Req消息發(fā) 送給Anchor SFA。在該系統(tǒng)中，AAA Server、AAA Client、Anchor SFA、基站之間的處理過(guò) 程已經(jīng)在上書(shū)實(shí)施例中進(jìn)行了詳細(xì)的說(shuō)明，在此不再贅述。綜上所述，在本實(shí)施例中，可以通 過(guò)AAA Server發(fā)送的Access Acc印t消息中的 Qos Profile參數(shù)攜帶Security Level參數(shù)。從而在建立業(yè)務(wù)流的過(guò)程中，用戶的每條業(yè) 務(wù)流都有一個(gè)Security Level值?；究梢愿鶕?jù)Security Level值決定在對(duì)應(yīng)業(yè)務(wù)傳輸 連接上數(shù)據(jù)是否需要以加密的方式傳輸。由于Qos Profile通常在AAA Server上基于用 戶和連接可配置，所以業(yè)務(wù)流是否加密傳輸也可以方便實(shí)現(xiàn)基于用戶和連接可配置。顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用 的計(jì)算裝置來(lái)實(shí)現(xiàn)，它們可以集中在單個(gè)的計(jì)算裝置上，或者分布在多個(gè)計(jì)算裝置所組成 的網(wǎng)絡(luò)上，可選地，它們可以用計(jì)算裝置可執(zhí)行的程序代碼來(lái)實(shí)現(xiàn)，從而，可以將它們存儲(chǔ) 在存儲(chǔ)裝置中由計(jì)算裝置來(lái)執(zhí)行，或者將它們分別制作成各個(gè)集成電路模塊，或者將它們 中的多個(gè)模塊或步驟制作成單個(gè)集成電路模塊來(lái)實(shí)現(xiàn)。這樣，本發(fā)明不限制于任何特定的 硬件和軟件結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，對(duì)于本領(lǐng)域的技 術(shù)人員來(lái)說(shuō)，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修 改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種業(yè)務(wù)流加密處理方法，其特征在于，包括認(rèn)證授權(quán)計(jì)費(fèi)服務(wù)器AAA krver向認(rèn)證授權(quán)計(jì)費(fèi)客戶端AAA Client發(fā)送用于指示業(yè) 務(wù)流是否需要加密的指示信息；所述AAA Client向業(yè)務(wù)流授權(quán)錨點(diǎn)Anchor SFA發(fā)送所述指示信息； Anchor SFA將所述指示信息發(fā)送給基站；所述基站根據(jù)所述指示信息對(duì)所述業(yè)務(wù)流進(jìn)行加密或不加密處理。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述AAAkrver向所述AAA Client發(fā)送 所述指示信息包括所述AAA krver在接入接受Access Accept消息中攜帶所述指示信息； 所述AAA krver將所述Access Acc印t消息發(fā)送給所述AAA Client。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述AAAkrver在所述Access Accept 消息中攜帶所述指示信息包括在所述Access Accept消息的服務(wù)質(zhì)量描述符QoS-Descriptor的子類型/長(zhǎng)度/數(shù) 值格式TLV中增加TLV，所述增加的TLV用于指示所述業(yè)務(wù)流是否需要加密。
4.根據(jù)權(quán)利要求1或3所述的方法，其特征在于，所述AAAClient向所述Anchor SFA 發(fā)送所述指示信息包括所述AAA Client在資源預(yù)留請(qǐng)求RR-Req消息的業(yè)務(wù)流參數(shù)中攜帶所述指示信息； 所述AAA Client將所述RR-Req消息發(fā)送給所述Anchor SFA。
5.根據(jù)權(quán)利要求1或3所述的方法，其特征在于，AnchorSFA將所述指示信息發(fā)送給 所述基站包括所述Anchor SFA在發(fā)送給所述基站的數(shù)據(jù)通道登記請(qǐng)求I^th_Reg_Req消息的業(yè)務(wù)流 參數(shù)中攜帶所述指示信息。
6.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述基站根據(jù)所述指示信息對(duì)所述業(yè)務(wù) 流進(jìn)行加密處理包括所述基站確定一個(gè)安全聯(lián)盟SA ；所述基站將所述SA的標(biāo)識(shí)ID與所述業(yè)務(wù)流進(jìn)行關(guān)聯(lián)，并將與所述業(yè)務(wù)流關(guān)聯(lián)的SA的 ID發(fā)送移動(dòng)臺(tái)；所述基站和/或移動(dòng)臺(tái)使用所述ID對(duì)應(yīng)的SA對(duì)所述業(yè)務(wù)流的數(shù)據(jù)流進(jìn)行加密和/或解密。
7.一種業(yè)務(wù)流加密處理系統(tǒng)，包括AAA Server, AAA Client、Anchor SFA、基站，其特 征在于，所述AAA krver向所述AAA Client發(fā)送用于指示業(yè)務(wù)流是否需要加密的指示信息； 所述AAA Client向所述Anchor SFA發(fā)送所述指示信息； 所述Anchor SFA將所述指示信息發(fā)送給所述基站； 所述基站根據(jù)所述指示信息對(duì)所述業(yè)務(wù)流進(jìn)行加密或不加密處理。
8.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述AAAkrver包括 第一設(shè)置模塊，用于在Access Accept消息中設(shè)置所述指示信息； 第一發(fā)送模塊，用于將所述Access Acc印t消息發(fā)送給所述AAA Client。
9.根據(jù)權(quán)利要求8所述的系統(tǒng)，其特征在于，所述第一設(shè)置模塊用于在所述AccessAccept消息的QoS-Descriptor的子TLV中增加TLV，所述增加的TLV用于指示所述業(yè)務(wù)流 是否需要加密。
10.根據(jù)權(quán)利要求7或9所述的系統(tǒng)，其特征在于，所述AAA Client包括 第二設(shè)置模塊，用于在RR-Req消息的業(yè)務(wù)流參數(shù)中攜帶所述指示信息； 第二發(fā)送模塊，用于將所述RR-Req消息發(fā)送給所述Anchor SFA。
全文摘要
本發(fā)明公開(kāi)了一種業(yè)務(wù)流加密處理方法及系統(tǒng)，該方法包括認(rèn)證授權(quán)計(jì)費(fèi)服務(wù)器AAA Server向認(rèn)證授權(quán)計(jì)費(fèi)客戶端AAA Client發(fā)送用于指示業(yè)務(wù)流是否需要加密的指示信息；AAA Client向業(yè)務(wù)流授權(quán)錨點(diǎn)Anchor SFA發(fā)送指示信息；Anchor SFA將指示信息發(fā)送給基站；基站根據(jù)指示信息對(duì)業(yè)務(wù)流進(jìn)行加密或不加密處理。通過(guò)本發(fā)明實(shí)現(xiàn)了根據(jù)用戶信息和QoS屬性配置業(yè)務(wù)流的安全需求。
文檔編號(hào)H04W12/02GK102083062SQ20091024624
公開(kāi)日2011年6月1日 申請(qǐng)日期2009年12月1日 優(yōu)先權(quán)日2009年12月1日
發(fā)明者顏文波 申請(qǐng)人:中興通訊股份有限公司