US20220272539A1

US20220272539A1 - Methods, UE and Access Node for Handling System Information Signatures

Info

Publication number: US20220272539A1
Application number: US17/618,935
Authority: US
Inventors: Icaro Leonardo Da Silva; Prajwol Kumar Nakarmi; Oscar OHLSSON
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2019-06-17
Filing date: 2020-05-26
Publication date: 2022-08-25
Also published as: WO2020256617A1; EP3984283A1; US20220303775A1; EP3984284A1; WO2020256616A1

Abstract

The present disclosure relates to a method performed by a UE (102) for handling validity of a SI signature in a com-munication system. The UE (102) obtains, from an access node (103, 104), SI and an associated SI signature for a cell served by the access node (103, 104) and which the UE (102) can use. The UE (102) determines if the obtained SI signature is valid or invalid. The UE (102) determines that the cell is valid if the SI signature is determined to be valid. The UE (102) determines that the cell is invalid if the SI signature is determined to be invalid. The UE (102) provides information indicating the invalid cell to the access node (103, 104) or to another node if the SI signature is determined to be invalid.

Description

TECHNICAL FIELD

Embodiments herein relate generally to a User Equipment (UE), a method performed by the UE, an access node and a method performed by the access node. The embodiments herein relate to handling System Information (SI) signatures.
The embodiments herein relate to enabling UE reporting of system information signature verification failure.

BACKGROUND

Wireless Communication Systems in Third Generation Partnership Project (3GPP)

Consider an example of a communication system as illustrated in FIG. 1, with a UE 102, which communicates with one or multiple access nodes 103, 104, which in turn is connected to a network node 106. The access nodes 103, 104 are part of the access network 100. The access network 100 may be a radio access network. The communication system exemplified in FIG. 1 may be a wireless communication system, a wired communication system or a combined wired and wireless communication system. The network node 106 may also be referred to as a Core Network (CN) node.
For communication systems pursuant to 3GPP Evolved Packet System, EPS (also referred to as Long Term Evolution (LTE) or Fourth Generation (4G) standard specifications, such as specified in 3GPP TS 36.300 and related specifications, the access nodes 103, 104 corresponds typically to an Evolved NodeB (eNB) and the network node 106 corresponds typically to either a Mobility Management Entity (MME) and/or a Serving Gateway (SGW). The eNB is part of the access network 100, which in this case is the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), while the MME and SGW are both part of the Evolved Packet Core (EPC) network. The eNBs are inter-connected via the X2 interface, and connected to EPC via the S1 interface, more specifically via S1-C to the MME and S1-U to the SGW.
For communication systems pursuant to 3GPP Fifth Generation (5G) System (5GS) , also referred to as New Radio (NR) or 5G, standard specifications, such as specified in 3GPP TS 38.300 and related specifications, on the other hand, the access nodes 103, 104 corresponds typically to an 5G NodeB (gNB) and the network node 106 corresponds typically to either a Access and Mobility Management Function (AMF) and/or a User Plane Function (UPF). The gNB is part of the access network 100, which in this case is the Next Generation Radio Access Network (NG-RAN), while the AMF and UPF are both part of the 5G Core Network (5GC). The gNBs are inter-connected via the Xn interface, and connected to 5GC via the NG interface, more specifically via NG-C to the AMF and NG-U to the UPF.
To support fast mobility between NR and LTE and avoid change of core network, LTE eNBs can also be connected to the 5G-C via NG-U/NG-C and support the Xn interface. An eNB connected to 5GC is called a next generation eNB (ng-eNB) and is considered part of the NG-RAN. LTE connected to 5GC will not be discussed further in this document; however, it should be noted that most of the solutions/features described for LTE and NR in this document also apply to LTE connected to 5GC. In this document, when the term LTE is used without further specification it refers to LTE-EPC.

System Information in NR

System Information (SI) is information that is repeatedly broadcast by the network, e.g. the access node 103, 104 and which needs to be acquired by UEs 102 in order for them to be able to access and, in general, operate properly within the network and within a specific cell.
In NR, SI is delivered using two different mechanisms relying on two different transport channels:

- A limited amount of SI, corresponding to the so-called Master-Information Block (MIB), is transmitted using the Broadcast Channel (BCH).
- The main part of the SI, corresponding to different so-called System-Information Blocks (SIBs), is transmitted using the Downlink Shared Channel (DL-SCH).

The MIB comprises the most essential SI parameters needed to bootstrap the UE 102 and to obtain the rest of the SI. Unlike the SIBs, the MIB has a fixed size and the only way to add new information is use to one of the spare bits in MIB that have been reserved for future use.
The first SIB, SIB1, comprises the SI that the UE 102 needs to know before it can access the system. SIB1 is always periodically broadcast over the entire cell area. An important task of SIB1 is to provide the information the UE 102 needs to carry out initial random access. SIB1 also comprises scheduling information for the remaining SIBs. MIB and SIB1 together forms what is known as the Minimum SI.
The remaining SIBs, not including SIB1, is known as the Other SI and comprises the SI that the UE 102 does not need to know before accessing the system. These SIBs can also be periodically broadcast similar to SIB1. Alternatively, these SIBs can be transmitted on demand, that is, only transmitted when explicitly requested by the UE 102. This implies that the network can avoid periodic broadcast of these SIBs in cells which no UE 102 uses, e.g. is connected to, has selected, is currently camping on etc., thereby allowing for enhanced network energy performance. Currently, at least the following SIBs are defined:

- SIB2 comprises cell re-selection information, mainly related to the serving cell;
- SIB3 comprises information about the serving frequency and intra-frequency neighbouring cells relevant for cell re-selection, including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters;
- SIB4 comprises information about other NR frequencies and inter-frequency neighbouring cells relevant for cell re-selection. including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters;
- SIB5 comprises information about Evolved-Universal Terrestrial Radio Access (E-UTRA) frequencies and E-UTRA neighbouring cells relevant for cell re-selection selection, including cell re-selection parameters common for a frequency as well as cell specific re-selection parameters;
- SIB6 comprises an Earthquake & Tsunami Warning System (ETWS) primary notification;
- SIB7 comprises an ETWS secondary notification;
- SIB8 comprises a Commercial Mobile Alert System (CMAS) warning notification;
- SIB9 comprises information related to Global Positioning System (GPS) time and Coordinated Universal Time (UTC).

Three types of Radio Resource Control (RRC) message listed above are used to transfer SI: the MIB message, the SIB1 message and SI messages. An SI message, of which there may be several, comprises one or more SIBs which have the same scheduling requirements, i.e. the same transmission periodicity. The mapping of SIBs into SI messages as well as the scheduling information for those SI messages are defined in SIB1.

Signed SI in NR

Today in NR SI is transmitted without integrity protection which means that an attacker may attempt to manipulate the SI without the UE 102 being able to detect it. As a result, UE 102 may use that manipulated SI and be tricked to camp on a rogue cell leading to Denial of Service (DoS) e.g. if the UE 102 tries to access a cell generated by a fake access node. The UE 102 may also end up reporting false/incorrect information about neighbor cells to the genuine network which in turn could impact various Self Organizing Networks (SON) functions. For example, the UE 102 may send a measurement report with a Physical Cell Identifier (PCI) associated to a cell generated by a fake access node that is unknown to the source node. That source node may then request the UE 102 to report the Cell Global Identifier (CGI) so that it can establish a neighbour relation. However, that would not work as that is a cell generated by a fake access node. To mitigate this type of attacks one solution is to digitally sign the SI using public key cryptography.

Selective Deployment of Signed SI

One general problem with signed SI is that only a subset of the operators may choose to deploy such a solution, and the ones that do might only do so in a limited part of their network. It is also possible that only parts of the SI are signed. For example, to avoid having to re-generate the signature all the time, SIBs that are updated often, e.g. SIB9 which comprises time information, can be excluded from the signature generation. There are existing methods for how an operator can inform the UE 102 in a secure way whether a network uses signed SI or not and which parts of the SI that are covered by the signature.

Supporting Large Signatures Using Late Detection

Ideally the signature should be comprised already in Minimum SI, i.e. MIB or SIB1, since this is the first SI that the UE 102 acquires and it is also the only SI that is required to access the system.
Since the size of the signature is large it can be difficult to fit it into the Minimum SI. Using MIB is ruled out since MIB has fixed size and the free space that is available is very limited. Also the size of SIB1 is limited in practice as cell edge UEs 102 need to be able to decode it within the SI transmission window. The exact size limit depends on factors such as transmission power, cell size and frequency band, etc. but is typically around 1000 bits. Since SIB1 also comprises other information there may not be enough space left to fit the signature. SIB1 is also time critical and to reduce the acquisition time it should preferably be as small as possible.
One way to solve the size problem is to transmit the signature in a separate SIB. However, if the UE 102 is required to acquire the separate SIB and verify the signature before it can start using the information in the Minimum SI there is a risk of increased delays. For example, cell search could take a very long time if the UE 102 is required to verify the signature in every cell that it discovers. Another example is when the network re-directs the UE 102 to another cell and the UE 102 needs to quickly setup a connection. To solve this issue, a “late detection” approach involves that the UE 102 applies the Minimum SI as soon as it has been acquired and where the signature verification is done afterwards once the signature is acquired. The same approach can be used also for the other parts of SI that is covered by the signature.

Indicating Support of Signed SI

In order to configure the necessary parameters for signed SI e.g. public keys, the network must first know if the UE 102 supports signed SI, which may be referred to as performing a SI protection negotiation. An SI protection negotiation mechanism may involve that the UE 102 could signal its capabilities and where the network could configure the signature verification parameters. The SI protection negotiation can either be performed as part of an existing Non-Access Stratum (NAS) procedure, e.g. network registration, or it could be performed using a dedicated NAS procedure, see FIG. 2. The procedure shown in FIG. 2 comprises at least one of the following steps, which steps may be performed in any suitable order than described below:

Step

10

The UE 102 sends a NAS message to the Serving CN. The NAS message may comprise the SI capability.

Step

11

The Serving CN determines that, for an UE 102 that has proper SU capabilities, it shall send SI protection information to the UE 102.

Step

12

The Serving CN sends a NAS message to the UE 102. The NAS message comprises SI protection information. The NAS message may comprise at least one of: Tracking Area Identities (TAI), Physical Cell Identities (PCI), Cell IDs, SI numbers, public keys etc.
One aspect of signed SI that has not yet been addressed is the signature verification failure handling. In particular, it is important that the UE 102 can recover from a SI signature verification failure so that it does not get stuck on a fake/rogue access node.
One aspect of signed SI that has not yet been addressed is the lack of understanding at the network side, e.g. the access node 103, 104, when that happens. In particular, it is important that the network is aware of a potential failure in the security mechanism to enable the feature and/or the potential presence of a fake access node 103, 104 pretending to be an access node 103, 104 and transmitting SI. Du to this lack of information and understanding, there could be for example, UEs 102 in the network camping on cells associated to fake access node 103, 104, i.e. sort of a denial of service attack.
Therefore, there is a need to at least mitigate or solve this issue.

SUMMARY

