IoT NTN pseudo base station identification method and communication system

Abstract

The application discloses an IoT NTN pseudo base station identification method and a communication system. The method comprises the following steps: after a user equipment reselects from a resident original cell to a new cell, acquiring a first TAC of the new cell; when reselecting from the new cell to the original cell, sending a TA update request message to an IoT NTN system in the original cell, wherein the TA update request message at least comprises a target element carrying the first TAC and an evolved packet system update type element indicating whether the new cell is an IoT NTN pseudo base station through the TAC; receiving a TA update acceptance message, wherein the TA update acceptance message at least comprises an evolved packet system mobility management reason element indicating whether the first TAC is verified; and judging whether the new cell is an IoT NTN pseudo base station according to the TA update acceptance message. The application solves the technical problem that related technologies cannot actively identify IoT NTN pseudo base stations, thereby increasing the risk of sensitive information leakage of the user equipment.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and more specifically, to an IoT NTN fake base station identification method and communication system. Background Technology

[0002] Currently, in the LTE (Long Term Evolution) and IoT NTN (Internet of Things Non-Terrestrial Networks) architectures based on 3GPP standards, fake base station attacks have become a significant source of risk threatening the information security of end users.

[0003] Under standard protocol procedures, in Radio Resource Control (RRC) Idle mode, User Equipment (UE) obtains the Track Area Code (TAC) by listening to the System Information Block (SIB) messages of the serving cell and stores it in its local Tracking Area (TA) list. When the UE reselects to a new cell, if it detects that the Track Area Code broadcast by the new cell is not within its local Tracking Area Code list, it will trigger the Tracking Area Update (TAU) procedure to register the new location with the centralized core network. This is the standard mobility management mechanism.

[0004] However, attackers can exploit the aforementioned mechanism to deploy fake base stations. These fake base stations significantly increase transmission power, forge legitimate SIB messages, and broadcast an abnormal tracking area code that is not part of the legitimate network planning. This induces the UE to mistakenly believe it has entered a new tracking area. After the UE completes reselection, random access, and radio resource control connection establishment according to protocol standards, it will proactively initiate a tracking area update request message, carrying this abnormal tracking area code as its current location information. At this point, instead of forwarding the tracking area update request message to the centralized core network as required by the protocol, the fake base station intercepts the message and forges an identity request message, requesting highly sensitive identity information such as the International Mobile Subscriber Identity (IMSI) / International Mobile Equipment Identity (IMEI) from the UE. Driven by the standard protocol, the UE then sends back this highly sensitive identity information via an identity response message. Once the fake base station obtains this information, it forges a tracking area update rejection message, terminating the connection under the pretext of "location update failure," forcing the UE to leave the fake base station and reselect to another legitimate cell, thus stealing the user's identity information undetected.

[0005] The aforementioned attack methods have been widely verified in terrestrial LTE networks. With the development of IoT NTN systems, the risk of such attacks has extended from the ground to the space domain. Furthermore, due to the centralized core network architecture of IoT NTN systems, the wide coverage of UEs, the complex channel propagation characteristics, the sparse distribution of UEs, and the fact that most of them are low-power consumer or industrial terminals, their anti-interference capabilities are weak and their security protection mechanisms are flimsy, making them extremely vulnerable to fake base station attacks.

[0006] There is currently no effective solution to the above problems. Summary of the Invention

[0007] This application provides an IoT NTN fake base station identification method and communication system to at least solve the technical problem that related technologies cannot actively identify IoT NTN fake base stations, which increases the risk of leakage of sensitive information of user equipment.

[0008] According to one aspect of the embodiments of this application, an IoT NTN fake base station identification method is provided, comprising: after a user equipment reselects from its original cell to a new cell, obtaining a first Tracking Area Update (TAC) of the new cell; when the user equipment reselects back to its original cell from the new cell, sending a Tracking Area Update Request message to the IoT NTN system within the original cell, wherein the Tracking Area Update Request message includes at least: a target information element containing the first TAC, and an Evolved Packet System Update Type (EPS) information element for indicating whether the new cell is an IoT NTN fake base station identified by the TAC; receiving a Tracking Area Update Accept message from the IoT NTN system, wherein the Tracking Area Update Accept message includes at least: an Evolved Packet System Mobility Management Reason (EPS) information element for indicating whether the first TAC has passed verification; and determining whether the new cell is an IoT NTN fake base station based on the Tracking Area Update Accept message.

[0009] In an exemplary embodiment, before sending a Tracking Area Update Request message to the IoT NTN system within the original cell, the method further includes: determining a second TAC of the original cell based on a local database, wherein the local database records cell information of multiple historically resided cells, wherein the cell information includes at least a TAC; and reselecting back to the original cell from the new cell based on the second TAC.

[0010] In an exemplary embodiment, the tracking area update request message further includes: a tracking area identifier information element containing the last access registration of the second TAC of the original cell, wherein receiving the tracking area update acceptance message from the IoT NTN system includes: receiving the tracking area update acceptance message from the IoT NTN system when the type value in the Evolved Packet System update type information element is a target valid value, wherein the reason value in the Evolved Packet System mobility management reason information element includes: a first valid value indicating that the first TAC has failed verification and a second valid value indicating that the first TAC has passed verification.

[0011] In an exemplary embodiment, the failure of the first TAC to pass verification includes: the geographical areas corresponding to the first TAC and the second TAC are not adjacent, and the first TAC does not exist in the preset list of legal TACs, wherein the list of legal TACs includes TACs of multiple legal cells.

[0012] In an exemplary embodiment, after determining whether the new cell is an IoT NTN fake base station based on the tracking area update reception message, the method further includes: if the new cell is an IoT NTN fake base station, continuing to camp on the original cell and switching the radio resource control state to the radio resource control idle state; if the new cell is not an IoT NTN fake base station, reselecting back to the new cell from the original cell.

[0013] In one exemplary embodiment, the IoT NTN system includes at least a satellite access network and a centralized core network, and the centralized core network includes only one mobility management module.

[0014] In one exemplary embodiment, the target valid value includes 110 or 111.

[0015] According to another aspect of the embodiments of this application, an IoT NTN fake base station identification method is also provided, comprising: an IoT NTN system receiving a Tracking Area Update Request message sent by a user equipment in the original cell before reselection, wherein the Tracking Area Update Request message includes at least: a target information element containing a first TAC of the new cell after reselection, and an Evolved Packet System Update Type information element for indicating whether the new cell is an IoT NTN fake base station identified by the TAC; determining whether the new cell is an IoT NTN fake base station based on the Tracking Area Update Request message, and constructing a Tracking Area Update Acceptance message based on the determination result, wherein the Tracking Area Update Acceptance message includes at least: an Evolved Packet System Mobility Management Reason information element for indicating whether the first TAC has passed verification; and feeding back the Tracking Area Update Acceptance message to the user equipment.

