Flexible RLC PDU Size was introduced in Release 7 in order to decrease RLC protocol overhead and to avoid sequence number stalling

Flexible RLC is used with MAC-ehs in Release 7. Mac-ehs is a new feature introduced in Release 7 to increase the downlink throughput.

RLC PDU Structure before Flexible RLC Size

In previous 3GPP releases RLC PDU size was semi static, e.g. 336 bits or 656 bits. An IP packet size is 1500 octets so many RLC PDUs are required to transmit a single IP packet. The detail description about this problem is described in the following examples.

Example # 1

Assumption RLC PDU size is 336 bits

Ethernet IP Packet Size: 1500 octets

1 RLC PDU size = 336 bits

Maximum RLC Data (RLC SDU) size = 336 – 16 = 320 bits = 40 octets

So minimum number of RLC PDUs required to transmit one Ethernet packet = 1500/40 = 37.5 ~ 38 PDUs

For 38 PDUs header added = 76 (38 * 2 (for fixed header)) + Length Indicators + Padding (If required)

Example # 2

Assumption RLC PDU size is 656 bits

Ethernet IP Packet Size: 1500 octets

1 RLC PDU size = 656 bits

Maximum RLC Data (RLC SDU) size = 656 – 16 = 640 bits = 80 octets

So minimum number of RLC PDUs required to transmit one Ethernet packet = 1500/80 = 18.75 ~ 19 PDUs

For 19 PDUs header added = 38 (19 * 2 (for fixed header)) + Length Indicators + Padding (If required)

Flexible RLC PDU Size

With the implementation of “Flexible RLC PDU Size” RLC overhead can be significantly decreased.

25.322 (4.2.1.3)

If flexible RLC PDU size is configured, the downlink AMD PDU size is variable up to the maximum RLC PDU size, and the Length Indicator size is configured by upper layers. The flexible RLC PDU size can be only configured in the downlink.

25.322 (9.2.2.9)

the length of RLC SDUs is constrained to a multiple of 8 bits

if "Flexible RLC PDU size" is configured (only applicable for downlink):

the last segment of an RLC SDU shall be concatenated with the first segment of the next RLC SDU in order to fill the data field up to the Maximum RLC PDU size. The "Length Indicator" field is used to point the borders between RLC SDUs.

if "Flexible RLC PDU size" is configured, the maximum size of the data field of the RLC PDU is 1503 octets.

CR 0342

The maximum size of the data field of the RLC PDU currently equals to the maximum MTU size of 1500 Byte used for Ethernet. However, if PDCP header needs to be included, the RLC PDU is not large enough to convey both the maximum MTU and the PDCP header. Since the PDCP header can be 0, 1 or 3 Byte, it is proposed that the maximum size of the data field should be 1503 octets.

25.322 (4.2.3)

In downlink, if flexible RLC PDU size is configured, RLC SDUs are segmented if the SDU is larger than the maximum RLC PDU size. Concatenation may be performed up to the maximum RLC PDU size.

Header Extension (HE) Enhancement in Release 7

A special value for Header Extension (HE) is introduced in Release 7.

10: The RLC AM PDU contains the last of the RLC SDU so no Length Indicator is required.

25.322 (11.3.2)

if the last octet of the PDU is the last octet of an SDU and there is no SDU concatenation inside the PDU, and the “use of the special value of the HE field” has been configured by higher layers, set the HE field to indicate that the last octet of the PDU is the last octet of an SDU. Set HE to 10

NOTE 1: In downlink, if "flexible RLC PDU size" is configured, the UTRAN should segment, and if possible concatenate the RLC SDUs into AMD PDUs with a size not larger than the maximum RLC PDU size.

NOTE 2: In downlink, UTRAN can initiate the Polling function by assembling a POLL SUFI when “flexible RLC PDU size” is configured. If a POLL SUFI was assembled, UTRAN should schedule and submit to lower layer a STATUS PDU containing the POLL SUFI.

Example

Assumptions:

Ethernet Packet Size: 1500 Octets

Special HE is enabled.

Flexible RLC is set in Radio Bearer Setup

Reference

Radio Link Control (RLC) protocol specification (Release 7):  http://www.3gpp.org/ftp/Specs/archive/25_series/25.322/25322-7a0.zip

CR 0342: Maximum RLC PDU Size: http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_40/docs/RP-080395.zip

Related posts:

1. UMTS: RLC Length Indicator (RLC LI)
2. UMTS: Radio Link Protocol (RLC) Overview 25.322
3. UMTS Radio Link Protocol Decoder
4. UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK
5. UMTS RLC Status PDU: SUFI LIST

What is UMTS-RLCDecoder?

UMTS-RLCDecoder is small but powerful tool for decoding RLC header information both for Acknowledged Mode RLC PDUs and Unacknowledged Mode RLC PDUs.

RLC Unacknowledged Mode (UM) PDU Decoding

UMTS-RLCDecoder can decode:

1. UMD RLC Header information
   1. UMD PDU Sequence Number
   2. Extension bit
2. Length Indicator Decoding

RLC Acknowledged Mode (AM) PDU Decoding

UMTS-RLCDecoder can decode the RLC Acknowledged Mode Data (AMD) PDUs and Control PDUs.

AMD PDUs

1. AMD PDU Header Decoding
   1. D/C Field
   2. Sequence Number
   3. Polling
   4. Header Extension
2. Length Indicator Decoding

Control PDUs

1. Status PDUs
   1. SUFI NO_MORE
   2. SUFI ACK
   3. SUFI LIST
   4. SUFI RLIST
2. Reset and Reset-Ack PDUs

Download

Related posts:

1. UMTS: Radio Link Protocol (RLC) Overview 25.322
2. UMTS: RLC Length Indicator (RLC LI)
3. UMTS RLC Status PDU: SUFI RLIST
4. Flexible RLC PDU Size (Release 7)
5. UMTS RLC Status PDU: SUFI LIST

Acceptable Cell

An UE can always attempt an emergency call on a Acceptable Cell. The acceptable cell satisfies certain criteria.

1. The cell is not barred
2. Cell selection criteria are fulfilled

Suitable Cell

Suitable cell is a cell on which UE can camp on to provide normal service. Suitable cell satisfies some criteria:

1. The cell should be part of the selected PLN or registered PLMN or equivalent PLMN.
2. The cell should not be barred
3. The cell is part of at least one LA which is not part of the forbidden LA list.
4. The cell selection criteria are full filled.

Barred Cell

The UE is not allowed to camp on a barred cell. System information 3 indicates whether a cell is barred or not.

Reserved Cell

This is a cell on which camping is not allowed. Only particular UE are allowed to camp on a reserved cell.

Cell Selection

Prerequisite

A new PLMN is selected taking PLMN selection criteria into account.

Celle Selection Process

Whenever PLMN has been selected by NAS, the UE shall attempt to camp on the selected cell.

NAS may control the cell selection by:

• Providing information on RAT(s) associated with the selected PLMN
• Maintaining set of forbidden registration areas.
• Providing list of equivalent PLMN

If a suitable cell is found, UE shall select this cell to camp on and report this event to NAS so that NAS can do the necessary registration procedure.

For cell selection UE can use one of the following search procedures:

Initial cell selection

This procedure requires no prior knowledge of which RF channels are UTRA carriers. The UE shall scan all RF channels in the UTRA bands according to its capabilities to find a suitable cell. On each carrier, the UE need only search for the strongest cell. Once a suitable cell is found this cell shall be selected.

Stored information cell selection

This procedure requires stored information of carrier frequencies and optionally also information on cell parameters, e.g. scrambling codes, from previously received measurement control information elements. Once the UE has found a suitable cell the UE shall select it. If no suitable cell is found the Initial cell selection procedure shall be started.

Criteria

The cell selection S is full filled when:

Srxlev > 0 and Squal > 0

Srxlev = Qrxlevmeas – Qrxlevmin – Pcompensation

Squal = Qqualmeas – Qqualmin

Where:

Where to get these parameters?

Qqualmeas (EcNo): Ratio of energy per modulating bit to the noise spectral density the quality. Tells the quality of the cell and is reported from physical layer

Qqualmin: Received in SIB3/4 for serving cell or SIB11/12 for neighbor cell.

