iii iii iii i ii iii 12,1111oli!lp1111111111111111111111
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2001/0036823 Al
`Nov. 1, 2001
`Van Lieshout et al.
`(43) Pub. Date:
`
`(54) TRANSPORT OF RADIO
`NETWORK-ORIGINATED CONTROL
`INFORMATION
`
`(76)
`
`Inventors: Gert-Jan Van Lieshout, Apeldoorn
`(NL); Goran Rune, Linkoping (SE);
`Per Willars, Stockholm (SE)
`
`Correspondence Address:
`NIXON & VANDERHYE P.C.
`8th Floor
`1100 North Glebe Road
`Arlington, VA 22201-4714 (US)
`
`(21) Appl. No.:
`
`09/801,869
`
`(22) Filed:
`
`Mar. 9, 2001
`
`Related U.S. Application Data
`
`(63) Non-provisional of provisional application No.
`60/190,097, filed on Mar. 20, 2000. Non-provisional
`of provisional application No. 60/191,499, filed on
`Mar. 23, 2000.
`
`Publication Classification
`
`(51) Int. C1.7
`(52) U.S. Cl.
`
`1104M 3/00
`455/418; 455/419; 455/509;
`455/517
`
`(57)
`
`ABSTRACT
`
`In a radio access network (RAN) where information may be
`sent to a mobile radio unit using a shared radio channel
`shared by other mobile radio units, a first transport bearer is
`established between a first RAN node, e.g., a drift RNC, and
`a second RAN node, e.g., a base station, to transport data to
`be transmitted on the shared radio channel. A second trans-
`port bearer is established between the first and second RAN
`nodes to transport control information originated in the first
`RAN node that relates to the first transport bearer data. The
`first RAN node then transmits the control information over
`the second transport bearer to the second RAN node. The
`control information might include, for example, scheduling
`information known to the first RAN node because the first
`RAN node supervises scheduling of data to be transmitted
`on the shared radio channel. The control information may
`provide to the mobile radio unit information needed to
`decode the data transmitted on the shared radio channel.
`Such needed information might include, for example, a
`frame identifier, a specific radio resource like a spreading
`code, and/or an indication of how different radio resources
`associated with different connections are multiplexed on the
`shared radio channel. In one example, non-limiting embodi-
`ment, the control information includes transport format
`indication information such as transmit format combination
`indicator (TFCI) information employed in third generation
`Universal Mobile Telephone Systems (UMTS) in accor-
`dance with the 3GPP specification.
`
`
`( Transport Information
`
`)100
`
`Transport bearer request at RAN associated with UE
`
`1202
`
`104
`
`Yes
`
`i -106
`
`SRNC Schedules
`DCH and DSCH data
`
`7- 108
`
`Establish a tranport
`bearer for DCH data and
`control information, e.g.,
`TFI1 and TFI2
`
`Establish a tranport
`bearer for DSCH data
`(and possibly some control
`information)
`
`SRNC Schedules DCH data,
`and DRNC schedules
`DSCH Data
`
`Establish a tranport
`bearer between DRNC and
`BS to convey DRNC-originated
`control information, e.g., TFCI2
`
`Establish other tranport
`bearers as needed/
`desired to carry DCH
`and DSCH information
`
`Ericsson Exhibit 1013
`Page 1
`
`

`

`Patent Application Publication Nov. 1, 2001 Sheet 1 of 6
`
`US 2001/0036823 Al
`
`CCore Network
`
`(CN)
`
`12
`
`— lu Interface
`
`Radio
`Access
`Network
`(RAN)
`
`10
`
`Serving Radio
`Network Controller
`(SRNC)
`
`lur Interface
`
`13
`
`X 16
`
`Drift Radio
`Network Controller
`(DRNC)
`
`— lub Interface
`
`lub Interface
`
`Base Station
`
`BS1
`
`8
`
`20
`
`Base Station
`BS2
`
`Uu Interface
`
`Y
`
`22
`.1
`UE
`
`FIG. 1
`
`Connection Frame Number (CFN)
`
`TFI or TFCI
`
`Spare
`
`Spare Extension
`
`FIG. 2
`
`Ericsson Exhibit 1013
`Page 2
`
`

`

`TV £Z89£00400Z SI1
`
`> = Shared physical channel transporting: scheduled data
`> = Dedicated physical channel transporting: scheduled data + TFCI1 + TFCI2
`— — — 00- = Scheduled data to be transported on a shared physical channel + TFI2
`lii. = Scheduled data to be transported on a dedicated physical channel + TFI1 + TFCI2
`IIP'` = Non-scheduled data to be transported on a shared physical channel
`
`—
`
`
`
`--PO- = Scheduled data to be transported on a dedicated physical channel + TFI1
`
`= Transport bearer
`
`(1:
`
`FIG. 3
`
`Ericsson Exhibit 1013
`Page 3
`
`

`

`Patent Application Publication
`
`9 jo £ jaaqs
`
`IV £Z89£00400Z Sfl
`
`= Shared physical channel transporting: scheduled data
`= Dedicated physical channel transporting: scheduled data + TFCI1 + TFCI2
`= Scheduled data to be transported on a shared physical channel + TFI2
`= TFCI2 control info
`= Non-scheduled data to be transported on a shared physical channel
`= Scheduled data to be transported on a dedicated physical channel + TFI1
`= Transport bearer
`
`FIG. 4
`
`Ericsson Exhibit 1013
`Page 4
`
`

`

`Patent Application Publication Nov. 1, 2001 Sheet 4 of 6
`
`US 2001/0036823 Al
`
`( Transport Information
`
`_)0.1 0
`
`Transport bearer request at RAN associated with UE 7-02
`
`104
`
`Yes
`
`SRNC Schedules
`DCH and DSCH data
`
`7 -108
`
`Establish a tran port
`bearer for DCH data and
`control information, e.g.,
`TFI1 and TFI2
`
`7-110
`
`Establish a tranport
`bearer for DSCH data
`(and possibly some control
`information)
`
`FIG. 5
`
`7 -112
`
`SRNC Schedules DCH data,
`and DRNC schedules
`DSCH Data
`
`7 -114
`
`Establish a tranport
`bearer between DRNC and
`BS to convey DRNC-originated
`control information, e.g., TFCI2
`
`-116
`Establish other tranport
`bearers as needed/
`desired to carry DCH
`and DSCH information
`
`Ericsson Exhibit 1013
`Page 5
`
`

`

`Patent Application Publication
`
`9 Jo S lamIS
`
`IV £Z89£00400Z Sfl
`
`ALCAP: establishment of DCH transport bearer
`
`ALCAP: establishment of DSCH transport bearer
`
`DSCH transport bearer parameters, ..)
`(DCH transport bearer parameters,
`
`RNSAP: RL_SETUP_RESPONSE
`
`DSCH transport bearer requested, ..)
`(DCH transport bearer requested,
`
`RNSAP: RL SETUP REQUEST
`
`SRNC
`
`FIG. 6
`
`.4
`
`.4
`DRNC
`
`ALCAP: establishment of TFCI2 transport bearer
`
`ALCAP: establishment of DSCH transport bearer
`
`ALCAP: establishment of DCH transport bearer
`
`TFCI2 transport bearer parameters, . ...)
`DSCH transport bearer parameters,
`(DCH transport bearer parameters,
`
`NBAP: RLSETUP_RESPONSE
`
`TFCI2 transport bearer reqeust, . ...)
`DSCH transport bearer requested,
`(DCH transport bearer requested,
`
`NBAP: RL_SETUP_REQUEST
`
`4
`
`.41
`
`Node B
`
`Ericsson Exhibit 1013
`Page 6
`
`

`

`Patent Application Publication
`
`9 jo 9 jaaqs
`
`IV £Z89£00400Z Sfl
`
`= Shared physical channel transporting: scheduled data
`= Dedicated physical channel transporting: scheduled data + TFCI1 + TFCI2
`= Scheduled data to be transported on a shared physical channel + TFI2
`= TFCI2 control info
`= Non-scheduled data to be transported on a shared physical channel
`= Scheduled data to be transported on a dedicated physical channel + TFI1
`= Transport bearer
`
`FIG. 7
`
`Ericsson Exhibit 1013
`Page 7
`
`

`

`US 2001/0036823 Al
`
`Nov. 1, 2001
`
`1
`
`TRANSPORT OF RADIO NETWORK-ORIGINATED
`CONTROL INFORMATION
`
`RELATED APPLICATIONS
`
`[0001] This application claims priority from commonly-
`assigned U.S. Provisional Patent Application Ser. Nos.
`60/190,097 and 60/191,499, filed Mar. 20, 2000 and Mar. 23,
`2000, respectively, the entire contents of which is incorpo-
`rated herein by reference.
`
`FIELD OF THE INVENTION
`
`[0002] The present invention relates to radio access, more
`specifically, to how certain control information communi-
`cated to a mobile radio terminal can be efficiently trans-
`ported in a Radio Access Network (RAN).
`
`SUMMARY OF THE INVENTION
`
`In a radio access network (RAN) where informa-
`[0003]
`tion may be sent to a mobile radio unit using a radio channel
`shared by other mobile radio units, a first transport bearer is
`established between a first RAN node and a second RAN
`node to transport data ultimately to be transmitted on the
`shared radio channel. A second transport bearer is estab-
`lished between the first and second RAN nodes to transport
`control information originated in the first RAN node that
`relates to the first transport bearer data. The first RAN node
`then transmits the control information over the second
`transport bearer to the second RAN node.
`
`for
`include,
`information might
`[0004] The control
`example, information known to the first RAN node because
`the first RAN node supervises scheduling of data to be
`transmitted on the shared radio channel. The control infor-
`mation may provide the mobile radio unit with information
`needed to decode the data transmitted on the shared radio
`channel. Such needed information might include a frame
`identifier, a specific radio resource like a spreading code in
`a CDMA type of communication system, and/or an indica-
`tion of how different radio resources are multiplexed on the
`shared radio channel. In one example, non-limiting embodi-
`ment, the control information includes transport format
`indication information such as transmit format indicator
`(TFI) and/or transmit format combination indicator (TFCI)
`information employed in third generation (3G) Universal
`Mobile Telephone Systems (UMTS) systems in accordance
`with the 3GPP specification.
`
`In a preferred, example embodiment, the first RAN
`[0005]
`node is a drift radio network controller (DRNC), and the
`second RAN node is a base station (BS). A third transport
`bearer may be established to transport dedicated radio
`channel data and dedicated radio channel control informa-
`tion through the RAN for transmission to a mobile radio unit
`on a dedicated radio channel. This third transport bearer may
`be established by a serving radio network controller (SRNC)
`working in conjunction with the DRNC to support the
`connection with the mobile radio unit.
`
`In one example implementation of the present
`[0006]
`invention, a computer-generated data signal, (e.g., generated
`in a computer in the DRNC), is transported on a separate
`transport bearer between the DRNC and the base station
`having a particular format. A frame number field includes a
`specific frame number identifying a frame on the shared
`
`radio channel. A transport format indicator field includes
`information relating to a particular radio channel resource in
`the corresponding frame. In one example implementation,
`the transport format indicator field includes an index to a
`transport format table previously stored in the mobile radio
`unit. In other words, the index addresses particular entries in
`the look-up table so the mobile can retrieve certain infor-
`mation that will allow it to receive and decode information
`intended for that mobile radio unit on the shared radio
`channel. For example, since the DRNC is in charge of
`scheduling how data is multiplexed in a frame on the shared
`radio channel and allocating particular radio resources, such
`as channelization codes and associated spreading factors, the
`DRNC can convey to the mobile radio, using the transport
`format indicator, these types of specific details to allow the
`mobile radio unit to decode information sent over the shared
`radio channel.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0007] The objects, features, and advantages of the inven-
`tion will be apparent from the following description of the
`preferred but non-limiting example embodiment described
`in conjunction with the following drawings. The drawings
`are not necessarily to scale or comprehensive, emphasis
`instead being placed upon illustrating the principles of the
`invention.
`
`[0008] FIG. 1 is a function block diagram of a radio
`communications system in which the present invention may
`be employed;
`
`[0009] FIG. 2 is an example transport format indicator
`(TFI) signaling message;
`
`[0010] FIG. 3 is an example radio access network archi-
`tecture in which certain control information (Like TFI
`and/or TFCI messages) to be communicated to a mobile
`radio terminal is transported in the radio access network
`architecture;
`
`[0011] FIG. 4 shows an example embodiment of the
`present invention in which a transport format indicator
`originated in a DRNC is communicated from the DRNC to
`a base station over a separate transport bearer;
`
`[0012] FIG. 5 is a flowchart diagram illustrating proce-
`dures in accordance with one example implementation of the
`present invention;
`
`[0013] FIG. 6 is an example signaling procedure for
`setting up a separate transport bearer between a DRNC and
`a base station for communicating DRNC-originated control
`information; and
`
`[0014] FIG. 7 shows an example of implementation of the
`invention in a differently configured RAN.
`
`DESCRIPTION OF THE FIGURES
`
`In the following description, for purposes of expla-
`[0015]
`nation and not limitation, details are set forth pertaining to
`a specific RAN architecture, having certain interfaces, sig-
`naling, and messages, in order to provide an understanding
`of the present invention. However, it will be apparent to one
`skilled in the art that the present invention may be practiced
`in other implementations, embodiments, and contexts that
`depart from these specific details.
`
`Ericsson Exhibit 1013
`Page 8
`
`

`

`US 2001/0036823 Al
`
`Nov. 1, 2001
`
`2
`
`In some instances, detailed descriptions of well-
`[0016]
`known methods, interfaces, devices, and signaling tech-
`niques are omitted so as not to obscure the description of the
`present invention with unnecessary detail. Moreover, indi-
`vidual function blocks are shown in some of the figures.
`Those skilled in the art will appreciate that the functions may
`be implemented using individual hardware circuits, using
`software functioning in conjunction with a suitably pro-
`grammed digital microprocessor or general purpose com-
`puter, using an application specific integrated circuit
`(ASIC), and/or using one or more digital signal processors
`(DSPs).
`
`[0017] The architecture of an example Radio Access Net-
`work (RAN) 13, the interfaces between nodes in the RAN
`13, and the physical channels on the radio interface are now
`described with reference to the radio communications sys-
`tem 10 shown in FIG. 1. User Equipment (UE) 22, such as
`a mobile or fixed radio terminal, is used by a subscriber to
`access services offered by one or more core networks (CN)
`12 (only one is shown). Examples of core networks include
`the PSTN, the ISDN, the Internet, other mobile networks,
`etc. Core networks may be coupled to the radio access
`network 13 through circuit-switched and/or packet-switched
`core network service nodes like Mobile Switching Center
`(MSC) (not shown) or a Serving GPRS Support Node
`(SGSN) (not shown). The radio access network 13 typically
`includes plural Radio Network Controllers (RNCs) 14, 16.
`Each RNC controls radio connectivity with mobile terminals
`within a geographical area, e.g., one or more cells, byway of
`one or more base stations (BS) 18, 20.
`
`[0018] For each connection between a UE mobile terminal
`30 and a core network node 12, an RNC may perform one
`of two roles. As a Serving RNC (SRNC) 18, the RNC
`controls the connection with the mobile terminal within the
`RAN. Sometimes, while a connection is active, the mobile
`terminal moves to a geographical area controlled by another
`RNC. This other RNC via which the connection is routed to
`the mobile terminal is called a Drift RNC (DRNC) 16. In the
`DRNC role, the RNC supports the SRNC by supplying radio
`resources controlled by the DRNC that are needed to support
`the connection with the mobile terminal. The DRNC is
`connected to the SRNC through a logical interface labeled
`Iur. Although there is only one SRNC, there may be more
`than one DRNC involved in a mobile terminal-CN connec-
`tion, depending on any movement of the mobile terminal
`and radio environment conditions.
`
`[0019] A Base Station (BS) node (18, 20), (sometimes
`called a "Node B"), provides UE radio connectivity in one
`or more cells. Each cell covers a limited geographical area.
`A base station is coupled to and controlled by a Controlling
`RNC (CRNC). A CRNC can be an SRNC or a DRNC. The
`CRNC performs admission control for all the resources of
`the base stations it is controlling. In addition, the CRNC
`performs the scheduling of common and shared physical
`channels (as described below) on the radio interface for
`these BSs. In FIG. 1, the RNC 14 labeled "SRNC" is the
`CRNC for base station (BS1) 18. The RNC 16 labeled
`"DRNC" is the CRNC for base station (BS2) 20. A base
`station is connected to its CRNC through a logical Iub
`interface.
`
`[0020] User data is transported on logical "transport bear-
`ers" over the Iub/Iur interfaces between the different nodes
`
`in the RAN. A transport bearer typically transports one
`transport channel including user data information (an infor-
`mation stream), and possibly also control information like
`cyclic redundancy check (CRC), bit error rate (BER), trans-
`port format indicators like TFIs and/or TFCIs (described
`below), etc. Depending on the transport network used, these
`logical transport bearers may, for example, be mapped to
`actual ATM Adaptation Layer 2 (AAL2) transport connec-
`tions (in the case of an ATM-based transport network) or
`User Data Protocol (UDP) transport connections (in the case
`of an IP-based transport network).
`
`[0021] The radio interface may include two groups of
`physical radio channels:
`
`[0022] (1) dedicated physical channels (referred to as
`DCH in the 3GPP specification) and
`
`[0023] (2) shared physical channels (referred to as
`DSCH in the 3GPP specification). Dedicated physical
`channels may be used for transporting information
`between a single UE terminal and a core network and
`are not shared or used by other mobile terminals. A
`shared physical channel may be used by multiple UE
`terminals, e.g., using a multiplexing scheme such as
`code or time division multiplexing. One or more trans-
`port bearers are mapped to a physical radio channel.
`
`[0024] When a DRNC provides resources for a mobile
`terminal-core network (CN) connection, there are different
`DRNC control functions for dedicated types of physical
`channels and for shared types of physical channels. For
`dedicated physical channels, the DRNC is involved in
`admission control because it must commit DRNC resources,
`(e.g., radio resources like spreading codes in a CDMA type
`system), to support the UE terminal-CN connection. Once
`the DRNC commits some of the resources it controls to
`support the UE terminal-CN connection, the DRNC is not
`responsible for scheduling or other supervising of the physi-
`cal channel resources for that UE terminal-CN connection.
`Instead, this responsibility is handled by the SRNC. How-
`ever, the DRNC may inform the SRNC of local conditions,
`like a congestion situation in a cell, and may request the
`SRNC to change the information rate on the dedicated
`physical channel.
`
`[0025] For shared physical channels, the DRNC is again
`involved in admission control when the mobile UE terminal-
`core network (CN) connection is established, to the extent its
`DRNC resources are needed to support that connection.
`After the DRNC commits its resources to support the UE
`terminal-CN connection, however, the DRNC must perform
`one or more additional control or supervisory functions.
`Because a shared physical channel is used by multiple UE
`terminals, the DRNC—not the SRNC—performs the final
`scheduling of the resources on the shared physical channel.
`
`In the downlink (DL) direction from RAN to the
`[0026]
`UE terminal, due to the last moment resource scheduling in
`the DRNC, the UE terminal typically does not know which
`shared physical channel resources, will be used by the RAN
`for its UE terminal-CN connection at each moment in time,
`e.g., spreading codes, frame multiplex times, etc. In order to
`overcome this uncertainty, (1) the UE terminal may monitor
`continuously all shared physical channel resources to detect
`which resources are used for its connection, or (2) the RAN
`can inform the UE terminal about the common/shared
`
`Ericsson Exhibit 1013
`Page 9
`
`

`

`US 2001/0036823 Al
`
`Nov. 1, 2001
`
`3
`
`resources it is using to support that UE terminal connection
`at each point in time. For the second approach (2), the RAN
`must continuously inform the UE terminal about the shared
`physical channel resources used at each moment in time. To
`accomplish this, the RAN must send to the UE resource
`identification/allocation messages on a parallel-established,
`dedicated radio channel before the UE is to receive the
`information on the shared radio channel.
`
`[0027] Radio channel information streams are transported
`in the RAN between the SRNC and the involved BS on
`transport bearers over the Iub and Iur interfaces. A transport
`bearer transports information related to either a dedicated
`physical radio channel or a shared physical radio channel.
`The information carried on a transport bearer used for
`transporting information related to a dedicated physical
`channel passes essentially transparently through the DRNC.
`However, in diversity handover connections, the DRNC
`may perform a combining (uplink from each BS)/splitting
`(downlink to each BS) functions for this information
`because multiple base stations coupled to the DRNC are
`supporting the UE terminal-CN connection. If the DRNC
`does not need to perform such combining/splitting, e.g., the
`two BSs are under the same DRNC, the DRNC need not
`manipulate the transported information in neither the uplink
`nor downlink direction. In this case, the DRNC functions
`like a conduit or relay node.
`
`[0028] For information carried on a transport bearer relat-
`ing to shared physical channels, the DRNC must schedule
`the physical radio channel-related information received for
`different mobile terminals from one (or possibly more)
`SRNCs, i.e., multiplex different information streams onto
`the shared radio channel at different times using different
`radio resources. The goal is to optimize use of the shared
`physical channel resources on the radio interface. In addi-
`tion, the DRNC may perform a rate control function with the
`SRNC, i.e., the DRNC requests the SRNC to slow down its
`data transmission in order to avoid congestion on the shared
`physical channel.
`
`[0029] The issue is how to get this and other kinds of
`control information originating at the DRNC to the mobile
`radio so it knows when and how to decode the information
`sent to it on the shared radio channel. Indeed, the timing of
`the physical channel information transport in the RAN is
`important for successful communication over the shared
`channel. For scheduling control, the information transported
`in the downlink is labeled with a timestamp indicating when
`the information needs to be sent over the radio interface. The
`base stations may use a receive "window" when receiving
`data from an SRNC or a DRNC. If data is received within
`the window, that data can be processed and transmitted on
`the radio interface. If the information is received too early,
`the base station may not have enough buffer capacity to
`temporarily store the received information. If the informa-
`tion is received too late, the base station may not have
`enough time to process the received information and send it
`out on the radio interface at the correct moment in time. The
`signaling on the Iub/Iur interfaces can support procedures,
`(e.g., a timing adjustment request message), by which the
`base station can request its CRNC (for shared physical
`channels) or an SRNC (for dedicated physical channels) to
`adjust the time at which information is sent to the base
`station.
`
`[0030] One way in which the identity of particular physi-
`cal channel resources to be used, (e.g., radio resources like
`spreading codes), and how these resources are to be used,
`(e.g., type of channel coding and coding rate), may be
`communicated by the RAN to the mobile terminal is through
`the use of Transport Format Indication (TFI) and/or Trans-
`port Format Combination Indication (TFCI) control mes-
`sages employed in the 3GPP specification. The invention is
`not limited any specific type of transport control message
`format or information. The TFI and TFCI are simply
`examples.
`
`[0031] A TFI or TFCI message may be used to describe
`these kinds of characteristics of a dedicated physical channel
`(hereafter "TFIl" or "TFCI1") as well as of a shared
`physical channel (hereafter "TFI2" or "TFCI2"). Again, a
`TFI or a TFCI is just an example of a control message, and
`other control messages as well as other types of control
`information may be used. Using a TFI example for purposes
`of illustration only, an SRNC determines a TFIl for each
`dedicated transport channel, and a DRNC determines the
`TFI2 for each shared transport channel. The base station
`maps the TFIl information for all dedicated transport chan-
`nels (if any) to a TFCIl. Similarly, the base station maps the
`TFI2 information for other shared transport channels (if any)
`to a TFCI2. If there is only one dedicated transport channel
`and one shared transport channel, the TFCI1 corresponds to
`one TFIl value, and the TFCI2 corresponds to one TFI2
`value. Both the TFCI1 and the TFCI2 are provided to the UE
`terminal by the BS on a dedicated physical radio channel.
`
`[0032] After receiving the TFCI1 control information over
`the dedicated physical control channel, the UE terminal
`knows how the different transport channels are multiplexed
`onto the dedicated physical radio channel. The UE is also
`aware of the downlink physical channel resources, (e.g.,
`spreading factor, channelization code, etc.), that are allo-
`cated when the radio link is first set up. With this informa-
`tion, the UE terminal can receive and demodulate informa-
`tion transmitted over the dedicated radio channel.
`
`[0033] On the other hand, a shared radio channel may use
`one of several radio resources, (e.g., one of several radio
`channel WCDMA spreading codes), based on the current
`radio resource scheduling by the CRNC. Because it is
`impractical for the UE terminal to know and check for
`information regarding all the radio resource(s) currently
`selected for use by the CRNC, the UE terminal is informed
`of the currently used radio resources for the shared physical
`channels, in this example, using the TFCI2 control message.
`The TFCI2 may identify for the UE terminal the particular
`radio resources, (e.g., spreading codes), to be used by the
`common/shared physical radio channel at a certain future
`moment in time. The TFCI2 may also indicate the time or
`multiplexing position within the identified frame that cor-
`responds to the information directed to the mobile unit
`which should be decoded.
`
`[0034] Typically, the TFCI 1 and TFCI 2 information is an
`index to a look-up table provided to and stored in the mobile
`radio unit during the time that a connection is established
`between a core network and the mobile unit. Information in
`the look-up table includes individually addressable entries of
`radio resource identification, e.g., a channelization code and
`corresponding spreading factor, as well as multiplexing or
`timing information that identify which portions of a particu-
`
`Ericsson Exhibit 1013
`Page 10
`
`

`

`US 2001/0036823 Al
`
`Nov. 1, 2001
`
`4
`
`lar frame on the shared radio channel contain information
`for the particular mobile radio unit. The TFCI index is used
`to address that look-up table and retrieve the corresponding
`information used by the mobile radio to then receive and
`properly decode information intended for it from the shared
`radio channel.
`
`[0035] A description of TFIs and TFCIs may be found in
`the 3GPP RAN2 specification entitled "Service Provided by
`the Physical Layer," 25.302, revision v.3.3.0, incorporated
`herein by reference. FIG. 2 shows an example TFI message
`format in a signaling control frame. An eight bit field
`indicates a connection frame number (CFN) followed by a
`TFI or TFCI indicator. The TFI and/or TFCI may be used to
`address control information previously stored in a look-up
`table in the mobile radio as described above. This reduces
`the amount of data to be transmit over the radio interface. Of
`course, control information could be communicated directly
`rather than indirectly. Optional Spare and Spare Extension
`bit fields are also shown.
`
`[0036] One approach for communicating TFCI2 informa-
`tion is for the DRNC to insert the TFCI2 into the information
`stream to be transmitted on the dedicated physical radio
`channel. The BS then transmits both the TFCI1 and TFCI2
`on the dedicated radio physical channel over the radio
`interface. FIG. 3 illustrates this approach. The scheduled
`data and the TFIl control information to be transported on
`a dedicated physical traffic radio channel are received at the
`DRNC on a corresponding transport bearer. See the solid
`line in the transport bearer (shown as a tube) between the
`SRNC 14 and DRNC16. The DRNC inserts the TFCI2 into
`that information stream before it is forwarded to the BS via
`the same transport bearer (shown as a dashed line in a tube)
`between DRNC 16 and BS2 20. This approach for convey-
`ing the TFCI2 data, however, has some drawbacks.
`
`[0037] First, insertion of the TFCI2 by the DRNC is
`inconsistent with a RAN architecture in which control and
`traffic information related to a dedicated physical channel
`are transported between SRNC and BS by "transparently"
`passing through the DRNC. If the DRNC must insert the
`TFCI2, it is no longer transparent. Instead, the DRNC must
`be knowledgeable of the data content it receives and for-
`wards, which increases the complexity of and the delay
`caused by the DRNC.
`
`[0038] Second, if the TFCI2 information arrives too late at
`the BS, the BS will send a timing adjustment request in the
`uplink direction to the RNC. All uplink information from the
`BS related to dedicated physical channels is supposed to be
`passed transparently to the SRNC. Accordingly, the timing
`adjustment request is transparently passed from the BS by
`the DRNC to the SRNC. However, it is the DRNC—not the
`SRNC—that should perform the timing adjustment function.
`The DRNC adds the TFCI2 to the downlink information
`stream to be transported over the dedicated physical radio
`channel.
`
`combining/splitting are not possible in the DRNC if
`needed), the benefits of such a solution may outweigh the
`drawbacks. Example benefits might include a decreased load
`on the DRNC and a decreased transport delay on the
`dedicated physical channel in the RAN, i.e., no DRNC
`processing and buffering delay. In any event, this approach
`eliminates the need to include the DRNC in the transport
`bearer route for data to be transported on a dedicated
`physical radio channel.
`
`[0040] To overcome these drawbacks and limitations, (and
`perhaps others), the present invention employs a separate
`transport bearer between a controlling-RNC (CRNC) and a
`BS to transport CRNC-originated control information that is
`to be transmitted by the BS to the mobile terminal on a
`dedicated physical radio channel. FIG. 4 illustrates an
`example of such a separate transport bearer (the thick dashed
`line) between a DRNC (the controlling RNC for BS2) and
`BS2 that conveys such information, e.g., TFCI2 control
`information originated in the DRNC. Although not shown,
`in a configuration that includes only an SRNC and a base
`station, (i.e., there is no DRNC supporting the connection),
`it may be appropriate or otherwise desirable to establish a
`separate transport bearer to carry the control information
`such as TFI information generated by the SRNC.
`
`[0041] Although the invention may transmit various types
`of control information over the separate transport bearer, the
`non-limiting, example described hereafter is TFCI2 control
`information. Rather than inserting the TFCI2 (or other
`control information) into the information stream related to
`the dedicated physical channels, a separate transport bearer
`is established from the DRNC to the BS (the thick dashed
`line) to convey the control information, e.g., the TFIC2.
`
`[0042] There are three transport bearers established
`between the DRNC 16 and the base station 20. A first
`transport bearer carries to the DRNC scheduled data to be
`transported on a shared radio channel, like the DSCH. A
`second transport bearer transports the SRNC-scheduled data
`to be transported on a dedicated radio channel, such as the
`DCH, along with control information originated at the
`SRNC, such as the TFIl. The third transport bearer trans-
`ports the control information originated at the DRNC 16,
`which in this case, is the TFCI2.
`
`[0043] A Transport Information procedure (block 100) is
`now described in conjunction with the flowchart illustrated
`in FIG. 5. A transport bearer request is received at the RAN
`to establish a transport bearer between a particular