[0016] In an exemplary embodiment, the tracking area update request message further includes: a tracking area identifier element containing the last access registration tracking area of ​​the original cell's second TAC, wherein determining whether the new cell is an IoT NTN fake base station based on the tracking area update request message, and constructing a tracking area update acceptance message based on the determination result, includes: determining whether the first TAC exists in a preset list of legitimate TACs, and whether the geographical areas corresponding to the first TAC and the second TAC are adjacent, wherein the list of legitimate TACs includes: TACs of multiple legitimate cells; if the first TAC does not exist in the list of legitimate TACs and / or the geographical areas corresponding to the first TAC and the second TAC are not adjacent, determining that the new cell is an IoT NTN fake base station, and constructing a tracking area update acceptance message carrying a first valid value, wherein the first valid value is used to indicate that the first TAC has failed verification; if the first TAC exists in the list of legitimate TACs and the geographical areas corresponding to the first TAC and the second TAC are adjacent, determining that the new cell is not an IoT NTN fake base station, and constructing a tracking area update acceptance message carrying a second valid value, wherein the second valid value is used to indicate that the first TAC has passed verification.

[0017] According to another aspect of the embodiments of this application, a communication system is also provided, which includes at least: a user equipment and an IoT NTN system, wherein the user equipment is configured to: after reselecting from its original cell to a new cell, obtain a first TAC of the new cell; and, in the case of reselecting back to the original cell from the new cell, send a Tracking Area Update Request message to the IoT NTN system within the original cell, wherein the Tracking Area Update Request message includes at least: a target information element containing the first TAC and an EPC Update Type information element for indicating whether the new cell is an IoT NTN fake base station identified by the TAC; the IoT NTN system is configured to: determine whether the new cell is an IoT NTN fake base station based on the Tracking Area Update Request message, and construct a Tracking Area Update Acceptance message based on the determination result, wherein the Tracking Area Update Acceptance message includes at least: an EPC Mobility Management Reason information element for indicating whether the first TAC has passed verification; and feed back the Tracking Area Update Acceptance message to the user equipment; the user equipment is further configured to: determine whether the new cell is an IoT NTN fake base station based on the Tracking Area Update Acceptance message.

[0018] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer-readable storage medium, when executed by a processor, performs the steps in any of the above method embodiments.

[0019] According to another aspect of the embodiments of this application, a computer program product or computer program is also provided, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, causing the computer device to perform the steps in any of the method embodiments described above.

[0020] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the steps of any of the above method embodiments through the computer program.

[0021] In this embodiment, after the user equipment reselects from its original cell to a new cell, it obtains the first TAC of the new cell; when the user equipment reselects back to the original cell from the new cell, it sends a Tracking Area Update Request message to the IoT NTN system within the original cell, which includes at least: a target information element carrying the first TAC and an EPC Update Type information element indicating whether the new cell is an IoT NTN fake base station identified by the TAC; it receives a Tracking Area Update Acceptance message from the IoT NTN system, which includes at least: an EPC Mobility Management Reason information element indicating whether the first TAC has passed verification; and it determines whether the new cell is an IoT NTN fake base station based on the Tracking Area Update Acceptance message. The above technical solution introduces a dual-end linkage mechanism of "back-off reporting and centralized core network collaborative verification," which prevents IoT NTN fake base stations from stealing users' sensitive information by intercepting tracking area update request messages and forging identity request messages. This completely switches the identity theft link in the IoT NTN fake base station attack chain, significantly reducing the risk of user privacy leakage. As a result, it enables the active identification of IoT NTN fake base stations without relying on physical layer features, thus solving the technical problem that related technologies cannot actively identify IoT NTN fake base stations, leading to an increased risk of leakage of sensitive information of user equipment. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 This is a signaling flowchart of one possible LTE fake base station attack in related technologies;

[0024] Figure 2 This is a structural block diagram of an optional communication system according to an embodiment of this application;

[0025] Figure 3 This is an interactive flowchart of an optional IoT NTN system and user equipment according to an embodiment of this application;

[0026] Figure 4 This is an alternative interaction flowchart of an IoT NTN system and user equipment according to an embodiment of this application;

[0027] Figure 5 This is a flowchart illustrating an optional IoT NTN fake base station identification method according to an embodiment of this application;

[0028] Figure 6 This is a flowchart illustrating another optional IoT NTN fake base station identification method according to an embodiment of this application;

[0029] Figure 7 This is a structural block diagram of an optional IoT NTN fake base station identification device according to an embodiment of this application;

[0030] Figure 8 This is a structural block diagram of another optional IoT NTN fake base station identification device according to an embodiment of this application;

[0031] Figure 9 This is a structural block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] To better understand the embodiments of this application, the following is a translation and explanation of some nouns or terms that appear in the description of the embodiments of this application:

[0035] Fake base stations, also known as fake base stations, are typically composed of a host computer and a laptop. Using devices such as SMS mass mailers and SMS transmitters, they can search for SIM card information within a certain radius. By impersonating a mobile operator's base station, they can forcibly send fraudulent, advertising, or other malicious text messages to users' phones using other people's phone numbers. When a fake base station is running, the user's mobile phone signal is forcibly connected to the device, causing the phone to be unable to use the services provided by the operator. The phone user will generally experience a temporary disconnection for 8-12 seconds before returning to normal service; some phones may require a complete power cycle to reconnect. Furthermore, it causes users to frequently update their location, straining wireless network resources in the area and causing network congestion, affecting normal communication.

[0036] The Tracking Area Update Request (STA) message is a key signaling message in the Non-Access Stratum (NAS) of 3GPP LTE / 5G networks. It is sent by the UE to the centralized core network when it detects a change in its tracking area. This request informs the network of its current location so that the network can maintain accessibility and mobility management for the UE. The format of the STAR Request message as defined in the 3GPP protocol is shown in Table 1 below.

[0037] Table 1

[0038]

[0039]

[0040]

[0041]

[0042] in:

[0043] The format of the "EPS Update Type" information element defined in the 3GPP protocol is shown in Table 2 below, and its length is 1 byte (containing 8 bits).

[0044] Table 2

[0045]

[0046] The EPS update type value consists of three bits with six possible values: 000—Normal Tracking Area Update (the UE triggers the tracking area update process because it moves into a new tracking area code but is not in the local tracking area list), 001—Joint Tracking Area / Location Area Update, 010—Joint Tracking Area / Location Area Update + IMSI Attachment, 011—Periodic Tracking Area Update, and 100 and 101—Reserved values ​​(cannot be rejected upon reception and must be processed as a normal tracking area update). The activation flag has two possible values: 0—No request to establish a dedicated bearer (i.e., the UE only updates its location and does not need to activate data services), and 1—Request to establish a dedicated bearer (i.e., the UE wants to establish a default bearer while completing the location update).

[0047] In addition, the format of the "Additional Update Type" information element is defined in the 3GPP protocol as shown in Table 3 below, and its length is 1 byte (containing 8 bits).

[0048] Table 3

[0049]

[0050] The additional update type value includes two possible values: 0—no additional information (if the receiver receives this value, it can be interpreted as a request for joint attach or joint tracking area update), and 1—SMS only; the signaling hold flag includes two possible values: 0—release the NAS signaling connection after completing the tracking area update process, and 1—maintain the NAS signaling connection after completing the tracking area update process; the preferred CIoT network behavior includes four possible values: 00—no additional information (i.e., no special optimization requirements, processed according to the normal process), 01—control plane CIoT EPS optimization (i.e., data is transmitted through the NAS signaling channel, suitable for small packet, low frequency, and low power consumption terminals), 10—user plane CIoT EPS optimization (i.e., data is transmitted through the packet data network connection, suitable for terminals that require high throughput or frequent data uploads), and 11—reserved value (if received, it can be regarded as a protocol error).