Qrxlevmeas (RSCP): Received Signal Code Power (RSCP) is the received power on one code measured on the primary CPICH and is reported from physical layer.

UE_TXPWR_MAX_RACH: Received in SIB3/4 for serving cell or SIB11/12 for neighbor cell

P_MAX: It is UE dependent value.

Reference

3GPP TS 25.304: User Equipment (UE) procedures in idle mode and procedures for cell reselection in connected mode

No related posts.

1. New MAC entities: MAC-e/es in UE and MAC-e in NodeB and MAC-es in RNC.
2. Transport channel: E-DCH
3. Physical channels: E-DPDCH/DPCCH, E-HICH, E-RGCH, E-AGCH
4. Transmission Time Interval: 2 ms or 10 ms
5. SF = 2 can be used
6. Fast Layer 1 transmission and retransmission
7. Hybrid- ARQ using soft combining and incremental redundancies
8. NodeB control grants or data rate
9. New Frame Protocol in Iub/Iur interface (E-DCH FP)

MAC Protocol

HSUPA introduced some changes in MAC protocol both in the UE and network side.

• MAC-e in the NodeB
• MAC-es in the SRNC
• MAC-e/es in the UE

MAC –e in the NodeB

The MAC-e entity is located in the NodeB. There is one MAC-e entity in the NodeB for each UE.

The MAC-e entity is responsible for

• Managing the cell resources related to HSUPA between UEs.
• Receiving the scheduling requests from the UEs and transmission of scheduling grants.
• De-multiplexing of MAC-e PDUs into MAC-es PDUs.
• Management of HARQ entity, which is responsible for transmitting ACK/NACK.

MAC-es in SRNC

For each UE there is one MAC-es entity in the SRNC. The MAC-es covers the following functionalities:

1. Combining and reordering the MAC-es PDUs according to TSN and NodeB tagging i.e. (CFN and subframe number)
2. Disassembling the MAC-es PDUs. When MAC-es PDUs are disassembled the MAC-es header is removed and MAC-d PDUs are extracted. Then the MAC-d PDUs are delivered to MAC-d entity.

MAC-e/es in UE

MAC-e/es handles the E-DCH specific functions in the UE. There are three different entities in MAC-e/es.

HARQ

HARQ entity is responsible for ACK/NACK handling. It receives ACK/NACK from the nodeB and act accordingly.

Multiplexing and TSN setting

Multiplexing and TSN setting entity is responsible for concatenating multiple MAC-d PDUs into one MAC-es PDU, and to multiplex several MAC-es PDUs into one MAC-e PDU.’

E-TFC selection

This entity is responsible for E-TFC selection taking the following into consideration:

1. Relative Grant
2. Absolute Grant
3. Serving Grant

E-DCH Transport Channel

On the uplink when E-DCH is supported, two CCTrCH are used simultaneously. The E-DCH transport channel can be configured with 10 ms TTI or with 2 ms TTI. 10 ms TTI is mandatory and must be supported by all UEs which support E-DCH, but 2 ms TTI is optional.

UE can have only one E-DCH transport channel at a given point of time. The E-DCH can be mapped onto one CCTrCH of E-DCH type at a given point of time and there will be only one Transport Block (TB) per TTI.

Physical Channels for HSUPA

Enhanced Dedicated Physical Data Channel (E-DPDCH)

The E-DCH transport blocks are carried on the E-DPDCH channel in the physical layer. E-DPDCH operates in 2 ms or 10 ms TTI. Release 6 E-DPDCH uses QPSK modulation and in Release 7 there is possibility to use 4 PAM modulations.

The E-DPDCH does not carry any other information other than data symbols. It depends on the DPCCH to carry pilot symbols and channel estimation and on E-DPCCH to carry E-TFC, Retransmission Sequence Number (RSN) and happy bit.

E-DPDCH uses multi-codes combinations to increase the data rate. Spreading Factor 2 (SF 2) can also be used.

So the different possibilities of data rates with code combinations:

Release-6 E-DPDCH

Release-7 E-DPDCH

Enhanced Dedicated Physical Control Channel (E-DPCCH)

E-DPCCH carries HSUPA-related physical layer control information. E-DPCCH always follows the TTI length of E-DPDCH.

