EP1226731A1

EP1226731A1 - Fast random access scheme

Info

Publication number: EP1226731A1
Application number: EP00954661A
Authority: EP
Inventors: Janne Parantainen; Guillaume Sebire
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2000-08-25
Filing date: 2000-08-25
Publication date: 2002-07-31
Also published as: WO2002017668A1; AU2000267038A1

Abstract

A method and a network control device are proposed for optionally providing fast resources in a network, comprising the step of transmitting network system information including information as to whether a fast access is supported in the network or not. By this method, introducing of fast resources is made optional.

Description

"FAST RANDOM ACCESS SCHEME"

Field of the invention

The present invention relates to a method and a network control device for optionally providing fast resources in a network.

BACKGROUND OF THE INVENTION

The invention relates to the GSM Edge Radio Access Network (GERAN) in which two approaches for allowing a so-called Temporary Block Flow (TBF) are considered.

The Temporary Block Flow (TBF) is a physical connection used between two peer entities to support an unidirectional transfer of LLC PDUs (Logistic Line Control Packet Data Units) on packet data physical channels. The TBF is an allocated radio resource on one or more PDCHs (Packet Data Channels) and comprises a number of RLC/MAC (Radio Link Control / Medium Access Control) blocks carrying one or more LLC PDUs. It is noted that the above definition is valid for Release ^λ97- ^λ99, in Release '00 changes will occur, in particular, PDCP (Packet Data Convergence Protocol) replaces LLC and SNDCP (Subnetwork Dependent Convergence Protocol) . A TBF is temporary and is maintained until there are no more RLC/MAC blocks to be transmitted and, in RLC acknowledged mode, all of the transmitted RLC/MAC blocks have been successfully acknowledged by the receiving entity.

A TBF may operate in either GPRS (General Packet Radio Network) or EGPRS (Enhanced GPRS) TBF mode. The EGPRS mode is only supported by EGPRS capable MSs (Mobile Stations) .

Each TBF is assigned a Temporary Flow Identity (TFI) by the network. Thus, an RLC/MAC block associated with a certain TBF comprises a TFI. The TBF is identified by the TFI together with, in case of a RLC data block, the direction (uplink or downlink) in which the RLC data block is sent; and in case of a RLC/MAC control message, the direction in which the RLC/MAC control message is sent and the message type.

In R97/99 (E)GPRS TBFs (Temporary Block Flows) are setup through an access on RACH (Random Access Channel) or PRACH (Packet Random Access Channel) when the MS / network has data in the transmission buffer. The access can be a one phase or a two phase access. It is noted that in GPRS one phase access is not possible on RACH, but only on PRACH. For EGPRS, both One and Two Phase Access are possible on RACH and PRACH (Packet Random

Access Channel) . PRACH is on PCCCH (Packet Common Control Channel) , RACH is on CCCH (Common Control Channel) . If PCCCH is not available, CCCH is used for (E)GPRS. (Usually, CCCH is used for circuit-switched connections) . The TBF is released immediately after last block

(Countdown value =0) has been sent. This means that for applications that have temporary idle periods between active transmission TBF must be setup several times. TBF setup may be relatively long depending on the load on a CCCH or PCCCH. Especially two phase access may take a long time, because the access procedure as such requires two two-way message exchanges.

Two approaches have been considered for R00 (Release 00) GERAN. 1. TBF is kept alive (TFI reserved) also during idle periods. The physical resource can be either kept reserved or reallocated to another user during the idle period. If the resource is kept reserved, and idle periods are frequent and long, this leads to significant waste of capacity. Therefore it is better to reallocate the capacity for other mobile stations than keep it unnecessarily reserved. On the other hand when the physical resource is reallocated it is crucial that some resources can be given back when the active period begins.

2. The other approach is that TBF is terminated when the idle period begins and it is fast re-established when the active period begins. In this case, it is very important that when the active period begins physical resource can be requested, assigned and allocated fast. This requires that MS capabilities and QoS class etc. are kept stored in the network after the TBF is released, and that contention resolution mechanism need not to be used when performing a fast TBF setup. One implication is also that the fast TBF setup shall have the same properties as the initial TBF setup that was used for conveying the targeted data. That is, e.g., close-ended or open-ended.

