`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2008/0056198 A1
`
`(43) Pub. Date:
`Mar. 6, 2008
`Charpentier et al.
`
`(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)
`
`PCT Filed:
`
`Sep. 22, 2005
`
`PCT No.:
`
`PCT/EP05/10285
`
`(86)
`
`§ 371(c)(1):
`(2), (4) Date: Oct. 4, 2007
`
`(30)
`
`Foreign Application Priority Data
`
`Sep. 27, 2004
`
`(EP) ........................................ 040229759
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`(2006.01)
`H04Q 7/38
`(52) US. Cl.
`.............................................................. 370/332
`
`(57)
`
`ABSTRACT
`
`In a mobile terminal of a wireless communication system,
`such as UMTS or 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 measurement result, 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 Combine: inspects RLC SN
`
`ofRLC PDUs each MAC entity
`
`delivers
`
`
`
`Signalsfi'om t
`
`serving cell
`
`Signalsfi'om t e target cell
`
`SAMSUNG 1008
`
`SAMSUNG 1008
`
`1
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 1 of 8
`
`US 2008/0056198 A1
`
`[mum
`
`109
`
`
`
`U-planeinformation
`
`
`
`1B C-planesignalling
`
`101;qu
`
`111
`
`2
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 2 0f 8
`
`US 2008/0056198 A1
`
`bnfivmmde
`
`
`
`lawBx2|»04m
`
`Gowwdoumodooénoflfinofimom.o.
`
`clamHom'83m3m3
`
`Emhmamcmbéo:v
`
`we
`
`NE
`
`_._~_
`
`.I
`30m052Inow9:2..om
`EN“.acmfiamcgv.3F04%:N...
`
`I|5v2_..
`
`
`
`
`
`
`son.5%...'22:son.53..5:3:53..5:9:
`
`5N
`
`3
`
`
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 3 of 8
`
`US 2008/0056198 A1
`
`no:
`
`Sm
`
`
`
`
`
`macs.Umuomccooz<m._.3
`
`Ioml=mo
`
`:8=8
`
`
`
`
`
`0%.fizgfl0mm$8.9”.Emfififimm0mm$8.0m
`
`
`
`
`
`
`
`
`
` 202222v\4/\/5:3585:3583:02:005:00:50
`
`4
`
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 4 0f 8
`
`US 2008/0056198 A1
`
`m3
`
`
`
`twatM“RE:A«53«a.n”Exam
`
`mow
`
`
`
`$33.3!Hm.VEnummvfimnRbDag\Lmto:
`
`33:81:62.2.
`
`
`
`\L“cache2358on:
`
`hzmsgwma‘m<mu$24?“
`
`Emmadmm
`
`mwfinrflmwoo
`
`35..5:0Dnmv
`
`mammmmmfim0.92”cm:
`3&5:onwa
`
`393£55
`
`$93«mam:06
`
`
`
`
`
`PmOmm—mhszmng‘m—s—”om—m
`
`:5
`
`E.«:398539:£330
`
`imam:05
`
`mgmg
`
`é
`
`5
`
`
`
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 5 of 8
`
`US 2008/0056198 A1
`
`
`
`
`
`ZwDAMfloommfiEmma—Eon.352$
`
`3&5032:08SamDuane
`
`$3.33
`
`3:
`
`~39BEEm»Ecfiflazmmw28Maria‘NEcfiflgmfi
`
`6
`
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 6 0f 8
`
`US 2008/0056198 A1
`
`
`
`RRC CONNECTION REQUEST
`
`
`
`RRC CONNECTION SETUP
`
`
`
`
`RRC CONNECTION SETUP COMPLETE
`
`Fig.6
`
`
`
`RRC QUALITY REPORT
`
`
`
`W5?
`
`7
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 7 of 8
`
`US 2008/0056198 A1
`
`805
`
`403
`
`ser-
`
`U
`
`in
`
`terfoce
`
`/
`Controller
`
`
`[:|~803
`
`
`
`304
`
`Fig.8
`
`402
`
`903
`
`904
`
`901
`
`Transmitter
`interface
`
`Receiver
`
`interface
`
`.
`
`
`
`
`
`
`905
`
`906
`
`
`
`
`
`
`
`
`
`
`
`Core
`network
`
`CM
`interface
`
`Controller
`
`
`
`Fig.9
`
`8
`
`
`
`Patent Application Publication Mar. 6, 2008 Sheet 8 0f 8
`
`US 2008/0056198 A1
`
`1000
`/
`
`1002
`
`1003
`
`1001
`
`Receiver
`
`Controller
`
`
`
` Transmitter
`
`
`9
`
`
`
`US 2008/0056198 A1
`
`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
`a new UMTS feature currently standardised for the UMTS
`release 6 within 3GPP. However, the invention is not limited
`to MBMS but 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 some predefined QoS attribute targets.
`
`[0003] This invention belongs to the last category and
`provides a new measurement reporting type that can be used
`to adapt the characteristics of a transmitted service.
`
`UMTS Air 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, error rate,
`priority etc) defined at the bearer setup.
`
`[0005] As shown in 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 (L3) 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 plane is 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 hand carries 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 BMC protocols 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 and the 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
`MAC layer 104 is transparent and the RLC layer 105 is not
`transparent. (A layer is 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 lower layer. This RLC PDU is, from a MAC layer 104
`point of view, a MAC SDU 206. As in this example, the
`MAC protocol does not perform any action on the MAC
`SDU; it transforms it directly into a MAC PDU or transport
`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.l.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 A1
`
`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 SDUs to 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 number check.
`
`[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 means of retransmission based on acknowl-
`edgment messages sent by the AM RLC entity at the
`receiver side. The receiving RLC entity delivers only
`error-free SDUs to 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,
`i.e.,
`RLC sub-layer should deliver SDUs to the receiving
`upper layer entity in the same order as 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 sublayer at 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
`where the transmitter is informed of the correct reception of
`the RLC SDUs thanks to the acknowledgement messages.
`With these messages, the RLC AM entity at the transmitter
`side can compute the SDU error rate and compare it with the
`Qos attribute (SDU error rate) 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 SDU error rate.
`
`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 according to identified and classified scenarios
`and are specified in 3GPP TS 25.33lv6.23.0 “Radio
`Resource Control (RRC); Protocol specification”.
`
`[0056] The following states are specified in 3GPP
`
`[0057]
`
`Idle mode
`
`[0058] Ce11_PCH
`
`[0059] URA_PCH
`
`[0060] Ce11_FACH
`
`[0061] Ce11_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
`
`11
`
`
`
`US 2008/0056198 A1
`
`Mar. 6, 2008
`
`[0063] The most common RRC state is the idle mode 301,
`which occurs after power on. In this state, the UE only
`monitors the paging channel and waits for an incoming call.
`In the following, each state is shortly described.
`
`[0064] CELL_DCH state 302:
`
`[0065] The CELL_DCH state 302 is characterised by
`
`[0066] A dedicated physical channel is allocated to the
`UE in the uplink and in the downlink.
`
`[0067] The UE is known at cell level according to its
`current active set.
`
`[0068] The CELL_DCH-state is entered from the Idle
`Mode through the setup of an RRC connection, or by
`establishing a dedicated physical channel from the
`CELL_FACH state.
`
`[0069] CELL_FACH state 303:
`
`[0070] The CELL_FACH state 303 is characterised by:
`
`[0071] No dedicated physical channel is allocated to the
`UE.
`
`[0072] The UE monitors a FACH channel in the down-
`link.
`
`[0073] The UE is 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.
`
`[0074] The position of the UE is known by UTRAN at cell
`level according to the cell where the UE last made a cell
`update.
`
`[0075] CELL_PCH state 304:
`
`[0076] The CELL_PCH state 304 is characterised by:
`
`[0077] No dedicated physical channel is 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 UTRAN at
`cell level according to the cell where the UE last made
`a cell update in CELL_FACH state.
`
`[0082] URA_PCH state 305:
`
`[0083] The URA_PCH state is characterised by:
`
`[0084] No dedicated channel is 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.
`
`[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 UEs in 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
`BCH transport channel. There is a one to one correspon-
`dence between BCCH and BCH.
`
`[0098] The PCCH (Paging Control Channel) and the asso-
`ciated PICH (Paging Indicator Channel) are used to notify a
`UE about a incoming call (paging procedure). Note that the
`PICH is not a logical channel but a physical channel. Only
`the PCCH is a real DL common logical channel. The paging
`procedure is performed in 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 PCH itself contains more infor-
`mation such as the full Id of the paged UE and some details
`about the incoming call.
`
`[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 (Common Traffic 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 DTCH 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, code rate) by collecting a significant number
`of such quality reports by the RNC for a particular cell.
`
`12
`
`12
`
`
`
`US 2008/0056198 A1
`
`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 REQUEST message as defined in 3GPP TS
`25.413v6.2.05.9.0 “UTRAN lu interface RANAP signal-
`ling”), the RRC entity in the RNC 402 estimates the trans-
`port channel block error rate target (TRCH BLER target) for
`the DPCH that will carry the established RAB and signals
`this value to the peer RRC entity in the UE 403 during an RB
`setup procedure.
`
`[0104] The TrCH BLER target is 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 compares the 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 REPORT in 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 QoS attribute 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 commands are used by a UE in Cell_DCH
`in order to control the transmission power of a dedi-
`cated channel at the transmission side in order to match
`
`some predefined received power level.
`
`[0108] AC NACK signalling are used by RLC UM in
`Cell_FACH or Cell_DCH mode in order to inform the
`transmitter RLC entity on the reception status of the
`RLC PDUs.
`
`[0109] As mentioned in the previous section and as
`shown in section 14.5 of 3GPP TS 25.33lv6.23.0, cited
`above, the only quality measurement report available in
`UMTS FDD is 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 UEs in cell_FACH and Cell_DCH are able
`to report in the uplink measurement reports.
`
`[0113] UE Measurement reports 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] One potential 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 MBMS is given in 3GPP TS 23.246v6.32.0
`“MBMS Architecture and functional description” and the
`radio aspects of MBMS are 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 MBMS is 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 3GPP in order to introduce MBMS services into
`the UMTS system. The MTCH (MBMS Traffic Channel) is
`provided for carrying the MBMS service data content itself.
`If only a few UEs are interested in the broadcast service, the
`network may rely on a normal DPDCH physical channel
`after establishment of separate dedicated radio links (point-
`to-point
`transmission PTP) or on a S-CCPCH physical
`channel carrying a FACH transport channel in case of PTM
`transmission towards several UEs. Finally, a new logical
`control channel is introduced. The MCCH (MBMS Control
`Channel) broadcasts the current MBMS configuration and
`signals MBMS specific 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
`
`In order to improve the reception quality at the UE,
`[0115]
`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 combines the 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 independent reception 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 number of radio links. By selecting error-ree PDUs
`from different radio links and combining them, a data stream
`with lower PDU error rate or error ratio may be obtained.
`
`[0112] Only UEs in Cell_DCH are able to report a
`quality measurement report.
`
`[0116] A number of DL common channels (FACH, BCH,
`PCH) were introduced in 3GPP in the past. However there
`
`13
`
`13
`
`
`
`US 2008/0056198 A1
`
`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_PCH and Cell_PCH modes where 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 FACH are 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 mode transmits in 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
`MBMS traffic (e.g. MTCHs in case of PTM transmission,
`MCCH) will probably be carried by the FACH transport
`channel.
`
`In the current state of the MBMS standardisation
`[0119]
`within 3GPP, no direct QoS control mechanism over the air
`interface has been developed except the point-to-point repair
`mechanism. However the 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, code rate, etc). As a matter of
`fact, in its current state, MBMS relies 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 MBMS has Two
`Major Consequences.
`
`[0121] First, no efficient adaptation of the transmission
`parameters of an MBMS session with respect to the actual
`terminal requirements is possible. In case of an insufficient
`transmission power, most of the UEs will 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. Moreover as 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 MBMS reception quality and will certainly use again
`the same parameters if an MBMS session with the same
`characteristics is to be transmitted.
`
`[0122] Another major problem related to the lack of uplink
`feedback is the limitation in the testing of MBMS capable
`UEs. In 3GPP, all main functions have to conform to the
`specifications and shall be tested in order to guarantee a
`certain quality level. MBMS shall 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_PCH and 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
`MBMS in 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
`equipment that is simulating the UTRAN. This enables the
`test equipment to compare the received and processed signal
`with the original and to easily compute test metrics such as
`the transport channel BLER. The problem with MBMS in
`idle, cell_PCH, URA_PCH and also cell_FACH is that there
`is no uplink or only little bandwidth is available. Therefore
`it is impossible to carry the foreseen DL MBMS data rates
`(64 kbps to 256 kbps services) in the uplink. As a matter of
`fact, there is today no possibility to test MBMS UEs with the
`current version of the specifications.
`[0123]
`In WO 2004/042963 Al, “An uplink common
`channel for sending feedback information” an uplink com-
`mon channel is used for transmitting feedback information.
`However details of such a transmission are not specified.
`[0124] U82003/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 MBMS transmission. 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
`MBMS related logical channels (MTCH, MCIH) and to
`enable the testing of the BCCH and PCCH reception 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] A new measurement reporting type in the uplink is
`disclosed where a UE receiving transport channels carrying
`common logical channels reports a kind of quality measure-
`ment metric to the network in an anonymous fashion. A new
`RRC procedure is proposed that may report the reception
`quality of a transport channel carrying a c