<<

. 124
( 132 .)



>>

network policy within the network element. The PEP receiving a request will ¬rst check
to see if it has enough network resources and if not it will reject the request. If there are
enough network resources it will then proceed to contact the policy decision point (PDP)
by sending a COPS request message. This must contain enough information for the PDP to
make an appropriate decision. In UMTS each request is bound to a SIP INVITE message
via the use of the authorization token header. The PDP then determines if the QoS request
is allowed by enforcing network policy. It then sends a COPS decision message back to
the PEP. The PEP will then signal back to the user accepting or rejecting the request. In
IMS the PEP is sited at the GGSN, which provides IMS connectivity; the PDP is sited
within the user™s P-CSCF.



9.8 IP IN THE RADIO ACCESS NETWORK (RAN)

For R5, all the UTRAN transport can be replaced with IP. In this case even though
the datalink and physical layers could remain based on ATM, they need not be. This
¬‚exibility is provided to suit the needs of both new and existing operators. For new
operators, it allows implementation of a network infrastructure based around any suitable
L2 technology. However, for operators migrating to all-IP, it allows for an upgrade to use
of IP, but without the need for a change in the existing ATM infrastructure. For example,
a switched Ethernet network would be perfectly acceptable given that it could support the
QoS requirements of UMTS.
In Release 99 of UMTS, transport within the UTRAN is based on an ATM transport, as
was discussed in Chapter 6 and 7. Transport bearer services across the Iub, Iur and Iu-CS
interfaces are based on AAL2, with the ALCAP protocols such as Q.2630.1 and Q.2630.2
used to dynamically establish channels within ATM circuits. The ALCAP protocols will
be phased out as UMTS moves to an all-IP network but to aid interoperability IP-ALCAP
(or ALCAP over IP) has been de¬ned. This is used for networks supporting a mixture of
old and new UTRAN elements (some using AAL2 and some IP) so that ALCAP messages
can be forwarded by nodes that support IP only.
Within UTRAN, a clear distinction has been between the radio network layer in which
the UTRAN functionality is carried out, and the transport layer, which is responsible
for delivering this data across the access network. Because of the clear demarcation and
logical independence of each of these layers, transport options within the RAN can be
changed without affecting the radio network user or control protocols.


9.8.1 Support for IPv6
All IP nodes within a R5 RAN using IP must support IPv6. Support for IPv4 is optional
for R5 but since network components require backward compatibility with earlier releases,
it is clear that a dual stack con¬guration (v4 and v6) must be provided.
610 RELEASE 5 AND BEYOND (ALL-IP)


9.8.2 IP in the Iu interface

Options for supporting IP across the Iu interface for the user plane are de¬ned in TS
25.414 (UTRAN Iu interface data transport and transport signalling). The R5 stack for
IP transport of user plane (UP) traf¬c towards the Iu-CS domain interface is shown in
Figure 9.32.
Each RTP payload contains a UP PDU. The functions of the RTP layer are somewhat
redundant as timing control is performed using the UP protocol. Each radio access bearer
(RAB) supported is sent and received using a separate transport bearer, de¬ned by source
and destination IP and port address. The IP address and port numbers are exchanged
between the core network element and the RNC in the RANAP request/con¬rm mes-
sages. The RNC will send the IP address (in the transport address IE) and port number
(in the binding ID IE) and associated RAB identi¬er to the MGW. The MGW will
then use the address and port number received as the IP transport options for the IP
transport bearer associated with that RAB. This process is illustrated in Figure 9.33.
The MSC server indicates in the RAB assignment request that its MGW is prepared
to receive user traf¬c on port number 5080 and IPv6 address 5555::123:456:789:900 for
RAB ID = 1450. The RNC responds with its own incoming UDP port number, 8067, and
IP address, 5555::456:123:089:912. Both parties now have transport information associ-
ated with the RAB ID and can forward traf¬c accordingly, the CN elements sending
to port 8067, address 5555::456:123:089:912 and the RNC sending to 5080, address
5555::123:456:789:900 for the established RAB.
For the transport connection to the PS domain, the protocol stack is different (Fig-
ure 9.34(a)), since this time RTP is not used. The payload of the UDP protocol is GTP-U
packets. The procedure is the same as was described in Chapter 6 with the exception of
useing IPv6 instead of IPv4.
The protocol stack for the control plane in the Iu interface (both Iu-PS and Iu-CS) is
shown in Figure 9.34(b). Since RANAP is an SS7 application part protocol and expects
to run over MTP3, sigtran is used. M3UA and SCTP are covered in Chapter 8.


RNC MGW

User part User part

RTP RTP

UDP UDP

IPv6 IPv6

Datalink Datalink
Iu
Physical Physical


Figure 9.32 Iu-CS interface IP options for user plane traf¬c
9.8 IP IN THE RADIO ACCESS NETWORK (RAN) 611



MSC server/
RNC
MGW