When the capacity is reallocated to other mobile stations (MSs) , the problem is how the network can know when the original MS becomes active.

A first option is regular polling in which the network checks at regular intervals whether the original MS becomes active again. A second option is the so-called random access based notification. Polling is sufficient if the application can tolerate relatively long access delay and if the idle periods are not very long. If the polling period is short and idle periods long, network polls the MS unnecessarily most of the time. That is, the network assigns sending permission but the MS does not have anything to send. This leads to waste of capacity.

Therefore, when idle periods are relatively long and when delay requirement is tight, the random access based solution is preferable. Thus, when the MS is idle, no physical resources are allocated for it until a notification is received on a random access channel (RACH or PRACH) . After receiving a notification, the network immediately assigns capacity for the MS so that transmission can start.

The current MAC (Medium Access Control) procedures need to be changed in order to meet the delay requirement of some traffic types having real-time nature (e.g. chat, telnet, ... ) .

As mentioned above two alternatives have been considered:

1. Keeping TBF and fast reallocating,

2. Releasing and fast re-establishing TBFs.

Both approaches utilize fast random access. The^' main problem of the fast random access scheme is that, in order to make the access fast, sufficient signaling capacity must be reserved. However, this reservation requires that the operator has enough spectrum and large enough portion of traffic benefit from fast access. For example, when initial COMPACT deployments are used, only a limited spectrum may be available and, therefore, the reservation for the fast random access scheme likely lead to a considerable decrease of the capacity.

SUMMARY OF THE INVENTION

Therefore, the object underlying the invention resides in removing the above drawbacks of the prior art.

This object is solved by a method for optionally providing fast resources in a network, comprising the step of transmitting network system information including information as to whether a fast access is supported in the network or not.

Alternatively, the above object is solved by a network control device for controlling an optional provision of fast resources in a network, comprising a transmitting means for transmitting network system information including information as to whether a fast access is supported in the network or not.

By the method and the network control device, fast access is is made optional. That is, by transmitting the information message e.g. by broadcast, every mobile station (MS) knows immediately whether fast access is supported, and, when it is supported, how it can use it.

Hence, for example, the operator of a network can allow fast access only if he has enough spectrum and large enough portion of traffic to benefit from fast access. For example, when COMPACT deployments are used, only a limited spectrum may be available and, therefore, all unnecessary signaling should be avoided. If the operator does not support fast access, polling or continuous allocation based solutions can be used (even if they are suboptimal) .

The above network system information may be transmitted in one network system information message or in a set of plural network system information messages.

In case fast access is supported, network system information including information regarding the location of Fast Packet Common Control Channel (FPCCCH) blocks in a multiframe structure may be transmitted. This information may come in a different system information message than the info whether fast access is supported.

A new Fast Packet Common Control Channel Group (FPCCCH__GROUP) may be defined on which the Fast Packet Common Control Channel (FPCCCH) is mapped. The FPCCCH_GROUP and the FPCCCH can be similar to the PCCCH_GROUP and PCCCH defined in GSM/ (E) GPRS, but may be independent thereof.

Alternatively, the Fast Packet Common Control Channel (FPCCCH) may be mapped on a Packet Common Control Channel Group (PCCCH_GROUP) .

The network system information message may be sent as broadcast message. Thus, all mobile stations concerned can immediately know whether fast access is supported or not, even when the descision as to the fast access is changed during operation.

In case fast access is available in the network, it may be additionally decided whether a mobile station is allowed to use fast access or not based on a predetermined criterion. Thus, mobile stations can be individually allowed to use fast access or not. This is advantageous for example in case fast access channels are congested. Then, some mobile stations can be blocked from using fast access.

The predetermined criterion may be the current traffic load in the network. That is, in case the current traffic load is too high, no fast resources will be allocated such that the traffic is not excessively limited.

Alternatively, the criterion maybe the traffic class of a call. For example, in case the mobile station performs a call which demands real-time communication, this mobile station is allowed to use fast access.

