Professional Documents
Culture Documents
Home : www.sharetechnote.com
Then, How we could have higher data rate and less latencies and more effective usange of radio channels with simpler signaling ? The secrete is
that as the technologies evolves, the higher layer signaling stays similar or even simpler, the lower layer (PHY and MAC) gets complicated and
these lower layers are the one that enable us to enjoy all those evolved features especially high data rate and low latencies. So to understand the
details of the evolved technologies, we have to understand the details of low layer - e.g, PHY and MAC.
Here is a list of questions you have to have when you want to study a new technology.
i) What kind of additional PHY channes has been added comparing to R99 ?
ii) What kind of information is carried by the additional physical channels ?
iii) What kind of MAC identieis are added comparing to R99 ?
iv) What is the role of the new MAC identities especially in terms of scheduling ?
ii) HS-SCCH
iii) HS-DPCCH
iv) F-DPCH
With introduction of these four channels, we could implement many of the methods to improve the data rate which has been briefly descrived in
previous section.
The most important channel is definately HS-DSCH (High Speed Downlink Shared Channel). As the name implies, it is a SHARED channel
whereas in R99 we used a DEDICATED channel. It means all the users within a cell is sharing a single channel which is a big pipes rather than
each of the users has it's own dedicated channel which is a small pipes. With this the network can optimize the resource allocation among the multi
users more efficiently. For example as an extreme case the network allocate 91% of resources to a single UE and only 1% of resources to each of
the remaining 9 users when the nine user does not require much resource or those 9 users are in such a poor environment where it can utilize only
small fraction of the transmission capacity. In case of using dedicated channel, we cannot do this kind of extreme resource allocation because
each of the dedicated channels requires a certain level of minum resource allocation even when the real utilization is lower than the minimum
resource allocation.
I said HS-DSCH is a shared channel. It means that the whole data in the channel is recieved by all users. Then how can a UE figure out whether
the data is for that UE or for some other UEs. I also said in HSDPA multiple modulation scheme is used, QAM and 16 QAM. Then how can a UE
knows whether the data is QAM modulated or 16 QAM modulated ? To carry all these information, another new channel was introduced and it is
HS-CCCH (High Speed Common Control Channel). The information carried by HS-CCCH is as follows :
i) Transport format information - code tree for the data, modulation scheme, transport blocksize
ii) Hybrid-ARQ related information
I said at the beginning, HSDPA uses a shared channel and try to achieve the optimum resource allocation at multi user level. To do this, the
network should know the exact status of the UE. And the network should know whether the data it sent successfully reached it's destination (a
specific UE). To enable this, UE reports its communication quality and the data reception status to the network repeatedly. For UE to send this
information to network, it uses a special channel called HS-DPCCH. This channel carries CQI (Communication Quality Indicator) and Ack/Nak info.
So far so good. It seems there is only advantages of introducing these new channels, but there is nothing that gains 100% without losing anything.
There is a drawback of relying on these shared channel method. It is about power control issue. You know that one of the critical requirement of
WCDMA technology is a very sophisticated power control. If UE power is too low, Node B would have difficulties decoding it and if the power is too
strong it can act as a noise to other UEs communicating with the Node B. For this purpose, Node B sends a UE a power control message
periodically and this message should be different for all the UE because each UE may be in a different channel condition, meaning this power
control message should be a "Dedicated" message. But as I explained HS-DSCH is a shared channel. Then how can Node B deliver the power
control message for each specific UE. The solution was to use R99 dedicated channel (DPCH) carrying only the power control message. But using
a full DPCH only for carrying a small power control message is waste of resource. To improve this situation, from Release 6 a new channel was
introduced and it is F-DPCH (Fractional DPCH). The details of F-DPCH is out of the scope of this section and I wouldn't explain any further on this
channel.
Improved scheduling in HSDPA
The whole purpose of improving scheduling is to decrease the latency between the communicating parties. In this case, the communicating parties
are a UE and a Network. The basic idea of this improvement is to refine the granularity of the scheduling period.
In WCDMA network, this scheduling happens for every TTI (Transmission Time Interval) and in R99 the common TTI is 10 ms (sometimes 20ms,
40ms TTI is taken). In HSDPA, this TTI has been changed to 2 ms. Why it is 2 ms ? What can't it be 1 ms or 4 ms ? It is just a result of trade-off
of various factors. If the TTI is longer like 4ms or 6 ms, the effect of the schedule time refinement would not be outstanding. However if the TTI is
too short, the ratio of scheduling overhead and the refinement would decrease because executing the scheduling algorithm requires a certain
amount of time and resources.
Another means of decreasing latency came from the way to handle the data with errors. In R99, those error can only be detected by RLC by
Ack/Nak from the other party and whether it would request retransmission or not is determined by even higher layer. But in HSDPA, this error is
detected at Physical layer. When a UE recieves data, it checks CRC and sends Ack or Nack on HS-DPCCH being transmitted 5 ms after it
received the data. If UE sends Nack, Network retransmit the data. This error detection and retransmition mechanism is called H-ARQ(Hybrid ARQ).
Another mechansim for the improved scheduling adopted in HSDPA is to allocate the optimized resources for each UE. How can this be achieved
? To do this, the network should need some information to make a best decision for each UE. The important informations for this decision making
is
i) CQI
ii) Buffer Status
iii) Priority of the data
CQI is calculated by the UE based on the signal-to-noise ratio of the recieved common pilot. If you look into details of TFRI determination by MAC
layer, you will notice CQI is the only parameter to determin the TFRI. (What is TFRI ? I will talk this later in this article or some other place. This is
very important to implement a test case for maximum throughput testing).
Buffer Status shows how much data is stored in the buffer for each UE. If there is no data in the buffer, the node B should not allocate any
resources for the UE. So checking the buffer status is also important for optimum resource allocation.
The overall scheduling algoritm is to allocate more resource to UE which report higher CQI, but there are some cases where the Node B should
allocate a certain amount of resources for a specific UE even when it reports a poor CQI. The common example for this situation is a certain RRC
message with tight time out value and some streaming data which has some expiration time. To handle these situation, the scheduler (Node B
MAC layer, MAC-hs) assign a priority to each data blocks and put those blocks into separate priority Queues.
What I explained so far is just brief overview and to provide motivation to study further. If you are involved in test case creation or protocol stack
development, this level of understanding would not help much. If you want to study further so that it may give you practical help for test case
development or protocol stack optimization, I recommend you to study very details of MAC-hs and TFRI selection mechanism.
Why we needed HSUPA ?
In previous section, we talked on why we needed HSDPA and how the HSDPA imroved the data throughput. But HSDPA improved only Downlink
throughput and did nothing about Uplink. So the natural tendency of next evolution would be improvement on Uplink side. This is how we came out
with another technology called HSUPA.
The overall mechanism by which HSUPA improved the uplink throughput is similar to the one used in HSDPA. So if you became familiar with
HSDPA mechanism you would not have difficulties understanding HSUPA mechanism.
Introduction of new Channels in HSUPA
As in HSDPA, several new channels were introduced to implement HSUPA and they are as follows :
i) E-DPDCH
ii) E-DPCCH
iii) E-HICH
iv) E-RGCH
v) E-AGCH
Briefly speaking, E-DPDCH is equivalent version of HS-DPSCH and E-DPCCH is equivalent to HS-SCCH and E-HICH is equivalent to HS-DPCCH.
But there is a main difference between these HSUPA channels and HSDPA channel. E-DPDCH and E-DPCCH are dedicated channels whereas
HS-DPSCH and HS-SCCH are shared channel, but this is understandable because in HSDPA case the source and target of the data transmission
is one-to-many but in HSUPA case the source and target is one-to-one, so it is understandable to use dedicated channels in HSUPA.
There are another big difference between HSDPA and HSUPA. It is about scheduling issue. Regardless of whether it is HSDPA or HSUPA, the
scheduler (the decision maker) is on Node B, not on a UE. For scheduling we need two very important information, the channel quality and buffer
status information. In HSDPA, the information that the decision maker (the scheduler) needs to get from the target of the transmission is only
channel quality information and this information was provided via HS-DPCCH and the buffer status information is already available to the scheduler
because the transmission buffer is located in the same place (node B) as the scheduler. So in HSDPA the transmitter (node B) can send the data
anytime the situation is allowed, but in HSUPA case the transmitter (UE) cannot send the data anytime it wants to send. Before the UE send the
data, it has to check whether the target (the reciever, Node B) is ready and has enough resource to recieve the data. For UE to check the status of
the reciever (node B) and get the approval from the node B, E-AGCH (Absolute Grant Channel) and E-RGCH (Relative Grant Channel) are used.
Node B (the scheduler) send the scheduling grants to UE on when and at what data rate the UE can transmit the data.
The difference between E-AGCH and E-RGCH are
i) E-AGCH is a shared channel and E-RGCH is a dedicated channel
ii) E-AGCH is typically used for large changes in the data rate and the E-RGCH is used for smaller adjustments.
Scheduling in HSUPA
HSUPA Scheduling is quite a complex process but the overall process in simple form are as follows :
i) UE sends Grant Request to Node B
iv) From RACH to CCCH : This goes through MAC-s/sh only. this is common to Release 99 and higher (manatory path for Release 99).
v) From DTCH to HS-DSCH : This goes through MAC-d first and then go through MAC-hs/ehs. In this process, various MAC Control signal gets
involved via MAC-es/MAC-is. This path applies to HSDPA, HSDPA+
vi) From E-DCH to DTCH : This goes through MAC-e/MAC-i first and then go through MAC-es/MAC-is and finally go through MAC-d. This applies to
HSUPA.
One thing you would notice from the analysis, you would notice that all DCCH, DTCH has to go through MAC-d at some point even though the
DTCH is for HSPA or HSPA+.
Now let's get into the details of each component of the MAC layer. A top for study this details would be "Don't try to focus on all the components.
Just try to pick up those path which is related to the current issue you are working on", otherwise you would get entangled with all those lines in the
digaram and completely loose direction.
< Combined Overview on MAC Layer Linking UTRAN and UE >
Another tip of understanding this diagram is to correlate this diagram to MAC PDU structure of each channel that is following this diagram (In
25.321, they are quite a far apart.. so you may lose mental connection between the two).
The end result of most of the procedure shown in the above figure is adding or removing a special portions in MAC header.
The first path we are thinking of is PCCH path which is downlink only and carries Paging message (Paging Type 1). 25.321 9.2.1.3 MAC header for
PCCH says "There is no MAC header for PCH". (The spec says PCH would have MAC-ehs when the PCH is mapped on HS-DSCH, but this does
not happen in the MAC component being discussed in this section).
Next path is BCCH path which is downlink only and carries MIB and SIBs. It can create one of the following three cases, but the case produced by
the MAC component shown in this section is Case a) which does not have any MAC header. I means that it is going through TCTF MUX block
without any modification. (Refer to 25.321 9.2.1.2 MAC header for BCCH for case b) and case c).
Even though PCCH, BCCH path does not have any MAC header in this process and MAC layer still do something for this channel. It is TFC
(Transport format Combination) Selection. MAC-c/sh select a proper TFCI and pass it to transport layer and then the transport layer encode PCH,
BCH data into PHY layer format.
Next Path is RACH to CCCH path (Uplink) and CCCH to FACH path (downlink). RRC Connection Request is going through RACH to CCCH path
and RRC Connection Setup is going through CCCH to FACH path. This path is dealing with the following MAC PDU structure. In CCCH to FACH
path, MAC-c/sh adds TCTF to MAC SDU. In RACH to CCCH path, MAC-c/sh check TCTF value and remove it and then distribute the SDU
accordingly to higher layer.
every MAC data goes through MAC-d sublayer somewhere along it's path. However the data flow within this sublayer differs among R99, R5, R6,
R7 and differs depending on whether it is uplink (From UE to UTRAN) or downlink (From UTRAN to UE).
To help you understand the path for each case, I colored the figure from 25.321 according to each of the case.
Red path represent the case for R99 and it applies to both Uplink and downlink. But when you want to follow the uplink path, you have to read the
figure from bottom to top and for downlink you have to read from top to bottom. The important thing to remember is that for R99 MAC-d is a whole
of MAC layer and the MAC flow does not go through any further processing.
Blue path indicate the path for HSDPA(R5) and HSPA+(R7). As you see, the data for HSDPA, HSPA+ goes through MAC-d with a very little
processing and are passed to MAC-hs (HSDPA) or MAC-ehs(HSPA+) for further detailed processing. You will go back to this processing later in
this section.
Green path shows the path for HSUPA, meaning this is an uplink path. You have to follow from bottom (from the point labeled 'from MAC-es/MACis) to top.
The MAC PDU for R99 (marked in Red path) has following structure. (Note that this PDU applies only to R99 MAC PDU and does not apply to
HSDPA, USUPA PDU. )
Field
Field Name
Bits
Description
TCTF
The purpose of this field is to indicate the logical channel type (class) and meaning
and number of bits for this field differs depending on the logical channel type. (Refer
to Table 9.2.1.1, 9.2.1.2, 9.2.1.4 for the details. These tables are all from 3GPP
25.321)
UE-Id Type
UE-Id Type
This field indicate UE ID type. (There are only two UE types as shown in table
9.2.1.7)
UE-Id
UE Identification
16 or 32
This field indicate UE ID. The bit length of the ID differs depending on which UE-Id
type is used in "UE-id Type" field.
C/T
C/T Field
C/T field indicate the logical channel number for the PDU and the meaning of this
value is listed in Table 9.2.1.5a.
||||
+-mac-hs-AddReconfQueue-List ::= SEQUENCE OF SIZE(1..maxQueueIDs[8]) [1]
||||
| +-MAC-hs-AddReconfQueue ::= SEQUENCE [1]
||||
| +-mac-hsQueueId ::= INTEGER (0..7) [0]
||||
| +-mac-dFlowId ::= INTEGER (0..7) [0]
||||
| +-reorderingReleaseTimer ::= ENUMERATED [rt50]
||||
| +-mac-hsWindowSize ::= ENUMERATED [mws16]
||||
| +-mac-d-PDU-SizeInfo-List ::= SEQUENCE OF SIZE(1..maxMAC-d-PDUsizes[8]) [1]
||||
|
+-MAC-d-PDUsizeInfo ::= SEQUENCE
||||
|
+-mac-d-PDU-Size ::= INTEGER (1..5000) [336]
||||
|
+-mac-d-PDU-Index ::= INTEGER (0..7) [0]
||||
+-mac-hs-DelQueue-List ::= SEQUENCE OF OPTIONAL:Omit
| | | +-dch-QualityTarget ::= SEQUENCE OPTIONAL:Omit
| | +-DL-AddReconfTransChInformation-r5 ::= SEQUENCE [1]
| +-frequencyInfo ::= SEQUENCE OPTIONAL:Omit
| +-maxAllowedUL-TX-Power ::= INTEGER OPTIONAL:Omit
| +-ul-ChannelRequirement ::= CHOICE [ul-DPCH-Info] OPTIONAL:Exist
| +-modeSpecificPhysChInfo ::= CHOICE [fdd]
| +-dl-HSPDSCH-Information ::= SEQUENCE [11] OPTIONAL:Exist
| +-dl-CommonInformation ::= SEQUENCE [11] OPTIONAL:Exist
| +-dl-InformationPerRL-List ::= SEQUENCE OF SIZE(1..maxRL[8]) [1] OPTIONAL:Exist
+-radioBearerSetup-r5-add-ext ::= BIT STRING OPTIONAL:Omit
+-v5d0NonCriticalExtenstions ::= SEQUENCE OPTIONAL:Omit
This is the MAC component for HSDPA and the detailed structure is as follows (R99 system does not have this module). Overall process that this
component is performing are :
i) Take in multiples of MAC-d PDUs
ii) Combine the multiple PDUs into a single big PDU
iii) Convert the combined PDU into a HARQ entity
iv) Encode the HARQ Entity according to the selected TFRI
The MAC PDU created by this module is as follows and the meaning of each field is summarized in a table following next.
Note : Just by reading the PDU structure shown here you would notice a couple of characteristics as follows.
i) A MAC-hs PDU can carry the data coming from only one Priority Queue.
ii) A MAC-hs PDU can carry the mulitple MAC-d PDUs. (These MAC-d PDUs can have same or different sizes).
Field
Field Name
Bits
Description
VF
Version Flag
Queue ID
Queue identifier
The Queue ID field provides identification of the reordering queue in the receiver, in
order to support independent buffer handling of data belonging to different reordering
queues
TSN
Transmission Sequence
Number
The TSN field provides an identifier for the transmission sequence number on the HSDSCH. The TSN field is used for reordering purposes to support in-sequence delivery
to higher layers
SID
The SID fields identifies the size of a set of consecutive MAC-d PDUs. The MAC-d
PDU size for a given SID is configured by higher layers and is independent for each
Queue ID
The number of consecutive MAC-d PDUs with equal size is identified with the N field.
In FDD mode, the maximum number of PDUs transmitted in a single TTI shall be
assumed to be 70
The F field is a flag indicating if more fields are present in the MAC-hs header or not.
If the F field is set to "0". the F field is followed by an additional set of SID, N and F
fields. If the F field is set to "1" the F field is followed by a MAC-d PDU. The
maximum number of MAC-hs header extensions, i.e. number of fields F set to "0", in
a single TTI shall be assumed to be 7. If more extensions than the maximum defined
for the corresponding mode are included in a TTI, the UE behaviour is unspecified
Flag
Now go back to previous item ("Overview on MAC-hs in UTRAN : HSDPA") and see the MAC-hs PDU structure and try to understand how the
structure will change as it flows from the bottom of this block (input) to the top of the block (output).
< Overview on MAC-e/es/i/is in UTRAN : HSUPA>
This is about HSUPA processing on UTRAN side. This process is so complicated and multiple modules get involved in this process. I strongly
recommend you to revisit < Overview on MAC Layer in UTRAN >, go through Figure 4.2.4.1 and get familiar to HSUPA path as much as possible.
You would see the two blocks in figure 4.2.4.1. MAC-e/i at the bottom left part and MAC-es/is at top right side. HSUPA data goes through MAC-e/i
first and then go to MAC-es/is.
As you will see from the following figures, MAC-e is more focused on L1 specific process like HARQ and Grant/ACK-NACK transmission. These
processes requires a lot of real time processing power, so MAC-e is located in Node B.
On the contrary MAC-es is doing reordering and disassemble the MAC-e PDUs into multiple MAC-d PDU which does not require such a tight real
time process. So this module is located in RNC.
The first question is "The data goes through MAC-e and MAC-i simultaneously ?" and "The data goes through MAC-es and MAC-is simultaneously
?".
The answer is NO. The HSUPA data goes through only one of the path. It has only two of the combination as follows :
i) MAC-e ---> MAC-es
ii) MAC-i ---> MAC-is
So you have to study MAC-e/MAC-es path and MAC-i/MAC-is path separately.
Then the next question is how UE can determine which path to follow ? This decision comes from the higher layer signaling message.
I think I have to update this sections for quite often since there are many details I have to revisit. For now, I will try to create a big picture. (When
you read this figure, you should be careful about the direction. For the path marked in Black lines, you have to follow from the bottom to the top and
for the path marked in red, you should follow from top to the bottom).
Following is the structure of MAC-es. One thing you would notice is that it has many blocks for Reordering. Why do you think we need this kind of
reordering ? The answer would be that there are possibility that multiple PDUs from MAC-e may arrive out of sequence ? Then the question is How
come those PDUs can arrive out of sequence. It is mainly because the HARQ process in MAC-e. Since multiple HARQ processes can run in
paralell, we cannot guarantee that all those data stream coming out of the HARQ process arrive at MAC-es in sequence. So we need some
mechanism to realign these incoming PDUs into a proper sequence before passing them to MAC-d. This is the role of Reordering block.
Following is MAC-i/MAC-is path. For now, just go through the diagram and try to make your own story.
It would be more helpful if have the MAC PDU structure, but will come in the following section < Overview on MAC-e/es in UE : HSUPA >. I
normally put the PDU structure on transmission side.
< Overview on MAC-e/es and MAC-i/is in UE : HSUPA >
UE side HSUPA block is a little bit simpler than UTRAN side since MAC-e/es are combined in one module.
For now just try to follow all the possible paths in the following figures.
(When you read this figure, you should be careful about the direction. For the path marked in Black lines, you have to follow from the bottom to the
top and for the path marked in red, you should follow from top to the bottom).
For every transmission (TTI), UE MAC-es/s determines the data rate by following criteria
i) Current Serving Grant
ii) Amount of Data waiting to be transmitted
iii) Minimum Allowed Spreading Factor (determined by higher layer signaling)
This sublayer can use multiple HARQs in paralelle and the maximum number of HARQ differs depending on TTI.
i) For 10 ms TTI - 4 HARQs
ii) For 2 ms TTI - 8 HARQs
The HARQ process that transmits in a particular frame is determined from the current SFN (this is unlike HSDPA where each HARQ process
transmits in a round-robin fashion).
UE can use chase combining (transmission of the exact same bits again) or incremental redundancy (transmission of a different set of bits) for
HARQ retransmission and the RRC layer message determines which method UE has to use.
You will get a little bit detailed understanding if you look into the PDU structure as follows.
First PDU is MAC-es PDU. From this structure, you would notice that the main role of MAC-es is to take in multiple MAC-d PDUs and combine
them into a single MAC-es PDU.
Meaning of the parameters in the MAC-es PDU is described in the table below.
Field
Field Name
Bits
Description
TSN
Transmission Sequence
Number
The TSN field provides the transmission sequence number for the MAC-es PDU. This
information is used for reordering purposes to support in-sequence delivery to higher
layers.
DDI
The DDI field identifies the logical channel, MAC-d flow and size of the MAC-d PDUs
concatenated into the associated MAC-es PDU. The mapping between the DDI values
and the logical channel ID, MAC-d flow and PDU size is provided by higher layers
The number of consecutive MAC-d PDUs corresponding to the same DDI value.
Now let's look into MAC-e PDU. From this, you would notice that MAC-e takes in multiple MAC-es PDUs and combine them into a single/big MACe PDU. Another thing you should notice is.. MAC-e collect all DDI/N part and connect all of them at the beginning of MAC-e PDU and put all the
payload part of MAC-es PDU next to the DDI/N portion.
Field
Field Name
Bits
Description
LCH-ID
The LCH-ID field provides identification of the logical channel at the receiver and the
re-ordering buffer destination of a reordering SDU.
TSN
Transmission Sequence
Number
The TSN field provides an identifier for the transmission sequence number on the HSDSCH. The TSN field is used for reordering purposes to support in-sequence delivery
to higher layers.
SI
Segmentation Indication
The SI field indicates if the MAC-ehs SDU has been segmented and it shows which
part of the segment it is if it is segmented .(See the table 9.2.2.1 following this table)
Length
11
The L field provides the length of the reordering SDU in octets. The reordering SDU
size can vary for each reordering SDU in the MAC-ehs PDU, and is set for each
reordering SDU individually.
The F field is a flag indicating if more fields are present in the MAC-ehs header or not.
If the F field is set to "0" the F field is followed by an additional set of LCH-ID and L
fields and optionally TSN and SI fields. If the F field is set to "1" the F field is followed
by a reordering PDU. Each header extension corresponds to one reordering SDU
Flag
111010111011110000000100111010111011110011101011101111001110010001111011 ......
LCID(4 bits)
L(11 bits)
TSN(6 bits)
SI(2 bits)
F(1 bit)
BIN
DEC
BIN
DEC
BIN
DEC
BIN
DEC
BIN
DEC
1110
14
10111011110
1502
000000
10
1110
14
10111011110
1502
1110
14
10111011110
1502
1110
14
01000111101
573
This is UE side of MAC-ehs. Everything is in reverse order of UTRAN side. You have to read from the bottom of this figure to the top.
S-RNTI
rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetup-r7.newU-RNTI.s-RNTI
SRNC identity
rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetup-r7.newU-RNTI.srnc-Identity
C-RNTI
rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetup-r7.new-cRNTI
Activation time
rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetupr7.activationTime
i) rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetupr7.newPrimary-E-RNTI
ii) radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.r6.radioBearerSetup-r6.newPrimary-E-RNTI
i) rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetupr7.newSecondary-E-RNTI
ii) radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.r6.radioBearerSetup-r6.newSecondary-E-RNTI
RB information elements
Transport channel identity,
i) rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetupr7.specificationMode.complete.srb-InformationSetupList.SRB-InformationSetup-r7[0].rb-MappingInfo.RBMappingOption-r7[0].dl-LogicalChannelMappingList.DL-LogicalChannelMapping-r7[0].logicalChannelIdentity
Logical channel identity,
ii) radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.r6.radioBearerSetupr6.specificationMode.complete.rab-InformationSetupList.RAB-InformationSetup-r6[0].rbInformationSetupList.RB-InformationSetup-r6[0].rb-MappingInfo.RB-MappingOption-r6[0].dlLogicalChannelMappingList.DL-LogicalChannelMapping-r5[0].logicalChannelIdentity
i) rrcConnectionSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.rrcConnectionSetupr7.specificationMode.complete.srb-InformationSetupList.SRB-InformationSetup-r7[0].rb-MappingInfo.RBMappingOption-r7[0].ul-LogicalChannelMappings.oneLogicalChannel.mac-LogicalChannelPriority
ii) radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.r6.radioBearerSetupr6.specificationMode.complete.rab-InformationSetupList.RAB-InformationSetup-r6[0].rbInformationSetupList.RB-InformationSetup-r6[0].rb-MappingInfo.RB-MappingOption-r6[0].ulLogicalChannelMappings.oneLogicalChannel.mac-LogicalChannelPriority
radioBearerSetup.later-than-r3.criticalExtensions.criticalExtensions.criticalExtensions.r6.radioBearerSetupr6.specificationMode.complete.rab-InformationSetupList.RAB-InformationSetup-r6[0].rbInformationSetupList.RB-InformationSetup-r6[0].rb-MappingInfo.RB-MappingOption-r6[0].ulLogicalChannelMappings.oneLogicalChannel.ul-TrCH-Type.e-dch.ddi
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.dlCommonInformation.mac-hsResetIndicator
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.mac-es-e-resetIndicator
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetupr7.specificationMode.complete.dl-AddReconfTransChInfoList.DL-AddReconfTransChInformation-r7[0].tfsSignallingMode.hsdsch.dl-MAC-HeaderType.mac-ehs.mac-ehs-AddReconfQueue-List.MAC-ehsAddReconfReordQ[0].reorderingReleaseTimer
i) radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetupr7.specificationMode.complete.dl-AddReconfTransChInfoList.DL-AddReconfTransChInformation-r7[0].tfsSignallingMode.hsdsch.harqInfo
ii) radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetupr7.specificationMode.complete.ul-AddReconfTransChInfoList.UL-AddReconfTransChInformation-r7[0].edch.harq-Info
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetupr7.specificationMode.complete.ul-AddReconfTransChInfoList.UL-AddReconfTransChInformation-r7[0].edch.modeSpecific.fdd.tti
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetupr7.specificationMode.complete.ul-AddReconfTransChInfoList.UL-AddReconfTransChInformation-r7[0].edch.addReconf-MAC-d-FlowList
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetupr7.specificationMode.complete.ul-AddReconfTransChInfoList.UL-AddReconfTransChInformation-r7[0].edch.addReconf-MAC-d-FlowList.E-DCH-AddReconf-MAC-d-Flow-r7[0].transmissionGrantType.nonScheduledTransGrantInfo
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.modeSpecificInfo.fdd.e-DPCCH-Info.e-DPCCH-DPCCH-PowerOffset
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.modeSpecificInfo.fdd.e-DPCCH-Info.happyBit-DelayCondition
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.modeSpecificInfo.fdd.e-DPDCH-Info.e-TFCI-TableIndex
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.modeSpecificInfo.fdd.e-DPDCH-Info.e-DCH-MinimumSet-E-TFCI
Reference E-TFCI
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.modeSpecificInfo.fdd.e-DPDCH-Info.reference-E-TFCIs
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.modeSpecificInfo.fdd.e-DPDCH-Info.schedulingInfoConfiguration.periodicityOfSchedInfoNoGrant
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.ulEDCH-Information.modeSpecificInfo.fdd.e-DPDCH-Info.schedulingInfoConfiguration.periodicityOfSchedInfoGrant
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.dtx-drxInfo.dtx-Info.e-dch-TTI-Length.dtx-e-dch-TTI-2ms.mac-dtx-Cycle-2ms
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.dtx-drxInfo.dtx-Info.mac-InactivityThreshold
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.dtx-drxTimingInfo.timing.newTiming.ue-dtx-drx-Offset
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.hs-scchLessInfo.hs-scchLessOperation
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.dtx-drxInfo.drx-Info.ue-GrantMonitoring-InactivityThreshold
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.dtx-drxInfo.dtx-Info.ue-dtx-cycle2InactivityThreshold
radioBearerSetup.later-thanr3.criticalExtensions.criticalExtensions.criticalExtensions.criticalExtensions.r7.radioBearerSetup-r7.dtx-drxInfo.dtx-Info.ue-dtx-cycle2DefaultSG
Others
Description
SIB5
Configures Common Channels (e.g, RACH, FACH,PCH) and inform UEs of it's HSDPA/HSUPA Capability.
Network setups the radio bearer for both data (DRB) and the signaling(SRB)
Not let's look into some examples for each of the messages listed above.
First SIB5 is broadcasting about it's HSPA capability as shown in the red part of the message below.
SysInfoType5 ::= SEQUENCE [001]
+-sib6indicator ::= BOOLEAN [FALSE]
+-pich-PowerOffset ::= INTEGER (-10..5) [-5]
+-modeSpecificInfo ::= CHOICE [fdd]
+-primaryCCPCH-Info ::= CHOICE OPTIONAL:Omit
+-prach-SystemInformationList ::= SEQUENCE OF SIZE(1..maxPRACH[16]) [1]
+-sCCPCH-SystemInformationList ::= SEQUENCE OF SIZE(1..maxSCCPCH[16]) [1]
+-cbs-DRX-Level1Information ::= SEQUENCE OPTIONAL:Omit
+-v4b0NonCriticalExtensions ::= SEQUENCE [11] OPTIONAL:Exist
+-sysInfoType5-v4b0ext ::= SEQUENCE [00001] OPTIONAL:Exist
+-v590NonCriticalExtensions ::= SEQUENCE [01] OPTIONAL:Exist
+-sysInfoType5-v590ext ::= SEQUENCE OPTIONAL:Omit
+-v650NonCriticalExtensions ::= SEQUENCE [01] OPTIONAL:Exist
+-sysInfoType5-v650ext ::= SEQUENCE OPTIONAL:Omit
+-v680NonCriticalExtensions ::= SEQUENCE [11] OPTIONAL:Exist
+-sysInfoType5-v680ext ::= SEQUENCE [1] OPTIONAL:Exist
| +-hsdpa-CellIndicator ::= ENUMERATED [hsdpa-CapableCell] OPTIONAL:Exist
+-v690NonCriticalExtensions ::= SEQUENCE [0] OPTIONAL:Exist
+-sysInfoType5-v690ext ::= SEQUENCE [1000]
| +-edch-CellIndicator ::= ENUMERATED [edch-CapableCell] OPTIONAL:Exist
| +-sccpch-SystemInformation-MBMS ::= CHOICE OPTIONAL:Omit
| +-additionalPRACH-TF-and-TFCS-CCCH-List ::= SEQUENCE OF OPTIONAL:Omit
| +-cBS-DRX-Level1Information-extension ::= ENUMERATED OPTIONAL:Omit
+-v770NonCriticalExtensions ::= SEQUENCE OPTIONAL:Omit
UE send its very basic HSPA capability via RRC Connection Request message as shown below in red.
UL-CCCH-Message ::= SEQUENCE [0]
+-integrityCheckInfo ::= SEQUENCE OPTIONAL:Omit
+-message ::= CHOICE [rrcConnectionRequest]
+-rrcConnectionRequest ::= SEQUENCE [11]
+-initialUE-Identity ::= CHOICE [tmsi-and-LAI]
+-establishmentCause ::= ENUMERATED [originatingHighPrioritySignalling]
+-protocolErrorIndicator ::= ENUMERATED [noError]
+-measuredResultsOnRACH ::= SEQUENCE [0] OPTIONAL:Exist
+-v3d0NonCriticalExtensions ::= SEQUENCE [1] OPTIONAL:Exist
+-rRCConnectionRequest-v3d0ext ::= SEQUENCE [0]
+-v4b0NonCriticalExtensions ::= SEQUENCE [1] OPTIONAL:Exist
+-rrcConnectionRequest-v4b0ext ::= SEQUENCE
| +-accessStratumReleaseIndicator ::= ENUMERATED [rel-6]
+-v590NonCriticalExtensions ::= SEQUENCE [1] OPTIONAL:Exist
+-rrcConnectionRequest-v590ext ::= SEQUENCE
+-v690NonCriticalExtensions ::= SEQUENCE [1] OPTIONAL:Exist
+-rrcConnectionRequest-v690ext ::= SEQUENCE [10]
| +-ueCapabilityIndication ::= ENUMERATED [hsdch-edch] OPTIONAL:Exist
| +-measuredResultsOnRACHinterFreq ::= SEQUENCE OPTIONAL:Omit
| +-domainIndicator ::= CHOICE [ps-domain]
+-v6b0NonCriticalExtensions ::= SEQUENCE [1] OPTIONAL:Exist
+-rrcConnectionRequest-v6b0ext ::= SEQUENCE [0]
| +-mbmsSelectedServices ::= SEQUENCE OPTIONAL:Omit
+-v6e0NonCriticalExtensions ::= SEQUENCE [0] OPTIONAL:Exist
||
|
| +-reorderingReleaseTimer ::= ENUMERATED [rt50]
||
|
| +-mac-hsWindowSize ::= ENUMERATED [mws16]
||
|
| +-mac-d-PDU-SizeInfo-List ::= [1]
||
|
|
+-MAC-d-PDUsizeInfo ::= SEQUENCE
||
|
|
+-mac-d-PDU-Size ::= INTEGER (1..5000) [148]
||
|
|
+-mac-d-PDU-Index ::= INTEGER (0..7) [0]
||
|
+-mac-hs-DelQueue-List ::= SEQUENCE OF OPTIONAL:Omit
||
+-dch-QualityTarget ::= SEQUENCE OPTIONAL:Omit
| +-frequencyInfo ::= SEQUENCE OPTIONAL:Omit
| +-multi-frequencyInfo ::= SEQUENCE OPTIONAL:Omit
| +-dtx-drx-TimingInfo ::= SEQUENCE OPTIONAL:Omit
| +-dtx-drx-Info ::= SEQUENCE OPTIONAL:Omit
| +-hs-scch-LessInfo ::= SEQUENCE OPTIONAL:Omit
| +-maxAllowedUL-TX-Power ::= INTEGER OPTIONAL:Omit
| +-ul-DPCH-Info ::= SEQUENCE [1] OPTIONAL:Exist
| | +-ul-DPCH-PowerControlInfo ::= CHOICE [fdd] OPTIONAL:Exist
| +-ul-EDCH-Information ::= SEQUENCE [1] OPTIONAL:Exist
| | +-mac-es-e-resetIndicator ::= ENUMERATED [true] OPTIONAL:Exist
| | +-modeSpecificInfo ::= CHOICE [fdd]
| | +-fdd ::= SEQUENCE [1110]
||
+-e-DPCCH-Info ::= SEQUENCE [00] OPTIONAL:Exist
||
| +-e-DPCCH-DPCCH-PowerOffset ::= INTEGER (0..8) [0]
||
| +-happyBit-DelayCondition ::= ENUMERATED [ms100]
||
| +-e-TFC-Boost-Info ::= SEQUENCE OPTIONAL:Omit
||
| +-e-DPDCH-PowerInterpolation ::= BOOLEAN OPTIONAL:Omit
||
+-e-DPDCH-Info ::= SEQUENCE [100] OPTIONAL:Exist
||
| +-e-TFCI-TableIndex ::= INTEGER (0..1) [0]
||
| +-e-DCH-MinimumSet-E-TFCI ::= INTEGER (0..127) [9] OPTIONAL:Exist
||
| +-reference-E-TFCIs ::= SEQUENCE OF SIZE(1..8) [2]
||
| | +-E-DPDCH-Reference-E-TFCI-r7 ::= SEQUENCE
||
| | | +-reference-E-TFCI ::= INTEGER (0..127) [11]
||
| | | +-reference-E-TFCI-PO-r7 ::= INTEGER (0..31) [4]
||
| | +-E-DPDCH-Reference-E-TFCI-r7 ::= SEQUENCE
||
| | +-reference-E-TFCI ::= INTEGER (0..127) [83]
||
| | +-reference-E-TFCI-PO-r7 ::= INTEGER (0..31) [16]
||
| +-maxChannelisationCodes ::= ENUMERATED [sf2x2]
||
| +-pl-NonMax ::= INTEGER (11..25) [21]
||
| +-schedulingInfoConfiguration ::= SEQUENCE [00]
||
| | +-periodicityOfSchedInfo-NoGrant ::= ENUMERATED OPTIONAL:Omit
||
| | +-periodicityOfSchedInfo-Grant ::= ENUMERATED OPTIONAL:Omit
||
| | +-powerOffsetForSchedInfo ::= INTEGER (0..6) [0]
||
| +-threeIndexStepThreshold ::= INTEGER OPTIONAL:Omit
||
| +-twoIndexStepThreshold ::= INTEGER OPTIONAL:Omit
||
+-schedulingTransmConfiguration ::= SEQUENCE [00] OPTIONAL:Exist
||
| +-ms2-SchedTransmGrantHARQAlloc ::= BIT STRING OPTIONAL:Omit
||
| +-servingGrant ::= SEQUENCE OPTIONAL:Omit
||
+-ul-16QAM-Settings ::= SEQUENCE OPTIONAL:Omit
| +-dl-HSPDSCH-Information ::= SEQUENCE [11] OPTIONAL:Exist
| | +-hs-scch-Info ::= SEQUENCE OPTIONAL:Exist
| | | +-modeSpecificInfo ::= CHOICE [fdd]
| | | +-fdd ::= SEQUENCE [0]
|||
+-hS-SCCHChannelisationCodeInfo ::= [1]
|||
| +-HS-SCCH-Codes ::= INTEGER (0..127) [7]
|||
+-dl-ScramblingCode ::= INTEGER OPTIONAL:Omit
| | +-measurement-feedback-Info ::= SEQUENCE OPTIONAL:Exist
| | | +-modeSpecificInfo ::= CHOICE [fdd]
| | | +-fdd ::= SEQUENCE
|||
+-measurementPowerOffset ::= INTEGER (-12..26) [12]
|||
+-feedback-cycle ::= ENUMERATED [fc4]
|||
+-cqi-RepetitionFactor ::= INTEGER (1..4) [1]
|||
+-deltaCQI ::= INTEGER (0..8) [5]
| | +-modeSpecificInfo ::= CHOICE [fdd]
| | +-fdd ::= SEQUENCE [0]
||
+-dl-64QAM-Configured ::= ENUMERATED OPTIONAL:Omit
| +-dl-CommonInformation ::= SEQUENCE [110] OPTIONAL:Exist
| | +-dl-dpchInfoCommon ::= CHOICE [dl-FDPCH-InfoCommon] OPTIONAL:Exist
| | | +-dl-FDPCH-InfoCommon ::= SEQUENCE [11]
| | | +-cfnHandling ::= CHOICE [initialise]
| | | | +-initialise ::= NULL
| | | +-dl-FDPCH-PowerControlInfo ::= SEQUENCE OPTIONAL:Exist
| | | | +-modeSpecificInfo ::= CHOICE [fdd]
| | | | +-fdd ::= SEQUENCE
||| |
+-dpc-Mode ::= ENUMERATED [singleTPC]
| | | +-dl-FDPCH-TPCcommandErrorRate ::= INTEGER (1..16) [4] OPTIONAL:Exist
| | +-modeSpecificInfo ::= CHOICE [fdd]
| | | +-fdd ::= SEQUENCE [101]
| | | +-defaultDPCH-OffsetValue ::= INTEGER (0..599) [0] OPTIONAL:Exist
| | | +-dpch-CompressedModeInfo ::= SEQUENCE OPTIONAL:Omit
| | | +-tx-DiversityMode ::= ENUMERATED [noDiversity] OPTIONAL:Exist
|
|
|
|
|
|
|
|
|
|
If UE is capable of Rel 7 features and network support it, UE would send some additional information about Rel 7 in RRC Connection Setup
Complete as follows.
+-v770NonCriticalExtensions ::= SEQUENCE [0] OPTIONAL:Exist
+-ue-RadioAccessCapability-v770ext ::= SEQUENCE [0010]
| +-pdcp-Capability ::= SEQUENCE OPTIONAL:Omit
| +-rlc-Capability ::= SEQUENCE
| | +-supportOfTwoLogicalChannel ::= BOOLEAN [FALSE]
| +-rf-Capability ::= SEQUENCE OPTIONAL:Omit
| +-physicalChannelCapability ::= SEQUENCE [1000]
| | +-fddPhysChCapability ::= SEQUENCE OPTIONAL:Exist
| | | +-downlinkPhysChCapability ::= SEQUENCE [11111]
| | | | +-hsdsch-physical-layer-category-ext ::= INTEGER (1..20) [10] OPTIONAL:Exist
| | | | +-hsscchlessHsdschOperation ::= ENUMERATED [true] OPTIONAL:Exist
| | | | +-enhancedFdpch ::= ENUMERATED [true] OPTIONAL:Exist
| | | | +-hsdschReception-CellFach ::= ENUMERATED [true] OPTIONAL:Exist
| | | | +-hsdschReception-CellUraPch ::= ENUMERATED [true] OPTIONAL:Exist
| | | +-uplinkPhysChCapability ::= SEQUENCE [111]
| | | +-edch-PhysicalLayerCategory-extension ::= INTEGER (7) [7] OPTIONAL:Exist
| | | +-discontinuousDpcchTransmission ::= ENUMERATED [true] OPTIONAL:Exist
| | | +-slotFormat4 ::= ENUMERATED [true] OPTIONAL:Exist
| +-multiModeRAT-Capability ::= SEQUENCE [0]
| | +-supportOfPSHandoverToGAN ::= ENUMERATED OPTIONAL:Omit
| +-ue-PositioningCapability ::= SEQUENCE [0]
| | +-ue-GANSSPositioning-Capability ::= SEQUENCE OPTIONAL:Omit
| +-mac-ehsSupport ::= ENUMERATED [true] OPTIONAL:Exist
| +-ue-specificCapabilityInformation ::= ENUMERATED OPTIONAL:Omit
+-v790NonCriticalExtensions ::= SEQUENCE OPTIONAL:Omit
Next is Radio Bearer Setup. This is the most complicated message and the detailed configuration would vary in wide degress depending on
situations. So following is only one example of Radio Bearer Setup message you would see in the field.
DL-DCCH-Message ::= SEQUENCE [1]
+-integrityCheckInfo ::= SEQUENCE OPTIONAL:Exist
| +-messageAuthenticationCode ::= BIT STRING SIZE(32) [10001101110111011010111101110101]
| +-rrc-MessageSequenceNumber ::= INTEGER (0..15) [1]
+-message ::= CHOICE [radioBearerSetup]
+-radioBearerSetup ::= CHOICE [later-than-r3]
+-later-than-r3 ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [criticalExtensions]
+-criticalExtensions ::= CHOICE [criticalExtensions]
+-criticalExtensions ::= CHOICE [criticalExtensions]
+-criticalExtensions ::= CHOICE [r7]
+-r7 ::= SEQUENCE [00]
+-radioBearerSetup-r7 ::= SEQUENCE [00100011000000011001111110]
| +-integrityProtectionModeInfo ::= SEQUENCE OPTIONAL:Omit
| +-cipheringModeInfo ::= SEQUENCE OPTIONAL:Omit
| +-activationTime ::= INTEGER (0..255) [160] OPTIONAL:Exist
| +-new-U-RNTI ::= SEQUENCE OPTIONAL:Omit
| +-new-C-RNTI ::= BIT STRING OPTIONAL:Omit
| +-new-DSCH-RNTI ::= BIT STRING OPTIONAL:Omit
| +-new-H-RNTI ::= BIT STRING SIZE(16) [0001001000110100] OPTIONAL:Exist
| +-newPrimary-E-RNTI ::= BIT STRING SIZE(16) [0001001000110100] OPTIONAL:Exist
| +-newSecondary-E-RNTI ::= BIT STRING OPTIONAL:Omit
| +-rrc-StateIndicator ::= ENUMERATED [cell-DCH]
| +-utran-DRX-CycleLengthCoeff ::= SEQUENCE OPTIONAL:Omit
| +-ura-Identity ::= BIT STRING OPTIONAL:Omit
| +-supportForChangeOfUE-Capability ::= BOOLEAN OPTIONAL:Omit
| +-cn-InformationInfo ::= SEQUENCE OPTIONAL:Omit
| +-specificationMode ::= CHOICE [complete]
| | +-complete ::= SEQUENCE [0100000001001]
| | +-srb-InformationSetupList ::= SEQUENCE OF OPTIONAL:Omit
| | +-rab-InformationSetupList ::= SEQUENCE OF SIZE(1..maxRABsetup[16]) [1]
| | | +-RAB-InformationSetup-r7 ::= SEQUENCE
| | | +-rab-Info ::= SEQUENCE [000]
| | | | +-rab-Identity ::= CHOICE [gsm-MAP-RAB-Identity]
| | | | | +-gsm-MAP-RAB-Identity ::= BIT STRING SIZE(8) [00000101]
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
+-numberOfTPC-Bits ::= ENUMERATED [tpc4] OPTIONAL:Exist
| +-ul-EDCH-Information ::= SEQUENCE [0] OPTIONAL:Exist
| | +-mac-es-e-resetIndicator ::= ENUMERATED OPTIONAL:Omit
| | +-modeSpecificInfo ::= CHOICE [fdd]
| | +-fdd ::= SEQUENCE [1110]
||
+-e-DPCCH-Info ::= SEQUENCE [00] OPTIONAL:Exist
||
| +-e-DPCCH-DPCCH-PowerOffset ::= INTEGER (0..8) [0]
||
| +-happyBit-DelayCondition ::= ENUMERATED [ms200]
||
| +-e-TFC-Boost-Info ::= SEQUENCE OPTIONAL:Omit
||
| +-e-DPDCH-PowerInterpolation ::= BOOLEAN OPTIONAL:Omit
||
+-e-DPDCH-Info ::= SEQUENCE [100] OPTIONAL:Exist
||
| +-e-TFCI-TableIndex ::= INTEGER (0..1) [0]
||
| +-e-DCH-MinimumSet-E-TFCI ::= INTEGER (0..127) [9] OPTIONAL:Exist
||
| +-reference-E-TFCIs ::= SEQUENCE OF SIZE(1..8) [2]
||
| | +-E-DPDCH-Reference-E-TFCI-r7 ::= SEQUENCE
||
| | | +-reference-E-TFCI ::= INTEGER (0..127) [11]
||
| | | +-reference-E-TFCI-PO-r7 ::= INTEGER (0..31) [4]
||
| | +-E-DPDCH-Reference-E-TFCI-r7 ::= SEQUENCE
||
| | +-reference-E-TFCI ::= INTEGER (0..127) [83]
||
| | +-reference-E-TFCI-PO-r7 ::= INTEGER (0..31) [16]
||
| +-maxChannelisationCodes ::= ENUMERATED [sf2x2]
||
| +-pl-NonMax ::= INTEGER (11..25) [21]
||
| +-schedulingInfoConfiguration ::= SEQUENCE [00]
||
| | +-periodicityOfSchedInfo-NoGrant ::= ENUMERATED OPTIONAL:Omit
||
| | +-periodicityOfSchedInfo-Grant ::= ENUMERATED OPTIONAL:Omit
||
| | +-powerOffsetForSchedInfo ::= INTEGER (0..6) [0]
||
| +-threeIndexStepThreshold ::= INTEGER OPTIONAL:Omit
||
| +-twoIndexStepThreshold ::= INTEGER OPTIONAL:Omit
||
+-schedulingTransmConfiguration ::= SEQUENCE [00] OPTIONAL:Exist
||
| +-ms2-SchedTransmGrantHARQAlloc ::= BIT STRING OPTIONAL:Omit
||
| +-servingGrant ::= SEQUENCE OPTIONAL:Omit
||
+-ul-16QAM-Settings ::= SEQUENCE OPTIONAL:Omit
| +-dl-HSPDSCH-Information ::= SEQUENCE [11] OPTIONAL:Exist
| | +-hs-scch-Info ::= SEQUENCE OPTIONAL:Exist
| | | +-modeSpecificInfo ::= CHOICE [fdd]
| | | +-fdd ::= SEQUENCE [0]
|||
+-hS-SCCHChannelisationCodeInfo ::= [1]
|||
| +-HS-SCCH-Codes ::= INTEGER (0..127) [7]
|||
+-dl-ScramblingCode ::= INTEGER OPTIONAL:Omit
| | +-measurement-feedback-Info ::= SEQUENCE OPTIONAL:Exist
| | | +-modeSpecificInfo ::= CHOICE [fdd]
| | | +-fdd ::= SEQUENCE
|||
+-measurementPowerOffset ::= INTEGER (-12..26) [12]
|||
+-feedback-cycle ::= ENUMERATED [fc4]
|||
+-cqi-RepetitionFactor ::= INTEGER (1..4) [1]
|||
+-deltaCQI ::= INTEGER (0..8) [5]
| | +-modeSpecificInfo ::= CHOICE [fdd]
| | +-fdd ::= SEQUENCE [0]
||
+-dl-64QAM-Configured ::= ENUMERATED OPTIONAL:Omit
| +-dl-CommonInformation ::= SEQUENCE [100] OPTIONAL:Exist
| | +-dl-dpchInfoCommon ::= CHOICE [dl-FDPCH-InfoCommon] OPTIONAL:Exist
| | | +-dl-FDPCH-InfoCommon ::= SEQUENCE [11]
| | | +-cfnHandling ::= CHOICE [maintain]
| | | | +-maintain ::= SEQUENCE [1]
| | | | +-timingmaintainedsynchind ::= ENUMERATED [false] OPTIONAL:Exist
| | | +-dl-FDPCH-PowerControlInfo ::= SEQUENCE OPTIONAL:Exist
| | | | +-modeSpecificInfo ::= CHOICE [fdd]
| | | | +-fdd ::= SEQUENCE
||| |
+-dpc-Mode ::= ENUMERATED [singleTPC]
| | | +-dl-FDPCH-TPCcommandErrorRate ::= INTEGER (1..16) [4] OPTIONAL:Exist
| | +-modeSpecificInfo ::= CHOICE [fdd]
| | | +-fdd ::= SEQUENCE [001]
| | | +-defaultDPCH-OffsetValue ::= INTEGER OPTIONAL:Omit
| | | +-dpch-CompressedModeInfo ::= SEQUENCE OPTIONAL:Omit
| | | +-tx-DiversityMode ::= ENUMERATED [noDiversity] OPTIONAL:Exist
| | +-mac-hsResetIndicator ::= ENUMERATED OPTIONAL:Omit
| | +-postVerificationPeriod ::= ENUMERATED OPTIONAL:Omit
| +-dl-InformationPerRL-List ::= SEQUENCE OF SIZE(1..maxRL[8]) [1] OPTIONAL:Exist
| | +-DL-InformationPerRL-r7 ::= SEQUENCE [110]
| | +-modeSpecificInfo ::= CHOICE [fdd]
| | | +-fdd ::= SEQUENCE
| | | +-primaryCPICH-Info ::= SEQUENCE
| | | | +-primaryScramblingCode ::= INTEGER (0..511) [9]
| | | +-servingHSDSCH-RL-indicator ::= BOOLEAN [TRUE]
| | | +-servingEDCH-RL-indicator ::= BOOLEAN [TRUE]
| | +-dl-dpchInfo ::= CHOICE [dl-FDPCH-InfoPerRL] OPTIONAL:Exist
| | | +-dl-FDPCH-InfoPerRL ::= SEQUENCE [1000]
| | | +-pCPICH-UsageForChannelEst ::= ENUMERATED [mayBeUsed]
| | | +-fdpch-FrameOffset ::= INTEGER (0..149) [0]
i) LTE has only two RRC States (RRC_IDLE, RRC_CONNECTED) whereas UMTS has five RRC States (IDLE, CELL_DCH, CELL_FACH,
CELL_PCH, URA_PCH)
ii) LTE is using only three SRBs (SRB0, SRB1, SRB2) whereas UMTS uses four different SRBs (SRB0, SRB1, SRB2, SRB3)
iii) In LTE, SRB 0 is used RLC TM entity over CCCH logical channel in DL whereas in UMTS RLC UM entity over CCCH logical channel in
DL. It means that RRC Connection Setup message is carried by RLC TM in LTE whereas it is carried by RLC UM in UMTS.
iv) In LTE, there is only one MAC entity you have to define whereas there are so many different MAC entities(MAC-d (DCH), MAC-c/sh
(FACH, DSCH), MAC-hs (HS-DSCH) and MAC-e (E-DCH), MAC-Ehs etc in UMTS. This is realy blessing to you if you are protocol stack
developer in LTE. It will simplify the radio bearer setup process and RRC Connection Reconfiguration message (Corresponding to Radio
Bearer Setup in UMTS) drastically.
v) There is no common and transport channel definition in LTE. This removes such an complicated definition/implementation like TFCS,
TFCI in radio bearer setup process. I like this so much -:)
vi) In LTE everthing is carried by shared channel, meaning there is no dedicated channel. It means every UE is using the same physical
channel configuration trasmitted by SIB (mainly SIB2) and does not need any dedicated channel configuration information in RRC message.
This is one of the main reason why LTE RRC Connection Setup and RRC Connection Reconfiguration message is so simpler than UMTS
RRC Connection Setup and Radio Bearer Setup message.
vii) In LTE, only one reconfiguration message (RRC Connection Reconfiguration) do everything whereas in UMTS there are various different
kind of reconfiguration, Radio Bearer Reconfiguration, Transport Channel Reconfiguration, Physical Channel Reconfiguration.
viii) No 'Activation Time' in LTE. You would know how much headache you had because of this in UMTS. Activation Time in Radio Bearer
Setup, Radio Bearer Reconfiguation and in Handover. These are one of the biggest source of headache in UMTS troubleshooting.