[0051] The Tracking Area Update Accept message is a key signaling message in the Non-Access Stratum (NAS) of 3GPP LTE / 5G networks. It approves the tracking area update request message initiated by the UE and notifies the UE of new tracking area information, timer parameters, etc., completing the location update process. The format of the Tracking Area Update Accept message defined in the 3GPP protocol is shown in Table 4 below.

[0052] Table 4

[0053]

[0054]

[0055]

[0056]

[0057] in:

[0058] The format of the "EPS Mobility Management Reason Value" information element is defined in the 3GPP protocol as shown in Table 5 below. Its length is 2 bytes, one byte is the information element identifier, and the other byte is the reason value.

[0059] Table 5

[0060]

[0061] The cause values ​​include 39 possible values: 00000010 - International Mobile Subscriber Identity (IMSI) not present on the Home Subscriber Server (HSS); 00000011 - Illegal UE (i.e., UE identity is illegal, such as unauthorized satellite network access); 00000101 - IISI not accepted (i.e., UE is blacklisted); 00000110 - Illegal mobile device (i.e., mobile device type or status is illegal); 00000111 - EPS service not allowed (i.e., user has not activated EPS service); 00001000 - Both EPS and non-EPS services not allowed (i.e., complete access ban, such as account freeze); 00001001 - Network cannot deduce UE identifier (i.e., network cannot deduce IMSI from S-TMSI, etc.); 00001010 - Implicit separation (UE is separated due to prolonged inactivity). Response to paging being automatically separated by the network), 00001011 - Public Land Mobile Network Not Allowed (i.e., the current public land mobile network is not on the UE whitelist or roaming is not allowed), 00001100 - Tracking Area Not Allowed (i.e., the current tracking area code is not in the allowed service area, such as due to geographical restrictions), 00001101 - This Tracking Area Not Allowed (i.e., the roaming user is prohibited from accessing the current tracking area), 00001110 - EPS Service Not Allowed in this Public Land Mobile Network (i.e., the user is prohibited from using EPS service within this operator's network), 00001111 - No suitable cell in the tracking area (i.e., no available cell for access), 00010000 - Mobile Switching Center (Mobile Switching Center) Switching Center (MSC) temporarily unavailable; 00010001 - Network failure (i.e., internal failure of the centralized core network); 00010010 - Circuit-switched domain unavailable; 00010011 - EPS session management failure (i.e., protocol data unit session establishment failure); 00010100 - Message authentication code failure (i.e., air interface integrity verification failure); 00010101 - Synchronization failure (i.e., UE and network cannot synchronize); 00010110 - Congestion (i.e., network load is too high, new requests are rejected); 00010111 - UE security capability mismatch (i.e., UE is incompatible with encryption / integrity algorithms supported by the network); 00011000 - Security mode denied, reason unknown (i.e., security mode negotiation failed, no specific reason); 00011001 - Unauthorized access to this Closed Subscriber Group.CSG), 00011010 - Non-EPS authorization is unacceptable (i.e., non-EPS authentication method was used), 00011111 - Redirection to 5GCN required (i.e., the network requires the UE to switch to the 5G centralized core network), 00100011 - Requested service option is not authorized in this public land mobile network, 00100100 - Integrated Access and Backhaul (IAB) node operation is not authorized, 00100111 - Circuit-switched domain service is temporarily unavailable (i.e., voice service is temporarily unavailable), 00101000 - No active EPS bearer context (i.e., the UE has not established any data bearer and cannot transmit data), 00101001 - Severe network failure, 01001110 - Public land mobile network operation is not allowed at the current location of the UE, 01011111 - Message with semantic error (e.g., message structure or information element value does not conform to protocol syntax), 01100000 - Invalid mandatory information. Element, 01100001 - Message type does not exist or is not implemented (e.g., received an unsupported NAS message type), 01100010 - Message type is incompatible with protocol state (i.e., the message was received in an error state), 01100011 - Information element does not exist or is not implemented (i.e., the message contains information elements not recognized by the network), 01100100 - Condition information element error, 01100101 - Message is incompatible with protocol state (i.e., the message conflicts with the current UE or network state), 01101111 - Protocol error (i.e., all undefined or unknown errors are considered this value).

[0062] Currently, in the 3GPP LTE network architecture, the UE, in the Radio Resource Control (RRC) idle state, periodically listens to the system information blocks of the serving cell to obtain the tracking area code broadcast by the serving cell and adds it to its locally maintained tracking area list for location management. Generally, when the UE reselects to a new cell and detects that the tracking area code of the new cell is not in its tracking area list, it will proactively initiate a tracking area update procedure to register the new location with the mobility management entity; this is the standard mobility management mechanism.

[0063] However, this mechanism has been maliciously exploited by attackers to create LTE fake base station attacks based on tracking area codes. Attackers deploy low-cost, high-power illegitimate base station equipment, forging the physical layer parameters (such as physical cell identifiers) and system broadcast messages of legitimate cells to broadcast an abnormal tracking area code that is not legitimately planned by the operator. This induces the UE to mistakenly believe that it has entered a new tracking area, thereby triggering the tracking area update process. Specifically, Figure 1 The following is a signaling flowchart of an LTE fake base station attack as specified in the standard protocol: Figure 1 As shown, it includes the following steps:

[0064] (1) When the UE is in the radio resource control idle state, it listens for the SIB1 message broadcast by the legitimate cell in the original cell where it is currently camped. By decoding the SIB1 message, it obtains the tracking area code of the current cell and records it in the local tracking area list for subsequent mobility management.

[0065] (2) The LTE fake base station starts up and identifies the weaker legitimate cell by measuring the reference signal reception power and reference signal reception quality of the neighboring legitimate cell and copying its physical cell identifier to avoid the UE's PCI anomaly detection. Then the LTE fake base station increases the transmission power and broadcasts forged system messages (such as system information block 1 message and main information block message).

[0066] (3) The UE sorts the neighboring cells according to the R criterion based on the reselection parameters in the broadcast system message (such as Qrxlevmin, Snonintrasearch, ThreshServingLow, etc.) and selects the LTE pseudo base station with the best signal quality as the reselection target. This is because: the power of the LTE pseudo base station increases, and its signal strength will be better than that of the neighboring cells, thus satisfying the UE's reselection conditions.

[0067] (4) The UE leaves the original serving cell and synchronizes the primary synchronization signal and secondary synchronization signal of the LTE pseudo base station to complete time and frequency synchronization and cell ID identification. Then, it receives and decodes the Master Information Block (MIB) message on the Physical Broadcast Channel (PBCH) to obtain basic parameters such as the System Frame Number (SFN), downlink system bandwidth, and Physical Hybrid ARQIndicator Channel (PHICH) configuration.

[0068] (5) Based on the scheduling information in the MIB message, the UE receives and decodes the SIB1 message on the Physical Downlink Shared Channel (PDSCH) to obtain information such as the cell access parameters (e.g., cellAccessRelatedInfo), tracking area code, and frequency priority of the LTE fake base station. Among them, the tracking area code is an illegal value forged by the LTE fake base station (e.g., 0xFFFF, a value not registered in the operator's tracking area code database), which is intended to prevent the tracking area code from being included in the tracking area list stored by the UE, thereby triggering the tracking area update process.

[0069] (6) The UE continues to receive and decode the SIB2 message to obtain the relevant configuration of the Physical Random Access Channel (PRACH), including: preamble format, PRACH resource location, number of preamble codes, power ramp step size and other information, in order to prepare for subsequent random access.

[0070] (7) The UE randomly selects an idle preamble from the available preamble sequences and prepares to send according to the PRACH time and frequency resource location configured in the SIB2 message.

[0071] (8) The UE sends the selected preamble (i.e. MSG1) on the PRACH to initiate the random access procedure.

[0072] (9) The UE calculates the Random Access Radio Network Temporary Identifier (RA-RNTI) and listens for random access responses on the corresponding PDCCH resources, waiting for feedback from the fake base station.

[0073] (10) As an illegal satellite access network node, the LTE fake base station sends a random access response message (i.e., MSG2) on the PDSCH, which includes information such as Timing Advance (TA), Uplink Grant, Cell Radio Network Temporary Identifier (C-RNTI), and Preamble Index.

[0074] (11) The UE sends a Radio Resource Control Connection Request message (i.e., MSG3) on the Common Control Channel (CCCH), which includes: the establishment reason (such as mo-Signaling, mt-Access) and the Temporary Mobile Subscriber Identity (S-TMSI).

[0075] (12) The LTE fake base station sends a radio resource control connection establishment message (i.e., MSG4) through PDSCH, which includes: the allocated cell-radio network temporary identifier (C-RNTI), radio resource configuration, and time division duplex (TDD) configuration (if applicable).

[0076] (13) The UE determines whether the tracking area code of the LTE fake base station is in the local tracking area list. If it finds that the tracking area code of the LTE fake base station is not in the local tracking area list, it determines that "moving across tracking areas" and triggers the tracking area update process.

[0077] (14) The UE sends a radio resource control connection establishment completion message (i.e., MSG5) to the LTE pseudo base station, which encapsulates a tracking area update request message encoded by the UE, and the request message contains: the tracking area code of the currently camped cell and the EPS update type.

[0078] (15) The LTE fake base station intercepts the radio resource control connection establishment completion message, but instead of forwarding it to the centralized core network side according to the protocol, it forges an identity request message and encapsulates it in the downlink transmission message and sends it to the UE. Its purpose is to request sensitive information from the UE.

[0079] (16) The UE constructs an identity response message carrying sensitive information according to the standard protocol, encapsulates it in the uplink transmission message, and reports it to the LTE fake base station.

[0080] (17) After obtaining sensitive information, the LTE fake base station forges a tracking area update rejection message (containing the EPS mobility management reason value), encapsulates it in the downlink transmission message, and sends it to the UE.

[0081] (18) After receiving the tracking area update rejection message, the UE releases the radio resource control connection, returns to the radio resource control idle state, and searches for and camps on other cells again according to the reselection mechanism.

[0082] The entire attack process is imperceptible to the user and does not trigger any alarm mechanisms. Therefore, the above attack method has been widely verified in terrestrial LTE networks. Since the current IoT NTN system and LTE system are completely consistent in terms of NAS layer and mobility management process, the IoT NTN system fully inherits all the protocol vulnerabilities relied upon by LTE fake base station attacks. In addition, its wide coverage, centralized architecture, and low-capability terminals allow attackers to steal batch sensitive information from a large number of terminals simply by forging SIB1 broadcasts. The system lacks any protocol layer verification of the legitimacy of the tracking area code and a terminal-centralized core network collaborative defense mechanism.

[0083] Therefore, IoT NTN systems not only face the same risk of fake base station attacks as LTE systems, but also face security threats that are larger in scale, more concealed, and more difficult to defend against due to network characteristics.

[0084] In view of the above technical background, this application proposes an IoT NTN fake base station identification method, which is applied to... Figure 2 The communication system shown, such as Figure 2 As shown, the communication system 200 includes at least: an IoT NTN system 201 and a user equipment 202, wherein:

[0085] The IoT NTN system 201 is a network system composed of satellites, ground tracking and control stations, satellite access networks, and a centralized core network (i.e., only one mobility management module is deployed). For example, the IoT NTN system can be a high-orbit IoT NTN system, a low-orbit IoT NTN system, a medium-orbit IoT NTN system, etc.

[0086] User equipment 202 is a communication device on the terminal side and is the sole interface for a user to access the mobile communication network. The term "user equipment" as used herein includes, but is not limited to, devices connected via wired lines, such as via Public Switched Telephone Networks (PSTN), Digital Subscriber Line (DSL), digital cable, direct cable connection; and / or another data connection / network; and / or via a wireless interface, such as for cellular networks, Wireless Local Area Networks (WLAN), digital television networks such as DVB-H networks, satellite networks, AM-FM broadcast transmitters; and / or other user equipment configured to receive / transmit communication signals; and / or Internet of Things (IoT) devices. User equipment configured to communicate via a wireless interface may be referred to as a "wireless communication terminal," "wireless terminal," or "mobile terminal." Examples of mobile terminals include, but are not limited to, satellite or cellular phones; personal communications system (PCS) terminals that can combine cellular radiotelephony with data processing, fax, and data communication capabilities; PDAs that may include radiotelephones, pagers, Internet / intranet access, web browsers, notebooks, calendars, and / or Global Positioning System (GPS) receivers; and conventional laptop and / or handheld receivers or other electronic devices that include radiotelephone transceivers. User equipment can refer to access terminals, user units, user stations, mobile stations, mobile stations, remote stations, remote terminals, mobile devices, user terminals, terminals, wireless communication equipment, user agents, or user equipment. Access terminals can be cellular phones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, Personal Digital Assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, user equipment in 5G networks, or user equipment in future PLMNs, etc.

[0087] Optionally, the IoT NTN system 201 and user equipment 202 can be configured as follows: Figure 3 The interactive flowchart shown is used to interact with the system and identify fake base stations:

[0088] Step S1: After the user equipment 202 reselects from the original cell to the new cell, the user equipment 202 first obtains the first TAC of the new cell.

[0089] In step S2, when the user equipment 202 reselects back to the original cell from the new cell, the user equipment 202 sends a tracking area update request message to the IoT NTN system 201 in the original cell. The tracking area update request message includes at least: a target information element containing a first TAC and an Evolved Packet System Update Type information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC.

[0090] Step S3, the IoT NTN system 201 determines whether the new cell is an IoT NTN fake base station based on the tracking area update request message, and constructs a tracking area update acceptance message based on the determination result. The tracking area update acceptance message includes at least an Evolved Packet System Mobility Management Reason Information Element used to indicate whether the first TAC has passed the verification.

[0091] In step S4, the IoT NTN system 201 sends a corresponding tracking area update acceptance message to the user equipment.

[0092] In step S5, user equipment 202 determines whether the new cell is an IoT NTN fake base station based on the tracking area update message.

[0093] In this embodiment of the application, the aforementioned original cell is the serving cell in which the user equipment last successfully registered.

[0094] In the above-mentioned interactive process, through the introduction of the dual-end linkage mechanism of "back-off reporting and centralized core network collaborative verification", the user equipment carries the first TAC of the new cell in the tracking area update request message and is actively verified by the IoT NTN system. This prevents IoT NTN fake base stations from intercepting the tracking area update request message and forging the identity request message to steal the user's sensitive information. This completely switches the identity theft link in the IoT NTN fake base station attack chain, significantly reduces the risk of user privacy leakage, and thus achieves active identification of IoT NTN fake base stations without relying on physical layer features.

[0095] The functions of the user equipment and the IoT NTN system within the communication system provided in the embodiments of this application will be further described below.

[0096] After a user equipment (UE) reselects from its original cell to a new cell, in order to ensure that the UE can initiate a Tracking Area Update Request (TAC) message in a trusted and legitimate environment, and thus enable the centralized core network to determine whether the new cell is an IoT NTN fake base station under interference-free and verifiable conditions, this application proposes a "reselection backoff" strategy. That is, the UE actively reselects to a previously successfully registered legitimate cell, and sends a TAC message to the IoT NTN system through a legitimate satellite access network channel in that cell. This prevents IoT NTN fake base stations from intercepting or tampering with the cell, ensuring that the IoT NTN system can receive the genuine TAC.

[0097] As an optional implementation, the user equipment can determine the second TAC of the original cell from a local database, wherein the local database records cell information of multiple historically camped cells, and the cell information includes at least: TAC; and reselect the original cell from the new cell based on the second TAC.

[0098] Regarding the local database, after successfully completing the network attachment or tracking area update process, the user equipment typically stores the tracking area identifier of the currently legitimate cell and its associated parameters (including but not limited to TAC, frequency point, physical cell identifier, and public terrestrial mobile communication network) in a local database (such as a local non-volatile secure storage area), forming a trusted network anchor. This record is only updated after successful registration and remains unchanged in subsequent reselection processes, serving as a baseline for fallback verification when encountering suspicious cells.

[0099] Furthermore, the user equipment sends a tracking area update request message to the IoT NTN system within the original cell. This tracking area update request message differs from the tracking area update request message defined in the 3GPP protocol in the following ways:

[0100] (1) Modify the type value in the Evolution Group System Update Type Information Cell.

[0101] The Evolved Packet System Update Type (ETC) element is a 1-byte (8-bit) field defined in the 3GPP protocol, containing the lower 3 bits, used to indicate the type and intent of the user equipment (UE) initiating a Tracking Area Update (TAC) procedure. Currently, the standard values ​​for this field include 000, 001, 010, 011, 100, and 101. Therefore, this application can use undefined, unoccupied, and network-safely-ignored values ​​as the target valid values, such as 110 or 111, to instruct the IoT NTN system to identify whether a new cell is an IoT NTN fake base station via TAC. It should be noted that although 100 and 101 are reserved values, the 3GPP protocol explicitly requires the network to interpret them as "Tracking Area Update." If the terminal uses these values, they will be ignored or misused by the network.

[0102] (2) Add a target information cell containing the first TAC.

[0103] Specifically, the target information cell is an optional information cell, whose information element identifier can be set to 12, and the value length can be set to 6 bytes (48 bits in total). The specific value content is the first TAC of the new cell obtained by the user equipment.

[0104] (3) The last access registration tracking area identifier cell carries the second TAC of the original cell.

[0105] Furthermore, after receiving a tracking area update request message from a user equipment, the IoT NTN system can determine whether the new cell is an IoT NTN fake base station based on the tracking area update request message, and then send a corresponding tracking area update acceptance message back to the user equipment based on the determination result. The specific implementation process is as follows:

[0106] First, the IoT NTN system determines whether the first TAC exists in the list of legitimate TACs of the mobility management entity, and whether the geographical areas corresponding to the first TAC and the second TAC are adjacent. The list of legitimate TACs includes TACs of multiple legitimate cells.

[0107] If the first TAC does not exist in the list of valid TACs and / or the geographical areas corresponding to the first TAC and the second TAC are not adjacent, the new cell is determined to be an IoT NTN fake base station, and a tracking area update acceptance message carrying a first valid value is sent back to the user equipment.

[0108] If a list of valid TACs exists for the first TAC and the geographical areas corresponding to the first TAC and the second TAC are adjacent, it is determined that the new cell is not an IoT NTN fake base station, and a tracking area update acceptance message carrying a second valid value is sent back to the user equipment.

[0109] The above analysis principle is as follows: Since the centralized core network of the IoT NTN system deploys only one mobility management module, and this module pre-configures the TACs (Tracking Area Codes) for all legal cells planned by the operator, and associates each TAC with its corresponding satellite beam coverage, geographical adjacency, and public land mobile network identifier. Therefore, when the IoT NTN system receives a tracking area update request message, it can perform dual verification of the first TAC based on this database, wherein:

[0110] If any verification fails, the new cell is determined to be an IoT NTN fake base station. At this time, the IoT NTN system can send a Tracking Area Update Receive Message to the user equipment, and the cause value of the Evolved Packet System Mobility Management Cause Information Element carried in the message is the first valid value. The first valid value is used to indicate the first valid value of the first TAC that has failed verification.

[0111] If the dual verification is successful, the new cell is determined not to be an IoT NTN fake base station. At this time, the IoT NTN system can send a Tracking Area Update Acceptance Message to the user equipment, and the cause value of the Evolved Packet System Mobility Management Cause Information Element carried in the message is the second valid value. The second valid value is used to indicate that the first TAC has passed the verification.

[0112] It should be noted that if the double verification is successful, the cause value of the Evolved Packet System Mobility Management Cause Element in the Tracking Area Update Receive Message fed back by the IoT NTN system to the user equipment may not be the second valid value, but rather an existing cause value that indicates "success" or "no error" according to the existing 3GPP protocol specifications, such as 00011010.

[0113] In this application embodiment, the first valid value and the second valid value mentioned above can be set to any value between the reserved range "0x20 (i.e., 00100000) ~ 0x7F (i.e., 01111111)" which is not disclosed in the 3GPP protocol, such as 0x21 (i.e., 00100001), 0x25 (i.e., 00100101), 0x2A (i.e., 00101010), etc. This application embodiment does not impose specific restrictions on this.

[0114] Finally, after receiving the Tracking Area Update Acceptance Message from the IoT NTN system, the user equipment uses the cause value of the Evolved Packet System Mobility Management Cause Information Element carried in the Tracking Area Update Acceptance Message to perform the following mobility decisions: if the new cell is an IoT NTN pseudo base station, it continues to camp on the original cell and switches the Radio Resource Control (RRC) state to the RRC idle state; if the new cell is not an IoT NTN pseudo base station, it reselects from the original cell back to the new cell and enters the random access process.

[0115] Furthermore, the following will be through Figure 4 The flowchart of the signaling process for an IoT NTN fake base station attack illustrates the implementation process of the IoT NTN fake base station identification method provided in this application embodiment.

[0116] (1) After registering with the IoT NTN system, the UE returns to the radio resource control idle state and listens for the SIB1 message broadcast by the legitimate cell in the original cell where it is currently camped. By decoding the SIB1 message, the UE obtains the TAC of the current cell and records it in the local tracking area list for subsequent mobility management.

[0117] (2) When the IoT NTN fake base station is activated, it identifies the legitimate cell with weaker signal by measuring the reference signal reception power and reference signal reception quality of the neighboring legitimate cell and copies its physical cell identifier to avoid the abnormal detection of the UE's physical cell identifier. Then the IoT NTN fake base station increases its transmission power and broadcasts forged system messages (such as SIB1 message and MIB message).

[0118] (3) The UE sorts the neighboring cells according to the reselection parameters in the broadcast system message and selects the new cell with the best signal quality as the new cell for reselection.

[0119] (4) The UE leaves the original cell and synchronizes with the primary synchronization signal and secondary synchronization signal of the new cell to complete time and frequency synchronization and cell ID identification. Then, it receives and decodes MIB messages on the PBCH to obtain basic parameters such as SFN, downlink system bandwidth, and PHICH.

[0120] (5) The UE receives and decodes the SIB1 message on the PDSCH according to the scheduling information in the MIB message to obtain information such as the cell access parameters, first TAC, and frequency priority of the new cell.

[0121] (6) The UE records the first TAC of the new cell and reselects the original cell that was successfully registered last time based on the TAC of the legally registered cells recorded in the local database, and re-camps in the cell.

[0122] (7) The UE synchronizes the primary synchronization signal and secondary synchronization signal of the original cell to complete time-frequency synchronization and cell ID identification. Then, it receives and decodes MIB messages on the PBCH to obtain basic parameters such as SFN, downlink system bandwidth, and PHICH.

[0123] (8) The UE receives and decodes the SIB1 message on the PDSCH according to the scheduling information in the MIB message to obtain information such as the cell access parameters, second TAC, and frequency priority of the original cell.

[0124] (9) The UE continues to receive and decode SIB2 messages to obtain PRACH-related configurations, including: preamble format, PRACH resource location, number of preamble codes, power ramp step size, etc., to prepare for subsequent random access.

[0125] (10) The UE randomly selects an idle preamble from the available preamble sequences and prepares to send according to the PRACH time and frequency resource location configured in the SIB2 message.

[0126] (11) The UE sends the selected preamble on the PRACH to initiate the random access procedure.

[0127] (12) The UE calculates the random access RA-RNTI and listens for the random access response on the corresponding PDCCH resource, waiting for feedback from the IoTNTN pseudo base station.

[0128] (13) The satellite access network sends a random access response message (i.e., MSG2) to the UE, which includes information such as time advance, ULGrant, C-RNTI, and Preamble Index.

[0129] (14) The UE sends a Radio Resource Control Connection Request message (i.e., MSG3) to the satellite access network, which includes: the establishment reason (such as mo-Signaling, mt-Access) and S-TMSI.

[0130] (15) The satellite access network sends a radio resource control connection establishment message (i.e., MSG4) to the UE, which includes: the allocated C-RNTI, radio resource configuration, and TDD configuration.

[0131] (16) UE-encoded New Tracking Area Update Request Message. The New Tracking Area Update Request Message has the following characteristics: the type value in the Evolved Packet System Update Type information element is 110, which is used to identify whether the new cell is an IoT NTN fake base station through TAC; the target information element contains the first TAC, and the value of the target information element is the first TAC extracted from the SIB1 message of the new cell; the last access registration tracking area identifier information element contains the second TAC of the original cell, and the value of the last access registration tracking area identifier information element is the second TAC extracted from the SIB1 message of the original cell.

[0132] (17) The UE sends a Radio Resource Control Connection Establishment Complete Message (i.e., MSG5) to the satellite access network, which encapsulates a New Tracking Area Update Request Message encoded by the UE.

[0133] (18) The satellite access network sends an initial UE message to the centralized core network, which carries a new tracking area update request message.

[0134] (19) The centralized core network adds the following TAC verification process to the original location update verification process: First, if the type value of the Evolved Packet System Update Type information element carried in the new tracking area update request message is 110, decode and extract the first TAC of the new cell and the second TAC of the original cell respectively, and verify them according to the following rules:

[0135] If the first TAC of the new cell is not in the valid TAC database of the mobility management module of the centralized core network, it means that the first TAC has failed the verification.

[0136] If the first TAC of the new cell is in the valid TAC database of the mobility management module of the centralized core network, then it is necessary to further determine whether the geographical locations of the tracking areas corresponding to the first TAC and the second TAC planned by the operator are adjacent. If they are not adjacent, it means that the first TAC has failed the verification.

[0137] If the above scenarios are not present, it means that the first TAC passed the verification, indicating that no anomalies were found in the first TAC in the centralized core network.

[0138] (20) The centralized core network encapsulates the newly constructed tracking area update acceptance message in a downlink NAS transmission message and sends it to the satellite access network. The reason value in the Evolved Packet System Mobility Management Reason Element in the new tracking area update acceptance message includes the following two types:

[0139] If the first TAC fails the verification, the reason value can be filled in as "00100000" to indicate that the first TAC is abnormal;

[0140] If the first TAC passes the verification, the reason value can be filled in as "00100001" to indicate that the first tracking area is normal, or it can be filled in according to the existing reason values ​​specified in the 3GPP protocol.

[0141] (21) The satellite access network sends a downlink transmission message to the UE, wherein the message carries a new tracking area update acceptance message.

[0142] (22) The UE receives and decodes the new tracking area update acceptance message, and determines whether the new cell is an IoT NTN fake base station based on the decoded cause value, wherein:

[0143] If the new cell is an IoT NTN fake base station, the UE will no longer access the new cell, release the radio resource control connection, return to the radio resource control idle state, and continue to camp on the original cell;

[0144] If the new cell is not identified as an IoT NTN fake base station, the UE will reselect to camp on the new cell and perform random access procedures.

[0145] In the above embodiments, upon detecting a suspicious new cell, the UE does not directly access it but actively falls back to the verified legitimate original cell. Within this legitimate original cell, it sends a Tracking Area Update Request (TAC) message to the IoT NTN system. This message carries the TAC of both the original and new cells, as well as a cell indicating whether the new cell is an IoT NTN fake base station. The centralized core network of the IoT NTN system verifies suspicious activity based on a global TAC database and geographical proximity rules. It then feeds back the Evolved Packet System Mobility Management (EPM) reason value to the UE via the TAC update acceptance message, enabling the UE to autonomously determine and refuse access to the IoT NTN fake base station. This method breaks through the traditional passive defense model relying on NAS encryption or IMSI theft protection. For the first time, it constructs a closed-loop active identification mechanism in non-terrestrial IoT networks, encompassing "terminal initiation—core authority judgment—protocol signaling feedback." This mechanism requires no modification to terminal encryption capabilities and does not rely on sensitive user information, significantly improving the identification rate and robustness against IoT NTN fake base station attacks. It provides commercially viable, deployable, and scalable high-security access protection for wide-area IoT terminals.

[0146] According to an embodiment of this application, an IoT NTN fake base station identification method for user equipment is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0147] Figure 5 This is a flowchart illustrating an IoT NTN fake base station identification method according to an embodiment of this application, as shown below. Figure 5 As shown, the method includes the following steps:

[0148] Step S502: After the user equipment reselects from the original cell to the new cell, it obtains the first TAC of the new cell.

[0149] Step S504: When the user equipment reselects from the new cell back to the original cell, a tracking area update request message is sent to the IoT NTN system in the original cell. The tracking area update request message includes at least: a target information element containing a first TAC and an Evolved Packet System Update Type information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC.

[0150] Step S506: Receive a tracking area update acceptance message from the IoT NTN system, wherein the tracking area update acceptance message includes at least: an Evolved Packet System Mobility Management Reason Information Element indicating whether the first TAC has passed verification.

[0151] Step S508: Determine whether the new cell is an IoT NTN fake base station based on the tracking area update received message.

[0152] Optionally, the target information element mentioned above is an optional information element, whose information element identifier can be set to 12, and the value length can be set to 6 bytes (48 bits in total). The specific value content is the first TAC of the new cell obtained by the user equipment.

[0153] Optionally, the aforementioned IoT NTN system includes at least a satellite access network and a centralized core network, with the centralized core network including only one mobility management module.

[0154] In an exemplary embodiment, before sending a Tracking Area Update Request message to the IoT NTN system within the original cell, the user equipment may also determine the second TAC of the original cell based on a local database, wherein the local database records cell information of multiple historically camped cells, and the cell information includes at least: TAC; and based on the second TAC, reselect back to the original cell from the new cell.

[0155] Optionally, the aforementioned tracking area update request message may also include: a tracking area identifier element containing the last access registration information of the second TAC of the original cell.

[0156] In an exemplary embodiment, a user equipment may receive a tracking area update acceptance message from an IoT NTN system by means of the following method: when the type value in the Evolved Packet System Update Type Information Element is a target valid value, the user equipment may receive a tracking area update acceptance message from an IoT NTN system, wherein the reason value in the Evolved Packet System Mobility Management Reason Information Element includes: a first valid value indicating that the first TAC has failed verification and a second valid value indicating that the first TAC has passed verification.

[0157] Since the Evolved Packet System Update Type (EPS) element is a 1-byte (8-bit) field defined in the 3GPP protocol, used to indicate the type and intent of the user equipment initiating a Tracking Area Update (TAC) procedure, the standard values ​​for this field currently include 000, 001, 010, 011, 100, and 101. Therefore, this application can use undefined, unoccupied, and network-safely-ignorable values ​​as target valid values, such as 110 or 111, to instruct the IoT NTN system to identify whether a new cell is an IoT NTN fake base station target valid value via TAC.

[0158] In addition, the first valid value and the second valid value mentioned above can be set to any value between the reserved range "0x20 (i.e., 00100000) ~ 0x7F (i.e., 01111111)" which is not disclosed in the 3GPP protocol, such as 0x21 (i.e., 00100001), 0x25 (i.e., 00100101), 0x2A (i.e., 00101010), etc., and this application embodiment does not impose specific restrictions on this.

[0159] Optionally, the first TAC failing verification includes: the geographical areas corresponding to the first TAC and the second TAC are not adjacent, and the first TAC does not exist in the preset list of valid TACs, wherein the list of valid TACs includes TACs of multiple valid cells.

[0160] In an exemplary embodiment, if the new cell is an IoT NTN fake base station, the user equipment can continue to camp on the original cell and switch the radio resource control state to the radio resource control idle state; if the new cell is not an IoT NTN fake base station, the user equipment can reselect from the original cell back to the new cell.

[0161] According to an embodiment of this application, an IoT NTN fake base station identification method for IoT NTN systems is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0162] Figure 6 This is a flowchart illustrating an IoT NTN fake base station identification method according to an embodiment of this application, as shown below. Figure 6 As shown, the method includes the following steps:

[0163] Step S602: Receive a Tracking Area Update Request message sent by the user equipment in the original cell before reselection. The Tracking Area Update Request message includes at least: a target information element containing the first TAC of the new cell after reselection, and an Evolved Packet System Update Type information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC.

[0164] Step S604: Determine whether the new cell is an IoT NTN fake base station based on the tracking area update request message, and construct a tracking area update acceptance message based on the determination result. The tracking area update acceptance message includes at least an Evolved Packet System Mobility Management Reason Information Element used to indicate whether the first TAC has passed the verification.

[0165] Step S606: Send a tracking area update acceptance message to the user equipment.

[0166] Optionally, the aforementioned tracking area update request message may also include: a tracking area identifier element containing the last access registration information of the second TAC of the original cell.

[0167] In one exemplary embodiment, the IoT NTN system can construct a tracking area update reception message by means of the following method:

[0168] First, determine whether the first TAC exists in the preset list of valid TACs, and whether the geographical areas corresponding to the first TAC and the second TAC are adjacent. The list of valid TACs includes TACs of multiple valid cells.

[0169] If the first TAC does not exist in the list of valid TACs and / or the geographical areas corresponding to the first TAC and the second TAC are not adjacent, the new cell is determined to be an IoT NTN fake base station, and a tracking area update receiving message carrying a first valid value is constructed, wherein the first valid value is used to indicate the first valid value that the first TAC has failed verification.

[0170] If a list of valid TACs exists for the first TAC and the geographical areas corresponding to the first TAC and the second TAC are adjacent, it is determined that the new cell is not an IoT NTN fake base station, and a tracking area update receiving message carrying a second valid value is constructed, wherein the second valid value is used to indicate that the first TAC has passed the verification.

[0171] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0172] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0173] According to another aspect of the embodiments of this application, an IoT NTN fake base station identification device for implementing the IoT NTN fake base station identification method provided in the above embodiments is also provided, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0174] Figure 7 This is a structural block diagram of an optional IoT NTN fake base station identification device according to an embodiment of this application, such as... Figure 7 As shown, the IoT NTN fake base station identification device includes:

[0175] The acquisition module 72 is used to acquire the first TAC of the new cell after the user equipment reselects from the original cell where it is camped to the new cell.

[0176] The sending module 74 is used to send a tracking area update request message to the IoTNTN system within the original cell when the user equipment reselects from the new cell back to the original cell. The tracking area update request message includes at least: a target information element containing a first TAC and an Evolved Packet System Update Type information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC.

[0177] The first receiving module 76 is used to receive a tracking area update acceptance message fed back by the IoT NTN system, wherein the tracking area update acceptance message includes at least: an Evolved Packet System Mobility Management Reason Information Element used to indicate whether the first TAC has passed the verification;