The predetermined criterion can be the operation performed in a call. For example, if an interactive operation is performed, fast access may be allowed.

The predetermined criterion may be the state of a network element .

In case fast access is available in the network, individual mobile stations may be prohibited from using fast access. The descision thereof can be effected on the basis of the same criterions as described above. For example, in case the traffic gets too high, certain MSs can be denied to use fast access.

Information regarding as to whether fast access is allowed or not may be included in a Packet Uplink Assignment message sent on a Packet Associated Control Channel (PACCH) . The network control device may be a Base Transceiver Station.

According to the invention, new channels for performing the fast access are introduced. Furthermore, corresponding allocation procedures for allocating the new channels are introduced.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more readily understood with reference to the accompanying drawings in which:

Fig. 1 an example for a PRACH allocation on a 52 multiframe according to the invention, and

Fig. 2 an example for a FPRACH allocation relatively to PRACH in a 52 multiframe according to the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following, preferred embodiments are described in detail.

As described above, in order to make the random access procedure fast, enough signaling capacity must be allocated. In case the operator has only limited bandwidth or not much traffic that would benefit from fast access, it is waste of scarce resource to provide a fast access mechanism. The invention as described in the following embodiment describes a scheme of optional fast access channels and procedures that can be used only when they are beneficial. Network system information messages contain information whether a fast random access channel is available or not and where it is located in a multiframe structure. The invention describes the needed signalling that is used to convey the information. In addition, the invention covers procedures for different traffic types in case fast access is or is not available.

According to the invention the following is provided:

- Definition of new channels for fast messaging,

- Realization of fast resource request and assignment, or fast re-establishment of TBF using fast messaging,

- Rule to dimension these channels based on QoS (Quality of Service) requirements (delay requirements) of targeted traffic classes using fast messaging,

- Definition of rules for accessing these channels,

- Definition of signaling for informing mobile stations according to Release 'Ox (denoted in the following as R'Ox MS) only of the existence and configuration of these channels,

- Definition of fixed and dynamic allocation methods for the new channels based on existing methods and taking into account the existing channels (PCCCH) in case the introduction is made to an established (E)GPRS network.

First, two new channels are introduced, FPRACH and FAGCH, wherein FPRACH refers to Fast Packet Random Access Channel and FAGCH to Fast Access Grant Channel.

Similar to random access channel, the FPRACH is used by the MS to send a connection request to a BTS (Base Transceiver Station) . The FAGCH is used to allocated resources that were requested on the FPRACH. Fast access may work only if a) FPRACH and FAGCH are close enough in time to be fast and subsequent allocations of FPRACH are close enough in time, so that an MS does not need to wait too long before being able to send on a FPRACH (in order to grant a request for a fast messaging as soon as possible) , and b) the signaling on FPRACH and FAGCH is limited (in order that the signals can be processed quickly) . Typically one UL (Uplink) message for fast request and one DL (Downlink) message for fast assignment should be allowed. It may be used in either of the approaches described above: fast reallocation or fast TBF setup.

