Signalling Radio Bearer 5 (SRB5)

SRB - 5 has been introduced in order to support quick changes in Multi-mode AMR or Wideband AMR data rate

SRB - 5 exist in UL & DL with the following characteristics:

• RB Id, can be any number between (5 - 31)  - SRB#5 need not have RB - ID 5, it can be any RB ID allocated by UTRAN
• UL RLC Mode = TM - DCCH is mapped to TM RLC
• DL RLC Mode = TM - DCCH is mapped to TM RLC
• TB Size  = 3 bits - currently only 3 – bit message is defined
• TBS =  0x3, 1x3
• It is mapped to a DCH TrCH different from DCH of SRB 1 to 4.

Until now only one message has been defined in standard i.e. "Transport Format Combination Control" which is send by UTRAN on TM RLC mode.

Transport Format Combination Control (TFCC):

When this message is sent on TM RLC Mode, i.e. on SRB#5, this message has special handling and encoding:

• This message is NOT ASN.1 encoded
• This message is encoded tabular format.
• Currently only 3 – bit tabular format is defined as below:

3	2	1	Transport Format Combination Sub Set Identity value
0	0	0	0
0	0	1	1
-	-	-	-
1	1	1	7

• There is no response to this message
• If UE receives this message and the TFC Subset id is out of range or more than the subsets that UE has then UE ignores this message and behave as if no such message is received.

 Typical Scenario to use SRB#5:

1. CS call is established for Multi – Mode AMR (12.2/7.95/5.9/4.75 kbps)

2. Typical RB Setup message would include:
1. Complete TFCS list for all  data rates 12.2/7.95/5.9/4.75 kbps
2. TFC Subset for specific data rate 12.2 / 7.95 / 5.9 / 4.75 kbps (four subsets)

3. In order to change the data rate to (say 5.9 kbps), UTRAN would send  TFCC message on RLC – TM mode only indicating TFC Subset to be uses, as in our example it would be “2”, indicating third TFC subset to be used

4. UE RRC would receive this message on TM – RLC; no ASN.1 decoding is needed for this message.

5. RRC should configure it lower layers as per the given TFC Subset in the received 3 – bit message

Serving Radio Network Subsystem (SRNS) Relocation

SRNS Relocation is a procedure executed at UTRAN side where by:

• Serving RNC is shifted from Current Serving RNC to Controlling RNC, .i.e. Iu signalling connection is shifter from current SRNC to the CRNC. After this CRNC becomes the Serving RNC.
• This may happen when UE sends measurement report to change serving cell, and this new serving cell belongs to different CRNC
• On reception of Meas Report NW may decide to perform Serving Cell Change with SRNS relocation
• At times SRNC and CRNC for a UE may be same or different.

SRNC and CRNC is the terminology used with respect to a UE. 

Serving RNC (SRNC):

• Serving RNC is that RNC where the Iu signalling connection terminates between RNC and the Core NW.

Controlling RNC (CRNC):

• Controlling RNC is that RNC which provides physical resources to the UE. In other words, CRNC controls and owns the resources of the cell to which UE is connected.

To perform SRNS relocation UTRAN may include the following IEs in any reconfiguration message with the following restriction:

•  if the reconfiguration procedure is simultaneous with SRNS relocation procedure:
• if the transmitted message is a RADIO BEARER RECONFIGURATION:
• include the IE "New U-RNTI".
• else:
• include the IE "Downlink counter synchronisation info".

Downlink Counter Synchronization Info:

DL Counter Sync Contains two IEs:

1. RB with PDCP SN Info: This contains two IEs as:
• RB ID
• RPCP Seq NO Info
• This IE is included for each RB having PDCP and lossless SRNS Relocation is needed for that RB.
• In order to perform lossless SRNS relocation, UTRAN provides a PDCP Seq no from where the transmission starts after relocation is done
2. RB with PDCP Context relocation: This contains three IEs as:

• RB ID
• DL RFC 3095 context relocation
• UL RFC 3095 context relocation
• RFC 3095 is basically used for ROboust Header Compression (ROHC)
• The context reinitialization MUST be done for all contexts at the compressor.
• This parameter may for instance be used to do context relocation at, e.g., a cellular handover that results in a change of compression point in the radio access network.

UE behavior on reception of DL-CounterSynchronization Info:

• If the IE "PDCP SN Info" is included, the UE shall:
• transfer the sequence number to the PDCP entity for the radio bearer;
• configure the RLC entity for the radio bearer to stop i.e.
• Stop RLC entity for SRBs 1, 3 & 4
• Stop all RLC AM and UM entities for RBs whose PDCP SN is not included
• include the current PDCP receive sequence number and the radio bearer identity for the radio bearer in the variable PDCP_SN_INFO in the response message

      Note: RBs whose SN is Included in the IE "PDCP SN Info" is not STOPPED

