1. Trang chủ
  2. » Kỹ Thuật - Công Nghệ

LTE handover multi cell measurement

20 4 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề LTE HandOver Multi Cell Measurement
Chuyên ngành Wireless Communications
Thể loại article
Năm xuất bản 2021
Định dạng
Số trang 20
Dung lượng 873,27 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

This page will explain about various aspect of Measurement Process that is happening in a LTE. In any technology,Measurement is done roughly at two stage. One is measurement in Idle mode and the other one is in Connectedmode. Idle mode measurement is mainly for Cell Selection and Reslection process and most of idle modemeasurement criteria is determined by SIB messages, the connected mode measurement is mostly for Handover orCSFB and the measurement criteria is determined by specific RRC messages dedicated for a specific UE

Trang 1

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 1/20

Multi Cell - Measurement in LTE Home : www.sharetechnote.com

This page will explain about various aspect of Measurement Process that is happening in a LTE In any technology, Measurement is done roughly at two stage One is measurement in Idle mode and the other one is in Connected mode Idle mode measurement is mainly for Cell Selection and Reslection process and most of idle mode

measurement criteria is determined by SIB messages, the connected mode measurement is mostly for Handover or CSFB and the measurement criteria is determined by specific RRC messages dedicated for a specific UE

This page will deal with connected mode measurement process only Idle mode measurement is not the scope of this page

In terms of RRC Message, you may say Measurement Process would be a simple one, that is,

i) eNB sends an RRC message indicating what kind of items to be measured and

ii) UE sends an RRC message that carries the result of the measurement

You're right at the high level, but you will find it very tricky if you are asked to create the RRC message with all the detailed parameters (IE : Information Elements) to trigger UE to perform the specific measurement There are so many details you need to understand

On UE protocol stack as well, implmentating the measurement process would be one of the most challenging item According to my experience, it tend to take huge time and effort to implement all sorts of measurement algorithm and take a lot of time for verification process as well

Topics on this page are as follows

LTE Measurement Report Trigger (EVENT for Measurement Report)

Measurement GAP

Measurement GAP - LTE and Legacy

Measurement GAP - LTE and NR

Layer 3 Filtering for Measurement Report

Measurement with CGI report

Example 1 > - Measuring RSRP, RSRQ for current Cell

Example 2 > - Event Based Measurement : A1, A2, A3

Example 3 > - Event Based Measurement : A5

LTE Measurement Report Trigger (EVENT for Measurement Report)

One of the most important step for Handover is Measurement Report from UE before the handover Network make a decision on whether it will let UE handover or not, based on the measurement value from UE There are many

different measurement items and many different ways to measure the signal quality of the current cell (serving cell) and target cell

Ideally a network let UE to report the signal quality (usually RSRP) of the current cell (serving cell) and target cell and set the arbitrary rule for handover But this can be too complicated and too much load on network since the network may need a multiple times of consecutive measurement result in stead of using only a single or a couple of measured signal quality value (Can you think of why only one or a couple of signal quality measurement (RSRP) would not be a good enough for this kind of decision making ?)

As a kind of solution, 3GPP defines several set of predefined set of measurement report mechanism to be performed

by UE These predefined measurement report type is called "Event" What kind of "event" a UE has to report is

specified by RRC Connection Reconfiguration message as follows (shown in red)

      +-rrcConnectionReconfiguration ::= SEQUENCE

        +-rrc-TransactionIdentifier ::= INTEGER (0 3) [0]

        +-criticalExtensions ::= CHOICE [c1]

      +-c1 ::= CHOICE [rrcConnectionReconfiguration-r8]

      +-rrcConnectionReconfiguration-r8 ::= SEQUENCE [100000]

      +-measConfig ::= SEQUENCE [01010111111] OPTIONAL:Exist

      | +-measObjectToRemoveList ::= SEQUENCE OF OPTIONAL:Omit

      | +-measObjectToAddModList ::= SEQUENCE OF SIZE(1 maxObjectId[32]) [1]