RAB Assignment Request
RAB ID=1450
Transport addr=5555::123:456:789:900
Binding ID=5080
RAB Assignment Response
RAB ID=1450
Transport addr=5555::456:123:089:912
Binding ID=8067

RANAP Direct Transfer
RAB ID=1450
IP src=5555::123:456:789:900 UDP port 5080
IP dest=5555::456:123:089:912 UDP port 8067

RANAP Direct Transfer
RAB ID=1450
IP src=5555::456:123:089:912 UDP port 8067
IP dest=5555::123:456:789:900 UDP port 5080

Figure 9.33 User transport signalling for IP over the Iu-CS interface


MSC server/
RNC
SGSN
RNC SGSN RANAP RANAP

User part User part SCCP SCCP

GTP-U GTP-U M3UA M3UA

UDP UDP SCTP SCTP

IPv6 IPv6 IPv6 IPv6

Datalink Datalink Datalink Datalink
Iu Iu
Physical Physical Physical Physical


(a) (b)

Figure 9.34 Iu-PS interface IP options for user and control plane traf¬c

9.8.2.1 Iu IP transport evolution
For R99 for the Iu interface IP is only used for the Iu-PS interface. For both signalling and
user transport, IP over AAL5 is used (see description in Chapter 7). For the R4 network
612 RELEASE 5 AND BEYOND (ALL-IP)


the Iu transport is the same as in R99, with IP being used only in the Iu-PS interface.
For R5 IP can be used for both interfaces (Iu-CS and Iu-PS) and the datalink layer can
be any suitable layer 2 technology and is not constrained to be AAL5.



9.8.3 IP in the Iur Interface
The Iur has to support RAN signalling as well as user data for functions such as soft han-
dover. The transport options for the Iur (and Iub) interfaces for dedicated channels are as
described in 3GPP 25.426 and for common data channels in 3GPP 25.424. Figure 9.35(a)
shows the R5 IP protocol stack for the user plane traf¬c for the Iur interface. The vari-
ous framing protocols for both dedicated and shared channels are carried over UDP. The
source and destination IP addresses and UDP port numbers de¬ne the transport bearer
channel carrying the framing protocols. This information is passed between the two RNCs
using the RNSAP protocol. The IP address is carried in the transport address IE and UDP
port in the binding ID IE.
Figure 9.35(b) shows the IP transport option protocol stack for the R5 Iur signalling
plane; again, sigtran is used since RNSAP is an SS7 application protocol.


9.8.3.1 Iur IP transport evolution
In R99 and R4, IP over AAL5 can be used to transport both RAN signalling (i.e. RNSAP)
and transport signalling in the form of ALCAP messages. The user plane transport for
both R99 and R4 is AAL2. With the introduction of R5 IP can be used for user data
and RAN signalling with any suitable layer 2 technology that can support the service
requirements allowed.


SRNC DRNC
DSCH/HS-DSCH FP




DSCH/HS-DSCH FP
RACH/CPCH FP




RACH/CPCH FP




SRNC DRNC
FACH FP




FACH FP
DCH FP




DCH FP




RNSAP RNSAP

SCCP SCCP

M3UA M3UA

UDP UDP SCTP SCTP

IPv6 IPv6 IPv6 IPv6

Datalink Datalink Datalink Datalink
Iur Iur
Physical Physical Physical Physical


(a) (b)

Figure 9.35 Iur IP transport option: user and control planes
9.8 IP IN THE RADIO ACCESS NETWORK (RAN) 613


9.8.4 IP in the Iub interface
The Iub interface connects the RNC to the BTS. its transport options are de¬ned in TS
24.434 (dedicated channels) and TS 25.426 (common channels). Figure 9.36 shows the R5
protocol stack for a Iub interface which supports IP. Note that for user data the protocol
stack is the same as is used for the Iur interface. Each transport bearer within the user
plane of the Iub is distinguished by the use of UDP port number and IP address. The BTS
control signalling in the form of NBAP messages is carried directly over the streaming
control transmission protocol (SCTP). The IP transport bearers are de¬ned by source and
destination IP address and UDP port numbers, and these values are exchanged in Node B
application part (NBAP) messages (again, using the transport address and binding ID
information elements).

9.8.4.1 Iub IP transport evolution
Previous to R5 IP is not used at all on the Iub interface; all transport is based on AAL2
and AAL5. For R5 signalling is carried using SCTP over IP and user data using UDP
over IP.


9.8.5 IP header compression in the RAN
All nodes that support low-speed links (e.g. E1/T1) are expected to support IP header com-
pression using the scheme described in RFC 2507. The use of compression is established
as part of the PPP NCP negotiation and is described in Chapter 5.


9.8.6 RAN IP datalink layer
When an RNC uses the IP transport option it must support the PPP protocol with HDLC
framing at the datalink layer. However, this does not preclude support for other datalink

Control plane
User plane
RACH FP
CPCH FP
DSCH FP


FACH FP

<<

. 124
( 132 .)



>>