Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Call dropped after exactly 6min

This topic contains 8 replies, has 0 voices, and was last updated by  wallis dudhnath 5 months, 2 weeks ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #55617 Reply

    Maram

    Hi all,

    In one cell of my network, the call is dropped exactly after 6min.
    Please can any one explain me the cause ?
    Is it a problem of timer ? if yes which timer please ?

    Thanks a lot !

    #55618 Reply

    Pix

    This is a problem in the core network, not the radio network. So look in your MSC, Call Server, etc. There is certainly a timer there that prevents a user to talk more than 6minutes.

    #55619 Reply

    Maram

    But this problem is not generalized in all cells, only in one cell.
    Please Pix, a core network problem can be in only one cell ?

    #55620 Reply

    Pix

    ok, sorry, i have misread your first post.

    6 minutes in one cell ??

    I’ve never came across anything like this. All calls on this cell are released after 6 minutes, exactly, 6 minutes ? All of them ?
    What about GPRS transfers ? Can you try to do a FTP download for more than 6 minutes ?

    Well, unless you have such weird timer in the BTS, I still believe it’s a MSC issue. Maybe I’m missing something, though. Which codec are you using? AMR? If yes..
    Could you try using another codec?

    Which vendor is it?

    #55621 Reply

    Maram

    Hi pix,

    Yes, All calls on this cell are released after exactly 6 minutes.

    We d’ont use AMR codec.

    Vendor is ALCATEL.

    I will try an FTP download.

    Hope we find a way to discover pb source !

    #55622 Reply

    Pix

    it’s alcatel, so i can check our database… if it’s there, i’ll tell you. But you’ll have to wait till after the weekend.

    #55623 Reply

    Maram

    Hi Pix,

    The pb seems generalized in all cells swapped recently from a G2 BSC to an MX BSC !!!!

    #55624 Reply

    Rash

    CAMEL roaming
    I want to know what is the standred in this case in 3GPP;

    When receiving an InitialDP message with the Event Type Bcsm “collectedInfo” (TDP-2), the SCP differentiates an InitialDP for an MO call from an InitialDP for an MF call by means of the following criteria:

    -The InitialDP for an MO call must include the parameter Called Party BCD Number.

    -When recognizing an InitialDP message for an MO call, the SCP uses the LocationInformation/vlr-number or MSC number parameter in the InitialDP for identifying the calling subscriber’s serving network and reply??

    in case the vlr number equal to MSC number , we don’t face any problem, but in case the vlr number is not equal MSC number we face a problem that we don’t reply to the MSC.

    we must care about vlr number or MSC number. do you have any idea about this or how we can fix this problem.

    #55625 Reply

    wallis dudhnath

    A number of parameters are conveyed with the InitialDP:-

    locationInformation:

    This parameter indicates the whereabouts of the Mobile Customer, and the age of the information defining the whereabouts

    mscAddress:

    This parameter gives the mscId assigned to the GMSC/MSC. Generally, it aligns with the VLR, i.e. MSC/VLR (SSF/gsmSSF).

    Align the MSC/VLR configuration.

Viewing 9 posts - 1 through 9 (of 9 total)
Reply To: Call dropped after exactly 6min
Your information:




<a href="" title="" rel="" target=""> <blockquote cite=""> <code> <pre> <em> <strong> <del datetime=""> <ul> <ol start=""> <li> <img src="" border="" alt="" height="" width="">