專利名稱：在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法
技術領域：
本發(fā)明涉及無線接入技術領域，特別是指在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法。
背景技術：
IEEE 802.16無線接入標準定義了一種基于連接的資源集中分配調(diào)度方式。在這種方式下，由基站(BS，Base Station)集中控制無線空口帶寬資源的分配。并且?guī)挼姆峙涫腔谶B接的，連接是802.16系統(tǒng)進行帶寬資源分配和調(diào)度的依據(jù)。每個移動臺(MSS，Mobile Subscribe Station)的業(yè)務數(shù)據(jù)都要映射到一個特定的連接上，每個激活的連接用一個唯一的連接標識(CID，Connection Identifier)進行標識。在802.16標準中，連接又稱為服務流(SF，Service Flow)，同樣，每個服務流都用一個唯一的服務流標識(SFID，Service Flow Identifier)進行標識。連接可以靜態(tài)配置，也可以通過信令流程動態(tài)創(chuàng)建。采用了這種資源管理方式的系統(tǒng)，能夠在MSS和BS之間提供可靠的端到端的業(yè)務質(zhì)量(QoS)保證。
如圖1示出的IEEE 802.16標準定義的空中接口的協(xié)議棧，空中接口由MAC層和物理層(PHY)組成，MAC層從上到下還依次分為特定服務匯聚子層(CS)，公共部分子層(MAC CPS，后文簡稱為CPS)，安全子層(SecuritySublayer)。采用這種分層結(jié)構，一方面是為了更清楚的對協(xié)議進行描述，另一方面也為協(xié)議的實現(xiàn)提供了一個參考。
當進行業(yè)務數(shù)據(jù)的發(fā)送時，CS層主要對來自特定的高層協(xié)議的數(shù)據(jù)源進行匯聚，經(jīng)過頭壓縮(PHS，Payload Header Suppression)、分類，將高層協(xié)議數(shù)據(jù)包映射到特定連接上的SDU中。IEEE 802.16標準定義了對ATM和包(Packet)兩種高層協(xié)議數(shù)據(jù)源的匯聚。經(jīng)過CS層的匯聚后，數(shù)據(jù)已經(jīng)被映射到某個特定的連接上的固定格式的SDU中。然后，通過MAC SAP定義的原語，將承載了高層業(yè)務數(shù)據(jù)的SDU傳遞給CPS層。在CPS層，根據(jù)需要對SDU進行分段、打包，形成MAC PDU。最后傳遞給PHY層，再進行物理層的相應處理后通過空口發(fā)送出去。
業(yè)務數(shù)據(jù)的接收流程和發(fā)送流程的逆過程類似，具體可參見IEEE802.16標準，此處不再贅述。
上面描述的即為IEEE 802.16標準定義的數(shù)據(jù)業(yè)務流程，如前所述，該流程是基于連接的，在數(shù)據(jù)發(fā)送和接收前，必須用協(xié)議定義的MAC信令建立相應的連接，并且在CS層和CPS層都需要保存相應的連接信息。因此，需要CS層和CPS層配合完成服務流維護的信令流程(包括連接的建立、修改、刪除)。
IEEE 802.16標準通過定義的空口消息和協(xié)議棧層與層之間的原語來完成服務流維護流程。下面以服務流建立和刪除流程為例，描述協(xié)議中現(xiàn)有的服務流維護信令流程。為了描述方便，用發(fā)起方表示服務流建立的請求方，用接收方表示服務流建立的被請求方。
服務流的建立可能是由業(yè)務數(shù)據(jù)包觸發(fā)的，也可能由高層信令觸發(fā)。對此，IEEE 802.16標準沒有做出明確規(guī)定。一般來說，服務流的建立是由CS層決策發(fā)起的，參見圖2示出的流程圖，IEEE 802.16標準定義的服務流的建立包括以下步驟步驟201發(fā)起方的CS層向其CPS層發(fā)起一個服務流建立請求原語(MAC_CREATE_SERVICE FLOW.request)。其中，該原語以及下面流程中的幾個原語都在IEEE 802.16d標準的附錄中給出了定義，此處不再對這些原語進行贅述。
步驟202發(fā)起方的CPS層收到該原語后，根據(jù)該原語構建一個DSA-REQ消息，經(jīng)過空口調(diào)度后發(fā)送給接收方。
步驟203接收方CPS層收到DSA-REQ消息后，通過服務流建立指示原語(MAC_CREATE_SERVICE FLOW.indication)通知接收方的CS層。
如果接收方是BS(Base Station)，此時接收方CPS層還應向發(fā)起方CPS層回應一個DSX-RVD消息，由于該步驟非本發(fā)明重點，故圖中未畫出該情況。
步驟204接收方的CS層對MAC_CREATE_SERVICE FLOW.indication原語進行處理，決定是否允許該服務流的建立，并用服務流建立響應原語(MAC_CREATE_SERVICE FLOW.response)對接收方CPS進行響應。
步驟205接收方CPS層收到MAC_CREATE_SERVICE FLOW.response原語后，根據(jù)該原語構建DSA-RSP消息，并通過空口調(diào)度后發(fā)送給發(fā)起方。
步驟206發(fā)起方收到DSA-RSP消息后，根據(jù)響應消息的內(nèi)容構建服務流建立確認原語(MAC_CREATE_SERVICE FLOW.confirmation)通知發(fā)起方的CS層，同時構建DSA-ACK消息，通過空口調(diào)度后發(fā)送給接收方。接收方的CPS層收到DSA-ACK消息后，認為整個服務流建立過程結(jié)束。
服務流的修改流程和建立流程基本相同，只是將上述流程中的“CREATE”更改為“CHANGE”，故不再對修改流程進行贅述，具體可參見IEEE 802.16標準。
在正常情況下，服務流的刪除由CS層決策發(fā)起。參見圖3示出的流程圖，對IEEE 802.16標準定義的正常情況下的服務流的刪除進行描述，包括以下步驟步驟301發(fā)起方的CS層向其CPS層發(fā)起一個服務流刪除請求原語(MAC_TERMINATION_SERVICE FLOW.request)。
步驟302發(fā)起方的CPS層收到該原語后，根據(jù)該原語構建一個DSD-REQ消息，經(jīng)過空口調(diào)度后發(fā)送給接收方。
步驟303接收方CPS層收到所述DSD-REQ消息后，通過服務流刪除指示原語(MAC_TERMINATION_SERVICE FLOW.indication)通知接收方的CS層。
步驟304接收方的CS層對MAC_TERMINATION_SERVICEFLOW.indication原語進行處理，決定是否允許刪除該服務流，并用服務流刪除響應原語(MAC_TERMINATION_SERVICE FLOW.response)對接收方CPS層進行響應。
步驟305接收方的CPS層收到MAC_TERMINATION_SERVICEFLOW.response原語后，根據(jù)該原語構建DSD-RSP消息，通過空口調(diào)度后發(fā)送給發(fā)起方。
步驟306發(fā)起方CPS層收到所述DSD-RSP消息后，根據(jù)響應消息的內(nèi)容構建服務流刪除確認原語(MAC_TERMINATION_SERVICEFLOW.confirmation)通知發(fā)起方的CS層，認為整個服務流刪除流程結(jié)束。
目前在實際應用中，發(fā)現(xiàn)在服務流建立、修改過程中，以及在服務流的信令流程出現(xiàn)異常時進行服務流的刪除時，CS層和CPS之間會出現(xiàn)失步的情況，即CS層和CPS層出現(xiàn)狀態(tài)的不一致導致數(shù)據(jù)傳輸失敗。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供了服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，保證在服務流維護信令流程中，CS層和CPS層之間的狀態(tài)是同步的，避免由于狀態(tài)的不一致導致CS層和CPS層之間的數(shù)據(jù)傳輸失敗。
本發(fā)明提供了一種在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，用于服務流建立或修改流程中，當發(fā)起方在建立服務流或修改服務流中，發(fā)起方公共部分子層CPS層構建響應消息發(fā)送給接收方后，還包括接收方CPS層收到該響應信息后，向接收方特定服務匯聚子層CS層發(fā)送一原語信息；CS層收到所述原語信息后，確定服務流建立或服務流修改流程結(jié)束。
可選的，當為服務流建立流程時，所述原語信息中包括服務流標識SFID，用于標識當前的服務流；響應碼response code，用于表示接收方CPS層是否收到發(fā)起方CPS層的響應消息；序列碼sequence number，用于標識當前的原語交互過程。
可選的，當為服務流修改流程時，所述原語信息中包括服務流標識SFID，用于標識當前的服務流；響應碼response code，用于表示接收方CPS層是否收到發(fā)起方CPS層的響應消息；序列碼sequence number，用于標識當前的原語交互過程。
可選的，所述的響應碼值為0時表示接收方CPS層正確收到發(fā)起方CPS層響應消息，為1時表示接收方CPS層沒有收到發(fā)起方CPS層響應消息。
本發(fā)明還提供了一種在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，用于服務流建立或服務流修改時出現(xiàn)異常時情況，包括出現(xiàn)異常一方的CPS層通過一原語信息通知其CS層；CS層收到該原語信息后，CS層發(fā)起服務流的刪除流程。
可選的，所述原語信息中包括服務流標識SFID，用于標識當前的服務流。
本發(fā)明還提供了另一種在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，用于服務流建立或服務流修改時出現(xiàn)異常時情況，其特征在于，出現(xiàn)異常一方的CPS層通過一原語信息通知其CS層，并等待該CS層的響應消息；CPS層接收到CS層的響應消息后，CPS層啟動服務流的刪除流程。
可選的，所述原語信息中包括服務流標識SFID，用于標識當前的服務流。
由上述方法可以看出，本發(fā)明為IEEE 802.16標準定義的服務流維護信令交互流程中，實現(xiàn)了CS層和CPS層之間的狀態(tài)同步，避免由于狀態(tài)的不一致導致CS層和CPS層之間的數(shù)據(jù)傳輸失敗。
具體來說，通過在服務流建立、修改流程后，加入接收方CPS層通知其CS層的機制，使其CPS層及時將其狀態(tài)通知CS層，在與CS層狀態(tài)保持同步的情況下由CS層決定數(shù)據(jù)的發(fā)送或接收，避免出現(xiàn)CS層與CPS層之間的失步而造成之間的數(shù)據(jù)發(fā)送丟失。
還通過在建立或修改服務流的信令流程出現(xiàn)異常時，增加出現(xiàn)異常方的CPS層及時通知其CS層的機制，保證了其CS與CPS之間的狀態(tài)同步，避免出現(xiàn)CS層與CPS層之間的失步而造成之間的數(shù)據(jù)發(fā)送丟失。


