<<

. 75
( 132 .)



>>

03 02 04 2A 22 00 20
37 00 20 40 96 06 91
2. Transport Block
40 52 A5 C1 09 70 85
98 D4 28 80 30 B8 95
0D 2E 28 4B 8C 4C C6
Payload CRC : 25384 (63 28h)

Figure 6.84 FACH data frame trace
360 UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM



Header CRC FT

CFN

TFI
spare
header
Power Offset

Code Number

SF MC Info sp

First TB
...



First TB Pad
...




Last TB
...




Last TB Pad


Payload Checksum



Figure 6.85 DSCH format

Table 6.30 Common channel control procedures
Transport Control frames
bearer
Timing DL transport Node sync DSCH TFCI
adjustment channel sync signalling
RACH N N N N
FACH Y Y Y N
CPCH N N N N
DSCH Y Y Y N
TFCI2 Y Y Y Y


However, there are some circumstances where a UE may be communicating with the
core network through a SRNC where it is not physically connected to any BTS for
which this is the CRNC. Such an example is where an inter-RNC hard handover has
been performed but a SRNC relocation has not. Figure 6.87 shows the RACH protocol
stack for this. In this particular situation information arriving from the UE on a com-
mon channel will be checked at one RNC, the CRNC, to see if the information is user
data or common control messages. It will deal with common control messages itself but
6.18 FRAME PROTOCOLS 361


DTCH DCCH CCCH CCCH DCCH DTCH



MAC-d MAC-d


MAC-c/sh MAC-c/sh

RACH FP

AAL2
PHY PHY PHY

ATM

UE Uu Node B Iub SRNC

Figure 6.86 Protocol for RACH with coincident CRNC/SRNC


DTCH DCCH CCCH CCCH DTCH DCCH


MAC-d MAC-d

RACH/
MAC-c/sh
MAC-c/sh RACH/CPCH
CPCH
FP
FP
RACH FP RACH FP
AAL2 AAL2 AAL2 AAL2
PHY PHY
ATM ATM ATM ATM
SRNC
UE Uu Node B Iub CRNC Iur

Figure 6.87 RACH protocol stack for separate CRNC and SRNC


user data (including user dedicated signalling) will be passed to another RNC, the SRNC
via the Iur.
For this reason, a more detailed set of information needs to be sent in the FP to deal
with identifying the CRNC and SRNC.


6.18.3.1 RACH/CPCH transport

The format of the RACH and CPCH data frames is the same, and is as shown in
Figure 6.88(a). The additional ¬elds are explained as follows:

• Serving RNC radio network temporary identi¬er (SRNTI, 20 bits): as previously dis-
cussed, the SRNTI identi¬es the UE context in the SRNC.
• MAC-c/sh SDU length (13 bits): identi¬es the length of each MAC-c/sh SDU in the
payload.
• Num of SDU (8 bits): indicates the number of MAC-c/sh SDUs in the frame payload.
362 UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM



Header CRC FT Header CRC FT

SRNTI
DRNTI
SRNTI
DRNTI
SRNTI spare
header DRNTI Cm CH-PI
Propagation delay
UE-ID MAC-c/sh SDU
spare header
MAC-c/sh SDU length type length
MAC-c/sh MAC-c/sh SDU length
spare
length contd.
Num of SDU Num of SDU
MAC-c/sh
spare
SDU 1 User buffer size
...




User buffer size
MAC-c/sh SDU 1
...




MAC-c/sh
spare
SDU n
...




MAC-c/sh SDU n

Payload Checksum

Payload Checksum

(a) (b)

Figure 6.88 (a) RACH/CPCH and (b) FACH Iur frame format


With this additional information, the RACH/CPCH can carry multiple users across the
Iur in the same logical channel.


6.18.3.2 FACH transport

The format for the FACH frame protocol is shown in Figure 6.88(b). Note that the diagram
shows only the header, since the payload is identical in format to that of the RACH/CPCH
frame protocol.

• Drift RNC temporary network identi¬er (DRNTI, 20 bits): identi¬es the UE in the
DRNC.
• Common transport channel priority indicator (Cm CH-PI, 4 bits): used to identify the
priority of this frame on the common channel. In this way, QoS can be provided on
the common channels across the Iur.
6.18 FRAME PROTOCOLS 363


• UE-ID type (1 bit): indicates to the DRNC/CRNC which identi¬er should be used in
the MAC-c/sh header. The options are either URNTI (0) or DRNTI (1).
• User buffer size (16 bits): indicates the amount of buffer space a user has available.

6.18.3.3 DSCH transport
The DSCH frame protocol format is almost the same as that for the FACH except that it
does not need to include the DRNTI ¬eld in the header. The header format is shown in
Figure 6.89.

6.18.3.4 Control protocol
The frame control protocol provides ¬‚ow control across the Iur interface for downlink
common channels. The rationale for providing this only in the downlink is that it is
designed to deal with limited buffering and processing capability in the mobile device,
whereas network components are in a position to offer signi¬cantly higher levels of each.
To perform ¬‚ow control, the SRNC may send a capacity request for either the FACH or
DSCH to the DRNC. This contains the user buffer space as an indication of the capacity
requested on the common channel. The SRNC may send this command again should it
not get a reply from the DRNC within a reasonable time. The DRNC will reply to the
SRNC with a FACH ¬‚ow control or DSCH capacity allocation. This request will contain
a credit value, which is the number of MAC-c/sh SDUs that may be transferred, and
for the DSCH, an interval during which the transfer may take place. A credit value of
0 blocks the SRNC from transfer of any more data and a maximum credit value of 255
indicates that the SRNC may send unlimited data.


6.18.4 User data on the Iu interface
The Iu user plane (UP) protocol is used to transport user data across the Iu interface
between the RNC and either the circuit or packet core network. The UP protocol is de¬ned

Header CRC FT

spare Cm CH-PI

MAC-c/sh SDU length

MAC-c/sh SDU
spare header
length
Num of SDU

User buffer size

User buffer size


Figure 6.89 DSCH Iur frame protocol header
364 UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM


on a per-RAB basis, and does not refer to a particular domain in the core network. Each
instance of the Iu UP is associated with a particular RAB, therefore if one mobile device
has a number of RABs established, they will be carried in separate Iu UP instances. There
are two modes of operation available:

• transparent mode (TrM)
• support mode for prede¬ned SDU sizes (SMpSDU).

The decision as to which mode is used for a particular RAB is made at the time the
RAB is established. The RAB is established using the RANAP protocol, as discussed
in the next section. As its name suggests, the transparent mode is used where the data
requires no extra facilities or support from the UP, and is to be carried transparently
to/from the core network. It adds no overhead to the data. The transparent mode is
typically used for transfer of GTP-U PDUs between the RNC and the packet core, and
also for circuit switched data on the Iu-CS interface. The support mode is used when
further information is required, and a frame protocol is added to the data to transfer this
information. The support mode also provides a number of control procedures between

<<

. 75
( 132 .)



>>