3GPP TSG-RAN WG2 #111 electronic DRAFT R2-20xxxxx

17th – 28th August 2020

Online

Source: NTT DOCOMO, INC. (Email discussion rapporteur)

Title: Report of email discussion [AT111-e][009][NR15] LTE SIB
extension issue
Document for: Discussion and decision
Agenda Item: 5.4.2

1. Introduction
This paper is aimed at discussing the following topic.

[AT111-e][009][NR15] LTE SIB extension issue (NTT DOCOMO)

Scope: Treat R2-2008083, R2-2008367, R2-2008107 (proponents to drive)

Part 1: Start after on-line initial discussion, Confirm severity/consequences of the issue, Try to find acceptable
solutions, put solutions on the table, gather initial round of comments to understand which could be acceptable.

Deadline: Aug 20, 0900 UTC.

Part 2: TBD. Urgency might depend on Whether acceptable Workarounds are found or not

Deadline: EOM

All of the relevant contributions were treated on-line at first. As a conclusion of the initial discussion, the following
scopes were agreed to discuss by email:

=> Continue by email, solutions with and without TS impact may be discussed. It is also interesting to
understand better the magnitude of the problem.

=> We can attempt to have a solution at this meeting, need to put solutions on the table and understand the
impacts to, we can assess the maturity towards the end of the meeting.

The following discussions are conducted in accordance with the agreed scopes.

2. Discussion
2.1. Identifying the problematic scenarios
According to the contributions submitted to this meeting and the on-line comments in the initial discussion, the
following two cases are the scenarios where some legacy UEs are unable to ignore the uncomprehending field.

Case 1: Only SIB24 is scheduled in a SI message;

Example: SI message #1 (SIB2), SI message #2 (SIB3, SIB5), SI message #3 (SIB24).

Case 2: An SI message schedules the other legacy SIBs as well as SIB24.

Example: SI message #1 (SIB2), SI message #2 (SIB3, SIB5, SIB24).

For both cases, some legacy UEs ignore the entire SIB1 and considers to fail in acquiring SIB1. As a consequence, the
cell broadcasting SIB24 is considered as barred. The same problem could be envisaged when the eNB broadcasts the
other SIBs than SIB24 which were introduced after the extension marker in the SIB-Type IE as shown below.
SIB-Type ::= ENUMERATED {
sibType3, sibType4, sibType5, sibType6,
sibType7, sibType8, sibType9, sibType10,
sibType11, sibType12-v920, sibType13-v920,

1
 sibType14-v1130, sibType15-v1130,
sibType16-v1130, sibType17-v1250, sibType18-v1250,
..., sibType19-v1250, sibType20-v1310, sibType21-v1430,
sibType24-v1530, sibType25-v1530, sibType26-v1530,
sibType26a-v1610, sibType27-v1610, sibType28-v1610,
sibType29-v1610}

Thus, the follow scenario can be identified as problematic:

- When an eNB broadcasts SIB1 which includes scheduling information of SI messages including SIB19 and
onwards, some legacy UEs are unable to acquire SIB1 and consider the cell as barred.

- It happens no matter whether SIB19 and onwards are scheduled separately from the other legacy SIBs (SIB2
to SIB18) via the different SI message, or SIB19 and onwards are scheduled together with the legacy SIBs in
the same SI message.

First of all, the rapporteur would like to develop the common understanding of the problematic scenarios.

Companies are invited to provide their views if companies share the same understanding of the problematic scenario. If
not, please share how you observe the problematic scenario.

Company name Agree/Not agree Comments (especially if not agree)

NTT DOCOMO Agree Although it has not been verified in the field whether any other extended
SIBs than SIB19 have the same problem, it most likely exists, given the
root cause of the SIB24 case.
Nokia Agree It is also our understanding that any SIB after the ellipsis marker in the
ENUMERATED list will end up resulting in the same issue.

2.2. Assumption of legacy UE

As discussed on-line, the standard itself is correct and there is no problem from the standard perspective. It is not
compliant with the standard that the UE is unable to acquire SIB1 and consider the cell as barred, when SIB1 includes
uncomprehending fields. Given that the test case has been introduced by RAN5 to check the handling of
uncomprehending fields, the standard compliant UE works properly from now on.

Nonetheless, the magnitude of this problem hinges on whether all of the concerning UEs already released into the
market can be upgraded to fix the bug or not. Ideally, the problem could be ironed out, if it were possible. On the other
hand, the real business seems not go well as ideal, according to the opinions expressed by operators, on-line. In that
case, potential solutions or workarounds need to be analysed based on the assumption that not all of the concerning UEs
can be upgraded and so there remains the UEs in the network which cannot handle the uncomprehending field in SIB1
properly.

Assumption: Not all of the concerning UEs can be upgraded, and so there remains the UE in the network which
cannot handle the uncomprehending field in SIB1 properly.

Companies are invited to provide their views if the assumption is agreeable to investigate potential workarounds or
solutions.

2
 Company name Agree/Not agree Reason
NTT DOCOMO Agree For instance, due to expiry of warranty period, lack of software update
functionality, it is not likely in reality to rely on the software update.
Nokia Agree, but In general, the understanding is that there may be a population of legacy
devices that cannot be upgraded (e.g. device out of warranty or any other
reason), but that cannot be a good enough reason to mandate specification
changes. For example, if 1% devices on the field have an issue then it does
not seem logical to force remaining 99% of UEs to be upgraded as a result
of a specification change. For this to be even considered as a viable
approach, we need to assume that all the non-problematic UEs can be
upgraded to incorporate the new behaviour. As soon as more than 1% of
the non-faulty UEs cannot be upgraded, this makes no difference in terms
of population of problematic UEs to deal with. Which means we have just
moved the problem around and not solved anything. Then the impact of the
fix to existing network implementations and existing features are also non-
trivial.

It would be good to understand the magnitude of the problem first in terms

of what percentage of the UE population we are referring to.

2.3. Potential workarounds

With regards to potential workarounds (i.e. NW implementation solutions which do not require changing the standards),
the following options were proposed:

Option 1: Broadcast SIB1 with/without SIB24 scheduling information, alternatively (Solution 1 in [1]);

Option 2: Do not broadcast SIB24, but relying on release with redirection from LTE to NR [2];

Option 3: Broadcast SIB24 only on a subset of LTE frequencies [3];

Option 4: Broadcast SIB24 without SI24 scheduling information in SIB1 [3].

All of the options have the advantage that it does not require the standard change and can be supported by NW
implementation/configuration. On the other hand, there might exist limitation and drawback of each option.
Furthermore, for future proofing, it should be assessed whether each option can be applied for the other SIBs than
SIB24 which are defined after the extension marker (i.e. SIB19 and onwards). On these two points, the rapporteur
would like to collect company views.

3
Company name Option 1
Limitation/drawback Applicability to other SIBs
NTT DOCOMO If the concerning UE receives SIB1 w/o SIB24 Can be used for the other SIBs, but the same
scheduling information by chance, the problem drawback as for SIB24 can be foreseen.
can be ironed out, In contrast, the problem
exists if the concerning UE receives SIB1 with
SIB24 scheduling information. Likewise, NR
SA UE has the same problem that 50% of NR
SA UEs can obtain SIB24, whilst the rest of
50% cannot.
Nokia Solution 1 in [1] does not provide full details Currently Rel-15 also has SIB19 (sidelink),
but we consider at least the following SIB20 (SC-PTM), SIB21 (LTE V2X), SIB25
limitations: (UAC for LTE connected to 5GC) and SIB26
- Additional network functionality in SIB (more V2X), and if the problem is the same,
scheduling to multiplex and transmit Type those could never be broadcast. And for Rel-
1 and Type 2 SIB content for legacy and 16, we added SIB26a (extended 5G indicator),
upgraded UEs respectively SIB27 (inter-RAT NB-IoT), SIB28 (NR sidelink)
- Wastage in broadcasting capacity and SIB29 (NR V2X coexistence), all of which
- Network node interaction to keep track of would suffer from the same issue
percentage of legacy and upgraded UEs
and take the percentage into account to Solution does not scale well i.e. Solution may
schedule Type 1 and Type 2 SIB content be applied to other SIBs but the drawbacks
- Type 1 and Type 2 SIB multiplexing indicated add up further limiting the system
solution will need to co-exist for a very capacity for SIB broadcast
long period of time
- Needs additional checking for feature
interworking issues e.g. with existing
features like CMAS/ETWS.
Cost of implementing new solution in network
and UE

Company name Option 2

