as) United States
`a2) Patent Application Publication 10) Pub. No.: US 2008/0056198 A1
`(43) Pub. Date: Mar.6, 2008
`
`Charpentieret al.
`
`US 20080056198A1
`
`(54)
`
`(75)
`
`ANONYMOUS UPLINK MEASUREMENT
`REPORT IN A WIRELESS
`COMMUNICATION SYSTEM
`
`Inventors: Frederic Charpentier, Berlin (DE);
`Joachim Lohr, Darmstadt (DE);
`Dragan Petrovic, Darmstadt (DE)
`
`Correspondence Address:
`STEVENS, DAVIS, MILLER & MOSHER, LLP
`1615 L. STREET N.W.
`SUITE 850
`
`WASHINGTON, DC 20036 (US)
`
`(73)
`
`Assignee: MATSUSHITA ELECTRIC INDUS-
`TRIAL CO., LTD., OSAKA (JP)
`
`(21)
`
`Appl. No.:
`
`11/575,935
`
`(22)
`
`PCTFiled:
`
`Sep. 22, 2005
`
`(86)
`
`PCT No.:
`
`PCT/EP05/10285
`
`§ 371(¢)(),
`(2), (4) Date: Oct. 4, 2007
`
`(30)
`
`Foreign Application Priority Data
`
`Sep. 27, 2004
`
`(EP) once testes seeeesees 04022975.9
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`(2006.01)
`H04Q 7/38
`(52) US. C1. oe eeessse ssn csnesnesnesnesneensesnesneaneaee 370/332
`
`(57)
`
`ABSTRACT
`
`In a mobile terminal of a wireless communication system,
`such as UMTSor any future communication system, the
`actual reception quality of data received on a broadcast
`channel, such as BCCH or MTCH,is measured. Based on
`the measurementresult, a report is prepared and sent to a
`radio network controller, which controls the transmission on
`the broadcast channel. The report does not contain the
`identifier of the mobile terminal. Therefore the reporting can
`be accomplished without informing the radio network con-
`troller about the identity of the mobile terminal.
`
`
`
`Selective Combiner inspects RLC SN|
`ofRLC PDUs each MACentity
`delivers
`
`
`
`
`
`
`
`
`
`
`Signalsfrom t
`
`serving cell
`
`Signalsfrom the target cell
`
`APPLE 1008
`
`1
`
`APPLE 1008
`
`

`

`Patent Application Publication Mar. 6, 2008 Sheet 1 of 8
`
`US 2008/0056198 Al
`
`eel
`th
`S
`——__-s+—— i_
`e
`»Y
`Y
`9
`&
`&
`e
`q 2 gs
`a
`=
`A
`qj
`a
`088 o
`Be
`8
`8 FeAas
`
`28
`gp
`
`non
`S
`
`=c
`
`h
`
`
`
`U-planeinformation
`
`C-plane
`
`109
`
`108
`
`at
`TTe
`
`Ht
`
`signalling
`
`2
`
`

`

`Patent Application Publication Mar. 6,2008 Sheet 2 of 8
`
`|tion}
`
`ndsDOTYnas91HYAIYA
`
`Ajqurasseo1i
`
`NdJeXe7]
`
`LOé
`
`sey6i}Y} Add49427
`
`
`JaysJoke"s8ubip
`
`
`
`
`
`UoTPEUusye2ou09~~“s~9WOTe}UOUIGeeejuewBesnaso1uQualedsueq-uou)Od71
`
`US 2008/0056198 A1
`
`
`
`eee
`
`NasOVW.SW2)
`
`LOG{|Guesedsuen)
`
`GOL
`
`vOl
`
`WH
`Lol
`
`3
`
`
`
`

`

`Patent Application Publication Mar. 6,2008 Sheet 3 of 8
`
`US 2008/0056198 A1
`
`¢B14
`
`LO¢
`
`Spo!PeyeuuodNVYLN
`
`HOd1189
`
`
`
`Hoa189
`
`
`QuyYsIqeIsa=OyYeseejeyOYiesOudeseajey
`ucyj9euu0y«=uaaaUUNDg«=—«-_-uonssuu04HOHSULIOD
`
`
`
`SpoSIPI|aw“oN
`
`
`
`
`
`4
`
`
`

`

`Patent Application Publication Mar. 6, 2008 Sheet 4 of 8
`
`US 2008/0056198 A1
`
`an
`
`ems>us:dA
`
`PENNS<YIS:UMOT
`
`pogcuuce#4OFHd]10
`
`
`
`(umop/dn)puewiesOd1
`
`rf
`
`GOV
`
`yess}AenD
`
`
`
`§e6ie}wSTEHOD
`
`
`
`(4414HOUL)
`
`(°@vag)3=Perhrg
`Jesu1077co
`
`
`LeOddYLNAWSAYNSVAN-OuY
`
`
`
`dANLSSYINVISOIGVY“OUN
`
`
`7S]synsespeunseawAyenzy
`(aye1s0n09ATS)J=“=yaTd
`
`c0¥
`
`Ov
`
`y°5i4
`
`
`
`
`
`ANSWDISSY8V8-dVNVY
`
`.Lsano3aw
`
`sayNquyeSor
`
`
`
`(eyesJOSNGS)
`
`LOv
`
`5
`
`
`
`
`

`

`Patent Application Publication Mar. 6,2008 Sheet 5 of 8
`
`US 2008/0056198 A1
`
`
`
`
`
`NSOTYspedsuyJourquiogsansayes
`
`
`
`ATGQVYoeesnddDTAJO
`
`SISATIOP
`
`C°
`614
`
`1129taBADIay}wWO4fSJOUBIS
`
`
`
`
`122SuldsasayywotfSIDUSIS
`
`6
`
`
`
`

`

`Patent Application Publication Mar. 6, 2008 Sheet 6 of 8
`
`US 2008/0056198 A1
`
`
`
`RRC CONNECTION REQUEST
`
`
`
`RRC CONNECTION SETUP
`
`
`
`
`RRC CONNECTION SETUP COMPLETE
`
`Fig.6
`
` RRC QUALITY REPORT
`
`Fig./
`
`7
`
`

`

`Patent Application Publication Mar. 6, 2008 Sheet 7 of 8
`
`US 2008/0056198 A1
`
`805
`
`403
`
`f
`
`
`[}~ 803
`Controller
`
`
`807 --L_]
`
`
`804
`
`U
`ser—
`terface
`in
`
`Storage
`means
`
`Fig.8
`
`interface
`
`Core
`network
`
`CN
`interface
`
`Controller
`
`906
`
`Receiver
`
`Receiver
`
`901
`
`905
`
`Transmitter
`interface
`
`|
`
`Transmitter
`
`Fig.9
`
`8
`
`

`

`Patent Application Publication Mar. 6, 2008 Sheet 8 of 8
`
`US 2008/0056198 A1
`
`1000
`
`Receiver
`
`Screen
`
`9
`
`

`

