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

Handover

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • 1st August 2003 at 07:03 #36228
    Neelam
    Guest

    I wanted to know what are the possible causes for a handover failure in GSM

    1st August 2003 at 08:24 #36229
    Nguyen
    Guest

    I think this is the big question which almost all operators have to face with. In my knowledge, the possible causes are:

    + Traffic congestion at the destination cell.
    + Bad planning of BSIC and frequency (included in HPLMN and adjacent PLMN)
    + Bad planning of radio coverage, that cause the ping-pong symptom.
    + The wait period set for the MS to move from the source cell to the destination cell in a handover may have been too short.
    + Other timers that related to handover (T7, T8, Tqho, T3103, T3105) have not been set properly.
    + … ;-(

    Of course there are still many causes, that are waiting for other to contribute.

    Brgds

    1st August 2003 at 09:01 #36230
    neelam
    Guest

    Thanks Nguyen
    what is the wait period of the MS and where it is defined

    1st August 2003 at 10:09 #36231
    Nguyen
    Guest

    This parameter does not belong to MS, it belongs to the BTS and can be set in the BTS database.

    This timer sets the wait period (time) for handover complete from MS on target cell.

    This timer starts when the BTS attempts to assign a channel for a handover.

    If this timer expires, the handover terminates.

    I dont know the ETSI name of this timer, and not sure whether it is the ETSI standard timer. In the Motorola BSS, this timer is named ho_complete.

    If anyone knows the ETSI name of this timer, plz let me know.

    Brgds.

    17th August 2003 at 04:59 #36232
    jjohnwongtp
    Guest

    Hi,

    I experienced this kind of situtation in some network coverage area before, we find MS can have several situtations need to check :

    1. Handover ARFCN receiving power level ?

    2. Handover ARFCN SNR ?

    3. Handover ARFCN BSIC situtaion

    If you find more handover failure statistic at some area is caused by (1), then, this means some bad coverage happen on this area, we need to check with AGC lever we use to make sure that AGC algorithm in Handset is correct, if this is a new MS design;

    if you find more handover failure statistic at some area is caused by (2), then, you need to check how many different network or ARFCN plan at that area, you also need to statistic their power level to understand any interference over the spec. of MS that MS can not handle, it mostly happen with situation there are several networks at some area with several repeater;

    18th August 2003 at 08:24 #36233
    Sharma
    Guest

    Hi All,
    There are some cause values in ETSI recommendation which describes the handover failure problem.Can anybody help me to know what does cause value 111 and other mean.I have found RR cause value 111 in layer 3 messages most of the times while doing the drive test.
    Thanks and Regards

    19th August 2003 at 09:05 #36234
    jjohnwongtp
    Guest

    HI Sharma,

    I checked with ETSI spec., I think the RR cause value 111 is
    listed below :

    │ RR cause value (octet ) │
    │ Bits │
    │ 8 7 6 5 4 3 2 1 │
    │ 0 0 0 0 0 0 0 0 Normal event │
    │ 0 0 0 0 0 0 0 1 Abnormal release, unspecified │
    │ 0 0 0 0 0 0 1 0 Abnormal release, channel │
    │ unacceptable │
    │ 0 0 0 0 0 0 1 1 Abnormal release, timer expired │
    │ 0 0 0 0 0 1 0 0 Abnormal release, no activity on │
    │ the radio path │
    │ 0 0 0 0 0 1 0 1 Preemptive release │
    │ 0 0 0 0 1 0 0 0 Handover impossible, timing advance │
    │ out of range │
    │ 0 0 0 0 1 0 0 1 Channel mode unacceptable │
    │ 0 0 0 0 1 0 1 0 Frequency not implemented │
    │ 0 1 0 0 0 0 0 1 Call already cleared │
    │ 0 1 0 1 1 1 1 1 Semantically incorrect message │
    │ 0 1 1 0 0 0 0 0 Invalid mandatory information │
    │ 0 1 1 0 0 0 0 1 Message type non-existent or not │
    │ implemented │
    │ 0 1 1 0 0 0 1 0 Message type not compatible with │
    │ protocol state │
    │ 0 1 1 0 0 1 0 0 Conditional IE error │
    │ 0 1 1 0 0 1 0 1 No cell allocation available │
    │ 0 1 1 0 1 1 1 1 Protocol error unspecified │
    │ │

    This means it is the Protocol error unspecified, this means a HANDOVER FAILURE message with RR cause value 111 is a scenario bug in MS, pls. list your MS message scenario for this HANDOVER FAILURE case;

    19th August 2003 at 09:09 #36235
    jjohnwongtp
    Guest

    Hi Sharma

    This RR cause value 111 could means that MS with some response scenario is incorrect to Network side, so network response with HANDOVER FAILURE with RR Cause value 111;

    Which network does you test for this case ? where are the location you tested ?

    20th August 2003 at 07:41 #36236
    Sharma
    Guest

    Hi jjohnwongtp
    Thanx.Will u pl let me know what do u mean by wrong response scenario.And what does

    0 1 0 1 1 1 1 1 Semantically incorrect message
    signify??

    I found this problem in Delhi/Dolphine network.

    Thanks and Regards

    29th March 2019 at 14:15 #36237
    Agume Alex
    Guest

    What is the meaning of this L3 message

    RR-MSG
    0> 00 00000000 T
    ..ulDcch-info
    1> 28 00101000 ….msg-type:0x28 (40)
    2> 03 00000011 L
    ….rrmsgcontent
    ……choice-by-protocol-discriminator
    3> 06 —-0110 T
    ……..radio-resource-management-messages
    0000—- ……….skip-

    indicator:0x0 (0)
    ……….choice
    4> 28 00101— T
    …………handover-messages
    …………..choice
    —–000 T
    …………….handover-failure
    5> 6F 01101111 ………………rr-cause:protocol-error-unspecified (111)

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