The E-DPCCH carries the following information:

1. E-TFC information which is 7 bits long. E-TFC determines the data rate.
2. 2 bits of retransmission information. RSN tells whether the packet is a new or retransmission of a previously transmitted packet.
3. The last 1 bit is the happy bit which tells whether the UE can use a higher uplink data rate or not.

For 2 ms TTI Case

• The 10 information bits are coded into 30 bits over three consecutive time slots.

For 10 ms TTI Case

• The content of 2 ms subframes are simply repeated five times.

E-DCH Hybrid ARQ Indicator Channel (E-HICH)

E-HICH channel is used to send the ACK/NACK information in the downlink i.e. NodeB indicates whether a packet is correctly received from a UE or not.

E-HICH is shared by multiple users at the same time. Each user is allocated one orthogonal signature for E-HICH and one for E-RGCH. Since there are 40 orthogonal signatures are available so only 20 users can use the same code channel at a specific point of time.

E-DCH Relative Grant Channel (E-RGCH)

E-RGCH is used to step up or step down the output power used by the UE. So E-RGCH does not carry any exact value but an indication to go up or down relative to the current serving grant.

E-HICH uses the same code channel as E-HICH to save code space.

E-DCH Absolute Grant Channel (E-AGCH)

An E-DCH Absolute Grant Channel is transmitted by the serving E-DCH cell. It carries two kind of information:

1. AG value
2. AG scope

AG value is the exact E-DPDCH/DPCCH power ratio that the UE need to use in the next transmission.

AG scope tells whether the AG value will be used by a single HARQ process or will be used by all processes.

UE Capabilities

When establishing RRC connection UE sends it E-DCH capabilities to the NW. In the RRC CONNECTION SETUP COMPLETE, UE sends information about E-DCH Physical layer category.

Release 6

Release 7

References

Enhanced uplink; Overall description: 3GPP TS 25.319

UE Radio Access capabilities: 3GPP TS 25.306

FDD Enhanced Uplink;Overall description;Stage 2: 3GPP TS 25.309 

Medium Access Control (MAC) protocol specification: 3GPP TS 25.321

Related posts:

1. MAC (Medium Access Control) Architecture (25.321)
2. UMTS Logical Channels and Transport Channels
3. WCDMA Physical Layer: Principles and Features

You may need the following tutorial:

• UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK
• UMTS RLC Status PDU: SUFI LIST

RLIST (Relative- List) Super field

The SUFI RLIST consists of the following fields: 1. Type identifier field(RLIST) 2. LENGTH Filed 3. First Sequence Number(FSN) 4. Code Words (CW_1, CW_2, …, CW_LENGTH ) The SUFI RLIST fields in the STATUS PDU are as follows:

LENGTH

The LENGTH is a 4bits long field. The LENGTH field signifies the number of codewords (CW) in the super field of type RLIST.

FSN

The length of the FSN super field is of 12 bits. The FSN is the “Sequence Number” of the first erroneous AMD PDU in the RLIST. When the LENGTH field is populated as “0000” at that time FSN is only present in the SUFI and it is the only erroneous AMD PDU.

CW

CW or codeword field is of 4 bits long. The encoding of the codeword field is as follows:

The first three bits of the CW are part of the number and the last one bit is a status indicator. The encoding of the last bit of the CW field as 0 or 1 can be as following:

By default, the number given by the CWs represents a distance between the previous indicated erroneous AMD PDU up to and including the next erroneous AMD PDU. One special value of CW is defined: 000 1: ‘Error burst indicator’ The error burst indicator means that the next CWs will represent the number of subsequent erroneous AMD PDUs (not counting the already indicated error position). After the number of errors in a burst is terminated with XXX 1, the next codeword will again by default be the least significant bits (LSB) of the distance to the next error. Special case while the STATUS PDU will be discarded: If the last CW, as indicated by the value of the LENGTH field, does not contain a "1" in its rightmost position, or the last CW, as indicated by the value of the LENGTH field does contain a "1" in its rightmost position, but is a special "error burst indicator" CW, the encoding of the RLIST SUFI is invalid, and the STATUS PDU is discarded.

Example