`US 2008/0056198 Al
`
`Mar.6, 2008
`
`ANONYMOUS UPLINK MEASUREMENT REPORT
`IN A WIRELESS COMMUNICATION SYSTEM
`
`[0001] This invention generally relates to wireless com-
`munication, and in particular to a control mechanism for the
`transmission quality of broadcast or multicast data in case of
`a wireless communication system. It applies in particular to
`MBMS(Multimedia Broadcast Multicast Service), which is
`anew UMTSfeature currently standardised for the UMTS
`release 6 within 3GPP. However, the invention is not limited
`to MBMSbut could be applied to any common channel
`broadcast
`in the downlink of a UMTS communication
`
`system or any other communication system including future
`mobile communication standards (4G).
`
`In every communication system, the control of the
`[0002]
`quality of service (QoS) has always been a widely discussed
`topic. This is particularly true for wireless communication
`systems, where the interface between transmitter and
`receiver generally causes a more or less severe deformation
`of the physical signal leading to degradation of the received
`signal quality. In order to cope with this, several methods
`have been developed. Firstly, some modulation techniques
`have been specially developed in order to match the physical
`characteristic of the transmission medium. Secondly, encod-
`ing methods are used in order to protect the message from
`interference. Finally, QoS control mechanisms enable an
`active control of the reception quality of the transmitted
`signal. The main idea of this type of techniques is that the
`receiver informs, by some means, the transmitter about the
`reception quality in order to allow the transmitter to adapt
`the transmission characteristics (e.g. transmission power)
`and meet somepredefined QoSattribute targets.
`
`[0003] This invention belongs to the last category and
`provides a new measurementreporting type that can be used
`to adapt the characteristics of a transmitted service.
`
`UMTSAir Interface Layers
`
`In order to enable data transmission over a wireless
`[0004]
`interface, 3GPP defined a set of layers and their respective
`protocols, which have the goal to provide the necessary
`services to support the pre-defined QoS (data rate, errorrate,
`priority etc) defined at the bearer setup.
`
`[0005] As shownin FIG.1, the radio interface is layered
`into three protocol layers:
`
`[0006]
`
`the physical layer (L1) 101,
`
`[0007]
`
`the data link layer (L2) 102;
`
`[0008] RRC layer (13) 103.
`
`into the following sub-layers:
`[0009] Layer 2 is split
`Medium Access Control (MAC) 104, Radio Link Control
`(RLC) 105, Packet Data Convergence Protocol (PDCP) 106
`and Broadcast/Multicast Control (BMC)107. Each layer has
`well defined functions, which are summarized in 3GPP TS
`25.301v6.0.0 “Radio Interface Protocol Architecture”.
`
`[0010] The Layer 3 and RLC layer are divided into
`Control (C-) and User (U-) planes 108 and 109. PDCP 106
`and BMC 107 exist in the U-plane 109 only. The main
`difference between control and user planeis that the control
`plane carries only control information (signalling) that is
`used by the peer entity in the receiver. The user plane on the
`other handcarries the data itself (e.g. voice).
`
`[0011] The RLC layer 105 provides in the control plane
`108 Signalling Radio Bearer (SRB) services and in the user
`plane 109 Radio Bearer (RB) services, except if the PDCP
`and BMCprotocols are used. In this case RB services are
`provided by PDCP 106 or BMC 107.
`
`[0012] The figure also shows connections 110 and 111
`between RRC 103 and MAC 104 as well as between RRC
`
`103 and L1101 providing local inter-layer control services.
`Equivalent control interfaces 112 to 114 exist between RRC
`103 and the RLC sub-layers 105, between RRC 103 and the
`PDCP sub-layers 106 and between RRC 103 and BMC
`sub-layers 107. These interfaces allow the RRC 103 to
`control the configuration of the lower layers within the same
`entity (transmission side or receiving side). Finally, the data
`transfer between the RLC 103 and the MAC sub-layer 104
`is performed thanks to logical channels and by transport
`channels between the MAC 104 andthe physical layer 101.
`
`[0013] When information is to be transmitted from one
`layer to the one immediately below, SDU (Service Data
`Unit) and PDU (Protocol Data Unit) are exchanged as
`shown in FIG. 2, which depicts a configuration where the
`MAClayer 104 is transparent and the RLC layer 105 is not
`transparent.(A layeris said to be transparent when no action
`is performed on the data it received, i.e. no header addition,
`but the layer may perform segmentation/reassembly of the
`data packets.) Starting from the top of the picture, a higher
`layer PDU 201 is received by the RLC layer 105. In case of
`a transparent PDCP layer 106, this higher layer PDU is an
`IP packet. From the RLC point of view, this packet is an
`RLC SDU 202 that may need to be segmented in order to
`match the size of the RLC SDU segment 203 configured by
`RRC. The RLC protocol adds a header 204 to each RLC
`SDU segment 203, which has a content depending on the
`mode configured by the RRC layer. Each RLC SDU segment
`203 with its header 204 forms a RLC PDU 205 that is given
`to the lowerlayer. This RLC PDUis, from a MAC layer 104
`point of view, a MAC SDU 206. As in this example, the
`MACprotocol does not perform any action on the MAC
`SDU;it transformsit directly into a MAC PDUortransport
`block 207 and transmits it directly to the physical layer 101.
`
`RLC Layer Transfer Modes
`
`[0014] The RLC sub layer has three working modes or
`transfer mode: transparent mode, un-acknowledged mode
`and acknowledged mode (TM, UM and AM). The RLC sub
`layer is defined by 3GPP in 3GPP TS 25.322v6.1.0 “Radio
`Link Control (RLC) protocol specification”, and a summary
`is given in 3GPP TS 25.301v6.0.0, cited above.
`
`Transparent Data Transfer:
`
`[0015] This service transmits upper layer PDUs without
`adding any protocol information but may perform segmen-
`tation/reassembly on the received PDUs. The transparent
`mode is mainly used for very delay-sensitive services like
`speech.
`
`[0016] The following functions are needed to support
`transparent data transfer:
`
`[0017] Segmentation and reassembly.
`
`[0018] Transfer of user data.
`
`[0019]
`
`SDU discard.
`
`10
`
`10
`
`

