WO2003101136A1 - Datenübertragungsverfahren und -system in einem mobilfunksystem - Google Patents

Datenübertragungsverfahren und -system in einem mobilfunksystem Download PDF

Info

Publication number
WO2003101136A1
WO2003101136A1 PCT/DE2003/001408 DE0301408W WO03101136A1 WO 2003101136 A1 WO2003101136 A1 WO 2003101136A1 DE 0301408 W DE0301408 W DE 0301408W WO 03101136 A1 WO03101136 A1 WO 03101136A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
parameters
channel
dsch
transmission
Prior art date
Application number
PCT/DE2003/001408
Other languages
English (en)
French (fr)
Inventor
Mark Beckmann
Michael Eckert
Martin Hans
Andreas Otte
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US10/495,904 priority Critical patent/US20040266461A1/en
Priority to AU2003232618A priority patent/AU2003232618A1/en
Publication of WO2003101136A1 publication Critical patent/WO2003101136A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/12—Access restriction or access information delivery, e.g. discovery data delivery using downlink control channel

Definitions

  • the present invention relates to a method and a system for transmitting data in a mobile radio system.
  • UMTS Universal Mobile Telecommunications System
  • the third generation UMTS mobile radio system information is transmitted to a user by reserving a physical resource.
  • the data transmission from the generally fixed base station (designation in the GSM - Global System for Mobile Communications) or "Node B" (designation of a base station in UMTS) to the mobile devices (in UMTS mobile stations) is carried out as a transmission in what is known as a "downlink" Direction, ie Downlink, designated.
  • a downlink Direction
  • uplink i.e. upward link.
  • Air interface two modes are provided: In frequency division duplex (Frequency Division Duplex - FDD) mode, the transmission in up and downlink direction takes place on different frequencies, in time division duplex (Time Division Duplex TDD) mode only one carrier frequency is used.
  • Frequency Division Duplex - FDD Frequency Division Duplex
  • Time Division Duplex TDD Time Division Duplex
  • Time slots separate the uplink and downlink
  • UMTS there are two types of radio channels for the transmission of information: dedicated channels, so-called “dedicated channels”, and common channels, so-called “common channels”.
  • dedicated channels a physical resource is reserved only for the transmission of information for a specific subscriber device, called “User Equipment” (UE) in UMTS.
  • UE User Equipment
  • shared channels information that is intended for all subscribers can be transmitted or only for a specific subscriber, in the latter case the common channel must also be used to transmit which subscriber the information is intended for.
  • FIG. 1 shows the known architecture of the UMTS network UTRAN (Universal Terrestrial Radio Access Networks) with a core network CN, a radio network control device RNC (radio network controller), base stations Node B1 and Node B2 and a mobile station UE.
  • RNC radio network controller
  • Figure 2 shows a UMTS protocol architecture.
  • the layers 2 and 3 shown therein are contained both once in the UE and once in the RNC.
  • the letter “L” followed by a number corresponds to a layer, for example L2 is layer 2.
  • “c” means control.
  • the protocol layers shown in Figure 2 are - the radio resources control layer RRC (Radio Resource Control layer, ie, lower layer 3, which is described in the technical specification TS 25.331 "Radio Resource Control", the 3rd Generation Partnership Project (3GPP), March 2001;
  • RRC Radio Resource Control layer, ie, lower layer 3, which is described in the technical specification TS 25.331 "Radio Resource Control", the 3rd Generation Partnership Project (3GPP), March 2001;
  • the packet data convergence protocol layer PDCP Packet Data Convergence Protocol layer, ie, the upper layer 2 in the technical specification TS 25.321, "Packet Data Convergence Protocol", the 3rd Generation Partnership Project (3GPP), March 2001 described is, the transmission / multiple transfer Steurungs harsh BMC (broadcast / multicast Control layer, ie, the upper layer 2 in the technical specification TS 25324 "broadcast / multicast Control", the 3rd generation Partnership Project (3GPP), March 2001 is described;
  • the Funksterecken control layer RLC Radio Link Control layer, ie the middle layer 2, which is described in the technical specification TS 25.322 “Radio Link Control", the 3rd Generation Partnership Project (3GPP), March 2001
  • the Mediumzugriff- described control layer MAC medium Access control
  • MAC medium Access control
  • a protocol in the transmitter exchanges protocol data units PDUs (Protocol Data Units) with the equivalent protocol in the receiver (UE or RNC) by the services of the underlying protocol
  • each protocol layer offers itss to the layer above it Services at so-called service access points, which are provided with common and unique names for a better understanding of the protocol architecture.
  • service access points above the protocols PDCP, BMC and RLC are referred to as radio supports RB, so-called “radio bearers”, and the service access points between the protocols RRC and RLC are signaling radio supports SRB, so-called “signaling radio bearers”.
  • the service access points between the protocols RLC and MAC as logical channels LogCH, so-called “Logical Channels”, and the service access points between the MAC protocol, which is the lowest protocol of layer 2, and the physical layer (layer 1) as Transport channels TrCH, so-called "transport channels”.
  • the channels that are used for the actual transmission of the data via the air interface are called physical channels PhyCH.
  • UMTS all physical channels of a transmission direction are generally transmitted simultaneously over a common frequency band. To the individual physical channels that overlap during transmission via the air interface in the
  • UMTS uses the CDMA multiple access method, in which the data to be transmitted are modulated with so-called spreading codes. Therefore, a parameter by which a physical channel is described, among other things, is the spreading code with which its data is spread or modulated. This parameter is available regardless of the two duplex modes FDD and TDD specified in UMTS.
  • the duplex mode describes how the two transmission directions downlink (DL, RNC ⁇ UE) and uplink (UL, UE-RNC) of a mobile radio connection are separated from each other.
  • DL and UL are generally transmitted on different frequency bands at the same time, whereas in TDD mode DL and UL are transmitted over the same frequency band, but the transmission takes place at different times.
  • the further explanations and explanations are only valid for the UMTS FDD mode. The tasks and functions of the RRC protocol, MAC protocol and the physical layer necessary for understanding the present invention are explained below.
  • the RRC protocol is explained below.
  • the RRC protocol is responsible for setting up, dismantling and reconfiguring PhyCHs, TrCHs, LogCHs and RBs and negotiating all parameters of the Layer 2 protocols and the physical layer.
  • This protocol is available in both the UE and the RNC and it uses the transmission services provided by the RLC protocol, ie the SRBs, to send RRC configuration messages.
  • the configured unit (UE) can acknowledge receipt of a configuration message from the configuring unit (RNC) by sending an acknowledgment of receipt.
  • the RRC protocols thus negotiate the configuration parameters required for establishing a connection, on the basis of which each individual RRC protocol in turn carries out the configuration of the layer 2 protocols below it and the configuration of layer 1.
  • the configuration messages that are sent by the RNC's RRC protocol can generally be divided into two types. On the one hand there are configuration parameters that have the same value and meaning for several UEs, and on the other hand there are configuration parameters that are only valid for a single UE. Therefore, the RRC protocol of the RNC sends configuration parameters that are equally valid for several UEs on logical channels that can be received by several UEs together, so-called "Common LogCHs", and configuration parameters that are only valid for one UE LogCHs that are only received by a specific UE so-called "Dedicated LogCHs". For example, generally valid configuration parameters are sent over a broadcast control channel BCCH (Broadcast Control Channel) and UE specific configuration parameters over a dedicated control channel DCCH (Dedicated Control Channel).
  • BCCH Broadcast Control Channel
  • DCCH dedicated Control Channel
  • the MAC protocol is explained below.
  • the task of the MAC protocol in the transmitter is to map the data that are present at a LogCH above the MAC protocol to the transport channels of the physical layer, or to distribute data received on transport channels to logical channels in the receiver.
  • each transport channel is preconfigured with a set of fixed parameters for the transmission of the data. From a further set of variable parameters, the MAC protocol can select the cheapest ones for the current transmission and thus dynamically influence the data transmission.
  • a valid setting of all parameters for a transport channel is called transport format TF.
  • the set of all possible settings for a transport channel is called Transport Format Set TFS (Transport Format Set).
  • TFS Transport Format Set
  • the individual TFs are identified by an indicator. This indicator is referred to as the transport format indicator TFI.
  • Transport Format Combination Indicator Transport Format Combination Indicator
  • a TF consists of static parameters that cannot be influenced by the MAC protocol, but can only be negotiated by the RRC protocol, and dynamic parameters, of which a set of different settings is negotiated by the RRC protocol and which can be influenced by the MAC protocol.
  • the static parameters include: the length of the transmission interval TTI (transmission
  • Time interval i.e. the time interval for which the physical layer processes data consecutively. This can be 10, 20, 40 or 80 milliseconds long.
  • the coding scheme for error protection the length of the redundancy information for error protection CRC
  • RLC size Since the MAC protocol neither generates MAC PDUs, nor does the RLC PDUs received by RLC segregate or depend on each other, a MAC PDU corresponds with exactly one RLC PDU as long as that MAC protocol of the RLC-PDU does not precede a control data header, a so-called MAC header. If the MAC protocol precedes the RLC-PDUs with a control data header, the MAC-PDU is longer than the RLC-PDU by the length of the MAC header. With this parameter, both the size of the RLC-PDU and the size of the MAC-PDU are set.
  • the data block transferred to the physical layer on the transport channel, the MAC-PDU is also called the transport block.
  • This parameter determines the number of MAC-PDUs that can be transferred to the physical layer for simultaneous processing and transfer via the air interface parts during a TTI.
  • TTI, RLC size and number of transport blocks result in the instantaneous data rate of the transport channel, which is determined dynamically by the MAC protocol by selection of the different transport formats, ie by variation of the TTI, the RLC - Size and number of transport blocks can be set.
  • the MAC protocol In addition to the dynamic selection of a TFC for each transmission interval (TTI), the MAC protocol, as already mentioned at the beginning, has the task of opening the data arriving on the various RBs, taking into account the service quality QoS (Quality of Service) set for the RB to distribute the transport channels.
  • Qos of an RB describes its transmission service quality, which is to be guaranteed by the layer 2 protocols and the physical layer during the duration of the mobile radio connection.
  • the QoS is characterized, for example, by a certain guaranteed data rate and / or a maximum transmission delay.
  • the RRC protocol deals with the establishment and reconfiguration of RBs e.g. from which logical channels are to be mapped onto which transport channels, it being possible for a plurality of logical channels to be assigned to each transport channel.
  • FIG. 3 shows the architecture of the MAC protocol in the RNC reduced to the UMTS-FDD mode, with a separate dedicated MAC unit MAC-d (MAC-dedicated) being present for each UE that is supplied by an RNC , Abbreviations already described in FIG. 3 have the same meaning.
  • MAC-d unit Via the MAC-d unit, only UE-specific user and control data, which reach the MAC-d unit via the corresponding logical channels, the dedicated traffic channel DCCH (Dedicated Traffic Channel) and the dedicated control channel DTCH (Dedicated Control Channel)
  • DCCH Dedicated Traffic Channel
  • DTCH dedicated Control Channel
  • a DL direction sent and received in UL direction.
  • At least one separate ter transport channel a so-called dedicated transport channel DCH (Dedicated Channel), available.
  • DCH Dedicated Channel
  • DPCH dedicated Physical Channel
  • the MAC control / shared unit MAC-c / sh MAC control / shared shown in FIG. 3 generally transmits useful and control data which are not UE-specific. This data reaches the MAC-c / sh unit via the logical channels Common Traffic Control (CTCH) and Common Control Channel (CCCH).
  • CTCH Common Traffic Control
  • CCCH Common Control Channel
  • the CCCH exists in both the DL and UL directions and is therefore carried in the DL by the FACH and in the UL by a direct access channel R ⁇ CH (Random Access Channel). Furthermore, system information that is the same for all UEs can also be transported via the MAC-c / sh unit. The system information reaches the MAC-c / sh unit via the logical channel BCCH (Broadcast Control Channel).
  • BCCH Broadcast Control Channel
  • the BCCH is a radio control channel and only exists in the DL direction and can generally be mapped to two different transport channels.
  • the BCCH can also be carried by the FACH, on the other hand, it can be transmitted to the transport channel BCH (broadcast) by a further MAC unit, which is not shown in FIG. 3 and is called the MAC transmission unit MAC-b (MAC broadcast) Channel) are mapped.
  • the MAC-c / sh unit is also capable of sending and receiving UE-specific user and control data.
  • this is the case when a UE e.g. Zt. has not set up a dedicated transport channel DCH, but still wants to receive or send smaller amounts of UE-specific data. From the point of view of
  • RNC the data is routed in the DL from the MAC-d unit to the MAC-c / sh unit, whereupon these inputs transfers the data to the physical layer via the FACH.
  • the data is received on the RACH in the UL direction in order to be forwarded from the MAC-c / sh to the MAC-d.
  • a UE may have set up a DCH, but its capacity is now too low to transmit a certain amount of data in a certain transmission interval.
  • This situation can be present, for example, in the case of a data stream which has peaks in the amount of data in its temporal course and which is generally referred to as a data stream BDS (Bursty Data Strea).
  • BDS Band Data Strea
  • additional capacities are made available to him for the corresponding period of time.
  • the additional capacities consist in a so-called distributed channel for a transmission in the downlink direction DSCH (Downlink Shared Channel). It is a Transport channel that only exists in the DL direction and that there are several DSCH (Downlink Shared Channel).
  • the DSCH is only assigned to one UE at a certain time and for a certain duration. At another time, however, it is easily possible for the same DSCH resources to be allocated to another UE.
  • the DSCH is mapped by the physical layer onto one or more physically distributed channels during a transmission in the downlink direction PDSCH (Physical Downlink Shared Channel), which, among other things, are again identified by specific spreading codes.
  • PDSCH Physical Downlink Shared Channel
  • the function of the MAC protocol can now be summarized as follows: The sending MAC protocol looks for a transport format for each TTI and for every TrCH (in total one TFC) and determines which LogCHs
  • the MAC protocol shares the corresponding RLC units each TF associated with RLC PDU size ', and the number of expected RLC PDUs.
  • the RLC protocols then transfer the corresponding number of RLC PDUs on the corresponding logical channel to the MAC protocol. If necessary, this adds a MAC header field to the data and simultaneously transfers the entire MAC PDUs for a transport channel to the physical layer.
  • the MAC protocol also transfers the physical layer's current TFI for each transport channel to the TTI.
  • the physical layer has the task of sending the data received from the MAC protocol via the transport channels within the corresponding TTIs of the transport channels via the air interface.
  • the physical layer uses the TFIs of the individual TrCHs transmitted by the MAC protocol to determine, among other things, the length of the redundancy information for error protection (CRC), the channel coding method, the code rate and the duration of the TTI in which the data of a TrCH are to be transported via the air interface.
  • CRC redundancy information for error protection
  • the physical layer calculates the CRC sum for each transport block of a TrCH that is to be transmitted in the corresponding TTI and attaches this to the data.
  • all dedicated transport channels (DCHs) of a UE are assigned to a CCTrCH and all DSCHs of a UE are mapped onto another separate CCTrCH.
  • the data to be sent are then mapped by a CCTrCH onto the corresponding physical channels, which are responsible for the transmission of the data via the air interface.
  • the data of the CCTrCH, which carries the dedicated transport channels (DCHs) of a UE are mapped on DPCHs and the data of the CCTrCH, which carries the DSCHs of a UE, are mapped on PDSCHs.
  • the data is sent via the air interface, it is then modulated and coded, ie spread, with the spreading code specific for the corresponding DPCH or PDSCH.
  • the physical layer of the transmitter determines from the TFIs of the transport channels that for the current TTI valid TFC and, in turn, the associated TFCI.
  • a TFCI generally has a length of 10 bits and is transmitted to the UE via a DPCH together with the data of the CCTrCH, which carries the dedicated transport channels.
  • the UE can therefore use the received TFCI to undo the measures carried out on the data by the transmitter and thus generally decode the data without errors.
  • the TFCI is generally specific for each CCTrCH, ie a UE that has been configured with two CCTrCH (one for DCHs and one for DSCHs) must be notified of two different TFCIs. To save transmission capacity, however, only a single 10 bit long TFCI is usually sent to a UE.
  • a DSCH which is mapped by the physical layer in the transmitter onto a separate CCTrCH and from this onto one or more PDSCHs, is generally used to break down data peaks, which are involved, for example, in so-called “Bursty Data Streams” (BDS)
  • BDS Band Data Streams
  • the characteristics of such a BDS include that the data peaks are generally irregular and sudden, so the sender (RNC) must be able to give the UE the additional capacities required for the transmission of the data peaks and in the form of the PDSCHs are available quickly and easily. For this reason, an explicit signaling of the additional resources does not make sense, since it would take too much time.
  • a configuration message from the RRC in the RNC to the RRC in the UE would have to be made be sent over the air interface to the with the parameters contained in the message configure the physical layer and the MAC protocol of the UE.
  • the additional capacities are therefore implicitly communicated to the UE by the RNC.
  • the 10-bit TFCI mentioned above is used for this.
  • the configuring unit When configuring an RB whose data flow has the characteristics of a BDS, the configuring unit (RNC) is aware that from time to time additional capacities in the form of one or more PDSCHs are required in the DL direction in order to operate within a certain time frame , a so-called "frame", to transmit a required amount of data to the UE. This has the consequence that a DSCH is configured in the DL for the UE.
  • the UE receives the necessary parameters that are required to receive a DSCH
  • the TFS of the DSCH, the TFCS of the CCTrCH belonging to the DSCH and the specific spreading codes of the PDSCHs on which one or more DSCHs are mapped include the RRC (re) configuration message, which communicates the parameters described above to a UE in various forms, for example as a radio support structure, the so-called “RADIO BEARER SETUP”, as a radio support reconfiguration, the called “RADIO BEARER RECONFIGURATION” or as a transport channel reconfiguration, the so-called “TRANSPORT CHANNEL RECONFIGURATION” is available.
  • RRC radio
  • FIG. 4 and FIGS. 5 and 6 show at which point in the "RB SETUP” message the previously mentioned parameters are communicated to a UE by so-called information elements (IEs). Expressions that have already been defined have the same meaning again. A “IE” afterwards means that the abbreviations already explained are each an information element. MS means the type of message.
  • the TFS of each DSCH is explicitly signaled to a UE by the IE "TFS" (Transport Format Set).
  • this IE is contained in the "RB SETUP” message once for each transport channel that is to be set up, regardless of whether it is is a DCH or a DSCH.
  • the UE receives the dynamic parameters (RLC size, number of transport blocks) as well as the semi-static parameters that are constant for the TFS for each TF in the TFS of the corresponding transport channel.
  • the IE "TFS” is in the IE "Add / Reconf. DL TrCH info # 1, 2 "(# 22 in FIG. 4).
  • TFS (# 23 in FIG.
  • this also contains another important parameter which is referred to as the" DCH quality target "
  • the UE uses this parameter to determine the reference value of the signal-to-interference ratio (SIR) for the DPCHs or PDSCHs required for a transport channel, for example, if this value is exceeded or not in the DL direction, the UE signals the sender to increase the transmission power in the next time frame or should decrease.
  • SIR signal-to-interference ratio
  • the TFCS of the CCTrCH on which one or more DSCHs are mapped by the physical layer in the transmitter in order to then be distributed to the various PDSCHs, is communicated to the UE by the IE “TFCS” (Transport Format Combination Set), which is in the IE , Common transport channel information for all transport channels 4 DLTrCHIcf TrCH (DL Transport Channel Information common for all transport channels) is included.
  • TFCS Transport Format Combination Set
  • a UE is initially informed of the configuration of the previously mentioned TFCI, which is transmitted to the UE together with the data in a frame during transmission in each frame.
  • the TFCI is configured by the IE "TFCS" as "normal".
  • the TFCI in this case consists of two fields.
  • the TFCI field 1 speaks of TFCI field 1 and TFCI field 2.
  • the length of the second field is explicitly communicated in the IE (length of the TFCI (field 2)), which implicitly results in the length of the first field.
  • the TFCI field 1 contains the TFCI of the CCTrCH, which carries the dedicated transport channels of the UE
  • the TFCI field 2 contains the TFCI of the CCTrCH, on which the DSCHs of a UE are mapped.
  • the UE is made aware of the actual TFCSs of the corresponding CCTrCHs by the IE "TFCI Field 1 Info” and "TFCI Field 2 Info”.
  • the IE "TFCI field 2 info” contains, among other things, the IE "TFCS explicit configuration", which contains each value of the TFCI field 2 assigns a TFC to the TFCS.
  • a UE is made aware of the TFCS of the CCTrCH that bears the DSCHs of the corresponding UE (# 24 in FIG. 5).
  • the UE is signaled by the receipt of the 10-bit TFCI. This signaling generally always takes place one time frame in advance, ie one time frame before the corresponding time frame in which the UE is to receive additional data on one or more DSCHs.
  • a received TFCI field 2 now corresponds to a TFC that indicates to the UE that the MAC protocol in the transmitter (RNC) does not map data to any of the DSCHs configured for the UE for the next time frame, the UE is aware that it in the next
  • Time frame has no data to receive on a PDSCH. If, on the other hand, the value of the TFCI field 2 signals a UE that the MAC protocol in the transmitter (RNC) maps data to one of the DSCHs configured for the UE in the next time frame, the UE is aware that it will add additional data to one or in the next time frame has to receive several PDSCHs. So that the UE now knows on which and how many PDSCHs it should receive additional data, the value of TFCI field 2 not only connects the current TFC of the corresponding CCTrCH, but also the information about the spreading codes of the PDSCHs on which the additional data is sent from the transmitter to the UE.
  • the corresponding spreading codes of the PDSCHs are also connected, which transmit the data of one or more DSCHs.
  • the assignment of the spreading codes of the required PDSCHs to the values of the TFCI field 2 is also made known to the UE by the "RB SETUP" message.
  • This message contains the "PhyCH” the IEs that a UE receives to receive communicate the parameters required for the physical resources.
  • the parameters required to receive one or more PDSCHs are given to a UE, for example, by the IE “PDSCH DL Information mation ", which in turn contains the IE" PDSCH Code Mapping "(# 25 in FIG. 6).
  • the last-mentioned IE contains the assignment of one or more spreading codes (corresponding to one or more PDSCHs) to the values of TFCI field 2.
  • a UE If a UE is now configured in the manner described above, it can determine for each time frame whether it has been allocated additional resources in the form of PDSCHs in the subsequent time frame by the transmitting unit (RNC), how many additional resources it has received and with which spreading code the corresponding resources (PDSCHs) were coded.
  • RNC transmitting unit
  • both the "RADIO BEARER SETUP" configuration message described here and the “RADIO BEARER RECONFIGURATION” and “TRANSPORT CHANNEL RECONFIGURATION” configuration messages are generally sent from the RRC in the RNC to the RRC in the UE via a dedicated logical control channel (DCCH)
  • DCCH dedicated logical control channel
  • the settings made by the configuration messages for the reception of DSCHs and the associated PDSCHs are only known to the corresponding UE, which makes sense since the resource of a DSCH can only be assigned to one UE at any given time
  • the data sent on one or more DSCHs should be received by several UEs at the same time, which of course presupposes that the configuration of the DSCHs must be the same for all UEs the technology to each UE that the data on the corresponding DSCHs should receive a separate configuration message via a DCCH from the RRC in
  • the PDSCH is a pure data channel, ie no signaling data is sent from the sender (physical layer in node B) to the UE. Therefore, the PDSCH in UMTS-FDD mode can only ever exist in connection with a DPCH in the DL direction and a DPCH in the UL direction. animals.
  • the transmitter (node B) in the transmission power control channel sends bits in the downlink direction DL-TPC (Transmit Power Control) together with the TFCI bits via the DPCH to the UE.
  • TPC bits signal the UE whether it should increase or decrease the transmission power in the UL.
  • the UE On the DPCH of the UL, the UE accordingly sends TPC bits that signal the NodeB that it has to increase or decrease the transmission power in the DL. Depending on these TPC bits, the NodeB increases or decreases the transmission power of the DPCHs and the PDSCHs. Thus, a known PDSCH cannot exist without DPCHs.
  • the present invention is therefore based on the object of providing a method and a system for transmitting data in a mobile radio system in which the required signaling effort via the air interface is kept low.
  • This object is achieved by a method for transmitting data in a mobile radio system, in particular UMTS, with the features of claim 1.
  • the method for transmitting data in a mobile radio system has the method steps - sending parameters for the reception of a channel used several times from a base station to a mobile station,
  • the parameters are known to all mobile stations supplied by the base station.
  • the multiply used channel is preferably a shared channel for a transmission in the downlink direction DSCH.
  • the parameters are evaluated in the at least one mobile station, whereupon data is received from the mobile station via the channel used several times. Such a reception is made possible by the parameters.
  • the parameters are preferably broadcast by radio into the coverage area of the mobile station. In this so-called "broadcast" transmission, the parameters are consequently made known to all mobile stations using in the coverage area of the base station.
  • the channel which is used more than once is preferably a channel which is mainly used for the transmission of data peaks. Data is therefore transmitted via it, the transmission of which could not be guaranteed in the case of a transmission via normally existing transmission paths.
  • the parameters are transmitted with a transmission power which ensures that the parameters can be received anywhere in the coverage area of the base station.
  • the data are received simultaneously by a plurality of mobile stations. This ensures that the data can also be received from this multitude of mobile stations via the channel that is used several times.
  • the data are data sent to a group of data sent to mobile stations simultaneously. These are preferably the multicast groups or multicast data.
  • the object stated at the outset is also achieved by a system for transmitting data into a mobile radio system, in particular UMTS, with the features of independent claim 8.
  • the system for transmitting data into a mobile radio system, in particular UMTS has means for sending parameters for the reception of a multi-use channel from a base station to a mobile station, means for evaluating the parameters in the mobile station, and means for receiving data transmitted to the base station via the channel used multiple times by the mobile station, the reception being made possible by the parameters.
  • the parameters are made known to all mobile stations supplied by the base station.
  • the present invention further relates to a mobile station for use in a method according to the invention and / or in a system according to the invention.
  • the present invention also relates to a base station for use in a method according to the invention and / or in a system according to the invention.
  • the parameters required for the reception of DSCHs are generally known in order to give several mobile radio terminals the possibility of receiving data on the DSCHs (or PDSCHs) at the same time and the required signaling effort to be kept as low as possible via the air interface.
  • An advantage of the invention is that the parameters required for receiving the DSCHs (or PDSCHs) do not have to be communicated to each UE separately via a DCCH if DSCHs (or PDSCHs) are to be received by several mobile radio terminals at the same time.
  • the signaling effort via the air interface is thus effectively reduced, which is equivalent to saving transmission capacities.
  • the transmission capacities saved can be used for the transmission of user data. This has the po- positive effect that the user data rate of the mobile radio system is increased and the signaling rate of the mobile radio system is reduced.
  • Another advantage of the present invention is that the corresponding parameters are already known from the general announcement in a mobile radio terminal, even if the reception of data at the same time as other mobile radio terminals on one or more DSCHs (or PDSCHs) for the corresponding one Mobile radio terminal is not yet provided. If the corresponding mobile radio terminal is now to receive data on one or more DSCHs (or PDSCHs) simultaneously with other mobile radio terminal data, the parameters required for receiving the data can be established immediately. The time required to configure a mobile radio terminal to receive data on the DSCHs (or PDSCHs) is therefore generally much less than in the known solutions, in which a configuration message is first sent to the mobile radio terminal got to.
  • FIG. 1 is a schematic representation of a UMTS network
  • FIG. 2 shows a schematic representation of the protocol architecture of the UMTS layers 2 and 3;
  • Figure 3 is a schematic representation of a reduced
  • FIG. 4 is a schematic representation of a radio prop setup message
  • FIG. 5 shows DL transport channel information together for all transport channels
  • Figure 6 is a schematic representation of physical channel information elements
  • FIG. 7 shows a system information block type 6
  • FIG. 8 shows an exemplary embodiment of a system information block type 6
  • FIG. 9 shows an exemplary embodiment of a system information block type 6.
  • FIGS. 1 to 6 were already described above when the description was introduced, so that reference is made to this description.
  • a multicast service in a UMTS mobile radio system includes the sending of data, which is generally intended for a group of mobile radio subscribers, over a single common channel in order to save transmission capacities of the air interface.
  • the functions and tasks of such a channel can take over, for example, the DSCH channel already described.
  • a DSCH that takes over the function of such a channel is therefore referred to below as MC-DSCH "Multicast Downlink Shared Channel".
  • This MC-DSCH is in principle identical to a conventional DSCH according to the prior art.
  • a difference to the known DSCH is that the MC-DSCH is not only assigned to one mobile radio subscriber or UE at a certain time, but can be assigned to several UEs at the same time.
  • the mobile radio subscribers that receive an MC-DSCH at the same time generally belong to the same multicast group (MC Group), so that an MC-DSCH is only ever assigned to a specific MC group at any given time.
  • the parameters required to receive the MC-DSCH are iden for all mobile radio subscribers who are to receive the MC-DSCH at the same time - table.
  • the parameters that the corresponding UEs of the mobile radio subscribers need for the reception of the MC-DSCH and the associated PDSCHs are the TFS of the MC-DSCH, the TFCS of the CCTrCH on which the MC-DSCH is mapped and the spreading codes of the PDSCHs on which the UEs are to receive the data of the MC-DSCH. If one now assumes that there is a separate CCTrCH for each MC-DSCH, a TFC of the TFCS always corresponds exactly to a TF of the TFS of the MC-DSCH.
  • the power control of an MC-DSCH can be carried out according to two different methods.
  • the power control can be carried out via the DPCHs of the participants in an MC group and, on the other hand, via an additional physical channel specially designed for the multicast service. A distinction is made between these two methods below.
  • the DPCH in the DL only serves to transmit the shared 10-bit TFCI and the TPC bits .
  • the basic setting means, for example, a certain TF of the DCH that signals the UE that it has no user data to receive on the corresponding DCH.
  • the entire TFS and an associated TFCS are made known to the DCH.
  • a physical channel for the DL direction which contains the TPC bits of all UEs belonging to an MC group and which is known as the multicast power channel McPwCH (multi- ticast Power Channel).
  • McPwCH multi- ticast Power Channel
  • Each UE of the MC group is informed via this channel whether or not it should increase the transmission power in the UL in the next transmission time frame, so that its TPC bits in the UL direction can still be received by the NodeB without errors.
  • McPwCH multi- ticast Power Channel
  • a variation of the McPwCH means that it does not only send TPC bits. This means that part of the total capacity of the McPwCH can be reserved for other control data or even for user data. If one now considers the case that a UE only wants to receive data from a multicast service and no data via dedicated channels (DCHs), the UE of the mobile radio subscriber only needs the DPCH associated with the MC-DSCH, as already described above, only for the transmission of the shared one 10 bit long TFCI.
  • DCHs dedicated channels
  • the TFCI of the CCTrCH, on which the MC-DSCH is mapped is sent to the UE via the McPwCH.
  • the TFCI is transmitted within the McPwCH transmission capacity reserved for other control data or user data.
  • the UE of a mobile radio subscriber who only wants to receive one or more multicast services does not need a DCH associated with the MC-DSCH and therefore also no DPCH.
  • a UE when setting up a DCH or the associated DPCH is the state of the art
  • SIB System Information Block
  • a SIB is sent from the RRC in the RNC via the logical channel BCCH to the MAC protocol.
  • the MAC protocol maps the BCCH to the transport channel BCH.
  • the BCH is then transmitted by the physical layer in the transmitter (Node B) with a power that ensures that the BCH can be received anywhere in the Node B coverage area.
  • the information on the BCH can be evaluated by any UE located in the coverage area of Node B.
  • the information sent over the BCH is made public. In this context, one speaks of "broadcasting" system information.
  • the parameters required for receiving an MC-DSCH and the associated PDSCHs can now be communicated to the UEs of the mobile radio subscribers of an MC group either by a SIB that has already been specified in UMTS, but which is then corresponding must be modified, or they can be made known to the UEs by their own SIB to be introduced only for the multicast service.
  • FIG. 7 shows the system information block type 6 (SIB 6) according to the prior art in tabular form. This is taken from the specification of the RRC protocol and is in the technical specification TS 25.331 "Radio Resource Control", the 3rd Generation Partnership Project (3GPP), March 2001 described in detail.
  • SIB 6 system information block type 6
  • the specification "OP" means that in a bit representation the IE starts with information that indicates whether further information about this element is available. Since this information can be represented by a single bit, for example, optional information elements can save transmission bandwidth in the absence of the information.
  • FIG. 8 (which extends over pages 8 and 9) shows the SIB 6 modified for the broadcast transmission of multicast information. Changes to the prior art are shown in italics. Since the SIB 6 is to transmit information that is required, among other things, to receive an MC-DSCH, the transport channel IEs have first been added to the SIB 6 (lines 1 to 7). Assuming that each MC group has its own MC
  • Line 2 in FIG. 8 states that all of the following elements in the table which are indented with at least one ">" are repeated as often as this IE indicates.
  • the IE in line 3 (MC group identity) identifies the MC group, for which the following IEs are important.
  • the transport format set of the MC-DSCH configured for the MC group is now made known and with the IE 'TFCS' the transport format combination set of the CCTrCH on which the data of the MC-DSCH are mapped.
  • the fifth IE in the list is a basic setting for the DCH associated with the MC-DSCH. of the transport format, although this IE can optionally be available.
  • the last IE in the list specifies the reference value for the power control of the PDSCH, on which the corresponding MC-DSCH is mapped.
  • the information generally valid for the reception of the PDSCHs and for the reception of the McPwCH are inserted in the SIB 6 under the IEs of the physical channels (lines 13 to 17). Since this information is also specific to MC groups, there is also a list of IEs that are sorted by MC groups. In other words, as before with the IEs for the transport channels, the IEs indented after line 13 with the character ">>>" are available once for each MC group. The IE 'MC group identity' in turn identifies the MC group for which the subsequent IEs (lines 15 to 17) are intended.
  • the IE 'PDSCH Code Mapping' (line 15) has the same task as in the prior art.
  • the assignment of TFCI (field 2) values to the spreading codes (channeling codes) of the PDSCHs that transport the data of the MC-DSCH is transmitted.
  • the IEs 'spreading factor (for McPwCH)' and 'code number (for McPwCH)' together describe the spreading code (channeling code) with which the McPwCH is spread over the air interface before transmission.
  • the information required for receiving an MC-DSCH and the associated PDSCH can be made known in general. This means that this information does not need to be transmitted to each UE individually via a dedicated connection if a mobile radio subscriber wants to use a multicast service. As a result, less transmission capacity is required to set up a multicast service and the signaling effort can be effectively reduced. Furthermore, the parameters received by a UE via the SIB 6 can be stored even if the UE does not yet want to receive a multicast service. The parameters required to set up a multicast service are therefore known in the UE and can be established immediately if the UE wishes to participate in a multicast service at a later time. The consequence of this is that it generally takes less time to set up a multicast connection.
  • the parameters or IEs proposed for broadcast transmission can also be contained in a separate SIB to be introduced specifically for multicast services.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zum Übertragen in einem Mobilfunksystem, insbesondere UMTS, aufweisend die Verfahrensschritte : Senden von Parametern für den Empfang eines mehrfach genutzten Kanals (DSCH) von einer Basisstation an eine Mobilstation; Auswerten der Parameter in der Mobilstation; und Empfangen von von der Basisstation ausgesendeten Daten über den mehrfach genutzten Kanal (DSCH) durch die Mobilstation, wobei der Empfang durch die Parameter ermöglicht wird, und die Parameter allen durch die Basisstation versorgten Mobilstationen bekannt sind. Bevorzugt werden die Parameter per Rundfunk in das Versorgungsgebiet der Mobilstation ausgesendet.

Description

Beschreibung
Datenübertragungsverfahren und -system
Die vorliegende Erfindung betrifft ein Verfahren und ein System zum Übertragen von Daten in einem Mobilfunksystem.
Derartige Verfahren bzw. Systeme finden u.a. in Mobilfunksystemen der dritten Generation, wie z.B. UMTS (Universal Mobile Telecommunications System) Anwendung.
Beim Mobilfunksystem der dritten Generation UMTS erfolgt die Übertragung von Informationen zu einem Anwender durch Reservierung einer physikalischen Ressource. Bei der Übertragung von Daten - egal welcher Art - wird im Mobilfunk zwischen zwei Übertragungsrichtungen unterschieden. Allgemein wird die Datenübertragung von der im Allgemeinen ortsfesten Basisstation (Bezeichnung im GSM - Global System for Mobile Communications) bzw. „Node B" (Bezeichnung einer Basisstation in UMTS) zu den mobilen Endgeräten (in UMTS Mobilstationen) als Übertragung in sogenannter „Downlink"-Richtung, d.h. Abwärtsstrecke, bezeichnet. Bei der Datenübertragung in der Gegenrichtung von einem Endgerät zu der Basisstation spricht man von Übertragung in sogenannter „Uplink"-Richtung, d.h. Auf- wärtsstrecke . Bei UMTS sind für die Übertragung über die
Luftschnittstelle zwei Modi vorgesehen: Beim Frequenzduplex- (Frequency Division Duplex - FDD) Modus erfolgt die Übertragung in-Up- und Downlink-Richtung auf unterschiedlichen Frequenzen, beim Zeitduplex- (Time Division Duplex TDD) Modus wird nur eine Trägerfrequenz verwendet. Durch Zuweisung von
/ Zeitschlitzen erfolgt eine Trennung der Up- und Downlink-
Richtung. Die Teilnehmer werden bei beiden Modi durch Aufprägen orthogonaler Codes, sogenannter „Channelization Codes", auf die Informationsdaten getrennt. Dieses Mehrfachzugriffs- verfahren ist als CDMA- (Code Division Multiple Access) Verfahren bekannt. Gemäß der technischen Spezifikation TS 25.211 V3.7.0 : „Physical Channels and Mapping of Transport Channels onto Physical Channels" des 3rd Generation Partnership Pro- ject (3GGP) , welche den UMTS-FDD-Modus beschreibt, ist ein physikalischer Kanal, das heißt ein Funkkanal, in der Down- link-Richtung durch Trägerfrequenz, einem Verschlüsselungs- Code (dem sogenannte „Scrambling Code") , einem Kanalisie- rungscode (dem sogenannten „Channelization Code") und einer Start- und Stopzeit definiert. Für die Uplink-Übertragung hat jede Mobilfunkstation ihren eigenen Scrambling Code. Der Sinn der Scrambling Codes liegt darin, die verschiedenen Mobil - funkstationen trennen zu können.
In UMTS gibt es für die Übertragung von Informationen zwei Arten von Funkkanälen: Dedizierte Kanäle, sogenannte „Dedica- ted Channels", und gemeinsame Kanäle, sogenannte „Common Channels". Bei den dedizierten Kanälen wird eine physikalische Ressource nur für die Übertragung von Informationen für ein bestimmtes Teilnehmergerät, in UMTS „User Equipment" (UE) genannt, reserviert. Bei den gemeinsamen Kanälen können Informationen übertragen werden, die für alle Teilnehmer ge- dacht sind oder nur für einen bestimmten Teilnehmer. Im letzteren Fall muss auf den gemeinsamen Kanal noch mit übertragen werden, für welchen Teilnehmer die Information gedacht ist.
Figur 1 zeigt die bekannte Architektur des UMTS-Netzwerks UTRAN (Universal Terrestrial Radio Access Networks) mit einem Kern-Netzwerk CN, einer Funk-Netzwerk-Kontrolleinrichtung RNC (Radio Netwotk Controler) , Basisstationen Node Bl und Node B2 und einer Mobilstation UE . Nachfolgend steht ein angefügtes „s" an eine definierte Einheit für die Mehrzahl der Einhei- ten.
Figur 2 zeigt eine UMTS Protokoll Architektur. Die darin dargestellten Schichten 2 und 3 sind sowohl einmal im UE als auch einmal im RNC enthalten. Der Buchstabe „L" gefolgt von einer Zahl entspricht einer Schicht, beispielsweise L2 ist die Schicht 2. Des Weiteren bedeutet „c" Steuerung. Die in Figur 2 dargestellten Protokoll-Schichten sind - die Funkmittel-Steuerungsschicht RRC (Radio Resource Control-Schicht, d.h. untere Schicht 3, die in der technischen Spezifikation TS 25.331 „Radio Resource Control", des 3rd Generation Partnership Projects (3GPP) , März 2001, beschrieben ist;
- die Packetdaten-Konvergenz-ProtokollSchicht PDCP (Packet Data Convergence Protokoll-Schicht, d.h. die obere Schicht 2, die in der technischen Spezifikation TS 25.321 „Packet Data Convergence Protocol", des 3rd Generation Partnership Projects (3GPP) , März 2001, beschrieben ist; die Übertragungs/Mehrfachübertragungs-Steurungsschicht BMC (Broadcast / Multicast Control-Schicht , d.h. die obere Schicht 2, die in der technischen Spezifikation TS 25.324 „Broadcast / Multicast Control", des 3rd Generation Partnership Projects (3GPP) , März 2001, beschrieben ist;
- die Funksterecken-Steuerungsschicht RLC (Radio Link Control-Schicht , d.h. mittlere Schicht 2, die in der technischen Spezifikation TS 25.322 „Radio Link Control", des 3rd Generation Partnership Projects (3GPP) , März 2001, beschrieben ist; die Mediumzugriff-Steuerungsschicht MAC (Medium Access Control-Schicht) , d.h. untere Schicht 2, die in der technischen Spezifikation TS 25.321 „Medium Access Control", des 3rd Generation Partnership Projects (3GPP) , März 2001, beschrieben ist; und
- die physikalische Schicht PHY, d.h. Schicht 1, die in der technischen Spezifikation TS 25.302 „Services Provided by Physical Layer", des 3rd Generation Partnership Projects (3GPP) , März 2001, beschrieben ist;
Im Allgemeinen tauscht ein Protokoll im Sender (RNC oder UE) Protokoll-Dateneinheiten PDUs (Protocol Data Units) mit dem gleichgestellten Protokoll im Empfänger (UE oder RNC) aus, indem es die Dienste der unter ihr liegenden Protokoll-
Schicht für den Transport der PDUs benutzt. Jede Protokoll- Schicht bietet dazu der über ihr liegenden Schicht ihre Dienste an sogenannten Dienstzugangspunkten an, die zum besseren Verständnis der Protokoll Architektur mit allgemein gebräuchlichen und eindeutigen Namen versehen sind. Wie Figur 2 zu entnehmen ist, bezeichnet man die DienstZugangspunkte o- berhalb der Protokolle PDCP, BMC und RLC als Funkstützen RB, sogenannte „Radio Bearer", die DienstZugangspunkte zwischen den Protokollen RRC und RLC als signalisiserende Funkstützen SRB, sogenannte „Signalling Radio Bearer", die DienstZugangs- punkte zwischen den Protokollen RLC und MAC als logische Kanäle LogCH, sogenannte „Logical Channels", und die Dienstzu- gangspunkte zwischen dem MAC Protokoll, das das unterste Protokoll der Schicht 2 darstellt, und der Physikalischen Schicht (Schicht 1) als Transportkanäle TrCH, sogenannte „Transport Channels". Die Kanäle, die für die eigentliche Ü- bertragung der Daten über die Luftschnittstelle benutzt werden bezeichnet man als physikalische Kanäle PhyCH. Alle physikalischen Kanäle einer Übertragungsrichtung werden bei UMTS im Allgemeinen gleichzeitig über ein gemeinsames Frequenzband übertragen. Um die einzelnen physikalischen Kanäle, die sich bei der Übertragung über die Luftschnittstelle überlagern, im
Empfänger wieder von einander trennen zu können, findet beim UMTS das Vielfachzugriffsverfahren CDMA Anwendung, bei dem die zu übertragenen Daten mit sogenannten Spreizkodes moduliert werden. Daher ist ein Parameter, durch den ein physika- lischer Kanal unter anderem beschrieben wird, der Spreizkode mit dem dessen Daten gespreizt bzw. moduliert werden. Dieser Parameter ist unabhängig von den beiden im UMTS spezifizierten Duplexmodi FDD und TDD vorhanden. Dabei beschreibt der Duplexmode, wie die beiden Übertragungsrichtungen Downlink (DL, RNC→UE) und Uplink (UL, UE-RNC) einer Mobilfunkverbin- dung von einander getrennt werden. Im FDD-Modus werden DL und UL auf unterschiedlichen Frequenzbändern im allgemeinen zeit- gleich übertragen, wogegen im TDD Modus DL und UL zwar über dem selben Frequenzband übertragen werden, die Übertragung jedoch zu unterschiedlichen Zeitpunkten stattfindet. Die weiteren Ausführungen und Erklärungen sind nur für den UMTS-FDD-Modus gültig. Im folgenden werden die Aufgaben bzw. Funktionen des für das Verständnis der vorliegenden Erfindung notwendigen RRC-Protokolls, MAC-Protokolls und der Physikali- sehen Schicht erläutert.
Nachfolgend wird das RRC-Protokoll erläutert. Für den Auf-, Abbau und die Umkonfiguration von PhyCHs, TrCHs, LogCHs und RBs und das Aushandeln aller Parameter der Schicht 2 Proto- kolle sowie der physikalischen Schicht ist das RRC-Protokoll verantwortlich. Dieses Protokoll ist sowohl im UE als auch im RNC vorhanden und es nutzt die Übertragungsdienste, die das RLC-Protokoll zur Verfügung stellt, also die SRBs, um RRC- Konfigurationsnachrichten zu versenden. Dabei gibt es im All- gemeinen beim Austausch von Konfigurationsnachrichten eine konfigurierende Einheit und eine konfigurierte Einheit, wobei im UMTS das RRC Protokoll des RNC grundsätzlich die konfigurierende Einheit und das RRC Protokoll des UE die konfigurierte Einheit ist. Die konfigurierte Einheit (UE) kann dabei den Empfang einer Konfigurationsnachricht von der konfigurierenden Einheit (RNC) durch das Senden einer Empfangsbestätigung quittieren. Somit handeln die RRC Protokolle die für den Aufbau einer Verbindung benötigten Konfigurationsparameter aus, anhand derer jedes einzelne RRC Protokoll wiederum die Konfiguration der unter ihm liegenden Protokolle der Schicht 2 sowie die Konfiguration der Schicht 1 vornimmt. Die Konfigurationsnachrichten, die vom RRC Protokoll des RNC gesendet werden, können dabei im allgemeinen in zwei Arten aufgeteilt werden. Zum einen gibt es Konfigurationsparameter, die für mehrere UEs im Wert und der Bedeutung gleich sind, und zum anderen gibt es Konfigurationsparameter, die nur für ein einzelnes UE Gültigkeit haben. Daher sendet das RRC Protokoll des RNC Konfigurationsparameter, die für mehrere UEs gleichermaßen gültig sind, auf logischen Kanälen, die von mehre- ren UEs gemeinsam empfangen werden können, sogenannte "Common LogCHs", und Konfigurationsparameter, die nur für ein UE gültig sind, auf LogCHs die nur von einem bestimmten UE empfan- gen werden können, sogenannte "Dedicated LogCHs" . Beispielsweise werden allgemein gültige Konfigurationsparameter über einen Sendungs-Steuerungskanal BCCH (Broadcast Control Channel) und UE spezifische Konfigurationsparameter über einen dedizierten Steuerungskanal DCCH (Dedicated Control Channel) gesendet .
Nachfolgend wird das MAC-Protokoll erläutert. Die Aufgabe des MAC Protokolls im Sender ist, die Daten, die an einem LogCH oberhalb des MAC Protokolls anliegen, auf die Transportkanäle der physikalischen Schicht abzubilden, bzw. im Empfänger auf Transportkanälen empfangene Daten auf logische Kanäle zu verteilen. Jeder Transportkanal ist dazu mit einem Satz von festen Parametern für die Übertragung der Daten vorkonfiguriert. Aus einem weiterer Satz von variablen Parametern kann das MAC Protokoll die jeweils für die aktuelle Übertragung günstigsten aussuchen und so die Datenübertragung dynamisch beeinflussen. Eine gültige Einstellung aller Parameter für einen Transportkanal wird dabei Transport-Format TF genannt. Die Menge aller möglichen Einstellungen für einen Transportkanal heißt Transport-Format-Satz TFS (Transport Format Set) . In einem TFS sind die einzelnen TF durch einen Indikator gekennzeichnet. Dieser Indikator wird als Transport-Format- Indikator TFI bezeichnet. Nur die variablen (dynamischen) Pa- rameter des TF variieren innerhalb eines TFS. Zu einem bestimmten Zeitpunkt ist für jeden Transportkanal nur ein Transport Format eingestellt . Die Menge der zu einem bestimmten Zeitpunkt für alle vorhandenen Transportkanäle eingestellten Transport-Formate heißt Transport-Format-Kombination TFC. Aus den für jeden Transportkanal gültigen Transport-
Formaten ergibt sich eine große Vielzahl von möglichen Kombinationen für alle Transportkanäle und theoretisch könnte jede dieser Kombinationen eine TFC ergeben. Praktisch ist die Anzahl der tatsächlich gleichzeitig erlaubten Kombinationen von Transport Formaten aber eingeschränkt. Die Menge aller erlaubten TFCs wird Transport-Format-Kombinationssatz TFCS (Transport Format Combination Set) genannt. In einem TFCS sind wiederum die einzelnen TFCs durch einen Indikator gekennzeichnet, der als Transport-Format-Kombinationsindikator TFCI (Transport Format Co bination Indicator) bezeichnet wird.
Wie oben beschrieben, besteht ein TF aus statischen Parametern, die nicht durch das MAC-Protokoll beeinflusst werden können, sondern nur durch das RRC-Protokoll ausgehandelt werden, und dynamischen Parametern, von denen ein Satz von ver- schiedenen Einstellungen vom RRC Protokoll ausgehandelt wird und die vom MAC Protokoll beeinflusst werden können. Zu den statischen Parametern gehören: die Länge des Übertragungsintervalls TTI (Transmission
Time Interval) , d.h. das Zeitintervall, für das die physi- kaiische Schicht Daten zusammenhängend verarbeitet. Dieses kann 10, 20, 40 oder 80 Millisekunden lang sein. das Kodierungsschema zum Fehlerschutz die Länge der Redundanzinformationen zum Fehlerschutz CRC
(Cyclic Redundancy Check) Die dynamischen Parameter sind:
- RLC-Größe (RLC-Size) : Da das MAC Protokoll weder MAC-PDUs generiert, noch die von RLC empfangenen RLC-PDUs segmen- tiert oder aneinander hängt, korrespondiert eine MAC-PDU solange mit genau einer RLC-PDU, wie das MAC Protokoll der RLC-PDU keinen Kontrolldatenkopf , einen sogenannten MAC- header, voranstellt. Stellt das MAC Protokoll den RLC-PDUs einen Kontrolldatenkopf voran, so ist die MAC-PDU um die Länge des MAC-headers größer als die RLC-PDU. Mit diesem Parameter wird also sowohl die Größe der RLC-PDU als auch die Größe der MAC-PDU eingestellt. Der auf dem Transportkanal an die physikalische Schicht übergebene Datenblock, die MAC-PDU, wird auch Transport-Block genannt.
- Anzahl der Transport-Blöcke (Number of Transport Blocks) : Dieser Parameter bestimmt die Anzahl der MAC-PDUs, die während eines TTIs an die physikalische Schicht zur gleichzeitigen Verarbeitung und den Transfer über die Luftschnittsteile übergeben werden dürfen. Wie man erkennt, ergibt sich aus den Parametern TTI, RLC- Größe und Anzahl der Transport-Blöcke die augenblickliche Datenrate des Transportkanals, die von dem MAC Protokoll dyna- misch durch Auswahl der verschiedenen Transport-Formate, also durch Variation des TTI, der RLC-Grδße und Anzahl der Transport-Blöcke eingestellt werden kann.
Über die dynamische Auswahl einer TFC für jedes Übertragungs- intervall (TTI) hinaus hat das MAC Protokoll, wie eingangs schon erwähnt, die Aufgabe, die auf den verschiedenen RBs ankommenden Daten unter Berücksichtigung des für die RB eingestellten Dienstleistungsqualität QoS (Quality of Service) auf die Transportkanäle zu verteilen. Der Qos eines RB beschreibt dessen Übertragungsdienstqualität, die während der Dauer der Mobilfunkverbindung durch die Protokolle der Schicht 2 sowie der physikalischen Schicht gewährleistet werden soll. Der QoS zeichnet sich dabei beispielsweise durch eine bestimmte garantierte Datenrate und/oder eine maximale Übertragungsverzδ- gerung aus. Das RRC-Protokoll handelt dazu beim Aufbau und der Rekonfiguration von RBs z.B. aus, welche logischen Kanäle auf welche Transportkanäle abzubilden sind, wobei jedem Transportkanal mehrere logische Kanäle zugeordnet werden können.
In Figur 3 ist die auf den UMTS-FDD-Modus reduzierte Architektur des MAC-Protokolls im RNC dargestellt, wobei für jedes UE, das von einem RNC versorgt wird, eine separate dedizierte MAC-Einheit MAC-d (MAC-dedicated) vorhanden ist. In Figur 3 haben bereits beschriebene Abkürzungen die gleiche Bedeutung. Über die MAC-d Einheit werden ausschließlich UE-spezifische Nutz- und Kontrolldaten, die über die entsprechenden Logischen Kanäle, den dedizierten Verkehrskanal DCCH (Dedicated Traffic Channel) und den dedizierten Steuerungskanal DTCH (Dedicated Control Channel) zur MAC-d Einheit gelangen, in
DL-Richtung gesendet und in UL-Richtung empfangen werden. Dabei ist für jede Übertragungsrichtung mindestens ein separa- ter Transportkanal, ein sogenannter dedizierten Transportkanal DCH (Dedicated Channel) , vorhanden. Ein solcher DCH wird von der physikalischen Schicht auf einen oder mehrere dedi- zierte physikalische Kanäle DPCH (Dedicated Physical Channel) abgebildet und über die Luftschnittstelle übertragen. Über die in Figur 3 dargestellte MAC-Steurungs/Verteilt-Einheit MAC-c/sh (MAC-control/shared) werden hingegen im allgemeinen Nutz- und Kontrolldaten übertragen die nicht UE spezifisch sind. Diese Daten gelangen über die logischen Kanäle Gemein- same Verkehrssteuerung CTCH (Common Traffic Channel) und Gemeinsamer Steuerungskanal CCCH (Common Control Channel) zur MAC-c/sh Einheit. Der CTCH ist nur in DL-Richtung existent und wird über den Transportkanal FACH (Forward Access Channel) zur physikalischen Schicht übertragen. Der CCCH hingegen ist sowohl in DL- als auch im UL-Richtung existent und wird daher im DL von dem FACH und im UL von einem Direktzugriffskanal RÄCH (Random Access Channel) getragen. Des weiteren können über die MAC-c/sh Einheit auch Systeminformationen transportiert werden, die für alle UEs gleich sind. Die Sys- teminformationen erreichen die MAC-c/sh Einheit über den Logischen Kanal BCCH (Broadcast Control Channel) . Der BCCH ist ein Rundfunksteuerungskanal und nur in DL-Richtung existent und kann im Allgemeinen auf zwei unterschiedliche Transportkanäle abgebildet werden. Zum einen kann der BCCH ebenfalls vom FACH getragen werden, zum anderen kann er durch eine weitere MAC Einheit, die in Figur 3 nicht dargestellt ist und als MAC-Übertragungseinheit MAC-b (MAC-broadcast) bezeichnet wird, auf den Transportkanal BCH (Broadcast Channel) abgebildet werden.
Die MAC-c/sh Einheit ist auch fähig, UE-spezifische Nutz- und Kontrolldaten zu senden bzw. zu empfangen. Dies ist zum einen der Fall, wenn ein UE z . Zt . keinen dedizierten Transportkanal DCH aufgebaut hat, aber dennoch geringere Mengen an UE- spezifische Daten empfangen oder senden möchte. Aus Sicht des
RNC werden in solch einem Fall im DL die Daten von der MAC-d Einheit zur MAC-c/sh Einheit geleitet, woraufhin diese Ein- heit die Daten über den FACH an die Physikalische Schicht ü- bergibt. In UL-Richtung werden in solch einem Fall die Daten auf dem RÄCH empfangen, um dann vom MAC-c/sh zum MAC-d weiter geleitet zu werden.
Zum anderen kann ein UE zwar ein DCH aufgebaut haben, wobei jedoch dessen Kapazität zwischenzeitlich zu gering ist, um eine gewisse Datenmenge in einem bestimmten Übertragungsintervall zu übertragen. Diese Situation kann beispielsweise bei einem Datenstrom vorliegen, der in seinem zeitlichen Verlauf Spitzen, sogenannte „Peaks", in der Datenmenge aufweist und den man im allgemeinen als Datenstrom BDS (Bursty Data Strea ) bezeichnet. Um dem UE zu ermöglichen, die geforderte Menge an Daten in einem bestimmten Übertragungsintervall zu empfangen, werden ihm daher für den entsprechende Zeitraum zusätzliche Kapazitäten zur Verfügung gestellt. Die zusätzlichen Kapazitäten bestehen in einem sogenannten verteilten Kanal bei einer Übertragung in Downlink-Richtung DSCH (Downlink Shared Channel) . Es handelt sich dabei um einen Transportka- nal, der nur in DL-Richtung existent ist und den sich mehrere
UEs gemeinsam teilen, um über diesen dedizierte Daten zu empfangen. Dabei ist der DSCH zu einem bestimmten Zeitpunkt und für eine bestimmte Dauer immer nur maximal einem UE zugewiesen. Zu einem anderen Zeitpunkt hingegen ist es ohne weiteres möglich, dass die selben DSCH Ressourcen einem anderen UE zugeteilt sind. Der DSCH wird dabei von der physikalischen Schicht auf einen oder mehrere physikalische verteilte Kanäle bei einer Übertragung in Downlink-Richtung PDSCH (Physical Downlink Shared Channel) abgebildet, welche unter anderem wieder durch spezifische Spreizkodes gekennzeichnet sind.
Die Funktion des MAC-Protokolls lässt sich nun zusammenfassend wie folgt beschreiben: Das sendende MAC-Protokoll sucht sich für jedes TTI und für jeden TrCH ein Transport Format aus (also insgesamt eine TFC) und bestimmt von welchen LogCHs
Daten in dem betrachteten TTI übertragen werden. Dann teilt das MAC-Protokoll den entsprechenden RLC-Einheiten die zum jeweiligen TF gehörende RLC-PDU-Größe' und die Anzahl der erwarteten RLC-PDUs mit. Die RLC-Protokolle übergeben daraufhin die entsprechende Anzahl an RLC-PDUs auf dem entsprechenden logischen Kanal an das MAC-Protokoll. Dieses fügt den Daten ggf. ein MAC-Kopffeld hinzu und übergibt die gesamten MAC- PDUs für einen Transportkanal gleichzeitig an die physikalische Schicht. Dabei übergibt das MAC-Protokoll der physikalischen Schicht zusätzlich das für das TTI aktuelle TFI eines jeden Transportkanals .
Nachfolgend wird die Physikalische Schicht beschrieben: Die Physikalische Schicht hat die Aufgabe, die vom MAC Protokoll über die Transportkanäle erhaltenen Daten innerhalb der entsprechenden TTIs der Transportkanäle über die Luftschnitt- stelle zu senden. Dazu bestimmt die Physikalische Schicht anhand der vom MAC Protokoll übermittelten TFIs der einzelnen TrCHs unter anderem die Länge der Redundanzinformationen zum Fehlerschutz (CRC) , das Kanalkodierungsverfahren, die Koderate sowie die Dauer des TTI in dem die Daten eines TrCH über die Luftschnittstelle transportiert werden sollen. Mit diesen Informationen berechnet die physikalische Schicht für jeden Transport Block eines TrCH, der in dem entsprechenden TTI ü- bertragen werden soll, die CRC-Summe und hängt diese den Daten an. Alle Transport Blöcke eines TTI eines TrCH werden daraufhin gemeinsam kanalkodiert, um sie vor Übertragungsfehler, die durch den Übertragungskanal verursacht werden können, zu schützen. Nach dem alle Daten eines Transportkanals noch durch weitere Maßnahmen, die in der technischen Spezifikation TS 25.212 „Multiplexing and Channel coding (FDD)" des 3rd Generation Partnership Projects (3GPP) , März 2001, näher beschrieben sind, für die Übertragung über die Luftschnittstelle vorbereitet wurden, werden die Daten aller Transport- kanäle auf einen internen Kanal in der physikalischen Schicht gemultiplext . Dieser Kanal wird als Zusammengesetzter- Codierter-Transportkanal CCTrCH (Coded Composit Transport
Channel) bezeichnet. Dabei werden im Allgemeinen alle dedizierten Transportkanäle (DCHs) eines UE auf einen CCTrCH und alle DSCHs eines UE auf einen weiteren separaten CCTrCH abgebildet. Von einem CCTrCH werden die zu sendenden Daten dann wiederum auf die entsprechenden physikalischen Kanäle abgebildet, die für die Übertragung der Daten über die Luft- schnittsteile verantwortlich sind. Dabei werden die Daten des CCTrCH, der die dedizierten Transportkanäle (DCHs) eines UE trägt, auf DPCHs abgebildet und die Daten des CCTrCH, der die DSCHs eines UE trägt, auf PDSCHs abgebildet. Vor dem Senden der Daten über die Luftschnittstelle werden diese dann noch moduliert und mit dem für den entsprechenden DPCH bzw. PDSCH spezifischen Spreizkode kodiert, d.h. gespreizt.
Um der physikalischen Schicht im Empfänger dabei die Möglichkeit zu geben, die über die verschiedenen DPCHs bzw. PDSCHs empfangenen Daten wieder richtig zu dekodieren, d.h. die für die Anpassung der Daten an die Luftschnittstelle vorgenommenen Maßnahmen (Spreizung, Modulation, Multiplexen, Kanalkodierung, usw.) wieder rückgängig zumachen, sowie dem MAC- Protokoll im UE die Möglichkeit zu geben, die über die Trans- portkanäle empfangenen Daten fehlerfrei auf die logischen Kanäle zu demultiplexen, ermittelt die physikalische Schicht des Senders aus den TFIs der Transport Kanäle die für das aktuelle TTI gültige TFC und daraus wiederum den zugehörigen TFCI . Ein solcher TFCI hat im allgemeinen eine Länge von 10 Bit und wird zusammen mit den Daten des CCTrCH, der die dedizierten Transportkanäle trägt, über einen DPCH zum UE übertragen. Das UE kann somit anhand des empfangenen TFCI die senderseitig an den Daten vorgenommenen Maßnahmen rückgängig machen und so die Daten im allgemeinen fehlerfrei dekodieren. Dabei ist der TFCI im Allgemeinen für jeden CCTrCH spezifisch, d.h. ein UE, das zwei CCTrCH konfiguriert bekommen hat (einen für DCHs und einen für DSCHs) , müssen zwei unterschiedliche TFCIs mitgeteilt werden. Um Übertragungskapazitäten zu sparen wird zu einem UE jedoch zumeist nur ein einzi- ger 10 Bit Langer TFCI gesendet. Wie vorstehend beschrieben wurde, dient ein DSCH, der von der physikalischen Schicht im Sender auf einen separaten CCTrCH und von diesem auf einen oder mehrere PDSCHs abgebildet wird, im Allgemeinen zum Abbau von Datenspitzen, die beispielsweise bei sogenannten „Bursty Data Streams" (BDS) vorkommen. Die Charakteristik eines solchen BDS beinhaltet dabei, dass die Datenpeaks generell unregelmäßig und plötzlich vorhanden sind. Somit muss der Sender (RNC) die Möglichkeit haben, dem UE die zusätzlichen Kapazitäten, die zur Übertragung der Da- tenpeaks benötigt werden und die in Form der PDSCHs vorhanden sind, schnell und unkompliziert bekannt zu machen. Aus diesem Grund ist eine explizite Signalisierung der zusätzlichen Ressourcen nicht sinnvoll, da sie zuviel Zeit in Anspruch nehmen würde. Es müsste nämlich zunächst eine Konfigurationsnach- rieht vom RRC im RNC zum RRC im UE über die Luftschnittstelle gesendet werden, um mit den in der Nachricht enthaltenden Parametern die physikalische Schicht und das MAC-Protokoll des UE zu konfigurieren. Daher werden dem UE die zusätzlichen Kapazitäten durch den RNC implizit mitgeteilt. Dazu wird der zuvor bereits erwähnte 10 Bit lange TFCI genutzt.
Bei der Konfiguration eines RB, dessen Datenfluss die Charakteristik eines BDS aufweist, ist der konfigurierenden Einheit (RNC) bewusst, dass in DL-Richtung von Zeit zu Zeit zusätzli- ehe Kapazitäten in Form eines oder mehrerer PDSCHs benötigt werden, um in einem bestimmten Zeitrahmen, einem sogenannten „Frame", eine geforderte Menge an Daten zum UE zu übertragen. Das hat -zur Folge, dass im DL für das UE ein DSCH konfiguriert wird. D.h., dem UE werden die erforderlichen Parameter, die zum Empfang eines DSCH benötigt werden, mitgeteilt. Dazu gehört unter anderem das TFS des DSCH, das TFCS des zum DSCH gehörenden CCTrCH und die spezifischen Spreizkodes der PDSCHs, auf die ein oder mehrerer DSCH abgebildet werden. Die RRC (Re-) Konfigurationsnachricht, die die zuvor beschriebenen Parameter einem UE bekannt macht, kann in verschiedenen Formen beispielsweise als Funkstütze-Aufbau, das sogenannte „RADIO BEARER SETUP", als Funkstü ze-Rekonfiguration, das so- genannte „RADIO BEARER RECONFIGURATION" oder als Transportkanal-Rekonfiguration, das sogenannte „TRANSPORT CHANNEL RECONFIGURATION" vorliegen. Schematisch ist in Figur 4 die in der technischen Spezifikation TS 25.331 „Radio Resource Control", des 3rd Generation Partnership Projects (3GPP) ,
März 2001, beschriebene „RADIO BEARER SETUP"-Nachricht dargestellt. Diese Nachricht kann die für den Aufbau mehrerer RB benötigten Informationen enthalten und somit auch die Informationen für den Aufbau mehrerer DSCHs. Figur 4 sowie die Fi- guren 5 und 6 zeigen dabei auf, an welcher Stelle in der „RB SETUP"-Nachricht die zuvor erwähnten Parameter durch sogenannte Informationselemente (IEs) einem UE mitgeteilt werden. Schon definierte Ausdrücke haben dabei wieder die gleiche Bedeutung. Ein nachgestelltes „IE" bedeutet nachfolgend, dass es sich bei den bereits erläuterten Abkürzungen jeweils um ein Informationseiement handelt. MS bedeutet Typ der Nachricht .
Das TFS eines jeden DSCHs wird einem UE explizit durch das IE „TFS" (Transport Format Set) signalisiert. Im Allgemeinen ist dieses IE in der „RB SETUP"-Nachricht für jeden Transportkanal der aufgebaut werden soll einmal enthalten, unabhängig davon ob es sich dabei um einen DCH oder einen DSCH handelt . Mit dem „TFS" bekommt das UE für jedes TF im TFS des entspre- chenden Transportkanals die dynamischen Parameter (RLC-Größe, Anzahl der Transport-Blöcke) sowie einmalig die für das TFS konstanten semi-statischen Parameter übermittelt. Wie Figur 4 zu entnehmen ist, wird das IE „TFS" in dem IE „Add/Reconf . DL TrCH info#l,2" (#22 in Figur 4) übertragen. In diesem ist au- ßer dem IE „TFS" (#23 in Figur 4) noch ein weiterer wichtiger Parameter enthalten, der als „DCH Qualitätsziel" bezeichnet wird. Anhand dieses Parameters legt das UE den Referenzwert des Signal-Störabstandes SIR (Signal-to-Interference Ratio) für die für einen Transportkanal benötigten DPCHs bzw. PDSCHs fest. Wird dieser Wert beispielsweise in DL-Richtung unter- oder überschritten, signalisiert das UE dem Sender, dass dieser die Sendeleistung im nächsten Zeitrahmen erhöhen oder verringern soll. Somit ist der Parameter „DCH Qualitätsziel" für die Leistungsregelung der den DSCHs zugehörigen PDSCH erforderlich.
Das TFCS des CCTrCH, auf den ein oder mehrere DSCHs von der physikalischen Schicht im Sender abgebildet werden, um dann auf die verschiedenen PDSCHs verteilt zu werden, bekommt das UE durch das IE „TFCS" (Transport Format Kombination Set) mitgeteilt, welches im IE , Gemeinsame Transportkanalinforma- tion für alle Transportkanäle 4 DLTrCHIcf TrCH (DL Transport Channel Information common for all transport Channels) enthalten ist.
Wie man Figur 5 entnehmen kann, werden im IE „TFCS" einem UE zunächst Informationen über die Konfiguration des zuvor schon erwähnten TFCI mitgeteilt, welcher während der Übertragung in jeden Rahmen zusammen mit den Daten auf einen DPCH zum UE gesendet wird. Erfordert z.B. keiner der für ein UE aufzubauenden RB einen DSCH, wird der TFCI durch das IE „TFCS" als „Normal" konfiguriert. D.h., alle 10 Bits des TFCI beschreiben für jeden Rahmen ausschließlich die TFC des CCTrCH, der die dedizierten Kanäle (DCHs) eines UE trägt. Erfordert hingegen nur einer der für ein UE 'aufzubauenden RB einen DSCH wird dem TFCI ein sogenannter „Split" konfiguriert, d.h. der TFCI besteht in diesem Fall aus zwei Feldern. Man spricht in diesem Zusammenhang von TFCI Feld 1 und TFCI Feld 2. Dabei wird die Länge des zweiten Feldes explizit in dem IE mitgeteilt (Länge des TFCI (Feld 2)), woraus sich die Länge des ersten Feldes implizit ergibt. Während der Übertragung von Daten beinhaltet das TFCI Feld 1 dabei den TFCI des CCTrCH, der die dedizierten Transportkanäle des UE trägt, und das TFCI Feld 2 beinhaltet den TFCI des CCTrCH auf den die DSCHs eines UE abgebildet werden. Die eigentlichen TFCSs der entsprechenden CCTrCHs werden dem UE durch die IE „TFCI Feld 1 Info" und „TFCI Feld 2 Info" bekannt gemacht. In dem IE „TFCI Feld 2 Info" ist unter anderem wiederum das IE „TFCS explizite Konfiguration" enthalten, welches jedem Wert des TFCI Feld 2 eine TFC des TFCS zuordnet . Auf diesem Weg wird einem UE somit das TFCS des CCTrCH bekannt gemacht, der die DSCHs des entsprechenden UE trägt (#24 in Figur 5) . Wann die physikalische Schicht des UE nun einen oder mehrere PDSCHs zu empfan- gen hat, um über diese zusätzliche Daten auf einem oder mehreren DSCHs zu erhalten, wird dem UE also durch den Empfang des insgesamt 10 Bit langen TFCI signalisiert. Diese Signalisierung findet dabei im Allgemeinen immer ein Zeitrahmen im Voraus statt, d.h. einen Zeitrahmen vor dem entsprechenden Zeitrahmen in dem das UE zusätzliche Daten auf einen oder mehreren DSCHs empfangen soll. Korrespondiert der Wert eines empfangenen TFCI Feld 2 nun mit einer TFC, die dem UE anzeigt, dass das MAC-Protokoll im Sender (RNC) für den nächsten Zeitrahmen auf keinen der für das UE konfigurierten DSCHs Daten abbildet, so ist dem UE bekannt, dass es im nächsten
Zeitrahmen keine Daten auf einem PDSCH zu empfangen hat. Signalisiert der Wert des TFCI Feld 2 einem UE hingegen, das das MAC-Protokoll im Sender (RNC) im nächsten Zeitrahmen Daten auf einen der für das UE konfigurierten DSCHs abbildet, ist dem UE bekannt, das es im nächsten Zeitrahmen zusätzliche Daten auf einen oder mehreren PDSCHs zu empfangen hat . Damit das UE nun weiß auf welchen und wie vielen PDSCHs es zusätzliche Daten empfangen soll, ist mit dem Wert des TFCI Feld 2 nicht nur die aktuelle TFC des entsprechenden CCTrCH verbun- den, sondern zusätzlich noch die Information über die Spreizkodes der PDSCHs, auf denen die zusätzlichen Daten vom Sender zum UE gesendet werden. D.h., mit jedem Wert des TFCI Feld 2 sind außer einer TFC für den entsprechenden CCTrCH noch die entsprechenden Spreizkodes der PDSCHs verbunden, die die Da- ten eines oder mehrerer DSCHs übertragen. Die Zuordnung von den Spreizkodes der benötigten PDSCHs zu den Werten des TFCI Feld 2 wird dem UE dabei ebenfalls durch die „RB SETUP"- Nachricht bekannt gemacht. In dieser Nachricht sind unter den „PhyCH" die IEs enthalten, die einem UE die zum Empfang der physikalischen Ressourcen benötigten Parameter mitteilen. Die zum Empfang eines bzw. mehrerer PDSCHs benötigten Parameter werden einem UE beispielsweise durch das IE „PDSCH DL Infor- mation" signalisiert, das unter anderem wiederum das IE „PDSCH Code Mapping" enthält ( #25 in Figur 6) . In dem zuletzt genannten IE ist dabei die Zuordnung von einem oder mehreren Spreizkodes (entsprechend einem oder mehreren PDSCHs) zu den Werten des TFCI Feld 2 enthalten.
Wird ein UE nun auf die zuvor beschriebene Weise konfiguriert, kann es für jeden Zeitrahmen ermitteln, ob es im darauf folgenden Zeitrahmen von der Sendeeinheit (RNC) zusätzli- ehe Ressourcen in Form von PDSCHs zugeteilt bekommen hat, wie viele zusätzliche Ressourcen es bekommen hat und mit welchen Spreizkode die entsprechenden Ressourcen (PDSCHs) kodiert wurden. Dabei wird betont, dass sowohl die hier beschriebene Konfigurationsnachricht „RADIO BEARER SETUP" als auch die Konfigurationsnachrichten „RADIO BEARER RECONFIGURATION" und „TRANSPORT CHANNEL RECONFIGURATION" im allgemeinen über einen dedizierten logischen Kontrollkanal (DCCH) vom RRC im RNC zum RRC im UE gesendet werden. Somit sind die durch die Konfigurationsnachrichten für den Empfang von DSCHs und den zugehö- rigen PDSCHs vorgenommenen Einstellungen nur dem entsprechenden UE bekannt. Dies ist sinnvoll, da die Ressource eines DSCHs zu einem bestimmten Zeitpunkt auch immer nur einem UE zugeordnet bzw. zugeteilt werden kann. Für verschiedenen Anwendungen ist es dabei aber denkbar, dass die auf einen oder mehreren DSCHs gesendeten Daten von mehreren UEs gleichzeitig empfangen werden sollen. Dies setzt dann natürlich voraus, dass die Konfiguration der DSCHs für alle UEs gleich sein muss. Dafür muss nach dem Stand der Technik zu jedem UE, das die Daten auf den entsprechenden DSCHs empfangen soll, eine separate Konfigurationsnachricht über einen DCCH vom RRC im
RNC zum RRC im UE gesendet werden. Dies reduziert jedoch die freien Übertragungskapazitäten der Luftschnittstelle in unnötiger Weise. Der PDSCH ist ein reiner Datenkanal, d.h. über ihn werden keinerlei Signalisierungsdaten vom Sender (physi- kaiische Schicht in der Node B) zum UE gesendet. Daher kann der PDSCH im UMTS-FDD-Modus auch immer nur in Verbindung mit einem DPCH in DL-Richtung und einem DPCH in UL-Richtung exis- tieren. Dies ist nicht nur darin begründet, dass ein UE den TFCI des CCTrCH, der die DSCHs des UE trägt, über einen DPCH mitgeteilt bekommt, sondern es ist auch darin begründet, dass die gesamte Leistungsregelung der für ein UE konfigurierten PDSCHs über die DPCHs durchgeführt wird. Zur Leistungsregelung sendet der Sender (Node B) im Sendeleistungs- Steuerungskanal bei einer Übertragung in Downlink-Richtung DL-TPC (Transmit Power Control) Bits zusammen mit den TFCI Bits über den DPCH zum UE. Diese TPC Bits signalisieren dem UE, ob es die Sendeleistung im UL erhöhen oder verringern soll . Auf dem DPCH des UL sendet das UE dementsprechend TPC Bits, die der NodeB signalisieren, das sie die Sendeleistung im DL zu erhöhen oder zu verringern hat . Abhängig von diesen TPC Bits erhöht bzw. verringert die NodeB die Sendeleistung der DPCHs sowie der PDSCHs . Somit kann ein bekannter PDSCH nicht ohne DPCHs existieren.
Somit liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein Verfahren und ein System zum Übertragen von Daten in ei- nem Mobilfunksystem bereitzustellen, bei dem der benötigte Signalisierungsaufwand über die Luftschnittstele gering gehalten wird.
Diese Aufgabe wird durch ein Verfahren zum Übertragen von Da- ten in einem Mobilfunksystem, insbesondere UMTS, mit den Merkmalen des Anspruchs 1 gelöst .
Das Verfahren zum Übertragen von Daten in einem Mobilfunksystem, insbesondere UMTS, weist die Verfahrensschritte - Senden von Parametern für den Empfang eines mehrfach genutzten Kanals von einer Basisstation an eine Mobilstation,
- Auswerten der Parameter in der Mobilstation, und
- Empfangen von von der Basisstation ausgesendeten Daten über den mehrfach genutzten Kanal durch die MobilStation, wobei der Empfang durch die Parameter ermöglicht wird, auf . Die Parameter sind dabei allen durch die Basisstation versorgten Mobilstationen bekannt. Bei dem mehrfach genutzten Kanal handelt es sich bevorzugt um einen gemeinsam genutzten Kanal bei einer Übertragung in Downlink-Richtung DSCH. Die Parameter werden in der mindestens einen Mobilstation ausgewertet, woraufhin über den mehrfach genutzten Kanal von der Mobilstation Daten empfangen werden. Ein solcher Empfang wird durch die Parameter ermöglicht. Bevorzugt werden die Parameter per Rundfunk in das Versorgungsgebiet der Mobilstation ausgesendet. Bei dieser sogenannten "Broadcast "-Übertragung werden folglich allen nutzenden Mobilstationen in dem Versorgungsgebiet der Basisstation die Parameter bekannt gemacht.
Bei dem mehrfach genutzten Kanal handelt es sich bevorzugt um einen Kanal, welcher hauptsächlich zur Übertragung von Datenspitzen genutzt wird. Es werden darüber folglich Daten übertragen, deren Übertragung bei einer Übertragung über normalerweise vorhandene Übertragungswege nicht gewährleistet werden könnte.
In einer Weiterbildung der vorliegenden Erfindung werden die Parameter mit einer Sendeleistung übertragen, die gewährleistet, dass die Parameter überall in dem Versorgungsbereich der Basisstation empfangen werden können.
In einer weiteren Ausführungsform der vorliegenden Erfindung werden die Daten gleichzeitig von einer Vielzahl von Mobilstationen empfangen. Dies gewährleistet, dass die Daten über den mehrfach genutzten Kanal auch von dieser Vielzahl von Mo- bilstationen empfangen werden können.
In einer Weiterbildung der vorliegenden Erfindung handelt es sich bei den Daten um an eine Gruppe von an Mobilstationen gleichzeitig versandte Daten. Dabei handelt es sich bevorzugt um die Multicast-Gruppen bzw. Multicast-Daten. Die eingangs gestellte Aufgabe wird auch durch ein System zum Übertragen von Daten in ein Mobilfunksystem, insbesondere UMTS, mit den Merkmalen des unabhängigen Anspruchs 8 gelöst. Das System zum Übertragen von Daten in ein Mobilfunksystem, insbesondere UMTS, weist Mittel zum Senden von Parametern für den Empfang eines mehrfach genutzten Kanals von einer Basisstation an eine Mobilstation, Mittel zum Auswerten der Para- meter in der Mobilstation, und Mittel zum Empfangen von von der Basisstation ausgesendeten Daten über den mehrfach ge- nutzten Kanal durch die Mobilstation, wobei der Empfang durch die Parameter ermöglicht wird, auf. Die Parameter werden allen durch die Basisstation versorgten Mobilstationen bekannt gemacht .
Die vorliegende Erfindung betrifft des Weiteren eine Mobil- Station zur Verwendung bei einem erfindungsgemäßen Verfahren und/oder in einem erfindungsgemäßen System. Darüber hinaus betrifft die vorliegende Erfindung auch eine Basisstation zur Verwendung bei einem erfindungsgemäßen Verfahren und/oder in einem erfindungsgemäßen System.
Bei der vorliegenden Erfindung werden die für den Empfang von DSCHs (bzw. PDSCHs) benötigten Parameter allgemein bekannt gemacht, um mehreren Mobilfunk-Endgeräten die Möglichkeit zu geben, gleichzeitig Daten auf den DSCHs (bzw. PDSCHs) zu empfangen, und dabei den benötigten Signalisierungsaufwand über die Luftschnittstele möglichst gering zu halten.
Ein Vorteil der Erfindung liegt darin, dass die zum Empfang der DSCHs (bzw. PDSCHs) benötigten Parameter nicht jedem UE separat über einen DCCH mitgeteilt werden müssen, wenn DSCHs (bzw. PDSCHs) zeitgleich von mehreren Mobilfunk-Endgeräten empfangen werden sollen. Somit wird der Signalisierungsaufwand über die Luftschnittstelle effektiv verringert, was ei- ner Einsparung von Übertragungs-Kapazitäten gleichzusetzen ist. Die eingesparten Übertragungskapazitäten können zur Übertragung von Nutzdaten verwendet werden. Dies hat den po- sitiven Effekt, dass die Nutzdatenrate des Mobilfunksystems erhöht und die Signalisierungsrate des Mobilfunksystems verringert wird.
Ein weiterer Vorteil der vorliegenden Erfindung ist, dass die entsprechenden Parameter durch die allgemeine Bekanntmachung in einem Mobilfunk-Endgerät bereits bekannt sind, auch wen der Empfang von Daten zeitgleich mit anderen Mobilfunk- Endgeräten auf einem oder mehreren DSCHs (bzw. PDSCHs) für das entsprechende Mobilfunk-Endgerät noch gar nicht vorgesehen ist. Soll das entsprechende Mobilfunk-Endgerät nun zeitgleich mit anderen Mobilfunk-Endgeräten-Daten auf einem oder mehreren DSCHs (bzw. PDSCHs) empfangen, können die für den Empfang der Daten benötigten Parameter sofort etabliert wer- den. Somit ist der Zeitbedarf zur Konfiguration eines Mobil- funk-Endgerätes für den Empfang von Daten auf dem DSCHs (bzw. PDSCHs) im Allgemeinen sehr viel geringer, als bei den bekannten Lösungen, bei denen zunächst eine Konfigurations- Nachricht zum Mobilfunk-Endgerät gesendet werden muss.
Die Erfindung wird im Folgenden unter Hinweis auf die beigefügten Zeichnungen anhand von Ausführungsbeispielen näher erläutert. Die dort dargestellten Merkmale und auch die bereits oben beschriebenen Merkmale können nicht nur in der genannten Kombination, sondern auch einzeln oder in anderen Kombinationen erfindungswesentlich sein. Es zeigen:
Figur 1 eine schematische Darstellung eines UMTS-Netzwerks; Figur 2 eine schematische Darstellung der Protokoll- Architektur der UMTS-Schichten 2 und 3;
Figur 3 eine schematische Darstellung einer reduzierten
MAC-Architektur; Figur 4 eine schematische Darstellung einer Funkstütze- Aufbau-Nachricht ; Figur 5 eine DL-Transportkanal-Information gemeinsam für alle Transportkanäle; Figur.6 eine schematische Darstellung physikalischer Kanal- Informations-Elemente;
Figur 7 einen System-Informationsblock Typ 6;
Figur 8 ein Ausführungsbeispiel eines System- Informationsblocks Typ 6;
Figur 9 ein Ausführungsbeispiel eines System- Informationsblocks Typ 6.
Die Figuren 1 bis 6 wurden bereits vorstehend bei der Einlei- tung der Beschreibung beschrieben, so dass auf diese Beschreibung Bezug genommen wird.
Im nachfolgenden Ausführungsbeispiel wird von einem Multicast-Service in einem UMTS Mobilfunksystem ausgegangen. Die- ser Multicast-Service beinhaltet das Versenden von Daten, die im allgemeinen für eine Gruppe von Mobilfunkteilnehmer bestimmt sind, über einen einzigen gemeinsamen Kanal, um Übertragungskapazitäten der Luftschnittstelle einzusparen. Die Funktionen und Aufgaben eines solchen Kanals kann dabei bei- spielsweise der bereits beschriebene DSCH-Kanal übernehmen. Ein DSCH, der die Funktion eines solchen Kanals übernimmt, wird daher im Folgenden als MC-DSCH „Multicast Downlink Shared Channel" bezeichnet. Dieser MC-DSCH ist dabei prinzipiell mit einem üblichen DSCH nach dem Stand der Technik identisch. Ein Unterschied zum bekannten DSCH ist, dass der MC-DSCH zu einem bestimmten Zeitpunkt nicht nur einem Mobilfunkteilnehmer bzw. UE zugeordnet ist, sondern mehreren UEs gleichzeitig zugeordnet sein kann. Die Mobilfunkteilnehmer, die zeitgleich einen MC-DSCH empfangen, gehören dabei im allgemeinen der selben Multicastgruppe (MC-Gruppe) an. Somit ist ein MC-DSCH zu einem bestimmten Zeitpunkt immer nur einer bestimmten MC- Gruppe zugewiesen.
Davon ausgehend das innerhalb eines Übertragungszeitrahmens, einem sogenannten Frame, immer nur ein MC-DSCH auf einen entsprechenden CCTrCH abgebildet wird, sind für alle Mobilfunkteilnehmer, die den MC-DSCH zur gleichen Zeit empfangen sollen, die zum Empfang des MC-DSCH benötigten Parameter iden- tisch. Die Parameter, die die entsprechenden UEs der Mobil- funkteilnehmer für den Empfang des MC-DSCH und der zugehörigen PDSCHs benötigen, sind dabei das TFS des MC-DSCH, das TFCS des CCTrCH auf den der MC-DSCH abgebildet wird sowie die Spreizkodes der PDSCHs auf den die UEs die Daten des MC-DSCH empfangen sollen. Geht man nun davon aus, dass für jede MC- DSCH eine eigener CCTrCH vorhanden ist, entspricht eine TFC des TFCS immer genau einem TF des TFS des MC-DSCH.
Die Leistungsregelung eines MC-DSCH kann nach zwei unterschiedliche Methoden durchgeführt werden. Zum einen kann die Leistungsregelung über die DPCHs der Teilnehmer einer MC- Gruppe durchgeführt werden und zum anderen über eine zusätzlichen eigens für den Multicastservice konzipierten physika- lischen Kanal. Diese beiden Methoden werden im Folgen unterschieden.
Für den Fall, dass ein Mobilfunkteilnehmer ausschließlich einen MC-DSCH empfangen will, und die Leistungsregelung des MC- DSCH über die TPC Bits der assoziierten DPCHs durchgeführt wird, dient der DPCH im DL lediglich zur Übermittlung des geteilten 10 Bit langen TFCI und der TPC Bits. Dies ist darin begründet, dass das MAC Protokoll im Sender keine Daten auf einen DCH abzubilden braucht. Somit ist es sinnvoll, eine Grundeinstellung für den auf den DPCH abgebildeten DCH allgemein bekannt zu machen. Mit Grundeinstellung ist dabei beispielsweise eine bestimmtes TF des DCH gemeint, das dem UE signalisiert, dass es keine Nutzdaten auf dem entsprechenden DCH zu empfangen hat. Dabei ist es aber auch möglich, dass für .den DCH das gesamte TFS und ein zugehöriges TFCS allgemein bekannt gemacht wird.
Für den Fall, dass die Leistungsregelung eines MC-DSCH über einen zusätzlichen physikalischen Kanal gewährleistet werden soll, wird ein physikalischer Kanal für die DL-Richtung beschrieben, der die TPC Bits aller einer MC-Gruppe zugehörigen UEs enthält und der als Multicast-Leistungskanal McPwCH (Mul- ticast Power Channel) bezeichnet wird. Über diesen Kanal wird jedem UE der MC-Gruppe mitgeteilt, ob es im nächsten Übertragungszeitrahmen die Sendeleistung im UL erhöhen soll oder nicht, damit dessen TPC Bits in UL-Richtung von der NodeB weiterhin fehlerfrei empfangen werden können. Ein solcher McPwCH wird dabei wiederum mit einem separaten für den Kanal spezifischen Spreizkode kodiert. Somit ist eine weiterer Parameter, der für den Empfang eines MC-DSCH und der zugehörigen PDSCHs benötigt wird, der Spreizkode mit dem der McPwCH kodiert wird.
Eine Variation des McPwCH beinhaltet, dass über ihn nicht ausschließlich TPC Bits gesendet werden. D.h., ein Teil der Gesamtkapazität des McPwCH kann für andere Kontrolldaten oder sogar auch für Nutzdaten reserviert sein. Betrachtet man nun den Fall, dass ein UE ausschließlich Daten eines Multi- castdienstes empfangen möchte und keine Daten über dedizierte Kanäle (DCHs) , benötigt das UE des Mobilfunkteilnehmers den zum MC-DSCH assoziierten DPCH, wie zuvor schon beschrieben, lediglich zur Übertragung des geteilten 10 Bit langen TFCI.
Da dies eine Verschwendung von Übertragungskapazitäten bedeutet, ist es sinnvoll, dass der TFCI des CCTrCH, auf den der MC-DSCH abgebildet wird, über den McPwCH zum UE gesendet wird. Der TFCI wird dabei innerhalb der für andere Kontroll- daten oder für Nutzdaten reservierten Übertragungskapazitäten des McPwCH übertragen. Somit benötigt das UE eines Mobilfunkteilnehmers, der ausschließlich einen oder mehrere Multi- castdienste empfangen möchte, keinen zum MC-DSCH assoziierten DCH und somit auch keinen DPCH. Da ein UE jedoch bei dem Auf- bau eines DCH bzw. des zugehörigen DPCH den im Stand der
Technik erwähnten Referenzwert für die Leistungsregelung mitgeteilt bekommt, würde das UE in dem hier beschriebenen Ausführungsbeispiel diesen Wert nicht erhalten. Das hätte zur Folge, dass ein UE in diesem Fall die Leistungsregelung nicht richtig durchführen könnte. Um zu gewährleisten, dass ein UE auch in dem Fall, dass mit einem MC-DSCH kein DCH bzw. DPCH verbunden ist, die Leistungsregelung richtig durchführen kann, muss ein weiterer Parameter allgemein bekannt gemacht werden, der als „MC-DSCH Qualitätsziel" bezeichnet wird.
Die zuvor beschriebenen Parameter sollen den UEs der Mobil- funkteilnehmer nun allgemein durch einen System- Informationsblock SIB (System Information Block) bekannt gemacht werden, anstatt sie durch eine separate Nachricht zu jedem UE zu übertragen. Im allgemeinen wird solch ein SIB vom RRC im RNC über den logischen Kanal BCCH zum MAC Protokoll gesendet. Das MAC-Protokoll bildet daraufhin den BCCH auf den Transportkanal BCH ab. Der BCH wird dann von der physikalischen Schicht im Sender (Node B) mit einer Leistung übertragen, die gewährleistet, dass der BCH überall in dem Versorgungsbereich der Node B empfangen werden kann. Die Informati- onen auf dem BCH können dabei von jedem im Versorgungsbereiche der Node B befindlichen UE ausgewertet werden. Somit werden die Information, die über den BCH gesendet werden, allgemein bekannt gemacht . Man spricht in diesem Zusammenhang vom „Broadcasten" von Systeminformationen. Die zum Empfang eines MC-DSCH und der zugehörigen PDSCHs benötigten Parameter könne den UEs der Mobilfunkteilnehmer einer MC-Gruppe nun entweder durch ein bereits im UMTS spezifizierten SIB mitgeteilt werden, der dann jedoch entsprechend modifiziert werden muss, oder sie können den UEs durch einen eigenen nur für den Mul- ticastdienst einzuführenden SIB bekannt gemacht werden.
Figur 7 zeigt tabellarisch den System Informationsblock Typ 6 (SIB 6) nach dem Stand der Technik. Dieser ist der Spezifikation des RRC Protokolls entnommen und wird in der technischen Spezifikation TS 25.331 „Radio Resource Control", des 3rd Generation Partnership Projects (3GPP) , März 2001, genauer beschrieben. In der Figur 7 sind in Zeilen die verschiedenen Informationselemente des SIB eingetragen und in der ersten Spalte der Name des Elements und ggf. eine hierarchische Gliederung des Elements mit Hilfe des Zeichens ">", in der zweiten Spalte eine Angabe darüber, ob das Element vorhanden sein muss (MP="Zwingend Notwendig", OP="Optional " , CV X="Bedingter Wert" also abhängig von X, wobei X unten definiert wird) , in der dritten Spalte ggf. eine Angabe über das mehrfache Vorhandensein des Elements und in weiteren Spalten weitere Informationen. Die Angabe "OP" bewirkt, dass in einer Bit-Representation das IE zunächst mit Informationen beginnt, die angeben, ob weitere Informationen dieses Elementes vorhanden sind. Da diese Information beispielsweise durch ein einzelnes Bit dargestellt werden können, können optionale Informationselemente bei Nicht-Vorhandensein der Information Übertragungsbandbreite sparen.
Wie Figur 7 zu entnehmen ist, wird im SIB 6 zwischen den beiden UMTS Modes FDD und TDD unterschieden. Die zuvor erwähnte hierarchische Gliederung der IEs durch das Zeichens ">" ist anhand dieser Unterscheidung zu erkennen. Das in Zeile 4 enthaltende Zeichen ">" bedeutet, dass alle nachfolgenden IEs mit dem Zeichen ">>" nur für den FDD Mode Gültigkeit haben, genauso wie alle IE, die nach Zeile 6 das Zeichen ">>" haben, nur für den TDD-Modus von Bedeutung sind. Dabei ist eine wei- terführende hierarchische Gliederung durch mehr als zwei Zeichen (>>>...) im allgemeinen möglich.
In Figur 8 (die sich über die Seiten 8 und 9 erstreckt) ist der für das Rundfunk-Übertragen von Multicastinformationen modifizierte SIB 6 abgebildet. Änderungen gegenüber dem Stand der Technik sind dabei in kursiver Schrift gezeigt. Da der SIB 6 Informationen übertragen soll, die unter anderem zum Empfang eines MC-DSCH benötigt werden, sind dem SIB 6 zunächst Transportkanal IEs hinzugefügt worden (Zeile 1 bis 7) . Setz man nun voraus, dass jede MC-Gruppe einen eigenen MC-
DSCH konfiguriert bekommt, besagt die Zeile 2 in Figur 8, dass alle in der Tabelle folgenden Elemente, die mit mindestens einem ">" eingerückt sind, sich so oft wiederholen, wie dieses IE angibt. Somit wird eine Liste von IEs erzeugt, die nach MC-Gruppen sortiert ist. D.h., die IEs in den Zeilen 3 bis 7 wiederholen sich für jede MC-Gruppe. Das IE in der Zeile 3 (MC-Gruppenidentität) identifiziert dabei die MC-Gruppe, für die die nachfolgenden IEs von Bedeutung sind. Mit dem IE 'TFS des MC-DSCH' (Zeile 4) wird nun der Transport-Format- Satz des für die MC-Gruppe konfigurierten MC-DSCHs allgemein bekannt gemacht und mit dem IE 'TFCS' der Transport-Format- Kombinationssatz des CCTrCH, auf den die Daten des MC-DSCH abgebildet werden. Mit dem fünften IE in der Liste wird für den zum MC-DSCH assoziierten DCH eine Grundeinstellung bzgl . des Transport Formats übertragen, wobei dieses IE jedoch optional vorhanden sein kann. Das letzte IE der Liste gibt den Referenzwert für die Leistungsregelung der PDSCH an, auf die der entsprechende MC-DSCH abgebildet wird.
Die für den Empfang der PDSCHs und die für den Empfang des McPwCH allgemein gültigen Informationen sind im SIB 6 unter den IEs der physikalischen Kanäle (Zeile 13 bis 17) eingefügt. Da diese Informationen auch wieder MC-Gruppen spezifisch sind, ist hier auch eine Liste von IEs vorhanden die nach den MC-Gruppen sortiert ist. D.h., wie zuvor bei den IEs für die Transportkanäle sind die nach Zeile 13 mit dem Zei- chen ">>>" eingerückten IEs für jede MC-Gruppe einmal vorhanden. Mit dem IE 'MC-Gruppenidentität' wird dabei wiederum die MC-Gruppe identifiziert, für die die nachfolgenden IEs (Zeile 15 bis 17) bestimmt sind. Das IE 'PDSCH Code Mapping' (Zeile 15) hat die gleiche Aufgabe wie beim Stand der Technik. Mit diesem IE wird die Zuordnung von TFCI (Feld 2) Werten zu den Spreizkodes (Kanalisierungscodes) der PDSCHs, die die Daten des MC-DSCH transportieren, übertragen. Die IEs 'Spreizfaktor (für McPwCH)' und 'Codenummer (für McPwCH)' beschreiben zusammen den Spreizkode (Kanalisierungscode) mit dem der McPwCH vor dem Senden über die Luftschnittstelle gespreizt wird.
Betrachtet man den Fall, dass im Sender (Node B) mehrere MC- DSCHs zeitmultiplext über einen CCTrCH gesendet werden, benötigt ein Teilnehmer, der nur ein bestimmten MC-DSCH und damit auch nur Informationen einer bestimmte MC-Gruppe empfangen möchte, ein TFCS das die Existenz aller über den CCTrCH übertragenen MC-DSCHs berücksichtigt. Somit ist ein solches TFCS nicht mehr für eine MC-Gruppe spezifisch, sondern ist für mehrere MC-Gruppen gleichermaßen gültig. Daher kann das IE 'TFCS' in solch einem Fall nach den MC-Gruppen spezifischen IEs im SIB 6 übertragen werden, wie es in Figur 9 (die sich über die Seiten 10 und 11 erstreckt) zu sehen ist. Änderungen gegenüber Figur 8 sind dabei in kursiver Schrift gezeigt.
Durch das Senden des modifizierten SIB 6 können die zum Empfang eines MC-DSCH und der zugehörigen PDSCH benötigten In- formationen allgemein bekannt gemacht werden. Somit brauchen diese Informationen nicht zu jedem UE einzeln über eine dedi- zierte Verbindung übertragen werden, wenn ein Mobilfunkteilnehmer einen Multicastdienst in Anspruch nehmen möchte. Das hat zur Folge, dass weniger Übertragungskapazitäten zum Auf- bau eines Multicastdienstes benötigt werden und sich der Signalisierungsaufwand effektiv verringern lässt. Ferner können die von einem UE über den SIB 6 empfangenen Parameter gespeichert werden, auch wenn das UE zum aktuellen Zeitpunkt noch keinen Multicastdienst empfangen möchte. Somit sind die zum Aufbau eines Multicastdienstes benötigten Parameter im UE bekannt und könne sofort etabliert werden, wenn das UE zu einem späteren Zeitpunkt an einem Multicastdienst teilnehmen möchte. Das hat zur Folge, dass der Aufbau einer Multicastverbin- dung im allgemeinen weniger Zeit in Anspruch nimmt .
Die zum Rundfunk-Übertragen vorgeschlagenen Parameter bzw. IEs können jedoch auch in einem separaten, eigens für Multi- castdienste einzuführenden SIB enthalten sein.

Claims

Patentansprüche
1. Verfahren zum Übertragen von Daten in einem Mobilfunksystem, insbesondere UMTS, aufweisend die Verfahrensschrit- te:
- Senden von Parametern für den Empfang eines mehrfach genutzten Kanals (DSCH) von einer Basisstation an eine MobilStation;
- Auswerten der Parameter in der Mobilstation; und - Empfangen von von der Basisstation ausgesendeten Daten über den mehrfach genutzten Kanal (DSCH) durch die Mobilstation, wobei der Empfang durch die Parameter ermöglicht wird, d a d u r c h g e k e nn z e i c h n e t, d a s s die Parameter allen durch die Basisstation versorgten Mobilstationen bekannt sind.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, d a s s die Parameter per Rundfunk in das Versorgungsgebiet der
Mobilstation ausgesendet werden.
3. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s über den mehrfach genutzten Kanal Datenspitzen übertragen werden.
4. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s die Parameter mit einer Sendeleistung übertragen werden, die gewährleistet, dass die Parameter überall in dem Versorgungsbereich der Basisstation empfangen werden können.
5. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s die Parameter von einer Vielzahl von Mobilstationen ausgewertet werden.
6. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s die Daten gleichzeitig von einer Vielzahl von Mobilstati- onen empfangen werden.
7. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, d a s s es sich bei den Daten um an eine Gruppe von Mobilstatio- nen gleichzeitig versandte Daten handelt.
8. System zum Übertragen von Daten in einem Mobilfunksystem, insbesondere UMTS, aufweisend:
- Mittel zum Senden von Parametern für den Empfang eines mehrfach genutzten Kanals (DSCH) von einer Basisstation an eine Mobilstation;
- Mittel zum Auswerten der Parameter in der Mobilstation; und
- Mittel zum Empfangen von von der Basisstation ausgesen- deten Daten über den mehrfach genutzten Kanal (DSCH) durch die Mobilstation, wobei der Empfang durch die Parameter ermöglicht wird, d a d u r c h g e k e n n z e i c h n e t, d a s s die Parameter allen durch die Basisstation versorgten Mo- bilstationen bekannt sind.
9. System nach Anspruch 8 , d a d u r c h g e k e n n z e i c h n e t, d a s s die Parameter per Rundfunk in das Versorgungsgebiet der Mobilstation ausgesendet werden.
10. System nach einem der Ansprüche 8 oder 9, d a d u r c h g e k e n n z e i c h n e t, d a s s über den mehrfach genutzten Kanal Datenspitzen übertragen werden.
11. System nach einem der Ansprüche 8 bis 10, d a d u r c h g e k e n n z e i c h n e t, d a s s die Parameter mit einer Sendeleistung übertragen werden, die gewährleistet, dass die Parameter überall in dem Versorgungsbereich der Basisstation empfangen werden können.
12. System nach einem der Ansprüche 8 bis 11, d a d u r c h g e k e n n z e i c h n e t, d a s s die Parameter von einer Vielzahl von Mobilstationen ausgewertet werden.
13. System nach einem der Ansprüche 8 bis 12, d a d u r c h g e k e n n z e i c h n e t, d a s s die Daten gleichzeitig von einer Vielzahl von Mobilstationen empfangen werden.
14. System nach einem der Ansprüche 8 bis 13, d a d u r c h g e k e n n z e i c h n e t, d a s s es sich bei den Daten um an eine Gruppe von Mobilstationen gleichzeitig versandte Daten handelt.
15.Mobilstation zur Verwendung bei einem Verfahren nach einem der Ansprüche 1 bis 7 und/oder in einem System nach einem der Ansprüche 8 bis 14.
16.Basisstation zur Verwendung bei einem Verfahren nach einem der Ansprüche 1 bis 7 und/oder in einem System nach einem der Ansprüche 8 bis 14.
PCT/DE2003/001408 2002-05-24 2003-05-02 Datenübertragungsverfahren und -system in einem mobilfunksystem WO2003101136A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/495,904 US20040266461A1 (en) 2002-05-24 2003-05-02 Method and system for transmitting data
AU2003232618A AU2003232618A1 (en) 2002-05-24 2003-05-02 Method and system for the transmission of data in a mobile radio system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10223204.0 2002-05-24
DE10223204 2002-05-24

Publications (1)

Publication Number Publication Date
WO2003101136A1 true WO2003101136A1 (de) 2003-12-04

Family

ID=29557291

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/001408 WO2003101136A1 (de) 2002-05-24 2003-05-02 Datenübertragungsverfahren und -system in einem mobilfunksystem

Country Status (3)

Country Link
US (1) US20040266461A1 (de)
AU (1) AU2003232618A1 (de)
WO (1) WO2003101136A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009005529A1 (de) * 2009-01-20 2010-07-22 Vodafone Holding Gmbh Steuerung von seitens in einem Mobilfunknetz betreibbaren mobilen Endgeräten ausführbaren Anwendungen

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6907010B2 (en) * 2002-10-11 2005-06-14 Interdigital Technology Corporation Dynamic radio link adaptation for interference in cellular systems
US7606205B2 (en) * 2002-10-28 2009-10-20 Nokia Corporation System and method for providing selection diversity for multicasting content
KR100943901B1 (ko) * 2003-08-19 2010-02-24 엘지전자 주식회사 방송 및 멀티캐스트를 위한 무선 프로토콜 엔터티 공유방식
US8320923B2 (en) * 2005-04-01 2012-11-27 Interdigital Technology Corporation Method and apparatus for validating radio resource control messages
US7941150B2 (en) 2005-05-19 2011-05-10 Nortel Networks Limited Method and system for allocating media access control layer resources in a wireless communication environment
WO2008069616A2 (en) * 2006-12-07 2008-06-12 Lg Electronics Inc. Methods of transferring data in a wireless communication system
WO2008069617A2 (en) * 2006-12-07 2008-06-12 Lg Electronics Inc. Method and transmitter for transmitting and method of receiving status report and structure of status data blocks in a mobile communication system
KR101342365B1 (ko) * 2006-12-07 2013-12-16 엘지전자 주식회사 무선 통신 시스템에서의 데이터 전달 방법
WO2008084957A1 (en) * 2007-01-08 2008-07-17 Lg Electronics Inc. Method for receiving common channel in wireless communication and terminal thereof
WO2008084985A2 (en) * 2007-01-09 2008-07-17 Lg Electronics Inc. Method of transmitting and receiving data in a wireless communication system
US8194559B2 (en) * 2007-01-09 2012-06-05 Lg Electronics Inc. Method of controlling data retransmission in a wireless communication system
WO2008084986A2 (en) * 2007-01-09 2008-07-17 Lg Electronics Inc. Method of transmitting and receiving scheduling information in a wireless communication system
EP2103003A4 (de) * 2007-01-09 2013-07-31 Lg Electronics Inc Verfahren zur meldung einer kanalqualität über einen allgemeinen uplink-kanal in einem drahtlosen kommunikationssystem
KR101211758B1 (ko) * 2007-01-10 2012-12-12 엘지전자 주식회사 무선 통신 시스템의 블록 데이터 생성 방법
CN101578783A (zh) * 2007-01-10 2009-11-11 Lg电子株式会社 用于在移动通信中构造数据格式的方法及其终端
KR101461938B1 (ko) 2007-01-31 2014-11-14 엘지전자 주식회사 시스템 정보의 전송 및 수신 방법
KR101455991B1 (ko) * 2007-01-31 2014-11-03 엘지전자 주식회사 멀티미디어 브로드캐스트/멀티캐스트 서비스에서의 시스템정보 수신 방법
US20080195860A1 (en) * 2007-02-14 2008-08-14 Motorola, Inc. Method and apparatus for detecting a compromised node in a network
EP2077646A1 (de) 2008-01-05 2009-07-08 Panasonic Corporation Kontrollkanal-Signalgebung mit Codepunkten zum Anzeigen des Planungsmodus
US8180335B2 (en) * 2008-01-11 2012-05-15 Qualcomm Incorporated System information modification notification and detection in wireless communications
US8089858B2 (en) * 2008-08-14 2012-01-03 Sony Corporation Frame and signalling pattern structure for multi-carrier systems
US20100272017A1 (en) * 2009-04-23 2010-10-28 Interdigital Patent Holdings, Inc. Method and apparatus for processing advanced long term evolution system information
EP2425661B1 (de) * 2009-04-27 2014-01-29 Telefonaktiebolaget LM Ericsson (publ) Verfahren und vorrichtungen zur betriebsmittelvergabe für direktzugriff in drahtlosen telekommunikationssystemen mit trägeraggregation

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1006740A2 (de) * 1998-12-02 2000-06-07 Lg Electronics Inc. Verfahren zur Realisierung eines Mehrfachübertragungsdienstes in einem mobilen Übertragungssystem
WO2002001769A2 (en) * 2000-06-28 2002-01-03 Telefonaktiebolaget Lm Ericsson (Publ) Plural signaling channels for communicating signaling information to a user equipment terminal in a radio communications system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6128490A (en) * 1997-05-08 2000-10-03 Nortel Networks Limited Wireless communication system that supports selection of operation from multiple frequency bands and multiple protocols and method of operation therefor
US6400697B1 (en) * 1998-01-15 2002-06-04 At&T Corp. Method and apparatus for sector based resource allocation in a broadhand wireless communications system
US6724813B1 (en) * 1998-10-14 2004-04-20 Telefonaktiebolaget Lm Ericsson (Publ) Implicit resource allocation in a communication system
FI107690B (fi) * 1999-04-30 2001-09-14 Nokia Mobile Phones Ltd Parannettu menetelmä ja järjestely solun valinnan hallitsemiseksi ja solukkojärjestelmän päätelaite
KR100586297B1 (ko) * 2002-05-01 2006-06-08 인터디지탈 테크날러지 코포레이션 무선 통신 시스템에서 공유 채널을 사용한 지점대다지점간 서비스

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1006740A2 (de) * 1998-12-02 2000-06-07 Lg Electronics Inc. Verfahren zur Realisierung eines Mehrfachübertragungsdienstes in einem mobilen Übertragungssystem
WO2002001769A2 (en) * 2000-06-28 2002-01-03 Telefonaktiebolaget Lm Ericsson (Publ) Plural signaling channels for communicating signaling information to a user equipment terminal in a radio communications system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GARG V K ET AL: "Role of MAC/RLC in achieving higher-data rates and QoS in third generation (3G) UMTS system", IEEE, 17 December 2000 (2000-12-17), pages 459 - 463, XP010534095 *
HUTCHINSON 3G: "RAN Solution Proposal to Support MBMS", 3GPP WORKSHOP, LONDON, UNITED KINGDOM, 6 May 2002 (2002-05-06) - 7 May 2002 (2002-05-07), pages 1 - 12, XP002249466, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/workshop/0205_MBMS_London/Docs/MBMS-000014> [retrieved on 20030729] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009005529A1 (de) * 2009-01-20 2010-07-22 Vodafone Holding Gmbh Steuerung von seitens in einem Mobilfunknetz betreibbaren mobilen Endgeräten ausführbaren Anwendungen

Also Published As

Publication number Publication date
US20040266461A1 (en) 2004-12-30
AU2003232618A1 (en) 2003-12-12

Similar Documents

Publication Publication Date Title
WO2003101136A1 (de) Datenübertragungsverfahren und -system in einem mobilfunksystem
EP1325590B1 (de) Verfahren zur übertragung von datenpaketen über eine luftschnittstelle eines mobilfunksystems
DE602004006344T2 (de) Vorrichtung und Verfahren zur Übertragung und zum Empfang von MBMS Kontrollinformationen in einem Mobilkommunikationssystem
EP3142410B1 (de) Teilnehmerendgerät und basisstation zur verwaltung eines buffer statusreports
DE60103500T2 (de) Drahtloses kommunikationssystem mit selektiv dimensionierten datentransportblöcken
DE69935397T2 (de) Verfahren und Vorrichtung zur Echtzeitdatenübertragung in einem Paketfunknetz
DE60126998T2 (de) Übertragung von multicast und broadcast multimedia diensten über eine funkschnittstelle
DE102005043001B4 (de) Verfahren zum Senden mehrerer Datenströme, Verfahren zum Demultiplexen von mittels mehrerer Empfangsantennen empfangenen Sende-Datenströmen, Sendeeinrichtung zum Senden mehrerer Datenströme, Empfangseinrichtung zum Demultiplexen von mittels mehrerer Empfangsantennen empfangenen Sende-Datenströmen und Computerprogrammelemente
DE10107700A1 (de) Verfahren und Vorrichtung zum Multiplexen und/oder Demultiplexen sowie entsprechende Computerprogramme und ein entsprechendes Computerprogramm-Erzeugnis
EP1276335A2 (de) Verfahren zum Übertragen von Multicast-Nachrichten in einem Funksystem sowie entsprechend ausgestaltetes Funksystem und entsprechend ausgestalteter Sender und Empfänger
EP1283650A1 (de) Verfahren, Sende-/Empfangseinheit und Kommunikationssystem zur Übertragung von Daten von einem Versender an mehrere Empfänger
EP1452058B1 (de) Verfahren zur zuweisung von übertragungskanälen in einer mobilfunkzelle für einen multicast-dienst
DE10331319B4 (de) Verfahren zur Steuerung der einer Mobilstation zugeordneten Funkressourcen und Funk-Kommunikationssystem
EP1518437B1 (de) Verfahren zur übertragung mindestens einer gruppennachricht, zugehörige netzwerkkontrolleinheit sowie funkkommunikationsgerät
DE10154428B4 (de) Verfahren, Vorrichtungen und Softwareprogramme zur Anpassung der Uplinksignalisierung beim Multicasting
DE10315044A1 (de) Verfahren zur Übertragung, Terminal,Basisstation und Kommunikationssystem
EP1250822A1 (de) Verfahren zur signalisierung einer kanalzuweisung in einem funk-kommunikationssystem
EP1415411B1 (de) Verfahren, vorrichtungen und computerprogrammprodukte zur anpassung der uplinksignalisierung beim multicasting
EP1523861B1 (de) Verfahren, funkkommunikationsgerät und netzwerkkontrolleinheit zur übertragung einer gruppennachricht
DE102004021070B4 (de) Kommunikationssystem mit einem Kommunikationsnetzwerk, Basisstation, Teilnehmergerät und Verfahren zum Verarbeiten von Daten
DE10138717A1 (de) Verfahren zur Ressourcen-Zuweisung zur Übertragung von Multi-castnachrichten über die Luftschnittstelle
EP1085716B1 (de) Drahtloses Datenübertragungsverfahren unter Verwendung einer Kompressionsprotokollschicht
DE102004037815B4 (de) Mobilfunkeinrichtung und Verfahren zum Steuern von Mobilfunk-Senderessourcen in einer Mobilfunkeinrichtung
DE10138768A1 (de) Broadcast/Multicast-Multiplexing
DE10233439B4 (de) Verfahren zur Übertragung mindestens einer Gruppennachricht, zugehörige Netzwerkkontrolleinheit sowie Funkkommunikationsgerät

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 10495904

Country of ref document: US

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP