Multiplex communications – Channel assignment techniques – Adaptive selection of channel assignment technique
Reexamination Certificate
2000-10-23
2004-11-30
Hsu, Alpus H. (Department: 2665)
Multiplex communications
Channel assignment techniques
Adaptive selection of channel assignment technique
C370S329000
Reexamination Certificate
active
06826193
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to data transmission in a telecommunications network and in particular, though not necessarily, to data transmission in a Universal Mobile Telecommunications System (UMTS).
BACKGROUND TO THE INVENTION
The European Telecommunications Standardisation Institute (ETSI) is currently in the process of standardising a new set of protocols for mobile telecommunications systems. The set of protocols is known collectively as the Universal Mobile Telecommunications System (UMTS).
FIG. 1
illustrates a simplified UMTS layer 2 protocol structure which is involved in the communication between mobile stations (e.g. mobile telephones) and Radio Network Controllers (RNCs) of a UMTS network. The RNCs are analogous to the Base Station Controllers (BSCs) of existing GSM mobile telecommunications networks, communicating with the mobile stations via Base Transceiver Stations (BTS).
The layer 2 structure of
FIG. 1
consists of a set of Radio Access Bearers (RABs) which make available radio resources (and services) to user applications. For each mobile station there may be one or several RABs. Data flows (in the form of segments) from the RABs are passed to respective Radio Link Control (RLC) entities which amongst other tasks buffer the received data segments. There is one RLC entity for each RAB. In the RLC layer, RABs are mapped onto respective logical channels. A Medium Access Control (MAC) entity receives data transmitted in the logical channels and further maps logical channels onto a set of transport channels. Transport channels are finally mapped to a single physical transport channel which has a total bandwidth (<2Mbits/sec) allocated to it by the network. Depending whether a physical channel is used exclusively by one mobile station or is shared between many mobile stations, it is referred to as either a “dedicated physical channel” or a “common channel”. A MAC entity connected to a dedicated physical channel is known as MAC-d, there being one MAC-d entity for each mobile station. A MAC entity connected to a common channel is known as MAC-c. There is one MAC-c entity for each cell.
The bandwidth of a transport channel is not directly restricted by the capabilities of the physical layer, but is rather configured by a Radio Resource Controller (RRC) entity using Transport Formats. For each transport channel the RRC entity defines one or several Transport Block (TB) sizes. Each Transport Block size directly corresponds to an allowed MAC Protocol Data Unit (PDU) and tells the MAC entity what packet sizes it can use to transmit data to the physical layer. In addition to block size, the RRC entity informs the MAC entity of a Transport Block Set (TBS) size, which is the total number of bits the MAC entity can transmit to the physical layer in single transmission time interval (TTI). The TB size and TBS size, together with some additional information relating to the allowed physical layer configuration, form a Transport Format (TF). An example of a TF could be (TB=80 bits, TBS=160 bits) meaning that the MAC entity can transmit two 80 bit packets in single transmission time interval. Thus the TF can be written as TF=(80,160).
The RRC entity also informs the MAC entity of all possible TFs for a given transport channel. This combination of TFs is called a Transport Format Combination (TFC). An example of a TFC is {TF
1
=(80, 80), TF
2
=(80, 160)}. In this example the MAC entity can choose to transmit one or two PDUs in one TTI on the particular transport channel in question. In both cases the PDUs will have a size of 80 bits.
In each TTI, the MAC entity has to decide how much data to transmit on each transport channel connected to it. These transport channels are not independent of one another, and are later multiplexed onto a single physical channel at the physical layer (as discussed above). The RRC entity has to ensure that the total transmission capability on all transport channels does not exceed the transmission capability of the underlying physical channel. This is done by giving the MAC entity a Transport Format Combination Set (TFCS), which contains the allowed Transport Format Combinations for all transport channels. By way of example, consider a MAC entity which has two transport channels which are further multiplexed onto a single physical channel which has a transport capacity of 160 bits per transmission time interval (NB. in practice, the capacity will be much greater than 160). The RRC could decide to assign three transport formats TF
1
=(80, 0), TF
2
=(80, 80) and TF
3
=(80, 160) to both transport channels. Clearly however, the MAC entity cannot choose to transmit on both transport channels at the same time using TF
3
as this would result in the need to transmit 320 bits on the physical channel which has only a capability to transmit 160 bits. The RRC entity has to restrict the total transmission rate by not allowing all combinations of the TFs. An example of this would be a TFCS as follows [{(80, 0), (80, 0)}, {(80, 0), (80, 80)}, {(80, 0), (80, 160)}, {(80, 80), (80, 0)}, {(80, 80), (80, 80)}, {(80, 0)}], where the transport format of transport channel
1
is given as the first element of each element pair, and the transport format of transport channel
2
is given as the second element. As the MAC entity can only choose one of these allowed transport format combinations from the transport format combination set, it is not possible to exceed the capability of the physical channel.
An element of the TFCS is pointed out by a Transport Format Combination Indicator (TFCI), which is the index of the corresponding TFC. For example, in the previous example there are 6 different TFCs, meaning that the TFCI can take any value between 1 and 6. The TFCI=2 would correspond to the second TFC, which is {(80, 0), (80, 80)}, meaning that nothing is transmitted from the first transport channel and a single packet of 80 bits is transmitted from the second transport channel.
It is of course necessary to share the total available bandwidth between the logical channels. The decision to distribute the bandwidth to different transport channels is made by the MAC entity for each transmission time interval by choosing a suitable TFCI. This sharing of bandwidth can be done in several ways, for example by giving an absolute preference to flows which are considered to be more important than others. This would be the easiest method to implement, but can result in a very unfair distribution of the bandwidth. Specifically, it is possible that flows that have lower priorities are not allowed to transmit for a prolonged period of time. This can result in extremely poor performance if the flow control mechanism of a lower priority flow reacts to this. A typical example of such a flow control mechanism can be found in the TCP protocol used in the Internet.
In existing technologies, such as IP and ATM networks, provision is made for allocating resources on a single output channel, to multiple input flows. However, the algorithms used to share out the resources in such systems are not directly applicable to UMTS where multiple input flows are transmitted on respective logical output channels.
A proposal for sharing resources between multiple input data flows has been made and is referred to as Generalised Processor Sharing (GPS). This proposal, when employed in systems having only a single output channel, is known as Weighted Fair Queuing (WFQ) and is described in a paper entitled “A Generalised Processor Sharing Approach to Flow Control in Integrated Services Networks: The Single Node Case”, A. K. Parekh, R. G. Gallager, published in IEEE/ACM Transactions On Networking, Vol. 1, no. 3, June 1993, pp344-357. Stated simply, GPS involves calculating a GPS weight for each input flow on the basis of certain parameters associated with the flow. The weights calculated for of all of the input flows are added together,
Hsu Alpus H.
Mattis Jason
Nixon & Vanderhye P.C.
Telefonaktiebolaget LM Ericsson (publ)
LandOfFree
Data transmission in a telecommunications network does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Data transmission in a telecommunications network, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data transmission in a telecommunications network will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3315875