專利名稱：通信系統(tǒng)中的分組流處理的制作方法
通信系統(tǒng)中的分組流處理本申請是申請日為2003年6月10日、申請?zhí)枮?3819163.6、發(fā)明名稱為“通信 系統(tǒng)中的分組流處理”的專利申請的分案申請。背景領(lǐng)域本發(fā)明涉及通信系統(tǒng)中的分組流處理，尤其涉及通信系統(tǒng)中的分組流映射和處 理以支持多個服務實例的處理，所述通信系統(tǒng)具有互聯(lián)網(wǎng)協(xié)議(IP)組件。背景支持數(shù)據(jù)通信的通信系統(tǒng)通常包括互聯(lián)網(wǎng)協(xié)議(IP)組件或部分，其中數(shù)據(jù)以IP 格式被通信。同樣，通信系統(tǒng)可以與IP系統(tǒng)通信，或者參與IP節(jié)點的通信。對于這樣的 通信，數(shù)據(jù)按分組傳送；一系列分組被稱為“分組流”。為了處理分組流，通信系統(tǒng)的 基礎(chǔ)結(jié)構(gòu)元件要求某些信息。例如，基礎(chǔ)結(jié)構(gòu)元件可以需要頭部壓縮和/或映射信息， 從而基礎(chǔ)結(jié)構(gòu)元件能引導分組流指向適當?shù)逆溌穼舆B接。因此，本領(lǐng)域需要向要求這些信息的基礎(chǔ)結(jié)構(gòu)元件提供分組流信息。同樣，需 要用于映射和處理通信系統(tǒng)中的分組流的有效方法。附圖的簡要描述