Trang 2

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 2/20

      | | +-MeasObjectToAddMod ::= SEQUENCE

      | |   +-measObjectId ::= INTEGER (1 maxObjectId[32]) [1]

      | |   +-measObject ::= CHOICE [measObjectEUTRA]

      | |     +-measObjectEUTRA ::= SEQUENCE [100000]

      | |       +-carrierFreq ::= INTEGER (0 maxEARFCN[65535]) [6300]

      | |       +-allowedMeasBandwidth ::= ENUMERATED [mbw25]

      | |       +-presenceAntennaPort1 ::= BOOLEAN [FALSE]

      | |       +-neighCellConfig ::= BIT STRING SIZE(2) [01]

      | |       +-offsetFreq ::= ENUMERATED [dB0] OPTIONAL:Exist

      | |       +-cellsToRemoveList ::= SEQUENCE OF OPTIONAL:Omit

      | |       +-cellsToAddModList ::= SEQUENCE OF OPTIONAL:Omit

      | |       +-blackCellsToRemoveList ::= SEQUENCE OF OPTIONAL:Omit

      | |       +-blackCellsToAddModList ::= SEQUENCE OF OPTIONAL:Omit

      | |       +-cellForWhichToReportCGI ::= INTEGER OPTIONAL:Omit

      | +-reportConfigToRemoveList ::= SEQUENCE OF OPTIONAL:Omit

      | +-reportConfigToAddModList ::= SEQUENCE OF SIZE(1 maxReportConfigId[32]) [1]

      | | +-ReportConfigToAddMod ::= SEQUENCE

      | |   +-reportConfigId ::= INTEGER (1 maxReportConfigId[32]) [1]

      | |     +-reportConfigEUTRA ::= SEQUENCE

      | |       +-triggerType ::= CHOICE [event]

      | |       | +-event ::= SEQUENCE

      | |       |   +-eventId ::= CHOICE [eventA3]

      | |       |   | +-eventA3 ::= SEQUENCE

      | |       |   |   +-a3-Offset ::= INTEGER (-30 30) [0]

      | |       |   |   +-reportOnLeave ::= BOOLEAN [FALSE]

      | |       |   +-hysteresis ::= INTEGER (0 30) [0]

      | |       |   +-timeToTrigger ::= ENUMERATED [ms640]

      | |       +-triggerQuantity ::= ENUMERATED [rsrp]

      | |       +-reportQuantity ::= ENUMERATED [both]

      | |       +-maxReportCells ::= INTEGER (1 maxCellReport[8]) [1]

      | |       +-reportInterval ::= ENUMERATED [ms1024]

      | |       +-reportAmount ::= ENUMERATED [r1]

Brief description you can find from 3GPP 36.331 5.5.4 Measurement report triggering is as follows You will see pretty complicated description of the exact procedure of each of these events, but if you convert those descriptions into a graphical format it would be much easier/intuitive to understand the nature of these events

Event A1 Serving becomes better than threshold

Event A2 Serving becomes worse than threshold

Event A3 Neighbour becomes offset better than serving

Event A4 Neighbour becomes better than threshold

Event A5 Serving becomes worse than threshold1 and neighbour becomes better than threshold2

Event A6 Neighbour become offset better than S Cell (This event is introduced in Release 10 for CA)

Event B1 Inter RAT neighbour becomes better than threshold

Event B1-NR NR neighbour becomes better than threshold

Event B2 Serving becomes worse than threshold1 and inter RAT neighbour becomes better thanthreshold2

Event B2-NR Serving becomes worse than threshold1 and NR neighbour becomes better than threshold2 Event C1 CSI-RS resource becomes better than threshold

Event C2 CSI-RS resource becomes offset better than reference CSI-RS resource

Event W1 WLAN becomes better than a threshold

Event W2 All WLAN inside WLAN mobility set becomes worse than threshold1 and a WLAN outside WLANmobility set becomes better than threshold2 Event W3 All WLAN inside WLAN mobility set becomes worse than a threshold

Event V1 The channel busy ratio is above a threshold

Event V2 The channel busy ratio is below a threshold

Event H1 The Aerial UE height is above a threshold

Event H2 The channel busy ratio is below a threshold

Trang 3

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 3/20

Following is an illustration showing possible conditions triggering each of the events A1~A6 Just suppose that you become a UE and generating measurement report following along the timeline If you don't get confused, you are high quality UE :)

Simply put, Measurement Report is triggered by whether the measured value crosses (goes higher or goes lower) a certain target value The target value can be set by one of two methods One is to use threshold which is a kind of absolute value and the other one is to use Offsef value which is a kind relative value with a reference to 'something' like serving cell value However, in reality the measured value can fluctuate pretty frequently sometimes by

measurement error by UE modem and sometimes by the fluctuation of Radio channel itself In most case, the network would not be interested in such a small fluctuation and does not want to get too many measurement reports triggered

by such a small fluctuation To provent this kind of unnecessarily frequent measurement report caused by small range

of fluctuation, the parameter called 'Hysterisis' is introduced The role of Hysterysis can be illustrated as below and hope this would make sense to you

Measurement GAP

Before the handover, UE normally measure the cell power (signal quality) of the target cell and report it to the network, so that network can make a decision whether to allow UE to handover to the target cell or not

