Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

Tch Failure in common bcch

  • This topic has 15 replies, 1 voice, and was last updated 15 years ago by pix.
Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #55209
    Rachid
    Guest

    we implement a common bcch feature in one site ( gsm900+dcs1800) and we got some problem with tch allocation failure during call& HO which register a huge degradation.
    what could be the reason?
    also is it possible to make a HO from a cell 900 of one segment to cell 1800 of another segment.
    thanks

    #55210
    Evgen
    Guest

    Hi Rachid.
    For TCH reselection beetwen segments responsible HOC parameters LAR(NON BCCH LAYER ACCESS THRESHOLD) ,LER (NON BCCH LAYER EXIT THRESHOLD), and BTS parameter NBL (NON BCCH LAYER OFFSET). Usually LAR=-85, LER=-95, NBL=5,7. Also parameter NBL must be set only for non-BCCH segment layer, because in other case you will have 99% RACH reject on cell. For GPRS reselection between segmentson Common BCCH need tune GPU & GPL parameters.
    Good luck.

    #55211
    cpes
    Guest

    if with these parametrs (LAR=-85, LER=-95, NBL=5,7) you will have big tch drops, increase NBL…

    #55212
    Evgen
    Guest

    Hi cpes.
    Pls, you can explaine more deeply, which reason will for drops?
    P.S. We have small TCDR value on this segments.

    #55213
    Pix
    Guest

    Rachid,

    Could you please state your vendor ?

    The degradation could be due to the fact that all the dcs1800 resources are occupied (which is a good thing). Because all traffic is carried in this inner zone, you understand that you fully use the benefit of the DCS1800 band.

    However, the BSC will still try to push more traffic in the inner zone, which leads to incoming HO congestion : HO from outer zone or from neighbor cells towards the inner zone cannot be done because no resources are available.

    This is not a problem 🙂 You have two possibilities :
    1/ share the traffic equally between GSM900 zone and DCS1800 zone. Bad option in my opinion, because you should load the inner zone as much as possible.
    2/ stop watching the (HO + normal assignment) congestion rate, but watch only the (normal assignment) congestion rate. You will have a much better view of what is the real QoS in this cell.

    Regards,
    pix

    #55214
    Rachid
    Guest

    Hi Pix;
    my vendor is Nokia.
    just one thing, there is no tch blocking in that segment. but high Tch Activation Failure either in Assignment or Handover.

    Thanks

    #55215
    Pix
    Guest

    Thx for the details rachid,

    Well, I’m not a nokia expert, but perhaps you should check your parameters : it’s possible that you push MS too much in the inner segment ? MS will suffer poor RXLEV, and fail to seize the TCH.

    Second possibility, which happen a lot in case of dualband cells : swap feeders… the inner segment of cell A is actually transmitting on the antenna of cell B…

    Other than that, I leave it to nokia experts 🙂

    Regards,
    pix

    #55216
    Hi All,
    Guest

    I have also faced this problem in my network and i found that there were some implementaion issues like,

    1) If u r not using a dual band antenna, then there may be possibility that the 2 GSM (900 & 1800) may be facing in a different dxn or may installed in a diffrent cell.

    2)And, there may be a swap.

    FYI, we are using LAR=-80, LER=-95 & NBL=5.

    #55217
    Rex
    Guest

    Hi,
    we have a pb, High Incomming HO congestion in some cells. Cells have enough free resources. RTCH_assign_congestion_rate is low. Nb of Inc_HO_requests is not high. How could be congestion if there are free resources? Vendor-Alcatel. What could be wrong? Parameters, timers …
    Please help!

    #55218
    Pix
    Guest

    I can help !

    Are those cells concentric cells ? Or Multiband cells ?

    #55219
    Rex
    Guest

    They are not concentric nor multiband. Frequency hopping-SFH. We are using P-GSM and E-GSM. First and second TRX in P-GSM, the others E-GSM.
    Regards,

    #55220
    Pix
    Guest

    Hi Rex,

    In which release are you ?
    There might be a problem in the frequency band allocation.. MS are not G1 and the only TS left are in TRX using a G1 freq. ? That sounds weird… because you’d see normal assignment congestion as well.

    If you know your indicators well enough you can give me the values for the indics below… But please reply with the full RNO indicator name 🙂

    at busy hour only:

    *in family RTCH Handover
    TCH Handover congestion rate
    Number of TCH Handover Requests

    *in family RTCH Assignment
    TCH Normal assignment congestion rate
    Number of TCH Normal Assign Requests

    * in family RTCH Traffic and Resources > Traffic
    TCH erlang, TCH capacity (static)

    * in family Traffic Model (or something like this)
    Look for something that give the ratio of MS that can support the G1 band. I’m not sure it exists… 🙂

    Now, per TRX, still at the same hour:
    number of incoming HO requests, number of TCH normal assignment requests, TCH erlang

    Then, per adjacency. Let’s say you’re looking at cell A which is HO incoming congested.
    Select all adjacencies from cell A to its neighbors, and right-click / add reverse adjacencies.
    Select all indicators located in the family “MATRIX” : Request, Allocated (or attempt?? I forgot) and Success

    If you prefer, send me an excel report (or several) at this email pix_erlang at yahoo dot com.

    Cheers,
    Pix

    #55221
    Rex
    Guest

    Hi Pix,
    I appreciate your help. As soon as I prepare the excel file I’ll send to your e-mail.
    Thanks again.

    #55222
    Rex
    Guest

    Hi Pix,
    I’ve sent you an e-mail regarding HO_incoming_congestion.
    BR

    #55223
    pix
    Guest

    i didn’t receive anything.

Viewing 15 posts - 1 through 15 (of 16 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.