Suppose following erroneous PDU Sequence Numbers need to be reported in Rlist SUFI: 3, 5, 6, 7, 8, 9, 10 In this case there are a number of PDUs detected as erroneous starting from sequence number 5. So the encoding of the SUFI RLIST will be as follows:

Step #1

FSN = 3. So the four bit FSN field will be encoded as: FSN = 3 (%0000 0000 0011)

Step #2

The LENGTH = 3 LENGTH = 0011

Step #3

The next SN = 5. Distance = 5 – 3 = 2 CW1 = 0101 (As the distance is 2 and again the codeword is terminated here so the last bit is 1).

Step #4

Now there is error burst continues up to sequence number 10. So the special burst indicator will be used. So now the distance will be 5. So the encoding of the codewords CW₂ and CW₃ will be as follows: CW₂ = 0001 (Special error bust indicator is encoded here while the next CW will signify the length of the error burst) CW₃ = 1011 (The distance from sequence number 5 to 10 is 5 and also the distance is terminated in this CW. So the last bit is 1)

The encoding of the SUFI RLIST as follows:

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322

Related posts:

1. UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK
2. UMTS RLC Status PDU: SUFI LIST
3. UMTS: Radio Link Protocol (RLC) Overview 25.322
4. UMTS Radio Link Protocol Decoder
5. UMTS: RLC Length Indicator (RLC LI)

• UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK

LIST Super field

The List Super-Field consists of a type identifier field (LIST), a list length field (LENGTH) and a list of LENGTH number of pairs.

LENGTH

• • Length: 4 bits
  • The number of (SNi, Li) pairs in the super-field of type LIST.
  • The value 0000 is INVALID and STATUS PDU is discarded.

SNi

• Lenght: 12 bits
• ”Sequence number” of AMD PDU, which was not correctly received.

Li

• Length: 4 bits
• Number of consecutive AMD PDUs not correctly received following AMD PDU with”Sequence number” SNi.

Example

In this example:

• RLC AMD PDUs with Sequence Number 0, 1, 2, 3, 6, 7 are received correctly
• PDUs with sequence number 4 and 5 are missing.

Encoding of Status PDU

Explanation

Octet #1:

0: D/C: Data or control PDU. As it is a control PDU this bit is set to 0.

000: Control PDU Type: 000 indicates it is a Status PDU.

0011: SUFI Type. This is SUFI LIST

Octet #2 and #3

0001: LENGTH field. This indicates the number of (SNi, Ni) pairs. Here there is only one pair

0000 0000 0100: (SNi): The start sequence number. This is the Sequence number of the missing PDU. Here the missing PDUs start from Sequence Number 4 (100).

0001: (Li): The number of consecutive missing PDUs following sequence number 4 (SNi). Here there is only 1 (Sequence number 5)

Rest of the Status PDU may be encoded for SUFI ACK and Padding.

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322

Related posts:

1. UMTS RLC Status PDU: SUFI NO_MORE & SUFI ACK
2. UMTS RLC Status PDU: SUFI RLIST
3. UMTS: Radio Link Protocol (RLC) Overview 25.322
4. UMTS: RLC Length Indicator (RLC LI)
5. UMTS Radio Link Protocol Decoder

Why STATUS PDU is required

• by the receiving entity to inform the transmitting entity about missing PDUs at the receiving entity;

• by the receiving entity to inform the transmitting entity about the size of the allowed transmission window;

• by the transmitting entity to request the receiving entity to move the receiving window.

NOTE: Status PDUs are octet aligned i.e. their length must be multiple of 8 bits.

Status PDU Parameters

D/C

This one bit field tells if the PDU is a Status PDU or AM Data PDU.

• If D/C = 1, then the PDU is AM data PDU
• If D/C = 0, then PDU is a Status PDU

PDU Type

The PDU type field indicates the type of Control PDU.

SUFI: Super Field

Super-Field indicates which AMD PDUs are received correctly and which are missing.

SUFI has three sub-fields:

• Type
• Length
• Value

Type field is 4 bits long and may have one of the following values:

Super-Field indicates which AMD PDUs are received correctly and which are missing.

SUFi has three sub-fields:

• Type
• Length
• Value