It is not a big issue to measure the signal quality of the target cell if the target cell is at the same frequency as the current cell (Intrafrequency measurement) But there would be an issue when the target cell is at a different frequency from the current cell (Interfrequency measurement) Just in terms of logical sense of view, the simplest solution for Interfrequency measurement, the simplest solution for this would be to implement two RF tranciever on UE However, there are some practical problems with this kind of two tranciever solution One of the problems is cost issue It would require additional cost to implement the additional tranciever The other problem would be the possible interference between the current frequency and target frequency especially when the current frequency and target frequency are close to each other

 

So they come out with a special techique called "Measurement GAP" This is the same concept as

"Compressed Mode" in UMTS. The idea of the Measurement GAP is to create a small gap during which no

Trang 4

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 4/20

transmission and reception happens since there is no signal transmission and reception during the gap, UE can switch to the target cell and perform the signal quality measurement and come back to the current cell

To make this work seamlessly, there should be a well established agreement between UE and Network about the gap definition (e.g, Starting Position of the Gap, Gap length, number of Gaps etc) and this agreement is established by MeasGapConfig IE of RRC Connection Reconfiguration message

Measurement GAP for LTE and Legacy (UTRAN, GRAN etc)

If you see this part, RRC contents is small but you need to go through several steps as followsto fully understand the implementation of the measurement GAP (The spreadsheet shown at the bottom is here Let me know if you find any problem with this spreadsheet)

One of the complications about the measurement GAP would be how to schedule data transmission around the gap Situation would be more complicated than you may think because we have to think about not only the data

transmission itself, but also the scheduling grant and ACK/NACK transmission One of possible scheduling example around measurement gap is as follows

Trang 5

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 5/20

Measurement GAP for LTE and NR

As LTE evolves, we got increasing number of measurement gap definition and with the introduction of NR, this list got exploded as below

Fundamental logic of the GAP setting is same as in LTE and Legacy case as explained above Recap the procedure, it can be summarized as follows

i) Get the Gap Pattern ID from RRC MeasGapConfig and additional SMTC parameter from

ii) Get the detailed Gap Setting Parameters for the Gap Pattern from 36.133 Table 8.1.2.1-1

iii) Determine Gap Subframe based on the condition described as below

Rules may sound simple ? It may sound simple, but you would not know how complicated it is before you really try it Rehan has put a lot of his time and effort on this and completed the excel spreadsheet to show the gap settings for each subframe automatically according to the parameters you set He kindly allowed me to share the spreadsheet for readers Click here to get the file

Followings a few examples from the spreadsheet

NOTE : You only need to set parameters highlighted in yellow The values for grey cells are automatically derived from the vlues in yellow cells

Example 1 > MGRP = 40ms, SSB Periodicity = 20ms

Trang 6

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 6/20

Example 2 > MGRP = 40ms, SSB Periodicity = 40ms

Basically overall RRC Structure is similar to LTE/Legacy case explained above, but there are a couple of additiona flags

a shown and a lot of different gapoffset as shown below

 

 

From 36.331

Trang 7

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 7/20

MeasConfig ::= SEQUENCE {

[[

   measGapConfigPerCC-List-r14         MeasGapConfigPerCC-List-r14 OPTIONAL,

   measGapSharingConfig-r14        MeasGapSharingConfig-r14 OPTIONAL

]],

[[

]],

[[

   measGapConfigDensePRS-r15       MeasGapConfigDensePRS-r15 OPTIONAL,

   heightThreshRef-r15 CHOICE {

        release NULL,

        setup INTEGER (0 31)

} OPTIONAL Need ON

]]

}

MeasGapConfig ::= CHOICE {

release NULL,

setup SEQUENCE {

gapOffset CHOICE { gp0 INTEGER (0 39), gp1 INTEGER (0 79), .,

gp2-r14 INTEGER (0 39), gp3-r14 INTEGER (0 79), gp-ncsg0-r14 INTEGER (0 39), gp-ncsg1-r14 INTEGER (0 79), gp-ncsg2-r14 INTEGER (0 39), gp-ncsg3-r14 INTEGER (0 79), gp-nonUniform1-r14 INTEGER (0 1279), gp-nonUniform2-r14 INTEGER (0 2559), gp-nonUniform3-r14 INTEGER (0 5119), gp-nonUniform4-r14 INTEGER (0 10239), gp4-r15 INTEGER (0 19),

gp5-r15 INTEGER (0 159), gp6-r15 INTEGER (0 19), gp7-r15 INTEGER (0 39), gp8-r15 INTEGER (0 79), gp9-r15 INTEGER (0 159), gp10-r15 INTEGER (0 19), gp11-r15 INTEGER (0 159) }

}

}

 

From 38.331

