+ Multiselect

FAQ

  • Q:Failed to create a USPP deployment package quickly

    A:Problem Cause Analysis:
         The focus is on the last sentence: "Omp number not equal ipi number", which means that the number of OMPs and the number of IPIs are inconsistent. It may be that the parameters in the INFO file are incorrect. 
         Check the INFO file through the INFO planning tool(plantool). Each network plane SIPI equivalent route + sub-interface is only equipped with one left port, and there are two OMPs planned, so the number of OMPs and the number of IPIs are inconsistent. 
    
    Problem Solution:
    Use the USPP INFO planning tool(plantool) to add a right port to each network plane SIPI equivalent route + sub-interface configuration, so that the number of IPIs is also 2 (equal to the number of OMPs); 
    Use the generated INFO file to quickly create a USPP deployment package. 
    
    
    

  • Q:Change M1 151 from FTP Server to SFTP Server for Multi users

    A:
    Problem Cause Analysis:
    The solution is the SFTP server. We can change from FTP Server to SFTP Server for support Multi users and good inspection. 
    We have upgrade the new function for MI 151 SFTP server. 
    
    Problem Solution:
    Create SFTP server on MI 151 
    On OMM 
    1. Add the IPv4 dispatch about MI 151 to open the MI’s SFTP Server function port, and synchronize data 
    2. Enter IP Stack Mode, Create the SFTP Server in the module MI 151. For better SFTP User Management, no need create the first SFTP Server user here 
    3. Create more users of the SFTP Server(hlr1, hlr2, hlr3 ……)
    4. Save the Online Data: 
    New Function about MI 151 SFTP Server
    1.Support 1000 files; Enable this function 
    2.Schedule Task; Enable this function 
    3.Display SFTP User in Agent Log; Enable this function 

  • Q:The CLIP service of VoLTE user abnormal that display two different number

    A:Problem Cause Analysis :
    1、check A# and B# subscribe date:the result is all right.
    2、check C number subscribe date. C# subscribe  VoLTE service and IMSI is 257010123456789(eg).check on agent service of USPP. the public identity is right.  but the relate private identity of the C# public identity management  is 257010123456123@ims.mnc.....  
      Actually the 257010123456123 is the imsi of A#. In a world that the private identity 257010123456123@ims.mnc.....  relate both A# and C# public identity. so when A# call B#.  For the CLIP service. B display both A# and C#. 
    
    Problem Solution:
    1、connect with provision and boss  side to modify subscribe. Got that the C# already abandon before. but not delete all subscribe date.
    2、provision side Delete VoLTE Subscriber date for C#
    3、A# Test OK.

  • Q:ZXUN uMAC- Modify OMM login from http to https

    A:1.  For example, the HTTP login link is : http://10.43.150.221:2323/combo_mmegngp_sgsn_7/client/#  .
    
     So the HTTPs login link is: https://10.43.150.221/combo_mmegngp_sgsn_7/client/#
    
     
    
    2. Disable HTTP
    
    a. Login OMM OS ,and vi /etc/httpd/conf/httpd.conf.
    
    Find " Listen 2323 "  in httpd.conf  and annotate this line with "#".
    
    b. vi /home/ngomm/config/bakhttp 
    
    Find " Listen 2323 "  in bakhttp  and annotate this line with "#".
    
    c. Run  "service httpd restart" command to restart http service. 
    

  • Q:ZXUN uMAC-MME delete dedicated bearer wrongly for idle user

    A:Problem Cause Analysis :
    From the uppper picture,we can see:after the establishment of dedicated bearer, when user enter idle state, the S1 connection will be released(release cause is user-inactivity), then MME will delete the dedicated bearer. 
    Troubleshooting Process (Problem Solution)  :
    1. MME can keep the dedicated bearer when user enter idle state. it is decided by a software parameter. the software parameter ID is 786479, shown as below: 
    2018-07-27 10:35:33 Command (No.4): SHOW SOFTWARE PARAMETER:PARAID=786479; 
    
    Parameter ID   Default Value   Current Value   Minimum Value   Maximum Value   Parameter Name   Remark   
    ---------------------------------------------------------------------------------------------------------- 
    
    modify 786479   14   14   0   255   preserve GBR bearers in case of eNodeB failure   BIT:1 Other reasons except User Inactivity,Inter-RAT Redirection,Radio Connection With UE Lost and CS Fallback triggered 0-No 1-Yes;BIT:2 User Inactivity 0-No 1-Yes;BIT:3 Inter-RAT Redirection 0-No 1-Yes;BIT:4 CS Fallback triggered 0-No 1-Yes;BIT:5-8 Invalid    
    ----------------------------------------------------------------------------------------------------------
    Record 1 
    2. Solution is that :set this software parameter to 14(default value), then when eNB release S1 connection with cause=User Inactivity,MME will not delete the dedicated bearer. 
    

  • Q:MANO-Link Broken between VNFM and VNF

    A:VNFM had not received the RPT HEARTBEAT from the VNF. 
    meanwhile,VNFM can receive the message RPT HEARTBEAT  from another VNF and has no Link Broken about this VNF. 
    therefore the issue caused by VNF OMM. 
    Operate VNF OMM in order to send the RPT HEARTBEAT message normally.

  • Q:ZXUN SBC-Link Disconnection Alarm After ISBC Version Upgrade

    A:During the commissioning test of ISBC V2.00.81, the interconnection with the EMS and northbound is normal. Later, the engineer upgrades the ISBC version to V2.00.85 according to the requirements of the VoLTE project team. After the upgrade is complete, the EMS shows that the link with the ISBC is broken and a critical alarm is reported. Meanwhile, the customer’s monitor system shows many northbound failure alarms. That is, the EMS cannot collect alarms and performance files from the NE. 
    After the ISBC is upgraded, no problem is found in the service verification. During the upgrade process, routing information is not modified. The engineer also compares the old and new routing tables but does not find any change. Therefore, the route from ISBC to EMS is reachable after the upgrade. It is also proved by the ping test. 
    The engineer upgrades the version according to the upgrade document, and the version is confirmed to be correct. On the EMS, the engineer deletes the NE and adds it again. Then, the problem persists. The engineer finally consults the 800 hotline. It is found that V2.00.85 has requirements for SNMP access. When trusted IP addresses are configured, the EMS’s address should be added to the ISBC. 
    The engineer configures snmp-server trust-host IP on the ISBC. The problem is solved.  
    

  • Q:ZXUN vUniCore-VM Cold Migration Steps

    A:Before commissioning, compute domains and forwarding domains are not divided according to specification. When preparing to deploy SBC VMs, the engineer finds that VMs exist on all blades. It is required to use some blades for forwarding domains and high-performance DVS core binding. 
    
    The following describes how to perform cold migration in TECS OpenStack: 
    Step 1: Log in to the control node through ssh. 
    Step 2: Query all the deployed VMs and host relations. 
    [root@sdevctl ~]# source /root/keystonerc_admin 
    [root@sdevctl ~(keystone_admin)]# nova list --all-t --fields name,status,power_state,host,instance_name 
    Suppose you want to migrate hostA to hostB. 
    Step 3: Query all the VMs deployed on hostA. 
    nova list --all-t --fields name,status,power_state,host,instance_name  | grep hostA 
    Step 4: Run the following command for cold migration. 
    nova migrate  UUID  hostB 
    After the migration is complete, the VMs cannot be seen on hostA. Run the following commands. 
    Step 5: Run the resize-confirm command to verify that the migration succeeds. 
    nova list --all-t --fields name,status,power_state,host,instance_name  | grep hostB 
    If the status changes from RESIZE to VERIFY_RESIZE, run the confirm command. 
    nova  resize-confirm UUID  
    Step 6: Repeat steps 4 and 5 until all VMs are migrated.

  • Q:ZXUN CSCF-CSCF OMM Client forced out after login in

    A:1. The OMM can login, it means the server process is up, can use ssh/xmanager access OMM. excute ps -ef|grep service to check the process
    2. The NE's service loopbcak IP can be ping, and OMM can also ping the front board, use this command to check, the front boaed process is work
    [admin]# sh 0
        Now switch to PLAT_L_X86_64_64_R_V01.02.21.00 shell ...
        [PLAT_L_X86_64_64_R_V01.02.21.00]# SCSShowMcmInfo()
    3. Excute show omslink to check at the OMM, find it is established
    4. Checking the service process at OMM, find this process is abnormal, the problem solved after restart
    

  • Q:ZXUN SSS-The troubleshooting of SSS PUR forwading in DRA with error 3007

    A:When SSS provision a user,the trace in DRA response error ---Diameter application unsupported 3007 
    According to the standard protocal,when the SSS sending the diameter to DRA,can't carry the destination host,but in this failure case,the PUR message carried the destination host name ,this is the reason. 
    The solution :
    In sss use the diameter signal edit to delete the destination host name ,ways as below 
    1.Open diameter signal edit switch,command as below : 
    SET SYS GLOBPARA:IDX=300,CURVAL="1",3=0; 
    2.Configure the detination host name related AVP code(293) 
    ADD DIM AVPCODEMATCH:ID=1,AVPCODE=293,VENDORID=0,AVPLAYER=1,FATHERAVPID1=0,FATHERAVPID2=0,FATHERAVPID3=0,FATHERAVPID4=0; 
    3.Configure the editing action and related the PUR Command code 307,and match the AVP (293)code 
    ADD DIM EDITACT:NO=1,OPWAY="DELAVP",DIRECTION="OUT",CMDCODE=307,METHODTYPE1="ACP",METHOD1=1,METHODTYPE2="NONE",METHOD2=0; 
    4.Adding the editing policy ,related  the destination host name and editing action 
    ADD DIM
    EDITPLC:NO=1,APPID="DIM_APPID_3GPP_SH_DH",URI="DRAUIO.epc.mnc000.mcc740.3gppnetwork.org",SWTICH="ON",ACTNO1=1,ACTNO2=0,ACTNO3=0,ACTNO4=0,ACTNO5=0,ACTNO6=0,ACTNO7=0,ACTNO8=0,ACTNO9=0,ACTNO10=0; 
    After  finishing the signal editing commands ,the  DRA forwarding the PUR  message successfully. 
    
    
    
    

  • Q:ZXUN CSCF Unable to enter the Linux operating system through the TECS console.

    A:Through the CRT tool SSH login CSCF linux operating system no problem, indicating that the normal operation of the CSCF linux operating system itself, except from the TECS console can not enter, indicating the CSCF Linux operating system and TECS communication problems
    1.After pressing Enter prompt error message:get message failed,Therefore, the messagebus service may be closed with the CSCF's linux operating system
    2.Login to CSCF's linux operating system via CRT tool
    3.Execute the "chkconfig messagebus on" and "service messagebus start" commands
    4.Then we can login in CSCF linux system via TECS console.
    

  • Q:How to check and solve the MAC conflict alarm for XGW

    A:First suspected the mac offset for the interface have some issues,so  checked for that and confirmed all ok .
    Then we check the alarm description in the e-reader for this alarm and find that we need to match the MAC address with the tag on the rack thus we can keep the mac address the same .so we do as follows:
    SuperMan16(config-corporation)#check basemac
    ---
    SuperMan16(config-corporation)#check basemac
    Consistence is correct,current base mac address is 00:d0:d0:a1:17:17,
    total is 63,do you want to modify it? [yes/no]:yes
    Please input new base mac address:00:d0:d0:a1:17:17
    Please input new base mac total:63
    Confirm it? [yes/no]:yes
    Modify base mac successfully,current base mac address is 00:d0:d0:a1:17:17,
    total is 63,the configuration will take effect after reloading system. 
    
    After reset the MAC ,as the XGW not online yet ,restart the XGW to take effect the new MAC address,After reset,the alarm cleared and working fine.

  • Q:ZXUN xGW-Some xGW cannot trigger the CCR message after interconnecting with the OCS.

    A:For interconnection between ZXUN xGW and the OCS, after the interconnection is completed, the user number’s service process cannot trigger the CCR message to authenticate and obtain quota from the OCS.  
    First, the onsite checks the link to the OCS by running the show pgw diameter link-state id 3 or 4 command on the xGW. The link to the OCS is in open status, which indicates that the link is proper. 
    Check configuration data of the online charging according to ZXUN xGW(GUL) V4.15.10_Online Charging Feature Guide. Each data is correctly configured. 
    Check the DPI status. Each CPU activates the DPI template already. 
    
    Trace the signaling and it finds that Charging Characteristics is normal charging in the GTP Creat PDP Context Request message. It cannot trigger online charging. 
    Signaling of GTP Creat PDP Context Request is sent to the xGW by the SGSN&MME. The SGSN&MME judges according to the user charging status delivered by the HLR&HSS. Check data of the HLR and it finds that charging mode of PDP Context is normal charging. After the parameter is modified to prepaid, the CCR message to the OCS can be normally activated on the xGW. 
    Caution: It must be charging type in PDP Context. There are several options for charing type on the HLR&HSS. The other option will not affect Charging Characteristics of GTP Creat PDP Context Request. 
    

  • Q:ZXUN uMAC-For MME cutover and accessing network, some eNodeB cannot access the MME.

    A:1. Check the base station configuration and the parameter related configuration. No problem is found. 
    2. Replace with the other manufacturer’s base station and restart. The problem still exists. 
    3. Check data configuration of the MME. The interconnection data with the eNodeB is proper. 
    4. Check the table capacity configuration of the MME. The dynamic eNodeB capacity (global) set on the SBCJ board is 64. The capacity is too small, resulting the base station whose capacity is over 64 cannot access the MME. Locate the problem by running the command below. 
    Command  (No.1): SHOW CAPACITY 
    3G USUP PDP context number (single module) Dynamic eNodeB capacity(global)  Diameter session capacity (single module) 
    ------------------------------------------------------------------------------------------------------------------ 
           100000                              64                                5000               
            500000                             64                                5000                 
    ----------------------------------------------------------------------------------------------------------- 
    5. Modify the capacity setting. Reboot to make the setting effective. 
    Perform the related service test. The problem is solved. 

  • Q:ZXUN SSS-Supplement for Integrated VPN Traffic Console Cutover Scheme

    A:The difference with the common group is: 
    1.     Modify the group property to “province ivpn group”. 
    2.     Open the “mixed group”, otherwise, short number of the traffic console cannot be connected (the short number is configured on the SSS). 
    3.     For the other properties, modify them according to the customer’s requirements. 
    4.     Number of the traffic console is as the same as the number of common traffic console. It distributes numbers normally. 
    5.     Modify the SP template on the HSS to be the template which only triggers the callee services of the SSS. 
    
    In addition, the following swithes of the SSS should be opened. 
    SET SYS GLOBPARA:IDX=1397,CURVAL="1"; 
    The difference is in the user’s call flow of the traffic console: 
    For the ASU traffic console, as the call is sent to the ASU directly through the traffic consle computer, the ASU sends the call to the SSS. Currently, the SSS traffic console sends the call to the ICSCF. In this case, after the call is sent to the ICSCF by the SSS, the ICSCF goes the callee process directly. The IVPN services of the ASU cannot be realized through the calling’s SCSCF. 
    The latest version handling process of the SSS is: 
    When the SSS traffic console is configured to be mixed group, if the ASU traffic console originates a call and the number is not the extension small number in the SSS number distribution group, the SSS will add orig in the route field when sending the number to the ICSCF. The ICSCF triggers the calling process according to the orig label. Find the calling SCSCF by querying the HSS. The calling SCSCF completes the calling’s IVPN service trigger. 
    HSS data configuration: 
    Pay attention that number of the ASU traffic console cannot subscribe services of the calling SSS. It is because that the call itself has already passed the calling SSS already and generates a CDR. If it subscribes the calling services to the SSS, it will generate a CDR again, resulting repeated charging. So it is required that only the caller services’ SIFC of the SSS is subscribed when the HSS distributes numbers. 

  • Q:ZXUN CSCF-After the CSCF Diameter link configuration is completed, part links instantaneous interrupt.

    A:The reason for the above problem is that when configuring the SCTP association, the CSCF acting as a client end to originate link establishment to the HSS which acts as a service end. At present, the CSCF verison is limited that the client end link cannot use the same IP address and port number. Otherwise, more than one association will share one bottom SCTP instance. In this case, if multiple links are successfully established, there will be no problem. But if one of the links fails and closes the instance, the bottom will forcely release all the links bundled on this instance.  The reason for this example is that the link configured to the HSS which is not enabled is broken and the same IP port is configured to the two HSS. These cause instantaneous interruption of the SCTP link. 
    When the IMS NE acts as a client end to configure SCTP associations to more than one service end, it is forbidden to use the same IP address + port. 

  • Q:ZXUN CSCF-A Troubleshooting Case of S-CSCF of Some Office Reports MO/MT Call Establishment Successful Rate Lower than Threshold When the Services Are Busy

    A:Make statistics of the failed call signaling of 503 through the signaling monitoring platform. It finds that these signalings are sent to the S-CSCF by the MGCF. 
    The cause value is 47. The failure reason is “resource is unusable”. 
    Through location and analysis, it finds that this failure code is mapped by the 2/3G gateway failure. 
    Through locating and analyzing the 2/3G gateway, it finds that the gateway resource is insufficient when the services are busy, resulting part calls are abnormally released. 
    Final location of the problem is that the gateway device’s capacity is insufficient, thus it needs expansion so as to meet the onsite’s traffic requirement. 
    

  • Q:ZXWN GGSN-Charging rule install failed because of "UNKNOWN_RULE_NAME"

    A:1. After in-depth inspection into the CCA message that receiving from PCRF, it was found that the AVP in the CCA was "charging-base-rule-name" instead of "charging-base-name" that we have agreed with PCRF. That was the reason xGW reported "UNKNOWN_RULE_NAME"  even if the configuration of "charge-control predefine" had been done.
    2. After PCRF changed  the AVP from "charging-base-rule-name" into "charging-base-name", the fault was fixed.
    

  • Q:ZXUN USPP-Can not open USPP remote MML terminal and Webagent though EMS after change URL to https login.

    A:It need to excute one command to allow the encrypted traffic for https login.
    The command is to excute the following command on EMS MML:
    set wrt encrypt:true
    

  • Q:ZXUN uMAC-MME NE Command Execution Is Overtime

    A:1. To run the command to modify the cell tracing way to be the OMM way, you shall restart OMM of MME. Restart OMM on the NEC dual-comput er interface. 
    2. After OMM is restarted, run the SHOW SOFTWARE PARAMETER:PARAID=786709; command, current value of the returned parameter is 2, which indicates that cell tracing is enabled. Run the SHOW SOFTWARE PARAMETER:PARAID=65657; command, current value of the returned parameter is 0, which indicates that the STS cell signaling tracing report type is EMS way. 
    3. Run the SET SOFTWARE PARAMETER:PARAID=65657,PARAVALUE=1; command to modify the STS cell signaling tracing report type to reporting OMM. Then, the oamserver CPU occupancy rate is reduced to 10%. The problem is solved. 
    

  • Q:ZXUN SBC-Bac returns error 481 when the wiring control calling number is called in the IMS domain.

    A:1.For the call of the secondary way: Call-ID: LU-1506526596901915-2422405@imsgroup0-001.pcscf01.ha.ctcims.cn 
    The length is 62. But in the info message, length of the carried info is 50. The inconsistent length causes that SBC returned error 481. 
    2.Bell modifies the secondary call: Call-ID: LU-1506526596901915-2422405@imsgroup0-001.pcscf01.ha.ctcims.cn 
    It modifies 62 to be 50. 

  • Q:ZXUN SSS-In one-touch upgrade process, it fails to run the related commands. It prompts of “instruction does not exsit”.

    A:1. First, confirm grammar and format of the command line to be executed are correct. 
    2. Query whether it failed to execute this operation in other province previously. 
    3. Only this province has this case. Restart the browser and execute again. The similar case still exists. 
    4. Check whether it is cache problem of the browser. Try to clear all the historical records and operation caches. 
    5. After the cache clearance command is executed, all the left commands can be executed. The upgrade task is completed smoothly. 
    

  • Q:ZXUN SSS-It prompts of forbidding entering when running the command to enter protocol stack in the SSS network.

    A:1. First, check whether there is any alarm or not. 
    2. View the board status. It prompts of connection overtime. 
    3. Check the link between the front-end and the back-end. The link is not established successfully. 
    For debugging on ASU, when the link from ASU to OMM is added, all the modules are configured with IPs to ASU, this causes link establishement. Delete the current link between the front-end and the back-end. Then, the problem is solved.

  • Q:ZXUN CSCF-How to shield IFC trigger for temporary?

    A:This service AS should be shielded for temporary. Wait for recovery. The configuration is as follows. 
    Add one SPT numbered 711 and group location is 60. Check both of them do not conflict of onsite. 
    ADD SPT:SPIID=711,NAME="GROUP30-NO-trigger",SPT="<SPT><ConditionNegated>0</ConditionNegated><Group>60</Group><SIPHeader><Header>aaaa</Header><Content>bbbb</Content></SIPHeader></SPT>"; 
    Note: For this SPT, it will trigger only when the sip header carries aaaa:bbbb on the basis of the original conditions. 
    Bundle this SPT with IFC. 
    Delete this SPT bundling after the services are recovered. 

  • Q:ZXUN SSS-AS NE A User Generates Abroad Roaming CDR Without Going Aboard

    A:Query normal CDR of the user on CG. It finds that the user is in 2/3G networking when being called. 
    Location area of the reported CDR is: 
    cS-Location-Information[0]{ 
             mscNumber="882322001999" 
             location-Area=F7B7 
             service-Area-Code=0000 
    View the roaming number brought by the above user. It is certainly not a roaming code of local city, The roaming number is taken from HSS through AS and needs to be continue analyzed on HSS. 

  • Q:ZXUN xGW-How to trigger dedicated bearer in xGW

    A:We can use bearer content to trigger the dedicated bearer to test:
    1. Configure one bearer content. Please pay attention that in TFT, the IP range is the UE IP range. 
    bearer-content 1 
    eps-bearer-id 5 
    operation-code 1 
    qos qci 1 arp pvi 1 pl 4 pci 1 mbr 2000000 2000000 gbr 2000000 2000000 
    tft 1 ipv4 10.150.76.0 255.255.255.0 mask 0 priority 1 direction 3 
    Exit 
    Following is the meaning of the parameters:
    a. eps-bearer-id:It is the bearer ID of current bearer content. The value range is 5-15. Usually, 5 stands for default bearer, and 6-15 stand for other dedicated bearer;
    
    b. operation-code:It is the corresponding operation of current bearer. The value range is 0-7. The detailed definition can be checked in 24.008 of 3GPP.
    c. QOS:It is the QOS to configure dedicated bearer, including QCI/ARP. When QCI corresponds to GBR bearer, MBR/GBR can be configured. But if QCI corresponds to Non-GBR bearer, MBR/GBR will be invalid even configured. When creating or modifying QOS, it is required to be different from the QOS of existing dedicated bearer. 
    d. TFT: It is used to configure the PF parameter of dedicated bearer. Usually the default bearer will not install any PF to make sure that it is the default data channel of system. Dedicated bearer must and can only create one TFT, but one TFT can contains more than one PF. At least one TFT(PF) needs to be configured when configuring dedicated bearer. 
    2. Use command to trigger the dedicated bearer for your SIM card.
    bearer-activate imsi  410060539954404 link-bearer 5 content1 1 
    3. For the delete dedicated bearer test case, we can use following command to delete for the test SIM. 
    bearer-delete imsi 410060539954404 link-bearer 5 network-deactive content1 1 
    

  • Q:ZXUN CSCF-ZXUN CSCF Send SAR Failure

    A:1. ICSCF and SCSCF connecting with the same DRA and HSS, ICSCF success to send UAR, and SCSCF send MAR is also fine, but SCSCF failing to send SAR message.
    2. Analying the route method of UAR/MAR/SAR, we can find that UAR and MAR use the hostname and domain name from the configuration in URIANA and TELANA to choose route selector.
    3. But SAR use the hostname and domain name is from the MAA message sending by HSS.
    4. HSS use HSSOPT command to configure hostname and domain name to fill in MAA.
    5. DRA request CSCF send domain name is ims.mnc, but the configuration in HSS is epc.mnc, so it returns to SCSCF ecp domain, SCSCF can't send SAR message using this domain.
    6. Configuring the domain name in HSS is ims, the issue solved.
    

  • Q:ZXUNN SSS-How to set the playing time of announcement tone

    A:By change the value TONETIMES of command "SET TONERES" to set the play times of tones.
    SET TONERES:NODEID=,SRVTONEID=TONETIMES=,TONEPRI="CP";
     
    

  • Q:ZXUN USPP-Active but failed to validate CFD supplementary service in USPP

    A:A new USPP commissioning and PAT test, which active but failed to validate CFD supplementary service, we found that USPP failed to send “DELETE”signaling message to VLR instead of “INSERT”. 
    In WCN Service Supporting Option Configuration (WCNOPT) on MML, there is a parameter “CFD Available In” set as “HPLMN” by default, in this way, it need to add local NDC configuration data, the command is as follow: ADD HNDC. 

  • Q:ZXUN SSS-When terminal perform voice/video switching, the terminal switching button is grey. It cannot perform switching.

    A:In the voice/tone switching testing process of some province, it finds that: 
    A->B voice completed, A switches video call request, B answers. At this time, switch back voice on terminal A. The button is grey. Switch back voice request on terminal B. Terminal A answers normally. After the call is completed, switch to video on terminal A and terminal B. The buttons are grey. 
    B->A voice completed, A and B switch video – voice – video – voice respectively. They are normal. 
    Through signaling analysis, it finds that B has CRBT while A does not have. 
    The CRBT platform deletes video feature tag in contact. This causes that the rear cannot identify video. 
    Contact head in invite message which is sent to CRBT platform: <sip:46002407406200@10.185.184.137:5082>;zte-did=2-12-20481-911-12-480;video;+g.3gpp.icsi-ref=”urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel” 
    After the message passes through the CRBT platform, contact in invite sent by the CRBT platform: <sip:10.185.187.3:5060> 
    Solution: Firstly, check whether SSS 5531 switch is configured to be 1. The CRBT deletes key content in the contact head. The CRBT platform shall handle.
    
      
    

  • Q:ZXUN uMAC-It prompts error 117 when uMAC loads patch version.

    A:Generally, it is network problem. It fails to communicate from OMP to OMM or it is caused by sftp.
    1. Ping the foreground OMP board on OMM. It pings through. 
    2. Ping the foreground OMM on OMP. It pings through. 
    3. FTP (SFTP) account and password can log on network management server normally. The logon speed is not slow. 
    4. Finally, view the file attribute, you can find that it has no read authority for the patch file. After the patch file authority is modified to be 777, it can load normally. 
    

  • Q:ZXUN SBC-Remote Obtain startrun.data of SBC

    A:Due to it fails to establish SBC measure task on U31, but the rear requires of obtaining runstart.data file of SBC, so it describes the method.
    1. Obtain files on the SBC equipment. To download these data packets from the SBC equipment, it must use ftp way. The SSS NE and SBC NE area connect to the same switch and the network sections are the same. So they can ping each other through. 
    2. Create ftp account information on SSS NE. 
    3. On the SSS NE, you can remote download the data packets on the SBC equipment to the SSS server directory with the created ftp account. 
    

  • Q:ZXUN SSS-Call Forwarding Abnormality of IVPN User

    A:Call forwarding of some ivpn user is abnormal. User B registers call forwarding unconditional and it feeds back that the specific calling A cannot forward (the caller B rings), but the other users’ calls can forward to C.
    Call forwarding is not triggered, but is is related to the calling. Correlation of the calling and the called should be analyzed. 
    1. When the called’s SSS services of B number is triggered, the carried A number is a long number. 
    2. After B number’s services are triggered, PAI in the invited message that returned to SCSCF is in the form of area code + user number. 
    3. Through checking, it is found that the calling A is also an ivpn user. Numbers A and B are in the same group and they are in the form of area code + user number. 
    It can be judged that the problem is in IVPN group. Check group property and it is found that mixed-group switch is enabled. 
    4. Check group services registered by the user. Set no forwarding for intra-group call. 
    5. Confirm with the user that disable the mixed-group switch for the ivpn group. 
    

  • Q:ZXUN uMAC-Processing of DNS Complaints

    A:Some carrier complains that an overseas carrier’s 4G data roaming service test fails. It asks for assistance. 
    Perform signaling trace on the user adhesion process and it finds that DNS query fails so that the user cannot obtain PGW address. 
    It suspects that DNS configuration causes analysis failure. 
    Check DNS analysis steps and it finds that TA analysis is successful which indicates that DNS services in the province are normal. 
    
    Choose another roaming carrier B to perform service test. It founds that users use 4G data services properly. It judges that the recurrence analysis process from intra-province LDNS to root DNS to international office’s iDNS is normal. 
    
    Check the international iDNS configuration. It is found that the DNS services of the superior international transfer carrier C’s services is configured in named.cache of the rr file. 
    Perform dig test on APN analysis record of the roaming carrier A on the international office’s iDNS. 
    It finds that carrier C returned DNS server IP of carrier A already. It judges that the transfer carrier A configures this analysis record to be iteration query way. Ping the returned DNS address on iDNS. The route is unreachable. 
    Feed back the check result to the customer. The customer checks the route from iDNS to DNS of roaming carrier A. It passes the roaming test after route problem is solved. 
    

  • Q:ZXUN RCP-Solution for Failing to Establish A link When PCRF Interconnects OCS

    A:1. First, check link configuration. Confirm ipv4 delivery is not configured. 
    2. Ping the rear OCS address. The address can be pinged through. But the link is not established. 
    3. Ping OCS address (with destination port number) with random source port number. The address cannot be pinged through. 
    4. Check the network problem with trace. The fireware which the network problem is in is found. 
    5. Contact the firewall side to enable the ports. The problem is solved. 
    6. The diameter link is established successfully.  

  • Q:ZXUN CSCF-Delay deteriorates obviously when v2v end-to-end call is established.

    A:1.Generally, the problem is caused by delay increasing when a link is established on EPC side or equipment fault on CN side. 
    2.Check delay index on SBC side is proper. 
    3.Rank the users whose delays are longer according to signaling detection platform. Perform signaling analysis on the front users. 
    4.Check it is fault of some TAS service platform which is used by a small number of users. This causes increasing of whole delay. 
    5.Services after recovered after TAS fault is eliminated.  
    

  • Q:ZXUN xGW-How to Solve the Problem of GSU Failure and CPU Offline?

    A:First, extract and view alarm information according to the related alarm prompt. 
    It is GSU board that reports this alarm. View the board status. Indicator of CPU4 has an alarm. The board can be powered on normally. Try to insert and extract this board again. Observe and you can find that alarms on GSU breakdown and CPU offline are eliminated already. But the alarm appears again after running for several hours. 
    It is preliminary suspected that CPU4 sub-card of the GSU board fails. So you can only try to replace with a new GSU board. Observe for one week and you can find that the alarm does not appear. The problem is solved. 

  • Q:ZXUN xGW-select OCS based on IMSI segment ?

    A:1.mapping IMSI number to OCS node name 
    KTM-SAEGW(config-xgw-pgw)#das ocs digit-number imsi 429040000429958 adjacent-node dmtsrv001  
    KTM-SAEGW(config-xgw-pgw)#show pgw das ocs digit-number                                 
    Prefix-type    Prefix              Ocs-server-type     Ocs-server-name 
    imsi          335550000666777    adjacent-node       dmtsrv001 
    2.enable OCS-selection function 
    KTM-SAEGW(config-xgw-pgw-apn)#charge online analysis-route ocs-priority-policy 
    3.create OCS priority policy , the policy is based on IMSI 
    KTM-SAEGW(config-xgw-pgw)#ocs priority-policy 1 imsi 
    4.In APN mode , use the OCS selection policy , which is created just now. 
    KTM-SAEGW(config-xgw-pgw-apn)#charge online ocs-priority-policy 1 
    

  • Q:ZXWN GGSN-PCRF send different Rule policy and HeadEnrich function realize

    A:operater A want to active HeadEnrich function,and PCRF send charge rule name to XGW,this charge rule name mapping xgw configuration charge-control predefined "policy name".because in charge-control predefined,policy name is unique.in DPI configuration,if no L7 rule setting,can't active HeadEnrich function,in this operater,we check the DPI,two piece of default L3/L4 rules defined for normal services,and some L7 rules for HeadEnrich function.L3/L4 and L7 relation to different RULE BASE ID.because policy name is unique.we can't seperate different control-rule for  HeadEnrich or non- HeadEnrich.so when we test,all the website be added  HeadEnrich,or we change the control-rule,all the website can't active  HeadEnrich.in this case,it doesn't meet customer requirments.and should be disclosure user privacy.
    
    if PCRF send charge rule base name to XGW,this issue will be fix very easy.charge rule base name mapping to xgw configuration charge-control-group charge-control-group predefined "group name",one group name can include many "policy name",so we can defined different control-rule for different RULE BASE ID in DPI.and for special website active HeadEnrich,for normal website don't active HeadEnrich.
    
    now PCRF send charge rule name to XGW,we can't defined different control-rule for normal websites and HeadEnrich websites.how to resolve this issue.according to the HeadEnrich function active mechanism.if no L7 rule,can't active HeadEnrich.so we can move L7 rule from default rule setting,just keep L3/L4 rule,even we choose HeadEnrich for this RULE BASE ID,the HeadEnrich function can not active for normal website.so first,we use "nslookup" get all the detail IPs for L7 URL.and move these RULE to other rows,add new L3/L4&L7 for HeadEnrich websites. and for all services active HeadEnrich in control-rule.
    

  • Q:ZXUN xGW-Subscribe bundle with 4Mbps limitation in PCRF but failed to service activity

    A:For 4Mbps limitation, it need to enable software parameter in PGW, the command  as below: 
    BZZGG01 (config - XGW - PGW) # list - softpara 711 
    Index  Current  Default  Comment 
    711    4000   300000  < 0,500000 >  Maximal service QoS control value (Kbps) 
    The default value is 4000, but the value need to be set to more than 4000, because: 
    1) This parameter is the Maximal service QoS control value (KBPS), the current value is 4000, so it can only support 4000 KBPS maximum. 
    2) If the PCRF send service speed rate is more than 4000 Kbps, and the service would be failure. 
    By modifying soft parameter 711 to more than 4000 to solve, the following commands: 
    BZZGG01(config-xgw-pgw)#softpara 711 5000 
    Synchronous change table to test validation problem solving. 
    

  • Q:ZXUN HSS-Disk Space Fully Occupied on the DST Board

    A:1. Log on the DST blade which has alarm and its corresponded DST blades. Compare occupied space of each file. 
    2. You may view file occupancy situation by running the du -h --max-depth=1 command. 
    3. Through comparison, it finds that in the DST blade which reports alarm, it generate a large number of files under /oracle/admin/hlr/udump/ which occupy space. The file type is *.rtc. 
    4. Confirm that these files are junk data. You can delete by running the rm -rf *.rtc command. The alarm is eliminated after these files are deleted. 
    5. But after a period of time, it reports alarm on full space again. It generates a large amount of junk data as the same. 
    6. Through further analysis, it finds that besides this alarm, another alarm of “DST persistent failure” appears irregularly. 
    7. The final reason is confirmed that due to connection abnormality between DST and database, it causes DST trace failure and generates rtc junk data. The basic solution is to handle connection failure between DST and database.  
    The problem is solved by re-establishing database and table for HSS NE database. It does not generate rtc junk file after it is recovered. 

  • Q:ZXUN xGW NE of some office’s EPC_LTE network reports alarm on GSU breakdown and CPU offline.

    A:According to the site description, the possible reasons that cause the alarm are board physical damage, some CPU sub-card problem, power-on failure of CPU or manual restarting CPU failure. 
    First, extract and view alarm information according to the related alarm prompt. 
    It is GSU board that reports this alarm. View the board status. Indicator of CPU4 has an alarm. The board can be powered on normally. Try to insert and extract this board again. Observe and you can find that alarms on GSU breakdown and CPU offline are eliminated already. But the alarm appears again after running for several hours. 
    It is preliminary suspected that CPU4 sub-card of the GSU board fails. So you can only try to replace with a new GSU board. Observe for one week and you can find that the alarm does not appear. The problem is solved. 

  • Q:ZXUN USPP-Error with Scheduled DB Backup

    A:1. Due to write process of the disk array has problem (another problem caused by disk array hard disk abnormity), DST node is in abnormal status. It should be that the link between IDSA and DST is still in abnormal status after DST node is normal. 
    2. Due to DST module restart up will not affect services, and this office is a standby office. Communicate with the customer and restart DST2. 
    3. After DST is restarted, IDSA node persistency status is normal. 
    4. Modify backup time. Test and confirm auto-backup is normal.

  • Q:ZXUN USPP-Enabling Telnet Login to OMM

    A:1. Log in to the OMM server through ssh, and modify the /home/ngomm/ndf/bin/conf/deploy-ndf-socket-def.properties as follows:
    ndf.switch.ssh=1
    ndf.switch.telnet=1  ///Modify the value from 0 to 1.
    ndf.type.cm=3 
    2.Run the following command to restart the NDF process to validate the modification:
    #pkill -9 ndf 
    Run the following command to check whether the NDF process is started successfully:
    #ps –ef | grep ndf 
    3. Run the telnet+OMM IP+port number (always 7777) command on the OMM client to try login. For example: 
    D:\>telnet 192.168.2.129 7777
    1) Set the office ID.
    2) Run OMM commands as required. 
    
     
    

  • Q:ZXUN SBC-Failure to Distinguish Audio From Video on the ISBC Media

    A:1. Video media formats include h261, h263, and h264, which should be distinguished from audio formats. 
    2. It is required to associate media rules under the PBX’s pool for this PBX. 
    3. In config-sbc-sp mode, configure sdp-check-profile 1. 
    4. In config-sbc-sp-sdpcp mode, configure no match media-format from video. 
    5. In config-sbc-sp mode, configure media-check-profile 1. 
    6. In config-sbc-sp-mcp mode, associate sdp-check-rule 1. 
    7. In config-sbc-sp-sg-pl-pnh mode, associate media-check-rule 1.  
    During ISBC configuration, media control can be configured based on media checking rules. The rules are valid only if the signal nexthop to be controlled is restricted. 

  • Q:ZXWN MSCS-MAP version inconsistent lead to OTA service failure

    A:1.  To review signaling message with SSN 9, it is normal. (Note: MSC signaling trace tool is 24-bit decoding by default, it need to change to 14-bit decoding, set is shown as below) 
    2.  Checking MAP dialogue in the message, OTA response CHKIMEI message with V2, it is not consistent between MSC and OTA. 
    3.  On MSC, to add the GTMAP configuration and change the application context version to V2. The MML command as below: 
    4.  Synchronization data to OMP, OTA service test again and IMEI response message become normal, this issue resolved.
    The integration between MSC and OTA, the following parameters in the signaling message should be focused on. 
    

  • Q:ZXUN uMAC-How to solve the subnet ID confliction while adding uMac NE to EMS

    A:Sometimes the subnet ID is not planned very well , or can not be integrated to EMS on time, we set the subnet ID as default value, then we may met problem while we integrate the NE to EMS. The system will give hint: same subnet ID exist is EMS node, cannot add it to system any more.
    The problem is caused by the subnet ID, so we have to ways to solve this problem.
    1. close the subnet ID check at EMS end
    2. Change the subnet ID at the NE end.
    Run vi command to edit the file and change the field to the value expected. 
    

  • Q:ZXCN USPP-processing voice call interrupt after add AAA configuration in USPP

    A:1.  before add AAA configuration, all voice service is ok ,that means BSS and MSCe have no problem. 
    2.  Check subscriber status in HLRe via WEBAGENT is normal. 
    3.  Trace signaling in MSCe, we found MSCe got refuse from HLRe, reason is ‘subscriber does not exist’. 
    4.  The issue happened after AAA configuration ,so we check AAA domain configuration, found service use default domain is AAA domain. That’s means when have voice coming, use AAA information to do CS service, then show ‘subscriber does not exist’. 
    5.  So we need change default domain is HLRe domain, as follows, 

  • Q:ZXUN CSCF-wildcard PUI configuration in ISCSCF

    A:1. in(PCSCF--ICSCF and ICSCF-SCSCF) entrance policy , set Trust P-Profile-Key Header and Wildcarded PUI to 'YES'
    2.global service configuration
    3. CxDx interface version
    4. COMMSW swich on dealing with wildcard type parameter 
    SET COMMSW:SWID=22,SWBIT=25,SW=0; 

  • Q:ZXWN CG- The billing resource SPU online failed

    A: When debugging the CG server, it was failed to online the resource SPU in the CG1 after add the resource SPU. The relation of resources as follows.
     1.    In CG1 it is found that VCS start /export/home/omc/zxhome/omcboot/omcstart timeout as user omc by viewing the engine_A.log. the log as follows: 
    2. It is possible that there is no access to excuse omcstart file. List the access of the omcstart file and it is found there is no problem about the access of the omcstart file.  After delete the user and group of omc, re-install the CG server software, the fault still exit. 
    3.    By executing the omcstart file manually as user omc, the nms and s10spu process can not be started. But executing the omcstart as user root, the nms and s10spu process can be started normally. So the reason of the fault may be the access of omc . 
    4.    By executing s10dog and s10spu process as user omc, it is found the /tmp/watchdog.lck and /tmp/spu.lck have been running. 
     5.    By checking the access of the .lck file in the /tmp, it is found access of .lck file is belongs to user root. After delete the .lck files as user root, and restart the omcstart process as user omc, the resource of SPU can be online normally. 
      When execute /export/home/omc/zxhome/omcboot/omcstart to start the nms and s10spu, the CG server program will create the .lck file in /tmp. If there is someone to execute the omcstart process by user root, the .lck file that belongs to user root would be created. So after that, when VCS start the resource of SPU as user omc, the resource of SPU can not be online normally because of the access of the .lck file.

  • Q:ZXWN SGSN-TAU faiulre between 3G ZTE SGSN and Huawei 4G MME

    A: inter-MME combined TAU(UE identity can’t be derived by the network) increased yesterday with increase over combined attach requests over 41161 and inter-SGSN RAU over CRZ04 
    inter-MME combined TAU(#9 UE identity can’t be derived by the network) when users move from 3G to LTE ((LAC DEC: 33041, HEX: 8111 to TAC DEC: 41161, HEX:A0C9))
    we need to  check from which SGSN context response message with cause IMSI NOT KNOWN as following so please check this LAC DEC: 33041, HEX: 8111 from ZTE SGSNs.
    if you will enable 4G with 3G you need to check LAI code
    Accoriding to the 3GPP standard protocal ,If the LAI most significant bit is 1,That means the lai is mapped for mmegi.The 2g&3g lac is less than 8000.
    if you have LAC more than 8000 you need to open the softparameter  
    SET SOFTWARE PARAMETER:PARAID=65587,PARAVALUE=1;

  • Q:ZXWN MSCS-A Troubleshooting Case of Some Gateway Office SIP Interconnecting CRBT Platform

    A:The province Unicom requires of SIP way testing of gateway office interconnecting CRBT platform. After the interconnection is completed, it does not play.
    1. Contact the CRBT platform and consult. It answers that it will be OK as long as the SIP head domain’s subscription message includes the CRBT service. There is no need to front-insert the pre-fix. 
    2. Communicate with the opposite side. It explains that it is the IMS domain’s realization way. It is not applicable to the CS domain. It cannot carry this parameter in the SIP head domain. 
    3. The opposite side still identifies the CRBT service by the front insert code. The problem is solved after the modification. 
    

  • Q:ZXUN CSCF-The SCSCF answers error 503 when some VoLTE users act as the calling.

    A:1. It can be basically concluded from the above reasons that it is the calling color printing problem. The service is not commissioned formally. It is not tested. 
    2.This problem occurs on part users. Analyze the other users and it finds that all of them subscribe the calling color printing service. It is concluded that the problem is the calling color printing. 
    3. Check configuration data of the calling color printing service. It finds that the SIFC data configuration is incorrect of the calling color printing. It configures a temporary host name. 
    4. The service is not commissioned formally. But the service support system commissions the services of part users. This causes that the SCSCF returns error 503 when these users act as the calling. The calling falls back. 
    5. Communicate with the customer. There are two solutions. One is to cancel the calling color printing service of these users. Another method is to modify the calling color print data on the SCSCF. 
    6. Modify the host name of the calling color printing’s SIFC data under the authorization of the customer. Test again. The problem is solved. 
    

  • Q:ZXWN MSCS-How to Check the problem about play announcement

    A:The target for resolving basic announcement issue. In a test call that we dial a number and get release immediately without announcement.In fact it should be play announcement:“You seem to have dialled an incorrect number. Please check the number and call back”。
    1. After check the document about announcement,We know that this announcement TONEID=102,So we can used “SHOW TONEID”check the config about this announcement: 
    2.Next we should  check this announcement is play OK or NOT.We can used“ADD TPDNAL”:,For example we define “1234567”,Call Service Type is “STONE”,Number Analysis Result1 is TONEID “102”. 
    3. In the window of Signaling Trace put “Ctrl+Alt+0”,Enter the “Inner signaling trace” In the result of the Inner signaling trace,There are have message of “CM_GETFAILTONE”: 
    4.From the Inner signaling trace we can know the reason of play announcement fail is that MSC can not get the ToneID=102,But MSC only get ToneID=0.SO we will check others config. 
    5.SHOW tone service,result: 
    6.From above “Inner signaling trace” FailType=31,FailCode=1052,Check  “FAILCD” and find out the Playing Code: 
    7.In the FAILCD the Playing Code for” FailType=31,FailCode=1052” is “0”, From that about this problem we can clear know the reason, Changed the Playing Code for” FailType=31,FailCode=1052” to 2028.Then “SYN”,and test is OK.   

  • Q:ZXUN xGW-Method to delete the useless version files in MPU slave board

    A:In one XGW,there was alarm 400130 "The usage of a hard disk partition on the board exceeds the threshold".
    And the harddisk usage of slave MPU was more than 90%.
    Active MPU can be accessed from FTP.
    But as to slave MPU, it is necessary to telnet from standby port.
    1. Connect one ethernet cable to the "stdy eth" port of active MPU. 
    2. Configure the laptop's ethernet port to IP 168.0.31.99/8.
    3. telnet 168.0.31.9, username: zte, password: zte.
    4. enter the folder "verset" to delete the useless version file.
    

  • Q:ZXUN SSS- CDR issue of Called number IN service

    A:A call B user, B user subscribes the called side inap IN service. SSS send IDP, "connect" that  inap IN respond  contains the destination routing number and the initial called number, or only the destination routing number.
    When there is only redirected number in connect, only think that IN network happen forwarding, in accordance with the forward business processing.
    Check the "Compatible process on SCP" of Called side IN service key configuration as shown, the switch is open. 
    Turn off this switch and  the issue is fixed. 

  • Q:ZXUN xGW-Null ULI in PGW CDRs

    A:If a subscriber hands over too fast, the CDR on PGW may have a null ULI field. Related scenarios include the following: 
    1. 12:51:27-12:51:29: When the subscriber is in the 4G network, the CDR causeForRecClosing=22(rATChange) is generated, which carries ULI. 
    2. 12:51:29-12:51:30: When the subscriber returns to the 3G network, the CDR causeForRecClosing=18(servingNodeChange) is generated, which carries ULI. 
    3. 12:51:30-12:51:31: When the subscriber returns to the 4G network, the CDR causeForRecClosing=22(rATChange is generated, without ULI. 
     In case of 4G-to-3G handover, the SGSN sends the RAU Accept message to the handset, and the subscriber returns to the 4G network before the handset receives this message. Thus, the 4G network considers that the subscriber does not experience handover and only the TAU flow is initiated. As a result, the 4G CDR type is EUTRAN and the ULI field does not carry any parameters. The detailed process is as follows: 
    1. Modify software parameter. 
    2. Use the related hotfix to upgrade the version. 
    

  • Q:Tulip Elastic Cloud System-Install TECS show "OS installation is successful, TECS installation failure"

    A:Virtualization E9000 failure when the underlying installation deployment TECS, prompt "OS installation is successful, TECS installation failure" 
    According to the prompt environment that is in the input parameters as input errors can lead to network
    Back to cluster related deployment, redo plane and network mapping related deployment, after successful installation
    The underlying tecs deployment requires many input parameters, the need to care.
    When the deployment of tecs according to the log file to find out the cause of the problem.

  • Q:Tulip Elastic Cloud System-Disk array using access vdirector test without a solution

    A:According to the interface error, magnetic matrix management IP address inaccessible, that is to say vdirector cannot reach the magnetic array of IP management, but after tests found on the control node can ping the address. Judging was due to other reasons.
    1 IP address unblocked inspections, first of all, found that can reach the address. Routing is correct. 
    2, eliminate address questions, start screening on the magnetic array configuration. Found after foxconn magnetic array configuration in section 3.1 in the manual initialization configuration part 6 close Telnet steps, doubt is caused by the reasons, to open the service after vdirector interface test pass, problem solving.
     1, if you use a foxconn magnetic circle vdirector interface test is not passed, when stored in the access and prompt management address inaccessible, can open Telnet service in the magnetic array. 
    2, after confirmed, if you don't open Telnet service, although vdirector access tests showed not through, but no influence on the back of the operation, also can ignore this problem.
    

  • Q:ZXUN CG-Ga link breakdown alarm appeared on SGSN/GGSN frequently

    A:When we checked the SGSN alarms, found there were many Ga link breakdown alarms in history alarms.From signaling trace, there were send and receive message, seemingly the signal interaction is normal. Then we captured the signal from switch and firewall, and found many packets loss on firewall.  So we modified the topology, made the signal transfer only from switch. No packets transfer from firewall, then the Ga link breakdown alarm cleared.  
    Capture the signaling in CG Ga interface, CG response to all the received request messages from the captured signaling we also found that there were many fragment packages reassembly failed, and some fragmented packet reassembly timeout, if there were alarms when we capture the signaling, the alarm may be caused by these packages no responding, we need to capture more signaling in multipoints 
    Messages exchange between SGSN and CG should access two switchs , one firewall and one ER,  transfer path is as follow: 
    SGSN—8905 SW—firewall—ER—firewall—5950 SW—CG 
    We capture signaling on switch & firewall and analysis the signaling ,found there were some packets losed on firewall. That because the firewall is very old and process capacity is low. 
    Then we modify the transfer route between sgsn and CG, only access switch 8905 and switch 5950, Ga link breakdown alarm no longer appear. 

  • Q:ZXUN SSS-Communication Deflection Service solution of CSCF/SSS

    A:SIP terminal (in this case accesing thorugh 3GPP SBC/P-CSCF) responds an INVITE with a "302 Moved Temporarily"  to trigger a call redirection. According to the standard the new called number is gotten from the Contact header on the 302 message. This kind of call scenario is Communication Deflection Service.That means SIP terminal trigger CFx by itself this kind of CFx service is not trigger in SSS.
     During the service test , fixed these problem:
    Step 1 : S-CSCF was rejecting the call because the called number (contact) was not found in the TELANA tabkles: This should not be directly redirected by the S-CSCF, the 302 should be send to the SSS for SSS to Trigger Call Deflection Suplementary Service. TO solve this disable the S-CSCF "3xx Redirection Function" on SVCGLB.
    Step2 : On SSS the CD Suplementary Service has been registered and activated for the IMS SIP user that is sending the 302.
    Step3 : SSS was releasing the call after trigger CD service because the calling number gotten from contact header is in SIP URI format and there is no analysis in SSS for SIP URI format.  Configure SIP URI analysis in SSS for the test prefix "6" and so on.The service is working OK.

  • Q:Packet Core Network-Error messages on Fujitsu DX server log collection procedure for support

    A:Below is the procedure for gathering the logs from the Fujitsu Eternus DX60.  If the file exceeds 10 MB, as an alternative, I have included instructions to ftp the file to our gateway 
    Problem indicated there was a failure on the current hard drives in the Raid configuration
    Step1: Log into the Fujitsu ETERNUS DX60 
    Step2:Once complete you will be asked to download the files to storage device.
    Once collected, it will ask you to save the file to your laptop/desktop.
    Finish
    These are important logs required by the 3rd party vendor to recover a disk array failure, and begin troubleshooting process for recovery of either a software or hardware failure in the server.

  • Q:ZXUN uMAC-Intersystem's Handover from 3G to 4G issue

    A: When the UE handover to 4G  from 3G, the UE sends a  Relocation Required (Cause, Target eNodeB Identifier, CSG ID, CSG access mode, Source RNC Identifier, Source RNC to Target RNC Transparent Container) message to the source SGSN .SGSN has no response. the handover procedure is fail
    there are one SGSN pool and MME pool.
    1.there are three SGSN in SGSN pool, every RNC connect to SGSN pool .
    2.there are three MME on MME pool , every EnodeB connect to MME pool
    Because enodeB id have 20 bit, rnc id only have 12 bit .So when EnodeB id greater than 65535, The mapping relationship between RNC ID and EnodeB id must be configured.
    3.check the the mapping relationship between RNC ID and EnodeB id  in SGSN and MME.

  • Q:How to access ZTE's customer portal?

    A:ZTE's knowledge database is a solution database created during customer support. Many of our customers have found that they can solve their problems by searching the database.

  • Q:What is ZTE customer's portal?

    A:For any technical problem or question about ZTE's products, please contact the technical support. For any problem related to accounts, subscription or authorization, please contact the customer service center.