一種信令發(fā)起方法、裝置及網(wǎng)關(guān)設(shè)備的制作方法
【專利摘要】本發(fā)明實施例提供一種信令發(fā)起方法、裝置及網(wǎng)關(guān)設(shè)備。所述方法包括：確定一觸發(fā)信息；其中，所述觸發(fā)信息與至少一個第一承載和至少一個第二承載相關(guān)；根據(jù)所述觸發(fā)信息判斷是否發(fā)起包括對所述至少一個第一承載進行第一類型處理的第一請求和對所述至少一個第二承載進行第二類型處理的第二請求的至少兩個請求，獲取一第一判斷結(jié)果；當(dāng)所述第一判斷結(jié)果為是時，通過一個第一請求信令發(fā)起所述至少兩個請求。本發(fā)明實施例通過一個第一請求信令發(fā)起不同類型的承載處理請求，從而減輕了網(wǎng)關(guān)設(shè)備的信令處理負擔(dān)。
【專利說明】一種信令發(fā)起方法、裝置及網(wǎng)關(guān)設(shè)備
【技術(shù)領(lǐng)域】
[0001 ] 本發(fā)明實施例涉及通信領(lǐng)域，尤其涉及一種信令發(fā)起方法、裝置及網(wǎng)關(guān)設(shè)備。
【背景技術(shù)】
[0002]圖1為演進的分組核心網(wǎng)(Evolved Packet Core, EPC)核心網(wǎng)絡(luò)架構(gòu)圖，參照圖1，在整個移動網(wǎng)絡(luò)中，分組數(shù)據(jù)網(wǎng)(Packet Data Network, F1DN)網(wǎng)關(guān)(PDN Gateway, PGff)位于移動網(wǎng)絡(luò)的終點，PGff的主要功能如下:
[0003]用戶報文過濾轉(zhuǎn)發(fā):根據(jù)為用戶的安裝過濾器，通過不同的承載(Bearer)轉(zhuǎn)發(fā)報文；
[0004]合法監(jiān)聽；
[0005]為用戶分配IP地址:提供地址，用于訪問TON網(wǎng)絡(luò)資源；
[0006]用戶計費:根據(jù)用戶的時長、流量進行計費；
[0007]用戶業(yè)務(wù)等級控制:不同用戶的業(yè)務(wù)控制等級不同，此功能為不同的用戶提供不同的服務(wù)等級；
[0008]DHCP服務(wù)器/客戶端:PGW可以實現(xiàn)DHCP服務(wù)器、客戶端功能。
[0009]從3GPP網(wǎng)絡(luò)架構(gòu)的演進來看，EPC網(wǎng)絡(luò)中，把大部分的控制權(quán)都交到了 PGW網(wǎng)元中，比如說用戶、前向網(wǎng)元(如SGW、MME)無法發(fā)起專有承載的建立、修改、刪除，任何操作，都需要通過命令(Command)消息通知到PGW，由PGW發(fā)起專有承載的操作。
[0010]另外EPC網(wǎng)絡(luò)中特別強調(diào)PCRF的應(yīng)用，用戶的相關(guān)策略如計費方式、用戶等級都是通過PCRF進行下發(fā)控制，PCRF發(fā)起的變更都將觸發(fā)PGW發(fā)起專有承載的建立、修改或刪除操作。
[0011]圖2為PCRF觸發(fā)的專有承載修改流程，參照圖2，PCRF觸發(fā)的專有承載修改流程如下:
[0012]步驟1:PCRF發(fā)送“ IP連接接入網(wǎng)絡(luò)(IP-Connectivity Access Network, IP-CAN)會話修改(Session Modification)” 消息給 PGW ；
[0013]步驟2:PGW根據(jù)收到的IP-CAN Session Modif ication消息得到承載處理相關(guān)規(guī)貝U，根據(jù)該承載處理相關(guān)規(guī)則確定需要對某一或某些承載進行QoS參數(shù)更新，向服務(wù)網(wǎng)關(guān)(Serving Gateway, SGff)發(fā)送更新承載請求(Update BearerRequest)消息,通知更新該一或該些承載的QoS參數(shù)；
[0014]步驟3:SGff收到消息后轉(zhuǎn)發(fā)消息到MME ；
[0015]步驟4-步驟10:這幾個步驟中，主要是MME通知eNodeB進行QoS參數(shù)更新，eNodeB檢查自己的資源是否能夠滿足要求,如果能夠滿足，則應(yīng)答成功；如果eNodeB發(fā)現(xiàn)自己的資源不足，那么eNodeB將拒絕此次更新(詳細的請參看3GPP規(guī)范23.401)；
[0016]步驟11:SGW轉(zhuǎn)發(fā)MME發(fā)過來的更新承載應(yīng)答(Update Bearer Response)消息給PGff ；
[0017]步驟12:PGW收到Update Bearer Response消息后,檢查執(zhí)行結(jié)果，并根據(jù)執(zhí)行結(jié)果決定本地應(yīng)用何種策略，例如應(yīng)用最新的QoS參數(shù)。處理完成后PGW向PCRF發(fā)送應(yīng)答消息,通知執(zhí)行結(jié)果。
[0018]上面是標準的PCRF觸發(fā)的承載修改，對于PCRF觸發(fā)的承載創(chuàng)建、刪除流程與修改流程類似，可參考圖3、圖4，詳細的描述可參考3GPP規(guī)范23.401，在此不再贅述。
[0019]圖5為UE觸發(fā)承載資源請求命令，參照圖5，用戶觸發(fā)的專有承載創(chuàng)建、修改、刪除流程如下:
[0020]步驟1:UE發(fā)起專有承載參數(shù)的更新，如QoS、業(yè)務(wù)流模板(TrafficFlowTemplate, TFT)參數(shù)變更，發(fā)送請求承載資源修改(Request BearerResourceModif ication)消息給 MME ；
[0021]步驟2-3:MME、SGW 將來自 UE 的 Request Bearer Resource Modif ication 消息中的參數(shù)變更信息通過承載資源命令(Bearer Resource Command)消息轉(zhuǎn)發(fā)到PGW ;
[0022]步驟4:PGW根據(jù)接收到的Bearer Resource Command消息中攜帶的參數(shù),決定發(fā)起創(chuàng)建、修改或者刪除承載流程。對于PGW來說，具體的操作與PCRF觸發(fā)承載操作相同。
[0023]在某些情況下，PGW根據(jù)來自PCRF的IP-CAN Session Modification消息或來自UE的參數(shù)變更信息，可能確定發(fā)起大于一種類型的承載處理請求，以如下PGW應(yīng)用場景為例:
[0024]某個用戶在PCRF上簽約的總帶寬為6兆比特每秒(megabit per second, Mbps),可以建立3個專有承載，其中:
[0025]Bearerl 用于 IP 多媒體子系統(tǒng)(IP Multimedia Subsystem, IMS)語音，預(yù)留帶寬2Mbps ；
[0026]Bearer2用于正常上網(wǎng)業(yè)務(wù),預(yù)留帶寬2Mbps ；
[0027]Bearer3用于流媒體業(yè)務(wù),預(yù)留帶寬4Mbps。
[0028]用戶上線后正常上網(wǎng)，做流媒體業(yè)務(wù)，此時建立了 Bearer2和Bearer3 ;用戶突然需要做MS語音業(yè)務(wù)，PGW檢測到業(yè)務(wù)后通知到PCRF，PCRF此時需要觸發(fā)Bearerl的創(chuàng)建，但是發(fā)現(xiàn)當(dāng)前Bearer2和Bearer3已經(jīng)占了 6Mbps帶寬，如果要發(fā)起B(yǎng)earerl的創(chuàng)建,必須要刪除已經(jīng)建立的承載，或者減小某個承載的帶寬。
[0029]PCRF決策需要刪除Bearer2，然后創(chuàng)建Bearerl，PCRF可能會將兩個承載的處理相關(guān)規(guī)則通過一條消息下發(fā)給PGW。PGW檢查到需要刪除和創(chuàng)建，由于創(chuàng)建承載請求(CreateBearer Request)消息只能攜帶要創(chuàng)建的承載,刪除承載請求(Delete Bearer Request消息)只能攜帶要刪除的承載，PGW需要先發(fā)起B(yǎng)earer2的刪除,接著再發(fā)起B(yǎng)earerl的創(chuàng)建。整個流程中PGW需要與前向網(wǎng)元交互2次才能完成，這就給PGW造成信令處理上的負擔(dān)。

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

[0030]有鑒于此，本發(fā)明實施例的目的是提供一種信令發(fā)起方法、裝置及網(wǎng)關(guān)設(shè)備，以減輕網(wǎng)關(guān)設(shè)備的信令處理負擔(dān)。
[0031]為解決上述技術(shù)問題，本發(fā)明實施例提供方案如下:
[0032]本發(fā)明實施例提供一種信令發(fā)起方法，用于一網(wǎng)關(guān)設(shè)備，所述方法包括:
[0033]確定一觸發(fā)信息；其中，所述觸發(fā)信息與至少一個第一承載和至少一個第二承載相關(guān);[0034]根據(jù)所述觸發(fā)信息判斷是否發(fā)起包括對所述至少一個第一承載進行第一類型處理的第一請求和對所述至少一個第二承載進行第二類型處理的第二請求的至少兩個請求，獲取一第一判斷結(jié)果；
[0035]當(dāng)所述第一判斷結(jié)果為是時，通過一個第一請求信令發(fā)起所述至少兩個請求。
[0036]優(yōu)選的，所述確定一觸發(fā)信息包括:
[0037]接收來自PCRF或UE的所述觸發(fā)信息。
[0038]優(yōu)選的，
[0039]所述第一類型為創(chuàng)建、修改和刪除中的一種，所述第二類型為創(chuàng)建、修改和刪除中不同于所述第一類型的一種。
[0040]優(yōu)選的，所述至少兩個請求還包括對至少一個第三承載進行第三類型處理的第三請求。
[0041]優(yōu)選的，所述第一類型為創(chuàng)建，所述第二類型為修改，所述第三類型為刪除。
[0042]優(yōu)選的，所述第一請求信令為對支持發(fā)起所述第一請求的第二請求信令進行擴展后的擴展信令。
[0043]優(yōu)選的，所述方法還包括:
[0044]接收一個針對所述第一請求信令的應(yīng)答信令；其中，所述應(yīng)答信令包括針對所述
第一請求的第一應(yīng)答信息；
[0045]判斷所述應(yīng)答信令是否包括針對所述第二請求的第二應(yīng)答信息，獲取一第二判斷結(jié)果;
[0046]當(dāng)所述第二判斷結(jié)果為是時，根據(jù)所述第一類型處理所述第一應(yīng)答信息，且根據(jù)所述第二類型處理所述第二應(yīng)答信息；
[0047]當(dāng)所述第二判斷結(jié)果為否時，根據(jù)所述第一類型處理所述第一應(yīng)答信息。
[0048]本發(fā)明實施例還提供一種信令發(fā)起裝置，用于一網(wǎng)關(guān)設(shè)備，所述裝置包括:
[0049]確定模塊，用于確定一觸發(fā)信息；其中，所述觸發(fā)信息與至少一個第一承載和至少一個第二承載相關(guān)；
[0050]判斷模塊，用于根據(jù)所述觸發(fā)信息判斷是否發(fā)起包括對所述至少一個第一承載進行第一類型處理的第一請求和對所述至少一個第二承載進行第二類型處理的第二請求的至少兩個請求，獲取一第一判斷結(jié)果；
[0051]發(fā)起模塊，用于當(dāng)所述第一判斷結(jié)果為是時，通過一個第一請求信令發(fā)起所述至少兩個請求。
[0052]優(yōu)選的，所述確定模塊包括:
[0053]第一接收模塊，用于接收來自PCRF或UE的所述觸發(fā)信息。
[0054]優(yōu)選的，
[0055]所述第一類型為創(chuàng)建、修改和刪除中的一種，所述第二類型為創(chuàng)建、修改和刪除中不同于所述第一類型的一種。
[0056]優(yōu)選的，所述第一請求信令為對支持發(fā)起所述第一請求的第二請求信令進行擴展后的擴展信令。
[0057]優(yōu)選的，所述裝置還包括:
[0058]第二接收模塊，用于接收一個針對所述第一請求信令的應(yīng)答信令；其中，所述應(yīng)答信令包括針對所述第一請求的第一應(yīng)答信息；
[0059]判斷單元，用于判斷所述應(yīng)答信令是否包括針對所述第二請求的第二應(yīng)答信息，獲取一第二判斷結(jié)果；
[0060]第一處理單元，用于當(dāng)所述第二判斷結(jié)果為是時，根據(jù)所述第一類型處理所述第一應(yīng)答信息，且根據(jù)所述第二類型處理所述第二應(yīng)答信息；
[0061]第二處理單元，用于當(dāng)所述第二判斷結(jié)果為否時，根據(jù)所述第一類型處理所述第
一應(yīng)答信息。
[0062]本發(fā)明實施例還提供一種包括以上所述的信令發(fā)起裝置的網(wǎng)關(guān)設(shè)備。
[0063]從以上所述可以看出，本發(fā)明實施例至少具有如下有益效果:
[0064]通過一個第一請求信令發(fā)起不同類型的承載處理請求，從而網(wǎng)關(guān)設(shè)備只需要與前向網(wǎng)元交互一次，從而減輕了網(wǎng)關(guān)設(shè)備的信令處理負擔(dān)。
【專利附圖】

【附圖說明】
[0065]圖1為現(xiàn)有技術(shù)的EPC網(wǎng)絡(luò)架構(gòu)圖；
[0066]圖2為現(xiàn)有技術(shù)的PCRF觸發(fā)的專有承載修改流程的示意圖；
[0067]圖3為現(xiàn)有技術(shù)的PCRF觸發(fā)的專有承載創(chuàng)建流程的示意圖；
[0068]圖4為現(xiàn)有技術(shù)的PCRF觸發(fā)的專有承載刪除流程的示意圖；
[0069]圖5為現(xiàn)有技術(shù)的UE觸發(fā)承載資源請求命令；
[0070]圖6為本發(fā)明實施例提供的一種信令發(fā)起方法的流程示意圖；
[0071]圖7為本發(fā)明較佳實施例一的PCRF通過一條消息觸發(fā)的專有承載修改及刪除流程的示意圖；
[0072]圖8為本發(fā)明較佳實施例二的PCRF通過一條消息觸發(fā)的專有承載創(chuàng)建及刪除流程的示意圖。
[0073][縮略語及中英文對照]
[0074]MME Mobility Management Entity,移動性管理實體
[0075]UTRAN Universal Terrestrial Radio Access Network,通用陸地?zé)o線接入網(wǎng)絡(luò)
[0076]E-UTRAN Evolved Universal Terrestrial Radio Access Network,演進通用陸地?zé)o線接入網(wǎng)絡(luò)
[0077]GERAN GSM EDGE Radio Access Network，GSM、EDGE 無線接入網(wǎng)絡(luò)
[0078]UE User Equipment,用戶設(shè)備
[0079]SGSN Serving GPRS Support Node, GPRS 服務(wù)支持節(jié)點
[0080]HSS Home Subscriber Server,歸屬用戶服務(wù)器
[0081]PCRF Policy and charging rule function,策略與計費規(guī)則功能
[0082]Operator’ s IP Services:運營商網(wǎng)絡(luò)服務(wù)
[0083]IMS IP Multimedia Subsystem, IP 多媒體子系統(tǒng)
【具體實施方式】
[0084]為使本發(fā)明實施例的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖及具體實施例對本發(fā)明實施例進行詳細描述。[0085]圖6為本發(fā)明實施例提供的一種信令發(fā)起方法的流程示意圖，參照圖6，該信令發(fā)起方法包括如下步驟:
[0086]步驟601，確定一觸發(fā)信息；其中，所述觸發(fā)信息與至少一個第一承載和至少一個
第二承載相關(guān)；
[0087]步驟602，根據(jù)所述觸發(fā)信息判斷是否發(fā)起包括對所述至少一個第一承載進行第一類型處理的第一請求和對所述至少一個第二承載進行第二類型處理的第二請求的至少兩個請求，獲取一第一判斷結(jié)果；
[0088]步驟603，當(dāng)所述第一判斷結(jié)果為是時，通過一個第一請求信令發(fā)起所述至少兩個請求。
[0089]該信令發(fā)起方法可以用于一網(wǎng)關(guān)設(shè)備。
[0090]可見，通過一個第一請求信令發(fā)起不同類型的承載處理請求，從而網(wǎng)關(guān)設(shè)備只需要與前向網(wǎng)元交互一次，從而減輕了網(wǎng)關(guān)設(shè)備的信令處理負擔(dān)。
[0091]在本發(fā)明實施例中，所述網(wǎng)關(guān)設(shè)備可以為PGW。
[0092]PGff作為移動網(wǎng)絡(luò)的終點，需要處理整個移動網(wǎng)絡(luò)中的用戶的信令報文，并提供用戶的數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)。從實際應(yīng)用角度看，一個PGW的容量往往會達到十幾萬到上百萬的用戶量，每個用戶產(chǎn)生一條信令，對于PGW來說就是幾十萬到上百萬條，而如果每個用戶產(chǎn)生更多條信令，PGW需要處理的信令條數(shù)就會更多。而PGW的處理能力有限，高峰時可能無法應(yīng)付如此大的數(shù)據(jù)量。因此，減輕PGW的信令處理負擔(dān)是非常重要的。
[0093]在本發(fā)明實施例中，承載的類型可以為EPC中的專有承載或默認承載。
[0094]所述觸發(fā)信息可以由PGW根據(jù)本地配置或者來自在線計費系統(tǒng)(OnlineChargingSystem, 0CS)的業(yè)務(wù)相關(guān)信息生成；或者，也可以來自PCRF或UE，則有:
[0095]所述確定一觸發(fā)信息包括:
[0096]接收來自PCRF或UE的所述觸發(fā)信息。
[0097]具體地，對于所述觸發(fā)信息來自PCRF的情況，所述觸發(fā)信息可以為PCRF發(fā)送的IP-CAN Session Modification消息,其中攜帶了與所述至少一個第一承載和所述至少一個第二承載相關(guān)的規(guī)則；對于所述觸發(fā)信息來自UE的情況，所述觸發(fā)信息可以為RequestBearer Resource Modification消息中與所述至少一個第一承載和所述至少一個第二承載相關(guān)的的參數(shù)變更信息等觸發(fā)內(nèi)容，由MME通過Bearer Resource Command消息經(jīng)由SGW轉(zhuǎn)發(fā)給PGW。
[0098]此外,所述觸發(fā)信息也可以來自大于一個設(shè)備,例如:
[0099]所述觸發(fā)信息可以包括與至少一個第一承載相關(guān)的第一觸發(fā)信息和與至少一個第二承載相關(guān)的第二觸發(fā)信息。所述第一觸發(fā)信息和所述第二觸發(fā)信息可以分別來自UE和PCRF，或者分別來自PCRF和UE。
[0100]這里的類型是指針對承載的處理類型。對于至少一個第一承載包括的承載數(shù)目大于I的情況，至少一個第一承載中的不同承載對應(yīng)的處理類型相同，但并不限制對不同承載的具體處理是否相同。例如，對于至少一個第一承載對應(yīng)的處理類型為創(chuàng)建的情況，至少一個第一承載中不同承載對應(yīng)的QoS參數(shù)可以相同也可以不同。對于至少一個第一承載對應(yīng)的處理類型為修改的情況，至少一個第一承載中不同承載對應(yīng)的更新后的Q0S參數(shù)可以相同也可以不同。同樣地，對于至少一個第二承載包括的承載數(shù)目大于I的情況，至少一個第二承載中的不同承載對應(yīng)的處理類型相同，但并不限制對不同承載的具體處理是否相同。
[0101]前面提到，所述觸發(fā)信息可以包括與至少一個第一承載相關(guān)的第一觸發(fā)信息和與至少一個第二承載相關(guān)的第二觸發(fā)信息。則在至少一個第一承載包括的承載數(shù)目大于I的情況下，所述第一觸發(fā)信息中對應(yīng)至少一個第一承載中一部分承載的觸發(fā)信息和剩余部分承載的觸發(fā)信息可以分別來自UE和PCRF，或者分別來自PCRF和UE。在至少一個第二承載包括的承載數(shù)目大于I的情況下，所述第二觸發(fā)信息中對應(yīng)至少一個第二承載中一部分承載的觸發(fā)信息和剩余部分承載的觸發(fā)信息可以分別來自UE和PCRF，或者分別來自PCRF和UE0
[0102]在本發(fā)明實施例中，所述第一類型可以為創(chuàng)建、修改和刪除中的一種，所述第二類型可以為創(chuàng)建、修改和刪除中不同于所述第一類型的一種。
[0103]在本發(fā)明實施例中，進一步地，所述至少兩個請求還可以包括對至少一個第三承載進行第三類型處理的第三請求。
[0104]其中，所述第一類型可以為創(chuàng)建，所述第二類型可以為修改，所述第三類型可以為刪除。
[0105]在本發(fā)明實施例中，所述第一請求信令可以為對支持發(fā)起所述第一請求的第二請求信令進行擴展后的擴展信令，例如，擴展的Create Bearer Request消息,擴展的UpdateBearer Request 消息或擴展的 Delete Bearer Request 消息。具體地，
[0106]考慮到所述至少兩個請求包括第一請求和第二請求的情況，當(dāng)所述第一類型為創(chuàng)建、所述第二類型為修改時，該擴展的Create Bearer Request消息可以為在現(xiàn)有技術(shù)的Create Bearer Request消息的基礎(chǔ)上添加被修改的承載上下文信息元素(InformationElement, IE)后得到，其中，發(fā)起第一請求所需信息和發(fā)起第二請求所需信息可以分別包括在現(xiàn)有技術(shù)的Create Bearer Request消息本身就包括的承載上下文IE中和該被修改的承載上下文IE中，該被修改的承載上下文IE可以添加到現(xiàn)有技術(shù)的Create BearerRequest消息中的任意位置，例如，任意兩個相鄰IE之間，第一個IE之前，或者最后一個IE之后。
[0107]當(dāng)所述第一類型為創(chuàng)建、所述第二類型為刪除時，該擴展的CreateBearerRequest消息可以為在現(xiàn)有技術(shù)的Create Bearer Request消息的基礎(chǔ)上添加了被刪除的承載上下文IE后得到，其中，發(fā)起第一請求所需信息和發(fā)起第二請求所需信息可以分別包括在現(xiàn)有技術(shù)的Create Bearer Request消息本身就包括的承載上下文IE中和該被刪除的承載上下文IE中，該被刪除的承載上下文IE可以添加到現(xiàn)有技術(shù)的CreateBearer Request消息中的任意位置。
[0108]當(dāng)所述第一類型為修改、所述第二類型為刪除時，該擴展的UpdateBearerRequest消息可以為在現(xiàn)有技術(shù)的Update Bearer Request消息的基礎(chǔ)上添加了被刪除的承載上下文IE后得到，其中，發(fā)起第一請求所需信息和發(fā)起第二請求所需信息可以分別包括在現(xiàn)有技術(shù)的Update Bearer Request消息本身就包括的承載上下文IE中和該被刪除的承載上下文IE中，該被刪除的承載上下文IE可以添加到現(xiàn)有技術(shù)的UpdateBearer Request消息中的任意位置。
[0109]而，考慮到所述至少兩個請求還包括第三請求的情況，該擴展的CreateBearerRequest消息也可以為在現(xiàn)有技術(shù)的Create Bearer Request消息的基礎(chǔ)上增加了被修改的承載上下文IE和被刪除的承載上下文IE后得到，其中，發(fā)起第一請求所需信息、發(fā)起第二請求所需信息和發(fā)起第三請求所需信息可以分別包括在現(xiàn)有技術(shù)的Create BearerRequest消息本身就包括的承載上下文IE中、該被修改的承載上下文IE中和該被刪除的承載上下文IE中，該被修改的承載上下文IE和該被刪除的承載上下文IE可以添加到現(xiàn)有技術(shù)的Create BearerRequest消息中的任意位置,且這兩個IE出現(xiàn)該擴展的Create BearerRequest消息中的前后順序沒有要求。
[0110]需要說明的是，這里只是列舉了擴展消息的幾個典型例子，其基本原理在于，使用現(xiàn)有技術(shù)的消息中的現(xiàn)有IE來承載與該消息對應(yīng)的承載處理類型一致的類型的處理請求，而不一致的類型的處理請求則通過在該消息的基礎(chǔ)上添加的新的IE來承載。由此，本領(lǐng)域技術(shù)人員可以直接得到在現(xiàn)有技術(shù)的CreateBearer Request消息、Update BearerRequest消息和Delete Bearer Request消息的基礎(chǔ)上進行消息擴展的其它方式以支持通過一個第一請求信令發(fā)起所述至少兩個請求。這些其它方式也在本發(fā)明實施例的記載范圍之內(nèi)，在此不再贅述。
[0111]進一步地，考慮到在工程實現(xiàn)中，被發(fā)起所述處理請求的網(wǎng)絡(luò)設(shè)備可能不支持所述第一請求信令，有鑒于此，所述方法還可以包括:
[0112]接收一個針對所述第一請求信令的應(yīng)答信令；其中，所述應(yīng)答信令包括針對所述
第一請求的第一應(yīng)答信息；
[0113]判斷所述應(yīng)答信令是否包括針對所述第二請求的第二應(yīng)答信息，獲取一第二判斷結(jié)果;
[0114]當(dāng)所述第二判斷結(jié)果為是時，根據(jù)所述第一類型處理所述第一應(yīng)答信息，且根據(jù)所述第二類型處理所述第二應(yīng)答信息；
[0115]當(dāng)所述第二判斷結(jié)果為否時，根據(jù)所述第一類型處理所述第一應(yīng)答信息。
[0116]具體地，所述應(yīng)答信令可以為支持所述第一類型的現(xiàn)有信令，例如，現(xiàn)有技術(shù)的創(chuàng)建承載應(yīng)答(Create Bearer Response)消息，現(xiàn)有技術(shù)的 Update BearerResponse 消息或現(xiàn)有技術(shù)的刪除承載應(yīng)答(Delete Bearer Response)消息；或者，也可以為在該現(xiàn)有信令的基礎(chǔ)上進行擴展后的擴展信令，例如，擴展的Create Bearer Response消息,擴展的Update Bearer Response消息或擴展的Delete Bearer Response消息。則對于所述應(yīng)答信令為該擴展信令的情況，所述第二判斷結(jié)果為是；對于所述應(yīng)答信令為該現(xiàn)有信令的情況，所述第二判斷結(jié)果為否。
[0117]更具體地，與前面對所述第一請求信令的描述對應(yīng)，下面舉出幾個擴展的CreateBearer Response 消息和擴展的 Update Bearer Response 消息的例子:
[0118]當(dāng)所述第一類型為創(chuàng)建、所述第二類型為修改時，擴展的Create BearerResponse消息可以為在現(xiàn)有技術(shù)的Create Bearer Response消息的基礎(chǔ)上添加被修改的承載上下文IE后得到，其中，所述第一應(yīng)答信息和所述第二應(yīng)答信息可以分別包括在現(xiàn)有技術(shù)的Create Bearer Response消息本身就包括的承載上下文IE中和該被修改的承載上下文IE中，該被修改的承載上下文IE可以添加到現(xiàn)有技術(shù)的Create Bearer Response消息中的任意位置，例如，任意兩個相鄰IE之間，第一個IE之前，或者最后一個IE之后。
[0119]當(dāng)所述第一類型為創(chuàng)建、所述第二類型為刪除時，擴展的Create BearerResponse消息可以為在現(xiàn)有技術(shù)的Create Bearer Response消息的基礎(chǔ)上添加了標記為刪除的承載上下文IE后得到，其中，所述第一應(yīng)答信息和所述第二應(yīng)答信息可以分別包括在現(xiàn)有技術(shù)的Create Bearer Response消息本身就包括的承載上下文IE中和該標記為刪除的承載上下文IE中，該標記為刪除的承載上下文IE可以添加到現(xiàn)有技術(shù)的Create BearerResponse消息中的任意位置。
[0120]當(dāng)所述第一類型為修改、所述第二類型為刪除時，擴展的Update BearerResponse消息可以為在現(xiàn)有技術(shù)的Update Bearer Response消息的基礎(chǔ)上添加了標記為刪除的承載上下文IE后得到，其中，所述第一應(yīng)答信息和所述第二應(yīng)答信息可以分別包括在現(xiàn)有技術(shù)的Update Bearer Response消息本身就包括的承載上下文IE中和該標記為刪除的承載上下文IE中，該標記為刪除的承載上下文IE可以添加到現(xiàn)有技術(shù)的Update BearerResponse消息中的任意位置。
[0121]對于所述至少兩個請求還包括第三請求的情況，當(dāng)所述第一類型為創(chuàng)建、所述第二類型為修改、所述第三類型為刪除時，擴展的Create Bearer Response消息也可以為在現(xiàn)有技術(shù)的Create Bearer Response消息的基礎(chǔ)上增加了被修改的承載上下文IE和標記為刪除的承載上下文IE后得到，該被修改的承載上下文IE和該標記為刪除的承載上下文IE可以添加到現(xiàn)有技術(shù)的Create BearerResponse消息中的任意位置,且這兩個IE出現(xiàn)該擴展的Create Bearer Response消息中的前后順序沒有要求。
[0122]同樣需要說明的是，這里只是列舉了擴展消息的幾個典型例子，其基本原理在于，使用現(xiàn)有技術(shù)的消息中的現(xiàn)有IE來承載針對與該消息對應(yīng)的承載處理類型一致的類型的處理請求的應(yīng)答信息，而針對不一致的類型的處理請求的應(yīng)答信息則通過在該消息的基礎(chǔ)上添加的新的IE來承載。由此,本領(lǐng)域技術(shù)人員可以直接得到在現(xiàn)有技術(shù)的Create BearerResponse 消息、Update BearerResponse 消息和 Delete Bearer Response 消息的基礎(chǔ)上進行消息擴展的其它方式以支持通過一個應(yīng)答信令來應(yīng)答所述第一請求信令。這些其它方式也在本發(fā)明實施例的記載范圍之內(nèi)，在此不再贅述。
[0123]在本發(fā)明實施例中，對于所述至少兩個請求還包括第三請求的情況，當(dāng)所述第一類型為創(chuàng)建、所述第二類型為修改、所述第三類型為刪除時，上述“判斷所述應(yīng)答信令是否包括針對所述第二請求的第二應(yīng)答信息”可以替換為“判斷所述應(yīng)答信令是否包括針對所述第二請求的第二應(yīng)答信息和針對所述第三請求的第三應(yīng)答信息”，則所述第一應(yīng)答信息、所述第二應(yīng)答信息和所述第三應(yīng)答信息可以分別包括在現(xiàn)有技術(shù)的Create BearerResponse消息本身就包括的承載上下文IE中、該被修改的承載上下文IE中和該標記為刪除的承載上下文IE中。
[0124]為了對擴展的消息表述得更加清楚明白，下面給出幾個擴展消息的例子。
[0125]表1.1給出了擴展的Update Bearer Request消息在現(xiàn)有技術(shù)的UpdateBearerRequest消息的基礎(chǔ)上添加被修改的承載上下文IE的格式和內(nèi)容。表1.2給出了該被修改的承載上下文IE的格式和內(nèi)容。
[0126]表1.1:更新承載請求消息內(nèi)容變更
[0127]更新承載請求消息增加如下可選信息元素，可以出現(xiàn)在任何位置:
[0128]
【權(quán)利要求】
1.一種信令發(fā)起方法，用于一網(wǎng)關(guān)設(shè)備，其特征在于，所述方法包括: 確定一觸發(fā)信息；其中，所述觸發(fā)信息與至少一個第一承載和至少一個第二承載相關(guān); 根據(jù)所述觸發(fā)信息判斷是否發(fā)起包括對所述至少一個第一承載進行第一類型處理的第一請求和對所述至少一個第二承載進行第二類型處理的第二請求的至少兩個請求，獲取一第一判斷結(jié)果； 當(dāng)所述第一判斷結(jié)果為是時，通過一個第一請求信令發(fā)起所述至少兩個請求。
2.如權(quán)利要求1所述的方法，其特征在于，所述確定一觸發(fā)信息包括: 接收來自策略與計費規(guī)則功能PCRF或用戶設(shè)備UE的所述觸發(fā)信息。
3.如權(quán)利要求1所述的方法，其特征在于， 所述第一類型為創(chuàng)建、修改和刪除中的一種，所述第二類型為創(chuàng)建、修改和刪除中不同于所述第一類型的一種。
4.如權(quán)利要求1所述的方法，其特征在于，所述至少兩個請求還包括對至少一個第三承載進行第三類型處理的第三請求。
5.如權(quán)利要求4所述的方法，其特征在于，所述第一類型為創(chuàng)建，所述第二類型為修改，所述第三類型為刪除。
6.如權(quán)利要求1所述的方法，其特征在于，所述第一請求信令為對支持發(fā)起所述第一請求的第二請求信令進行擴展后的擴展信令。
7.如權(quán)利要求6所述的方法，`其特征在于，所述方法還包括: 接收一個針對所述第一請求信令的應(yīng)答信令；其中，所述應(yīng)答信令包括針對所述第一請求的第一應(yīng)答信息； 判斷所述應(yīng)答信令是否包括針對所述第二請求的第二應(yīng)答信息，獲取一第二判斷結(jié)果; 當(dāng)所述第二判斷結(jié)果為是時，根據(jù)所述第一類型處理所述第一應(yīng)答信息，且根據(jù)所述第二類型處理所述第二應(yīng)答信息； 當(dāng)所述第二判斷結(jié)果為否時，根據(jù)所述第一類型處理所述第一應(yīng)答信息。
8.一種信令發(fā)起裝置，用于一網(wǎng)關(guān)設(shè)備，其特征在于，所述裝置包括: 確定模塊，用于確定一觸發(fā)信息；其中，所述觸發(fā)信息與至少一個第一承載和至少一個第二承載相關(guān)； 判斷模塊，用于根據(jù)所述觸發(fā)信息判斷是否發(fā)起包括對所述至少一個第一承載進行第一類型處理的第一請求和對所述至少一個第二承載進行第二類型處理的第二請求的至少兩個請求，獲取一第一判斷結(jié)果； 發(fā)起模塊，用于當(dāng)所述第一判斷結(jié)果為是時，通過一個第一請求信令發(fā)起所述至少兩個請求。
9.如權(quán)利要求8所述的裝置，其特征在于，所述確定模塊包括: 第一接收模塊，用于接收來自策略與計費規(guī)則功能PCRF或用戶設(shè)備UE的所述觸發(fā)信肩、O
10.如權(quán)利要求8所述的裝置，其特征在于， 所述第一類型為創(chuàng)建、修改和刪除中的一種，所述第二類型為創(chuàng)建、修改和刪除中不同于所述第一類型的一種。
11.如權(quán)利要求8所述的裝置，其特征在于，所述第一請求信令為對支持發(fā)起所述第一請求的第二請求信令進行擴展后的擴展信令。
12.如權(quán)利要求11所述的裝置，其特征在于，所述裝置還包括: 第二接收模塊，用于接收一個針對所述第一請求信令的應(yīng)答信令；其中，所述應(yīng)答信令包括針對所述第一請求的第一應(yīng)答信息； 判斷單元，用于判斷所述應(yīng)答信令是否包括針對所述第二請求的第二應(yīng)答信息，獲取一第二判斷結(jié)果； 第一處理單元，用于當(dāng)所述第二判斷結(jié)果為是時，根據(jù)所述第一類型處理所述第一應(yīng)答信息，且根據(jù)所述第二類型處理所述第二應(yīng)答信息； 第二處理單元，用于當(dāng)所述第二判斷結(jié)果為否時，根據(jù)所述第一類型處理所述第一應(yīng)答信息。
13.—種網(wǎng)關(guān)設(shè)備，其特征在于`，包括權(quán)利要求8至12中任一項所述的信令發(fā)起裝置。
【文檔編號】H04W88/16GK103874240SQ201210531553
【公開日】2014年6月18日 申請日期:2012年12月11日 優(yōu)先權(quán)日:2012年12月11日
【發(fā)明者】韓相國 申請人:中興通訊股份有限公司