MeasObjectNR ::= SEQUENCE {

smtc1        SSB-MTC OPTIONAL,

smtc2        SSB-MTC2 OPTIONAL,

}

 

SSB-MTC ::= SEQUENCE {

periodicityAndOffset CHOICE {

Trang 8

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 8/20

sf5       INTEGER (0 4), sf10        INTEGER (0 9), sf20        INTEGER (0 19), sf40        INTEGER (0 39), sf80        INTEGER (0 79), sf160       INTEGER (0 159) },

duration       ENUMERATED { sf1, sf2, sf3, sf4, sf5 }

}

 

SSB-MTC2 ::= SEQUENCE {

pci-List          SEQUENCE (SIZE (1 maxNrofPCIsPerSMTC)) OF PhysCellId OPTIONAL,

periodicity       ENUMERATED {sf5, sf10, sf20, sf40, sf80, spare3, spare2, spare1}

}

 

< 36.133 v15.3 - Table 8.1.2.1-1: Gap Pattern Configurations supported by the UE >

Trang 9

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 9/20

< 36.133 v15.3 - Table 8.1.2.1-2: Gap Pattern Configurations for UE supporting low density burst gap pattens >

Trang 10

23/5/2021 ShareTechnote

https://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html 10/20

 

Layer 3 Filtering for Measurement Report

To be honest, I've never paid attention to this parameter before, but lately I heard an apisode of a serious field

problem (too frequent handover failure) which was caused by a wrong implementation of this filter It is the motivation for me to look into this parameter

It is about the parameter for Layer 3 filtering for the measurement report value which is specified in

rrcConnectionReconfiguration as specified below (in blue)

      +-rrcConnectionReconfiguration-r8 ::= SEQUENCE [100000]

      +-measConfig ::= SEQUENCE [01010111111] OPTIONAL:Exist

      | +-measObjectToRemoveList ::= SEQUENCE OF OPTIONAL:Omit

      | +-measObjectToAddModList ::= SEQUENCE OF SIZE(1 maxObjectId[32]) [1]

      | | +-MeasObjectToAddMod ::= SEQUENCE

      | |   +-measObjectId ::= INTEGER (1 maxObjectId[32]) [1]

      | |   +-measObject ::= CHOICE [measObjectEUTRA]

      | +-reportConfigToRemoveList ::= SEQUENCE OF OPTIONAL:Omit

      | +-reportConfigToAddModList ::= SEQUENCE OF SIZE(1 maxReportConfigId[32]) [1]

      | | +-ReportConfigToAddMod ::= SEQUENCE

      | |   +-reportConfigId ::= INTEGER (1 maxReportConfigId[32]) [1]

      | |   +-reportConfig ::= CHOICE [reportConfigEUTRA]

      | |     +-reportConfigEUTRA ::= SEQUENCE

      | |       +-triggerType ::= CHOICE [event]

      | |       | +-event ::= SEQUENCE

      | |       |   +-eventId ::= CHOICE [eventA3]

      | |       |   | +-eventA3 ::= SEQUENCE

      | |       |   |   +-a3-Offset ::= INTEGER (-30 30) [0]

      | |       |   |   +-reportOnLeave ::= BOOLEAN [FALSE]

      | |       |   +-hysteresis ::= INTEGER (0 30) [0]

      | |       |   +-timeToTrigger ::= ENUMERATED [ms640]

      | |       +-triggerQuantity ::= ENUMERATED [rsrp]

      | |       +-reportQuantity ::= ENUMERATED [both]

      | |       +-maxReportCells ::= INTEGER (1 maxCellReport[8]) [1]

      | |       +-reportInterval ::= ENUMERATED [ms1024]

      | |       +-reportAmount ::= ENUMERATED [r1]

      | +-measIdToRemoveList ::= SEQUENCE OF OPTIONAL:Omit

      | +-measIdToAddModList ::= SEQUENCE OF SIZE(1 maxMeasId[32]) [1] OPTIONAL:Exist

      | | +-MeasIdToAddMod ::= SEQUENCE

      | |   +-measId ::= INTEGER (1 maxMeasId[32]) [1]

      | |   +-measObjectId ::= INTEGER (1 maxObjectId[32]) [1]

      | |   +-reportConfigId ::= INTEGER (1 maxReportConfigId[32]) [1]

      | +-quantityConfig ::= SEQUENCE [1111] OPTIONAL:Exist

      | | +-quantityConfigEUTRA ::= SEQUENCE [11] OPTIONAL:Exist

      | | | +-filterCoefficientRSRP ::= ENUMERATED [fc0] OPTIONAL:Exist

Ngày đăng: 04/12/2022, 11:26

w