Limitation/drawback Applicability to other SIBs
NTT DOCOMO Once NR SA capable UEs camp on the LTE SIB19 (sidelink discovery):
network, the UE will never reselect an NR cell SIB20 (SC-PTM):
(except if the UE returns back from out of SIB21 (V2X sidelink):
coverage). For NR SA capable UEs in such a SIB25 (UAC):
case, the terminal display cannot show “5G” SIB26/26a/28 (V2X sidelink):
since the UE camps on an LTE cell (except if SIB28: cell selection for NB-IoT
the upper layer indication is used). SIB29: coexistence with NR
Furthermore, every time when the NR SA
capable UE transits to the connected start to For all cases, the corresponding (LTE)
originate or terminate a call, the LTE NW has functionality and service cannot be provided
to redirect the UE to an NR carrier. This is an on the cell.
extra burden for the LTE NW to offer NR SA
services. It is also noted that redirection from
LTE to NR involves the core network change
(EPC to 5GC), unless LTE is connected to
5GC.
Nokia Based on the discussion in [2] at least the Currently Rel-15 also has SIB19 (sidelink),
following drawbacks are understood: SIB20 (SC-PTM), SIB21 (LTE V2X), SIB25
- Unless all of the UEs who cannot handle (UAC for LTE connected to 5GC) and SIB26
the uncomprehending value properly are (more V2X), and if the problem is the same,
upgraded to fix the bug, LTE NW cannot those could never be broadcast. And for Rel-
broadcast SIB24 for NR SA and has to 16, we added SIB26a (extended 5G indicator),
redirect the UE to NR whenever the UE SIB27 (inter-RAT NB-IoT), SIB28 (NR sidelink)
originates terminates a call and SIB29 (NR V2X coexistence), all of which
- As long as the problematic UEs exist on would suffer from the same issue
the field the standard solution from
specifications is useless Solution works for SIB24 and does not impact
Cost of implementing solution in network UE at all which is a good aspect but is non-
(including testing) is a factor optimal

Solution for other SIBs need to be evaluated

for alternative solution on case by case basis

4
Company name Option 3
Limitation/drawback Applicability to other SIBs
NTT DOCOMO It works only if there exists the frequency The corresponding (LTE) functionality and
bands which the concerning UE does not service can be provided only on a subset of
support, but the other normal UE supports. LTE frequencies. So, the service availability is
Different operators may have different restricted to those subset frequencies.
spectrum holding, and so it is not always true if
such a frequency band exists. Even so, the
coverage of such a band is limited. For
instance, the legacy UE is likely to support
lower frequency bands (e.g. Band 1, 3), since
the nation-wide coverage is quite important
when a new service is launched. After that,
when new spectrum is available, the new may
supports both the legacy band and the new
frequency band. Nevertheless, the new band
seems to be higher frequency band, e.g. Band
42. In that case, the coverage where SIB24
can be broadcasted would be quite limited.
Nokia Based on the discussion in [3] at least the Currently Rel-15 also has SIB19 (sidelink),
following drawbacks are understood: SIB20 (SC-PTM), SIB21 (LTE V2X), SIB25
- Requires additional frequencies to isolate (UAC for LTE connected to 5GC) and SIB26
legacy and Rel-15 UEs i.e. reserve some (more V2X), and if the problem is the same,
low band LTE carrier (e.g. 700M, or those could never be broadcast. And for Rel-
900/1800M) without SIB24 broadcast, to 16, we added SIB26a (extended 5G indicator),
guarantee service availability of those SIB27 (inter-RAT NB-IoT), SIB28 (NR sidelink)
problematic old UEs which may not be and SIB29 (NR V2X coexistence), all of which
efficient spectrum usage would suffer from the same issue
- May require additional effort on radio
network planning Solution works for SIB24 and does not impact
- As long as the problematic UEs exist on UE at all which is a good aspect but is non-
the field the standard solution from optimal
specifications is useless
Cost of implementing solution in network Solution for other SIBs need to be evaluated
(including testing) is a factor for alternative solution on case by case basis

Company name Option 4

Limitation/drawback Applicability to other SIBs
NTT DOCOMO Given that the specification does not The same drawback as for SIB24 can be
guarantee the UE behaviour that UE is able to foreseen.
acquire SIBs even without scheduling
information, it is doubtful if all of the UEs
across different vendors can do so. We believe
that it is neither solution nor workaround.
Nokia Based on the discussion in [3] at least the Currently Rel-15 also has SIB19 (sidelink),
following drawbacks are understood: SIB20 (SC-PTM), SIB21 (LTE V2X), SIB25
- Not transmitting SIB24 in the scheduling (UAC for LTE connected to 5GC) and SIB26
list but only directly transmitting the SIB24 (more V2X), and if the problem is the same,
might not be 3GPP compliant and even those could never be broadcast. And for Rel-
probably not work well on some UEs as 16, we added SIB26a (extended 5G indicator),
they may still ignore the SIB24. SIB27 (inter-RAT NB-IoT), SIB28 (NR sidelink)
- As long as the problematic UEs exist on and SIB29 (NR V2X coexistence), all of which
the field the standard solution from would suffer from the same issue
specifications is useless
Cost of implementing solution in network Solution works for SIB24 but may not work for
(including testing) is a factor all UEs as this is might be non-compliant to
3GPP specifications

Solution for other SIBs need to be evaluated

for alternative solution on case by case basis

5
Finally, the rapporteur would like to collect company views on whether the above options are enough to address the
problematic issue for all concerning SIBs (i.e. SIB19 and onwards) as workarounds.

Company name Yes/No Comments (reason of your opinion)

NTT DOCOMO No All of the options have considerable drawback and limitation, not only for
SIB24, but also for the other concerning SIBs. It is a serious pitfall to launch
NR SA services, as well as deploying any other functionalities using SIB19
and onwards.
Nokia Yes, but there There was an option also from [2] on the lines of “SIB24 is scheduled via
was one more the additional SI scheduling information list, whilst the legacy SI scheduling
information list is untouched and kept as it is”. As mentioned in [2], one
drawback of this solution is that this can work only if all NR SA capable
UEs support the additional SI scheduling information list and this requires
to invalidate current specification and implement new solution in UE and
network.

2.4. Potential solutions

With regards to potential solutions (i.e. solutions which require changing the standard), the followings were proposed:

Solution 1: Introduce an additional scheduling information for SIB24 in SIB1 [23] or SIB3 (Solution 5 in [1]);

Solution 2: Broadcast two variants of SIB1 (with/without SIB24 scheduling information) in time domain or
frequency domain (Solution 2, 3 in [1]);

Solution 3: Deliver SIB24 via RRC connection reconfiguration or RRC connection release (Solution 4 in [1]).

All of the solutions can iron out the problematic scenario. On the other hand, the amount of standard changes is
different amongst the solutions. In addition, the other impacts (e.g. increased broadcast overhead) need to be analysed.
Applicability to the other SIBs (SIB19 and onwards) has to be investigates, as well. In the light of these viewpoints, the
rapporteur would like to seek company views on which solution is preferred, if the standard change is deemed as
necessary to iron out the problem. If companies prefer Solution 1 or Solution 2, please also share your preferred sub-
option.

6
 Company name Preferred solution Reason of your opinion)
NTT DOCOMO Solution 1 with the Solution 2 requires twofold radio resources to broadcast two variants of
additional SIB1. Increased broadcast overhead is larger than Solution 1. Solution 3
scheduling info in requires the UE to connect the LTE cell at first. One could imagine that
SIB1 the validity time is defined for SIB24. Every time when the validity timer is
expired, the NW has to deliver the SIB24 again. It is not clear how the
NW knows if the timer is expired or not for each UE. Furthermore, it is not
clear how to update SIB24, when the content is modified.
With regards to the solution variant of Solution 1, we prefer to introduce
the additional scheduling information in SIB1. The reason and benefit of
defining SI scheduling information into the other SIB is not clear to us.
Nokia Solution 3 but would All solutions have pros and cons and it is rather difficult to make a choice
prefer network as this means new network and/or UE implementation and invalidating
being able to correctly specified behavior. If we now introduce a solution that will cause
broadcast SIB24 in new UEs to rely only on the new signalling, then that signalling cannot be
the future. removed in the future because it would again create a legacy UE problem
(for the “new UEs” using that, which will become “legacy UEs” in the
future). In this case we are just moving the problem around and not really
solving anything.

We also agree to the following and quoting from [3], “3GPP has claimed
Rel-15 ASN.1 freeze for quite a long time. At this stage, NBC change on
Rel-15 specification is not acceptable to us. The Rel-15 UE with correct
implementation should NOT be mandated to use another solution due to
wrong implementation of some legacy UEs. This is really a bad practice if
3GPP decides to favor the wrongly implemented UEs and add additional
effort to the UEs with correct implementation”.

In the end, no matter which standardized solution is adopted, it will

penalize UEs that were correctly implemented. We have to figure out
means to handle this (in the network) but the only real way to solve this
problem will be to phase out the faulty UEs or upgrade them.

3. Summary and proposal

Editor’s note: To be added later.

4. References
[1] R2-2008367, “Discussion on SIB24 issue,” CMCC.

[2] R2-2008083, “Problem on SI scheduling via an extended field,” NTT DOCOMO, INC.

[3] R2-2008107,” Workaround for LTE SIB24 issue,” MediaTek

[4] R5-202138, “Discussion paper on the need for testing UE handling of extended and spare fields in SI,” NTT
DOCOMO, INC.

[5] R5-203060, “Addition of new RRC TC for checking extended / spare field handling in SI,” Rel-16 CR to 36.523-1,
NTT DOCOMO, INC.

[6] R5-203067, “Addition of new NB-IoT RRC TC for checking extended / spare field handling in SI”, Rel-16 CR to
36.523-1, NTT DOCOMO, INC.