Generic selectors
Exact matches only
Search in title
Search in content

Co-BCCH/TCH + co-BSIC

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #64418 Reply
    JZ
    Guest

    A network is running baseband hopping (BCCH included) with SDCCH allocated on TCH. Consider two nearby cells: BCCH1=TCH2 and BSIC1=BSIC2. Problems with SDCCH timeouts are encountered and they go away when BSIC1 or BSIC2 is changed.

    I don’t have explanation for this. BSIC is broadcast on BCCH and only co-BCCH/co-BSIC reuse should be relevant. Can anyone comment potential co-BCCH/TCH + co-BSIC reuse? Where could problems be coming from?
    Thank you in advance.

    #64419 Reply
    Mustaff
    Guest

    Dear JZ,
    In baseband hopping Co-Bcch/TCH will create a problem since our dedicated timeslot hops in between BCCH and all TCH channels available.

    Even with different Bsic, using co-bcch/tch can create a problem.

    Best Regards;

    #64420 Reply
    pix
    Guest

    indeed, when a MS goes to the cell n2 by doing a Incoming HO, a HO ACCESS is sent to TCH(n2) with BSIC(n2)
    will be understood as a CHANNEL REQUEST on BCCH(n1) with BSIC(n1) = BSIC(n2)

    This will happen because the TCH(n2), on the TS4 -let’s say-, is scheduled at the same time as the TS0 of TRX1 of the cell n2. The 2 cells are not synchronized. When MS sends HO ACCESS to TS4 of n2, it will also be heard in cell n1, in the TS0.

    Regards
    pix

    #64421 Reply
    MF
    Guest

    Dear JZ,
    in dedicate mode, channel number(ARFCN) is important for both MS and BSC. it is not important if the serving channel is bcch or tch. in any case it will suffer interference.

    #64422 Reply
    pix
    Guest

    hi mf,
    we’re talking about sdcch timeouts 🙂

    #64423 Reply
    JZ
    Guest

    Pix,
    Thank you very much, makes perfect sense.

    Can you comment on anything vendor-specific that could help? For example, better error coding on the message ID, so HO_Access is not misinterpreted as Channel_Request? In other words, would you expect this effect to depend on equipment vendor?

    Thank you in advance

    #64424 Reply
    pix
    Guest

    jz,

    no, all those air-interface protocols are fully described and full frozen in the 3GPP (because they are ms-dependent)

    I can give you two solutions :
    – don’t do handovers (…)

    – *more seriously, i promise* optimize the rach_ta_filter in n1 : the ho access from n2 arrives at random toa (time of advance) in the cell n1, because the 2 cells are not sync. The TOA here does not indicate the distance between MS and the n1, it is just a random value. For n2, of course, it represents the distance MS to n2.

    By setting rach ta filter(n1) = 32 instead of 64 (limiting the call setup coverage at 18km instead of 36km, which sounds reasonnable in an urban environment), you will reject 50% of the HO ACCESS.

    Not a bad solution, considering it is only 8am 🙂

    Regards
    pix

    #64425 Reply
    pix
    Guest

    “you will reject 50% of the HO ACCESS” , i am talking about ho access from MS doing incoming HO to n2.
    … and more generally, all “ghost” ho access that are heard on bcch(n1)/bsic(n1).

    #64426 Reply
    JZ
    Guest

    Pix,
    Actually excellent solution regardless of time od day :).

    Thank you!

    JZ

Viewing 9 posts - 1 through 9 (of 9 total)
Reply To: Reply #64422 in Co-BCCH/TCH + co-BSIC
Your information:




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