The new fast random access and access grant channels (FPRACH and FAGCH respectively) should be accessible to mobile stations (MS) only which actually can utilize this service, i.e., which are able to request and get resources fast. For example, these new channels should be accessible to mobile stations according to the Release 2000 and onwards (further referred to as R'Ox) standard only.

Furthermore, fast messaging should be introduced if sufficient capacity is available in the network only. The solution may be either fast TBF setup based or fast resource request based. The approach as described above works for both.

According to the invention, there are two alternatives for providing new channels for fast messaging.

The first alternative for providing new channels for fast messaging is that new logical channels are introduced on the current PCCCH_GROUPs . That is, some blocks are reserved to those logical channels with parameters broadcast on PBCCCH that are visible to R'Ox MS and defined in a similar way as current parameters (e.g. BS_PRACH_BLKS) . FAGCH is mapped on PCCCH/D, and FPRACH is mapped on PCCCH/U. (In this connection it is noted that current PCCCH/U contains only PRACH) . This implies that the capacity reserved to PRACH is being reduced. This results in increasing the MS density, and therefore the PRACH performance.

The second alternative for providing new channels for fast messaging is to define new FPCCCH_GROUPS . These new FPCCCH_GROUPS are defined in a similar way as for PCCCH__GROUPS (based on IMSI (International Mobile Subscriber Identity)) on which new channels (FPCCCH/U and FPCCCH/D) for "fast" messaging only are mapped. This would allow for FPCCCH messaging on same or different timeslots than the ones of PCCCH. If the same timeslots are used, the blocks allocated to FPCCCH shall be different from those of PCCCH. Similar parameters as those defined for PCCCH need to be defined and broadcast on PBCCH. FAGCH would be mapped on FPCCCH/D and FPRACH on FPCCCH/U. The fast messaging here requires that FPCCCH/D is allocated blocks occurring shortly after FPCCCH/U. Note that FPCCCH/D may be skipped (i.e. not allocated) in case PCCCH/D occurs shortly after FPCCCH/U. Therefore, FPCCCH/D may be allocated only if FPCCCH/U is allocated.

In order to make fast messaging efficient, i.e., useful, it is required that the time-closeness between (F) PCCCH/U and (F) PCCCH/D blocks meets the QoS (Quality of Service) requirements, i.e., delay requirements of the traffic classes using those channels for fast messaging. The benefits of either of the alternatives described above is that it avoids deteriorating unnecessarily the performance of PCCCH/U (i.e. PRACH), and that the efficiency of the new channels would remain due to the limitation to fast messaging only i.e. the traffics on FPRACH and PRACH are segregated: the traffic on PRACH would remain unchanged to the current GSM/GPRS (including EGPRS also) definitions, i.e. the use of PRACH is not extended to fast access.

The second alternative is more flexible, as it is not tied to the PCCCH allocation in the network (cell) and therefore allows for providing, if sufficient capacity is available, fast messaging to existent networks in a smooth way. That is, PCCCH need not be re-dimensioned.

Next, it is described how the new channels can be accessed.

In case FPCCCH is available in general, on multiframes where there is no FPCCCH, fast messaging is forbidden since it is not possible. Also, FPCCCH should be introduced only if sufficient capacity is available in the network, as mentioned above.

An MS may send fast resource request on FPRACH (assuming the data connection is already alive) on PCCCH/U (resp. FPCCCH/U) of its corresponding PCCCH_GROUP (resp. FPCCCH_GROUP) only. If no FPCCCH/D is available, the fast assignment could be made on the PCCCH/D of its corresponding PCCCH_GROUP provided it is sufficiently close (depending on the most stringent QoS requirements of the targeted data connections) in time to the (F) PCCCH/U where the fast request was sent. If FPCCCH/D is available, fast assignment may not be sent elsewhere than on this channel.

For example, an assignment message carried as fast assignment can be in the same form as the current (E)GPRS assignment message. FPRACH should use the access burst for the same reason as the PRACH (no up-to-date timing advance) . Because FPRACH occurs on different blocks than PRACH, all bits in the access burst (extended access burst) are available. It is noted that here the access burst denote at the same time an acces burst (8 bits of information) and an extended access burst (11 bits of information) .

Next, allocation methods and associated signaling are described. As a first possibility, fixed allocation can be carried out.

Availability and the location of FPCCCH/U and FPCCCH/D in multiframe is informed in system information messages.

Preferably, the determination of the FPCCCH_GROUP can be similar (based on IMSI) to that of PCCCH_GROUP (see GSM 05.02). The number of FPCCCH_GROUPs may be different from the number of PCCCH_GROUPs : it may for example be bigger. (Currently, the PCCCH_GROUPs are limited to 16, so that it is likely that more FPCCCH_GROUPs will be defined) .

In GSM 04.60, a so called Packet System Information Type 2 (PSI2) is defined. This message is sent by the network on PBCCH and PACCH giving information of reference frequency lists, cell allocation, GPRS mobile allocations and PCCH descriptions being used in the cell. Hence, the indication of FPCCCH availability can be indicated in one message of the consistent set of PSI2 messages, in a similar way as for PCCCH. FPCCCH description structure can be defined in the same way as for the PCCCH description (see GSM 04.60).

It is noted that the FPCCCH/D bit is required to indicate the availability of downlink FPCCCH. As mentioned previously, FPCCCH/D may be not allocated in case PCCCH/D is close enough in time to FPCCCH/U.

In the following an example of FPCCCH description struct is given:

< FPCCCH Description Lists struct > : := { 1 < FPCCCH

Description struct > } ** 0 ;

< FPCCCH Description struct > ::=

< FPCCCH/D : bit >

< TSC : bit (3) > {0 < Non-hopping FPCCCH carriers : < Non-Hopping

FPCCCH Carriers Lists struct > > I 1 < MA_NUMBER : bit (4) >

< Hopping FPCCCH carriers : < Hopping FPCCCH Carriers Lists struct > > } ; < Non-hopping FPCCCH Carriers Lists struct > ::=

{ 1 < Non-Hopping FPCCCH Carriers struct > } ** 0 ;

< Non-Hopping FPCCCH Carriers struct > : :=

< ARFCN : bit (10) >

< TIMESLOT_ALLOCATION : bit (8) > ; < Hopping FPCCCH Carriers Lists struct > ::= { 1< Hopping FPCCCH Carriers struct > } ** 0 ;

< Hopping FPCCCH Carriers struct > ::=

< MAIO : bit (6) >

< TIMESLOT_A LOCATION : bit (8) > ; The information element fields mentioned above are similar to those defined in GSM 04.60. For example, the field TSC (3 bit field) is the binary representation of the training sequence code, see GSM 05.02. Range: 0 to 7. The field MA_NUMBER (4 bit field) is the binary identification of a GPRS Mobile Allocation provided in this message or the binary reference to such. Range: 0 to 15. The field ARFCN (10 bit field) is the binary representation of the absolute radio frequency channel number (ARFCN) defined in GSM 05.05. Range 0 to 1023. The field MAIO (6 bit field) is the binary representation of the mobile allocation index offset (MAIO), see GSM 05.02. Range: 0 to 63.

A new field is the TIMESLOT_ALLOCATION (8 bit field) indicating which timeslots are allocated as FPCCCH.

According to the invention, the PSI2 should in addition contain, in case of the second alternative (i.e., introducing of new FPCCCH_GROUPS) , the FPCCCH organization parameters to control the organization of FPCCCHs present in the cell (fixed allocation) , as an optional Information Element (IE) . If this IE is absent, no fast messaging is allowed in the cell. That is, introducing or not-introducing of the fast messaging is controlled by the fact whether the PSI2 contains such an Information Element or not. Alternatively, the above- described information element could be included in another suitable network system information message (apart from PSI2) .

It is noted that if the PCCCH_GROUP and FPCCCH_GROUP are on the same timeslots, blocks for PRACH and FPRACH must be different, as mentioned before. In the following, an FPCCCH Organization Parameters Information Element (IE) is shown:

< FPCCCH Organization Parameters IE > ::= < BS_FPCC_REL : bit >

< BS_FPRACH_BLKS : bit (4) > ;

Here, the parameter BS_FPCC_REL is similar to the BS_PCC_REL (as described, e.g., in GSM 04.60). This parameter describes release of the FPCCCH. The parameter BS_FPRACH_BLKS indicates the number of blocks reserved in a fixed way to the FPRACH channel on any PDCH carrying FPCCCH. This parameter has similar range as BS_PRACH_BLKS (see GSM 05.02) .

Furthermore, this is illustrated in Fig. 1. Fig. 1 shows a multiframe, and in particular an example of a PRACH Allocation on a 52 multiframe. In Fig. 1, the symbols B0 to Bll denote radio blocks, respectively, wherein the numerals within each block indicate the order of allocation of the blocks to PRACH.

That is, if one block is allocated to PRACH, it must be B0 in the multiframe. If two blocks are allocated to PRACH, they must be B0 and B6 in the multiframe and so on. For example, a third block allocated must be B3.

In Fig. 2, an example of FPRACH allocation relatively to PRACH (on the same PDCH) according to the invention is illustrated.

That is, according to the invention, if the FPRACH is on the same PDCH (ti eslot) as the PRACH, the FPRACH allocation should be made relatively to the blocks allocated to PRACH. This implies that a maximum number of 12 PRACH blocks may be allocated on any PDCH for FPRACH in a fixed manner. In the example of Fig. 2, blocks BO, B6 and B3 are allocated for FPRACH.

A per-PDCH allocation could be done instead, however, this would require more signaling.

Next, a dynamic allocation is described. Dynamic allocation in downlink and uplink may be realized using the same principles as used currently for PCCCH:

That is, dynamic uplink allocation may be realized using the same principle as for PRACH, i.e., through an Uplink State Flag (USF) defined in GSM 04.60. Such an Uplink State Flag (USF) is included in the header of each

RLC/MAC block on a downlink PDCH. It may be used by the network to control the multiplexing of different mobile stations on uplink PDCH. The use of USF is further specified in GSM 05.02.

Mobile stations according to (E)GPRS as well as mobile stations according to Release ' Ox have to monitor all DL (Downlink) blocks. Thus, the FPRACH blocks must be indicated in DL with the USF. A USF value has to be reserved and must be different from the value "FREE" so that (E)GPRS mobile stations do not consider the FPRACH as PRACH. Also this USF value must not be allocated to any mobile stations for data transfer on any timeslots where FPRACH occurs (timeslots of the (F) PCCCH_GROUPs) . This implies that all Release 'Ox mobile stations on a given carrier know which timeslots are allocated to the entire (F) PCCCH_GROUPs . Elsewhere, this USF value could be allocated to some MS for data transfer. The use of USF allows for dynamic allocation of the FPRACH. For downlink allocation, the FPCCCH may occur on the PDCH of the corresponding FPCCCH_GROUP. FPCCCH/D blocks would be allocated in a dynamic manner, similarly to PCCCH/D: see GSM 05.02. The message_type field of the control messages sent on PCCCH/D identifies the associated logical channel. The same principle may be applied on FPCCCH/D.

A rule to dimension the above new channels is based on the population of Release ^Λ0x MS to be supported, for example. In particular, the capacity available for the new channels should be bigger or equal to the estimated number of MS to be supported.

Next, a second embodiment of the invention is described. The second embodiment is similar to the fist embodiment, however, here, additionally, an MS can be informed independently whether it is allowed to use fast access or not.

That is, the network may allow or not allow a specific MS to use fast access, even though fast access would be available in the network. This information (fast access allowed or not) can be carried as assignment of resources within the Packet Uplink Assignment message sent on PACCH (Packet Associated Control Channel) to the MS, by adding on bit as follows:

<Fast_Access : bit> description: Fast_Access :

1: The MS is allowed to use fast access 0: The MS is not allowed to use fast access This is in particular useful in case fast access channels get congested.

There may be a plurality of criterions according to which an individual MS is allowed or is not allowed to use fast access .

As mentioned above, congestion of fast access channels can be a criterion. That is, in case of a high traffic load on the fast access channels, certain (selected) MSs can be prohibited from using fast access.

Furthermore, another criterion can be the traffic class. Namely, fast access is meant to be used mainly for applications of a traffic class having real-time (or tight) delay requirements. Also other traffic classes in shared mode of operation may use fast access. Therefore, in other dedicated modes which do not require fast access, are not allowed to use fast access.

Moreover, fast access may not be supported in case of certain operations performed during a call of the MS.

For example, real-time (RT) interactive traffic is sent through the so-called shared mode MAC. If there is no dedicated mode which requires fast access or in which no fast access is possible, no fast access is performed.

In a modification of the above embodiments, the state of a requesting MS is considered.

Currently, the MS can be in packet idle mode or packet transfer mode. One or two phase accesses can be made in packet idle mode to setup a TBF to enter packet transfer mode. In order to make a fast access work, some relevant information needed in TBF setup (radio priority, MS multislot class, etc) can be stored after first TBF setup and the MS could be assigned an identifier (for example, an Access Request Identifier (ARI)) so that access burst on PRACH with ARI included can be used to setup TBF and that way speed up access.

Another way to realize fast access would be to introduce a new state (e.g. packet silent mode) which would be a sub state of packet transfer mode, where the MS wouldn't have anything to send but would have TBF on (TFI allocated, all MS related necessary information stored) . From this state fast access (or actually fast resource request) can be made by sending a fast resource request in order to get physical resources (move to packet transfer mode) .

It is noted that the above-described criterions for establishing a fast messaging or not can be arbitrarily combined.

The above description and accompanying drawings only illustrate the present invention by way of example. Thus, the embodiments of the invention and the modifications thereof may vary within the scope of the attached claims.

Claims

1. A method for optionally providing fast resources in a network, comprising the step of transmitting a network system information message including information as to whether a fast access is supported in the network or not.

2. The method according to claim 1, further comprising the step of, transmitting, in case fast access is supported, network system information including information regarding the location of Fast Packet Common Control Channel (FPCCCH) blocks in a multiframe structure.

3. The method according to claim 1, wherein a Fast Packet Common Control Channel Group (FPCCCH_GROUP) is defined on which the Fast Packet Common Control Channel (FPCCCH) is mapped.

4. The method according to claim 1, wherein the Fast Packet Common Control Channel (FPCCCH) is mapped on a Packet Common Control Channel Group (FPCCCH_GROUP) .

5. The method according to claim 1, wherein the network system information is sent as broadcast message.

6. The method according to claim 1, further comprising the step of deciding, in case fast access is available in the network, whether a mobile station is allowed to use fast access or not based on a predetermined criterion.

7. The method according to claim 6, wherein the predetermined criterion is the current traffic load in the network.

8. The method according to claim 6, wherein the predetermined criterion is whether the network supports fast resources at all or not.

9. The method according to claim 6, wherein the predetermined criterion is the traffic class of a call.

10. The method according to claim 6, wherein the predetermined criterion is the operation performed in a call .

11. The method according to claim 6, wherein the criterion is the state of a network element requesting fast resources.

12. The method according to claim 6, wherein information regarding as whether a mobile station is allowed or not to use fast access is included in a Packet Uplink Assignment message sent on a Packet Associated Control Channel (PACCH) .

13. The method according to claim 1, wherein channels dedicated for performing the fast access are introduced.

14. The method according to claim 13, further comprising a step of allocating resources for the channels.

15. A network control device for controlling an optional provision of fast resources in a network, comprising a transmitting means for transmitting network system information including information as to whether a fast access is supported in the network or not.

16. The network control device according to claim 15, further comprising a transmitting means for transmitting, in case fast access is supported, network system information including information regarding the location of Fast Packet Common Control Channel (FPCCCH) blocks in a multiframe structure.

17. The network control device according to claim 15, wherein a Fast Packet Common Control Channel Group

(FPCCCH_GROUP) is defined on which the Fast Packet Common Control Channel (FPCCCH) is mapped.

18. The network control device according to claim 15, wherein the Fast Packet Common Control Channel (FPCCCH) is mapped on a Packet Common Control Channel Group (FPCCCH_GROUP) .

19. The network control device according to claim 15, wherein the network system information message is sent as broadcast message.

20. The network control device according to claim 15, further comprising a deciding means which is adapted to decide, in case fast access is available in the network, whether a mobile station is allowed to use fast access or not based on a predetermined criterion.

21. The network control device according to claim 20, wherein the predetermined criterion is the current traffic load in the network.

22. The network control device according to claim 20, wherein the predetermined criterion is whether the network supports fast resources at all or not.

23. The network control device according to claim 20, wherein the predetermined criterion is the traffic class of a call.

24. The network control device according to claim 20, wherein the predetermined criterion is the operation performed in a call.

25. The network control device according to claim 20, wherein the criterion is the state of a network element requesting fast resources.

26. The network control device according to claim 20, wherein information regarding as whether fast access is allowed or not is included in a Packet Uplink Assignment message sent on a Packet Associated Control Channel (PACCH) .

26. The network control device according to claim 15, wherein the network control device is a Base Transceiver Station.