Category 0 is a category that is added to LTE in Rel 12 with the maximum data rate of 1 Mbps. Why the lowest throughput category become so special in such a high throughput oriented technology like LTE ? It is because it has several important features as follows :
- Cat 0 is the category that meets the criteria of MTC (Refer to MTC for the details)
- Cat 0 is the category that supports PSM (Refer to PSM for the details)
- Therefore, Cat 0 is the category that is best fit for M2M or IoT.
The rest of this page is built around three captures taken from a live Cat 0 attach. Let me use them to show where the category appears in RRC, where it appears in NAS, and what the two power saving timers inside them actually do.
- What does Category 0 actually specify?
- RRC Aspect for Category 0
- NAS Aspect of Category 0
- How do the two timers turn into a sleep?
- Where to read the full signalling logs
What does Category 0 actually specify?
The 1 Mbps figure above is the one everybody quotes, but it is only one row of the capability table. Category 0 sets four downlink limits, and three of them matter more for the cost of the modem than the data rate does. So let me put the numbers beside an ordinary category, because the size of the gap is the point.
36.306 sets these limits through two fields rather than one. The first, ue-CategoryDL, fixes what the UE must be able to receive. The second, ue-CategoryUL, fixes what it must be able to send. Release 12 split them apart, and the next section shows both in a real capability message.
The downlink half of 36.306 Table 4.1A-1 is extracted below. Category 1bis and Category 4 are there for scale, not because a Cat 0 device has anything to do with either of them.
UE DL Category |
Max DL-SCH Bits per TTI |
Max Bits of One Transport Block |
Soft Channel Bits |
DL Layers |
DL Category 1bis |
10296 |
10296 |
250368 |
1 |
DL Category 4 |
150752 |
75376 |
1827072 |
2 |
1000 bits in a 1 ms TTI is 1 Mbps, which is where the opening figure on this page comes from. The uplink half, 36.306 Table 4.1A-2, gives UL Category 0 the same 1000 bits per TTI and no 64QAM.
The soft channel bits column is the one that decides silicon cost. Those bits are the HARQ soft buffer, and a Cat 0 UE needs 25344 of them against 1827072 for Category 4. That is a factor of about seventy, and it comes straight out of the memory on the die. The single spatial layer removes a second receive chain on top of that.
One exception is worth knowing before you read a log. Note 2 under 36.306 Table 4.1A-1 raises that limit in a single case. A transport block addressed to P-RNTI, SI-RNTI or RA-RNTI may carry up to 2216 bits, while the UE's own data stays capped at 1000. System information, paging and random access responses are therefore not squeezed to the data limit, and a 2216 bit block on a Cat 0 device is not a fault.
Category 0 also drops requirements that every other UE has to meet. 36.306 makes CRS interference handling optional for it. It does the same for the TDD synchronisation and common channel interference handling that builds on that. It also waives the increased number of carriers a UE must monitor in idle and connected mode. Each of those is a receiver feature that costs area and power, so the exemptions follow the same argument as the buffer size.
The data rate is the least interesting limit : 1000 bits per TTI is the number everyone quotes. The 25344 bit soft buffer and the single spatial layer are what make the modem cheap.Broadcast and paging are not capped at 1000 bits : Note 2 under 36.306 Table 4.1A-1 allows 2216 bits for a transport block addressed to P-RNTI, SI-RNTI or RA-RNTI.Release 12 split the category in two : ue-CategoryDL and ue-CategoryUL are set separately, and the capability message in the next section carries both.Some mandatory features become optional : CRS interference handling and the extended carrier monitoring requirement are waived for Category 0. That saves receiver complexity rather than throughput.
RRC Aspect for Category 0
As any other categories, UE need to inform to network that it supports Category 0 on UE Capability Information message. One thing you would notice is that Category 0 is specified in Rel 12 category and in Release 12 DL category and UL category is specified separately.
UE Capability Information
The message below runs to more than a hundred lines, and almost none of it concerns Category 0. Five lines do, and they sit far apart in the nesting. So skim it first for shape, then use the breakdown underneath, which names each of the five and says which one misleads.
Following is an example of UE capability Information from a Cat 0 device captured by Amarisoft LTE Network Simulator.
(I simplified the contents so that you can easily identify Cat 0 related IEs. For full UE capability message, click here)
Decoded RRC message,
message c1: ueCapabilityInformation: {
rrc-TransactionIdentifier 0,
criticalExtensions c1: ueCapabilityInformation-r8: {
ue-CapabilityRAT-ContainerList {
{
rat-Type eutra,
ueCapabilityRAT-Container {
accessStratumRelease rel12,
ue-Category 1,
pdcp-Parameters {
supportedROHC-Profiles {
....
}
},
phyLayerParameters {
ue-TxAntennaSelectionSupported FALSE,
ue-SpecificRefSigsSupported TRUE
},
rf-Parameters {
supportedBandListEUTRA {
{
bandEUTRA 7,
halfDuplex TRUE // halfDuplex is not mandatory for Category 0.
// but network can apply Halfduplex if UE support
// and network decided to do
}
}
},
measParameters {
bandListEUTRA {
{
interFreqBandList {
{
interFreqNeedForGaps FALSE
}
}
}
}
},
featureGroupIndicators '5a000002'H
interRAT-Parameters {
},
nonCriticalExtension {
phyLayerParameters-v920 {
enhancedDualLayerFDD-r9 supported,
enhancedDualLayerTDD-r9 supported
},
...
nonCriticalExtension {
lateNonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
...
}
}
}
},
nonCriticalExtension {
...
},
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
pdcp-Parameters-v1130 {
},
phyLayerParameters-v1130 {
..
},
rf-Parameters-v1130 {
},
measParameters-v1130 {
},
interRAT-ParametersCDMA2000-v1130 {
},
otherParameters-r11 {
},
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
rf-Parameters-v1250 {
supportedBandListEUTRA-v1250 {
{
...
}
}
},
ue-CategoryDL-r12 0, // this indcate UE support Cat 0 for DL
ue-CategoryUL-r12 0 // this indcate UE support Cat 0 for UL
}
}
}
}
}
}
}
}
}
}
}
}
},
nonCriticalExtension {
nonCriticalExtension {
ue-RadioPagingInfo-r12 {
ue-Category-v1250 0
}
}
}
}
}
Five lines in that capture carry the category, and the first two are the ones that make a first reading go wrong.
accessStratumRelease rel12 : the UE declares Release 12. Without this the network would not look for the Release 12 category fields at all.ue-Category 1 : the Release 8 field, reading 1 rather than 0. That is not an error, and the tile below shows why.ue-CategoryDL-r12 0 and ue-CategoryUL-r12 0 : the real answer, and the two fields 36.306 uses to set the limits in the table above.ue-Category-v1250 0, inside ue-RadioPagingInfo-r12 : the same fact again, in the block the MME stores and hands back to the eNB when it pages this UE. The eNB therefore knows the category before the UE has said anything in that cell.halfDuplex TRUE : a property of the band entry rather than of the category. The paragraph after the tile covers what the specification actually says about it.
The type itself explains why ue-Category reads 1. The Release 8 field and the Release 12 fields are defined in different places, and only one of them can hold a zero.
Following is based on
UE-EUTRA-Capability ::= SEQUENCE {
accessStratumRelease AccessStratumRelease,
ue-Category INTEGER (1..5),
pdcp-Parameters PDCP-Parameters,
phyLayerParameters PhyLayerParameters,
rf-Parameters RF-Parameters,
measParameters MeasParameters,
featureGroupIndicators BIT STRING (SIZE (32)) OPTIONAL,
interRAT-Parameters SEQUENCE {
utraFDD IRAT-ParametersUTRA-FDD OPTIONAL,
utraTDD128 IRAT-ParametersUTRA-TDD128 OPTIONAL,
utraTDD384 IRAT-ParametersUTRA-TDD384 OPTIONAL,
utraTDD768 IRAT-ParametersUTRA-TDD768 OPTIONAL,
geran IRAT-ParametersGERAN OPTIONAL,
cdma2000-HRPD IRAT-ParametersCDMA2000-HRPD OPTIONAL,
cdma2000-1xRTT IRAT-ParametersCDMA2000-1XRTT OPTIONAL
},
nonCriticalExtension UE-EUTRA-Capability-v920-IEs OPTIONAL
}
UE-EUTRA-Capability-v1250-IEs ::= SEQUENCE {
phyLayerParameters-v1250 PhyLayerParameters-v1250 OPTIONAL,
rf-Parameters-v1250 RF-Parameters-v1250 OPTIONAL,
rlc-Parameters-r12 RLC-Parameters-r12 OPTIONAL,
ue-BasedNetwPerfMeasParameters-v1250 UE-BasedNetwPerfMeasParameters-v1250 OPTIONAL,
ue-CategoryDL-r12 INTEGER (0..14) OPTIONAL,
ue-CategoryUL-r12 INTEGER (0..13) OPTIONAL,
wlan-IW-Parameters-r12 WLAN-IW-Parameters-r12 OPTIONAL,
measParameters-v1250 MeasParameters-v1250 OPTIONAL,
dc-Parameters-r12 DC-Parameters-r12 OPTIONAL,
mbms-Parameters-v1250 MBMS-Parameters-v1250 OPTIONAL,
mac-Parameters-r12 MAC-Parameters-r12 OPTIONAL,
fdd-Add-UE-EUTRA-Capabilities-v1250 UE-EUTRA-CapabilityAddXDD-Mode-v1250 OPTIONAL,
tdd-Add-UE-EUTRA-Capabilities-v1250 UE-EUTRA-CapabilityAddXDD-Mode-v1250 OPTIONAL,
sl-Parameters-r12 SL-Parameters-r12 OPTIONAL,
nonCriticalExtension UE-EUTRA-Capability-v1260-IEs OPTIONAL
}
The Release 8 field is INTEGER (1..5). Zero is not in that range, so a Category 0 UE cannot report its category there at all. 36.331 settles it in the description of ue-CategoryDL. For ASN.1 compatibility a UE indicating DL category 0 shall also indicate any of the categories 1 to 5 in ue-Category without a suffix, and that value is ignored by the eNB. The 1 in the capture is one of five values the UE was free to pick, and nothing reads it.
The Release 12 fields do the real work, and both sit inside UE-EUTRA-Capability-v1250-IEs as optional fields. Their types are INTEGER (0..14) for ue-CategoryDL-r12 and INTEGER (0..13) for ue-CategoryUL-r12. The paging copy is narrower still. In UE-RadioPagingInfo-r12 the field ue-Category-v1250 is INTEGER (0), a type whose only legal value is zero, so its presence alone means Category 0.
One line in the capture needs a correction rather than an explanation. The comment beside halfDuplex TRUE reads as though the network may choose whether to apply half duplex. 36.331 defines the field the other way round. If halfDuplex is set to true then only half duplex operation is supported for that band. Otherwise full duplex is supported. The value states what the UE can do, and the network has no choice left to make. The capture is left exactly as it was recorded, comment included, because editing a capture destroys the evidence.
Read the Release 12 fields, not the Release 8 one : ue-Category cannot go below 1, so it never says Category 0. ue-CategoryDL-r12 and ue-CategoryUL-r12 carry the answer.A Release 8 network sees an ordinary low category UE : that is the designed fallback. It over-estimates the device rather than failing to parse the message.The category reaches the eNB twice : once in the capability message, and once in ue-RadioPagingInfo-r12, which the MME returns at paging time.halfDuplex belongs to the band, not to the category : Category 0 does not require it, and 36.331 makes the field a statement of what the UE supports rather than a network option.
NAS Aspect of Category 0
Usually NAS layer does not play much role to defining the service for UE category, but in case of Category 0 (in Category M in Rel 13 as well) there is special mode of operation called PSM (Power Saving Mode) and this PSM operation is defined by two specific NAS timer as shown below.
Attach Request
This is the UE asking, not the network deciding. Two power saving timers appear near the end of it, and at this point both are only proposals. The Attach Accept settles what the device actually gets, so read the two together rather than either one alone.
Following is the Attach Request from the same Cat 0 device, captured by Amarisoft LTE Network Simulator.
(I simplified the contents so that you can easily identify the power saving IEs. For the full Attach Request, click here)
Decoded NAS message,
EMM: Attach request
Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x0 (Plain NAS message, not security protected)
Message type = 0x41 (Attach request)
EPS attach type = 1 (EPS attach)
NAS key set identifier:
TSC = 0
NAS key set identifier = 1
Old GUTI or IMSI:
...
UE network capability:
...
ESM message container:
Protocol discriminator = 0x2 (EPS Session Management)
EPS bearer identity = 0
Procedure transaction identity = 1
Message type = 0xd0 (PDN connectivity request)
Request type = 1
PDN type = 3 (IPv4v6)
Protocol configuration options:
...
Last visited registered TAI:
MCC = 001
MNC = 01
TAC = 0x0001
T3324 value:
value = 10
unit = 2 (decihours)
T3412 extended value:
value = 24
unit = 0 (10 minutes)
Attach Accept
This is the half that binds. The same two timers come back with the same values, and a third row appears that the Request had no reason to carry. That row is the plain T3412, switched off. Watch for it, because switching it off is what hands the job to the extended timer.
Following is the Attach Accept the network returned to it, captured by Amarisoft LTE Network Simulator.
(I simplified the contents so that you can easily identify the power saving IEs. For the full Attach Accept, click here)
Decoded NAS message,
EMM: Attach accept
Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered)
Auth code = 0xdbbf1ea2
Sequence number = 0x01
Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x0 (Plain NAS message, not security protected)
Message type = 0x42 (Attach accept)
EPS attach result = 1 (EPS only)
T3412 value:
value = 0
unit = 7 (deactivated)
TAI list:
Length = 6
Data = 00 00 f1 10 00 01
ESM message container:
Protocol discriminator = 0x2 (EPS Session Management)
EPS bearer identity = 5
Procedure transaction identity = 1
Message type = 0xc1 (Activate default EPS bearer context request)
EPS Qos:
Length = 1
Data = 09
Access point name = "www.test.org"
PDN address:
PDN type = 1 (IPv4)
IPv4 = 10.0.0.2
ESM cause = 0x32 (PDN type IPv4 only allowed)
Protocol configuration options:
...
GUTI:
...
T3412 extended value:
value = 24
unit = 0 (10 minutes)
T3324 value:
value = 10
unit = 2 (decihours)
Both captures carry the same two timers, and the values agree. So this device asked for power saving and the network granted exactly what it asked for. The table collects the five rows and does the arithmetic, because the encoding splits every timer into a value and a unit.
Message |
Timer |
Value |
Unit |
Works Out As |
Attach Request |
T3324 |
10 |
2 (decihours) |
1 hour |
Attach Request |
T3412 extended |
24 |
0 (10 minutes) |
4 hours |
Attach Accept |
0 |
|||
Attach Accept |
T3412 extended |
24 |
0 (10 minutes) |
4 hours |
Attach Accept |
T3324 |
10 |
2 (decihours) |
1 hour |
One row in the Accept is easy to miss. The plain T3412 is set to unit 7, which the decoder prints as deactivated. That is how the network says the ordinary periodic tracking area update timer does not apply and the extended one replaces it. Without that row the UE would be running two periodic timers at once.
NAS is where power saving is negotiated : the category itself is an RRC matter, but PSM is requested in the Attach Request and granted in the Attach Accept.Read the Accept, not the Request : the UE proposes both timers and the network may return different ones. Here they match, which is not guaranteed.Every timer is a value and a unit : 24 with unit 0 is four hours, and 10 with unit 2 is one hour. A decoder that prints only the value tells you almost nothing.Deactivated is a real setting : unit 7 on the plain T3412 switches it off, which is what makes room for the extended timer.
How do the two timers turn into a sleep?
Those two timers do not do the same job, and a reader meeting PSM for the first time usually assumes T3324 is the sleep. It is the opposite. T3324 is how long the UE stays awake, and T3412 extended is how long the whole cycle lasts. Getting that backwards makes every PSM log look wrong.
Both timers start at the same moment, when the UE releases its RRC connection and enters idle. T3324 runs first. While it runs the UE behaves like any other idle UE, monitoring paging on its normal DRX cycle, so the network can still reach it. When T3324 expires the UE enters Power Saving Mode and stops monitoring paging altogether. It is then unreachable until it wakes itself up.
What wakes it is T3412 extended. On expiry the UE performs a periodic tracking area update, becomes reachable again, and the cycle restarts. So the sleep is not T3412 extended. It is T3412 extended minus T3324, and Figure 1 draws that with the values the Attach Accept granted.
Figure 1. One PSM cycle, drawn with the values the Attach Accept granted. T3324 is the awake part and not the sleep, so lengthening it makes the device more reachable and not less. The sleep is whatever is left of T3412 extended once T3324 has run.
The green block is the reachable part : one hour out of four here, and paging works normally inside it.The blue block is the saving : three hours with no paging reception at all, which is where the battery life comes from.The bracket underneath is one full cycle : it starts at idle entry and ends at the periodic TAU, after which the same two blocks repeat.Lengthening T3324 shortens the sleep : T3412 extended fixes the cycle, so the two settings trade against each other rather than adding up.
With the captured values this device is unreachable for three hours in every four. Mobile terminated traffic has to wait for the next window, and that is the trade an application makes when it turns PSM on. A device that must be reachable sooner wants eDRX instead, or a shorter T3412 extended.
T3324 is the awake window, not the sleep : this is the one people reverse, and reversing it makes a 1 hour setting look like a 1 hour saving.The sleep is the difference between the two : T3412 extended minus T3324, which is three hours in this capture.PSM makes the device unreachable, not merely quiet : the UE is not monitoring paging, so mobile terminated data waits. Design the application around that, or use eDRX.
Where to read the full signalling logs
For your study purpose, I put the link for full signaling logs below with the permission from Amarisoft. It looks a little intimidating but this is how real life log looks like.
Three files are linked, one per node, and they record the same call from three places. The table says how big each one is and what is worth finding in it, because the interesting lines are a small fraction of the total.
Log |
Lines |
What Is In It |
5629 |
The UE side, from PSS detection onward. Mostly PHY, with 19 RRC lines and 11 NAS lines buried in it. |
|
6109 |
The eNB side, carrying the same air interface plus 15 S1AP lines. Its header declares the cell: earfcn=2850, pci=1, FDD, 25 resource blocks each way. |
|
Network NAS layer log (MME log) |
1185 |
The MME side. No air interface at all, so the 14 S1AP and 12 NAS lines are easy to find. |
One check ties these logs back to the capture at the top of the page. The eNB header declares earfcn=2850, and that channel number sits in Band 7, which is the band the UE reported in its capability message. The cell runs 25 resource blocks each way, so this is a 5 MHz carrier rather than a full 20 MHz one.
Start in the MME log : it carries no PHY at all, so the attach sequence is readable end to end in a little over a thousand lines.Then find the RRC lines in the UE log : there are 19 of them among 5629, and they mark the stages the rest of the log fills in.Use the eNB log for the S1AP side : it is the only one of the three that shows both the air interface and the S1 interface for the same moment.