圖1為IEEE 802.16標準定義的協(xié)議棧示意。
圖2為服務流建立過程中CS與CPS原語交互及空口消息交互流程圖。
圖3為服務流刪除過程中CS與CPS原語交互及空口消息交互流程圖。
圖4為本發(fā)明服務流建立過程中CS與CPS原語交互及空口消息交互流程圖。
圖5為本發(fā)明服務流建立過程中異常時CS與CPS原語交互及空口消息交互流程圖。
具體實施例方式
首先對現(xiàn)有的流程進行分析，來分析為什么會存在現(xiàn)有技術中提到的CS層和CPS層失步問題。下面進行說明從圖2來分析，在步驟204后，服務流建立的接收方CS層，響應服務流建立請求(MAC_CREATE_SERVICE FLOW.indication)原語而發(fā)出服務流建立響應(MAC_CREATE_SERVICE FLOW.response)原語后，接收方CS層就認為服務流已經(jīng)建立成功，而接收方CPS層則需要在步驟206后收到發(fā)起方的DSA-ACK消息后才會認為服務流建立成功。由于接收方的CS層和CPS層在服務流建立流程中存在上述的異步因素，接收方的CS層可能會在CPS層還沒有準備好之前(如在步驟204后到接收方CPS層收到發(fā)起方DSA-ACK的時間段內(nèi))發(fā)送數(shù)據(jù)，從而引起接收方的CS層發(fā)送給CPS層數(shù)據(jù)包的丟失。
同理，在服務流的修改流程中，同樣存在上述的異步因素，導致在接收方的CS層在CPS層還沒有準備好之前的情況下向CPS層發(fā)送數(shù)據(jù)時，引起數(shù)據(jù)包的丟失。
圖3提供的流程圖是在正常情況下服務流的刪除流程。該刪除操作是由CS層發(fā)起的，但是，在異常情況下，如在服務流建立或修改信令流程中，當由于空口消息丟失或其他情況引起信令流程異常時，服務流刪除操作是由出現(xiàn)異常的一方的CPS層主動發(fā)起的，以將尚未建立成功，或者某一方認為已經(jīng)建立成功的服務流刪除。這種情況下，也會造成CS層和CPS層的失步，下面以服務流建立流程出現(xiàn)異常為例進行分析說明當發(fā)起方發(fā)送了DSA_REQ消息而沒有收到接收方的DSA_RSP消息，或者接收方發(fā)送了DSA_RSP消息而沒有收到發(fā)起方的DSA_ACK消息時，會導致超時并重發(fā)DSA_REQ或DSA_RSP消息，當重發(fā)次數(shù)達到設定的最大值后，將認為信令流程異常而發(fā)起刪除服務流的操作。與正常的服務流刪除操作不同的是，刪除操作不是由CS層發(fā)起的，而是由CPS層發(fā)起的，這是因為，上述DSA_REQ、DSA_RSP、DSA_ACK消息是CPS層間的交互信息，因此在服務流建立信令流程出現(xiàn)異常時，是在CPS層發(fā)起的。目前，CPS層發(fā)起服務流刪除操作后，IEEE 802.16標準尚沒有提供一種機制讓CS層及時得知CPS層發(fā)起了服務流刪除，因此會使CS層和CPS層出現(xiàn)狀態(tài)的不一致而導致CS層向CPS層傳輸數(shù)據(jù)失敗。
基于上述的分析，本發(fā)明提供了一個方案，使得在服務流維護信令流程中，保持CS層和CPS層之間的同步，在服務流建立、修改過程中，或在信令流程出現(xiàn)異常時的服務流刪除過程中，CS層能夠及時得知CPS層的狀態(tài)，保證CPS層和CS層狀態(tài)的同步，避免由于狀態(tài)的不一致導致CS層向CPS層發(fā)送數(shù)據(jù)的丟失。本發(fā)明提供的方案包括在CS層與CPS層之間增加一個通知原語，用于CPS將自己的狀態(tài)通知CS層，并修改了CS與CPS之間的交互流程，下面進行詳細描述。
首先以正常的服務流建立流程為例進行說明，當接收方CPS接收到發(fā)起方的響應信息后，本發(fā)明增加了接收方的CPS通知CS層的步驟。下面參見圖4示出的服務流建立流程，對于正常的服務流建立流程，本發(fā)明在圖2示出的流程的步驟206接收方CPS接收到DSA-ACK響應信息后，增加了下述的步驟接收方CPS向接收方CS層發(fā)送一通知原語消息通知CS層，表示CPS層已經(jīng)服務流建立完成；CS層收到所述原語消息后，認為服務流建立流程結(jié)束，CS層可以進行數(shù)據(jù)發(fā)送或接收。
其中，所述的通知原語可以采用如下斜體字示出的格式MAC_CREATE_SERVICE FLOW.notify(SFID，response code，sequence number)其中，參數(shù)SFID為服務流標識，用于標識當前的服務流。response code為響應碼，用于表示接收方CPS是否收到發(fā)起方CPS的響應消息其值為0時表示正確收到DSA_ACK消息，為1時表示沒有收到DSA_ACK消息；sequence number為序列碼，用于標識一個完整的原語交互過程，和MAC_CREATE_SERVICE FLOW.indication原語、MAC_CREATE_SERVICEFLOW.response原語相匹配。
對于正常的服務流建立流程，和修改信令流程相比，除了消息不同外基本相同，因此，同理，對于正常的服務流修改信令流程中，本發(fā)明在接收方的CPS層在收到來自發(fā)起方的DSC-ACK響應信息后，增加了下述的步驟接收方CPS向接收方CS層發(fā)送一通知原語消息通知CS層，表示CPS層已經(jīng)服務流修改完成；CS層收到所述原語消息后，認為服務流修改流程結(jié)束，CS層可以進行數(shù)據(jù)發(fā)送或接收。
其中，可所述的原語可以采用下述斜體字示出的格式MAC_CHANGE_SERVICE FLOW.notify(SFID，response code，sequence number)其中，參數(shù)SFID為服務流標識，用于標識當前的服務流。response code為響應碼，用于表示接收方CPS是否收到發(fā)起方CPS的響應消息其值為0時表示正確收到DSC_ACK消息，為1時表示沒有收到DSC_ACK消息；sequence number為序列碼，用于標識一個完整的原語交互過程，和MAC_CHANGE_SERVICE FLOW.indication原語MAC_CHANGE_SERVICE FLOW.response原語相匹配。
再參見圖5示出的異常情況下的服務流刪除流程圖，在服務流建立或修改信令流程出現(xiàn)異常時，本發(fā)明在原有的圖3示出的流程圖中的步驟301前增加了下述步驟發(fā)現(xiàn)異常的一方的CPS層通過通知原語主動通知其CS層；CS層收到該通知原語后，CS層發(fā)起服務流的刪除流程。其中，CS層進行服務流的刪除過程可參見圖3，不再贅述。
其中，所述通知原語可以采用下面斜體字示出的格式
MAC_TERMINATION_SERVICE FLOW.notify(SFID)其中，參數(shù)SFID為服務流標識，用于標識當前的服務流。
可以看出，當服務流建立、修改流程出現(xiàn)異常時，本發(fā)明由出現(xiàn)異常的一方CPS層通知其CS層，而后由CS層發(fā)起服務流的刪除。避免了CPS層直接發(fā)起刪除流程而無法通知CS層。
本發(fā)明還提供了另一個異常情況下的服務流刪除方法，也能夠保證CPS層和CS層狀態(tài)的一致，其刪除流程仍以由CPS進行，包括以下步驟出現(xiàn)異常一方的CPS層通過一通知原語(可仍采用上例中的原語格式)通知CS層，并等待CS層的響應消息；CPS層接收到CS層的響應消息后，CPS層啟動服務流的刪除。其中CPS進行服務流的刪除過程和IEEE 802.16定義的相同，不再贅述。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
權利要求
1.一種在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，用于服務流建立或修改流程中，其特征在于，當發(fā)起方在建立服務流或修改服務流中，發(fā)起方公共部分子層CPS層構建響應消息發(fā)送給接收方后，還包括接收方CPS層收到該響應信息后，向接收方特定服務匯聚子層CS層發(fā)送一原語信息；CS層收到所述原語信息后，確定服務流建立或服務流修改流程結(jié)束。
2.根據(jù)權利要求1所述的方法，其特征在于，當為服務流建立流程時，所述原語信息中包括服務流標識SFID，用于標識當前的服務流；響應碼response code，用于表示接收方CPS層是否收到發(fā)起方CPS層的響應消息；序列碼sequence number，用于標識當前的原語交互過程。
3.根據(jù)權利要求1所述的方法，其特征在于，當為服務流修改流程時，所述原語信息中包括服務流標識SFID，用于標識當前的服務流；響應碼response code，用于表示接收方CPS層是否收到發(fā)起方CPS層的響應消息；序列碼sequence number，用于標識當前的原語交互過程。
4.根據(jù)權利要求2、或3所述的方法，其特征在于，所述的響應碼值為0時表示接收方CPS層正確收到發(fā)起方CPS層響應消息，為1時表示接收方CPS層沒有收到發(fā)起方CPS層響應消息。
5.一種在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，用于服務流建立或服務流修改時出現(xiàn)異常時情況，其特征在于，包括出現(xiàn)異常一方的CPS層通過一原語信息通知其CS層；CS層收到該原語信息后，CS層發(fā)起服務流的刪除流程。
6.根據(jù)權利要求5所述的方法，其特征在于，所述原語信息中包括服務流標識SFID，用于標識當前的服務流。
7.一種在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，用于服務流建立或服務流修改時出現(xiàn)異常時情況，其特征在于，出現(xiàn)異常一方的CPS層通過一原語信息通知其CS層，并等待該CS層的響應消息；CPS層接收到CS層的響應消息后，CPS層啟動服務流的刪除流程。
8.根據(jù)權利要求7所述的方法，其特征在于，所述原語信息中包括服務流標識SFID，用于標識當前的服務流。
全文摘要
本發(fā)明提供了一種在服務流維護信令流程中協(xié)議層之間狀態(tài)同步的方法，用于服務流建立或修改流程時為發(fā)起方CPS層構建響應消息發(fā)送給接收方，接收方CPS層收到該響應信息后，向接收方CS層發(fā)送一原語信息；CS層收到所述原語信息，確定服務流建立或修改流程結(jié)束。用于服務流建立或流修改時出現(xiàn)異常情況時為出現(xiàn)異常一方的CPS層通過一原語信息通知其CS層；CS層收到該原語信息后發(fā)起服務流的刪除流程。提供了另一種用于所述異常時的方法，為出現(xiàn)異常一方的CPS層通過一原語信息通知其CS層，并在收到CS層的響應消息后，CPS層啟動服務流的刪除流程。使用該發(fā)明可避免由于CS層和CPS層狀態(tài)不一致導致數(shù)據(jù)相互傳輸失敗。
文檔編號H04L29/06GK1855918SQ20051006625
公開日2006年11月1日 申請日期2005年4月25日 優(yōu)先權日2005年4月25日
發(fā)明者李永茂, 肖正飛, 張俊 申請人:華為技術有限公司