`

`US 2008/0056198 Al
`
`Mar.6, 2008
`
`[0020] Unacknowledged data transfer:
`
`[0021] This service transmits upper layer PDUs without
`guaranteeing delivery to the peer entity.
`
`[0022] The unacknowledged data transfer mode has the
`following characteistics:
`
`[0023] Detection of erroneous data: The RLC sub-layer
`shall deliver only those SDUsto the receiving upper
`layer that are free of transmission errors by using the
`sequence number check function.
`
`Immediate delivery: The receiving RLC sub-
`[0024]
`layer entity shall deliver a SDU to the upper layer
`receiving entity as soon as it arrives at the receiver.
`
`[0025] The unacknowledged mode is used, for example,
`for certain RRC signalling messages. Examples of user
`services are the cell broadcast service (CBS), MBMS,voice
`over IP (VoIP) and potentially HSDPA.
`
`[0026] The following functions are needed to support
`unacknowledged data transfer:
`
`[0027] Segmentation and reassembly.
`
`[0028] Concatenation.
`
`[0029] Padding.
`
`[0030] Transfer of user data.
`
`[0031] Ciphering.
`
`[0032]
`
`Sequence numbercheck.
`
`[0033]
`
`SDU discard.
`
`[0034] Acknowledged Data Transfer:
`
`[0035] This service transmits upper layer PDUs and guar-
`antees delivery to the peer entity. In case RLC is unable to
`deliver the data correctly, the RLC at the transmitting side is
`notified. For this service, both in-sequence and out-of-
`sequence delivery are supported. In many cases an upper
`layer protocol can restore the order of its PDUs. As long as
`the out-of-sequence properties of the lower layer are known
`and controlled (i.e. the upper layer protocol will not imme-
`diately request retransmission of a missing PDU) allowing
`out-of-sequence delivery can save memory space in the
`receiving RLC.
`
`[0036] The acknowledged data transfer mode has the
`following characteristics:
`
`is
`delivery
`delivery: Error-free
`[0037] Error-free
`ensured by meansof retransmission based on acknowl-
`edgment messages sent by the AM RLCentity at the
`receiver side. The receiving RLC entity delivers only
`error-free SDUsto the upper layer.
`
`shall
`[0038] Unique delivery: The RLC sub-layer
`deliver each SDU only once to the receiving upper
`layer using duplication detection function.
`
`In-sequence delivery: The RLC sub-layer shall
`[0039]
`provide support for in-order delivery of SDUs, 1e.,
`RLC sub-layer should deliver SDUsto the receiving
`upperlayer entity in the sameorderas the transmitting
`upper layer entity submits them to the RLC sub-layer.
`
`the receiving RLC entity delivers SDUs to upper layer
`in different order than submitted to RLC sublayerat the
`transmitting side.
`
`[0041] The following functions are needed to support
`acknowledged data transfer:
`
`[0042] Segmentation and reassembly.
`
`[0043] Concatenation.
`
`[0044] Padding.
`
`[0045] Transfer of user data.
`
`[0046] Error correction.
`
`[0047]
`
`In-sequence delivery of PDUs.
`
`[0048] Duplicate detection.
`
`[0049] Flow Control.
`
`[0050] Protocol error detection and recovery.
`
`[0051] Ciphering.
`
`[0052]
`
`SDU discard.
`
`QoS Control by the RLC Layer
`
`[0053] The description of the different modes of the RLC
`layer has shown that actually only the RLC AM provides
`true QoS control mechanisms. Indeed,this is the only mode
`wherethe transmitter is informedofthe correct reception of
`the RLC SDUsthanks to the acknowledgement messages.
`With these messages, the RLC AM entity at the transmitter
`side can compute the SDUerror rate and compare it with the
`Qos attribute (SDUerrorrate) set at the RB setup procedure.
`However, it is also interesting to note that the RLC AM
`entity at the receiver side has no knowledge about the QoS
`attributes and in particular about the SDUerrorrate.
`
`the SDU error rate QoS
`In the other modes,
`[0054]
`attribute has to be controlled by indirect means. One pos-
`sibility is the usage of QoS functions of upper layer proto-
`cols (e.g. TCP/IP) but this solution is rather inefficient, as
`these protocols have not been developed specially for wire-
`less systems. In UMTS, the QoS is usually controlled by
`other functions offered by lower layers like the power
`control function. This is particularly true for CS voice
`services where a TCP protocol cannot be used.
`RRC States
`
`[0055] The RRC states have been introduced in 3GPP
`specifications. They describe typical UE behaviours and
`requirements accordingto identified andclassified scenarios
`and are specified in 3GPP TS 25.331v6.23.0 “Radio
`Resource Control (RRC); Protocol specification’.
`
`[0056] The following states are specified in 3GPP
`
`[0057]
`
`Idle mode
`
`[0058] Cell_PCH
`
`[0059] URA_PCH
`
`[0060] CellFACH
`
`[0061] Cell_DCH
`
`[0040] Out-of-sequence delivery: Alternatively to in-
`sequence delivery,it shall also be possible to allow that
`
`[0062] The different RRC states and the possible transi-
`tions between them are shown in FIG.3.
`
`11
`
`