Bits	Description
0000	No more data (NO_MORE)
0001	Window Size (WINDOW)
0010	Acknowledgement (ACK)
0011	List (LIST)
0100	Bitmap (BITMAP)
0101	Relative list (Rlist)
0110	Move Receiving Window (MRW)
0111	Move Receiving Window Acknowledgement (MRW_ACK)
1000	Poll (POLL)
1001-1111	Reserved

No more data SUFI

No more data SUFI indicates the end of a Status PDU. Everything after this SUFI will be regarded as padding and will be discarded.

NO_MORE SUFI is always the last SUFI if it is included in a STATUS PDU.

Acknowledgement Super Field

• The ‘Acknowledgement’ super-field consists of a type identifier field (ACK) and a sequence number (LSN).
• Acknowledges the reception of all AMD PDUs with "Sequence Number" < LSN (Last Sequence Number) that are not indicated to be erroneous in earlier parts of the STATUS PDU.
• LSN is of 12 bits.
• SUFI ACK is always the last SUFI if it is included in a Status PDU. So SIFI NO_MORE and SUFI ACK can not be included in the same Status PDU.

Example

Explanation

Octet 1:

0:  D/C: Data or Control. As it is a Control PDU, this bit is set to 0.

000: Control PDU Type: It is a STATUS PDU, so 000.

0010: SUFI Type. 0010 means SUFI ACK

000000000100: LSN, Last Sequence Number: 4 (100)

LSN is encoded as 4, this means all PDUs with Sequence Number less than 4 are correctly received.

In this example PDUs with Sequence Number 0, 1, 2, 3 are correctly received.

Padding: The rest part of the Control PDU is padding.

NOTE: Other RLC SUFIs will be described in separate tutorials.

Reference

Radio Link Control (RLC) protocol specification: 3GPP TS 25.322

Related posts:

1. UMTS RLC Status PDU: SUFI LIST
2. UMTS RLC Status PDU: SUFI RLIST
3. UMTS: Radio Link Protocol (RLC) Overview 25.322
4. UMTS: RLC Length Indicator (RLC LI)
5. UMTS Radio Link Protocol Decoder

Radio Network Subsystem (RNS): The RNS controls the allocation and release of radio resources to establish a connection between a UE and the UTRAN.

A single UE may be associated with one or more Radio Access Bearers (RABs). For instance a UE may simultaneously use one RAB for voice and one RAB for a packet call.

Radio Access Bearer (RAB): RAB is a logical connection between the UE and the UMSC/SGSN.

Iu Bearer: The connection between the RNC and the Core network is referred to as the Iu bearer.

Radio Bearer (RB): The connection between the RNC and the UE is referred to as the Radio Bearer (RB).

During Hard Handover when the UE moves away from the area that is covered by one RNS to a new RNS, there is a requirement to perform an inter-RNC handover between the Serving RNC (S-RNC) to the Target RNC (RNC_T) of the new RNS.

There are two ways to change the Serving RNC:

• One possibility is that the Target RNC may immediately become the Serving RNC referred as the Combined Hard Handover and SRNS Relocation Procedure

• In the other case known as the Serving RNS Relocation Procedure the user plane from the S-RNC extends to the Target RNC, in this situation the Target RNC is referred as the Drift RNC. The Interface between the Serving and the Drift RNC is the Iur interface described in the 3GPP TS 25.420.

NOTE: In either case the Serving RNC initiates the SRNS relocation procedure.

Relocation Procedure

Serving RNS Relocation Procedure

This procedure is only performed for a UE in CONNECTED state where the Iur interface carries both the control signaling and the user data.

The Serving SRNS Relocation procedure is used to move the connection between the RAN and the CN for the source SRNC to the RAN for the target RNC, from a "standing still position". In the procedure, the Iu links are relocated.

If the target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed.

 

If the routing area is changed, this procedure is followed by an Intra-SGSN Routing Area Update procedure. The SGSN detects an Intra-SGSN routing area update by noticing that it also handles the old RA. In this case, the SGSN has the necessary information about the UE and there is no need to inform the HLR about new location of the UE.

Before the SRNS Relocation procedure and RA update, the UE is registered in the old SGSN. The source RNC is acting as a serving RNC (SRNC).