圖1是一通信系統(tǒng)。圖2是處理的呼叫流程，其中PDSN確定流處理和分組流從RSVP消息的映射。圖3是處理的呼叫流程，其中PDSN確定流處理和從“sniffing”會話啟動協(xié)議 (SIP)消息的映射。圖4說明了支持源保留協(xié)議的通信系統(tǒng)。圖5是適用于處理分組流的移動站。圖6-8說明了按照各種實施例的分組流處理。圖9是多信道流處理協(xié)議(MCFTP)分組格式。優(yōu)選實施例的詳細描述短語“示例性”這里用來專指“作為一例子、實例、或示例”。這里所描述為 “示例性”的任何實施例不必被理解為優(yōu)選的或優(yōu)于其他實施例的。圖1是適用于數(shù)據(jù)通信的通信系統(tǒng)100。通信系統(tǒng)100包括與基站(BS) 104通 信的移動站(MS) 102。BS104還與分組數(shù)據(jù)服務節(jié)點(PDSN) 106通信，以及與處理語音 通信的其它組件等通信(未示出)。PDSmoe用作MS102和BS104與數(shù)據(jù)網(wǎng)絡(luò)的接口， 所述網(wǎng)絡(luò)諸如支持IP通信的網(wǎng)絡(luò)。MS102支持數(shù)據(jù)通信，其中幾個AlO連接和服務選項(SO)連接被說明。SO連 接用于所選服務選項的通信，服務選項諸如分組數(shù)據(jù)服務。接著，AlO連接提供用于在 PDSN106和BS104之間發(fā)送互聯(lián)網(wǎng)協(xié)議(IP)分組的鏈路。SO連接提供用于在MS102和 BS104之間發(fā)送IP分組的鏈路。在SO連接(MS-BS)和AlO連接(BS-PDSN)之間存 在一對一的映射。多個AlO/SO連接對在圖1中示出，因為MS102支持多個同時連接。 換言之，MS102能并行處理多個分組流。每個分組流被分配給一 AlO連接或鏈路。將一分組流分配給AlO鏈路被稱為分組流“映射”，并由PDSN確定。存在多個用于這種 映射的標準和算法，所述映射可應用于圖1的系統(tǒng)100中。如上文所討論，MS102和BS104之間的每個SO連接或鏈路具有BS104和 PDSN106之間相應的AlO連接或鏈路。通過BS104的虛線示出了此對應。SO/AIO連 接可以用于雙向或互動通信，諸如IP上語音(VoIP)通信，或者可以用于諸如下載數(shù)據(jù)的 單向通信，或者用于從互聯(lián)網(wǎng)源流出信息。隨著數(shù)據(jù)通信類型數(shù)的增加，SO/AIO連接 可以被實現(xiàn)用于越來越多的這些通信。值得注意的是，需要多個SO連接(又稱服務實 例)來支持分組流的不同QoS要求。例如，MS102可以具有兩個活動的SO連接。第 一 SO連接，具有重發(fā)機制以便以傳輸延時為代價提供可靠的空中傳送，因此用于傳送要 求可靠傳輸?shù)臄?shù)據(jù)。第二 SO連接可以不具有重發(fā)機制，并用于傳送需要急速傳輸?shù)臄?shù) 據(jù)。PDSN106還包括認證記賬和特許(AAA)112。AAA112用作認證連接和通過 電信公司或服務提供者跟蹤記賬財務等。PDSN106從相應節(jié)點(CN) 108以及從其它源 110接收分組流。CN108可以是因特網(wǎng)上的一個節(jié)點、服務提供者、終端等。換言之， CN108是信息源或者通信的參與者。值得注意的是，PDsmoe可以從多個源接收多個分 組流，其中所述分組流去往多個參與者，諸如MS102。每個分組流被映射到相應的SO/ AlO連接，并且按照參與者協(xié)商的參數(shù)處理。當多個服務實例被建立給諸如MS102的指定用戶時，每個分組流的流映射和處 理特別重要。如果MS102具有多個活動的服務實例并且MS102使用多個頭部壓縮算法， 則PDSN106將期望用于處理與每個服務實例相關(guān)的分組流的信息。信息包括但不限制于 用于每個分組流的特定頭部壓縮算法，以及每個分組流到每個AlO連接的映射。這里下面所描述的實施例是通過RSVP消息提供流處理信息的一方法，所述 RSVP消息包含稱為流處理的新對象。RSVP消息是為互聯(lián)網(wǎng)上綜合服務所設(shè)計的資 源保存建立協(xié)議，在RFC2205中被描述，所述RFC2205標題為“ResourceReSerVation Protocol (RSVP)，，，作者為R.Bnmden等。RSVP協(xié)議被主機用于從某些應用數(shù)據(jù)流的網(wǎng) 絡(luò)請求特定服務質(zhì)量。RSVP也被路由器用于將服務質(zhì)量(QoS)傳遞到沿流的路徑的所 有節(jié)點，以及建立和保持提供請求服務的狀態(tài)。RSVP請求一般導致源被保留在沿數(shù)據(jù) 路徑的每個節(jié)點內(nèi)。RSVP消息提供雙向分組流(例如，互動VoIP會話)或單向分組流 (例如，流會話)的分組濾波器。分組濾波器被節(jié)點用于識別某個分組流。RSVP將“會話”定義為具有某個目的地和傳輸層協(xié)議的數(shù)據(jù)流。RSVP獨立 地處理每個會話。RSVP會話由三元組定義(DestAddress、ProtocolId[DstPort])。這里 DestAddress>數(shù)據(jù)分組的IP目標地址可以是單播或多播地址。ProtocolId是IP協(xié)議ID。 可任選的DstPort參數(shù)是“廣義的目的地端口”，即傳輸或應用協(xié)議層中的一些進一步解 復用的點。DstPort能通過用戶數(shù)據(jù)報協(xié)議/傳輸控制協(xié)議(UDP/TCP)目標端口字段、 通過另一傳輸協(xié)議中的等價字段、或者通過一些應用專用信息來定義。建立一主要服務實例后，當MS102決定建立輔助服務實例時，MS102發(fā)送 RSVP PATH和RESV消息以請求服務質(zhì)量(QoS)資源。在RSVP RESV消息中，MS102 將通過IP地址和端口號表征數(shù)據(jù)流，并且傳遞編解碼類型和頭部壓縮類型。接收RSVP RESV消息后，PDSN將檢驗信息并且請求到BS的新的AlO連接，并且將新建立的AlO連接與由濾波器說明和可任選地由會話級別(下文中關(guān)于RSVP類型協(xié)議而定義)所表征 的分組流相關(guān)聯(lián)。圖4詳細描述了與RFC2205 —致的RSVP消息的格式。RSVP消息被 視為一個消息的示例，所述消息可以被用于分組流處理和/或映射的問PDSN所需的信息 傳輸?？蛇x實施例可以實現(xiàn)其它消息，以提供相同或相似的信息。值得注意的是，在整個RSVP類型協(xié)議的討論中，按照數(shù)據(jù)流的方向定義方向 術(shù)語。攜帶保留請求的RSVP消息在接收端開始，并上行去往發(fā)送端。特別地，方向性 術(shù)語“上游”相對于”下游”，“前一跳”相對于“后一跳”，以及“進入接口”相 對于“外出接口”，是相對于數(shù)據(jù)流的方向而定義的。圖4說明了具有主機401和路由器450的通信系統(tǒng)，所述路由器450實現(xiàn)RSVP 協(xié)議。如所說明的，主機401包括雙向耦合到RSVP處理單元404的應用單元402。RSVP 處理單元404確定適當?shù)腞SVP消息以及用于傳輸?shù)膬?nèi)容，并且也考慮從路由器450接收 的那些RSVP消息和內(nèi)容。RSVP處理單元404被耦合到策略控制單元506。主機401 內(nèi)的通信是通過通信總線420的。主機401還包括允許控制單元408、分組調(diào)度器410以 及分級器412。繼續(xù)圖4，路由器450包括與主機401中相似的單元，然而此配置可以用略微不 同的方式實現(xiàn)。路由器450包括路由器單元452、RSVP處理單元454、策略控制單元 456、允許控制單元458、分組調(diào)度器460、分級器462，以上全都通過通信總線480通 信。值得注意的是，RSVP處理單元404將RSVP消息向RSVP處理單元454往返通信。在系統(tǒng)400內(nèi)，通過統(tǒng)稱為“話務控制”的機制對某個數(shù)據(jù)流實現(xiàn)服務質(zhì)量。 這些機制包括(1)分組分級器(分級器412、462)，(2)允許控制(允許控制408、458)， 以及(3) “分組調(diào)度器”(分組調(diào)度器410、460)或者一些其它鏈路層相關(guān)機制以確定何 時轉(zhuǎn)發(fā)某些分組?！胺纸M分級器”機制或者分級器412、462確定每個分組的QoS類(或 許是路由)。對于每個外出接口，“分組調(diào)度器”或者其它鏈路層相關(guān)機制達到允諾的 QoS。話務控制實現(xiàn)由集成所定義QoS服務模型。在保留建立期間，RSVP QoS請求被傳遞到兩個本地判決模塊“允許控制”(允 許控制408、458)和“策略控制”(406、456)。允許控制408、458確定節(jié)點是否有足 夠的可用資源來提供請求的QoS。政策控制(406、456)確定用戶是否具有管理許可，以 便進行保留。如果兩個檢查都成功，則參數(shù)被設(shè)置在分組分級器中和鏈路層接口中(例 如，在分組調(diào)度器中)，以獲得期望的QoS。如果任何一個檢查失敗，則RSVP程序?qū)⒊?錯通知返回給始發(fā)請求的應用過程。RSVP協(xié)議機制提供用于在多播或單播傳遞路徑的網(wǎng)格上創(chuàng)建和維持分布保留狀 態(tài)。RSVP本身按照不透明數(shù)據(jù)傳遞和操作QoS和政策控制參數(shù)，將它們傳遞到適當?shù)?話務控制和策略控制模塊，用于解釋。由于大的多播組的會員資格和產(chǎn)生的多播樹拓撲 可能隨時間變化，RSVP設(shè)計假定RSVP的狀態(tài)和話務控制狀態(tài)將在路由器和主機中被逐 漸建立以及銷毀。為了此目的，RSVP建立“軟”狀態(tài)；即RSVP發(fā)送周期性的更新消 息以便沿保存的路徑維持狀態(tài)。缺少更新消息的情況下，狀態(tài)自動地過期并且被刪除。 總之，RSVP具有下列屬性1.RSVP為單播和多對多的多播應用進行資源保留，動態(tài)地適應改變組成員資格 以及改變路由。
2.RSVP是單工的，即支持單向數(shù)據(jù)流的保留。3.RSVP是面向接收機的，即數(shù)據(jù)流的接收機啟動和維持用于所述流的資源保
&3 甶ο4.RSVP在路由器和主機中維持“軟”狀態(tài)，提供對動態(tài)成員資格變化和自適應 路由變化的良好支持。5.RSVP不是一路由協(xié)議，但是支持現(xiàn)在和未來的路由協(xié)議。6.RSVP傳輸和維持話務控制和策略控制參數(shù)，所述參數(shù)對于RSVP是不透明 的。7.RSVP提供幾個保留模型以適應多種應用。8.RSVP通過不支持RSVP的路由器提供透明操作。9.RSVP 支持 IPv4 和 Ipv6。示例性的RSVP保留請求由“流規(guī)范”和“濾波器規(guī)范” 一起組成；此對被稱 為“流描述符”。流規(guī)范規(guī)定期望的QoS。濾波器規(guī)范和會話規(guī)范一起定義數(shù)據(jù)分組的 集合-“流”-以接收流規(guī)范所定義的QoS。流規(guī)范被用于設(shè)置節(jié)點的分組調(diào)度器或者 其它鏈路層機制中的參數(shù)，同時濾波器規(guī)范被用于設(shè)置分組分級器中的參數(shù)。被定址到 某個會話但與那個會話的任何濾波器規(guī)范不匹配的數(shù)據(jù)分組都被作為最佳工作話務而處 理。保留請求中的流規(guī)定一般包括服務級別以及兩組數(shù)值參數(shù)(1)定義期望的QoS 的"Rspec" (R代表“保留”)，以及(2)描述數(shù)據(jù)流的"Tspec" (T代表“話務”)。 Tspec和Rspec的格式和內(nèi)容由系統(tǒng)確定，并且一般對于RSVP不透明。濾波器規(guī)范的確切格式取決于使用哪個IP版本。當前版本考慮IPv4或Ipv6。按 照一種方法，濾波器規(guī)范可以選擇給定會話中分組的任意子集合。這些子集合可以按照 發(fā)送端(即，發(fā)送端的地址以及統(tǒng)一化的源端口)、按照高層協(xié)議、或者一般按照分組中 任何協(xié)議頭部內(nèi)的字段來定義。例如，濾波器規(guī)范可能被用來通過在應用層頭部的字段 上選擇而選擇分層編碼視頻流的不同子流。為了簡明(以及最小化層違規(guī))，當前RSVP 規(guī)范中定義的基本濾波器規(guī)范格式具有非常嚴格的形式發(fā)送端IP地址和任選的UDP/ TCP 端口號 SrcPort。在每個中間節(jié)點處，保留請求觸發(fā)兩個一般操作，如下1.在鏈路上進行保留RSVP過程傳遞對允許控制和政策控制的請求。如果任何測試失敗，則保留被彈 出，而且RSVP過程將出錯消息返回適當?shù)慕邮諜C。如果兩者都成功，則節(jié)點設(shè)置分組 分級器以選擇濾波器規(guī)范定義的數(shù)據(jù)分組，而且它與適當?shù)逆溌穼踊右垣@得流規(guī)范定 義的期望的QoS。用于滿足RSVP QoS請求的詳細規(guī)則取決于每層上使用的特定鏈路層技術(shù)。例 如，對于簡單租用線，期望的QoS將從鏈路層驅(qū)動器內(nèi)的分組調(diào)度器獲得。如果鏈路層 技術(shù)實現(xiàn)它本身的QoS管理能力，則RSVP與鏈路層協(xié)商以獲得請求的QoS。值得注意 的是，控制QoS的操作發(fā)生在數(shù)據(jù)進入鏈路層媒質(zhì)處，即邏輯或物理鏈路的上游末端處 發(fā)生，盡管RSVP保留請求源自接收機下游。2.向上游轉(zhuǎn)發(fā)請求
朝著適當?shù)陌l(fā)送者向上游傳播保留請求。給定保留請求被傳播到的發(fā)送者主機 的集合被稱為那個請求的“范圍”。由于兩個原因，節(jié)點向上游轉(zhuǎn)發(fā)的保留請求不同于從下游接收的請求。話務控 制機制可以逐跳地修改流規(guī)范。更重要的是，從來自相同發(fā)送者(或發(fā)送者的集合)的 多播樹的不同下游流分支保留隨著保留向上游傳送必須被“融合”。當接收機啟動一保留請求時，它也能請求一確認消息，以指示它的請求在網(wǎng)絡(luò) 中(可能)被安裝。成功的保留請求沿多播樹向上游傳播，直到它到達存在的保留等于 或大于正在被請求的保留的點。在此點，到達的請求與原地保留融合，而且不需要被進 一步轉(zhuǎn)發(fā)；接著節(jié)點可以將保留確認消息發(fā)送回接收機。有兩個基本RSVP消息類型RESV和PATH。每個接收機主機向發(fā)送者朝上游 發(fā)送RSVP保留請求(RESV)消息。這些消息必須正好沿著數(shù)據(jù)分組將使用的路徑的反 向，向上游傳至包括在發(fā)送者選擇中的所有發(fā)送者主機。RESV消息在沿路徑的每個節(jié) 點內(nèi)產(chǎn)生“保留狀態(tài)”的建立和維持。RESV消息最后被傳遞到發(fā)送者主機本身，從而 這些主機能為沿路徑的第一跳建立適當?shù)脑拕湛刂茀?shù)。每個RSVP發(fā)送者主機嚴路由協(xié)議提供的單/多播路由向下游發(fā)送 RSVP “PATH”消息，沿著數(shù)據(jù)的路徑。這些RSVP PATH消息存儲沿此方向的每個節(jié) 點內(nèi)的“路徑狀態(tài)”。此路徑狀態(tài)至少包括前一跳節(jié)點的IP地址，所述地址被用于沿反 方向逐跳地路由RESV消息。值得注意的是，未來的設(shè)計可以實現(xiàn)路由協(xié)議，所述協(xié)議 直接提供轉(zhuǎn)發(fā)信息的反向路徑，替代路徑狀態(tài)的反向路由功能。PATH消息還包含除前一跳地址的下列信息1.發(fā)送者模板PATH消息被要求傳輸發(fā)送者模板，所述發(fā)送者模板描述發(fā)送者將始發(fā)的數(shù)據(jù)分 組的格式。此模板使用濾波器規(guī)范的形式，所述濾波器規(guī)范能被用于從同一鏈路上同一 會話中的其他人選擇發(fā)送者的分組。發(fā)送者模板具有與出現(xiàn)在Resv消息中的濾波器規(guī)范 完全相同的表示功率和格式。因此，發(fā)送者模板可以只規(guī)定發(fā)送者IP地址以及可任選地 UDP/TCP發(fā)送者端口，并且采用為此會話規(guī)定的協(xié)議Id。2.發(fā)送者 TspecPATH消息被要求傳輸發(fā)送者Tspec，所述發(fā)送者Tspec定義發(fā)送者將產(chǎn)生的數(shù)據(jù) 流的話務特性。此Tspec被話務控制用來阻止過保留，以及也許是非必要的允許控制失 敗。3. Adspec路徑消息可以傳輸OPWA廣告信息的分組，所述OPWA廣告信息被稱為 “Adspec”。PATH消息中接收的Adspec被傳遞到本地話務控制，本地話務控制返回一
更新的Adspec;更新版本接著向下游發(fā)送的PATH消息中被轉(zhuǎn)發(fā)。PATH消息與相同的源 和目的地址一起作為數(shù)據(jù)被發(fā)送，從而它們將被通過非RSVP云正確路由。另一方面， RESV消息被逐跳地發(fā)送；每個RSVP講話節(jié)點將一 RESV消息轉(zhuǎn)發(fā)到前一 RSVP跳的單 播地址。圖2說明了 MS102、BS104(包括分組控制功能(PCF)操作)、PDSN106、 AAA108以及CNllO之間的雙向互動呼叫處理。在從標有1到16的步驟中按照時間順序描述此流。在步驟1處，移動站能發(fā)送應用觸發(fā)的會話啟動協(xié)議(SIP)信令前，MS建立服 務選項(SO)，諸如分組數(shù)據(jù)服務S033。在示出的示例中，無線鏈路協(xié)議(RLP)重發(fā)被 使能。這提供了 SIP消息被可靠地經(jīng)空中傳播的機制。值得注意的是，SIP在LRosenberg 等人所著、由因特網(wǎng)工程工作小組發(fā)表、具有文獻號draft-ietf-sip-rfc2543bis_08.ps、日 期為2002年2月21日發(fā)表的"SIP Session Initiation Protocol"中被詳細描述；并且還 在M.Handley等人所著、由網(wǎng)絡(luò)工作組發(fā)表、具有文獻號為RFC 2543、日期為1999年3 月的 ‘‘SIP: Session Initiation Protocol"中也被詳細描述。會話啟動協(xié)議(SIP)是用于建立、修改和終斷與一個或多個參與者的會話的應用 層控制(信令)協(xié)議。這些會話包括因特網(wǎng)電話呼叫、多媒體分布、以及多媒體會議。 用于建立會話的SIP邀請攜帶允許參與者對一組相容的媒質(zhì)類型達成協(xié)議的會話描述。 SIP使用稱為代理服務器的元件來幫助路由到用戶當前位置的請求，認證和授權(quán)服務的用 戶，實現(xiàn)提供者呼叫-路由策略，以及向用戶提供特性。SIP也提供允許用戶通過代理服 務器上載它們使用的當前位置的登記功能。SIP在幾個不同傳送協(xié)議的頂層運行。在步驟2中，MS建立與PDSN的點到點(PPP)會話。這為鏈路層提供了承載 體連接，使得分組流的連接建立。值得注意的是，PPP在W.Simpson所著、網(wǎng)絡(luò)工作組 發(fā)表為 RFC1661、日期為 1994 年 7 月的 ‘‘The Point-to-PointProtocol (PPP) ” 中被詳細描 述。在步驟3中，PDSN向包含MS網(wǎng)絡(luò)訪問標識符(NAI)和憑證的AAA發(fā)送訪問請 求。NAI對于MS是唯一的標識符。所述憑證是由MS響應于詢問握手認證協(xié)議(CHAP) (如果使用簡單IP)或外部代理詢問(如果使用移動IP)而計算的認證碼。在步驟4中，如果移動方成功地被認證，則AAA發(fā)送包含用戶預訂特性的訪問 接受。特性由兩部分組成空中(OTA)分量；以及IP分量。在步驟5中，PDSN接收和緩沖用戶IP預定特性并且將用戶OTA預訂特性轉(zhuǎn)發(fā) 給BSo在步驟6中，移動方通過PPP/S033發(fā)送SIP信令。SIP信令用于建立與CN的 虛擬承載體連接。這是分組流將通過其被傳輸?shù)腎P承載體連接。在步驟7中，CN被SIP信令(例如，183會話進程)觸發(fā)，向MS發(fā)送 RSVPPATH消息。在RSVP PATH消息中，CN包括標準RSVP對象發(fā)送者模板和發(fā)送 者話務規(guī)范(Tspec)，所述Tspec表征將由CN產(chǎn)生的分組流。在步驟8中，PDSN將 RSVP PATH消息轉(zhuǎn)發(fā)到MS。在步驟9中，接收到RSVP PATH消息后，MS使用包含在 此消息中的信息計算用于接收分組流的期望的QoS參數(shù)(即，帶寬和延時)。接著，移 動站沿著到CN的路徑發(fā)送RSVP PATH消息以保留資源。RSVPPATH消息包含流規(guī)范、 濾波器規(guī)范、以及處理規(guī)范，所述處理規(guī)范是專用于一些系統(tǒng)，所述系統(tǒng)支持名為“3rd Generation Partnership Project 2” (這里稱為3GPP2)的協(xié)會提供的標準以及TR-45.5 (這 里稱為cdma2000標準)。流規(guī)范規(guī)定期望的QoS。流規(guī)范被用于設(shè)置節(jié)點的分組調(diào)度器或者其它鏈路層 機制中的參數(shù)。保留請求中的流規(guī)范一般將包括服務等級和兩組數(shù)字參數(shù)(1)定義期 望的QoS的“Rspec”(R代表“保留”)，以及⑵描述數(shù)據(jù)流的“Tspec”(Τ代表“話務”)。Tspec和Rspec的格式和內(nèi)容由綜合服務模型確定，一般對于RSVP是不透 明的。濾波器規(guī)范定義用于分組流的分組濾波器，所述分組流的QoS由流規(guī)范定義。 濾波器規(guī)范被用于設(shè)置分組分級器中的參數(shù)。被定址在某會話但與那個會話的任何濾波 器規(guī)范不匹配的數(shù)據(jù)分組被處理為最佳工作話務。處理規(guī)范，是一新的RSVP對象，傳遞應該用在分組流上的頭部壓縮類型。接收到RSVP RESV消息后，PDSN基于PDSN加載和本地政策、移動可達性以 及用戶的IP預訂特性執(zhí)行授權(quán)。如果PDSN拒絕RSVP RESV消息，則PDSN向CN發(fā) 送RSVPTear消息，向MS發(fā)送PATHTear消息?；蛘呷绻鸕SVP RESV被授權(quán)，貝Ij PDSN 檢驗RSVP RESV消息的處理規(guī)范。處理規(guī)范包含MS想在分組流上使用的頭部壓縮類 型。PDSN確定是否需要新的AlO連接。如果需要，則在步驟10中PDSN將All注冊 更新(RUP)消息發(fā)送到BS，以便請求新的AlO連接。例如如果頭部壓縮類型是LLAROHC，貝IJ PDSN通過All向BS提供通知，以
建立新的AlO連接，并且啟動諸如與MS的SO 61的所選服務選項實例的建立。如果頭部壓縮類型是ROHC，則PDSN通過All向BS發(fā)送通知，以建立新的 AlO連接，以及啟動諸如與MS的SO 33 (無RLP重發(fā))的輔助服務選項實例的建立。頭部壓縮類型和SO之間的關(guān)聯(lián)可以在PDSN或BS內(nèi)完成。如果此關(guān)聯(lián)在PDSN 中被完成，則All RUP消息將包含SO號，而且BS使用它啟動與MS的服務協(xié)商。如 果此關(guān)聯(lián)在BS內(nèi)完成，則All RUP消息將包含頭部壓縮類型，而且BS將它與SO號相 關(guān)聯(lián)，并且使用它啟動與MS的服務協(xié)商。在步驟11中，BS響應于All注冊確認(RACK)消息。在步驟12中，BS嘗 試通過呼叫分配消息(CLAM)連接All信令消息內(nèi)規(guī)定的SO。在步驟13中，BS連接 所選SO。在步驟14中，BS發(fā)送All RRQ (注冊請求)，以建立AlO連接，在步驟15 中，PDSN用All RRP (注冊應答)響應。在步驟16中，成功建立新的AlO連接后，PDSN將新建立的AlO連接與從步驟 9中RSVP RESV消息的濾波器規(guī)范中獲得的分組濾波器相關(guān)聯(lián)。這使得PDSN執(zhí)行分組 流上的流映射，所述分組流符合分組流濾波器的描述。PDSN將處理說明從RSVP RESV 消息移除，并且將它朝著CN發(fā)送。如果由于一些原因，一個過時之后新的AlO連接沒 有被建立，則PDSN向MS發(fā)送TATHTear消息。從此點，通過PDSN從CN到MS處理分組流。PDSN對數(shù)據(jù)流執(zhí)行適當?shù)念^部 壓縮，并且將此分組流轉(zhuǎn)發(fā)到適當?shù)腁lO連接。值得注意的是，圖2示出了從CN到MS的單向通信。對于CN和MS之間的互 動雙向通信，MS和CN都是源和目的地。因此，除了圖2中示出的以及上面詳細描述 的步驟，從MS啟動對稱的步驟。例如，MS也發(fā)送RSVP路徑消息，同樣，PDSN將 PSVP路徑消息轉(zhuǎn)發(fā)到CN。CN提供RSVP RESV消息；而且PDSN將RSVP RESV消息 轉(zhuǎn)發(fā)到MS。來自CN的RSVP RESV消息將不必觸發(fā)PDAN以請求如步驟10中的AlO 連接建立。對于不使能RLP重發(fā)的輔助SO 33的現(xiàn)存AlO連接的形式，一實施例使用的現(xiàn) 存的連接。按照一可選實施例，BS建立與MS的另一輔助S033。在此情況下，如果MS拒絕，則現(xiàn)存輔助SO 33被用于也傳輸新的編解碼。圖2示出了擴頻通信系統(tǒng)中的呼叫流，所述通信系統(tǒng)適用于IP通信，而且能處 理分組流?？蛇x通信系統(tǒng)可以被用來提供處理分組流的必要信息。這樣的信息不限于本 示例中詳細描述的具體信息，而是可以包括系統(tǒng)組件需要或期望的任何信息。同樣，可 以按照給定系統(tǒng)的設(shè)計和需要改變步驟的順序。圖2的呼叫流被提供作為分組流處理的 示例。這里下面描述的實施例是通過RSVP消息提供流處理和流映射信息的另一方 法。流處理和映射信息能從RSVP RESV消息中傳遞的標準RSVP對象導出，而且沒有 新的RSVP對象需要如前面的方法中那樣被定義。呼叫流與圖2中的一樣。一個區(qū)別是，在步驟9中RSVP RESV消息只包含流 規(guī)范和濾波器規(guī)范。沒有處理規(guī)范來明確表明PDSN應該在分組流上使用什么頭部壓縮 類型。而是，PDSN使用流規(guī)范來隱含地確定頭部壓縮類型。流規(guī)范包括保留規(guī)范(Rspec)和Traffic Spec(Tspec)。Rspec描述了服務速率， Tspec描述了表征CN將產(chǎn)生的話務的標記記錄參數(shù)(記錄速率、峰值速率、記錄部分、 最大分組大小)。Rspec和Tspec —起表征CDMA語音編解碼器(例如，13-kbps的純語 音、8-kbps的EVRC、8-kbps的SMV或者4kbps的SMV)，所述CDMA語音編解碼器每 20ms輸出一個語音幀。PDSN被配置來基于流規(guī)范中的參數(shù)值而識別CDMA語音編解 碼。如果匹配而且MS支持LLAROCH，則PDSN請求BS建立一新的AlO連接，而且 BS建立與MS的SO 61。如果不匹配，則PDSN得出結(jié)論分組流傳輸不同于CDMA語音 編解碼的實時編解碼；這樣，如果MS支持ROHC并且當時沒有輔助的SO 33，則PDSN 請求BS建立新的AlO連接，而且BS建立與MS的輔助SO 33 (不使能RLP重發(fā))?？赡懿煌木幗獯a具有如CDMA編解碼一樣的Rspec和Tspec描述。例如，編 解碼X被表征為服務速率8kbps、20毫秒的恒定的分組間間隔、以及加上頭部雜項開銷的 最大分組大小為171，上述與EVRC特征相同。這項貢獻推薦，O字節(jié)的頭部壓縮被應用 于傳輸編解碼X的分組流，如同它是EVRC。盡管編解碼X的較低速率幀大小可能會不 同于EVRC的，每個較低速率幀能被插入并且填入CDMA物理層幀(全速率、1/2、1/4 或者1/8速率)。圖3說明了呼叫流處理，其中PDSN從“sniffing” SIP消息確定流處理和/或 映射。鑒別(sniffing)指檢驗尋找特定信息的消息的過程。通常，節(jié)點將對特定信息鑒 別，而忽略所有其它信息。在圖3中說明的實施例中，PDSN對期望確定給定分組流的 處理的特定信息鑒別，和/或?qū)o定分組流的映射鑒別。PDSN對SIP信令消息鑒別。 PDSN忽略SIP消息的其它內(nèi)容。可選實施例可以應用SIP消息中的其它內(nèi)容，所述SIP 消息用于這些處理或者PDSN的其它操作。圖3中說明的實施例提供確定流處理和流映射信息的可選方法，其中這樣的確 定基于PDSN測錯會話啟動協(xié)議(SIP)消息。此方法依賴PDSN對SIP消息鑒別，以確 定IP地址、端口號、以及將由CN產(chǎn)生的新分組流的編解碼。這為PDSN提供充足的信 息來確定流處理和流映射。PDSN也確定是否需要新的AlO連接來傳輸分組流。如果需 要，則PDSN請求BS建立AlO連接，而且BS啟動與MS的新服務實例的建立。對SIP消息鑒別需要PDSN識別出，IP分組攜帶SIP消息并且從SIP消息中選出基本信息。PDSN檢驗分組的目的地端口號。如果它等于5060，則傳輸負載攜帶SIP消 息。值得注意的是，有多個SIP消息和字段。PDSN注意SIPINVITE和SIP 200 OK消 息，并且可以選擇忽略其它SIP消息。值得注意的是，SIP定義多個消息。SIPINVITE 消息指示用戶或服務正被邀請來參加一會話。SIP 200 OK消息指示請求已經(jīng)成功。在 SIP INVITE和SIP 200 OK消息內(nèi)，PDSN注意傳送IP地址信息的連接字段、傳遞端口號 信息的媒質(zhì)字段、以及傳遞編解碼類型的屬性字段?；诰幗獯a類型，PDSN確定在分 組流上使用哪種頭部壓縮類型。例如，如果編解碼類型指示一 CDMA編解碼(例如，純 語音、EVRC或SMV)，鏈路層輔助魯棒頭部壓縮(LLAROHC)將被使用；如果編解碼類 型指示一不同于CDMA編解碼的編解碼，則魯棒頭部壓縮(ROHC)將被使用?？蛇x的系 統(tǒng)可以支持幾種編解碼類型中的任一，而且這里提供的特定細節(jié)用作示例。PDSN確定頭部壓縮類型之后，PDSN確定對于新分組流，是否需要一新的AlO 連接。如果需要，則PDSN請求BS建立AlO連接，而且BS啟動與MS的新服務實例的 建立。成功建立AlO連接之后，PDSN將AlO連接與從對SIP消息鑒別獲得的分組濾波 器相關(guān)聯(lián)，SIP消息即SIP INVITE和SIP 200 OK消息的連接字段和媒質(zhì)字段。圖5說明了適用于處理分組流的MS500。MS500包括天線510、接收機520和 發(fā)射機530。接收機520和發(fā)射機530各自被耦合到中央處理單元(CPU) 540。CPU540 和存儲器550各自被耦合到通信總線560。而且，分組流建立單元570、分組流處理單元 580、以及分組流確定單元590各自被耦合到通信總線560。分組流確定單元590確定通 信是雙向的還是單向的。分組流建立單元570確定分組流的細節(jié)，諸如編解碼類型、頭 部壓縮。分組流建立單元570和分組流確定單元590涉及在初始訪問中，并且為分組流 的傳輸而被建立，諸如圖2和3中所說明的。一旦通信被建立，則分組流處理單元580 按照建立的特定參數(shù)處理分組流。本發(fā)明提供用于不依靠差分服務編碼點(DSCP)通信RSVP消息中的分組流參數(shù) 的靈活的方法，所述DSCP在IP頭部、協(xié)議類型和公知的端口號的字段中被傳遞。使用 諸如RSVP消息的消息可以用于雙向和單向分組流。使用現(xiàn)存消息來提供分組流信息達到有效的空中源分配和使用準則。在一實施 例中，用于通信的新的承載體連接，即新的AlO連接沒有被建立，直到RSVP保留被授 權(quán)。這避免了在拒絕時要求承載體連接(即，輔助SO、A8/A10連接)的中斷。在一可選實施例中，附加的服務實例建立可以如圖6中所說明的那樣被初始 化。圖6的呼叫流圖表說明了當MS已經(jīng)隨建立的主要服務實例而活動時，附加服務實 例建立的步驟，步驟如下所示在a點，PDSN確定建立附加的服務實例；PDSN向PCF發(fā)送All-注冊更新。 All注冊更新消息允許PDSN指示應用的頭部壓縮算法。PDSN啟動與注冊更新消息(稱 為計時器“T’ regupd")相關(guān)聯(lián)的計時器。在點b，PCF將A9-BS服務請求消息發(fā)送到BS，以便請求附加的服務實例，并 且啟動稱為計時器“Tbsreq9”的計時器。頭部壓縮算法和服務選項之間的映射在PCF或 BS中執(zhí)行。按照一個實施例，所述確定由TSG-A(技術(shù)規(guī)定組)進行。如果由PCF執(zhí) 行映射，則對于現(xiàn)有的A9-BS服務請求消息不進行任何改變。如果在BS中執(zhí)行映射， 則PCF在A9-BS服務請求消息中將對BS指示應用頭部壓縮算法。例如，映射表可以被規(guī)定如下
頭部壓縮算法服務選項ROHCS033LLAROHCS060 或 S061在步驟c中，BS向MSC發(fā)送附加服務請求消息，并且啟動稱為計時器“T3Q3” 的計時器來重連附加的服務實例。在步驟d中，MSC向BS發(fā)送分配請求消息，以請求分配無線資源和BS與PCF 之間的A8(例如，用戶話務)連接。MSC接著啟動稱為計時器"Tltl”的計時器。在從 MSC接收到分配請求消息后，BS終止計時器T3(l3。在步驟e，BS響應于A9-BS服務響應。PCF在接收到A9-BS服務響應消息之 后終止計時器Tbsreq9.在步驟f，從BS接收到成功的A9-BS服務響應消息后，PCF響應于All-注冊 確認。PDSN終止計時器T ’ regupd。在步驟g中，BS可以在無線接口的話務信道上發(fā)送呼叫分配消息，以啟動CC 狀態(tài)機(呼叫控制狀態(tài)機)的建立。在步驟h中，BS向MS發(fā)送下列消息之一，來調(diào)用附加服務選項連接i)服務 連接消息；ii) 一般切換方向消息；或者iii)通用切換方向消息。在步驟i中，可以在MS和BS之間執(zhí)行服務協(xié)商。在步驟j中，MS完成服務協(xié)商過程后，用服務連接完成消息作出響應。在步驟k中，BS向PCF發(fā)送A9-建立-A8消息，來在BS和用于附加服務實例 的PCF之間通過A9(例如，信令)連接而建立A8(即，用戶話務)連接。接著，BS啟 動稱為計時器“TA8_S一”的計時器。在步驟1中，PCF識別存在與此移動站相關(guān)聯(lián)的AlO連接，以及附加的AlO連 接需要被建立。PCF向相應的PDSN發(fā)送All-注冊請求消息。PCF啟動稱為計時器
“T’ regreq"的計時器。在步驟m中，PDSN通過返回具有接受指示的All-注冊響應消息而接受此連接。在步驟η中，PCF用Α9-連接-Α8消息響應，以完成對此分組服務請求的Α8 (例 如，用戶話務)連接的建立。當從PCF接收到Α9-連接-Α8消息之后，BS終止計時器
TA8-Setup °在步驟ο中，在已經(jīng)建立無線服務連接和AlO連接后，BS向MSC發(fā)送分配完 成消息。接著，當MSC發(fā)送分配請求消息(見步驟d)時，MSC終止計時器T1(1。值得注意的是，PDSN可以通過使用系統(tǒng)所支持的消息啟動一請求，來增加新的 AlO連接。PDSN向PCF發(fā)送All-注冊更新消息，以請求增加新的AlO連接。PDSN 發(fā)送All-注冊更新消息，消息中的編碼字段被設(shè)置為“增加新連接”，以請求PCF建立 一新的AlO連接。接著，PDSN在發(fā)送All-注冊更新消息后啟動與注冊更新相關(guān)聯(lián)的計時器(稱為“T’ regupd")，并且等待來自PCF的All-注冊確認消息。如果計時器T，regupd超時，PDSN以可配置的次數(shù)向PCF重發(fā)All-注冊更新
消息。在可配置次數(shù)重發(fā)后而沒有來自PCF的響應后，會話建立步驟可以被認為失敗， 然而現(xiàn)存的AlO連接將維持連通。如果請求的操作能被BS、PCF和MSC成功地支持，則PCF向PDSN發(fā)送 All-注冊確認消息以確認請求的AlO連接被接受。接收具有被設(shè)置為“增加新連接”的消息的編碼字段的All-注冊更新消息后， 如果PCF支持請求的AlO連接，貝IJ PCF將向BS發(fā)送A9-BS服務請求消息。如果MSC 和BS支持新連接，則PCF將通過將消息中的狀態(tài)字段設(shè)置為“新連接被接受”而如此指 示。接收到此消息后，當All-注冊更新消息被發(fā)送時PDSN將終止計時器T’ requpd, 當接收到Al I-Ack時停止。接收具有被設(shè)置為“增加新連接”的消息的編碼字段的All-注冊更新消息后， 如果PCF不支持請求的AlO連接，或請求的連接由從BS接收的A9-BS服務響應消息所 拒絕，則PCF將通過將消息的狀態(tài)字段設(shè)置為“拒絕新連接”而如此指示。接收到此消 息后，PDSN終止計時器T ’ requpd ο如果PDSN從PCF接收All-注冊更新消息消息失敗，則PDSN在認為新建立失 敗前可以以可配置的次數(shù)重發(fā)All-注冊更新消息。上述每個消息可以包括任何數(shù)目的字段和編碼，如系統(tǒng)所定義。例如，按照 3GPP2中的設(shè)計所建議，All-注冊更新消息包括一編碼。當此消息要求附加連接或請求 對現(xiàn)存連接更新時，編碼信息單元被包括。編碼單元標識處理All-注冊更新消息的結(jié) 果。例如，編碼(十進制)33指示“增加新連接”。同樣，All-注冊更新消息具有標識處理All-注冊更新消息的結(jié)果的相關(guān)聯(lián)的 狀態(tài)單元。例如，狀態(tài)(十進制)149指示“接受新連接”；而狀態(tài)(十進制)150指示
“拒絕新連接”。另外，正常的銷售商/組織特定擴展(NVSE)-應用類型OAH(十六進制值)指 示頭部壓縮算法。接著，應用子類型被用于標識具體算法。例如，(十六進制值)01H 標識魯棒頭部壓縮(ROHC)，同時(十六進制)02H標識鏈路層輔助ROHC (LLAROHC)。 MN會話參考ID字段被用于唯一地標識移動站中的分組數(shù)據(jù)服務實例。MN會話參考ID 從移動站被傳遞到PCF。對于應用類型OAH (頭部壓縮算法)，MN會話參考ID字段包 含以進制11八的頭部壓縮算法。多信道流處理協(xié)議(MCFTP)被定義為新的PPP協(xié)議類型。MCFTP攜帶關(guān)于分 組流和SR_ID之間棒綁定的信息，SR_ID用于O字節(jié)的頭部壓縮，諸如在MS和PDSN之 間流應該如何被映射到基于的服務實例連接。如果頭部移去模式在MS和PDSN之間使 用，則MCFTP也將IR-靜態(tài)信息從MS傳輸?shù)絇DSN。MCFTP的信息元件按照類型、 長度、值(TLV)原則設(shè)計，所述原則依需要允許協(xié)議的簡單擴展。在可通信任何MCFTP分組前，PPP將到達網(wǎng)絡(luò)層協(xié)議階段。MCFTP分組在圖 9中被說明。多于一個MCFTP分組可以被封裝在PPP信息字段中，其中協(xié)議號指示協(xié)議 x0289 (MCFTP)。MCFTP使用三個基本消息格式MCFTP-請求(操作代碼=1)
MCFTP-響應(操作代碼=2)MCFTP-拒絕(操作代碼=7)MCFTP-請求消息格式被發(fā)送，代碼等于1，并且包含表1中示出的字段。表1 .MCFTP請求消息格式
字段字段長度值代碼1字節(jié)1ID1字節(jié)標識請求者設(shè)定的請求的ID字段長度2字節(jié)以字節(jié)為單位的分組的全長任選項可變(TLV格式)話務流模板(TFT) Type = 1響應于被成功接收和處理的MCFTP-請求消息而發(fā)送MCFTP-響應。它只是是 包括空主體或IR-靜態(tài)信息的MCFTP分組。MCFTP-響應消息格式被發(fā)送，代碼等于 2，并且包括表2中示出的字段。表2.MCFTP響應消息格式
字段字段長度值代碼1字節(jié)2ID1字節(jié)用于匹配相應請求的ID字段長度2字節(jié)以字節(jié)為單位的分組的全長選項可變(TLV格式)IR-靜態(tài)Type = 1響應于不能被處理的MCFTP-請求消息而發(fā)送MCFTP-拒絕消息，諸如當接收 機不能標識接收選項或子選項時不能處理的MCFTP-請求消息。MCFTP-拒絕分組格式 被發(fā)送，代碼等于7，并且包含表3中示出的字段。表3LMCFTP拒絕分組格式
權(quán)利要求
1.一種在通信系統(tǒng)中的基礎(chǔ)結(jié)構(gòu)實體的操作方法，其包括 檢驗至少兩個通信實體之間交換的數(shù)據(jù)分組；檢測來自數(shù)據(jù)分組的分組流參數(shù)信息；以及基于從數(shù)據(jù)分組檢測的分組流參數(shù)信息確定所述至少兩個通信實體之間交換的數(shù)據(jù) 分組的分組流處理。
2.如權(quán)利要求1所述的方法，其中交換的數(shù)據(jù)分組來自資源保留消息。
3.如權(quán)利要求1所述的方法，其中交換的數(shù)據(jù)分組來自會話啟動消息。
4.如權(quán)利要求1所述的方法，包括在確定分組流處理之后在至少兩個通信實體之間建 立承載體連接。
5.如權(quán)利要求4所述的方法，還包括在基礎(chǔ)結(jié)構(gòu)實體和至少兩個通信實體中的一個之 間建立新的連接作為承載體連接的一部分。
6.如權(quán)利要求1所述的方法，其中分組流參數(shù)信息包括服務質(zhì)量、頭部壓縮和編解碼 中至少之一。
7.如權(quán)利要求6所述的方法，其中確定分組流處理包括授權(quán)分組流參數(shù)信息的使用。
8.—種在通信系統(tǒng)中的通信實體的操作方法，包括經(jīng)由基礎(chǔ)結(jié)構(gòu)實體發(fā)送包括分組流參數(shù)信息的消息到另一個通信實體，該基礎(chǔ)結(jié)構(gòu) 實體確定在所述通信實體和另一個通信實體之間交換的數(shù)據(jù)分組的分組流處理；以及 如果基礎(chǔ)結(jié)構(gòu)實體確定需要新的分組流處理，則接收用于建立連接的消息。
9.如權(quán)利要求8所述的方法，其中所述消息是資源保留消息。
10.如權(quán)利要求8所述的方法，其中所述消息是會話啟動消息。
11.如權(quán)利要求8所述的方法，還包括經(jīng)由承載體連接與另一個通信實體進行通信， 該承載體連接包括在基礎(chǔ)結(jié)構(gòu)實體和通信實體之間的新的連接。
12.如權(quán)利要求8所述的方法，其中分組流參數(shù)信息包括服務質(zhì)量、頭部壓縮和編解 碼中至少之一。
13.如權(quán)利要求11所述的方法，其中確定分組流處理包括授權(quán)分組流參數(shù)信息的使用。
14.一種通信系統(tǒng)中的基礎(chǔ)結(jié)構(gòu)實體，包括用于檢驗至少兩個通信實體之間交換的數(shù)據(jù)分組的裝置； 用于檢測來自數(shù)據(jù)分組的分組流參數(shù)信息的裝置；以及用于基于從數(shù)據(jù)分組檢測的分組流參數(shù)信息確定在所述至少兩個通信實體之間交換 的數(shù)據(jù)分組的分組流處理。
15.如權(quán)利要求14所述的基礎(chǔ)結(jié)構(gòu)實體，其中交換的數(shù)據(jù)分組來自資源保留消息。
16.如權(quán)利要求14所述的基礎(chǔ)結(jié)構(gòu)實體，其中交換的數(shù)據(jù)分組來自會話啟動消息。
17.如權(quán)利要求14所述的基礎(chǔ)結(jié)構(gòu)實體，還包括在確定分組流處理之后在至少兩個通 信實體之間建立承載體連接的裝置。
18.如權(quán)利要求17所述的基礎(chǔ)結(jié)構(gòu)實體，還包括在基礎(chǔ)結(jié)構(gòu)實體和至少兩個通信實體 中的一個之間建立新的連接作為承載體連接的一部分。
19.如權(quán)利要求14所述的基礎(chǔ)結(jié)構(gòu)實體，其中分組流參數(shù)信息包括服務質(zhì)量、頭部壓 縮和編解碼中至少之一。
20.如權(quán)利要求19所述的基礎(chǔ)結(jié)構(gòu)實體，其中確定分組流處理的裝置包括授權(quán)分組流 參數(shù)信息的使用的裝置。
21.—種通信系統(tǒng)中的通信實體，包括用于經(jīng)由基礎(chǔ)結(jié)構(gòu)實體發(fā)送包括分組流參數(shù)信息的數(shù)據(jù)分組到另一個通信實體， 該基礎(chǔ)結(jié)構(gòu)實體確定在所述通信實體和另一個通信實體之間交換的數(shù)據(jù)分組的分組流處 理；以及用于在基礎(chǔ)結(jié)構(gòu)實體確定需要新的分組流處理時，接收用于建立連接的消息的裝置。
22.如權(quán)利要求21所述的通信實體，其中所述數(shù)據(jù)分組來自資源保留消息。
23.如權(quán)利要求21所述的通信實體，其中所述數(shù)據(jù)分組來自會話啟動消息。
24.如權(quán)利要求21所述的通信實體，還包括經(jīng)由承載體連接與另一個通信實體進行通 信的裝置，該承載體連接包括在基礎(chǔ)結(jié)構(gòu)實體和通信實體之間的新的連接。
25.如權(quán)利要求21所述的通信實體，其中分組流參數(shù)信息包括服務質(zhì)量、頭部壓縮和 編解碼中至少之一。
26.如權(quán)利要求25所述的通信實體，其中確定分組流處理的裝置包括授權(quán)分組流參數(shù) 信息的使用的裝置。
27.—種通信系統(tǒng)中的基礎(chǔ)結(jié)構(gòu)實體，包括被如下配置的電路檢驗至少兩個通信實體之間交換的數(shù)據(jù)分組；檢測來自數(shù)據(jù)分組的分組流參數(shù)信息；以及基于從數(shù)據(jù)分組檢測的分組流參數(shù)信息確定在所述至少兩個通信實體之間交換的數(shù) 據(jù)分組的分組流處理。
28.如權(quán)利要求27所述的基礎(chǔ)結(jié)構(gòu)實體，其中交換的數(shù)據(jù)分組來自資源保留消息。
29.如權(quán)利要求27所述的基礎(chǔ)結(jié)構(gòu)實體，其中交換的數(shù)據(jù)分組來自會話啟動消息。
30.如權(quán)利要求27所述的基礎(chǔ)結(jié)構(gòu)實體，其中所述電路還被配置成在確定分組流處理 之后在至少兩個通信實體之間建立承載體連接。
31.如權(quán)利要求30所述的基礎(chǔ)結(jié)構(gòu)實體，其中所述電路還被配置成在基礎(chǔ)結(jié)構(gòu)實體和 至少兩個通信實體中的一個之間建立新的連接作為承載體連接的一部分。
32.如權(quán)利要求27所述的基礎(chǔ)結(jié)構(gòu)實體，其中分組流參數(shù)信息包括服務質(zhì)量、頭部壓 縮和編解碼中至少之一。
33.如權(quán)利要求32所述的基礎(chǔ)結(jié)構(gòu)實體，其中所述電路還被配置成確定分組流處理， 確定分組流處理還被配置成授權(quán)分組流參數(shù)信息的使用。
34.—種通信系統(tǒng)中的通信實體，包括被如下配置的電路經(jīng)由基礎(chǔ)結(jié)構(gòu)實體發(fā)送包括分組流參數(shù)信息的數(shù)據(jù)分組到另一個通信實體，該基礎(chǔ) 結(jié)構(gòu)實體確定在所述通信實體和另一個通信實體之間交換的數(shù)據(jù)分組的分組流處理；以 及如果基礎(chǔ)結(jié)構(gòu)實體確定需要新的分組流處理時，接收用于建立連接的消息。
35.如權(quán)利要求34所述的通信實體，其中所述數(shù)據(jù)分組來自資源保留消息。
36.如權(quán)利要求34所述的通信實體，其中所述數(shù)據(jù)分組來自會話啟動消息。
37.如權(quán)利要求34所述的通信實體，其中所述電路還被配置成經(jīng)由承載體連接與另一 個通信實體進行通信，該承載體連接包括在基礎(chǔ)結(jié)構(gòu)實體和通信實體之間的新的連接。
38.如權(quán)利要求34所述的通信實體，其中分組流參數(shù)信息包括服務質(zhì)量、頭部壓縮和 編解碼中至少之一。
39.如權(quán)利要求38所述的通信實體，其中所述電路被配置成確定分組流處理，確定分 組流處理還被配置成授權(quán)分組流參數(shù)信息的使用。
全文摘要
本發(fā)明涉及在通信系統(tǒng)中的基礎(chǔ)結(jié)構(gòu)實體的操作方法和基礎(chǔ)結(jié)構(gòu)實體。操作方法包括檢驗至少兩個通信實體之間交換的數(shù)據(jù)分組；檢測來自數(shù)據(jù)分組的分組流參數(shù)信息；以及基于從數(shù)據(jù)分組檢測的分組流參數(shù)信息確定至少兩個通信實體之間交換的數(shù)據(jù)分組的分組流處理。
文檔編號H04W28/18GK102025618SQ20101056353
公開日2011年4月20日 申請日期2003年6月10日 優(yōu)先權(quán)日2002年6月10日
發(fā)明者R·T·蘇, 王俊 申請人:高通股份有限公司