An objective of embodiments herein is therefore to obviate at least one of the above disadvantages and to provide improved handling of SI signatures. The embodiments herein provide improved UE recovery at SI signature verification failure. The embodiments herein provide improved UE reporting of SI signature verification failure.
According to a first aspect, the object is achieved by a method performed by a UE for handling validity of a SI signature in a communication system. The UE obtains, from an access node, SI and an associated SI signature for a cell served by the access node and which the UE can use. The UE determines if the obtained SI signature is valid or invalid, and determines that the cell is valid if the SI signature is determined to be valid. The UE determines that the cell is invalid if the SI signature is determined to be invalid. The UE provides information indicating the invalid cell to the access node or to another node if the SI signature is determined to be invalid.
According to a second aspect, the object is achieved by a UE adapted to handle validity of a SI signature in a communication system. The UE is adapted to obtain, from an access node, SI and an associated SI signature for a cell served by the access node and which the UE can use. The UE is adapted to determine if the obtained SI signature is valid or invalid, and to determine that the cell is valid if the SI signature is determined to be valid. The UE is adapted to determine that the cell is invalid if the SI signature is determined to be invalid. The UE is adapted to provide information indicating the invalid cell to the access node or to another node if the SI signature is determined to be invalid.
According to a third aspect, the object is achieved by a method performed by an access node for handling validity of a SI signature in a communication system. The access node provides, to a UE, SI and an associated SI signature for a cell served by the access node and selectable by the UE. The access node obtains information indicating an invalid cell from the UE. The cell is invalid if the SI signature is invalid. The access node acts according to the obtained information.
According to a fourth aspect, the object is achieved by an access node adapted for handling validity of a SI signature in a communication system. The access node is adapted to provide, to a UE, SI and an associated SI signature for a cell served by the access node and selectable by the UE. The access node is adapted to obtain information indicating an invalid cell from the UE. the cell is invalid if the SI signature is invalid. The access node is adapted to act according to the obtained information.
Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows:
One advantage of the embodiments herein is that they allow the UE to recover from SI signature verification failure by temporarily barring the cell with invalid/signature and selecting another cell. By also allowing the network to disable barring and instead let the UE report the cells which failed SI signature verification, testing/troubleshooting can be simplified and prevents that UEs become unreachable when signed SI is deployed in a network. A cell may be considered barred if it is so indicated in the system information. A barred cell is a cell the UE is not allowed to use, e.g. connected to, to select, camp on etc.
One advantage of the embodiments herein is that they allows the network, e.g. the access node, to identify that UEs detected SI signature verification failure, which may either indicate a problem in the generation of signatures and/or the presence of fake base stations.
Thanks to the embodiments herein, the network, e.g. the access node, would become aware of a potential failure in the security mechanism to enable the feature of signed SI so that future failures could be avoided. In addition, network operator would also learn about the potential presence of a fake access node pretending to be a base station and transmitting SI. That could prevent UEs in the network to use, e.g. connected to, select, camp on etc., cells associated to fake access nodes, and thereby avoiding denial of service attacks.
The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein will now be further described in more detail by way of example only in the following detailed description by reference to the appended drawings illustrating the embodiments and in which:

FIG. 1 schematic block diagram illustrating an example of a communication network or system.

FIG. 2 is a signaling diagram illustrating an example of SI protection negotiation.

FIG. 3 is a flow chart illustrating an example of a method performed by the UE.

FIG. 4 is a flow chart illustrating an example of a method performed by the access node.

FIG. 5 is a signaling diagram illustrating an example of a UE information procedure.

FIG. 6 is a signaling diagram illustrating an example of measurement reporting

FIG. 7a-7b are schematic drawings illustrating an example of a UE.

FIG. 8a-8b are schematic drawings illustrating an example of an access node.

FIG. 9 is a schematic block diagram illustrating a telecommunication network connected via an intermediate network to a host computer.

FIG. 10 is a schematic block diagram of a host computer communicating via an access node with a UE over a partially wireless connection.

FIG. 11 is a flowchart depicting embodiments of a method in a communications system comprising a host computer, an access node and a UE.

FIG. 12 is a comprising depicting embodiments of a method in a communications system comprising a host computer, an access node and a UE.

FIG. 13 is a flowchart depicting embodiments of a method in a communications system comprising a host computer, an access node and a UE.

FIG. 14 is a flowchart depicting embodiments of a method in a communications system comprising a host computer, an access node and a UE.

The drawings are not necessarily to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein.

DETAILED DESCRIPTION

The communication system exemplified in FIG. 1 will now be described in more detail. FIG. 1 depicts a non-limiting example of a communications system, which may be a wireless communications system, sometimes also referred to as a wireless communications network, cellular radio system, or cellular network, in which embodiments herein may be implemented. The communications system may be a 5G system, 5G network, NR-U or Next Gen system or network. The communications system may alternatively be a younger system than a 5G system. The communications network may support other technologies such as, for example, LTE, LTE-Advanced/LTE-Advanced Pro, e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), LTE operating in an unlicensed band, NB-IoT. Thus, although terminology from 5G/NR and LTE may be used in this disclosure to exemplify embodiments herein, this should not be seen as limiting the scope of the embodiments herein to only the aforementioned systems.
The communications system comprises one or a plurality of access nodes, whereof a first access node 103 and a second access node 104 is depicted in the non-limiting example of FIG. 1. The term access node together with the reference numbers 103, 104 will be used herein when referring to any of the first access node 103 and the second access node 104. Note that only two access nodes 103, 104 are exemplified in FIG. 1 for the sake of simplicity, and that any n number of access nodes 103, 104 may be present in the communications system where n is a positive integer. The access node 103, 104 may be a radio network node, such as a radio base station, a radio access network node, an access network node or any other network node with similar features capable of serving a UE 102, such as a wireless device or a machine type communication device, in the communications system. The access node 103, 104 may be an eNB, gNB, Master eNB (MeNB), Radio Network Controller (RNC), NB, etc.
The communications system may cover a geographical area which may be divided into cell areas, wherein each cell area may be served by an access node 103, 104, although, one access node 103, 104 may serve one or several cells. Note that any n number of cells may be comprised in the communications system, where n is any positive integer. A cell is a geographical area where radio coverage is provided by the access node 103, 104 at an access node site. Each cell is identified by an identity within the local access node area, which is broadcast in the cell. In FIG. 1, the access node 103, 104 may serve a cell. The access node 103, 104 may be of different classes, such as, e.g., macro base station (BS), home BS or pico BS, based on transmission power and thereby also cell size. Thet access node 103, 104 may be a distributed node, such as a virtual node in the cloud, and it may perform its functions entirely on the cloud, or partially, in collaboration with another network node.
The access node 103, 104 may be directly or indirectly connected to one or more CNs, e.g. represented by a network node 106 in FIG. 1. Note that only one network node 106 is shown in FIG. 1 for the sake of simplicity, but any other suitable number of network nodes 106 may be located in the communications system. The network node 106 may be any suitable CN node such as e.g. a SGW, Packet Data Network Gateway (PGW), Gateway General Packet Radio Services (GPRS) Support Node (GGSN), Serving GPRS Support Node (SGSN), MME, AMF, UPF, Session Management Function (SMF), Home Location Register (HLR), Home Subscriber Server (HSS), Policy Control Function (PCF), Access Function (AF), Unified Data Management (UDM), Authentication Server Function (AUSF), Network Repository Function (NRF), Network Exposure Function (NEF), Network Slice Selection Function (NSSF), Charging Function (CHF) etc. The network node 106 may be referred to as a serving CN node, i.e. network node 106 which is currently serving the UE 102. The network node 106 may also referred to as a first CN node, or a home CN node.
One or a plurality of UEs 102 is located in the communication system. Only one UE 102 is exemplified in FIG. 1 for the sake of simplicity. A UE 102 may also be referred to simply as a device. The UE 102, e.g. a LTE UE or a 5G/NR UE, may be a wireless communication device which may also be known as e.g., a wireless device, a mobile terminal, wireless terminal and/or mobile station, a mobile telephone, cellular telephone, or laptop with wireless capability, just to mention some further examples. The UE 102 may be a device by which a subscriber may access services offered by an operator's network and services outside the operator's network to which the operator's access network and core network provide access, e.g. access to the Internet. The UE 102 may be any device, mobile or stationary, enabled to communicate over a radio channel in the communications system, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Internet of Things (IOT) device, terminal device, communication device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE 102 may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the access network, with another entity, such as another UE, a server, a laptop, a Personal Digital Assistant (PDA), or a tablet, Machine-to-Machine (M2M) device, device equipped with a wireless interface, such as a printer or a file storage device, modem, or any other radio network unit capable of communicating over a radio link in the communications system.
The UE 102 is enabled to communicate wirelessly within the communications system. The communication may be performed e.g. between two UEs, between a UE 102 and a regular telephone, between the UE 102 and an access node 103, 104, between network nodes 106, and/or between the UE 102 and a server via the access network and 100 possibly one or more core networks and possibly the internet.
The access node 103, 104 may be configured to communicate in the communications system with the UE 102 over a communication link, e.g., a radio link.
It should be noted that the communication links in the communications system may be of any suitable kind comprising either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the OSI model) as understood by the person skilled in the art.
To enable the network, e.g. the access node 103, 104, to detect a potential failure in the security framework for the SI signatures and/or to enable the access node 103, 104 to identify fake access node 103, 104, e.g. base stations, and consequently, avoiding UEs 102 to camp on fake access node 103, 104, e.g. base stations, or perform measurements on fake access node 103, 104, e.g. base stations, the embodiments herein comprises a method at a wireless terminal (also called user equipment—UE 102), the method comprising at least one of the following steps, which step may be performed in any suitable order than described below:

- Determining SI signature verification failure;
- Storing information associated to the occurrence of a SI signature verification failure, possibly including associated information enabling the network, e.g. the acces node 103, 104, to take counter-measures e.g. location information of where the failure occurred, measurements around the time where the failure has occurred, etc.
- Reporting information associated to the occurrence of a SI signature verification failure to the network, e.g. the access node 103, 104, possibly including associated information enabling the network to take counter-measures e.g. location information of where the failure occurred, measurements around the time where the failure has occurred, etc.

FIG. 3 is a flow chart illustrating an example of a method performed by the UE 102. The method performed by the UE 102 comprises at least one of the following steps, which steps may be performed in any suitable order than described below:

Step 201

As part of the SI protection negotiation, the UE 102 may be configured with SI protection parameters, including the public key for SI signature verification. That may include potentially other parameters associated to actions to be taken upon failure detection. To give an example, there could be an intra-frequency cell selection allowed indication, a barring timer, and an indication of whether cells with invalid SI signature should be barred or not. If the public key and the other parameters are pre-configured or hardcoded into the UE 102 by the standard this step 201 can be skipped.

Step

202

The UE 102 obtains, e.g. it acquires, the SI and the associated signature in a cell. This step may be performed when the UE 102 is in RRC_IDLE state, or RRC_INACTIVE state or any other power saving state and searches for a suitable cell to use, e.g. connect to, to select, to camp on etc., in the cell selection/re-selection procedure. It could also be performed by a UE 102 in RRC_CONNECTED state when cell selection is triggered as part of the RRC connection re-establishment procedure, after a handover to a new cell when the UE 102 reads the SI the target cell or upon the UE 102 being configured to report a Cell Global Identifier (CGI) of a cell that is not the Primary Cell (PCell) e.g. a neighbour cell, etc. In general, any action requiring the UE 102 to acquire SI could benefit from this step.

Step

203

The UE 102 determines if the SI signature is valid or invalid.

Step

214

This step is performed if step 203 in indicates that the SI signature is valid. If the SI signature is valid, indicated with yes in FIG. 3, the UE 102 considers cell as valid. In the case of being in a power saving state, the UE 102 simply uses the cell, e.g. connects to, selects, camps on etc., the cell. In the case of a connected state, the UE 102 performs actions as usual e.g. in the case the UE 102 is configured for CGI reporting, the UE 102 obtains cell access related information, e.g. CGI in SIB1, and reports to the network, e.g. the access node 103, 104.

Step

204

This step is performed if step 203 in indicates that the SI signature is invalid. If the UE 102 determines that the SI signature is invalid, indicated with no in FIG. 3, the UE 102 stores failure information associated and reports the cell to the network, e.g. the access node 103, 104. The cell could either be reported immediately or it can be logged and reported later, e.g. the next time the UE 102 connects to the network, e.g. the access node 103, 104. The network, e.g. the access node 103, 104, could also poll the UE 102 the report logged cells. That may also include information enabling the network, e.g. the access node 103, 104, to take counter-measures such as location information, measurements, etc.
Note that a SI signature may be considered invalid when the SI signature does not match the expected SI signature calculated using the public key. It also includes the case when the SI signature is missing or malformed. An invalid SI signature may be sometimes also referred to as an integrity protection failure.
In case the UE 102 is in RRC_CONNECTED mode and SI verification failure is detected after a handover to a new cell, the UE 102 may also trigger RRC re-establishment and/or NAS recovery in addition to barring the cell. Hence, the reporting of the logged information may occur when these procedures are being executed or after the UE 102 re-connects.
FIG. 4 is a flow chart illustrating a method performed by an access node 103, 104. The method comprises at least one of the following steps, which steps may be performed in any suitable order than described below:

Step

401

The access node 103, 104 may provide, to the UE 102, an indication of that it wants a failure report when the UE 102 has detected a failure.

Step

402

The access node 103, 104 obtains information associated to the occurrence of a SI signature verification failure from the UE 102, possibly including associated information enabling the access node 103, 104 to take counter-measures e.g. location information of where the failure occurred, measurements around the time where the failure has occurred, etc.

Step

403

The access node 103, 104 acts according to the obtained information.

Further Details

The embodiments herein relate to a method executed by a UE 102, the method comprising at least one of the following steps:

- Determining a SI signature verification failure;
- Storing information associated to the occurrence of a SI signature verification failure, possibly including associated information enabling the network, e.g. the access node 103, 104, to take counter-measures e.g. location information of where the failure occurred, measurements around the time where the failure has occurred, etc.
- Reporting information associated to the occurrence of a SI signature verification failure to the network, e.g. the access node 103, 104, possibly including associated information enabling network, e.g. the access node 103, 104, to take counter-measures e.g. location information of where the failure occurred, measurements around the time where the failure has occurred, etc.

Determining SI Signature Verification Failure

Determining SI signature verification failure may be done in different manners. The detection of the verification failure could either be done by the RRC layer or by lower layer, i.e. Physical (PHY) layer/Medium Access Control (MAC) layer/Radio Link Control (RLC) layer/Packet Data Convergence Control (PDCP) layer. In the latter case lower layers may provide an indication to the RRC layer that integrity protection of SI failed. In the case RRC layer is responsible for that verification, the SI signature would be something like a short MAC-I or resume MAC-I transmitted by the network, e.g. the access node 103, 104, in SI in the RRC message i.e. in the SI itself. In the embodiments herein, an Information Element (IE) named SysInfoMAC-I may be used to indicate a security token that may be included in SI.
The detection process may be done per SI block e.g. MIB or SIB-X.

SysInfoMAC-I

The IE SysInfoMAC-I is used to identify and verify the network upon SI acquisition.

SysInfoMAC-I Information Element:


	-- ASN1START
	-- TAG-SHORTMAC-I-START

SysInfoMAC-I ::=

BIT STRING (SIZE (X))

	-- TAG-SHORTMAC-I-STOP
	-- ASN1STOP

Storing Information Associated to the Occurrence of a SI Signature Verification Failure

Upon detecting a verification failure in SI, the UE 102 logs information, e.g. stores, obtains, receives etc., associated to that failure detection.

- This logging may be done every time that verification failure occurs. This could be implemented in the specification by a new UE variable, e.g., a SysInfolntegrityFailure-report. It may also be implemented as an existing report. e.g. like the Radio Link Failure (RLF)-report, that would be in the proposed method triggered by a new cause i.e. the SI integrity verification failure, or
- This logging may be done based on network configuration. That configuration is an indication that the network, e.g. the access node 103, 104, wants a failure report when the failure is detected. The configuration may be provided when the SI signature procedure is configured;

When it comes to the exact information to be stored, the information may be an indication of the occurrence of the failure event i.e. the detecting a verification failure in SI. There may be different solutions depending how the scheme is used in SI. If a single SI signature is used for any or all SI, i.e. MIB and SIBs, the UE 102 includes an indication. If multiple signatures are used e.g. for different SI parts, e.g. one for MIB and another for SIB(s), the UE 102 includes an indication of which SI signature verification has failed, in a more granular manner.
Other information to be stored may comprise the broadcasted SI that failed the verification such as MIB, SIB1, any other SIB, or information within MIB or any SIB e.g. cell identifiers, Public Land Mobile Network (PLMN) identifiers, CN identifiers like Tracking Area Identifiers, RAN identifiers, e.g. RAN-based Notification Area Code (RANAC) identifiers, etc. Typical parts of SI to comprise are the one in cell access related information, as shown below:

CellAccessRelatedInfo

The IE CellAccessRelatedInfo indicates cell access related information for this cell.

CellAccessRelatedInfo Information Element:


	-- ASN1START
	-- TAG-CELLACCESSRELATEDINFO-START

	CellAccessRelatedInfo ::=	SEQUENCE {
	plmn-IdentityList	PLMN-IdentityInfoList,
	cellReservedForOtherUse	Enumerated (true)
		OPTIONAL, -- Need R

	...
	}
	-- TAG-CELLACCESSRELATEDINFO-STOP
	-- ASN1STOP


CellAccessRelatedInfo field descriptions

cellReservedForOtherUse

Indicates whether the cell is reserved. The field is applicable to all

PLMNs.

plmn-IdentityList

The plmn-IdentityList is used to configure a set of PLMN-IdentityInfoList

elements. Each of those elements contains a list of one or more PLMN

Identities and additional information associated with those PLMNs. The

total number of PLMNs in the PLMN-IdentityInfoList does not exceed 12.

The PLMN index is defined as b1 + b2 + . . . + b(n − 1) + i for the

PLMN included at the n-th entry of PLMN-IdentityInfoList and the i-th

entry of its corresponding PLMN-IdentityInfo, where b(j) is the number

of PLMN-Identity entries in each PLMN-IdentityInfo, respectively.

PLMN-IdentityInfoList

The IE PLMN-IdentityInfoList includes a list of PLMN identity information.

PLMN-IdentityInfoList Information Element:


-- ASN1START
-- TAG-PLMN-IDENTITYINFOLIST-START

PLMN-IdentityInfoList ::=	SEQUENCE (SIZE (1..maxPLMN))
	OF PLMN-IdentityInfo
PLMN-IdentityInfo ::=	SEQUENCE {
plmn-IdentityList	SEQUENCE (SIZE (1..maxPLMN))

OF PLMN-Identity,

trackingAreaCode

TrackingAreaCode

OPTIONAL, -- Need R

ranac

RAN-AreaCode

OPTIONAL, -- Need R

cellIdentity	CellIdentity,
cellReservedForOperatorUse	Enumerated {reserved, notReserved),

...

)

-- TAG-PLMN-IDENTITYINFOLIST-STOP

-- ASN1STOP


PLMN-IdentityInfo field descriptions

cellReservedForOperatorUse

Indicates whether the cell is reserved for operator use (per PLMN).

trackingAreaCode

Indicates Tracking Area Code to which the cell indicated by cellIdentity

field belongs. The presence of the field indicates that the cell supports

at least standalone operation (per PLMN); the absence of the field

indicates that the cell only supports EN-DC functionality (per PLMN).

CellAccessRelatedInfo-EUTRA-5GC

The IE CellAccessRelatedInfo-EUTRA-5GC indicates cell access related information for an LTE cell connected to 5GC.

CellAccessRelatedInfo-EUTRA-5GC Information Element:


-- ASN1START
-- TAG-CELLACCESSRELATEDINFOEUTRA-5GC-START

CellAccessRelatedInfo-EUTRA-5GC ::=	SEQUENCE {
plmn-IdentityList-eutra-5gc	PLMN-IdentityList-EUTRA-5GC,
trackingAreaCode-eutra-5gc	TrackingAreaCode,
ranac-5gc	RAN-AreaCode

OPTIONAL,

cellIdentity-eutra-5gc

CellIdentity-EUTRA-5GC

}

PLMN-IdentityList-EUTRA-5GC ::=

SEQUENCE (SIZE (1..maxPLMN) ) OF PLMN-Identity-

EUTRA-5GC

PLMN-Identity-EUTRA-5GC ::=	CHOICE {
plmn-Identity-EUTRA-5GC	PLMN-Identity
plmn-index	Integer (1..maxPLMN)

}

CellIdentity-EUTRA-5GC ::=	CHOICE {
cellIdentity-EUTRA	BIT STRING (SIZE (28) ),
cellID-index	INTEGER (1..maxPLMN)

}

-- TAG-CELLACCESSRELATEDINFOEUTRA-5GC-STOP

-- ASN1STOP

CellAccessRelatedInfo-EUTRA-EPC

The IE CellAccessRelatedInfo-EUTRA-EPC indicates cell access related information for an LTE cell connected to EPC.

CellAccessRelatedInfo-EUTRA-EPC Information Element:


-- ASN1START
-- TAG-CELLACCESSRELATEDINFOEUTRA-EPC-START

CellAccessRelatedInfo-EUTRA-EPC ::=	SEQUENCE {
plmn-IdentityList-eutra-epc	PLMN-IdentityList-EUTRA-EPC,
trackingAreaCode-eutra-epc	BIT STRING (SIZE (16) ),
cellIdentity-eutra-epc	BIT STRING (SIZE (28) )

}

PLMN-IdentityList-EUTRA-EPC::=

SEQUENCE (SIZE (1..maxPLMN) ) OF PLMN-Identity

-- TAG-CELLACCESSRELATEDINFOEUTRA-EPC-STOP

-- ASN1STOP

It may also be logged security related information such as the exact signature, e.g. something like a short MAC-I, e.g., SysInfoMAC-I as shown below, the protocol PDUs/packets that have failed the SI signature, the algorithms being used at the time, the security keys being used by the UE 102, etc.
It is also logged information enabling the network, e.g. the access node 103, 104, to figure out the location of a possibly fake access node 103, 104, e.g. base station, and in which frequency it is operating such as frequency information, e.g. Absolute radio-frequency channel number (ARFCN) of the cell that failed the verification, measurements for other cells in the same frequency and/or other frequency, other location information (e.g. GPS), etc.
It is also logged information enabling the network, e.g. the access node 103, 104, to perform root cause analyses such as:

- Measurements. e.g. Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Signal to Interference plus Noise Ratio (SINR), on the cell where the failure has been detected, e.g. called measResultsLastServCell, on cell level and/or beam level, e.g. per Synchronisation Signal Block (SSB) and/or per Channel State Information Reference Signal (CSI-RS) resource; and/or
- Measurements, e.g. RSRP, RSRQ, SINR, on neighbour cells, e.g. called measResultNeighCells, on cell level and/or beam level, e.g. per SSB and/or per CSI-RS resource—That may possibly comprise neighbour Radio Access Technologies (RAT)/frequencies such as NR, EUTRA, etc., and/or
- Location information, e.g. locationInfo, and/or
- Information related to the cell where the failure is detected, e.g. failedCellId; and/or
- Information related to the cell where the UE 102 regains the connectivity e.g. cell the UE re-establishes or resumes after the failure, e.g. reestablishmentCellId; and/or
- Time information regarding when the failure has occurred e.g. time stamp or time elapsed since a certain procedure, possibly requiring the UE 102 to read SI, has occurred; and/or
- An indication that a specific type of failure associated to the SI signature verification failure has occurred, and/or
- Information related to the source cell of the last handover before the SI signature verification failure detection; and/or
- Other information, as shown below in the example signalling and field description.

The content of these logs may be included in a new report, e.g., defined by a UE 102 variable, called SysInfoSignatureFailure-Report. Alternatively, the content of these logs may be included in an existing report, like RLF report, with the difference that the information included has a meaning for the new use case of SI signature verification failure and that a new cause value for logging the report is included i.e. related to the new use case.
The content of these logs may have also information equivalent to what is also reported in an RLF report, as shown below:


SysinfoSignatureFailure-Report ::=	SEQUENCE {
measResultLastServCell	SEQUENCE {
rsrpResult	RSRP-Range,

rsrqResult	RSRQ-Range	OPTIONAL
sinrResult	SINR-Range	OPTIONAL

},

measResultNeighCells

SEQUENCE {

measResultListNR	MeasResultList2NR	OPTIONAL,
measResultListEUTRA	MeasResultList2EUTRA	OPTIONAL,
measResultListUTRA	MeasResultList2UTRA	OPTIONAL,
measResultListGERAN	MeasResultListGERAN	OPTIONAL,
measResultsCDMA2000	MeasResultList2CDMA2000	OPTIONAL

} OPTIONAL,

...,

locationInfo

LocationInfo

OPTIONAL,

failedPCellId	CHOICE {
cellGlobalId	CellGlobalIdNR,
pci-arfcn	SEQUENCE {
physCellId	PhysCellId,
carrierFreq	ARFCN-ValueNR

}

OPTIONAL,

reestablishmentCellID	CellGlobalIdNR	OPTIONAL,
timeConnFailure	INTEGER (0..1023)	OPTIONAL,

connectionFailureType	ENUMERATED {rlf, hof, sysInfoSignatureFailure,
	rlc-MaxNumRetx, t312-Expiry-r12}

OPTIONAL,

previousPCellId

CellGlobalIdNR

OPTIONAL

c-RNTI	C-RNTI,
timeSinceFailure	TimeSinceFailure
previousEUTRA-CellId	SEQUENCE {
carrierFreq	ARFCN-ValueEUTRA,
physCellId	PCI-EUTRA

cellGlobalId

CellGlobalIdEUTRA

OPTIONAL

}

OPTIONAL,

selectedEUTRA-CellId-r11	SEQUENCE {
carrierFreq	ARFCN-ValueEUTRA,
physCellId	PCI-EUTRA

}

OPTIONAL

tac-FailedPCell

TrackingAreaCode

logMeasResultListBTS	LogMeasResultListBT	OPTIONAL,
logMeasResultListWLAN	LogMeasResultListWLAN	OPTIONAL

}


absoluteTimeStamp
Indicates the absolute time when the logged measurement configuration
logging is provided, as indicated by E-UTRAN within absoluteTimeInfo.
anyCellSelectionDetected
This field is used to indicate the detection of any cell selection state. The
UE sets this field when performing the logging of measurement results in
RRC_IDLE and there is no suitable cell or no acceptable cell.
bler
Indicates the measured BLER value. The coding of BLER value is
defined in TS 36.133 [16].
blocksReceived
Indicates total number of MCH blocks, which were received by the UE
and used for the corresponding BLER calculation, within the
measurement period as defined in TS 36.133 [16].
carrierFreq
In case the UE includes carrierFreq-v9e0 and/or carrierFreq-v1090, the
UE shall set the corresponding entry of carrierFreq-r9 and/or
carrierFreq-r10 respectively to maxEARFCN. For E-UTRA and UTRA
frequencies, the UE sets the ARFCN according to the band used when
obtaining the concerned measurement results.
connectionFailureType
This field is used to indicate whether the connection failure is due to
radio link failure or handover failure.
contentionDetected
This field is used to indicate that contention was detected for at least one
of the transmitted preambles.
c-RNTI
This field indicates the C-RNTI used in the PCell upon detecting radio
link failure or the C-RNTI used in the source PCell upon handover
failure or upon system information signature verification failure.
dataBLER-MCH-ResultList
Includes a BLER result per MCH on subframes using dataMCS, with the
applicable MCH(s) listed in the same order as in pmch-InfoList within
MBSFNAreaConfiguration.
drb-EstablishedWithQCI-1
This field is used to indicate the radio link failure occurred while a
bearer with QCI value equal to 1 was configured.
failedCellId
This field is used to indicate the cell in which connection establishment
failed.
failedPCellId
This field is used to indicate the PCell in which RLF is detected or the
target PCell of the failed handover. The UE sets the EARFCN according
to the band used for transmission/reception when the failure occurred.
inDeviceCoexDetected
Indicates that measurement logging is suspended due to IDC problem
detection.
logMeasResultListBT
This field refers to the Bluetooth measurement results.
logMeasResultListWLAN
This field refers to the WLAN measurement results.
maxTxPowerReached
This field is used to indicate whether or not the maximum power level
was used for the last transmitted preamble.
mch-Index
Indicates the MCH by referring to the entry as listed in pmch-InfoList
within MBSFNAreaConfiguration.
measResultFailedCell
This field refers to the last measurement results taken in the cell, where
connection establishment failure happened. For UE supporting CE Mode
B, when CE mode B is not restricted by upper layers,
measResultFailedCell-v1360 is reported if the measured RSRP is
less than −140 dBm.
measResultLastServCell
This field refers to the last measurement results taken in the PCell, where
radio link failure or handover failure happened. For BL UEs or UEs in
CE, when operating in CE Mode B, measResultLastServCell-v1360 is
reported if the measured RSRP is less than −140 dBm.
measResultListEUTRA
If measResultListEUTRA-v9e0, measResultListEUTRA-v1090 or
measResultListEUTRA-v1130 is included, the UE shall include the
same number of entries, and listed in the same order, as in
measResultListEUTRA-r9, measResultListEUTRA-r10 and/or
measResultListEUTRA-r11 respectively.
measResultListEUTRA-v1250
If included in RLF-Report-r9 the UE shall include the same number of
entries, and listed in the same order, as in measResultListEUTRA-r9;
If included in LogMeasInfo-r10 the UE shall include the same number of
entries, and listed in the same order, as in measResultListEUTRA-r10;
If included in ConnEstFailReport-r11 the UE shall include the same
number of entries, and listed in the same order, as in
measResultListEUTRA-r11;
measResultListIdle
This field indicates the measurement results done during IDLE mode at
network request.
measResultServCell
This field refers to the log measurement results taken in the Serving cell.
For UE supporting CE Mode B, when CE mode B is not restricted by
upper layers, measResultServCell-v1360 is reported if the measured RSRP
is less than −140 dBm.
mobilityHistoryReport
This field is used to indicate the time of stay in 16 most recently visited
E-UTRA cells or of stay out of E-UTRA.
numberOfPreamblesSent
This field is used to indicate the number of RACH preambles that were
transmitted. Corresponds to parameter
PREAMBLE_TRANSMISSION_COUNTER.
previousPCellId
This field is used to indicate the source PCell of the last handover (source
PCell when the last RRCReconfiguration message including
reconfigurationWithSync was received, before the UE has failed the
system information signature verification).
previousEUTRA-CellId
This field is used to indicate the source EUTRA cell of the last successful
handover to NR, when RLF occurred at the target PCell or when
verification failure of system information signature is detected. The
UE sets the ARFCN according to the band used for transmission/reception
on the concerned cell.
reestablishmentCellId
This field is used to indicate the cell in which the re-establishment
attempt was made after connection failure.
relativeTimeStamp
Indicates the time of logging measurement results, measured relative to
the absoluteTimeStamp. Value in seconds.
rlf-Cause
This field is used to indicate the cause of the last radio link failure that
was detected. In case of handover failure information reporting (i.e., the
connectionFailureType is set to ‘hof’), the UE is allowed to set this field
to any value.
selectedEUTRA-CellId
This field is used to indicate the EUTRA cell that the UE selects after
RLF is detected, while T311 is running, or when verification failure of
system information signature is detected. The UE sets the ARFCN
according to the band selected for transmission/reception on the
concerned cell.
signallingBLER-Result
Includes a BLER result of MBSFN subframes using signallingMCS.
tac-FailedPCell
This field is used to indicate the Tracking Area Code of the PCell in
which RLF is detected or in which verification failure of system
information signature is detected.
tce-Id
Parameter Trace Collection Entity Id.
timeConnFailure
This field is used to indicate the time elapsed since the last HO
initialization until connection failure. Actual value = field value * 100 ms.
The maximum value 1023 means 102.3 s or longer.
timeSinceFailure
This field is used to indicate the time that elapsed since the connection
(establishment) failure or the verification failure of system information
signature. Value in seconds. The maximum value 172800 means 172800 s
or longer.
timeStamp
Includes time stamps for the waypoints that describe planned locations
for the UE.
traceRecordingSessionRef
Parameter Trace Recording Session Reference
wayPointLocation
Includes location coordinates for a UE for Aerial UE operation. The
waypoints describe planned locations for the UE.

Location Info

The IE Location Info may be used to transfer detailed location information available at the UE 102 to correlate measurements and UE position information.

LocationInfo Information Element:


--ASN1START
LocationInfo-r10 ::= SEQUENCE {

locationCoordinates-r10

CHOICE {

ellipsoid-Point-r10	OCTET STRING,
ellipsoidPointWithAltitude-r10	OCTET STRING,

...,

ellipsoidPointWithUncertaintyCircle-r11	OCTET STRING,
ellipsoidPointWithUncertaintyEllipse-r11	OCTET STRING,
ellipsoidPointWithAltitudeAndUncertaintyEllipsoid-r11	OCTET STRING,
ellipsoidArc-r11	OCTET STRING,
polygon-r11	OCTET STRING

},

horizontalVelocity-r10	OCTET STRING	OPTIONAL,
gnss-TOD-msec-r10	OCTET STRING	OPTIONAL,

...,

[[ verticalVelocityInfo-r15

CHOICE {

verticalVelocity-r15	OCTET STRING,
verticalVelocityAndUncertainty-r15	OCTET STRING

} OPTIONAL

]]

}

-- ASN1STOP


LocationInfo field descriptions

ellipsoidArc

Parameter EllipsoidArc. The first/leftmost bit of the first octet contains

the most significant bit.

ellipsoid-Point

Parameter Ellipsoid-Point. The first/leftmost bit of the first octet

contains the most significant bit.

ellipsoidPointWithAltitude

Parameter EllipsoidPointWithAltitud. The first/leftmost bit of the first

octet contains the most significant bit.

ellipsoidPointWithAltitudeAndUncertaintyEllipsoid

Parameter EllipsoidPointWithAltitudeAndUncertaintyEllipsoid. The first/

leftmost bit of the first octet contains the most significant bit.

ellipsoidPointWithUncertaintyCircle

Parameter Ellipsoid-PointWithUncertaintyCircl. The first/leftmost bit

of the first octet contains the most significant bit.

ellipsoidPointWithUncertaintyEllipse

Parameter EllipsoidPointWithUncertaintyEllipse. The first/leftmost bit

of the first octet contains the most significant bit.

gnss-TOD-msec

Parameter Gnss-TOD-msec The first/leftmost bit of the first octet

contains the most significant bit.

horizontalVelocity

Parameter HorizontalVelocity. The first/leftmost bit of the first

octet contains the most significant bit.

polygon

Parameter Polygon. The first/leftmost bit of the first octet contains

the most significant bit.

verticalVelocityAndUncertainty

Parameter verticalVelocityAndUncertainty corresponds to

horizontalWithVerticalVelocityAndUncertainty. The first/leftmost

bit of the first octet contains the most significant bit.

verticalvelocity

Parameter verticalvelocity corresponds to horizontalWithVerticalVelocity.

The first/leftmost bit of the first octet contains the most significant bit.

Below is an example where the UE 102 is in IDLE or INACTIVE state or any other power saving state that could be possibly defined, and determines the SI signature verification failure. Then, upon that, among other actions, it logs the relevant information as described herein.

Essential SI Missing or Indication from Lower Layers of an Integrity Protection Failure from Lower Layers (or SI Verification Signature Failure)

The UE 102 may:

- 1>if in RRC_IDLE or in RRC_INACTIVE or in RRC_CONNECTED while T311 is running:
  - 2>if the UE 102 is unable to acquire the MIB or;
  - 2>if lower layers indicate an integrity protection failure of SI:
    - 3>consider the cell as barred; and
    - 3>perform barring as if intraFreqReselection is set to allowed;
    - 3>log further information enabling the network to detect a fake base station e.g. SI that failed integrity protection verification;
  - 2>else if the UE 102 is unable to acquire the SIB1:
    - 3>consider the cell as barred.
    - 3>if intraFreqReselection in MIB is set to notAllowed:
      - 4>consider cell re-selection to other cells on the same frequency as the barred cell as not allowed.
    - 3>else:
      - 4>consider cell re-selection to other cells on the same frequency as the barred cell as allowed.

Reporting Information Associated to the Occurrence of a SI Signature Verification Failure to the Network

The method comprises the UE 102 reporting that logged information to the network, e.g. the access node 103, 104, upon a successful connection to a verified network. That may be request by the network, e.g. the access node 103, 104, e.g. in a UE Information
Request like message, when the UE 102 is in Connected state.
The different actions performed by the UE 102 regarding reporting may depend on which state the UE 102 is in. For example, in the case the UE 102 is in RRC_IDLE or RRC_INACTIVE state or any other power saving state when the failure is detected the UE 102 can store a failure report.
In the case this occurs while the UE 102 is in Inactive state and assuming the UE 102 remains in Inactive state, when the UE 102 succeeds in connecting to the network, e.g. via resume inactive to connected transition, the UE 102 may include an indication that there is this failure report available e.g. in an RRC Resume Complete like message.

RRCResumeComplete

The RRCResumeComplete message is used to confirm the successful completion of a RRC connection resumption.

- Signalling radio bearer: SRB1
- RLC-SAP: AM
- Logical channel: DCCH
- Direction: UE to Network

RRCResumeComplete Message:


-- ASN1START
-- TAG-RRCRESUMECOMPLETE-START

RRCResumeComplete ::=	SEQUENCE {
rrc-TransactionIdentifier	RRC-TransactionIdentifier,
criticalExtensions	CHOICE {
rrcResumeComplete	RRCResumeComplete-r15-IEs,
criticalExtensionsFailure	SEQUENCE { }

}

RRCResumeComplete-r15-IEs ::=

SEQUENCE {

dedicatedNAS-Message	DedicatedNAS-Message	OPTIONAL,
selectedPLMN-Identity	INTEGER (1..maxPLMN)	OPTIONAL,
uplinkTxDirectCurrentList	UplinkDirectCurrentList	OPTIONAL,
lateNonCriticalExtension	OCTET STRING	OPTIONAL,
nonCriticalExtension	SEQUENCE { }	OPTIONAL

}

RRCResumeComplete-rX-IEs ::=

SEQUENCE {

sysInfoSignatureFailure-ReportAvailable Enumerated (true)

OPTIONAL,

}

-- TAG-RRCRESUMECOMPLETE-STOP

-- ASN1STOP

The example of procedure may be as follows:

- set the content of RRCResumeComplete message as follows:
  - if the UE 102 has SI signature verification failure information available in VarSysInfoSignatureFailure-Report:
  - include the sysInfoSignatureFailure-ReportAvailable;

In the case this occurs while the UE 102 is in Idle state, when the UE 102 succeeds in connecting to the network, e.g. via setup/establishment procedure, the UE 102 may include an indication that there is this failure report available e.g. in an RRC Setup Complete like message.
In the case this occurs while the UE 102 is in Inactive state, but fallback to Idle occurs, i.e. the UE 102 receives an RRC Setup like message in response to an RRC Resume Request like message, when the UE 102 succeeds in connecting to the network, e.g. the access node 103, 104, e.g. via setup/establishment procedure, the UE 102 may include an indication that there is this failure report available e.g. in an RRC Setup Complete like message.

RRCSetupComplete

The RRCSetupComplete message is used to confirm the successful completion of an RRC connection establishment.

- Signalling radio bearer: SRB1
- RLC-SAP: AM
- Logical channel: DCCH
- Direction: UE 102 to Network, e.g. access node 103, 104.

RRCSetupComplete Message:


-- ASN1START
-- TAG-RRCSETUPCOMPLETE-START

RRCSetupComplete ::=	SEQUENCCE {
rrc-TransactionIdentifier	RRC-TransactionIdentifier,
criticalExtensions	CHOICE {

rrcSetupComplete	RRCSetupComplete-r15-IEs,
criticalExtensionsFailure	SEQUENCE {

}

RRCSetupComplete-r15-IEs ::=	SEQUENCE {
selectedPLMN-Identity	INTEGER (1..maxPLMN)
registeredAMF	RegisteredAMF

OPTIONAL,

guami-Type

ENUMERATED {native, mapped}

OPTIONAL,

s-NSSAI-List

SEQUENCE 9SIZE (1..maxNrofS-NSSAI) )

OF S-NSSAI

OPTIONAL,

dedicatedNAS-Message	DedicatedNAS-Message
ng-5G-S-TMSI-Value	CHOICE {

ng-5G-S-TMSI	NG-5G-S-TMSI,
ng-5G-S-TMSI-Part2	BIT STRING (SIZE (9) )

}

OPTIONAL,

lateNonCriticalExtension

OCTET STRING

OPTIONAL,

nonCriticalExtension

SEQUENCE{ }

OPTIONAL

}

RegisteredAMF ::=	SEQUENCE {
plmn-Identity	PLMN-Identity

OPTIONAL,

amf-Identifier

AMF-Identifier

}

RRCSetupComplete-rX-IEs ::=

SEQUENCE {

sysInfoSignatureFailure-reportAvailable

ENUMERATED (true)

OPTIONAL,

}

-- TAG-RRCSETUPCOMPLETE-STOP

-- ASN1STOP

An example of a method may be as follows:

- set the content of RRCSetupComplete message as follows:
  - if the UE 102 has SI signature verification failure information available in VarSysInfoSignatureFailure-Report:
  - include the sysInfoSignatureFailure-ReportAvailable;

For example, in the case the UE 102 is in RRC_CONNECTED state, the method comprises the UE 102 storing a failure report. An indication is included when the UE 102 sends a message trying to reconnect to the network e.g. via re-establishment. Then, network, e.g. the access node 103, 104, may request the UE 102 to report the failure report and, upon that, UE 102 includes the failure report in a message. When the UE 102 succeeds in connecting to the network, e.g. via re-establishment procedure, the UE 102 may include an indication that there is this failure report available e.g. in an RRC Reestablishment Complete like message.

RRCReestablishmentComplete

The RRCReestablishmentComplete message is used to confirm the successful completion of an RRC connection re-establishment.

- Signalling radio bearer: SRB1
- RLC-SAP: AM
- Logical channel: DCCH
- Direction: UE 102 to access node 103, 104.

RRCReestablishmentComplete Message:


-- ASN1START
-- TAG-RRCREESTABLISHMENTCOMPLETE-START

RRCReestablishmentComplete ::=	SEQUENCE {
rrc-TransactionIdentifier	RRC-TransactionIdentifier
criticalExtensions	CHOICE {
rrcReestablishmentComplete	RRCReestablishmentComplete-r15-IEs,
criticalExtensionsFuture	SEQUENCE { }

}

RRCReestablishmentComplete-r15-IEs ::=

SEQUENCE {

lateNonCriticalExtension	OCTET STRING	OPTIONAL,
nonCriticalExtension	SEQUENCE { }	OPTIONAL

}

RRCReestablishmentComplete-rX-IEs ::=

SEQUENCE {

sysInfoSignatureFailure-ReportAvailable ENUMERATED {true}

OPTIONAL,

}

-- TAG-RRCREESTABLISHMENTCOMPLETE-STOP

-- ASN1STOP

An example of a method may be as follows:

- set the content of RRCReestablishmentComplete message as follows:
  - if the UE 102 has SI signature verification failure information available in VarSysInfoSignatureFailure-Report:
  - include the sysInfoSignatureFailure-ReportAvailable;

Another possibly UE action for recovery when the UE 102 is in Connected and detects a system information failure signature, could be NAS recovery i.e. UE 102 goes to IDLE and performs an IDLE to CONNECTED transition. In that case, the indication of availability of report may be included in the RRCSetupComplete like message.
For any of these cases, the UE 102 may receive the request to report the failure in an UE Information Request, with an indication for this specific report, e.g. SI signature verification failure report. This UE information procedure is shown in FIG. 5 and will be described below.

UE Information

The UE information procedure is used by the network, e.g. the access node 103, 104, to request the UE 102 to report information.

Initiation

The network, e.g. the access node 103, 104, initiates the procedure by sending the UEInformationRequest message of the UE 102 in step 501 in FIG. 5. The network should initiate this procedure only after successful security activation.

Reception of the UEInformationRequest Message

Upon receiving the UEInformationRequest message, the UE 102 may, only after successful security activation:
. . .

- 1>if sysInfoSignatureFailure-ReportReq is set to true, set the contents of the sysInfoSignatureFailure-ReportReq in the UEInformationResponse message according to the defined field descriptions.

. . .

- 1>else:

2>submit the UEInformationResponse message to lower layers for transmission via SRB1;

UEInformationRequest

The UEInformationRequest is the command used by the access node 103, 104, e.g. ht e E-UTRAN, to retrieve information from the UE 102.

- Signalling radio bearer: SRB1
- RLC-SAP: AM

Logical channel: DCCH Direction: Access node 103, 104, e.g. E UTRAN, to UE 102
UEInformationRequest Message:


-- ASN1START

UEInformationRequest ::=	SEQUENCE {
rrc-TransactionIdentifier	RRC-TransactionIdentifier,
criticalExtensions	CHOICE {
criticalExtensionsFuture	SEQUENCE { }

}

UEInformationRequest-IEs ::=	SEQUENCE {
sysInfoSignatureFailure-ReportReq	BOOLEAN,

}

UEInformationResponse

The UEInformationResponse message may be used by the UE 102 to transfer the information requested by the E-UTRAN, e.g. the access node 103, 104 in a UE information response message in step 503 in FIG. 5.

- Signalling radio bearer: SRB1 or SRB2, when logged measurement information is included
- RLC-SAP: AM
- Logical channel: DCCH

Direction: UE 102 to access node 103, 104, e.g. E-UTRAN

UEInformationResponse Message:


-- ASN1START

UEInformationResponse ::=	SEQUENCE {
rrc-TransactionIdentifier	RRC-TransactionIdentifier,
criticalExtensions	CHOICE {
criticalExtensionsFuture	SEQUENCE { }

}

UEInformationResponse-IEs ::=	SEQUENCE {
sysInfoSignatureFailure-Report	SysInfoSignatureFailure-Repor OPTIONAL,

}

CGI Reporting and Reporting of System Information Verification Failure

Another use case where a SI verification failure may occur in Connected state, and where the method comprises the reporting of failure information, is in the CGI report procedure. The UE 102 may be configured to report the CGI associated to a PCI provided by the network, e.g. the access node 103, 104, in the configuration. Upon that the UE 102 needs to acquire SI associated to that PCI. However, according to the embodiments herein, an action is that before acquiring SI where the CGI related information is transmitted, the UE 102 verifies the SI signature, at least for the SI to be acquired e.g. SIB1. Part of the solution also comprises the UE 120 having longer time to obtain SI, in case of a SI signature is expected to be transmitted and verified.
Then, the UE 102 may perform the following actions depending on some conditions:

- If the UE 102 succeeds the verification of the SI signature, the UE 102 obtains the CGI related information and includes in the CGI report to be provided to the source cell, e.g. PCell or Primary Secondary Cell (PSCell);
- Else, there could be different alternative solutions:
  - In a first solution, if the UE 102 fails the verification of the SI signature, e.g. SysInfoMAC-I broadcasted does not match the one the UE 102 has computed, the UE 102 obtains the CGI related information anyway, includes that in the CGI report to be provided to the source cell, e.g. PCell or PSCell, e.g. the access node 103, 104 serving the source cell, and in addition includes the SI signature that has failed, as shown below. The UE 102 may also include further information that may assist the network, e.g. the access node 103, 104, to counter-measure the failure or avoid the cells where the failure has occurred. An example of what could be reported even in the case the UE 102 has failed the signature verification is shown below.

CGI-InfoNR

The IE CGI-InfoNR indicates cell access related information, which is reported by the UE 102 as part of report CGI procedure to the access node 103, 104.

CGI-InfoNR Information Element:


	-- ASN1START
	-- TAG-CGI-INFO-NR-START

CGI-InfoNR ::=

SEQUENCE {

	plmn-IdentityInfoList	PLMN-IdentityInfoList	OPTIONAL,
	frequencyBandList	MultiFrequencyBandListNR	OPTIONAL,

	noSIB1	SEQUENCE {
	ssb-SubcarrierOffset	INTEGER (0..15),
	pdcch-ConfigSIB1	PDCCH-ConfigSIB1

}

OPTIONAL,

sysInfoSignatureFailure

SysInfoMAC-I

OPTIONAL,

	...
	}
	-- TAG-CGI-INFO-NR-STOP
	-- ASN1STOP


CGI-InfoNR field descriptions

noSIB1

Contains ssb-SubcarrierOffset and pdcch-ConfigSIB1 fields acquired by

the UE 102 from MIB of the cell for which report CGI procedure was

requested by the network in case SIB1 was not broadcast by the cell.

One example of a method is shown below:

Measurement Identity Addition/Modification

The network, e.g. the access node 103, 104 may perform the following procedure:

- Configure a measId only if the corresponding measurement object, the corresponding reporting configuration and the corresponding quantity configuration, are configured.

The UE 102 may:

1>for each measId included in the received measIdToAddModList:
- 2>if an entry with the matching measId exists in the measIdList within the VarMeasConfig:
  - 3>replace the entry with the value received for this measId;
- 2>else:
  - 3>add a new entry for this measId within the VarMeasConfig;
- 2>remove the measurement reporting entry for this measId from the VarMeasReportList, if included;
- 2>stop the periodical reporting timer or timer T321, whichever one is running, and reset the associated information, e.g. timeToTrigger, for this measId;
- 2>if the reportType is set to reportCGI in the reportConfig associated with this measId:
  - 3>if the measObject associated with this measId concerns E-UTRA:
    - 4>start timer T321 with the timer value set to 1 second for this measId;
  - 3>if the measObject associated with this measId concerns NR:
    - 4>if the measObject associated with this measId concerns FR1:
      - 5>start timer T321 with the timer value set to 2 seconds for this measId;
    - 4>if the measObject associated with this measId concerns FR2:
      - 5>start timer T321 with the timer value set to 16 seconds for this measId.
    - 4>if the configured PCI associated with this measId has is expected to have a system information signature:
      - 5>increment X seconds the previous timer T321 value for this measId.

Performing Measurements

General

The UE 102 may:

1>for each measId included in the measIdList within VarMeasConfig:
- 2>if the reportType for the associated reportConfig is set to reportCGI:
  - 3>perform the corresponding measurements on the frequency and RAT indicated in the associated measObject using available idle periods;
  - 3>if the cell indicated by reportCGI field for the associated measObject is an NR cell and that indicated cell is broadcasting SIB1:
    - 4>perform system information signature verification, e.g. check if the transmitted security token matches the security token calculated by the UE 102;
    - 4>try to acquire SIB1 in the concerned cell;
  - 3>if the cell indicated by reportCGI field is an E-UTRA cell:
    - 4>perform SI signature verification, e.g. check if the transmitted security token matches the security token calculated by the UE 102;
    - 4>try to acquire SystemInformationBlockType1 in the concerned cell;

Measurement Report Triggering

General

2>if reportType is set to reportCGI:
- 3>if the UE 102 acquired the SIB1 or SystemInformationBlockType1 for the requested cell; or
- 3>if SI signature verification has failed; or
- 3>if the UE 102 detects that the requested NR cell is not transmitting SIB1:
  - 4>stop timer T321;
  - 4>include a measurement reporting entry within the VarMeasReportList for this measId;
  - 4>initiate the measurement reporting procedure;
2>upon the expiry of T321 for this measId:
- 3>include a measurement reporting entry within the VarMeasReportList for this measId;
- 3>set the numberOfReportsSent defined within the VarMeasReportList for this measId to 0;
- 3>initiate the measurement reporting procedure.

Measurement Reporting

General

An example of measurement reporting is illustrated in FIG. 6. FIG. 6 shows that the UE 102 sends a measurement report to the access node 103, 104 in step 601.

2>else:
- 3>if the cell indicated by cellForWhichToReportCGI is an NR cell:
  - 4>if plmn-IdentityInfoList of the cgi-Info for the concerned cell has been obtained:
    - 5>include the plmn-IdentityInfoList including plmn-IdentityList, trackingAreaCode, if available, ranac. if available and cellIdentity for each entry of the plmn-IdentityInfoList;
    - 5>include frequencyBandList if available;
  - 4>else if MIB indicates the SIB1 is not broadcast:
    - 5>include the noSIB1 including the ssb-SubcarrierOffset and pdcch-ConfigSIB1 obtained from MIB of the concerned cell;
  - 4>if SI signature verification has failed:
    - 5>include the sysInfoSignatureFailure for the concerned cell;
    - 5>include other information of the concerned cell such as information in SysInfoSignatureFailure-Report;
- 3>if the cell indicated by cellForWhichToReportCGI is an E-UTRA cell:
  - 4>if all mandatory fields of the cgi-Info-EPC for the concerned cell have been obtained:
    - 5>include in the cgi-Info-EPC the fields broadcasted in E-UTRA SystemInformationBlockType1 associated to EPC;
  - 4>if the UE is E-UTRA/5GC capable and all mandatory fields of the cgi-Info-5GC for the concerned cell have been obtained:
    - 5>include in the cgi-Info-5GC the fields broadcasted in E-UTRA SystemInformationBlockType1 associated to 5GC;
  - 4>if the mandatory present fields of the cgi-Info for the cell indicated by the cellForWhichToReportCGI in the associated measObject have been obtained:
    - 5>include the freqBandIndicator,
    - 5>if the cell broadcasts the multiBandInfoList, include the multiBandInfoList;
    - 5>if the cell broadcasts the freqBandIndicatorPriority, include the freqBandIndicatorPriority;
  - 4>if SI signature verification has failed:
    - 5>include the sysInfoSignatureFailure for the concerned cell;
    - 5>include other information of the concerned cell such as information in SysInfoSignatureFailure-Report;

In a second solution, if the UE 102 fails the verification of the SI signature, e.g. SysInfoMAC-I broadcasted does not match the one the UE 102 has computed, the UE 102 does not obtain the CGI related information, and includes information indicating the Si signature failure, e.g., the failed SI signature itself or a flag. An advantage here may be to avoid the UE 102 to spend time and efforts obtaining SI that will not be valid.

Performing Measurements

General

The UE 102 may:

1>for each measId included in the measIdList within VarMeasConfig:
- 2>if the reportType for the associated reportConfig is set to reportCGI:
  - 3>perform system information signature verification, e.g. check if the transmitted security token matches the security token calculated by the UE 102;
    - 4>if the SI signature verification for the cellForWhichToReportCGI succeeds:
      - 5>perform the corresponding measurements on the frequency and RAT indicated in the associated measObject using available idle periods;
      - 5>if the cell indicated by reportCGI field for the associated measObject is an NR cell and that indicated cell is broadcasting SIB1:
      - 6>try to acquire SIB1 in the concerned cell;
      - 5>if the cell indicated by reportCGI field is an E-UTRA cell:
      - 6>try to acquire SystemInformationBlockType1 in the concerned cell;

Measurement Report Triggering

General

2>if reportType is set to reportCGI:
- 3>if the UE 102 acquired the SIB1 or SystemInformationBlockType1 for the requested cell; or
- 3>if SI signature verification has failed; or
- 3>if the UE 102 detects that the requested NR cell is not transmitting SIB1:
  - 4>stop timer T321;
  - 4>include a measurement reporting entry within the VarMeasReportList for this measId;
  - 4>initiate the measurement reporting procedure.
2>upon the expiry of T321 for this measId:
- 3>include a measurement reporting entry within the VarMeasReportList for this measId;
- 3>set the numberOfReportsSent defined within the VarMeasReportList for this measId to 0;
- 3>initiate the measurement reporting procedure.

Measurement Reporting

General

An example of measurement reporting is illustrated in FIG. 6.

2>else:
- 3>if the cell indicated by cellForWhichToReportCGI is an NR cell:
  - 4>if system information signature verification has suceeded:
    - 5>if plmn-IdentityInfoList of the cgi-Info for the concerned cell has been obtained:
      - 6>include the plmn-IdentityInfoList including plmn-IdentityList, trackingAreaCode, if available, ranac ,if available, and cellIdentity for each entry of the plmn-IdentityInfoList;
      - 6>include frequencyBandList if available;
    - 5>else if MIB indicates the SIB1 is not broadcast:
      - 6>include the noSIB1 including the ssb-SubcarrierOffset and pdcch-ConfigSIB1 obtained from MIB of the concerned cell;
  - 4>else if SI signature verification has failed:
    - 5>include the sysInfoSignatureFailure for the concerned cell;
    - 5>include other information of the concerned cell such as information in SysInfoSignatureFailure-Report;

In a third solution, if the UE 102 fails the verification of the SI signature, e.g.
SysInfoMAC-I broadcasted does not match the one the UE 102 has computed, the UE 102 does not obtain the CGI related information, and considers the cell as not applicable for CGI reporting;

2>else if the corresponding reportConfig includes a reportType set to reportCGI:
- 3>consider the cell detected on the associated measObject which has a physical cell identity matching the value of the cellForWhichToReportCGI included in the corresponding reportConfig within the VarMeasConfig to be applicable, except if the SI signature verification has failed;.

On the network side, e.g. the access node 103, 104, for example, one action upon detection of a SI signature verification failure, e.g., based on the proposed reports from the UE 102, could be to black list certain cells for measurement reporting.
Another action upon detection of a SI signature verification failure, e.g., based on the proposed reports from the UE 102, could be to investigate if there is any problem in the SI signature generation function.
Note that although the methods herein may, in some places, be described in the context of NR, the same methods may be applied to any access technologies that make use of SI like LTE or Narrowband-Internet of Things (NB-IoT).
FIG. 7a and FIG. 7b depict two different examples in panels a) and b), respectively, of the arrangement that the UE 102 may comprise. In some embodiments, the UE 102 may comprise the following arrangement depicted in FIG. 7 a.
The embodiments herein in the UE 102 may be implemented through one or more processors, such as a processor 3001 in the UE 102 depicted in FIG. 7a , together with computer program code for performing the functions and actions of the embodiments herein. A processor, as used herein, may be understood to be a hardware component. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the UE 102. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the UE 102.
The UE 102 may further comprise a memory 3003 comprising one or more memory units. The memory 3003 is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the UE 102.
In some embodiments, the UE 102 may receive information from, e.g., the access node 103, 104, through a receiving port 3004. In some embodiments, the receiving port 3004 may be, for example, connected to one or more antennas in UE 102. In other embodiments, the UE 102 may receive information from another structure in the communications system through the receiving port 3004. Since the receiving port 3004 may be in communication with the processor 3001, the receiving port 3004 may then send the received information to the processor 3001. The receiving port 3004 may also be configured to receive other information.
The processor 3001 in the UE 102 may be further configured to transmit or send information to e.g. access node 103, 104 or another structure in the communications network, through a sending port 3005, which may be in communication with the processor 3001, and the memory 3003.
The UE 102 may comprise an obtaining unit 3015, a determining unit 3017, a triggering unit 3020, a selecting unit 3023, a providing unit 3025 other units 3040.
Those skilled in the art will also appreciate that obtaining unit 3015, a determining unit 3017, a triggering unit 3020, a selecting unit 3023, a providing unit 3025 other units 3040 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor 3001, perform as described above. One or more of these processors, as well as the other digital hardware, may be comprised in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).
Also, in some embodiments, the different units 3015-3040 described above may be implemented as one or more applications running on one or more processors such as the processor 3001.
Thus, the methods according to the embodiments described herein for the UE 102 may be respectively implemented by means of a computer program 3010 product, comprising instructions, i.e. software code portions, which, when executed on at least one processor 3001, cause the at least one processor 3001 to carry out the actions described herein, as performed by the UE 102. The computer program 3010 product may be stored on a computer-readable storage medium 3008. The computer-readable storage medium 3008, having stored thereon the computer program 3010, may comprise instructions which, when executed on at least one processor 3001, cause the at least one processor 3001 to carry out the actions described herein, as performed by the UE 102. In some embodiments, the computer-readable storage medium 3008 may be a non-transitory computer-readable storage medium, such as a CD ROM disc, or a memory stick. In other embodiments, the computer program 3010 product may be stored on a carrier comprising the computer program 3010 just described, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium 508, as described above.
The UE 102 may comprise a communication interface configured to facilitate communications between the UE 102 and other nodes or devices, e.g., the access node 103, 104 or another structure. The interface may, for example, comprise a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.
In other embodiments, the UE 102 may comprise the following arrangement depicted in FIG. 30b . The UE 102 may comprise a processing circuitry 3011, e.g., one or more processors such as the processor 3001, in the UE 102 and the memory 3003. The UE 102 may also comprise a radio circuitry 3013, which may comprise e.g., the receiving port 3004 and the sending port 3005. The processing circuitry 3011 may be configured to, or operable to, perform the method actions according to FIG. 3-6, in a similar manner as that described in relation to FIG. 7a . The radio circuitry 3013 may be configured to set up and maintain at least a wireless connection with the UE 102. Circuitry may be understood herein as a hardware component.
Hence, embodiments herein also relate to the UE 102 operative to operate in the communications system. The UE 102 may comprise the processing circuitry 3011 and the memory 3003, said memory 3003 comprising instructions executable by the processing circuitry 3011, whereby the UE 102 is further operative to perform the actions described herein in relation to the UE 102, e.g., in FIG. 3-6.
FIGS. 8a and FIG. 8b depict two different examples in panels a) and b), respectively, of the arrangement that the access node 103, 104 may comprise. In some embodiments, the access node 103, 104 may comprise the following arrangement depicted in FIG. 8 a.
The embodiments herein in the access node 103, 104 may be implemented through one or more processors, such as a processor 3101 in the access node 103, 104 depicted in FIG. 8a , together with computer program code for performing the functions and actions of the embodiments herein. A processor, as used herein, may be understood to be a hardware component. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the access node 103, 10. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the access node 103, 104.
The access node 103, 104 may further comprise a memory 3103 comprising one or more memory units. The memory 3103 is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the access node 103, 104.
In some embodiments, the access node 103, 104 may receive information from, e.g. the UE 102 and/or another network node, through a receiving port 3104. In some embodiments, the receiving port 3104 may be, for example, connected to one or more antennas in access node 103, 104. In other embodiments, the access node 103, 104 may receive information from another structure in the communications system the receiving port 3104. Since the receiving port 3104 may be in communication with the processor 3101, the receiving port 3104 may then send the received information to the processor 3101. The receiving port 3104 may also be configured to receive other information.
The processor 3101 in the access node 103, 104 may be further configured to transmit or send information to e.g. the UE 102, or another structure in the communications system, through a sending port 3105, which may be in communication with the processor 3101 and the memory 3103.
The access node 103, 104 may comprise a obtaining unit 3113, an acting unit 3115, a providing unit 3118, a determining unit 3120, a performing unit 3123, other units 3140 etc.
The communications system may be a 2G network, a 3G network, a 4G network, a 5G network, a 6G network or any other legacy, current of future network.
The access node 103, 104 may be e.g. a base station, node B, eNB, gNB, RNC etc, or a network node 106 as exemplified above.
Those skilled in the art will also appreciate that the obtaining unit 3113, an acting unit 3115, a providing unit 3118, a determining unit 3120, a performing unit 3123, other units 3140 etc. described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor 3101, perform as described above. One or more of these processors, as well as the other digital hardware, may be comprised in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).
Also, in some embodiments, the different units 3113-3140 described above may be implemented as one or more applications running on one or more processors such as the processor 3101.
Thus, the methods according to the embodiments described herein for the access node 103, 104 may be respectively implemented by means of a computer program 3110 product, comprising instructions, i.e., software code portions, which, when executed on at least one processor 3101, cause the at least one processor 3101 to carry out the actions described herein, as performed by the access node 103, 104. The computer program 3110 product may be stored on a computer-readable storage medium 3108. The computer-readable storage medium 3108, having stored thereon the computer program 3110, may comprise instructions which, when executed on at least one processor 3101, cause the at least one processor 3101 to carry out the actions described herein, as performed by the access node 103, 104. In some embodiments, the computer-readable storage medium 3110 may be a non-transitory computer-readable storage medium, such as a CD ROM disc, or a memory stick. In other embodiments, the computer program 3110 product may be stored on a carrier comprising the computer program 3110 just described, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium 3108, as described above.
The access node 103, 104 may comprise a communication interface configured to facilitate communications between the access node 103, 104 and other nodes or devices, e.g., the UE 102, or another structure. The interface may, for example, comprise a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.
In other embodiments, the access node 103, 104 may comprise the following arrangement depicted in FIG. 8b . The access node 103, 104 may comprise a processing circuitry 3111, e.g., one or more processors such as the processor 3101, in the access node 103, 104 and the memory 3103. The access node 103, 104 may also comprise a radio circuitry 3114, which may comprise e.g., the receiving port 3104 and the second sending port 3105. The processing circuitry 3111 may be configured to, or operable to, perform the method actions according to FIG. 3-6 in a similar manner as that described in relation to FIG. 8a . The radio circuitry 3114 may be configured to set up and maintain at least a wireless connection with the access node 103, 104. Circuitry may be understood herein as a hardware component.
Hence, embodiments herein also relate to the access node 103, 104 to operate in the communications system. The access node 103, 104 may comprise the processing circuitry 3111 and the memory 3103. The memory 3103 comprises instructions executable by said processing circuitry 3111, whereby the access node 103, 104 is further operative to perform the actions described herein in relation to the access node 103, 104, e.g., FIG. 3-6.