Serving SRNS Relocation procedure Signalling

NOTE: The sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation.

After the SRNS Relocation procedure and RA update, the UE is registered in the new SGSN. The UE is in the state CONNECTED Mode towards the new SGSN, and the target RNC is acting as the serving RNC.

Combined Hard Handover and SRNS Relocation Procedure

This procedure is only performed for an UE in CONNECTED state in case the Iur interface is not available.

The Combined Hard Handover and SRNS Relocation procedure is used to move the connection between the RAN and the CN for the source SRNC to the RAN for the target RNC, while performing a hard handover decided by the RAN.

In the procedure, the Iu links are relocated.

If the target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed.

If the routing area is changed, this procedure is followed by an Intra-SGSN Routing Area Update procedure. The SGSN detects that it is an intra-SGSN routing area update by noticing that it also handles the old RA. In this case, the SGSN has the necessary information about the UE and there is no need to inform the HLR about the new UE location.

If the target RNC is connected to a different SGSN than the source SRNC, an Inter-SGSN SRNS Relocation procedure is performed. This procedure is followed by an Inter-SGSN Routing Area Update procedure.

Before the SRNS Relocation and Routing Area Update the UE is registered in the old SGSN and in the old MSC/VLR. The source RNC is acting as serving RNC.

Combined Hard Handover and SRNS Relocation Procedure Signalling

The sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation. Furthermore, this signaling flow is also applicable for BSS to RNS relocation and vice-versa, as well as BSS to BSS relocation.

After the SRNS relocation and RA update, the UE is registered in the new SGSN and in the new MSC/VLR. The UE is in CONNECTED mode towards the new SGSN and in MM IDLE state towards the new MSC/VLR. The target RNC is acting as serving RNC.

References:

• UTRAN Iu interface RANAP signalling: 3GPP TS 25.413
• General Packet Radio Service (GPRS);Service description;Stage 2: 3GPP TS 23.060
• SRNS relocation in a UMTS network: Patent US 6,807,419

Related posts:

1. UMTS Security: User Identity Confidentiality (IMSI, TMSI & P-TMSI)
2. UMTS Security: Entity Authentication
3. WCDMA Physical Layer: Principles and Features
4. Introduction to LTE

1. First to permit the network to check whether the identity provided by the mobile station is acceptable or not;
2. Second to provide parameters enabling the mobile station to calculate a new UMTS ciphering key;
3. Third to provide parameters enabling the mobile station to calculate a new UMTS integrity key;
4. Fourth to permit the mobile station to authenticate the network.

Authentication Vectors

The Authentication Vectors are used in Entity Authentication and Security procedures.

The VLR/SGSN starts this procedure by requesting authentication vector to the HE/AuC.

When HE/AuC receives the request from the VLR/SGSN it retrieves the calculated authentication vectors AV (1…n) from the HLR database and sends it to the VLR/SGSN in Authentication data response.

The Authentication Vectors generation procedure in HE/AuC is as follows:

HE/AuC first generates a fresh sequence number SQN and an unpredictable challenge RAND.

After that the following will be calculated:

Message Authentication Code MAC = f1K (SQN || RAND || AMF), f1 is the message authentication function.

Expected response XRES = f2K (RAND)

Cipher key CK = f3K (RAND), f3 is a key generating function

Integrity key IK = f4K (RAND), f4 is a key generating function.

Anonymity key AK = f5K (RAND)

Authentication Procedure

The authentication procedure is as follows:

The steps are as follows:

Step#1

In the beginning both the USIM and the Network are not authenticated. That means USIM does not know whether the network is a real network and network does not know whether the USIM is a valid Subscriber.

Step#2

Network starts the authentication procedure by sending the User Authentication Request with the parameter RAND and AUTN.

Step#3

After UE receives RAND and AUTN, the USIM first computes the anonymity key AK = f5K (RAND) and retrieves the SQN = (SQN AK) AK

After that UE computes XMAC = f1K (SQN || RAND || AMF) and compares with MAC.

If both are different UE send user authentication reject back to the VLR/SGSN.

If the USIM finds the SQN is not in the correct range, it sends synchronization failure.

Step#4