[0178] The judgment module 78 is used to determine whether a new cell is an IoT NTN fake base station based on the tracking area update received message.

[0179] in addition, Figure 8 This is a structural block diagram of another optional IoT NTN fake base station identification device according to an embodiment of this application, such as... Figure 8 As shown, the IoT NTN fake base station identification device includes:

[0180] The second receiving module 82 is used to receive a Tracking Area Update Request message sent by the user equipment in the original cell before reselection. The Tracking Area Update Request message includes at least: a target information element containing the first TAC of the new cell after reselection, and an Evolved Packet System Update Type information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC.

[0181] The construction module 84 is used to determine whether the new cell is an IoT NTN fake base station based on the tracking area update request message, and to construct a tracking area update acceptance message based on the determination result. The tracking area update acceptance message includes at least an Evolved Packet System Mobility Management Reason Information Element used to indicate whether the first TAC has passed the verification.

[0182] Feedback module 86 is used to send tracking area update acceptance messages back to the user equipment.

[0183] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0184] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0185] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0186] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0187] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0188] According to another aspect of the embodiments of this application, a computer program product is also provided, the computer program product including a computer program / instructions containing program code for performing the method shown in the flowchart.

[0189] Optionally, the computer program executes the following steps during runtime: after the user equipment reselects from its original cell to a new cell, it obtains the first TAC of the new cell; if the user equipment reselects back to its original cell from the new cell, it sends a Tracking Area Update Request message to the IoT NTN system within the original cell, wherein the Tracking Area Update Request message includes at least: a target information element containing the first TAC and an EPC Update Type information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC; it receives a Tracking Area Update Acceptance message from the IoT NTN system, wherein the Tracking Area Update Acceptance message includes at least: an EPC Mobility Management Reason information element used to indicate whether the first TAC has passed verification; and it determines whether the new cell is an IoT NTN fake base station based on the Tracking Area Update Acceptance message.