`

`US 2008/0056198 Al
`
`Mar.6, 2008
`
`[0063] The most common RRCstateis the idle mode 301,
`which occurs after power on. In this state, the UE only
`monitors the paging channel and waits for an incomingcall.
`In the following, each state is shortly described.
`
`[0064] CELL_DCHstate 302:
`
`[0065] The CELL_DCHstate 302 is characterised by
`
`[0066] A dedicated physical channelis allocated to the
`UE in the uplink and in the downlink.
`
`[0067] The UEis knownatcell level according to its
`current active set.
`
`[0068] The CELL_DCH-state is entered from the Idle
`Modethrough the setup of an RRC connection, or by
`establishing a dedicated physical channel from the
`CELL_FACHstate.
`
`[0069] CELL_FACHstate 303:
`
`[0070] The CELL_FACHstate 303 is characterised by:
`
`[0071] No dedicated physical channelis allocated to the
`UE.
`
`[0072] The UE monitors a FACH channelin the down-
`link.
`
`[0073] The UEis assigned a default common or shared
`transport channel in the uplink (e.g. RACH)that it can
`use anytime according to the access procedure for that
`transport channel.
`
`[0089]
`
`Idle state 301:
`
`[0090] The idle state 301 is characterised by:
`
`[0091] No dedicated channel is allocated to the UE.
`
`[0092] The radio access network has no knowledge
`about a UE in idle mode.It doesn’t know its existence
`nor its location.
`
`[0093] The UE monitors a PICH every DRX cycle in
`order to detect page sent by the CN.
`
`[0094] The UE monitors the BCH in order to receive
`general system information.
`
`[0095] No uplink activity is possible.
`Common Downlink Channels in FDD
`
`Several common downlink logical channels have
`[0096]
`been introduced in R99. All of them shall be broadcasted
`over the complete cell and all UEsin the cell should be able
`to receive them.
`
`[0097] The BCCH (Broadcast Common Control Channel)
`contains general system information on the configuration of
`the system as well as configuration parameters for the UEs
`that selected this network. The BCCH is mapped onto the
`BCHtransport channel. There is a one to one correspon-
`dence between BCCH and BCH.
`
`[0098] The PCCH (Paging Control Channel) andthe asso-
`ciated PICH (Paging Indicator Channel) are used to notify a
`[0074] The position of the UE is known by UTRANatcell
`UEabout a incomingcall (paging procedure). Note that the
`level according to the cell where the UE last madeacell
`PICH is not a logical channel but a physical channel. Only
`update.
`the PCCHis a real DL commonlogical channel. The paging
`procedure is performedin 2 steps. First, a message is sent on
`the PICH that forces a group of UEs, including the paged
`UE,to read the PCH. The PCHitself contains more infor-
`mation such as the full Id of the paged UE and somedetails
`about the incomingcall.
`
`[0075] CELL_PCHstate 304:
`
`[0076] The CELL_PCHstate 304 is characterised by:
`
`[0077] No dedicated physical channelis allocated to the
`UE.
`
`[0078] The UE monitors a PICH every DRX cycle in
`order to detect page sent by the CN.
`
`[0079] The UE monitors the BCH in order to receive
`general system information
`
`[0080] No uplink activity is possible.
`
`[0081] The position of the UE is known by UTRANat
`cell level according to the cell where the UE last made
`a cell update in CELL_FACHstate.
`
`[0082] URA_PCHstate 305:
`
`[0083] The URA_PCHstate is characterised by:
`
`[0084] No dedicated channelis allocated to the UE.
`
`[0085] The UE monitors a PICH every DRX cycle in
`order to detect page sent by the CN.
`
`[0086] The UE monitors the BCH in order to receive
`general system information.
`
`[0087] No uplink activity is possible.
`
`[0099] The PCCH is mapped onto the PCH transport
`channel. There is a one to one correspondence between
`PCCH and PCH.
`
`[0100] The CTCH/CCCH (CommonTraffic Channel and
`Common Control Channel) are used to transmit user and
`control information towards and from a population of UE. A
`typical example is CBS (cell broadcast service) or SMS
`where information on the cell (e.g. cell Id) or text message
`are broadcasted over the complete cell. CTCH and CCCH
`logical channels are mapped onto FACH (Forward Access
`Channel), which may also transmit dedicated logical chan-
`nels such as DICH or DCCH (Dedicated Traffic Channel
`and Dedicated Control Channel).
`
`[0101] One common characteristic of all transport chan-
`nels (FACH, PCH, BCH)carrying logical channels to be
`broadcast over the complete cell is that they are not power
`controlled and mechanisms have been defined to report the
`reception quality at the UE such as for example the transport
`channel BLER.
`
`[0088] The location of the UE is known at the UTRAN
`Registration area level according to the URA assigned
`to the UE during the last URA update in CELL_FACH
`state.
`
`[0102] There is a need for a new reporting type which
`could be used to adapt the transmission parameters (trans-
`mission power, coderate) by collecting a significant number
`of such quality reports by the RNC for a particularcell.
`
`12
`
`12
`
`

`

`US 2008/0056198 Al
`
`Mar.6, 2008
`
`Power Control of Dedicated Channel in FDD
`
`[0103] A graphical description of the power control can be
`found in FIG. 4. In FDD, dedicated channels (DPCH) are
`power controlled in the uplink and in the downlink in order
`to compensate the fluctuations of the received power of
`dedicated channel due to fast and slow fading. After receiv-
`ing from the CN 401 the parameters of the RAB to be
`established and in particular
`its QoS attributes
`(RAB
`ASSIGNMENT REQUESTmessageas defined in 3GPP TS
`25.413v6.2.05.9.0 “UTRAN lu interface RANAPsignal-
`ling’’), the RRC entity in the RNC 402 estimates the trans-
`port channel block error rate target (TRCH BLERtarget) for
`the DPCH that will carry the established RAB andsignals
`this value to the peer RRCentity in the UE 403 during an RB
`setup procedure.
`
`[0104] The TrCH BLERtargetis used as a reference value
`by the RRC entity in the UE 403 and, thanks to an imple-
`mentation dependent function, computes the corresponding
`SIR_target of the physical channel carrying this transport
`channel. The UE 403 measures the SIR of the DL physical
`channel to be controlled 404 and comparesthe results of this
`measurement with the computed target value in order to
`generate the appropriate TPC command 405 (up or down)
`that is transmitted in the uplink. Finally a quality measure-
`ment report can be sent by the UE 403 to the network with
`a RRC MEASUREMENT REPORTin order to inform the
`
`RNC 402 on the achieved transport BLER.
`
`[0105] Here again it can be noted that the UE is not
`informed about the actual value of the QoSattribute set by
`the CN 401. It further requires two mapping functions,
`which, if they occur to be inaccurate, may have a negative
`impact on the actual QoS experienced by the end user.
`
`Summary of the Different Types of Reporting for QoS
`Support.
`
`[0106] According to the previous sections and 3GPP TS
`25.331v6.23.0 “Radio Resource Control (RRC); Protocol
`specification”, 3 types of uplink signalling can be considered
`as supporting the QoS control in UMTS:
`
`[0107] TPC commandsare used by a UEin Cell_DCH
`in order to control the transmission powerof a dedi-
`cated channel at the transmission side in order to match
`
`somepredefined received powerlevel.
`
`[0108] AC NACKsignalling are used by RLC UM in
`Cell_FACH or Cell_DCH modein order to inform the
`transmitter RLC entity on the reception status of the
`RLC PDUs.
`
`[0109] As mentioned in the previous section and as
`shownin section 14.5 of 3GPP TS 25.331v6.23.0, cited
`above, the only quality measurementreport available in
`UMTSFDDis the transport channel BLER measure-
`ment. This can only be used in Cell_DCH mode.
`
`[0110] The following conclusions on the different types of
`reporting for QoS support can be drawn.
`
`(0111] Only UEsin cell_FACH and Cell_DCHare able
`to report in the uplink measurementreports.
`
`[0112] Only UEs in Cell_DCH are able to report a
`quality measurementreport.
`
`[0113] UE Measurementreports are always associated
`in some way with the identification of the source UE.
`Indeed normal measurement report messages are sent
`over DCCH (dedicated control channel), which iden-
`tifies the source UE and measurements on RACH are
`associated with a message that carries a UE identifier.
`Multimedia Broadcast Multicast Service (MBMS)
`[0114]
`Onepotential field of application for this invention
`is MBMS, which is a new 3G service currently under
`standardisation within the 3GPP standardisation body. In
`MBMS, a service (video clip, data download,etc.) is broad-
`casted over a predefined service area and is simultaneously
`received by one or many mobiles that previously subscribed
`to this service. An overview of the architecture and func-
`tional aspects of MBMSis given in 3GPP TS 23.246v6.32.0
`“MBMSArchitecture and functional description” and the
`radio aspects of MBMSare currently standardised in 3GPP
`TS 25.346v6.10.0 “Introduction of the Multimedia Broad-
`
`cast Multicast Service (MBMS) in the Radio Access Net-
`work (RAN)stage 2”. The main interest of MBMSis that the
`same information can be transmitted to several mobiles at
`the same time with a point to multipoint transmission PTM.
`Therefore the network does not need to set up dedicated
`links to each of the interested mobiles in order to transmit
`the data. Several new logical channels are currently stan-
`dardised by 3GPPin order to introduce MBMSservicesinto
`the UMTSsystem. The MTCH (MBMSTraffic Channel) is
`provided for carrying the MBMSservice data contentitself.
`If only a few UEsare interested in the broadcastservice, the
`network may rely on a normal DPDCHphysical channel
`after establishment of separate dedicated radio links (point-
`to-point
`transmission PTP) or on a S-CCPCH physical
`channel carrying a FACHtransport channel in case of PTM
`transmission towards several UEs. Finally, a new logical
`control channelis introduced. The MCCH (MBMSControl
`Channel) broadcasts the current MBMSconfiguration and
`signals MBMSspecific parameters or messages. Depending
`on the evolution of the standardisation process, more logical
`channels might be introduced in the future by 3GPP.
`
`Soft and Selective Combining
`[0115]
`In order to improvethe reception quality at the UE,
`two techniques are currently under investigation in 3GPP.
`The general principle of soft and selective combining is the
`same. Both techniques rely on the reception of the same
`information from more than one cell. Soft combining is
`similar to the well-known soft handover scenario already
`introduced in R99 of UMTS, where a UE combinesthe soft
`bits received from several cells at the physical layer pro-
`vided that the radio links from all cells are sufficiently
`synchronised in time. In the case of selective combining,the
`combining process takes place at the RLC layer. The prin-
`ciple of selective combining is shown in FIG. 5. With this
`technique, several links from several cells are received and
`each link undergoes an independentreception process up to
`the RLC layer. Therefore the RLC receives several times the
`same RLC PDUs that are identified by their sequence
`number(SN). As the different radio links are non-correlated,
`the probability of receiving correct RLC PDUs increases
`with the numberofradio links. By selecting error-ree PDUs
`from different radio links and combining them,a data stream
`with lower PDUerrorrate or error ratio may be obtained.
`{0116] A number of DL common channels (FACH, BCH,
`PCH) were introduced in 3GPP in the past. However there
`
`13
`
`13
`
`

`

`US 2008/0056198 Al
`
`Mar.6, 2008
`
`is no possibility to inform the transmitter on the reception
`quality (e.g. BLER, BER or other quality metric) of these
`channels. This
`is particularly true for UEs
`in idle,
`URA_PCHand Cell_PCH modeswhere no uplink exists. In
`these modes, the BCH and the PCH are monitored by the UE
`but a degraded reception quality cannot be signalled to the
`network.
`
`[0117] As a matter of fact, in its current state, the trans-
`mission parameters (transmission power, code rate)
`for
`BCH, PCH and FACHare not based on the actual require-
`ments and the needs of the receiving stations but there are
`some pre-defined parameters based on field measurements
`or on some empiric rules, as no quality feedback reports are
`sent from the terminals to the radio access network. More-
`over it is currently not possible to test the UE reception
`performance of the BCCH and PCCH,as these UEs have no
`uplink. For FACH reception, some special test mode (loop-
`back mode) can be used to overcome the absence of feed-
`back reports. A UE in loopback modetransmitsin the uplink
`the data received in the downlink. This allows the test
`
`equipment to compare the original signal with the received
`signal and to measure the UE reception performance.
`
`[0118] At the beginning of the standardisation of UMTS,
`the lack of UL feedback for common channels was not
`
`regarded as a critical point that couldn’t be addressed by
`turn-around solutions. Therefore no feedback mechanism
`was standardised. However with the introduction of MBMS
`
`the same issue reappears with a stronger dimension, as the
`MBMStraffic (e.g. MTCHs in case of PTM transmission,
`MCCH) will probably be carried by the FACH transport
`channel.
`
`In the current state of the MBMSstandardisation
`[0119]
`within 3GPP, no direct QoS control mechanism overthe air
`interface has been developed except the point-to-point repair
`mechanism. Howeverthe point-to-point repair mechanism is
`an application level procedure, which cannot be used to
`control transmission parameters related to the radio access
`network (transmission power, coderate, etc). As a matter of
`fact, in its current state, MBMSrelies on a “blind” trans-
`mission, where the transmission parameters are based not on
`the actual requirements and needs of the receiving stations
`but on some empiric rules, as no quality feedback reports are
`sent from the terminals to the radio access network.
`
`[0120] This Gap in the Functionality in MBMShas Two
`Major Consequences.
`
`[0121] First, no efficient adaptation of the transmission
`parameters of an MBMSsession with respect to the actual
`terminal requirements is possible. In case of an insufficient
`transmission power, most of the UEswill receive the MBMS
`services with a high error rate and,
`if allowed by the
`application layer, will require a point-to-point repair session
`in order to recover the losses. This will create significant
`traffic in the uplink and in the downlink, which will severely
`decrease the spectrum efficiency of MBMS. Moreoveras the
`point-to-point repair procedure is an application level pro-
`cedure, this will be completely transparent to the UTRAN.
`It will see this traffic as signalling messages designated for
`the application layer. Therefore the UTRAN will not be able
`to use this procedure to adapt the radio parameters to the
`actual MBMSreception quality and will certainly use again
`the same parameters if an MBMSsession with the same
`characteristics is to be transmitted.
`
`[0122] Another major problem relatedto the lack of uplink
`feedback is the limitation in the testing of MBMScapable
`UEs. In 3GPP, all main functions have to conform to the
`specifications and shall be tested in order to guarantee a
`certain quality level. MBMSshall not be an exception to this
`rule, as new features will be introduced in the lower layers
`of the UE; reception of high data rate in RRC idle mode,
`URA_PCHand cell_PCH and cell_FACH modes, MCCH
`reception, selective combining,
`inter-frequency measure-
`ment in presence of MBMS to name a few. As MBMS
`reception should be provided in all RRC states and in
`particular in RRC idle mode, a methodology should be
`derived that would enable the conformance testing of
`MBMSin this mode. As mentioned above, UEs are usually
`tested with the help of a special loop back mode, where the
`DL traffic is directly sent back in the uplink to the test
`equipmentthat is simulating the UTRAN. This enables the
`test equipment to comparethe received and processedsignal
`with the original and to easily compute test metrics such as
`the transport channel BLER. The problem with MBMSin
`idle, cell_PCH, URA_PCHandalso cell_FACHis that there
`is no uplink or only little bandwidth is available. Therefore
`it is impossible to carry the foreseen DL MBMSdata rates
`(64 kbps to 256 kbps services) in the uplink. As a matter of
`fact, there is today no possibility to test MBMS UEswith the
`current version of the specifications.
`[0123]
`In WO 2004/042963 Al, “An uplink common
`channel for sending feedback information” an uplink com-
`mon channelis used for transmitting feedback information.
`Howeverdetails of such a transmission are not specified.
`[0124] US2003/0119452 Al “Apparatus and method for
`controlling transmission power of downlink data channel in
`a mobile communication system supporting MBMS”pro-
`poses a feedback mechanism in order to control the QoS of
`an MBMStransmission. However in this application, the
`feedback reports are only composed of power commands
`that are based on an SIR measurement performed in the
`physical layer.
`[0125]
`It is therefore an object of the present invention to
`solve both issues by proposing an efficient feedback mecha-
`nism that can be used by the radio access network to adapt
`the radio transmission parameters (transmission power, code
`rate, etc.) of the transport channel carrying R99 common
`logical channel (BCCH, PCCH, CCCH, CTCH) and the
`MBMSrelated logical channels (MTCH, MCIH) and to
`enable the testing of the BCCH and PCCHreception as well
`as testing a UE with respect to the new functionalities
`introduced by MBMS.
`[0126] This object is achieved by a method according to
`claim 1, a mobile terminal according to claim 22, a radio
`network controller according to claim 24 and a test system
`according to claim 27. Advantageous embodiments are
`subject-matter of the dependent claims.
`[0127] Anew measurementreporting type in the uplink is
`disclosed where a UE receiving transport channels carrying
`commonlogical channels reports a kind of quality measure-
`ment metric to the network in an anonymousfashion. A new
`RRC procedure is proposed that may report the reception
`quality of a transport channel carrying a common logical
`channel. This RRC signalling called further herein below
`“RRC QUALITY REP