UE sends expected response RES to the VLR/SGSN.

If RES = XRES, then the authentication procedure completes

Message sequence from UE point of view

[UE <-- NW] DOWNLINK DIRECT TRANSFER (IDENTITY REQUEST)

[UE --> NW] UPLINK DIRECT TRANSFER (IDENTITY RESPONSE)

[UE <-- NW] DOWNLINK DIRECT TRANSFER (AUTHENTICATION REQUEST)

[UE --> NW] UPLINK DIRECT TRANSFER (AUTHENTICATION RESPONSE)

[UE <-- NW] SECURITY MODE COMMAND

[UE --> NW] SECURITY MODE COMPLETE

References

3G Security: Security architecture: 3GPP TS 33.102

Related posts:

1. UMTS Security: User Identity Confidentiality (IMSI, TMSI & P-TMSI)
2. SRNS Relocation in UMTS Network
3. 3G Tutorials: Introduction to 3G

NOTE: The MAC header may have none of the parameters in some cases.

MAC PDU Header Parameters

TCTF: Target Channel Type Field

TCTF field tells the type of logical channel mapped on a Transport Channel. The following combinations can be possible:

Transport Channel: FACH

For FDD Mode:

TCTF	Designation
00	BCCH
01000000	CCCH
01000001-01001111	Reserved
01010000	MCCH
01010001-01011110	Reserved
01011111	MSCH
0110	MTCH
0111	Reserved
10000000	CTCH
10000001-10111111	Reserved
11	DCCH or DTCH over FACH

For TDD Mode

TCTF	Designation
000	BCCH
001	CCCH
010	CTCH
01100	DCCH or DTCH over FACH
01101	MCCH
01110	MTCH
01111	MSCH
100	SHCCH
101-111	Reserved

Transport Channel: RACH

Fore FDD Mode

TCTF	Designation
00	CCCH
01	DCCH or DTCH over RACH
10-11	Reserved

For TDD Mode

TCTF	Designation
00	CCCH
0100	DCCH or DTCH Over RACH
0101 – 0111	Reserved
10	SHCCH
11	Reserved

Transport Channel: USCH or DSCH (Only in TDD Mode)

TCTF	Designation
0	SHCCH
1	DCCH or DTCH over USCH or DSCH

C/T Field

The C/T field is used to identify the logical channel when multiple logical channels are mapped on the same transport channel. Example: In case of SRB (Signalling Radio Bearer), four SRBs are mapped on the same transport channel. C/T is 4 bit long.

C/T field	Designation
0000	Logical channel 1
0001	Logical channel 2
…	…
1110	Logical channel 15
1111	Reserved

UE-Id

UE-Id is used to identify a UE on common transport channel. There are mainly two types of identifiers are used:

U-RNTI: UTRAN Radio Network Temporary Identity

U-RNTI is always used in the downlink. The length of the U-RNTI is 32 bits. The U-RNTI is normally associated with connection to a Serving RNC (SRNC).

C-RNTI: Cell Radio Network Temporary Identity

The C-RNTI is used on DCCH or DTCH on uplink and may be used on DCCH on downlink. The length of the C-RNTI is 16 bits. The C-RNTI is normally associated with connection to a controlling RNC (CRNC).

UE-Id Type

The UE-Id type is used to ensure the correct decoding of the UE-Id field in the MAC header.

UE-Id Type field 2 bits	UE-Id Type
00	U-RNTI
01	C-RNTI
10	Reserved
11	Reserved

MBMS-Id

MBMS-Id is used to identify the MTCH for an MBMS service on FACH. MBMS-Id is always used on downlink.

MBMS-Id field	MBMS logical channel identity [7]
0000	1
0001	2
…	…
1110	15
1111	Reserved

Example

In case of Signalling Radio Bearer (SRB), four DCCH logical channels are multiplexed on one DCH transport channel. For SRBs the RLC PDU size is 144 bits.

MAC PDU

C/T

RLC PDU

C/T field can have the value from 0000 to 0011.

References

Medium Access Control (MAC) protocol specification: 3GPP TS 25.321

Related posts:

1. UMTS Logical Channels and Transport Channels
2. MAC (Medium Access Control) Architecture (25.321)