[0190] Optionally, the computer program executes the following steps during runtime: receiving a Tracking Area Update Request message sent by the user equipment in the original cell before reselection, wherein the Tracking Area Update Request message includes at least: a target information element containing the first TAC of the new cell after reselection, and an EPC Update Type information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC; determining whether the new cell is an IoT NTN fake base station based on the Tracking Area Update Request message, and constructing a Tracking Area Update Acceptance message based on the determination result, wherein the Tracking Area Update Acceptance message includes at least: an EPC Mobility Management Reason information element used to indicate whether the first TAC has passed verification; and feeding back the Tracking Area Update Acceptance message to the user equipment.

[0191] As an alternative implementation, the above-mentioned electronic device may exist in the form of a mobile terminal, a computer terminal, or a similar computing device. Figure 9 A hardware block diagram of an electronic device for implementing an IoT NTN fake base station identification method is shown. Figure 9 As shown, the electronic device 90 may include one or more processors 902 (shown as 902a, 902b, ..., 902n in the figure) 902 (processor 902 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 904 for storing data, and a transmission device 906 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 9 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, electronic device 90 may also include components that are more... Figure 9 The more or fewer components shown, or having the same Figure 9 The different configurations shown.

[0192] It should be noted that the aforementioned one or more processors 902 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element of the electronic device 90. As involved in the embodiments of this application, the data processing circuit serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0193] The memory 904 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the IoTNTN fake base station identification method in this embodiment. The processor 902 executes various functional applications and data processing by running the software programs and modules stored in the memory 904, thereby implementing the aforementioned application vulnerability detection method. The memory 904 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 904 may further include memory remotely located relative to the processor 902, and these remote memories can be connected to the electronic device 90 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0194] The transmission device 906 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 90. In one example, the transmission device 906 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 906 may be a Radio Frequency (RF) module for wireless communication with the Internet.

[0195] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows users to interact with the user interface of the electronic device 90.

[0196] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0197] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for identifying fake IoT NTN base stations, characterized in that, include: After the user equipment reselects from the original cell where it is camped to the new cell, it obtains the first tracking area code (TAC) of the new cell; When the user equipment reselects back to the original cell from the new cell, a tracking area update request message is sent to the IoT NTN system in the original cell. The tracking area update request message includes at least: a target information element containing the first TAC and an Evolved Packet System Update Type information element for indicating whether the new cell is an IoT NTN fake base station identified by the TAC. The tracking area update acceptance message received by the IoT NTN system includes at least one Evolved Packet System Mobility Management Reason Element indicating whether the first TAC has passed verification. Based on the tracking area update reception message, determine whether the new cell is an IoT NTN fake base station.

2. The method according to claim 1, characterized in that, Before sending a tracking area update request message to the IoT NTN system within the original cell, the method further includes: The second TAC of the original cell is determined based on the local database, wherein the local database records cell information of multiple historically camped cells, and the cell information includes at least: TAC; Based on the second TAC, the cell is reselected from the new cell back to the original cell.

3. The method according to claim 1, characterized in that, The tracking area update request message also includes: a tracking area identifier element containing the last access registration information of the second TAC of the original cell, wherein receiving the tracking area update acceptance message fed back by the IoT NTN system includes: When the type value in the Evolved Packet System Update Type Information Element is a target valid value, the tracking area update acceptance message fed back by the IoT NTN system is received, wherein the reason value in the Evolved Packet System Mobility Management Reason Information Element includes: a first valid value indicating that the first TAC has failed verification, and a second valid value indicating that the first TAC has passed verification.

4. The method according to claim 3, characterized in that, The first TAC fails verification in the following ways: the geographical areas corresponding to the first TAC and the second TAC are not adjacent; or the first TAC does not exist in a preset list of valid TACs, wherein the list of valid TACs includes TACs of multiple valid cells.

5. The method according to claim 1, characterized in that, After determining whether the new cell is an IoT NTN fake base station based on the tracking area update reception message, the method further includes: If the new cell is an IoT NTN fake base station, it will continue to camp on the original cell and switch the radio resource control state to the radio resource control idle state; If the new cell is not an IoT NTN fake base station, the cell is reselected from the original cell back to the new cell.

6. The method according to claim 1, characterized in that, The IoT NTN system includes at least a satellite access network and a centralized core network, and the centralized core network includes only one mobility management module.

7. The method according to claim 3, characterized in that, The target effective value includes: 110 or 111.

8. A method for identifying fake IoT NTN base stations, characterized in that, include: The IoT NTN system receives a Tracking Area Update Request message sent by a user equipment in the original cell before reselection. The Tracking Area Update Request message includes at least: a target information element containing the first Tracking Area Code (TAC) of the new cell after reselection, and an Evolved Packet System Update Type (EPS) information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC. Based on the tracking area update request message, it is determined whether the new cell is an IoT NTN fake base station, and a tracking area update acceptance message is constructed based on the determination result. The tracking area update acceptance message includes at least an Evolved Packet System Mobility Management Reason Information Element for indicating whether the first TAC has passed the verification. The tracking area update acceptance message is sent back to the user equipment.

9. The method according to claim 8, characterized in that, The tracking area update request message also includes: a tracking area identifier element containing the last access registration tracking area of ​​the original cell's second TAC, wherein, based on the tracking area update request message, it is determined whether the new cell is an IoT NTN fake base station, and a tracking area update acceptance message is constructed based on the determination result, including: Determine whether the first TAC exists in a preset list of valid TACs, and whether the geographical regions corresponding to the first TAC and the second TAC are adjacent, wherein the list of valid TACs includes TACs of multiple valid cells; If the first TAC does not exist in the list of legitimate TACs and / or the geographical areas corresponding to the first TAC and the second TAC are not adjacent, the new cell is determined to be an IoT NTN fake base station, and a tracking area update receiving message carrying a first valid value is constructed, wherein the first valid value is used to indicate the first valid value that the first TAC has failed verification. If the first TAC exists in the list of legitimate TACs and the geographical regions corresponding to the first TAC and the second TAC are adjacent, it is determined that the new cell is not an IoT NTN fake base station, and a tracking area update acceptance message carrying a second valid value is constructed, wherein the second valid value is used to indicate that the first TAC has passed the verification.

10. A communication system, characterized in that, The communication system includes at least: user equipment and an Internet of Things (IoT) NTN system, wherein... The user equipment is configured to obtain the first Tracking Area Code (TAC) of the new cell after reselecting from the original cell where it is camped; and to send a Tracking Area Update Request message to the IoT NTN system within the original cell when reselecting back from the new cell. The Tracking Area Update Request message includes at least: a target information element containing the first TAC and an Evolved Packet System Update Type (EPS) information element used to indicate whether the new cell is an IoT NTN fake base station identified by the TAC. The IoT NTN system is used to determine whether the new cell is an IoTNTN fake base station based on the tracking area update request message, and to construct a tracking area update acceptance message based on the determination result. The tracking area update acceptance message includes at least: an Evolved Packet System Mobility Management Reason Information Element indicating whether the first TAC has passed the verification; and to feed back the tracking area update acceptance message to the user equipment. The user equipment is further configured to determine whether the new cell is a fake base station based on the tracking area update reception message.

Images