• Else if PDCP SN Info is not included in the message
• Stop all RLC AM an UM entities, except SRB - 2
• SRB - 2 is re-established
• if the received message contains "ciphering mode info"
• If security is pending, then it is applied and response is sent with new ciphering configuration
• set the new uplink and downlink HFN component of COUNT-C of RB2 to MAX(uplink HFN component of COUNT-C of RB2, downlink HFN component of COUNT-C of RB2);
• increment by one the downlink and uplink values of the HFN of COUNT-C for RB2;
• calculate the START value
• include the calculated START values for each CN domain in the IE "START list" in the IE "Uplink counter synchronisation info";

After transmission of response message UE needs to wait for RLC ACK for completion of SRNS Relocation procedure in UE.

After reception of successful RLC ack UE shall:

• Configure all RBs to "Continue", except for SRB-2 if not stopped
• re-establish all RLC entities except SRB-2
• Initialize first 20 bits of HFN of the Count - C of all AM and UM RLC entities to the START value transmitted in the response message
• Initialize remaining bits of Count - C of all UM RLC entities to zero

New - URNTI:
UTRAN Radio Network Temporary Identity (URNTI), is an identity allocated to UE having an RRC Connection and identifies the UE with in sUTRAN

• Initially Allocated by UTRAN on RRC Conn Establishment
• During SRNS Relocation NW may allocate New - URNTI to the UE
• On reception of this IE UE needs to calculate START Value and include calculated START in the response message

HSDPA Concepts

The Configuration of HSDPA is as follows:


For the configuration of HSDPA, following logical and physical resources needs to be allocated to UE by UTRAN in any of the reconfiguration message:

1. AM / UM Mode RBs mapped on to HS-DSCH
2. HS-DSCH TrCH - with DCH or without DCH
3. HS-SCCH set
4. DL Info per RL containing F-DPCH or DPCH configuration 
5. HS-PDSCH configuration is given in HS-SCCH 

High Speed - Physical Downlink Shared Channel (HS-PDSCH):

• HS - PDSCH is a DL shared physical channel
• SF = 16, so at max only 16 HS-PDSCH physical channels can be allocated, but by doing so all physical resources (codes) of the cell get exhausted
• Number of HS-PDSCH channels has to be planned in such a way that a cells physical resources are utilized efficiently among dedicated and other common resources.
• Shared between all the UEs in a Cell

MAC-d flows:

• MAC-d flow is the flow of PDUs which are MAC-d multiplexed
• It is almost similar to DCH TrCH
• MAC-d flow signifies a specific QoS on which, logical channels of same QoS are mapped
• MAC-d flows are between MAC-d and MAC-hs or MAC-ehs

HARQ:

• Hybrid Automatic Repeat Request

HARQ Entiry:

• There is only one HARQ Entity per UE in UTRAN.
• The HARQ entity adds Queue ID, Transmit Sequence Number (TSN) and HARQ Process Identifier to the transmitted MAC- hs / MAC - ehs PDU
• There is one HARQ Entity in the UE, which process HARQ Process Identifier received on HS-SCCH associated with MAC - hs PDU received on HS-DSCH.
• Each received MAC - hs PDU is allocated to the HARQ Process, identified by HARQ Process Identifier of the MAC - hs PDU.

HARQ process:

• HARQ Process handles one MAC - hs / MAC - ehs PDU
• MaxHProcesses = Maximum number of H-ARQ processes = 8
• Each HARQ Process has SoftBuffer to store MAC- hs / ehs PDUs

TX / UTRAN side:

• The HARQ process sets the New data indicator in transmitted MAC-hs PDUs. UTRAN should:
• set the New Data Indicator to the value "0" for the first MAC-hs PDU transmitted by a HARQ process;
• not increment the New Data Indicator for retransmissions of a MAC-hs PDU;
• increment the New Data Indicator with one for each transmitted MAC-hs PDU containing new data.
• The HARQ process processes received status messages. UTRAN should:
• deliver received status messages to the scheduler.

RX / UE side:

• HARQ Process, process the New Data Indicator associated with each MAC - hs PDU, indicated by Lower layers

If the MAC-hs PDU is received within 5 sub-frames from the reception of the previous MAC-hs PDU intended for this HARQ process; 

• discard the MAC-hs PDU.

When operating in CELL_DCH state, or in CELL_FACH state with a dedicated H-RNTI, if the MAC-ehs PDU is received within 5 sub-frames from the reception of the previous MAC-ehs PDU intended for this HARQ process:

• discard the MAC-ehs PDU.

=> This means each HARQ Process can be scheduled only once in 5 Sub-frame


1 Radio Frame = 10 ms
1 Radio Frame = 15 slots
1 Sub - Frame = 3 Slots = 2ms
1 Slot = 2560 chips