Further Extensions and Variations

Telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments.
With reference to FIG. 9, in accordance with an embodiment, a communication system comprises a telecommunication network 3210 such as the communications network, for example, a 3GPP-type cellular network, which comprises access network 3211, such as an access network, and core network 3214. Access network 3211 comprises a plurality of access nodes 103, 104. For example, access nodes 3212 a, 3212 b, 3212 c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213 a, 3213 b, 3213 c. Each access node 3212 a, 3212 b, 3212 c is connectable to core network 3214 over a wired or wireless connection 3215. A plurality of UEs, such as the UE 102 may be comprised in the communications system. In FIG. 9, a first UE 3291 located in coverage area 3213 c is configured to wirelessly connect to, or be paged by, the corresponding access node 3212 c. A second UE 3292 in coverage area 3213 a is wirelessly connectable to the corresponding access node 3212 a. While a plurality of UEs 3291, 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE 102 is connecting to the corresponding access node 3212. Any of the UEs 3291, 3292 may be considered examples of the UE 102.
Telecommunication network 3210 is itself connected to host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. Host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 3221 and 3222 between telecommunication network 3210 and host computer 3230 may extend directly from core network 3214 to host computer 3230 or may go via an optional intermediate network 3220. Intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; intermediate network 3220, if any, may be a backbone network or the Internet; in particular, intermediate network 3220 may comprise two or more sub-networks (not shown).
The communication system of FIG. 9 as a whole enables connectivity between the connected UEs 3291, 3292 and host computer 3230. The connectivity may be described as an Over-The-Top (OTT) connection 3250. Host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and/or signaling via OTT connection 3250, using access network 3211, core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. OTT connection 3250 may be transparent in the sense that the participating communication devices through which OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, access node 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from host computer 3230 to be forwarded, e.g., handed over, to a connected UE 3291. Similarly, access node 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.
In relation to FIGS. 10-14 which are described next, it may be understood that the access node may be considered an example of the access node 103, 104.
FIG. 10 illustrates an example of host computer communicating via an access node 103, 104 with a UE 102 over a partially wireless connection in accordance with some embodiments
The UE 102 and the access node 103, 104, e.g., a access node and host computer discussed in the preceding paragraphs will now be described with reference to FIG. 10. In communication system 3330, such as the communications network, host computer 3310 comprises hardware 3315 comprising communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system 3300. Host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, processing circuitry 3318 may comprise one or more programmable processors, ASICs, field programmable gate arrays (FPGA) or combinations of these (not shown) adapted to execute instructions. Host computer 3310 further comprises software 3311, which is stored in or accessible by host computer 3310 and executable by processing circuitry 3318. Software 3311 comprises a host application 3312. Host application 3312 may be operable to provide a service to a remote user, such as UE 3330 connecting via OTT connection 3350 terminating at UE 3330 and host computer 3310. In providing the service to the remote user, host application 3312 may provide user data which is transmitted using OTT connection 3350.
Communication system 3300 further comprises the access node 103, 104 exemplified in FIG. 10 as an access node 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with host computer 3310 and with UE 3330. Hardware 3325 may comprise a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system 3300, as well as radio interface 3327 for setting up and maintaining at least wireless connection 3370 with the UE 102, exemplified in FIG. 10 as a UE 3330 located in a coverage area (not shown in FIG. 10) served by access node 3320. Communication interface 3326 may be configured to facilitate connection 3360 to host computer 3310. Connection 3360 may be direct or it may pass through a core network (not shown in FIG. 33) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, hardware 3325 of access node 3320 further comprises a processing circuitry 3328, which may comprise one or more programmable processors, ASICs, FPGAs or combinations of these (not shown) adapted to execute instructions. Access node 3320 further has software 3321 stored internally or accessible via an external connection.
Communication system 3300 further comprises a UE 3330 already referred to. It's hardware 3335 may comprise a radio interface 3337 configured to set up and maintain wireless connection 3370 with a access node serving a coverage area in which UE 3330 is currently located. Hardware 3335 of UE 3330 further comprises a processing circuitry 3338, which may comprise one or more programmable processors, ASICs, FPGAs or combinations of these (not shown) adapted to execute instructions. UE 3330 further comprises software 3331, which is stored in or accessible by UE 3330 and executable by processing circuitry 3338. Software 3331 comprises a client application 3332. Client application 3332 may be operable to provide a service to a human or non-human user via UE 3330, with the support of host computer 3310. In host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via OTT connection 3350 terminating at UE 3330 and host computer 3310. In providing the service to the user, client application 3332 may receive request data from host application 3312 and provide user data in response to the request data. OTT connection 3350 may transfer both the request data and the user data. Client application 3332 may interact with the user to generate the user data that it provides.
It is noted that host computer 3310, access node 3320 and UE 3330 illustrated in FIG. 33 may be similar or identical to host computer 3230, one of access nodes 3212 a, 3212 b, 3212 c and one of UEs 3291, 3292 of FIG. 32, respectively. This is to say, the inner workings of these entities may be as shown in FIG. 10 and independently, the surrounding network topology may be that of FIG. 9.
In FIG. 10, OTT connection 3350 has been drawn abstractly to illustrate the communication between host computer 3310 and UE 3330 via access node 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from UE 3330 or from the service provider operating host computer 3310, or both. While OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing, e.g., on the basis of load balancing consideration or reconfiguration of the network.
Wireless connection 3370 between UE 3330 and access node 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE 3330 using OTT connection 3350, in which wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the spectrum efficiency, and latency, and thereby provide benefits such as reduced user waiting time, better responsiveness and extended battery lifetime.
A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring OTT connection 3350 between host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring OTT connection 3350 may be implemented in software 3311 and hardware 3315 of host computer 3310 or in software 3331 and hardware 3335 of UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of OTT connection 3350 may comprise information indicating message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect access node 3320, and it may be unknown or imperceptible to access node 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating host computer 3310's measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that software 3311 and 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using OTT connection 3350 while it monitors propagation times, errors etc.
FIG. 11 illustrates an example of methods implemented in a communication system comprising a host computer, an access node and a user equipment. FIG. 10 is a flowchart illustrating a method implemented in a communication system. The communication system comprises a host computer, an access node 103, 104 and an UE 102 which may be those described with reference to FIG. 8 and FIG. 9. For simplicity of the present disclosure, only drawing references to FIG. 10 will be included in this section. In step 3410, the host computer provides user data. In substep 3411 (which may be optional) of step 3410, the host computer provides the user data by executing a host application. In step 3420, the host computer initiates a transmission carrying the user data to the UE. In step 3430 (which may be optional), the access node transmits to the UE 102 the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 3440 (which may also be optional), the UE 102 executes a client application associated with the host application executed by the host computer.
FIG. 12 illustrates methods implemented in a communication system comprising a host computer, an access node 103, 104 and an UE 102 in accordance with some embodiments. FIG. 12 is a flowchart illustrating a method implemented in a communication system. The communication system comprises a host computer, an access node 103, 104 and an UE 102 which may be those described with reference to FIG. 8 and FIG. 9. In step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In step 3520, the host computer initiates a transmission carrying the user data to the UE 102. The transmission may pass via the access node, in accordance with the teachings of the embodiments described throughout this disclosure. In step 3530 (which may be optional), the UE 102 receives the user data carried in the transmission.
FIG. 13 illustrates methods implemented in a communication system comprising a host computer, an access node 103, 104 and a UE 102. FIG. 13 is a flowchart illustrating a method implemented in a communication system. The communication system comprises a host computer, an access node 103, 104 and a UE 102 which may be those described with reference to FIG. 8 and FIG. 9. For simplicity of the present disclosure, only drawing references to FIG. 13 will be included in this section. In step 3610 (which may be optional), the UE 102 receives input data provided by the host computer. Additionally or alternatively, in step 3620, the UE 102 provides user data. In substep 3621 (which may be optional) of step 3620, the UE 102 provides the user data by executing a client application. In substep 3611 (which may be optional) of step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE 102 initiates, in substep 3630 (which may be optional), transmission of the user data to the host computer. In step 3640 of the method, the host computer receives the user data transmitted from the UE 102, in accordance with the teachings of the embodiments described throughout this disclosure.
FIG. 14 illustrates methods implemented in a communication system comprising a host computer, an access node 103, 104 and an UE 102. FIG. 14 is a flowchart illustrating a method implemented in a communication network. The communication system comprises a host computer, an access node 103, 104 and an UE 102 which may be those described with reference to FIG. 8 and FIG. 9. In step 3710 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the access node 103, 104 receives user data from the UE 102. In step 3720 (which may be optional), the access node initiates transmission of the received user data to the host computer. In step 3730 (which may be optional), the host computer receives the user data carried in the transmission initiated by the access node.
Some embodiments may be summarized as follows:
A access node 103, 104 configured to communicate with a UE 102, the access node 103, 104 comprising a radio interface and processing circuitry configured to perform one or more of the actions described herein as performed by the access node 103, 104.
A communication system comprising a host computer comprising:

- processing circuitry configured to provide user data; and
- a communication interface configured to forward the user data to a cellular network for transmission to a UE 102,
- wherein the cellular network comprises an access node 103, 104 having a radio interface and processing circuitry, the access node's processing circuitry configured to perform one or more of the actions described herein as performed by the access node 103, 104.

The communication system may further comprise the access node 103, 104.
The communication system may further comprise the UE 102, wherein the UE 102 is configured to communicate with the access node 103, 104.
The communication system, wherein:

- the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and
- the UE 102 comprises processing circuitry configured to execute a client application associated with the host application.

A method implemented in an access node 103, 104, comprising one or more of the actions described herein as performed by the access node 103, 104.
A method implemented in a communication system comprising a host computer, an access node 103, 104 and a UE 102, the method comprising:

- at the host computer, providing user data; and
- at the host computer, initiating a transmission carrying the user data to the UE 102 via a cellular network comprising the access node 103, 104. The access node 103, 104 performs one or more of the actions described herein as performed by the access node 103, 104.

The method may further comprise:

- at the access node 103, 104, transmitting the user data.

The user data may be provided at the host computer by executing a host application, and the method may further comprise:

- at the UE 102, executing a client application associated with the host application.

A UE 102 configured to communicate with an access node 103, 104, the UE 102 comprising a radio interface and processing circuitry configured to perform one or more of the actions described herein as performed by the UE 102.
A communication system comprising a host computer comprising:

- processing circuitry configured to provide user data; and
- a communication interface configured to forward user data to a cellular network for transmission to a UE 102,
- the UE 102 comprises a radio interface and processing circuitry, the UE's processing circuitry configured to perform one or more of the actions described herein as performed by the UE 102.

The communication system may further comprise the UE 102.
The communication system further comprising an access node 103, 104 configured to communicate with the UE 102.
The communication system, wherein:

- the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and
- the UE's processing circuitry is configured to execute a client application associated with the host application.

A method implemented in a UE 102, comprising one or more of the actions described herein as performed by the UE 102.
A method implemented in a communication system comprising a host computer, an access node 103, 104 and a UE 102, the method comprising:

- at the host computer, providing user data; and
- at the host computer, initiating a transmission carrying the user data to the UE 102 via a cellular network comprising the access node, wherein the UE 102 performs one or more of the actions described herein as performed by the UE 102.

The method may further comprise:

- at the UE 102, receiving the user data from the access node 103, 104.

- a communication interface configured to receive user data originating from a transmission from a UE 102 to an access node 103, 104,
- the UE 102 comprises a radio interface and processing circuitry, the UE's processing circuitry configured to perform one or more of the actions described herein as performed by the UE 102.

The communication system may further comprise the UE 102.
The communication system may further comprise the access node 103, 104, wherein the access node 103, 104 comprises a radio interface configured to communicate with the UE 102 and a communication interface configured to forward to the host computer the user data carried by a transmission from the UE 102 to the access node 103, 104.
The communication system, wherein:

- the processing circuitry of the host computer is configured to execute a host application; and
- the UE's processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data.

The communication system, wherein:

- the processing circuitry of the host computer is configured to execute a host application, thereby providing request data; and
- the UE's processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data in response to the request data.

A method implemented in a UE 102, comprising one or more of the actions described herein as performed by the UE 102.
The method may further comprise:

- providing user data; and
- forwarding the user data to a host computer via the transmission to the access node 103, 104.

A method implemented in a communication system comprising a host computer, an access node 103, 104 and a UE 102, the method comprising:

- at the host computer, receiving user data transmitted to the access node 103, 104 from the UE 102, wherein the UE 102 performs one or more of the actions described herein as performed by the UE 102.

The method may further comprise:

- at the UE 102, providing the user data to the access node 103, 104.

The method may further comprise:

- at the UE 102, executing a client application, thereby providing the user data to be transmitted; and
- at the host computer, executing a host application associated with the client application.

The method may further comprise:

- at the UE 102, executing a client application; and
- at the UE 102, receiving input data to the client application, the input data being provided at the host computer by executing a host application associated with the client application,
- the user data to be transmitted is provided by the client application in response to the input data.

A access node 103, 104 configured to communicate with a UE 102, the access node 103, 104 comprising a radio interface and processing circuitry configured to perform one or more of the actions described herein as performed by the access node 103, 104.
A communication system comprising a host computer comprising a communication interface configured to receive user data originating from a transmission from a UE 102 to a access node 103, 104, wherein the access node 103, 104 comprises a radio interface and processing circuitry, the network node's processing circuitry configured to perform one or more of the actions described herein as performed by the access node 103, 104.
The communication system may further comprise the access node 103, 104.
The communication system may further comprise the UE 102. The UE 102 is configured to communicate with the access node 103, 104.
The communication system wherein:

- the processing circuitry of the host computer is configured to execute a host application;
- the UE 102 is configured to execute a client application associated with the host application, thereby providing the user data to be received by the host computer.

A method implemented in an access node 103, 104, comprising one or more of the actions described herein as performed by any of the access node 103, 104.
A method implemented in a communication system comprising a host computer, an access node 103, 104 and a UE 102, the method comprising:

- at the host computer, receiving, from the access node 103, 104, user data originating from a transmission which the access node has received from the UE 102, wherein the UE 102 performs one or more of the actions described herein as performed by the UE 102.

The method may further comprise:

- at the access node 103, 104, receiving the user data from the UE 102.

The method may further comprise:

- at the access node 103, 104, initiating a transmission of the received user data to the host computer.

Some embodiments will be summarized below:
The communications system may be a 2G network, a 3G network, a 4G network, a 5G network, a 6G network or any other legacy, current of future network.
The access node 103, 104 may be a base station, node B, eNB, gNB, MeNB, RNC, access node, radio access node etc.
The embodiments herein relate to 5G, 4G, false access node, SI, broadcast message, digital signature etc.
The embodiments herein relate to UE recovery at SI signature verification failure.
Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step.
Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.
In general, the usage of “first”, “second”, “third”, “fourth”, and/or “fifth” herein may be understood to be an arbitrary way to denote different elements or entities, and may be understood to not confer a cumulative or chronological character to the nouns they modify, unless otherwise noted, based on context.
Several embodiments are comprised herein. It should be noted that the examples herein are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments
The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the embodiments. A feature from one embodiment may be combined with one or more features of any other embodiment.
The term “at least one of A and B” should be understood to mean “only A, only B, or both A and B.”, where A and B are any parameter, number, indication used herein etc.
It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements.
The term “configured to” used herein may also be referred to as “arranged to”, “adapted to”, “capable of” or “operative to”.
It should also be emphasised that the steps of the methods may, without departing from the embodiments herein, be performed in another order than the order in which they appear herein.

ABBREVIATIONS

3GPP 3rd Generation Partnership Project
5G 5th Generation
5GS 5G System
5GC 5G Core network
AMF Access and Mobility Management Function
CN Core Network
DL Downlink
eNB Evolved Node B
E-UTRAN Evolved Universal Terrestrial Access Network
EPC Evolved Packet Core network
gNB 5G Node B
LTE Long-term Evolution
MME Mobility Management Entity
NG The interface/reference point between the RAN and the CN in 5G/NR.
NG-C The control plane part of NG (between a gNB and an AMF).
NG-U The user plane part of NG (between a gNB and a UPF).
NG-RAN Next Generation Radio Access Network
NR New Radio
RAN Radio Access Network
RRC Radio Resource Control
Rx Receive
S1 The interface/reference point between the RAN and the CN in LTE.
S1-C The control plane part of S1 (between an eNB and a MME).
S1-U The user plane part of S1 (between an eNB and a SGW). SGW Serving Gateway
TS Technical Specification
UE User Equipment
UL Uplink
UPF User Plane Function
X2 The interface/reference point between two eNBs.
X2AP X2 Application Protocol
Xn The interface/reference point between two gNBs.
XnAP Xn Application Protocol

Claims

1-24. (Canceled)

25. A method performed by a User Equipment (UE) for handling validity of a System Information (SI) signature in a communication system, the method comprising:

obtaining, from an access node, System Information (SI) and an associated SI signature for a cell served by the access node and which the UE can use;

determining whether the obtained SI signature is valid or invalid; and

in response to determining that the SI signature is valid, determining that the cell is valid; or

in response to determining that the SI signature is invalid:

determining that the cell is invalid; and

providing information indicating the invalid cell to the access node or to another node, the information comprising failure information indicating at least one of: location information associated with the cell or measurements made by the UE for the cell.

26. The method according to claim 25, comprising:

obtaining one or multiple SI protection parameters used for determining if the SI signature is valid or invalid and associated to actions to be taken upon determining that the SI signature is invalid.

27. The method according to claim 26, wherein the one or multiple SI protection parameters comprises at least one of: one or more public key s associated with determining if the SI signature is valid or invalid, an indication of allowed intra-frequency cell selection, barring timer, an indication of whether a cell with invalid SI signature should be barred or not.

28. The method according to claim 25, wherein the SI and the associated SI signature for the cell is obtained for any one or more of the following circumstances:

when the UE is in Radio Resource Control IDLE, RRC_IDLE, or RRC_INACTIVE state or any other power saving state and searches for a suitable cell to use in the cell selection/re-selection procedure;

when the UE is in RRC_CONNECTED state when cell selection is triggered as part of a RRC connection re-establishment procedure, after a handover to a target cell when the UE reads the SI of the target cell;

when the UE is being configured to report a Cell Global Identifier, CGI, of a cell that is not a Primary Cell, PCell; or

during any action requiring the UE to obtain the SI.

29. The method according to claim 25, wherein when the UE determines the cell as valid, then the UE uses the cell.

30. The method according to claim 25, wherein, when the UE is in connected state and is configured for Cell Global Identifier (CGI) reporting, the method comprises:

obtaining cell access related information; and

providing the cell access related information to the access node.

31. The method according to claim 25, wherein the method includes any one or more of providing the information indicating the invalid cell to the access node immediately after the determining, logging the information indicating the invalid cell and providing the logged information to the access node at a later time, or providing the information indicating the invalid cell to the access node in response to the UE receiving polling from the access node.

32. The method according to claim 25, wherein the SI signature is determined to be invalid responsive to at least one of: the SI signature not matching an expected or predetermined SI signature calculated using a public key, or the SI signature being missing or malformed.

33. A User Equipment (UE) comprising:

radio circuitry configured for communicating with access nodes of a communication system; and

processing circuitry operatively associated with the radio circuitry and configured to control the UE to:

determine whether a System Information (SI) signature is valid, the SI signature obtained from an access node of the communication system for a cell that is associated with the access node and usable by the UE; and

provide information indicating SI signature invalidity to the access node or to another node of the communication system, responsive to determining that the SI signature is not valid.

34. A non-transitory computer-readable medium storing computer program instructions that, when executed by one or more processors of a User Equipment (UE) configured for communicating with a communication system, configure the UE to: