Gn Uu Um MGW EIR R Applications & services Legacy mobile signalling network Multimedia IP networks PSTN/ legacy/external GGSN SGSN Signalling interface Signalling and data transfer inter
Trang 1Multiple Access Protocols for Mobile Communications: GPRS, UMTS and Beyond
Alex Brand, Hamid Aghvami Copyright 2002 John Wiley & Sons Ltd ISBNs: 0-471-49877-7 (Hardback); 0-470-84622-4 (Electronic)
11
TOWARDS ‘ALL IP’ AND SOME
CONCLUDING REMARKS
This concluding chapter provides first an introduction to some of the planned release 5 enhancements to UMTS and the GPRS/EDGE RAN (GERAN) These can be seen as the first step towards ‘all IP’ The challenges when having to deliver real-time IP services over an air interface, in particular voice over IP services, are summarised and possible solutions to achieve spectrum efficiencies similar to those of optimised cellular voice services are outlined
Unlike the UTRA modes, the GSM/GPRS air interface was not designed to handle real-time packet-data traffic Further enhancements are required to support real-time IP bearers in GERAN Possible alternatives are discussed and planned solutions are briefly described
The last section provides summarising comments on multiplexing efficiency and access control, two key topics that kept reappearing throughout this book, for TDMA, hybrid CDMA/TDMA and CDMA systems
11.1 Towards ‘All IP’: UMTS and GPRS/GERAN Release 5
In early 1999, a few operators and infrastructure manufacturers got together to form 3G.IP [92], an ‘industrial lobby group’ intended to influence 3GPP (for UMTS) and ETSI (for EDGE/GPRS) towards adoption of what was then termed an ‘all IP’ network architecture This further evolved GPRS architecture, based on packet technologies and
IP telephony, would function as a common core network to access networks based on both EDGE and WCDMA radio access technologies The system would have to be able
to deliver IP-based multimedia services efficiently, requiring also enhancements to the air interface One of the main benefits provided by IP technology is the service flexibility, as already identified in Section 2.4 Another motivating factor for some operators is the wish
to focus exclusively on the packet-switched infrastructure, once the technology is ready,
to facilitate network management and possibly to save also on infrastructure costs This would imply that existing services, including ‘plain voice’, would have to be replicated
on the packet-switched infrastructure
The top-level architecture devised by 3G.IP was adopted by 3GPP as a basis for enhancements to the packet-switched part of the 3GPP network architecture which,
if further delays can be avoided, are to be incorporated in release 5 of the 3GPP
Trang 2Gn
Uu
Um
MGW
EIR
R
Applications
& services
Legacy mobile signalling network
Multimedia
IP networks
PSTN/
legacy/external
GGSN
SGSN
Signalling interface
Signalling and data transfer interface
Other PLMN
SGW
CSCF
Mm
Mh
Ms
Cx
Gi Mr
Mg G
i
Gr
Gp
Gn
Gf
Gi
Gi
Mc
Gc
Iu-PS GERAN
UTRAN
MRF
MGCF GGSN
SGSN
HSS (HLR)
Figure 11.1 Simplified architecture for the support of IP-based multimedia services in 3GPP release 5
specifications A few new functional entities are to be introduced, which form the IP Multimedia Subsystem (IMS), as shown in Figure 11.1 These are the Call State Control Function (CSCF), the Media GateWay (MGW), the Media Gateway Control Function (MGCF), the Media Resource Function (MRF), and Signalling GateWays (SGW) Additionally, the PS-domain core network of UMTS release 1999 composed of SGSNs and GGSNs (in itself an evolution from GPRS) has to be evolved to provide the necessary quality of service for real-time traffic Finally, the concept of the HLR has evolved, it is
to be substituted by a Home Subscriber Server (HSS)
One of the key components to provide IP-based multimedia services is the CSCF, which executes, among other things, the call control To be precise, it was decided to base the required protocol on the IETF Session Initiation Protocol (SIP) [293] ‘Session’ is in fact
a more generic and appropriate term than ‘call’ The latter is mostly associated with voice calls, while the aim is to provide all imaginable types of IP-based multimedia services, which may, but do not have to contain voice streams A media gateway is required when providing an interconnection from the GGSN to legacy circuit-switched networks, such
as the Public Switched Telephone Network (PSTN) The MGCF controls that gateway The MRF performs multiparty call and multimedia conferencing functions The signalling gateways perform signalling conversion as required
Compared to the original 3G.IP reference architecture to be found in Reference [92], for the 3GPP network architecture shown in the release 5 version of TS 23.002 [294], some of the new elements were further decomposed In particular, there are now different types of CSCF, for instance a proxy CSCF with a policy control function, the latter
Trang 311.1 TOWARDS ‘ALL IP’: UMTS AND GPRS/GERAN RELEASE 5 393
having a separate interface to the GGSN, namely Go, on top of the Gi interface shown
in Figure 11.1 Two types of signalling gateways were introduced, namely the Transport Signalling GateWay function (T-SGW) and the Roaming Signalling GateWay function (R-SGW) For details on the functionality of the individual components, see TS 23.002 [294] and TS 23.228 [295] To provide a simple picture, Figure 11.1 shows the original 3G.IP reference architecture with a single type of CSCF and a single type of SGW, but with some of the terminology adapted to that now used in 3GPP
The introduction of the IMS and the evolution of the PS-domain of the core network have a relatively moderate impact on UTRAN In terms of support of real-time packet traffic over the air interface, the capabilities of the two UTRA modes, in particular the UTRA FDD mode, were discussed in some detail in Chapter 10 and it was shown that UTRA FDD provides considerable flexibility in this respect One key concern relates to spectrum efficiency, mainly due to the overhead introduced by IP and higher layer headers, which has to be reduced or eliminated through appropriate means, as will be discussed in Section 11.2 Other than that, further improvements on top of what is available in release
1999 are being considered and may be introduced, if proven beneficial These include both mechanisms to improve the radio link performance in general, and mechanisms specifically targeted for optimised wireless IP support, in particular bi-directional real-time and interactive IP-based applications The latter could for instance consist of improved common downlink channels
For the so-called GSM/EDGE RAN (GERAN), as the GSM radio network infrastructure
is referred to from release 4 onwards, the situation looks different Connecting GERAN
infrastructure directly to the UMTS core network, as intended, means that Iu-CS and
Iu-PS interfaces must be supported instead of the A and the Gb interface According to
Reference [296], the connection to the CS-domain via the Iu-CS interface is not so much
different from that via the A interface However, when comparing Gb to Iu-PS, which are the interfaces of relevance here, there are substantial differences This has to do with the functional split between the core network and the radio access network, which are not the same in GSM and UMTS It was decided to eliminate any radio-related functionality from the UMTS core network, so that different types of radio technologies could be connected to it (which is exactly what is happening here with UTRA and EGPRS) This resulted in functionality located in the GPRS core network in R97 (and also in EGPRS R99) to be pushed down to the RAN for UMTS R99 For instance, ciphering for the radio link, which used to be performed by the SGSN in GPRS R97, is performed by the
RNC in UMTS Accordingly, if a GERAN is to be connected via Iu-PS to a 3G SGSN, then the ciphering must be implemented in the GERAN In terms of protocol stacks, LLC and SNDCP known from GPRS terminate in the core network, whereas in UMTS, where LLC and SNDCP were eliminated and PDCP introduced instead, the respective functionality is contained in the RAN The reader is referred to Reference [296] for further information
Another fundamental matter is that of the support of real-time packet traffic over the air interface Essentially, neither GPRS R97 nor EGPRS R99 provide means to support real-time traffic over the air interface, so enhancements are necessary Options and likely solutions will be discussed in more detail in Section 11.3, after having outlined some of the general challenges relating to the efficient support of voice over IP over air interfaces
in Section 11.2 These are relevant for both UTRA and (E)GPRS
Trang 4To conclude this section, we would like to point out that ‘all IP’ means different things to different people Evolving the GPRS core network, which makes use of some IP technologies, and adopting a few IETF protocols such as SIP for session control, while still keeping for instance cellular mobility management principles, is for a lot of people far from ‘all IP’ For these people, release 5 provides only a first step towards ‘all IP’ Possible evolutionary paths to ‘real all IP’ were briefly discussed in Section 2.5
11.2 Challenges of Voice over IP over Radio
The Internet is working according to the end-to-end principle It means that only the packet source and the packet destination have to be interested in the packet contents, while the network in between these two entities is assumed to be dumb It does just one thing, namely sending packets from one place to another, in theory without discrimination It is assumed that all packets are treated equally, and that their content is not tampered with This is exactly how the often-quoted service flexibility is achieved: since no assumptions are made about the packets travelling across the network, there are no constraints on the uses to which they can be put In practise, as multimedia traffic containing real-time streams is starting to be delivered over the Internet, means to provide appropriate QoS for these real-time streams have to be introduced This implies often that packets are not treated equally anymore, but rather depending on the QoS requirements of the stream they belong to
Regardless of QoS matters, the end-to-end principle is in direct conflict with what the cellular industry normally does, namely trying to optimise the use of precious spectrum resources depending on the nature of the data to be delivered We have discussed this in detail for GSM voice in Chapter 4, where the importance of every single bit is known and it is treated accordingly Efficiency is derived from the following means:
• low-bit-rate voice codecs optimised for wireless use, ideally adapting to the channel conditions;
• avoidance of header overheads since the application carried is known;
• Unequal Error Protection (UEP) according to the importance of the payload bits, so that FEC coding redundancy is only expended for bits for which it is worthwhile;
• Unequal Error Detection (UED) so that the frame erasure rate (FER) depends only
on the residual error-rate of the most important bits (when used together with UEP, typically the same bits that enjoy the strongest error protection)
The same is not true for circuit-switched data in 2G systems, however, where, with the possible exception of payload compression (as an equivalent to low-bit-rate coding), none of these techniques is applied, nor is it for packet-switched data in 2.5G systems
So what are the concerns when dealing with real-time IP services?
Let us consider what is probably the most challenging service from an efficiency perspective, namely Voice over IP (VoIP) Assuming that it is desirable to carry voice over the PS-domain, then VoIP is the most obvious way in which this could be achieved
If a pure ‘plain’ voice service is to be offered (e.g because it is required to replicate all
Trang 511.2 CHALLENGES OF VOICE OVER IP OVER RADIO 395
current services on the packet-switched infrastructure), then this service has to compete against optimised circuit-switched voice in terms of efficiency
There are two main reasons for which, without taking special measures, a VoIP service cannot compete, in terms of spectrum efficiency, with optimised circuit-switched voice:
• lacking payload optimisation, i.e having to use equal error detection and protec-tion (EED and EEP) instead of UED and UEP, if the end-to-end principle is respected (since the latter implies that there is no guarantee for the network to know the payload);
• the header overhead due to IP and higher layer headers
It is important to note that these two factors are independent from whether voice is carried on dedicated or shared channels over the air interface Choosing circuit-switched voice as a benchmark is simply due to the fact that this is the type of voice service which
is typically supported in cellular communication systems, and which allows a high degree
of optimisation The same type of optimisation could also be performed if shared channels were used on the air interface, using for instance PRMA as a multiple access protocol
11.2.1 Payload Optimisation
As regards UED and UEP, if the payload is known (e.g both the type of codec applied and the ordering of the output bits according to their importance), these techniques can also
be applied in conjunction with a VoIP service According to Reference [86, p 96], UEP performs around 1 dB better than EEP, in the conditions considered in Reference [297], the performance difference is 1.5 dB Using UED and UEP violates somewhat the end-to-end principle, in so far as assumptions are made about the terminal behaviour and as the terminals would have to let the network know what they are doing on the bearers they are assigned If a network-controlled ‘plain voice service’ is replicated on the packet-switched infrastructure, with exactly the same features as the original circuit-switched service, then
the end-to-end principle is anyway a priori abandoned and the network should know what
its bearers are used for
Knowing the importance of the bits and being able to apply UED and UEP accordingly
is only one important technique to improve the radio link performance, adapting the type
of voice coding depending on the current radio conditions is another one gaining impor-tance For instance, with the recently standardised Adaptive Multi-Rate (AMR) codec,
it is possible to trade off robustness against ‘voice fidelity’ depending on the current radio conditions If they are bad, it is better to choose a lower rate, allowing more FEC redundancy to be added while keeping the channel rate constant, so that, even though fidelity is reduced, intelligibility can be improved This requires either local control of the codec mode (e.g by performing transcoding close to the radio link, that is converting
a radio-independent non-AMR bit-stream into an AMR-coded stream according to the local conditions) or suitable end-to-end protocols to negotiate the rates In the context
of VoIP, the former is clearly not in tune with the end-to-end principle The latter raises some challenges in terms of protocol architecture and information exchange It would still leave the end terminals in charge of how they want to deal with media streams, so it could be considered end-to-end, but it would introduce dependence between the transport infrastructure and the applications running on top of it It would therefore affect service flexibility
Trang 611.2.2 VoIP Header Overhead
Real-time interactive traffic is often carried over IP using the Real Time Protocol (RTP)
as an application protocol and the User Datagram Protocol (UDP) as a transport protocol The header overhead specific to VoIP is therefore composed of IP, UDP and RTP headers UDP headers are 8 octets long, RTP headers at least 12, and the length of the IP headers depends on the IP version applied IPv4 headers are at least 20, IPv6 headers at least
40 octets long Taken together, this means 40 octets or more with IPv4, and 60 octets
or more with IPv6 Additional overhead results, for instance, if IP voice packets are encapsulated in an ‘outer’ IP packet, due for instance to the application of the mobile IP protocol [96] or the IP security protocol with encapsulating security payload [298] The IP-related header overhead is particularly disturbing with low-bit-rate real-time services such as voice Because of the packetisation delay, only a limited number of voice frames can be packed into an IP datagram or packet Ideally, to provide a decent quality and keep the delay low, given a voice frame length of 20 ms typical for cellular communications, there should be a one-to-one relationship between voice frames and IP packets Recall from Section 4.3 that a GSM full-rate voice frame lasting 20 ms measures
260 bits, hence roughly 33 octets before error coding, an enhanced full-rate frame 244 bits or 31 octets In other words, with one frame per packet, the header overhead is bigger than the payload, and this even before adding lower-layer headers (e.g at RLC and MAC), which are not required in an optimised voice solution, but may be required for VoIP
Given that spectrum is the most precious resource for an operator of a mobile commu-nications system, the key concern is inefficiency on the air interface Hence the question
is whether we do need to carry the headers over the air interface and, if we do, whether
we can somehow compress them
11.2.3 How to Reduce the Header Overhead 11.2.3.1 Header Removal
Clearly, the most drastic approach to remove the IP-related header overhead is to terminate the VoIP session in the RAN, i.e at the BSC or the RNC, and to send conventional voice without any headers to the mobile terminal This would imply that there is no VoIP client
in the mobile terminal and the aspect of IP service flexibility would not be exploited However, it would still allow reliance on the packet-switched core-network infrastructure for the delivery of the voice service
11.2.3.2 Transparent Header Compression
The only approach that is compatible with the end-to-end principle and does not reduce
service flexibility, is so-called transparent header compression It means that IP/UDP/RTP
headers are compressed, before a packet is sent over the air interface, and decompressed
at the receiving end, before being handed over to the IP stack (e.g in the terminal) This is shown in Figure 11.2 for the downlink direction Transparency implies lossless compression, hence in the absence of transmission errors over the air interface, from
an IP perspective, this process works as if no header compression were applied at all Owing to the fact that these headers contain a lot of fields, which remain static over the
Trang 711.2 CHALLENGES OF VOICE OVER IP OVER RADIO 397
RTP
Air interface Voice sample Compressed
IP/UDP/RTP header
Voice over IP over GPRS/UMTS Network
Header compression and decompression Application generating/receiving
VoIP packets (e.g SIP client)
MS decompression entity (e.g PDCP)
Compression at RNC or BSC
RTP (Remote End Point)
IP UDP RTP Voice sample
Figure 11.2 Header compression over the air interface
duration of a voice call (e.g the source and destination IP addresses), or change in a predictable fashion (sequence numbers, RTP time stamps), very high compression ratios can be achieved
‘Early schemes’ suitable for IP/UDP/RTP header compression, such as that specified
in Reference [299], were not designed for radio links and are known not to be suitable for cellular communications [222,300] Triggered by 3G.IP activities, a working group
was set up in IETF to deal with so-called robust header compression schemes, which are
at the same time very efficient and do not suffer unduly from errors experienced on the wireless transmission medium This RObust Header Compression (ROHC) scheme was recently finalised and is specified in Reference [222] It is supported by the UMTS PDCP protocol from release 4 onwards [301] A short description of a preliminary scheme, which was fed into the ROHC standardisation process, can be found in Reference [302] With ROHC, the average combined IP/UDP/RTP header size can be reduced to less than two octets for a conventional two-party voice call, hence the relative header overhead is reduced to a few percent, which appears to be acceptable However, lossless compression comes at the price of variable sizes for the compressed headers, as unexpected or rare changes of certain header fields require longer compressed headers to be used In the case
of UTRA FDD, for example, owing to the inherent statistical multiplexing capability and the support of real-time VBR traffic, this can be tolerated (although it may, depending
on the solution adopted, consume precious TFCI code points to signal what header size
is currently being used) On the other hand, when trying to support packet-voice over the rather narrow-band GSM carriers, which are partitioned into even narrower basic physical channels, variable size headers are uncalled for
Another problem in the end-to-end context is that the header compression entity can only guess what media streams are carried by the IP packets it is dealing with, through application of appropriate heuristics To maximise the compression efficiency, it would
be helpful to separate a voice stream running over IP/UDP/RTP from other IP/UDP/RTP streams to apply individually optimised ROHC profiles, and also from non-IP/UDP/RTP
Trang 8streams, for which other compression methods may be applied This implies again that the mobile network needs to gain some knowledge on the services it is dealing with Finally, it is important to note that if end-to-end encryption is applied, then the redun-dancy in the header fields is eliminated and compression cannot be performed anymore Compression would have to take place before encryption, but since compression is a hop-by-hop operation, here applied over the radio link, this is incompatible with end-to-end
encryption Additionally, when block-ciphers are applied for encryption, which work on
a block of bits rather than single bits, then it is also not possible anymore to apply, for example, UEP, because there is no evident relation between the importance of a bit at a
given position in a packet before and after ciphering However, when stream-ciphers are
applied, which work bit-by-bit (e.g by performing an ‘exclusive or’ operation between a data bit to be encrypted and a key), then at least this problem does not arise
11.2.3.3 Non-transparent Header Compression or Header Stripping
Transparent header compression exhibits drawbacks, namely that the remaining header overhead is still non-negligible and, in particular, variable in size When dealing with a known service such as voice, which is delivered over a radio link from which timing and other information can be extracted from layers 1 and 2, one could be tempted to reduce the IP/UDP/RTP header overhead over the air interface to zero The link information, together with information submitted at call set-up (e.g IP source and destination addresses), should
be sufficient to regenerate these headers at the other end, although it cannot be guaranteed that the regenerated header is bit-wise identical to the original header This process is
sometimes referred to as header stripping and regeneration It is envisaged to be used
with VoIP in cdma2000 systems and EDGE/GPRS release 5 systems1 There have been intense discussions in the IETF ROHC working group on whether such a header-stripping scheme should be dealt with by IETF at all, given that it can only be used in very specific circumstances, and violates fundamental Internet principles Nobody can tell, for instance, what the impact on a remote VoIP client unaware of the applied compression scheme would be, when headers appearing to be semantically correct are not completely identical
to the original headers At the time of writing, this matter has not yet been resolved, see Reference [303] for up-to-date information
Another approach, which solves the problem somewhat differently, is a gatewaying solution It involves the setting up and interworking of two different VoIP sessions, one between the mobile terminal and the gateway (e.g at the BSC or the RNC), and one between the gateway and the remote end (e.g a VoIP client outside the domain of the mobile network) Header stripping applied over the air interface does in this case not affect the separate session between gateway and remote end Also, both mobile terminal and gateway are aware of the header stripping method which is applied, and can therefore behave in such a manner that unexpected header field changes are avoided in the session between them and that the headers can be regenerated properly
In both these cases, one would have to ask what the justification for a VoIP client in the mobile terminal is If an optimised solution is sought for a specific service (i.e plain voice) with little required IP service flexibility, why not use a header removal solution,
in which the VoIP session is terminated at the BSC/RNC and interworked with a ‘plain voice bearer’ to the mobile terminal?
1 For EDGE/GPRS, the process is referred to as header removal in TS 43.051, hence the use of terminology
is somewhat different from that used here.
Trang 911.3 REAL-TIME IP BEARERS IN GERAN 399
11.3 Real-time IP Bearers in GERAN
The suitability of UMTS radio bearers for real-time packet-date traffic has already been discussed in Chapter 10 The protocol architecture defined for UMTS release 1999 (as illustrated in Figure 10.2), which separates transport from logical channels, and enables various modes of operation for the MAC and the RLC layers, provides to a large extent the flexibility required for IP multimedia services to be supported For VoIP to be carried efficiently over the air interface, header adaptation methods need to be introduced (e.g ROHC header compression, which is supported from release 4 onwards) and means must
be found to enable the application of UEP/UED Whether all this will be available in the release 5 time-frame remains to be seen
In the case of GERAN, the situation is somewhat different In Section 4.9, we illus-trated how the relative overhead created by the GPRS protocol stack can be detrimental when dealing with short IP packets such as those typical for VoIP IP/UDP/RTP header compression or even header stripping help little in this case without introducing other system enhancements In addition, neither GPRS R97 nor EGPRS R99 were designed for real-time traffic; further enhancements are therefore also required in this respect
11.3.1 Adoption of UMTS Protocol Stacks for GERAN
Regarding the protocol stack, when a GERAN is connected to the GSM/UMTS core network in ‘Iu-mode’ (i.e via the Iu-PS and Iu-CS interface), then the protocol model from UMTS is used, with UMTS MAC, RLC, and in particular the UMTS PDCP instead of the GPRS LLC and SNDCP This reduces the overhead drastically, since RLC, MAC and PDCP can be used in modes which create minimal overhead (e.g zero octets for MAC and RLC and one octet for PDCP) Additionally, the GERAN may also be
connected to a GSM/UMTS core network via A and Gbinterface, to support pre-release-4 GSM/GPRS terminals which do not support the new protocols, as shown in Figure 11.3
This figure also shows that an Iur-like interface is envisaged both between GERAN base station systems and possibly even between a GERAN BSS and a UTRAN radio network subsystem This has to do with a 3GPP work item on optimised radio resource manage-ment across different radio access technologies The overall description of the GERAN
is contained in 3GPP TS 43.051 [304]
11.3.2 Shared or Dedicated Channels?
In GPRS and EGPRS, non-real-time packet-data traffic is, with the exception of exclusive allocation in dual transfer mode, supported on shared channels Voice and other real-time traffic, on the other hand, is only supported in the circuit-switched domain, using dedicated channels on the air interface When wanting to support real-time traffic such as voice in the packet-switched domain, a very interesting question from a MAC perspective is whether
it should be carried on dedicated channels or on shared channels The latter would allow statistical multiplexing to be exploited by assigning physical channels to individual users only for the duration of their talk spurts This matter was discussed in a contentious manner first in 3G.IP, then in ETSI and finally in 3GPP It also ties into the discussion
on interference-limited versus blocking-limited operation provided in Section 4.6
Trang 10Gb
Iu
MS Um
BSC BTS
BTS BSS
BSS
RNC Core networkGSM/UMTS
GERAN
UTRAN
Iur-g
Iur-g
Figure 11.3 GERAN connected to GSM/UMTS core network
In Reference [305], a system capacity analysis for voice-only traffic with the same voice model we used in Chapter 7 is provided, considering 1/3, 3/9 and 4/12 frequency reuse
patterns, and different values for the pathloss coefficient γ pl and the standard deviation
of the shadowing σ s ‘Packet-switched operation’ on shared channels is compared with
‘circuit-switched operation’ on dedicated channels Only GMSK modulation is considered The required carrier-to-interference ratio (CIR) is assumed to be 1 dB higher for calls carried on shared channels than for those on dedicated channels, due to additional header overhead that is needed (e.g an RLC/MAC header identifying the user) A hard-blocking limit of 2 % is assumed and a CIR outage probability of 10 % Furthermore, in the case of packet-switching, the dropping probability threshold is 1 %, with packets being dropped
if they are delayed for more than 40 ms Only the downlink is considered, because this
is assumed to be the worst-case scenario from an interference perspective
With dedicated channels, it is generally found that a tight 1/3 reuse pattern resulting
in a soft-blocked capacity-limit delivers higher capacity than looser reuse patterns, the
capacity being the higher, the higher γ pl and the lower σ s However, when γ pl is relatively
low and σ s sufficiently high, then 3/9 reuse provides higher (hard-blocked) capacity For
γ pl = 4, this is the case when σ s exceeds 8 dB, for γ pl = 3.5 already at 7 dB The capacity
achieved with shared channels is in all cases higher than that with dedicated channels (in some cases by more than 50 %), and in most cases, the maximum shared-channel capacity, which is achieved either at a 3/9 or a 4/12 reuse, is hard-blocked Judging from these results, shared-channel operation appears to be the preferred option However, since the downlink is considered, capacity reductions in the reverse direction caused
by the necessary uplink access mechanism are ignored Furthermore, while interleaving
on dedicated channels is typically diagonal over eight bursts, to make efficient use of resources and limit access and scheduling delay, realistically rectangular interleaving over four bursts will have to be applied on the shared channels in the same manner as
in GPRS According to Reference [297], this will increase the required CIR by 2 dB