【正文】 時計費流程。專用承載實時計費詳細(xì)流程參見圖524及流程說明。圖524 PCC引入后專用承載實時計費流程1) PCRF制定策略；2) PCRF依據(jù)用戶策略，響應(yīng)PGW策略請求或主動推送策略到PGW。通過計費Online=enable/disable標(biāo)識是在線計費還是離線計費；3) PGW向終端側(cè)發(fā)起專用承載創(chuàng)建請求；4) 用戶向PGW回專用承載創(chuàng)建響應(yīng)；5) PGW基于PCRF下發(fā)的策略消息中Online字段判斷承載是否為實時計費，如果PCRF未攜帶Online字段，說明PCRF不支持或未開啟“下發(fā)計費控制信息”功能，PGW可直接根據(jù)HLR/HSS中CC字段取值決定是否觸發(fā)實時計費流程；6) 如果該承載為實時計費類型，流程同標(biāo)準(zhǔn)實時計費流程； 7) PCRF依據(jù)用戶策略，響應(yīng)PGW策略請求或主動推送策略到PGW，釋放該專用承載；8) PGW向終端發(fā)起專用承載刪除請求；9) 用戶向PGW回專用承載刪除響應(yīng)；10) GGSN、PGW發(fā)送終止信用控制服務(wù)的消息（CCRT）到BOSS，CCRequestType AVP=TERMINATION_REQUEST，消息中應(yīng)該有標(biāo)識服務(wù)終止時間的EventTimestamp AVP，以及標(biāo)識該業(yè)務(wù)實際使用的單元UsedServiceUnit AVP，CCRTerminate消息中不再包含標(biāo)識請求配額的RequestServiceUnit AVP；注：PCRF通過RAR消息觸發(fā)PGW建立或刪除專用承載時，PGW在承載建立或刪除后，需要向PCRF回RAA響應(yīng)消息。. 其他流程心跳控制使用DiameterBase協(xié)議中的DeviceWatchdogRequest與DeviceWatchdogAnswer消息，能力協(xié)商使用DiameterBase協(xié)議中的CapabilitiesExchangeRequest與CapabilitiesExchangeAnswer消息。由于上述流程屬于GGSN、PGW與BOSS底層之間的交互，不再贅述，可參考相關(guān)規(guī)范。在上述各流程中，BOSS實現(xiàn)了配額分配和批價等功能，因此在CCR消息中RequestedServiceUnit（RSU）字段為空，但需要指出的是，GGSN、PGW必須具備對該字段的支持能力。為便于BOSS計費話單過濾和處理，BOSS僅對GGSN、PGW話單PSFCI中記錄的PSFreeFormatData取值16的GGSN、PGW話單過濾、不作離線計費，以避免重復(fù)計費；對其余GGSN、PGW話單全部做離線計費，包括PSFCI中PSFreeFormatData取值111或其他賦值以及不帶PSFCI字段場景，以避免漏計費。在GGSN、PGW和BOSS的DCC交互過程中，BOSS在每個RC=2001/2002的CCA消息中都需要返回PSFCI信息，其中PSFreeFormatData取值16表示在線計費、取值15表示實時流量提醒。以此確保在實時計費正常情況下，GGSN、PGW話單按照CCA消息映射PSFCI的 PSFreeFormatData取值16記錄在離線話單，傳送給BOSS作話單過濾、避免重復(fù)計費?；谌缟螧OSS計費話單處理簡化原則，BOSS在如下情況下可以不攜帶PSFCI字段，網(wǎng)絡(luò)側(cè)處理方式如下：1) 初始BOSS用戶鑒權(quán)的用戶業(yè)務(wù)未授權(quán)、禁止使用業(yè)務(wù)，CCAI消息Command Level返回RC=4010時，GGSN、PGW離線話單不攜帶PSFCI字段；2) HLR/HSS與BOSS用戶計費方式不一致，轉(zhuǎn)離線計費，CCAI消息Command Level返回RC=4011時，GGSN、PGW離線話單不攜帶PSFCI字段；3) BOSS無用戶數(shù)據(jù)，相應(yīng)業(yè)務(wù)正常使用，轉(zhuǎn)離線計費，CCAI消息Command Level返回RC=4011時，GGSN、PGW離線話單不攜帶PSFCI字段；4) CCAI消息Command Level返回RC=5003永久錯誤碼，去激活用戶的場景下，GGSN、PGW離線話單不攜帶PSFCI字段；CCAU消息Command Level返回RC=5003永久錯誤碼，去激活用戶的等場景下，GGSN、PGW離線話單攜帶的PSFCI取值保持不變；要求GGSN、PGW對該DCC會話中所產(chǎn)生的每條話單都記錄BOSS下發(fā)的PSFCI信息，當(dāng)BOSS未下發(fā)PSFCI信息時相應(yīng)GGSN、PGW話單不攜帶PSFCI字段。當(dāng)PSFCI取值改變時，GGSN、PGW需及時關(guān)閉當(dāng)前話單，話單關(guān)閉原因為managementIntervention（20），并將最新的PSFCI信息寫入新打開的部分話單中。當(dāng)BOSS通過結(jié)果碼指示GGSN、PGW將用戶轉(zhuǎn)離線時，例如BOSS下發(fā)CCAU消息Command Level的 Result Code=4011或其他結(jié)果碼時，BOSS需下發(fā)相應(yīng)PSFCI值（例如下發(fā)PSFCI=11），指示GGSN以及PGW切割話單、并將最新PSFCI值體現(xiàn)在后續(xù)離線話單中，保證該用戶后續(xù)離線話單能夠被正常計費。6. DCCA協(xié)議定義. 協(xié)議結(jié)構(gòu)遵循Diameter基礎(chǔ)協(xié)議，DCCA協(xié)議是在Diameter 基礎(chǔ)協(xié)議之上，根據(jù)數(shù)據(jù)業(yè)務(wù)在線計費的具體需求，設(shè)計的用于進(jìn)行信用控制的應(yīng)用層協(xié)議：Diameter Credit Control ApplicationDiameter Base ProtocolTLSTCPSCTPIP/IPsec圖61 DCCA協(xié)議的協(xié)議結(jié)構(gòu). 協(xié)議格式. 消息頭格式DCCA協(xié)議的消息結(jié)構(gòu)如圖62所示，這些字段是以網(wǎng)絡(luò)字節(jié)順序傳送的。0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +++++++++++++++++++++++++++++++++ | Version | Message Length | +++++++++++++++++++++++++++++++++ | mand flags | CommandCode | +++++++++++++++++++++++++++++++++ | ApplicationID | +++++++++++++++++++++++++++++++++ | HopbyHop Identifier | +++++++++++++++++++++++++++++++++ | EndtoEnd Identifier | +++++++++++++++++++++++++++++++++ | AVPs ... +++++++++++++圖62 消息頭格式關(guān)鍵字段說明如下：(1) Version：該版本字段必須被置為1，表明Diameter版本1。(2) Message Length：該消息長度字段為3個八位組，指明該Diameter消息的字節(jié)長度，包括頭字段。(3) Command flags：該命令標(biāo)記字段為8個比特。已經(jīng)分配的比特位如下：0 1 2 3 4 5 6 7+++++++++|R P E T r r r r|+++++++++252。 R(equest) 如果設(shè)置，表明該消息是一個請求。如果清零，該消息是一個應(yīng)答。252。 P(roxiable) –如果設(shè)置，表明該消息可以被Proxy、中繼或者重定向。如果清零，該消息必須在本地處理。252。 E(rror) 如果設(shè)置，表明該消息包含一個協(xié)議差錯，且該消息與ABNF中描述的該命令不一致。“E”比特設(shè)置的消息一般當(dāng)作差錯消息。在請求消息中不能設(shè)置該比特。252。 T(Potentially retransmitted message)該標(biāo)記在鏈路失敗過程后被設(shè)置，以幫助去除重復(fù)的請求。當(dāng)重發(fā)請求還沒有被確認(rèn)時，需要設(shè)置該比特，以作為鏈路失敗而造成的可能的重復(fù)包的指示。當(dāng)?shù)谝淮伟l(fā)送一個請求時，該比特必須被清零，否則發(fā)送者必須設(shè)置該比特。Diameter代理僅需要關(guān)心它們發(fā)送的同一請求消息的遍數(shù)；其他實體進(jìn)行的重傳不須考慮。Diameter代理接收到一個T比特設(shè)置為1的請求，必須在前轉(zhuǎn)該請求時保持T標(biāo)記的設(shè)置。如果接收到一個以前消息的差錯消息（例如協(xié)議差錯），則不可以設(shè)置該標(biāo)記。該標(biāo)記只有在沒有接收到任何來自服務(wù)器的該請求的應(yīng)答、且該請求再次被發(fā)送的情況下，才能被設(shè)置。該標(biāo)記不能在應(yīng)答消息中設(shè)置。252。 r(eserved) 這些標(biāo)記比特為將來使用預(yù)留，必須設(shè)置為0，接收者應(yīng)當(dāng)忽略。(4) CommandCode：該命令碼字段為3個八位組，用于表明與該消息相關(guān)聯(lián)的命令。該24位地址空間由IETF的IANA負(fù)責(zé)分配管理。命令碼值16，777，214和16，777，215（16進(jìn)制的FFFFFE－FFFFFF）被預(yù)留為實驗使用。(5) ApplicationID： 應(yīng)用ID為4個八位組，用于標(biāo)識該消息可適用于哪個應(yīng)用。該應(yīng)用可以是一個認(rèn)證應(yīng)用。頭中的應(yīng)用ID必須與該消息中包含的其他相關(guān)AVP相同。(6) HopbyHop Identifier：HopbyHop標(biāo)識符為一個無符號32比特整數(shù)字段（按網(wǎng)絡(luò)字節(jié)順序），用來幫助匹配請求和響應(yīng)。發(fā)送者必須保證請求中的HopbyHop標(biāo)識符在特定的連接上在任何特定的時間是唯一的，并且保證該數(shù)字在經(jīng)過重啟動后仍然唯一。應(yīng)答消息的發(fā)送者必須確保HopbyHop標(biāo)識符字段維持與相應(yīng)的請求相同的值。HopbyHop標(biāo)識符通常是單調(diào)升序的數(shù)字，其開始值是隨機(jī)生成的。一個帶有未知HopbyHop標(biāo)識符的應(yīng)答消息必須被丟棄。(7) EndtoEnd Identifier：端到端標(biāo)識符是一個無符號32比特整數(shù)字段（按網(wǎng)絡(luò)字節(jié)順序），用來檢測重復(fù)消息。重啟動實施可以設(shè)置高位12比特為包含當(dāng)前時間的低位12比特，低位20比特為隨機(jī)值。請求消息的發(fā)送者必須為每一個消息插入一個唯一的標(biāo)識符。該標(biāo)識符必須維持本地唯一至少4分鐘，即使經(jīng)過重啟動。應(yīng)答消息的生成者必須確保該端到端標(biāo)識符字段包含與相應(yīng)的請求相同的值。端到端標(biāo)識符不可以被Diameter代理以任何原因修改。源主機(jī)AVP和該字段的結(jié)合可以用于檢測重復(fù)。重復(fù)請求會造成相同應(yīng)答的傳輸，并且不可以影響任何狀態(tài)的設(shè)置，當(dāng)處理原始請求時。應(yīng)當(dāng)在本地被消除的重復(fù)的應(yīng)答消息將會被忽略。(8) AVPs：AVP是封裝與Diameter消息相關(guān)的信息的一種方法。. AVP頭格式AVP中的字段必須按網(wǎng)絡(luò)字節(jié)順序發(fā)送。頭的格式如圖63所示：0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+++++++++++++++++++++++++++++++++ | AVP Code | +++++++++++++++++++++++++++++++++ |V M P r r r r r| AVP Length | +++++++++++++++++++++++++++++++++ | VendorID (opt) | +++++++++++++++++++++++++++++++++ | Data ... +++++++++圖63 AVP頭格式關(guān)鍵字段說明如下：(1) AVP CodeAVP碼與制造商ID 結(jié)合，可以唯一標(biāo)識屬性。AVP 1到255為前向兼容RADIUS預(yù)留，無需設(shè)置制造商ID字段。256以及大于256的AVP用于Diameter，由IANA負(fù)責(zé)分配。(2) AVP 標(biāo)記AVP標(biāo)記字段告知接收者如何處理每個屬性?！皉”（預(yù)留）比特不使用，應(yīng)設(shè)置為0。表示以后的Diameter應(yīng)用可以在AVP頭中定義附加的比特，一個未被承認(rèn)的比特應(yīng)被看作差錯。“P”比特指