網絡智能化過程中端局配合NGN數據設置實例

摘要：雖然網絡智能化有不可否認的種種優點，但在嫩江網絡智能化割接過程中，也遇到了不少問題，通過端局數據設置的全力配合，終于在規定時間內實現全網智能化。關鍵詞：網絡智能化；中端局配合NGN數據設置；交換機

中圖分類號：G202

文獻標識碼：A

DOI：10.3969/1.issn.1672-0407.2011.10.006

文章編號：1672-0407(2011)10-014-03

收稿日期：2011-09-16

在現實應用中，網絡智能化的優勢相當的明顯：

通過統一的業務提供層(ENIP)以用戶為中心快速提供業務；

通過SHLR構建多網集中的用戶數據管理，提供統一用戶管理和認證；

通過協議修改和適配，接入層支持對SHLR的訪問，對于端局不支持情況，通過匯接局適配，屏蔽端局特性差異，解放網絡能力；

通過業務、網絡、終端及全流程的支撐系統的配合，形成端到端的快速業務響應流程；

全網集約控制，方便進行全網話務統計、控制和分析，大大提高了網絡的運行質量；

網絡結構簡單、路由簡化使維護工作方便快捷，大大縮短了修改網絡數據及排除障礙的時間；

端局模塊化，端局的路由及數據簡單，降低端局維護難度，節省維護人力。

雖然網絡智能化有以上的不可否認的種種優點，但在嫩江網絡智能化割接過程中，也遇到了不少問題，通過端局數據設置的全力配合，終于在規定時間內實現全網智能化。

下面談談08交換機割接至NGN網絡所遇到的問題和解決辦法。

案例l：CC08交換機和NGN的SOFTX3000 同屬華為的產品，在割接前，認為割接應是沒有問題，事實并非如此。由于嫩江08交換機所帶的用戶有集團和酒店用戶，所以為了實現集團虛擬網內的部分用戶顯話務臺號碼，分別設置了呼叫源，做主叫號碼分析，進行號碼變換，幾乎每個集團都有一個呼叫源。由于本局話務要強制出局，就要對每個呼叫源呼叫本局字冠進行號首處理，200個呼叫源對應5個本局字冠就是1000條數據，每增加一個呼叫源，需做5條號首處理數據，每增加一個本局字冠，需做200條號首處理數據。其他類型交換機并不需要做如此多數據是因為只有一個源。省內其他本地網的割接方案是以到每個呼叫源對應本局字冠，做號首處理的，原因是呼叫源不多。在一次測試過程中，對呼叫源采用了65534通配符，問題一下就解決了。

1，將所有本局用戶的呼叫源針對本局字冠進行號首特殊處理。

ADD PFXPRO：PFX=K'8707，CSC=65534，DDC=TRUE，DDCX=0，NPS=10，RAF=TRUE；

這樣處理對以后數據設置帶來方便，每增加呼叫源，不用做號首處理數據，每增加一個本局字冠，只用做一條號首處理數據就夠了，數據設置大為簡潔，以利今后的維護。

案例2：這樣的數據設置帶來一個故障，酒店用戶經話務臺轉分機無應答重入故障。經信令跟蹤分析，原因如下：

從NGN過來的TGl234，呼叫源為50，號首集為50。

2，新增號首集50，開放所有本局字冠，業務屬性和業務權限均為本局。

ADD

CNACLD：P=50，PFX=K'8，

MINL=8，MAXL=8，CHSC=I；

3，對號首集50中的所有本局字冠和PRA用戶新增號首處理記錄，變換為普通號首集0或專網號首集，注意不能重新分析，變換后直接查找號段表實現呼叫落地；

ADD PFXPRO：P=50，PFX=K'8707，CSC=50，DDC=TRUE，NPS=0，RAF＝FALSE；

50呼叫源經過號首處理后，存在于O號首集中(這同一個號首集有許多呼叫源，而一個呼叫源只能是一個號首集矛盾，做了號首處理后，同一呼叫源可以在不同的號首集中)。分機無應答重入回的是話務臺的長號，呼叫源為50，因為前面做了65534通配符，所有的呼叫源打本局字冠上NGN，這樣就會再上NGN，這就需要：

4對O號首集中50呼叫源針對本局字冠進行號首處理，不變號首集，不重新分析。

ADD PFXPRO：PFX=K'8707，

CSC=50，DDC=TRUE；

這條數據的設置解決本地來話呼叫源為50的主叫不上NGN。解決無應答重入故障。

案例2：某酒店分機經話務臺轉接，酒店接口機上話單割接前是話務臺的邏輯號87068888，割接后是話務臺的短號，這是因為割接前話務臺號碼變換是在端局，而割接后，號碼變換在SHLR。用戶要求強烈，數據進行重新設置：

1)，在SHLR中采用新羅輯號碼對應新物理號碼，老邏輯號碼對應新物理號碼的方法。

例如：話務臺號碼為87030888，路由號為817。

話務臺對外顯示87668888，原路由號為814。

新對應方法87030888 81787030888

87668888 81787668888

2)，在端局做87668888字冠的號首處理，變換成87030888接通。

配置實例：

端局上sS數據

1)ADD CALLSRC：CSC=I，CSCNAME=\"xx酒店”，PRDN=3；

2)ADD DNC：DCX=I，DCT=MOD，DCL=8，ND=K'87668888；

3)ADD

CNACLR：PFX=K'*65534#，

CSC=I，CID=K'8703，RSSC--0，FSC-=O，RCHS=0，RUT=ALL，RDCX=I；

SHLR上數據

1)ADD USR：DN=\"87030888\"。LRN=\"81787030888”：

2)ADD USR：DN=\"87668888\"，LRN=\"81787668888”：

它局號碼在端局的落地數據

1)ADD

CNACLD：P=50，PFX=K'87668888，MINL=8，MAXL=8，CHSC=0；

2)ADD DNC：DCX=2，DCT=MOD，DCL=8，ND=K'87030888；

3)ADD PFXPRO：P=50。PFX=K'87668888，CSC=50，DDC=TRUE，NPS=0，RAF=FALSE；這樣數據設置后，卻再次出現話務臺無應答重入故障。經跟蹤分析，話務臺重入時，被叫號碼里邊填充了用戶所撥號碼，而并沒有填寫經過變換后的被叫號碼。

首先在50號首集里邊分析被叫號碼87668888，變號首集為O，號碼為87030888(話務臺的真實號碼)，并接續到話務臺。話務臺拍叉至群內用戶B，B用戶無應答重入話務臺，重入時只是將被叫號碼填充為87668888進行分析，這里并沒有變換號首集為50。在O號首集里邊因為沒有87668888，沒有該用戶導致分析失敗，呼叫被拆除。

它局用戶號碼在08交換機落地的，無應答重人時又返回的甩戶所撥號碼，即87668888。應做如下樹據：

ADD CNACLD：PFX=K'87668888，SR 39=1MINL=8，MAXL=8，CHSC=0；

ADD PFXPRO：PFX=K'87668888，CSC=50，DDC=TRUE，DDCX=I，NPS=0，RAF=TRUE；

案例3：智能公用電話用戶正常呼叫時，因在被叫前插96544C，發送到CS時不能將C及以后的IAM消息轉發到端局，直接向端局發送REL消息，原因值為非法號碼；

08交換機下掛智能公用電話，因為08交換機局發送的IAM消息C字冠是后續發送到SS，SS默認對c字冠的處理為“#”符合，對于SS來說(A至F)這些字符雖然可以正常透傳，但是C字符和F字符很特別，C字符是默認為”#”字符，F字符默認為“結束號”進行處理。

將08交換機局的965449字冠最小位長更改為8位后，能正常接續。

案例4：08交換機端局ISDN用戶打本地網用戶，被叫用戶來電顯示為ISDN用戶的物理號。在SS跟蹤信令，發現08交換機端局ISDN用戶送過來的主叫用戶類別為國內號碼，并帶區號。在08交換機端局跟蹤，主叫用戶類別同樣為國內號碼。這樣，帶區號的主叫號碼在SHLR中找不到與此對應的邏輯號碼，所以在被叫端顯示的是ISDN用戶的物理號碼。

修改08交換機軟件參數。呼叫內部參數3，比特3：ISDN送主叫號碼參數。

=l：送給CCB的主叫號碼是國內號碼：

=0：送給CCB的主叫號碼是用戶號碼。

MODSFP：ID=P51，VAI_=\"FFF7\"；

修改后，被叫端顯示正常。

案例5：08交換機端局本局以及出局話務割接至SS后。根據端局數據簡單化的原則，字冠不必細分，但是，某證券公司要實現限額限呼功能，字冠必須細分，對區內和區間字冠要區分，對港澳臺和普通國際字冠要區分，普通國際和美國字冠等地區要區分，各種類型字冠對應不同的計費選擇碼，對應不同的計費情況和費率，才能使用戶準確的使用限額限呼。

以上案例我認為就是端局配合NGN數據配置比較成功的范例。有一定的推廣價值。

如果以為端局割接至NGN網絡后，端局數據簡單化，一切問題交給SS或SHLR解決，那是錯的。華為的NGN產品，是新產品，有其不成熟之處，除了文章開頭提到的各種優勢以外，并不能解決所有問題。案例1需要SHLR中要實現多個物理號對應一個邏輯號，案例2酒店用戶話單顯示需要與割接前的一致性，案例3是NGN網絡本身的問題，需要打補丁解決。案例4是網絡智能化后，對端局主叫要求規范化。案例5是用戶要實現特殊新業務功能，NGN網絡并不能滿足。這樣集團用戶和酒店用戶提出的各種各樣的需求，有時還需端局實現。這就是網絡智能化和用戶需求個性化之間的矛盾，這種矛盾就需要我們維護人員去解決。在給甩戶提供精品網絡的同時，盡量使用戶感到電信網絡的—致性，贏得客戶的信任，才能贏得市場。