Security context processing method, communication device and storage medium

Abstract

The invention discloses a security context processing method, communication equipment and a storage medium. The security context processing method comprises the following steps: using a first security context in a first state; and entering a second state from the first state, and storing the first security context.

Description

Security context processing method, communication device and storage medium Technical Field

[0001] The present disclosure relates to the field of communication technologies, and in particular to a security context processing method, a communication device, and a storage medium. Background Art

[0002] Ambient-powered IoT devices are a type of IoT device. These devices can also be referred to as ambient IoT devices (ambient IoT). These devices may not have batteries or may have very small batteries. For example, these devices can be powered by collecting radio waves, light, motion, heat, or any other suitable power source. Applications of the ambient IoT can improve supply chain efficiency and sustainability, prevent counterfeiting, and more.

[0003] Summary of the Invention

[0004] Embodiments of the present disclosure provide a security context processing method, a communication device, and a storage medium.

[0005] According to a first aspect of an embodiment of the present disclosure, a security context processing method is provided, which is executed by a first device and includes: using a first security context in a first state; entering a second state from the first state and saving the first security context.

[0006] According to a second aspect of an embodiment of the present disclosure, a security context processing method is provided, which is executed by a second device. The method includes: a first device that saves a second state uses a first security context in a first state.

[0007] According to a third aspect of an embodiment of the present disclosure, a security context processing method is provided, which is executed by a third device and includes: receiving an eighth message; the eighth message is used to indicate at least one of the following: the first device re-enters the first state; the first device re-enters the first state and continues to use the first security context; and continues to use the first security context of the first device.

[0008] According to a fourth aspect of an embodiment of the present disclosure, a first device is provided, which includes: a processing module configured to use a first security context in a first state; and a storage module configured to enter a second state from the first state and save the first security context.

[0009] According to a fifth aspect of an embodiment of the present disclosure, a second device is provided, comprising: a storage module configured to save a first device in a second state using a first security context in a first state.

[0010] According to the sixth aspect of an embodiment of the present disclosure, a third device is provided, which includes: a receiving module configured to receive an eighth message; the eighth message is used to indicate at least one of the following: the first device re-enters the first state; the first device re-enters the first state and continues to use the first security context; continues to use the first security context of the first device.

[0011] According to the seventh aspect of an embodiment of the present disclosure, a communication device is provided, wherein the communication device includes: one or more processors; wherein the processor is used to call instructions so that the communication device executes the security context processing method provided by any technical solution of the aforementioned first to third aspects.

[0012] According to an eighth aspect of an embodiment of the present disclosure, a storage medium is provided, wherein the storage medium stores instructions, which, when the instructions are executed on a communication device, enable the communication device to execute the security context processing method provided by any of the first to third aspects.

[0013] The technical solution provided by the embodiment of the present disclosure saves the first security context when the first device enters the second state. The first security context can be continued to be used when the device enters the first state again subsequently, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[0014] It should be understood that the foregoing general description and the following detailed description are merely exemplary and explanatory and are not restrictive of the embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the embodiments of the present disclosure.

[0016] FIG1A is a schematic diagram showing an architecture of a communication system according to an exemplary embodiment;

[0017] FIG1B is a schematic diagram of an environmental IoT device according to an exemplary embodiment;

[0018] FIG1C is a schematic diagram showing a topology of an environmental IoT device according to an exemplary embodiment;

[0019] FIG1D is a schematic diagram showing a topology of IoT devices in an environment according to an exemplary embodiment;

[0020] FIG1E is a schematic diagram showing a topology of an environmental IoT device according to an exemplary embodiment;

[0021] FIG1F is a schematic diagram showing a topology of IoT devices in an environment according to an exemplary embodiment;

[0022] FIG1G is a schematic diagram showing an environment IoT device according to an exemplary embodiment;

[0023] FIG2A is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0024] FIG2B is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0025] FIG2C is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0026] FIG3A is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0027] FIG3B is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0028] FIG3C is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0029] FIG4A is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0030] FIG4B is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0031] FIG4C is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0032] FIG5 is a flow chart showing a method for processing a security context according to an exemplary embodiment;

[0033] FIG6A is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0034] FIG6B is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0035] FIG6C is a schematic diagram showing a flow chart of a security context processing method according to an exemplary embodiment;

[0036] FIG6D is a schematic flow chart showing a method for processing a security context according to an exemplary embodiment;

[0037] FIG7A is a schematic structural diagram of a terminal according to an exemplary embodiment;

[0038] FIG7B is a schematic diagram showing the structure of a master node according to an exemplary embodiment;

[0039] FIG7C is a schematic diagram showing the structure of a master node according to an exemplary embodiment;

[0040] FIG8A is a schematic structural diagram of a communication device according to an exemplary embodiment;

[0041] FIG8B is a schematic structural diagram of a chip according to an exemplary embodiment. DETAILED DESCRIPTION

[0042] Embodiments of the present disclosure provide a security context processing method and apparatus, a communication device, a communication system, and a storage medium.

[0043] In a first aspect, an embodiment of the present disclosure provides a security context processing method, which is executed by a first device and includes: using a first security context in a first state; entering a second state from the first state and saving the first security context.

[0044] In the above embodiment, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[0045] In combination with some embodiments of the first aspect, in some embodiments, before entering the second state from the first state, the method also includes: receiving a first message sent by the second device, where the first message is used to instruct the first device to enter the second state and save the first security context.

[0046] Based on the above solution, the second device saves the first security context when triggering the first device to enter the second state through the first message sending, thereby realizing the control of the state switching of the first device by the network side device.

[0047] In combination with some embodiments of the first aspect, in some embodiments, the first message includes at least one of the following: a first identifier, used to determine the first security context; a first indicator, used to indicate that the first security context is to be saved.

[0048] Based on the above solution, the specific content of the first message includes the first identifier, which can clearly indicate the first security context that needs to be saved when the first device enters the second state, and / or instructs the first security context to be saved through the first indicator.

[0049] In combination with some embodiments of the first aspect, in some embodiments, the first identifier includes at least one of the following: a context identifier, used to identify the first security context; a device identifier, used to identify the first device, and different first devices have different security contexts; a device group identifier, used to identify the device group to which the first device belongs, and different device groups use different security contexts.

[0050] The above solution defines a specific implementation method of the first identifier and has the characteristic of being simple to implement.

[0051] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: verifying the first message using the first security context; if the first message passes the verification, the first device enters the second state.

[0052] The above solution uses the first security context to perform security verification on the first message, thereby ensuring the security of information interaction between the first device and the second device.

[0053] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: before entering the second state, sending a second message to the second device; the second message is at least used to indicate whether the first device confirms entering the second state and saving the first security context.

[0054] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: using the first security context to protect the second message.

[0055] The above solution uses the first security context to protect the second message, thereby ensuring the security of the second message.

[0056] In combination with some embodiments of the first aspect, in some embodiments, the method includes: sending a third message to the second device, where the third message is used by the first device to request to enter the first state.

[0057] In the above solution, the first device can actively request the second device to return to the first state by sending the third message.

[0058] In combination with some embodiments of the first aspect, in some embodiments, the third message includes at least one of the following: a second identifier, used to indicate the security context used after the first device enters the first state; first verification information; first verification information, used by the second device to verify the third message.

[0059] The above scheme limits the information content contained in the third message, and can instruct the first device to return to the security context used in the first state through the second identifier and / or implement security verification of the third message through the first verification information, thereby ensuring communication security.

[0060] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: receiving a fourth message sent by the second device; the fourth message is used to indicate whether the first device is allowed to enter the first state.

[0061] In the above solution, the second device ultimately indicates via the fourth message whether to allow the first device to enter the first state, thereby enabling the second device to control the state switching of the first device.

[0062] Based on the above solution, the fourth message includes: an acceptance message for indicating that the first device is allowed to enter the first state, or a rejection message for indicating that the first device is not allowed to enter the first state.

[0063] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: receiving a fifth message sent by the second device; the fifth message is used to instruct the first device to enter the first state.

[0064] Based on the above solution, the fifth message includes at least one of the following:

[0065] A third identifier, used to identify a security context used by the first device to enter the first state;

[0066] The second verification information is used by the first device to verify the fifth message.

[0067] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: generating third verification information based on the first security context; and entering the first state when the third verification information matches the second verification information.

[0068] Based on the above solution, the security of information interaction between the first device and the second device is achieved by matching the third verification information with the second verification information.

[0069] In combination with some embodiments of the first aspect, in some embodiments, the method also includes: sending a sixth message to the second device; the sixth message is used to indicate whether the first device enters the first state, or the sixth message is used by the first device to prepare to enter the first state to the second device.

[0070] In the above solution, after receiving the fifth message, the first device will send a sixth message to the second device, and the sixth message will inform the second device whether it has entered the first state or is about to enter the first state, thereby realizing information interaction between the first device and the second device.

[0071] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes:

[0072] Receive a seventh message sent by the second device; the seventh message is used to indicate whether to agree or confirm that the first device enters the first state.

[0073] In the above solution, the first device will receive the seventh message from the second device, thereby achieving alignment of the state of the first device between the first device and the second device, so that the state of the first device recorded by the second device is accurate.

[0074] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: determining whether to maintain the first state of the first device according to the seventh message.

[0075] In the above scheme, the first device can determine again whether to maintain the first state of the first device after receiving the seventh message, thereby achieving alignment of the state of the first device between the first device and the second device, so that the state of the first device recorded by the second device is accurate.

[0076] In combination with some embodiments of the first aspect, in some embodiments, determining whether to maintain the first state of the first device is based on the seventh message, including: when the seventh message indicates that the first device is not approved to enter the first state, the first device returns to the second state, or, when the seventh message indicates that the first device is approved to enter the first state, the first device maintains the first state.

[0077] In combination with some embodiments of the first aspect, in some embodiments, the method also includes: verifying the seventh message using the security context indicated by the third identifier; determining whether to maintain the first state of the first device based on the seventh message, including: determining whether to maintain the first state of the first device based on the verified seventh message.

[0078] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: when the seventh message fails to pass verification, the first device returns to the second state or resends the sixth message to the second device.

[0079] In combination with some embodiments of the first aspect, in some embodiments, the first device is an environmental physical network IoT device.

[0080] The first device in the above solution is an environmental IoT device, which can further save the security of the environmental IoT device.

[0081] In a second aspect, an embodiment of the present disclosure provides a security context processing method, which is executed by a second device and includes: a first device that saves a second state uses a first security context in a first state.

[0082] In combination with some embodiments of the first aspect, in some embodiments, the method further includes: sending a first message to the first device, where the first message is used to instruct the first device to enter the second state and save the first security context.

[0083] In combination with some embodiments of the second aspect, in some embodiments, the first message includes at least one of the following: a first identifier, used to indicate the first security context; a first indicator, used to indicate that the first security context is to be saved.

[0084] In combination with some embodiments of the second aspect, in some embodiments, the first identifier includes at least one of the following: a context identifier, used to identify the first security context; a device identifier, used to identify the first device, and different first devices have different security contexts; a device group identifier, used to identify the device group to which the first device belongs, and different device groups use different security contexts.

[0085] In combination with some embodiments of the second aspect, in some embodiments, the method also includes: receiving a second message sent by the first device; the second message is at least used to indicate whether the first device confirms entering the second state and saving the first security context.

[0086] In combination with some embodiments of the second aspect, in some embodiments, the method further includes: when the second message passes the verification based on the first security context, recording that the first device enters the second state.

[0087] In combination with some embodiments of the second aspect, in some embodiments, the method further includes: receiving a third message sent by the first device, where the third message is used by the first device to request to enter the first state.

[0088] In combination with some embodiments of the second aspect, in some embodiments, the third message includes at least one of the following: a second identifier, used to indicate the security context used after the first device enters the first state; first verification information; the first verification information is used by the second device to verify the third message.

[0089] In combination with some embodiments of the second aspect, in some embodiments, the method also includes: generating fourth verification information based on the security context indicated by the second identifier; when the fourth verification information matches the first verification information, determining that the first device is allowed to enter the first state, recording the first device entering the first state and saving the security context indicated by the second identifier, or, when the fourth verification information does not match the first verification information, determining that the first device is not allowed to enter the first state.

[0090] In combination with some embodiments of the second aspect, in some embodiments, the method further includes: sending a fourth message to the first device; the fourth message is used to indicate whether the first device is allowed to enter the first state.

[0091] In combination with some embodiments of the second aspect, in some embodiments, the fourth message includes: an acceptance message for indicating that the first device is allowed to enter the first state, or a rejection message for indicating that the first device is not allowed to enter the first state.

[0092] In combination with some embodiments of the second aspect, in some embodiments, the method further includes: sending a fifth message to the first device; the fifth message is used to instruct the first device to enter the first state.

[0093] In combination with some embodiments of the second aspect, in some embodiments, the fifth message includes at least one of the following: a third identifier, used to identify the security context used by the first device to enter the first state; second verification information, used by the first device to verify the fifth message.

[0094] In combination with some embodiments of the second aspect, in some embodiments, the method also includes: receiving a sixth message sent by the first device; the sixth message is used to indicate whether the first device enters the first state, or the sixth message is used by the first device to prepare to enter the first state to the second device.

[0095] In combination with some embodiments of the second aspect, in some embodiments, the method also includes: verifying the verification result of the sixth message based on the security context indicated by the third identifier, and sending a seventh message to the first device; the seventh message is used to indicate whether to agree to the first device to enter the first state.

[0096] In combination with some embodiments of the second aspect, in some embodiments, when the sixth message passes verification, the seventh message indicates consent for the first device to enter the first state, or, when the sixth message fails verification, the seventh message indicates disagreement with the first device to enter the first state.

[0097] In combination with some embodiments of the second aspect, in some embodiments, the method also includes: sending an eighth message to the third device; the eighth message is used to indicate at least one of the following: the first device enters the first state; the first device re-enters the first state and continues to use the first security context; continues to use the first security context of the first device.

[0098] In combination with some embodiments of the second aspect, in some embodiments, the third device includes at least one of the following: a network function NF of the core network CN; an application function AF.

[0099] In a third aspect, an embodiment of the present disclosure provides a security context processing method, which is executed by a third device and includes: receiving an eighth message; the eighth message is used to indicate at least one of the following: the first device re-enters the first state; the first device re-enters the first state and continues to use the first security context; and continues to use the first security context of the first device.

[0100] In a fourth aspect, an embodiment of the present disclosure provides a first device, which includes: a processing module configured to use a first security context in a first state; and a storage module configured to enter a second state from the first state and save the first security context.

[0101] In a fifth aspect, an embodiment of the present disclosure provides a second device, which includes: a storage module configured to save the first device in the second state using the first security context in the first state.

[0102] In the sixth aspect, an embodiment of the present disclosure provides a third device, which includes: a receiving module configured to receive an eighth message; the eighth message is used to indicate at least one of the following: the first device re-enters the first state; the first device re-enters the first state and continues to use the first security context; continues to use the first security context of the first device.

[0103] In the seventh aspect, an embodiment of the present disclosure provides a communication device, the communication device including: one or more processors; wherein the processor is used to call instructions to enable the communication device to execute the security context processing method described in the optional implementation methods of the first to third aspects.

[0104] In an eighth aspect, an embodiment of the present disclosure provides a storage medium, wherein the storage medium stores instructions, which, when the instructions are executed on a communication device, enable the communication device to execute the security context processing method described in the optional implementation methods of the first to third aspects.

[0105] In a ninth aspect, embodiments of the present disclosure provide a program product. When executed by a communication device, the program product causes the communication device to perform the security context processing method described in the optional implementations of aspects 1 to 3. In a tenth aspect, embodiments of the present disclosure provide a computer program. When executed on a computer, the program program causes the computer to perform the security context processing method described in the optional implementations of aspects 1 to 3.

[0106] It is understandable that the above-mentioned terminals, network devices, communication systems, program products, and computer programs are all used to execute the methods provided by the embodiments of the present disclosure. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of the corresponding methods and will not be repeated here.

[0107] The present disclosure provides a security context processing method, communication device, communication system, and storage medium. In some embodiments, the terms "security context processing method," "information processing method," and "signal processing method" are interchangeable; "information indicating device," "information processing device," and "information transmission device" are interchangeable; and "communication system," "information processing system," and "information processing system" are interchangeable.

[0108] The embodiments of the present disclosure are not exhaustive and are merely illustrative of some embodiments, and are not intended to be a specific limitation on the scope of protection of the present disclosure. In the absence of contradiction, each step in a certain embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a certain embodiment can also be implemented as an independent embodiment, and the order of the steps in a certain embodiment can be arbitrarily exchanged. In addition, the optional implementation methods in a certain embodiment can be arbitrarily combined; in addition, the embodiments can be arbitrarily combined. For example, some or all steps of different embodiments can be arbitrarily combined, and a certain embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0109] In each embodiment of the present disclosure, unless otherwise specified or provided for by logic, the terms and / or descriptions between the embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form a new embodiment based on their inherent logical relationships.

[0110] The terms used in the embodiments of the present disclosure are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure.

[0111] In the embodiments of the present disclosure, unless otherwise specified, elements expressed in the singular, such as "a", "an", "the", "above", "the", "the", etc., may mean "one and only one", or "one or more", "at least one", etc. For example, when articles such as "a", "an", "the" in English are used in translation, the noun following the article may be understood as a singular expression or a plural expression.

[0112] In the embodiments of the present disclosure, “plurality” refers to two or more.

[0113] In some embodiments, the terms "at least one," "one or more," "a plurality of," "multiple," etc. may be used interchangeably.

[0114] In some embodiments, descriptions such as "at least one of A and B," "A and / or B," "in one case A, in another case B," or "in one case A, in another case B" may include the following technical solutions depending on the situation: in some embodiments, A (A is executed independently of B); in some embodiments, B (B is executed independently of A); in some embodiments, execution is selected from A and B (A and B are selectively executed); and in some embodiments, A and B (both A and B are executed). The same applies when there are more branches such as A, B, and C.

[0115] In some embodiments, "A or B" and other descriptions may include the following technical solutions depending on the situation: in some embodiments, A (A is executed independently of B); in some embodiments, B (B is executed independently of A); in some embodiments, execution is selected from A and B (A and B are selectively executed). The above is also applicable when there are more branches such as A, B, C, etc.

[0116] The prefixes such as "first" and "second" in the embodiments of the present disclosure are only used to distinguish different description objects and do not constitute any restriction on the position, order, priority, quantity or content of the description objects. For the statement of the description object, please refer to the description in the context of the claims or embodiments, and no unnecessary restriction should be constituted due to the use of prefixes. For example, if the description object is a "field", the ordinal number before the "field" in the "first field" and the "second field" does not limit the position or order between the "fields". "First" and "second" do not limit whether the "fields" they modify are in the same message, nor do they limit the order of the "first field" and the "second field". For another example, if the description object is a "level", the ordinal number before the "level" in the "first level" and the "second level" does not limit the priority between the "levels". For another example, the number of description objects is not limited by the ordinal number and can be one or more. Taking "first device" as an example, the number of "devices" can be one or more. In addition, the objects modified by different prefixes can be the same or different. For example, if the description object is "device", then the "first device" and the "second device" can be the same device or different devices, and their types can be the same or different; for another example, if the description object is "information", then the "first information" and the "second information" can be the same information or different information, and their contents can be the same or different.

[0117] In some embodiments, “including A,” “comprising A,” “used to indicate A,” and “carrying A” can be interpreted as directly carrying A or indirectly indicating A.

[0118] In some embodiments, terms such as "...", "determine...", "in the case of...", "at the time of...", "when...", "if...", "if...", etc. can be used interchangeably.

[0119] In some embodiments, terms such as "greater than", "greater than or equal to", "not less than", "more than", "more than or equal to", "not less than", "higher than", "higher than or equal to", "not less than", and "above" can be replaced with each other, and terms such as "less than", "less than or equal to", "not greater than", "less than", "less than or equal to", "not more than", "lower than", "lower than or equal to", "not higher than", and "below" can be replaced with each other.

[0120] In some embodiments, devices, etc. can be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. Terms such as "device", "equipment", "device", "circuit", "network element", "node", "function", "unit", "section", "system", "network", "chip", "chip system", "entity", and "subject" can be used interchangeably.

[0121] In some embodiments, "network" can be interpreted as devices included in the network (eg, access network equipment, core network equipment, etc.).

[0122] In some embodiments, the terms "access network device (AN device)", "radio access network device (RAN device)", "base station (BS)", "radio base station" "fixed station", "node", "access point", "transmission point (TP)", "reception point (RP)", "transmission / reception point (TRP)", "panel", "antenna panel", "antenna array", "cell", "macro cell", "small cell", "femto cell", "pico cell", "sector", "cell group", "serving cell", "carrier", "component carrier", "bandwidth part (BWP)" and the like may be used interchangeably.

[0123] In some embodiments, the terms "terminal", "terminal device", "user equipment (UE)", "user terminal", "mobile station (MS)", "mobile terminal (MT)", subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, etc. can be used interchangeably.

[0124] In some embodiments, the access network device, the core network device, or the network device can be replaced by a terminal. For example, the various embodiments of the present disclosure can also be applied to a structure in which the communication between the access network device, the core network device, or the network device and the terminal is replaced by communication between multiple terminals (for example, device-to-device (D2D), vehicle-to-everything (V2X), etc.). In this case, it is also possible to set the structure in which the terminal has all or part of the functions of the access network device. In addition, terms such as "uplink" and "downlink" can also be replaced by terms corresponding to communication between terminals (for example, "side"). For example, uplink channels, downlink channels, etc. can be replaced by side channels, and uplinks, downlinks, etc. can be replaced by side links.

[0125] In some embodiments, the terminal may be replaced by an access network device, a core network device, or a network device. In this case, the access network device, the core network device, or the network device may have a structure that has all or part of the functions of the terminal.

[0126] In some embodiments, obtaining data, information, etc. may comply with the laws and regulations of the country where the data is obtained.

[0127] In some embodiments, data, information, etc. may be obtained with the user's consent.

[0128] In addition, each element, each row, or each column in the table of the embodiment of the present disclosure can be implemented as an independent embodiment, and the combination of any elements, any rows, and any columns can also be implemented as an independent embodiment.

[0129] FIG1A is a schematic diagram showing the architecture of a communication system according to an embodiment of the present disclosure.

[0130] As shown in Figure 1A, a communication system 100 includes a terminal 101 and a network device 102. The network device 102 may include an access network device, a core network device and / or an application function (AF).

[0131] In some embodiments, the terminal 101 includes, for example, at least one of a mobile phone, a wearable device, an Internet of Things device, a car with communication capabilities, a smart car, a tablet computer, a computer with wireless transceiver capabilities, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control, a wireless terminal device in self-driving, a wireless terminal device in remote medical surgery, a wireless terminal device in a smart grid, a wireless terminal device in transportation safety, a wireless terminal device in a smart city, and a wireless terminal device in a smart home, but is not limited thereto. In some embodiments, the terminal is also referred to as a user equipment (UE).

[0132] In some embodiments, physical network devices may include, but are not limited to, ambient IoT devices.

[0133] In some embodiments, the access network device may be, for example, a node or device that accesses a terminal to a wireless network. The access network device may include an evolved NodeB (eNB), a next generation evolved NodeB (ng-eNB), a next generation NodeB (gNB), a node B (NB), a home node B (HNB), a home evolved nodeB (HeNB), a wireless backhaul device, a radio network controller (RNC), a base station controller (BSC), a base transceiver station (BTS), a base band unit (BBU), a mobile switching center, a base station in a 6G communication system, an open base station (Open RAN), a cloud base station (Cloud RAN), a base station in other communication systems, and at least one of an access node in a Wi-Fi system, but is not limited thereto.

[0134] In some embodiments, the technical solution of the present disclosure can be applied to the Open RAN architecture. In this case, the interfaces between or within the access network devices involved in the embodiments of the present disclosure can be transformed into internal interfaces of the Open RAN, and the processes and information interactions between these internal interfaces can be implemented through software or programs.

[0135] In some embodiments, the access network device can be composed of a centralized unit (CU) and a distributed unit (DU), where the CU can also be called a control unit. The CU-DU structure can be used to split the protocol layer of the access network device, with the functions of some protocol layers centrally controlled by the CU, and the functions of the remaining part or all of the protocol layers distributed in the DU, which is centrally controlled by the CU, but is not limited to this.

[0136] In some embodiments, the core network device may be a single device including a first network element, or may be a plurality of devices or a group of devices, each including a first network element. The network element may be virtual or physical. The core network may include, for example, at least one of an Evolved Packet Core (EPC), a 5G Core Network (5GCN), and a Next Generation Core (NGC).

[0137] The application server may include an application function located in the core network and / or an application server provided by an application service provider.

[0138] It can be understood that the communication system described in the embodiment of the present disclosure is for the purpose of more clearly illustrating the technical solution of the embodiment of the present disclosure, and does not constitute a limitation on the technical solution provided by the embodiment of the present disclosure. Ordinary technicians in this field can know that with the evolution of the system architecture and the emergence of new business scenarios, the technical solution provided by the embodiment of the present disclosure is also applicable to similar technical problems.

[0139] The following embodiments of the present disclosure may be applied to the communication system 100 shown in FIG1A , or a portion thereof, but are not limited thereto. The entities shown in FIG1A are illustrative only. The communication system may include all or part of the entities shown in FIG1A , or may include other entities other than those shown in FIG1A . The number and form of the entities may be arbitrary. The connection relationship between the entities is illustrative only. The entities may be connected or disconnected, and the connection may be in any manner, including direct or indirect, wired or wireless.

[0140] The embodiments of the present disclosure can be applied to Long Term Evolution (LTE), LTE-Advanced (LTE-A), LTE-Beyond (LTE-B), SUPER 3G, IMT-Advanced, 4th generation mobile communication system (4G), 5th generation mobile communication system (5G), 5G new radio (NR), future radio access (FRA), new radio access technology (RAT), new radio (NR), new radio access (NX), future generation radio access (FX), Global System for Mobile communications (GSM (registered trademark)), CDMA2000, Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi (registered trademark)), IEEE 802.16 (WiMAX (registered trademark)), IEEE 802.20, Ultra-WideBand (UWB), Bluetooth (registered trademark), Public Land Mobile Network (PLMN) networks, Device-to-Device (D2D) systems, Machine-to-Machine (M2M) systems, Internet of Things (IoT) systems, Vehicle-to-Everything (V2X), systems utilizing other security context processing methods, and next-generation systems based on and extending these systems. Furthermore, multiple systems may be combined (for example, a combination of LTE or LTE-A with 5G).

[0141] There are many applications for ambient-powered IoT devices.

[0142] For example, ambient energy devices can be used in many smart city projects, such as providing data needed for advanced transportation and smart city initiatives. A network device sends a physical layer signal to an ambient IoT device, and the device that triggers the reflected signal back from the ambient IoT device is called an anchor point for the ambient IoT device's reader.

[0143] It is worth noting that ambient IoT devices are devices that use the backscatter transmission mechanism for wireless communication. In specific implementations, other devices can also use the backscatter transmission mechanism for wireless communication.

[0144] The anchor point or reader for an ambient IoT device can be a network node in a wireless communication network, such as an access network device, a relay node (or intermediate node), or a terminal. As shown in Figure 1B, the reader sends an excitation signal to the ambient IoT device. The ambient IoT device then receives energy and can send a backscattered signal back to the reader. The excitation signal can be any wireless signal.

[0145] Backscatter transmission network topologies can include one of the following:

[0146] Topology 1: As shown in Figure 1C, ambient IoT devices and access network devices communicate directly. This communication can be one-way or two-way. If two-way communication is used, the terminal can transmit data in both uplink (UL) and downlink (DL).

[0147] Topology 2: As shown in Figure 1D, the ambient IoT device communicates directly with the intermediate node. The ambient IoT device can communicate with the intermediate node in either a one-way or two-way manner. The intermediate node can be located between the ambient IoT device and the base station. The intermediate node can be a relay, an integrated access backhaul (IAB) node, a user equipment (UE), a repeater (RP), or any other device capable of facilitating communication between the ambient IoT device and the access network equipment.

[0148] Topology 3: As shown in Figure 1E, an auxiliary node is introduced between the ambient IoT device and the access network device. The ambient IoT device can communicate directly with the access network device in the uplink, and the ambient IoT device communicates with the access network device in the downlink through the auxiliary node. The auxiliary node can be a relay, an integrated access backhaul (IAB) node, a terminal, or a network controlled repeater (NCR).

[0149] Topology 4: As shown in Figure 1F, the IoT device and the terminal directly receive and transmit data on the downlink and uplink. The UE collects data and forwards it to the network.

[0150] In all of the above topologies, ambient IoT devices need to transmit and report perceived data to the 5GC or application server. To protect data transmission, security contexts must be generated and maintained, which is very power-intensive for these IoT devices with limited battery and storage. Therefore, a more efficient and energy-efficient security context management approach needs to be developed and applied to ambient IoT devices to protect transmitted data.

[0151] As shown in Figure 1G, devices that use the backscatter transmission mechanism for wireless communication can be divided into three types:

[0152] Device A: has no energy storage, cannot generate or amplify signals independently, and can only perform backscatter transmission.

[0153] Device B: Has energy storage, cannot generate signals independently, and can only perform backscatter transmission. The use of stored energy can include amplification of the backscattered signal.

[0154] Device C: has energy storage and can independently generate signals, that is, it has active radio frequency (RF) components for transmission.

[0155] FIG2A is an interactive diagram illustrating a security context processing method according to an embodiment of the present disclosure. As shown in FIG2A , the present disclosure embodiment relates to a security context processing method for a communication system 100, the method comprising:

[0156] S2101: The first device uses a first security context in a first state.

[0157] In some embodiments, the first device may be the aforementioned environmental IoT device. For example, the environmental IoT device may be any one of the environmental IoT devices shown in FIG. 1C to FIG. 1F .

[0158] In some embodiments, the first state may be any state in which the first device is in wireless communication.

[0159] In some embodiments, the first state may include but is not limited to an RRC connected state.

[0160] In some embodiments, the first state may be an activated state of the first device. In the activated state, the first device may perform wireless communication with other devices.

[0161] In some embodiments, the first security context may be a security context used by the first device when performing wireless communication.

[0162] In some embodiments, the first security context may be used to securely protect wireless communication messages.

[0163] Exemplarily, the security includes but is not limited to at least one of the following:

[0164] Security protection against tampering, such as integrity protection and / or digital signatures;

[0165] Encryption protection,

[0166] Scrambled.

[0167] In some implementations, the first security context may include, but is not limited to, at least one of the following:

[0168] Key;

[0169] Parameters for key derivation;

[0170] The algorithm identifier of the security algorithm.

[0171] Of course, the above is merely an example of the first security context, but the specific implementation is not limited to the above example.

[0172] S2102: The second device sends a first message.

[0173] In some embodiments, the second device sends the first message to the first device.

[0174] In some embodiments, the second device unicasts the first message to the first device.

[0175] In some embodiments, the second device multicasts the first message to the device group to which the first device belongs.

[0176] In some embodiments, the second device broadcasts the first message.

[0177] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[0178] In some embodiments, the second device may include at least one of the following:

[0179] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[0180] Intermediate nodes can be other communication devices besides environmental IoT devices;

[0181] Auxiliary nodes, etc.

[0182] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0183] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[0184] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0185] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[0186] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[0187] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[0188] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[0189] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[0190] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[0191] RRC message;

[0192] Media Access Control (MAC) MAC layer messages;

[0193] Physical downlink control information (DCI);

[0194] PC5 news.

[0195] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[0196] A first identifier, used to determine a first security context;

[0197] The first indicator is used to indicate saving the first security context.

[0198] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[0199] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[0200] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[0201] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[0202] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[0203] In some embodiments, the first identifier includes at least one of the following:

[0204] A context identifier, used to identify the first security context;

[0205] A device identifier is used to identify the first device. The device identifier corresponds to the first device and identifies a first security context used by the first device.

[0206] The device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context. In this case, the device group identifier may indicate the security context that needs to be saved when entering the second state.

[0207] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[0208] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[0209] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[0210] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[0211] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[0212] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[0213] In some embodiments, the second device sends the first message through an RRC link of the first device.

[0214] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[0215] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[0216] In some embodiments, the first message may be a message secured using a first security context.

[0217] In other embodiments, the first message may also be a message that is not protected by the first security context.

[0218] S2103: The first device enters the second state and saves the first security context.

[0219] In some embodiments, the first device exits the first state to enter the second state and saves the first security context.

[0220] In some embodiments, the power consumption of the first device in the first state is higher than the power consumption of the first device in the second state.

[0221] In some embodiments, the first device enters the second state based on the first message.

[0222] In some embodiments, the first device may enter the second state upon expiration of a timer maintaining the first state.

[0223] S2104: The first device sends a second message.

[0224] In some embodiments, the first device sends the second message to the second device.

[0225] In some embodiments, the first device sends the second message to the second device before entering the second state or when entering the second state.

[0226] In some embodiments, the first device sends a second message to the second device based on the first message.

[0227] In some embodiments, the second message is used to indicate whether the first device enters the second state.

[0228] In some embodiments, the second message is used to indicate whether the first device saves the first security context.

[0229] In some embodiments, the second message is used to instruct the first device to enter the second state and whether to save the first security context.

[0230] In some embodiments, the second message may be used to enable the first device to enter the second state and save the first security context.

[0231] Exemplarily, the second message may be an acknowledgement character (ACK), used to indicate that the first device has entered the second state and / or has saved the first security context.

[0232] In another exemplary embodiment, the second message may be a non-acknowledgement character (NACK) message, which is used to indicate that the first device has not entered the second state and / or has not saved the first security context. For example, the NACK may indicate that the first device has entered the second state but has not saved the first security context.

[0233] In some embodiments, the second message may be a message secured using the first security context.

[0234] In other embodiments, the second message may also be a message that is not protected by the first security context.

[0235] S2105: The first device sends a third message.

[0236] In some embodiments, the first device sends a third message to the second device.

[0237] In some embodiments, the third message is used by the first device to request to enter the first state.

[0238] Exemplarily, the third message may include but is not limited to an RRC connection request message and / or an RRC connection recovery request message.

[0239] In some embodiments, the third message includes at least one of the following:

[0240] A second identifier, used to indicate a security context used by the first device after entering the first state;

[0241] First verification information: The first verification information is used by the second device to verify the third message.

[0242] In some embodiments, the second identifier may be an identifier of the same type as the first identifier. If the first device continues to use the first security context after returning to the first state, the second identifier may be the same as the first identifier.

[0243] In one embodiment, the first verification information may include but is not limited to a verification code. By carrying the first verification information, secure verification of the third message can be achieved between the first device and the second device, thereby improving the security of the third message.

[0244] In some embodiments, the first verification information may be generated using the security context corresponding to the second identifier.

[0245] Exemplarily, the verification code is obtained by signing other message contents of the third message using the security context corresponding to the second identifier.

[0246] As another example, the first verification information is obtained by security processing of the security context corresponding to the second identifier.

[0247] Exemplarily, the second identifier and the first verification information may be carried in plain text in the third message.

[0248] In some embodiments, the first verification information is optional content of the third message.

[0249] In some embodiments, the third message may be a message secured using the first security context.

[0250] In other embodiments, the third message may also be a message that is not protected by the first security context.

[0251] In some embodiments, the first device may be device C as shown in Figure 1G , which can store some power and send a third message to the second device. For example, if a timer on the first device expires, the first device reaches the time to enter the first state and proactively sends the third message to the second device. This timer may be the timer of the first device in the second state. The duration of this timer may be configured by the second message or agreed upon by the protocol.

[0252] S2106: The second device sends a fourth message.

[0253] In some embodiments, the second device sends a fourth message to the first device.

[0254] In some embodiments, the second device sends a response message to the third message to the first device.

[0255] In some embodiments, the fourth message is used to indicate whether the first device is allowed to enter the first state.

[0256] In some embodiments, the fourth message includes an acceptance message, wherein the acceptance message is used to indicate that the first device is allowed to enter the first state.

[0257] In some embodiments, the fourth message includes a rejection message, wherein the rejection message is used to indicate that the first device is not allowed to enter the first state.

[0258] In some embodiments, after the first verification information is verified, the second device sends an acceptance message to the first device.

[0259] In some embodiments, the first verification information is verified and the first device is allowed to return to the first state, and the second device sends an acceptance message to the first device.

[0260] In some embodiments, if the first verification information fails to pass verification and / or the first device is not allowed to return to the first state, the second device sends a rejection message to the first device.

[0261] For example, the second device may determine whether to allow the first device to return to the first state based on the current load rate of the cell and / or the tolerable delay of the communication service requested by the first device.

[0262] In some embodiments, the second device locally generates fourth verification information based on the security context of the second identifier.

[0263] In some embodiments, if the fourth verification information successfully matches the first verification information, the first verification information passes verification.

[0264] In some embodiments, if the fourth verification information and the first verification information do not match successfully, the first verification information fails verification.

[0265] Optionally, when the fourth verification information matches the first verification information, it is determined that the first device is allowed to enter the first state, the entry of the first device into the first state is recorded, and the security context indicated by the second identifier is saved.

[0266] Optionally, when the fourth verification information does not match the first verification information, it is determined that the first device is not allowed to enter the first state.

[0267] In some embodiments, if the third message does not carry the first verification information, the second device can skip the above-mentioned step of verifying the first verification information and determine whether to allow the first device to enter the first state based solely on the load rate on the network side and / or the urgency of the business requesting to enter the first state.

[0268] In some embodiments, the fourth message may be a message secured using the first security context.

[0269] In other embodiments, the fourth message may also be a message that is not protected by the first security context.

[0270] S2107: The first device enters the first state and reuses or continues to use the saved first security context.

[0271] In some embodiments, when the fourth message is an acceptance message, the first device enters the first state and resumes or continues to use the first security context.

[0272] S2108: The first device is maintained in the second state. It should be noted that S2108 and S2107 are parallel steps and are not executed at the same time.

[0273] In some embodiments, if the fourth message is a rejection message, the first device remains in the second state.

[0274] S2109: The second device sends an eighth message to the third device.

[0275] In some embodiments, the third device is a core network device.

[0276] In some embodiments, the third device includes at least one of the following:

[0277] Network functions NF of the core network CN;

[0278] Application function AF.

[0279] The CN NF may include but is not limited to: Access Management Function (AMF), Location Management Function (LMF), Session Management Function (SMF) and / or User Plane Function (UPF).

[0280] The AF may include but is not limited to an application server.

[0281] In some embodiments, the second device sends an eighth message to the third device when the first device enters the second state.

[0282] In some embodiments, the eighth message is used to indicate at least one of the following:

[0283] The first device enters a first state;

[0284] The first device re-enters the first state and continues to use the first security context;

[0285] The first security context of the first device continues to be used.

[0286] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the second device.

[0287] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the access network device.

[0288] In some embodiments, the first security context may be used for security protection of communications between the first device and the third device.

[0289] For example, the first security context may be used for security protection of Non Access Stratum (NAS) messages between the first device and the core network device.

[0290] In some embodiments, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[0291] FIG2B is an interactive diagram illustrating a security context processing method according to an embodiment of the present disclosure. As shown in FIG2A , the present disclosure embodiment relates to a security context processing method for a communication system 100, the method comprising:

[0292] S2201: The first device uses a first security context in a first state.

[0293] In some embodiments, the first device may be the aforementioned environmental IoT device. For example, the environmental IoT device may be any one of the environmental IoT devices shown in FIG. 1C to FIG. 1F .

[0294] In some embodiments, the first state may be any state in which the first device is in wireless communication.

[0295] In some embodiments, the first state may include but is not limited to an RRC connected state.

[0296] In some embodiments, the first state may be an activated state of the first device. In the activated state, the first device may perform wireless communication with other devices.

[0297] In some embodiments, the first security context may be a security context used by the first device when performing wireless communication.

[0298] In some embodiments, the first security context may be used to securely protect wireless communication messages.

[0299] Exemplarily, the security includes but is not limited to at least one of the following:

[0300] Security protection against tampering, such as integrity protection and / or digital signatures;

[0301] Encryption protection,

[0302] Scrambled.

[0303] In some implementations, the first security context may include, but is not limited to, at least one of the following:

[0304] Key;

[0305] Parameters for key derivation;

[0306] The algorithm identifier of the security algorithm.

[0307] Of course, the above is merely an example of the first security context, but the specific implementation is not limited to the above example.

[0308] S2202: The second device sends a first message.

[0309] In some embodiments, the second device sends the first message to the first device.

[0310] In some embodiments, the second device unicasts the first message to the first device.

[0311] In some embodiments, the second device multicasts the first message to the device group to which the first device belongs.

[0312] In some embodiments, the second device broadcasts the first message.

[0313] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[0314] In some embodiments, the second device may include at least one of the following:

[0315] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[0316] Intermediate nodes can be other communication devices besides environmental IoT devices;

[0317] Auxiliary nodes, etc.

[0318] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0319] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[0320] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0321] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[0322] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[0323] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[0324] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[0325] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[0326] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[0327] RRC message;

[0328] Media Access Control (MAC) MAC layer messages;

[0329] Physical downlink control information (DCI);

[0330] PC5 news.

[0331] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[0332] A first identifier, used to determine a first security context;

[0333] The first indicator is used to indicate saving the first security context.

[0334] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[0335] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[0336] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[0337] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[0338] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[0339] In some embodiments, the first identifier includes at least one of the following:

[0340] A context identifier, used to identify the first security context;

[0341] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[0342] The device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context. In this case, the device group identifier may indicate the security context that needs to be saved when entering the second state.

[0343] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[0344] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[0345] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[0346] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[0347] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[0348] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[0349] In some embodiments, the second device sends the first message through an RRC link of the first device.

[0350] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[0351] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[0352] S2203: The first device enters the second state and saves the first security context.

[0353] In some embodiments, the first device exits the first state to enter the second state and saves the first security context.

[0354] S2204: The first device sends a second message.

[0355] In some embodiments, the first device sends the second message to the second device.

[0356] In some embodiments, the first device sends the second message to the second device before entering the second state or when entering the second state.

[0357] In some embodiments, the first device sends a second message to the second device based on the first message.

[0358] In some embodiments, the second message is used to indicate whether the first device enters the second state.

[0359] In some embodiments, the second message is used to indicate whether the first device saves the first security context.

[0360] In some embodiments, the second message is used to instruct the first device to enter the second state and whether to save the first security context.

[0361] In some embodiments, the second message may be used to enable the first device to enter the second state and save the first security context.

[0362] Exemplarily, the second message may be an acknowledgement character (ACK), used to indicate that the first device has entered the second state and / or has saved the first security context.

[0363] In another exemplary embodiment, the second message may be a non-acknowledgement character (NACK) message, which is used to indicate that the first device has not entered the second state and / or has not saved the first security context. For example, the NACK may indicate that the first device has entered the second state but has not saved the first security context.

[0364] In some embodiments, the second message may be a message secured using the first security context.

[0365] In other embodiments, the second message may also be a message that is not protected by the first security context.

[0366] S2205: The second device sends a fifth message.

[0367] In some embodiments, the second device sends a fifth message to the first device.

[0368] In some embodiments, the fifth message is used to instruct the first device to enter the first state.

[0369] In some embodiments, the fifth message may be a broadcast message, a multicast message, or a unicast message.

[0370] In some embodiments, the fifth message may include, but is not limited to, a paging message.

[0371] In some embodiments, the fifth message includes at least one of the following:

[0372] A third identifier, used to identify a security context used by the first device to enter the first state;

[0373] The second verification information is used by the first device to verify the fifth message.

[0374] If the second device instructs the first device to use the first security context, the third identifier is the same as the first identifier.

[0375] In some embodiments, the fifth message may include second verification information, which can be used by the first device to verify the security of the fifth message.

[0376] In some embodiments, the fifth message may include second verification information generated according to the security context corresponding to the third identifier.

[0377] Exemplarily, the second verification information is generated according to the context identifier corresponding to the third identifier.

[0378] In some embodiments, the third identifier and / or the second verification information may be optional content of the fifth message.

[0379] In some embodiments, the fifth message causes the first device to enter the first state, and whether the first device uses the security context saved by the first device after entering the first state can be determined by protocol agreement, etc.

[0380] In some embodiments, the fifth message may include a third identifier but not the second verification information. Then, the security context used for entering the first state this time can be determined from one or more security contexts stored by itself based on the third identifier.

[0381] In some embodiments, if the fifth message includes the second verification information and the second verification information is verified, the first device enters the first state. In some embodiments, if the fifth message includes the second verification information and the second verification information is verified, the first device maintains the second state.

[0382] In some embodiments, the fifth message may include the second verification information but not the third identifier.

[0383] S2206: The first device generates third verification information.

[0384] In some embodiments, the first device generates third verification information based on the first security context stored by the first device.

[0385] In some embodiments, the first device generates third verification information based on the security context indicated by the third identifier.

[0386] S2207: The first device enters the first state.

[0387] In some embodiments, the first device enters the first state when the third verification information and the second verification information match.

[0388] In some embodiments, the first device enters the first state upon receiving the fifth message.

[0389] S2208: The first device sends a sixth message.

[0390] In some embodiments, the first device sends a sixth message to the second device.

[0391] In some embodiments, the sixth message is used to indicate whether the first device enters the first state.

[0392] In some embodiments, the sixth message may include, but is not limited to, at least one of the following: an RRC connection establishment message, an RRC connection re-establishment message, or an RRC recovery message.

[0393] In some embodiments, the sixth message may be a message that is security-protected using the security context corresponding to the third identifier.

[0394] In other embodiments, the sixth message may be a message that is not security-protected.

[0395] In some embodiments, after receiving the fifth message, the first device confirms that it has entered the first state, and the first device does not need to determine again whether to request the second device to confirm whether to enter the first state. At this time, the first device sends a sixth message to the second device indicating that the first device has entered the first state or is determined to enter the first state.

[0396] S2209: The second device sends an eighth message to the third device.

[0397] In some embodiments, the third device is a core network device.

[0398] In some embodiments, the third device includes at least one of the following:

[0399] Network functions NF of the core network CN;

[0400] Application function AF.

[0401] The CN NF may include but is not limited to: Access Management Function (AMF), Location Management Function (LMF), Session Management Function (SMF) and / or User Plane Function (UPF).

[0402] The AF may include but is not limited to an application server.

[0403] In some embodiments, the second device sends an eighth message to the third device when the first device enters the second state.

[0404] In some embodiments, the eighth message is used to indicate at least one of the following:

[0405] The first device enters a first state;

[0406] The first device re-enters the first state and continues to use the first security context;

[0407] The first security context of the first device continues to be used.

[0408] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the second device.

[0409] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the access network device.

[0410] In some embodiments, the first security context may be used for security protection of communications between the first device and the third device.

[0411] For example, the first security context may be used for security protection of Non Access Stratum (NAS) messages between the first device and the core network device.

[0412] In some embodiments, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[0413] FIG2C is an interactive diagram illustrating a security context processing method according to an embodiment of the present disclosure. As shown in FIG2A , the present disclosure embodiment relates to a security context processing method for a communication system 100, the method comprising:

[0414] S2301: The first device uses a first security context in a first state.

[0415] In some embodiments, the first device may be the aforementioned environmental IoT device. For example, the environmental IoT device may be any one of the environmental IoT devices shown in FIG. 1C to FIG. 1F .

[0416] In some embodiments, the first state may be any state in which the first device is in wireless communication.

[0417] In some embodiments, the first state may include but is not limited to an RRC connected state.

[0418] In some embodiments, the first state may be an activated state of the first device. In the activated state, the first device may perform wireless communication with other devices.

[0419] In some embodiments, the first security context may be a security context used by the first device when performing wireless communication.

[0420] In some embodiments, the first security context may be used to securely protect wireless communication messages.

[0421] Exemplarily, the security includes but is not limited to at least one of the following:

[0422] Security protection against tampering, such as integrity protection and / or digital signatures;

[0423] Encryption protection,

[0424] Scrambled.

[0425] In some implementations, the first security context may include, but is not limited to, at least one of the following:

[0426] Key;

[0427] Parameters for key derivation;

[0428] The algorithm identifier of the security algorithm.

[0429] Of course, the above is merely an example of the first security context, but the specific implementation is not limited to the above example.

[0430] S2302: The second device sends a first message.

[0431] In some embodiments, the second device sends the first message to the first device.

[0432] In some embodiments, the second device unicasts the first message to the first device.

[0433] In some embodiments, the second device multicasts the first message to the device group to which the first device belongs.

[0434] In some embodiments, the second device broadcasts the first message.

[0435] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[0436] In some embodiments, the second device may include at least one of the following:

[0437] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[0438] Intermediate nodes can be other communication devices besides environmental IoT devices;

[0439] Auxiliary nodes, etc.

[0440] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0441] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[0442] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0443] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[0444] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[0445] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[0446] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[0447] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[0448] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[0449] RRC message;

[0450] Media Access Control (MAC) MAC layer messages;

[0451] Physical downlink control information (DCI);

[0452] PC5 news.

[0453] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[0454] A first identifier, used to determine a first security context;

[0455] The first indicator is used to indicate saving the first security context.

[0456] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[0457] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[0458] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[0459] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[0460] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[0461] In some embodiments, the first identifier includes at least one of the following:

[0462] A context identifier, used to identify the first security context;

[0463] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[0464] The device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context. In this case, the device group identifier may indicate the security context that needs to be saved when entering the second state.

[0465] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[0466] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[0467] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[0468] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[0469] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[0470] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[0471] In some embodiments, the second device sends the first message through an RRC link of the first device.

[0472] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[0473] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[0474] S2303: The first device enters the second state and saves the first security context.

[0475] In some embodiments, the first device exits the first state to enter the second state and saves the first security context.

[0476] S2304: The second device sends a fifth message.

[0477] In some embodiments, the second device sends a fifth message to the first device.

[0478] In some embodiments, the fifth message is used to instruct the first device to enter the first state.

[0479] In some embodiments, the fifth message may be a broadcast message, a multicast message, or a unicast message.

[0480] In some embodiments, the fifth message may include, but is not limited to, a paging message.

[0481] In some embodiments, the fifth message includes at least one of the following:

[0482] A third identifier, used to identify a security context used by the first device to enter the first state;

[0483] The second verification information is used by the first device to verify the fifth message.

[0484] If the second device instructs the first device to use the first security context, the third identifier is the same as the first identifier.

[0485] In some embodiments, the fifth message may include second verification information, which can be used by the first device to verify the security of the fifth message.

[0486] In some embodiments, the fifth message may be second verification information generated according to the security context corresponding to the third identifier.

[0487] Exemplarily, the second verification information is generated according to the context identifier corresponding to the third identifier.

[0488] In some embodiments, the third identifier and / or the second verification information may be optional content of the fifth message.

[0489] In some embodiments, the fifth message causes the first device to enter the first state, and whether the first device uses the security context saved by the first device after entering the first state can be determined by protocol agreement, etc.

[0490] In some embodiments, the fifth message may include a third identifier but not the second verification information. Then, the security context used for entering the first state this time can be determined from one or more security contexts stored by itself based on the third identifier.

[0491] In some embodiments, if the fifth message includes the third verification information and the second verification information passes verification, the first device enters the first state. In some embodiments, if the fifth message includes the second verification information and the second verification information passes verification, the first device maintains the second state.

[0492] In some embodiments, the fifth message may include the second verification information but not the second identifier.

[0493] S2305: The first device generates third verification information.

[0494] In some embodiments, the first device generates third verification information based on the first security context stored by the first device.

[0495] In some embodiments, the first device generates third verification information based on the security context indicated by the third identifier.

[0496] S2306: The first device enters the first state.

[0497] In some embodiments, the first device enters the first state when the third verification information and the second verification information match.

[0498] In some embodiments, the first device enters the first state upon receiving the fifth message.

[0499] S2307: The first device sends a sixth message.

[0500] In some embodiments, the first device sends a sixth message to the second device.

[0501] In some embodiments, the sixth message is used to indicate whether the first device enters the first state.

[0502] In some embodiments, the sixth message is used by the first device to confirm with the second device whether it can enter the first state.

[0503] In some embodiments, the sixth message may include, but is not limited to, at least one of the following: an RRC connection establishment message, an RRC connection re-establishment message, or an RRC recovery message.

[0504] In some embodiments, the sixth message may be a message that is security-protected using the security context corresponding to the third identifier.

[0505] In other embodiments, the sixth message may be a message that is not security-protected.

[0506] S2308: The second device sends a seventh message.

[0507] In some embodiments, the second device sends a seventh message to the first device.

[0508] In some embodiments, the second device sends a seventh message to the first device based on the sixth message.

[0509] In some embodiments, the seventh message is used to indicate whether to agree or confirm that the first device enters the first state.

[0510] In some embodiments, in some embodiments, the seventh message may be a message that is security-protected using the security context corresponding to the third identifier.

[0511] In other embodiments, the seventh message may be a message that is not security-protected.

[0512] In some embodiments, when the sixth message passes verification, the seventh message indicates consent for the first device to enter the first state.

[0513] In some embodiments, when the sixth message fails verification, the seventh message indicates disagreement with the first device entering the first state.

[0514] S2309: Determine whether to maintain the first state of the first device or determine whether to enter the first state.

[0515] In some embodiments, the first device enters the first state upon receiving the seventh message.

[0516] In some embodiments, when the seventh message indicates consent for the first device to enter the first state, the first device enters the first state.

[0517] In some embodiments, when the seventh message indicates disagreement with the first device entering the first state, the first device maintains the second state.

[0518] In some embodiments, the first device determines whether to maintain the first state of the first device according to the seventh message.

[0519] In some embodiments, when the seventh message indicates consent for the first device to enter the first state, the first device maintains the first state.

[0520] In some embodiments, when the seventh message indicates that the first device does not agree to enter the first state, the first device exits the first state and returns to the second state.

[0521] In some embodiments, the seventh message may be securely protected, for example, by a security context corresponding to the third identifier.

[0522] In other embodiments, the seventh message is not security protected.

[0523] In some embodiments, the seventh message is security-protected, and the first device may verify the seventh message based on the security context corresponding to the third identifier.

[0524] In some embodiments, the first device determines whether to enter the first state based on the verified seventh message.

[0525] In some embodiments, when the seventh message passes verification, the first device enters the first state when the seventh message indicates that the first device agrees to enter the first state.

[0526] In some embodiments, when the seventh message passes verification, the first device maintains the second state when the seventh message indicates that it disagrees with the first device entering the first state. In some embodiments, when the seventh message fails verification, the first device maintains the second state.

[0527] In some embodiments, the first device determines whether to maintain the first state based on the verified seventh message.

[0528] In some embodiments, when the seventh message passes verification, the first device returns to the second state when the seventh message indicates disagreement with the first device entering the first state.

[0529] In some embodiments, when the seventh message passes verification, the first device maintains the first state when the seventh message indicates to enter the first state with the first device.

[0530] In some embodiments, when the seventh message fails verification, the first device remains in the first state.

[0531] In some embodiments, if the first device does not receive the verified seventh message within a preset period of time after the first device sends the sixth message, the first device returns to the second state, so that the first device returns to a low power consumption state.

[0532] S2310: The second device sends an eighth message to the third device.

[0533] In some embodiments, the third device is a core network device.

[0534] In some embodiments, the third device includes at least one of the following:

[0535] Network functions NF of the core network CN;

[0536] Application function AF.

[0537] The CN NF may include but is not limited to: Access Management Function (AMF), Location Management Function (LMF), Session Management Function (SMF) and / or User Plane Function (UPF).

[0538] The AF may include but is not limited to an application server.

[0539] In some embodiments, the second device sends an eighth message to the third device when the first device enters the second state.

[0540] In some embodiments, the eighth message is used to indicate at least one of the following:

[0541] The first device enters a first state;

[0542] The first device re-enters the first state and continues to use the first security context;

[0543] The first security context of the first device continues to be used.

[0544] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the second device.

[0545] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the access network device.

[0546] In some embodiments, the first security context may be used for security protection of communications between the first device and the third device.

[0547] For example, the first security context may be used for security protection of Non Access Stratum (NAS) messages between the first device and the core network device.

[0548] In some embodiments, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[0549] As shown in FIG3A , an embodiment of the present disclosure provides a security context processing method, which is executed by a first device. The security context processing method may include:

[0550] S3101: Use the first security context in the first state.

[0551] In some embodiments, the first device may be the aforementioned environmental IoT device. For example, the environmental IoT device may be any one of the environmental IoT devices shown in FIG. 1C to FIG. 1F .

[0552] In some embodiments, the first state may be any state in which the first device is in wireless communication.

[0553] In some embodiments, the first state may include but is not limited to an RRC connected state.

[0554] In some embodiments, the first state may be an activated state of the first device. In the activated state, the first device may perform wireless communication with other devices.

[0555] In some embodiments, the first security context may be a security context used by the first device when performing wireless communication.

[0556] In some embodiments, the first security context may be used to securely protect wireless communication messages.

[0557] Exemplarily, the security includes but is not limited to at least one of the following:

[0558] Security protection against tampering, such as integrity protection and / or digital signatures;

[0559] Encryption protection,

[0560] Scrambled.

[0561] In some implementations, the first security context may include, but is not limited to, at least one of the following:

[0562] Key;

[0563] Parameters for key derivation;

[0564] The algorithm identifier of the security algorithm.

[0565] Of course, the above is merely an example of the first security context, but the specific implementation is not limited to the above example.

[0566] S3102: Receive the first message.

[0567] In some embodiments, the first device receives a first message sent by the second device.

[0568] In some embodiments, the first device receives the first message broadcast, multicast, or unicast by the second device.

[0569] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[0570] In some embodiments, the second device may include at least one of the following:

[0571] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[0572] Intermediate nodes can be other communication devices besides environmental IoT devices;

[0573] Auxiliary nodes, etc.

[0574] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0575] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[0576] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0577] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[0578] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[0579] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[0580] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[0581] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[0582] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[0583] RRC message;

[0584] Media Access Control (MAC) MAC layer messages;

[0585] Physical downlink control information (DCI);

[0586] PC5 news.

[0587] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[0588] A first identifier, used to determine a first security context;

[0589] The first indicator is used to indicate saving the first security context.

[0590] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[0591] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[0592] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[0593] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[0594] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[0595] In some embodiments, the first identifier includes at least one of the following:

[0596] A context identifier, used to identify the first security context;

[0597] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[0598] The device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context. In this case, the device group identifier may indicate the security context that needs to be saved when entering the second state.

[0599] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[0600] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[0601] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[0602] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[0603] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[0604] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[0605] In some embodiments, the second device sends the first message through an RRC link of the first device.

[0606] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[0607] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[0608] In some embodiments, the first message may be a message secured using a first security context.

[0609] In other embodiments, the first message may also be a message that is not protected by the first security context.

[0610] S3103: Enter the second state and save the first security context.

[0611] In some embodiments, the first device exits the first state to enter the second state and saves the first security context.

[0612] In some embodiments, the power consumption of the first device in the first state is higher than the power consumption of the first device in the second state.

[0613] S3104: Send the second message.

[0614] In some embodiments, the first device sends the second message to the second device.

[0615] In some embodiments, the first device sends the second message to the second device before entering the second state or when entering the second state.

[0616] In some embodiments, the first device sends a second message to the second device based on the first message.

[0617] In some embodiments, the second message is used to indicate whether the first device enters the second state.

[0618] In some embodiments, the second message is used to indicate whether the first device saves the first security context.

[0619] In some embodiments, the second message is used to instruct the first device to enter the second state and whether to save the first security context.

[0620] In some embodiments, the second message may be used to enable the first device to enter the second state and save the first security context.

[0621] Exemplarily, the second message may be an acknowledgement character (ACK), used to indicate that the first device has entered the second state and / or has saved the first security context.

[0622] In another exemplary embodiment, the second message may be a non-acknowledgement character (NACK) message, which is used to indicate that the first device has not entered the second state and / or has not saved the first security context. For example, the NACK may indicate that the first device has entered the second state but has not saved the first security context.

[0623] In some embodiments, the second message may be a message secured using the first security context.

[0624] In other embodiments, the second message may also be a message that is not protected by the first security context.

[0625] S3105: Send the third message.

[0626] In some embodiments, the first device sends a third message to the second device.

[0627] In some embodiments, the third message is used by the first device to request to enter the first state.

[0628] Exemplarily, the third message may include but is not limited to an RRC connection request message and / or an RRC connection recovery request message.

[0629] In some embodiments, the third message includes at least one of the following:

[0630] A second identifier, used to indicate a security context used by the first device after entering the first state;

[0631] First verification information: The first verification information is used by the second device to verify the third message.

[0632] In some embodiments, the second identifier may be an identifier of the same type as the first identifier. If the first device continues to use the first security context after returning to the first state, the second identifier may be the same as the first identifier.

[0633] In one embodiment, the first verification information may include but is not limited to a verification code. By carrying the first verification information, secure verification of the third message can be achieved between the first device and the second device, thereby improving the security of the third message.

[0634] In some embodiments, the first verification information may be generated using the security context corresponding to the second identifier.

[0635] Exemplarily, the verification code is obtained by signing other message contents of the third message using the security context corresponding to the second identifier.

[0636] As another example, the first verification information is obtained by security processing of the security context corresponding to the second identifier.

[0637] Exemplarily, the second identifier and the first verification information may be carried in plain text in the third message.

[0638] In some embodiments, the first verification information is optional content of the third message.

[0639] In some embodiments, the third message may be a message secured using the first security context.

[0640] In other embodiments, the third message may also be a message that is not protected by the first security context.

[0641] S3106: Receive the fourth message.

[0642] In some embodiments, the first device receives a fourth message sent by the second device.

[0643] In some embodiments, the fourth message corresponds to the third message, for example, the fourth message is sent by the second device according to the third message.

[0644] In some embodiments, the fourth message is used to indicate whether the first device is allowed to enter the first state.

[0645] In some embodiments, the fourth message includes an acceptance message, wherein the acceptance message is used to indicate that the first device is allowed to enter the first state.

[0646] In some embodiments, the fourth message includes a rejection message, wherein the rejection message is used to indicate that the first device is not allowed to enter the first state.

[0647] In some embodiments, the acceptance message may be a fourth message sent by the second device to the first device after the first verification information passes the verification.

[0648] In some embodiments, the received message may be a fourth message sent by the second device to the first device when the first verification information is verified and the first device is allowed to return to the first state.

[0649] In some embodiments, the rejection message may be a fourth message sent by the second device to the first device when the first verification information fails to pass verification and / or does not allow the first device to return to the first state.

[0650] For example, the second device may determine whether to allow the first device to return to the first state based on the current load rate of the cell and / or the tolerable delay of the communication service requested by the first device.

[0651] In some embodiments, the fourth verification information may be verification information generated by the second device according to the security context identified by the second identifier.

[0652] In some embodiments, if the fourth verification information successfully matches the first verification information, the first verification information passes verification.

[0653] In some embodiments, if the fourth verification information and the first verification information do not match successfully, the first verification information fails verification.

[0654] Optionally, when the fourth verification information matches the first verification information, it is determined that the first device is allowed to enter the first state, the entry of the first device into the first state is recorded, and the security context indicated by the second identifier is saved.

[0655] Optionally, when the fourth verification information does not match the first verification information, it is determined that the first device is not allowed to enter the first state.

[0656] In some embodiments, if the third message does not carry the first verification information, the second device can skip the above-mentioned step of verifying the first verification information and determine whether to allow the first device to enter the first state based solely on the load rate on the network side and / or the urgency of the business requesting to enter the first state.

[0657] In some embodiments, the fourth message may be a message secured using the first security context.

[0658] In other embodiments, the fourth message may also be a message that is not protected by the first security context.

[0659] S3107: Enter the first state and reuse or continue to use the saved first security context.

[0660] In some embodiments, when the fourth message is an acceptance message, the first device enters the first state and resumes or continues to use the first security context.

[0661] S3108: Maintain in the second state.

[0662] In some embodiments, if the fourth message is a rejection message, the first device remains in the second state.

[0663] It is worth noting that some embodiments include S3101 and S3103, and the remaining steps are optional. For example, the first device may automatically enter the second state based on the pre-configuration of the second device or according to the protocol. For example, the protocol stipulates that the first device enters the second state by default after completing data transmission. At this time, the second device can know that the first device has indicated that data transmission is complete and automatically enters the second state and automatically saves the first security context used in the first state.

[0664] Some embodiments include S3101 to S3103, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, it enters the second state and saves the first security context after receiving the first message. There is no need to notify the second device whether it has confirmed that it has entered the first state. The first device may no longer be used or may not enter the first state for a long time. Therefore, the subsequent steps can be omitted.

[0665] Some embodiments include S3101 to S3104, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may no longer be used or may not enter the first state for a long time, so the subsequent steps can be omitted.

[0666] Some embodiments include S3101 to S3105, with the remaining steps being optional. For example, after the second device instructs the first device to enter the first state, the first device may request the second device to re-enter the first state via a third message. Possible scenarios include: the second device receives the third message but does not respond to the first device, or the second device does not receive the third message, and therefore subsequent steps may be omitted.

[0667] Some embodiments include S3101 to S3107, and the remaining steps are optional steps.

[0668] Some embodiments include S3101 to S3106 and S3108, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may request the second device to re-enter the first state via a third message. Possible scenarios include: the second device receives the third message but does not reply to the first device, or the second device does not receive the third message, and therefore the subsequent steps may be omitted.

[0669] As shown in FIG3B , an embodiment of the present disclosure provides a security context processing method performed by a first device. The security context processing method may include:

[0670] S3201: Using the first security context in the first state.

[0671] In some embodiments, the first device may be the aforementioned environmental IoT device. For example, the environmental IoT device may be any one of the environmental IoT devices shown in FIG. 1C to FIG. 1F .

[0672] In some embodiments, the first state may be any state in which the first device is in wireless communication.

[0673] In some embodiments, the first state may include but is not limited to an RRC connected state.

[0674] In some embodiments, the first state may be an activated state of the first device. In the activated state, the first device may perform wireless communication with other devices.

[0675] In some embodiments, the first security context may be a security context used by the first device when performing wireless communication.

[0676] In some embodiments, the first security context may be used to securely protect wireless communication messages.

[0677] Exemplarily, the security includes but is not limited to at least one of the following:

[0678] Security protection against tampering, such as integrity protection and / or digital signatures;

[0679] Encryption protection,

[0680] Scrambled.

[0681] In some implementations, the first security context may include, but is not limited to, at least one of the following:

[0682] Key;

[0683] Parameters for key derivation;

[0684] The algorithm identifier of the security algorithm.

[0685] Of course, the above is merely an example of the first security context, but the specific implementation is not limited to the above example.

[0686] S3202: Receive the first message.

[0687] In some embodiments, the first device receives a first message sent by the second device.

[0688] In some embodiments, the first device receives the first message broadcast, multicast, or unicast by the second device.

[0689] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[0690] In some embodiments, the second device may include at least one of the following:

[0691] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[0692] Intermediate nodes can be other communication devices besides environmental IoT devices;

[0693] Auxiliary nodes, etc.

[0694] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0695] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[0696] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0697] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[0698] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[0699] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[0700] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[0701] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[0702] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[0703] RRC message;

[0704] Media Access Control (MAC) MAC layer messages;

[0705] Physical downlink control information (DCI);

[0706] PC5 news.

[0707] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[0708] A first identifier, used to determine a first security context;

[0709] The first indicator is used to indicate saving the first security context.

[0710] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[0711] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[0712] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[0713] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[0714] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[0715] In some embodiments, the first identifier includes at least one of the following:

[0716] A context identifier, used to identify the first security context;

[0717] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[0718] The device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context. In this case, the device group identifier may indicate the security context that needs to be saved when entering the second state.

[0719] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[0720] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[0721] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[0722] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[0723] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[0724] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[0725] In some embodiments, the second device sends the first message through an RRC link of the first device.

[0726] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[0727] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[0728] In some embodiments, the first message may be a message secured using a first security context.

[0729] In other embodiments, the first message may also be a message that is not protected by the first security context.

[0730] S3203: Enter the second state and save the first security context.

[0731] In some embodiments, the first device exits the first state to enter the second state and saves the first security context.

[0732] In some embodiments, the power consumption of the first device in the first state is higher than the power consumption of the first device in the second state.

[0733] S3204: Send the second message.

[0734] In some embodiments, the first device sends the second message to the second device.

[0735] In some embodiments, the first device sends the second message to the second device before entering the second state or when entering the second state.

[0736] In some embodiments, the first device sends a second message to the second device based on the first message.

[0737] In some embodiments, the second message is used to indicate whether the first device enters the second state.

[0738] In some embodiments, the second message is used to indicate whether the first device saves the first security context.

[0739] In some embodiments, the second message is used to instruct the first device to enter the second state and whether to save the first security context.

[0740] In some embodiments, the second message may be used to enable the first device to enter the second state and save the first security context.

[0741] Exemplarily, the second message may be an acknowledgement character (ACK), used to indicate that the first device has entered the second state and / or has saved the first security context.

[0742] In another exemplary embodiment, the second message may be a non-acknowledgement character (NACK) message, which is used to indicate that the first device has not entered the second state and / or has not saved the first security context. For example, the NACK may indicate that the first device has entered the second state but has not saved the first security context.

[0743] In some embodiments, the second message may be a message secured using the first security context.

[0744] In other embodiments, the second message may also be a message that is not protected by the first security context.

[0745] S3205: Receive the fifth message.

[0746] In some embodiments, the second device sends a fifth message to the first device.

[0747] In some embodiments, the fifth message is used to instruct the first device to enter the first state.

[0748] In some embodiments, the fifth message may be a broadcast message, a multicast message, or a unicast message.

[0749] In some embodiments, the fifth message may include, but is not limited to, a paging message.

[0750] In some embodiments, the fifth message includes at least one of the following:

[0751] A third identifier, used to identify a security context used by the first device to enter the first state;

[0752] The second verification information is used by the first device to verify the fifth message.

[0753] If the second device instructs the first device to use the first security context, the third identifier is the same as the first identifier.

[0754] In some embodiments, the fifth message may include second verification information, which can be used by the first device to verify the security of the fifth message.

[0755] In some embodiments, the fifth message may include second verification information, which can be used by the first device to verify the security of the fifth message.

[0756] In some embodiments, the fifth message may include second verification information generated according to the security context corresponding to the third identifier.

[0757] Exemplarily, the second verification information is generated according to the context identifier corresponding to the third identifier.

[0758] In some embodiments, the third identifier and / or the second verification information may be optional content of the fifth message.

[0759] In some embodiments, the fifth message causes the first device to enter the first state, and whether the first device uses the security context saved by the first device after entering the first state can be determined by protocol agreement, etc.

[0760] In some embodiments, the fifth message may include a third identifier but not the second verification information. Then, the security context used for entering the first state this time can be determined from one or more security contexts stored by itself based on the third identifier.

[0761] In some embodiments, if the fifth message includes the third verification information and the second verification information passes verification, the first device enters the first state. In some embodiments, if the fifth message includes the second verification information and the second verification information passes verification, the first device maintains the second state.

[0762] S3206: Generate third verification information.

[0763] In some embodiments, the first device generates third verification information based on the first security context stored by the first device.

[0764] In some embodiments, the first device generates third verification information based on the security context indicated by the third identifier.

[0765] S3207: Entering the first state.

[0766] In some embodiments, the first device enters the first state when the third verification information and the second verification information match.

[0767] In some embodiments, the first device enters the first state upon receiving the fifth message.

[0768] Optionally, when the third verification information does not match the second verification information, the first device remains in the second state.

[0769] S3208: Send the sixth message.

[0770] In some embodiments, the first device sends a sixth message to the second device.

[0771] In some embodiments, the sixth message is used to indicate whether the first device enters the first state.

[0772] In some embodiments, the sixth message is used by the first device to confirm with the second device whether it can enter the first state.

[0773] In some embodiments, the sixth message may include, but is not limited to, at least one of the following: an RRC connection establishment message, an RRC connection re-establishment message, or an RRC recovery message.

[0774] In some embodiments, the sixth message may be a message that is security-protected using the security context corresponding to the third identifier.

[0775] In other embodiments, the sixth message may be a message that is not security-protected.

[0776] In some embodiments, after receiving the fifth message, the first device confirms that it has entered the first state, and the first device does not need to determine again whether to request the second device to confirm whether to enter the first state. At this time, the first device sends a sixth message to the second device indicating that the first device has entered the first state or is determined to enter the first state.

[0777] It is worth noting that some embodiments include S3201 and S3203, and the remaining steps are optional. For example, the first device may automatically enter the second state based on the pre-configuration of the second device or in accordance with the protocol. For example, the protocol stipulates that the first device enters the second state by default after completing data transmission. At this time, the second device can know that the first device has indicated that data transmission is complete and automatically enters the second state and automatically saves the first security context used in the first state.

[0778] Some embodiments include S3201 to S3203, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, it enters the second state and saves the first security context after receiving the first message. There is no need to notify the second device whether it has confirmed that it has entered the first state. The first device may no longer be used or may not enter the first state for a long time. Therefore, the subsequent steps can be omitted.

[0779] Some embodiments include S3201 to S3204, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may no longer be used or may not enter the first state for a long time, so the subsequent steps can be omitted.

[0780] Some embodiments include S3201 to S3205, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may request the second device to re-enter the first state via a fifth message. Possible scenarios include: the second device receives the fifth message but does not reply to the first device, or the second device does not receive the fifth message, and therefore the subsequent steps may be omitted.

[0781] Some embodiments include S3201 to S3207, and the remaining steps are optional steps, that is, after directly entering the first state, there is no need to additionally notify the second device that the first device has entered the first state.

[0782] Some embodiments include S3201 to S3208, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may request the second device to re-enter the first state via a fifth message. Possible scenarios include: the second device receives the fifth message but does not reply to the first device, or the second device does not receive the fifth message, and therefore the subsequent steps may be omitted.

[0783] FIG3C is an interactive diagram illustrating a security context processing method according to an embodiment of the present disclosure. The security context processing method according to the embodiment of the present disclosure is executed by a first device, and the security context processing method includes:

[0784] S3301: Using the first security context in the first state.

[0785] In some embodiments, the first device may be the aforementioned environmental IoT device. For example, the environmental IoT device may be any one of the environmental IoT devices shown in FIG. 1C to FIG. 1F .

[0786] In some embodiments, the first state may be any state in which the first device is in wireless communication.

[0787] In some embodiments, the first state may include but is not limited to an RRC connected state.

[0788] In some embodiments, the first state may be an activated state of the first device. In the activated state, the first device may perform wireless communication with other devices.

[0789] In some embodiments, the first security context may be a security context used by the first device when performing wireless communication.

[0790] In some embodiments, the first security context may be used to securely protect wireless communication messages.

[0791] Exemplarily, the security includes but is not limited to at least one of the following:

[0792] Security protection against tampering, such as integrity protection and / or digital signatures;

[0793] Encryption protection,

[0794] Scrambled.

[0795] In some implementations, the first security context may include, but is not limited to, at least one of the following:

[0796] Key;

[0797] Parameters for key derivation;

[0798] The algorithm identifier of the security algorithm.

[0799] Of course, the above is merely an example of the first security context, but the specific implementation is not limited to the above example.

[0800] S3302: Receive the first message.

[0801] In some embodiments, the first device receives a first message sent by the second device.

[0802] In some embodiments, the first device receives the first message unicast by the second device.

[0803] In some embodiments, the first device receives the first message multicast by the second device.

[0804] In some embodiments, the first device receives a first message broadcast by the second device.

[0805] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[0806] In some embodiments, the second device may include at least one of the following:

[0807] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[0808] Intermediate nodes can be other communication devices besides environmental IoT devices;

[0809] Auxiliary nodes, etc.

[0810] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0811] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[0812] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0813] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[0814] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[0815] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[0816] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[0817] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[0818] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[0819] RRC message;

[0820] Media Access Control (MAC) MAC layer messages;

[0821] Physical downlink control information (DCI);

[0822] PC5 news.

[0823] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[0824] A first identifier, used to determine a first security context;

[0825] The first indicator is used to indicate saving the first security context.

[0826] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[0827] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[0828] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[0829] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[0830] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[0831] In some embodiments, the first identifier includes at least one of the following:

[0832] A context identifier, used to identify the first security context;

[0833] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[0834] The device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context. In this case, the device group identifier may indicate the security context that needs to be saved when entering the second state.

[0835] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[0836] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[0837] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[0838] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[0839] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[0840] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[0841] In some embodiments, the second device sends the first message through an RRC link of the first device.

[0842] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[0843] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[0844] S3303: Enter the second state and save the first security context.

[0845] In some embodiments, the first device exits the first state to enter the second state and saves the first security context.

[0846] S3304: Receive the fifth message.

[0847] In some embodiments, the first device receives a fifth message sent by the second device.

[0848] In some embodiments, the fifth message is used to instruct the first device to enter the first state.

[0849] In some embodiments, the fifth message may be a broadcast message, a multicast message, or a unicast message.

[0850] In some embodiments, the fifth message may include, but is not limited to, a paging message.

[0851] In some embodiments, the fifth message includes at least one of the following:

[0852] A third identifier, used to identify a security context used by the first device to enter the first state;

[0853] The second verification information is used by the first device to verify the fifth message.

[0854] If the second device instructs the first device to use the first security context, the third identifier is the same as the first identifier.

[0855] In some embodiments, the fifth message may include second verification information, which can be used by the first device to verify the security of the fifth message.

[0856] In some embodiments, the fifth message may be second verification information generated according to the security context corresponding to the third identifier.

[0857] In some embodiments, the fifth message causes the first device to enter the first state, and whether the first device uses the security context saved by the first device after entering the first state can be determined by protocol agreement, etc.

[0858] In some embodiments, the fifth message may include a third identifier but not the second verification information. Then, the security context used for entering the first state this time can be determined from one or more security contexts stored by itself based on the third identifier.

[0859] In some embodiments, if the fifth message includes the third verification information and the second verification information passes verification, the first device enters the first state. In some embodiments, if the fifth message includes the second verification information and the second verification information passes verification, the first device maintains the second state.

[0860] In some embodiments, the fifth message may include the second verification information but not the second identifier.

[0861] S3305: Generate third verification information.

[0862] In some embodiments, the first device generates third verification information based on the first security context stored by the first device.

[0863] In some embodiments, the first device generates third verification information based on the security context indicated by the third identifier.

[0864] S3306: Entering the first state.

[0865] In some embodiments, the first device enters the first state when the third verification information and the second verification information match.

[0866] In some embodiments, the first device enters the first state upon receiving the fifth message.

[0867] Optionally, the first device maintains the second state when the third verification information does not match the second verification information.

[0868] S3307: Send the sixth message.

[0869] In some embodiments, the first device sends a sixth message to the second device.

[0870] In some embodiments, the sixth message is used to indicate whether the first device enters the first state.

[0871] In some embodiments, the sixth message is used by the first device to confirm with the second device whether it can enter the first state.

[0872] In some embodiments, the sixth message may include, but is not limited to, at least one of the following: an RRC connection establishment message, an RRC connection re-establishment message, or an RRC recovery message.

[0873] In some embodiments, the sixth message may be a message that is security-protected using the security context corresponding to the third identifier.

[0874] In other embodiments, the sixth message may be a message that is not security-protected.

[0875] S3308: Receive the seventh message.

[0876] In some embodiments, the first device receives a seventh message sent by the second device.

[0877] In some embodiments, the seventh message corresponds to the sixth message.

[0878] In some embodiments, the seventh message is used to indicate whether to agree or confirm that the first device enters the first state.

[0879] In some embodiments, in some embodiments, the seventh message may be a message that is security-protected using the security context corresponding to the third identifier.

[0880] In other embodiments, the seventh message may be a message that is not security-protected.

[0881] In some embodiments, when the sixth message passes verification, the seventh message indicates consent for the first device to enter the first state.

[0882] In some embodiments, when the sixth message fails verification, the seventh message indicates disagreement with the first device entering the first state.

[0883] S3309: Determine whether to maintain the first state of the first device or determine whether to enter the first state.

[0884] In some embodiments, the first device enters the first state upon receiving the seventh message.

[0885] In some embodiments, when the seventh message indicates consent for the first device to enter the first state, the first device enters the first state.

[0886] In some embodiments, when the seventh message indicates disagreement with the first device entering the first state, the first device maintains the second state. In some embodiments, the first device determines whether to maintain the first state of the first device according to the seventh message.

[0887] In some embodiments, when the seventh message indicates consent for the first device to enter the first state, the first device maintains the first state.

[0888] In some embodiments, when the seventh message indicates that the first device does not agree to enter the first state, the first device exits the first state and returns to the second state.

[0889] In some embodiments, the seventh message may be securely protected, for example, by a security context corresponding to the third identifier.

[0890] In other embodiments, the seventh message is not security protected.

[0891] In some embodiments, the seventh message is security-protected, and the first device may verify the seventh message based on the security context corresponding to the third identifier.

[0892] In some embodiments, the first device determines whether to enter the first state based on the verified seventh message.

[0893] In some embodiments, when the seventh message passes verification, the first device enters the first state when the seventh message indicates that the first device agrees to enter the first state.

[0894] In some embodiments, when the seventh message passes verification, the first device maintains the second state when the seventh message indicates that it disagrees with the first device entering the first state. In some embodiments, when the seventh message fails verification, the first device maintains the second state.

[0895] In some embodiments, the first device determines whether to maintain the first state based on the verified seventh message.

[0896] In some embodiments, when the seventh message passes verification, the first device returns to the second state when the seventh message indicates disagreement with the first device entering the first state.

[0897] In some embodiments, when the seventh message passes verification, the first device maintains the first state when the seventh message indicates to enter the first state with the first device.

[0898] In some embodiments, when the seventh message fails verification, the first device remains in the first state.

[0899] In some embodiments, if the first device does not receive the verified seventh message within a preset period of time after the first device sends the sixth message, the first device returns to the second state, so that the first device returns to a low power consumption state.

[0900] It is worth noting that some embodiments include S3301 and S3303, and the remaining steps are optional. For example, the first device may automatically enter the second state based on the pre-configuration of the second device or according to the protocol agreement. For example, the protocol stipulates that the first device enters the second state by default after completing data transmission. At this time, the second device can know that the first device has indicated that data transmission is complete and automatically enters the second state and automatically saves the first security context used in the first state.

[0901] Some embodiments include S3301 to S3303, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, it enters the second state and saves the first security context after receiving the first message. There is no need to notify the second device whether it has confirmed that it has entered the first state. The first device may no longer be used or may not enter the first state for a long time. Therefore, the subsequent steps can be omitted.

[0902] Some embodiments include S3301 to S3304, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may no longer be used or may not enter the first state for a long time, so the subsequent steps can be omitted.

[0903] Some embodiments include S3301 to S3305, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may request the second device to re-enter the first state via a fifth message. Possible scenarios include: the second device receives the fifth message but does not reply to the first device, or the second device does not receive the fifth message, and therefore the subsequent steps may be omitted.

[0904] Some embodiments include S3301 to S3307, and the remaining steps are optional steps, that is, after directly entering the first state, there is no need to additionally notify the second device that the first device has entered the first state.

[0905] Some embodiments include S3301 to S3308, and the remaining steps are optional. For example, after the second device instructs the first device to enter the first state, the first device may request the second device to re-enter the first state via a fifth message. Possible scenarios include: the second device receives the fifth message but does not reply to the first device, or the second device does not receive the fifth message, and therefore the subsequent steps may be omitted.

[0906] As shown in FIG4A , a security context processing method according to an embodiment of the present disclosure is executed by a second device. The security context processing method includes:

[0907] S4101: Send the first message.

[0908] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[0909] In some embodiments, the second device may include at least one of the following:

[0910] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[0911] Intermediate nodes can be other communication devices besides environmental IoT devices;

[0912] Auxiliary nodes, etc.

[0913] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0914] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[0915] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[0916] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[0917] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[0918] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[0919] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[0920] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[0921] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[0922] RRC message;

[0923] Media Access Control (MAC) MAC layer messages;

[0924] Physical downlink control information (DCI);

[0925] PC5 news.

[0926] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[0927] A first identifier, used to determine a first security context;

[0928] The first indicator is used to indicate saving the first security context.

[0929] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[0930] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[0931] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[0932] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[0933] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[0934] In some embodiments, the first identifier includes at least one of the following:

[0935] A context identifier, used to identify the first security context;

[0936] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[0937] A device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context, and the device group identifier may indicate the security context that needs to be protected when entering the second state.

[0938] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[0939] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[0940] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[0941] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[0942] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[0943] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[0944] In some embodiments, the second device sends the first message through an RRC connection of the first device.

[0945] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[0946] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[0947] In some embodiments, the first message may be a message secured using a first security context.

[0948] In other embodiments, the first message may also be a message that is not protected by the first security context.

[0949] S4102: Receive the second message.

[0950] In some embodiments, the second device receives the second message sent by the first device.

[0951] In some embodiments, the second message is used to indicate whether the first device enters the second state.

[0952] In some embodiments, the second message is used to indicate whether the first device saves the first security context.

[0953] In some embodiments, the second message is used to instruct the first device to enter the second state and whether to save the first security context.

[0954] In some embodiments, the second message may be used to enable the first device to enter the second state and save the first security context.

[0955] Exemplarily, the second message may be an acknowledgement character (ACK), used to indicate that the first device has entered the second state and / or has saved the first security context.

[0956] In another exemplary embodiment, the second message may be a non-acknowledgement character (NACK) message, which is used to indicate that the first device has not entered the second state and / or has not saved the first security context. For example, the NACK may indicate that the first device has entered the second state but has not saved the first security context.

[0957] In some embodiments, the second message may be a message secured using the first security context.

[0958] In other embodiments, the second message may also be a message that is not protected by the first security context.

[0959] In some embodiments, the second message may be a message secured using the first security context.

[0960] In other embodiments, the second message may also be a message that is not protected by the first security context.

[0961] S4103: The first device that saves the second state uses the first security context in the first state.

[0962] In some embodiments, the first identifier and the first security context of the first device are correspondingly saved.

[0963] In some embodiments, the first identifier includes at least one of the following:

[0964] A context identifier, used to identify the first security context;

[0965] A device identifier, used to identify the first device, where the security context of different first devices is different;

[0966] The device group identifier is used to identify the device group to which the first device belongs. Different device groups use different security contexts.

[0967] S4104: Receive the third message.

[0968] In some embodiments, the second device receives the third message from the first device.

[0969] In some embodiments, the third message is used by the first device to request to enter the first state.

[0970] Exemplarily, the third message may include but is not limited to an RRC connection request message and / or an RRC connection recovery request message.

[0971] In some embodiments, the third message includes at least one of the following:

[0972] A second identifier, used to indicate a security context used by the first device after entering the first state;

[0973] First verification information: The first verification information is used by the second device to verify the third message.

[0974] In some embodiments, the second identifier may be an identifier of the same type as the first identifier. If the first device continues to use the first security context after returning to the first state, the second identifier may be the same as the first identifier.

[0975] In one embodiment, the first verification information may include but is not limited to a verification code. By carrying the first verification information, secure verification of the third message can be achieved between the first device and the second device, thereby improving the security of the third message.

[0976] In some embodiments, the first verification information may be generated using the security context corresponding to the second identifier.

[0977] Exemplarily, the verification code is obtained by signing other message contents of the second message using the security context corresponding to the second identifier.

[0978] As another example, the first verification information is obtained by security processing of the security context corresponding to the second identifier.

[0979] Exemplarily, the second identifier and the first verification information may be carried in plain text in the third message.

[0980] In some embodiments, the first verification information is optional content of the second message.

[0981] In some embodiments, the third message may be a message secured using the first security context.

[0982] In other embodiments, the third message may also be a message that is not protected by the first security context.

[0983] S4105: Send the fourth message.

[0984] In some embodiments, the second device sends a fourth message to the first device.

[0985] In some embodiments, the second device sends a response message to the third message to the first device.

[0986] In some embodiments, the fourth message is used to indicate whether the first device is allowed to enter the first state.

[0987] In some embodiments, the fourth message includes an acceptance message, wherein the acceptance message is used to indicate that the first device is allowed to enter the first state.

[0988] In some embodiments, the fourth message includes a rejection message, wherein the rejection message is used to indicate that the first device is not allowed to enter the first state.

[0989] In some embodiments, after the first verification information is verified, the second device sends an acceptance message to the first device.

[0990] In some embodiments, the first verification information is verified and the first device is allowed to return to the first state, and the second device sends an acceptance message to the first device.

[0991] In some embodiments, if the first verification information fails to pass verification and / or the first device is not allowed to return to the first state, the second device sends a rejection message to the first device.

[0992] For example, the second device may determine whether to allow the first device to return to the first state based on the current load rate of the cell and / or the tolerable delay of the communication service requested by the first device.

[0993] In some embodiments, the second device locally generates fourth verification information based on the security context of the second identifier.

[0994] In some embodiments, if the fourth verification information successfully matches the first verification information, the first verification information passes verification.

[0995] In some embodiments, if the fourth verification information and the first verification information do not match successfully, the first verification information fails verification.

[0996] Optionally, when the fourth verification information matches the first verification information, it is determined that the first device is allowed to enter the first state, the entry of the first device into the first state is recorded, and the security context indicated by the second identifier is saved.

[0997] Optionally, when the fourth verification information does not match the first verification information, it is determined that the first device is not allowed to enter the first state.

[0998] In some embodiments, if the third message does not carry the first verification information, the second device can skip the above-mentioned step of verifying the first verification information and determine whether to allow the first device to enter the first state based solely on the load rate on the network side and / or the urgency of the business requesting to enter the first state.

[0999] In some embodiments, the fourth message may be a message secured using the first security context.

[1000] In other embodiments, the fourth message may also be a message that is not protected by the first security context.

[1001] S4106: Send the eighth message.

[1002] In some embodiments, the second device sends an eighth message to the third device.

[1003] In some embodiments, the third device is a core network device.

[1004] In some embodiments, the third device includes at least one of the following:

[1005] Network functions NF of the core network CN;

[1006] Application function AF.

[1007] The CN NF may include but is not limited to: Access Management Function (AMF), Location Management Function (LMF), Session Management Function (SMF) and / or User Plane Function (UPF).

[1008] The AF may include but is not limited to an application server.

[1009] In some embodiments, the second device sends an eighth message to the third device when the first device enters the second state.

[1010] In some embodiments, the eighth message is used to indicate at least one of the following:

[1011] The first device enters a first state;

[1012] The first device re-enters the first state and continues to use the first security context;

[1013] The first security context of the first device continues to be used.

[1014] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the second device.

[1015] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the access network device.

[1016] In some embodiments, the first security context may be used for security protection of communications between the first device and the third device.

[1017] For example, the first security context may be used for security protection of Non Access Stratum (NAS) messages between the first device and the core network device.

[1018] In some embodiments, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[1019] It is worth noting that some embodiments include S4101, and the remaining steps are optional. The second device may instruct the first device, via the first message, to save the first security context upon entering the second state. This may be a default for the first device to save the first security context. Subsequently, the first device may return to the first state in a variety of ways, not limited to S4104 and other steps. The third device may continue to maintain the first security context of the first device and may not be concerned with changes in the first device's state.

[1020] Some embodiments include S4101 and S4106, and the remaining steps are optional. The second device may instruct the first device to save the first security context upon entering the second state via a first message, and upon receiving the second message from the first device, determine the first security context of the first device. It may be assumed that the first device will save the first security context. There are multiple ways for the first device to subsequently return to the first state, not limited to steps such as S4104.

[1021] Some embodiments include S4101 to S4103, and the remaining steps are optional. After the first device enters the second state, it is shut down or stays in the second state for a long time or moves to another location, then the second device may not be required to operate in the subsequent steps.

[1022] Some embodiments include S4101 to S4103 and S4106, and the remaining steps are optional. After the first device enters the second state, it is shut down or stays in the second state for a long time or moves to another location, then the second device may not be required to operate in the subsequent steps.

[1023] Some embodiments include S4101 and S4103, and the remaining steps are optional. For example, if the second device sends a first message without the first device responding to the first message, it is assumed that the first device will save the first security context when entering the second state. If the first device then enters the second state and then shuts down, remains in the second state for an extended period, or moves to another location, the second device may not be required to perform subsequent steps.

[1024] Some embodiments include S4101, S4103, and S4106, and the remaining steps are optional. For example, if the second device sends a first message without the first device responding to the first message, it is assumed that the first device will save the first security context when entering the second state. If the first device then enters the second state and then shuts down, remains in the second state for an extended period, or moves to another location, the second device may not be required to perform subsequent steps.

[1025] Some embodiments include S4101, S4103 to S4104, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it is assumed that the first security context is continuously saved unless a specific reset event is met. In this case, the second device does not need to send the eighth message to the third device.

[1026] Some embodiments include S4101 to S4105, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it can be continuously saved unless a specific reset event is met. In this case, the second device does not need to send the eighth message to the third device.

[1027] As shown in FIG4B , a security context processing method according to an embodiment of the present disclosure is executed by a second device. The security context processing method includes:

[1028] S4201: Send the first message.

[1029] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[1030] In some embodiments, the second device may include at least one of the following:

[1031] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[1032] Intermediate nodes can be other communication devices besides environmental IoT devices;

[1033] Auxiliary nodes, etc.

[1034] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[1035] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[1036] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[1037] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[1038] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[1039] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[1040] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[1041] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[1042] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[1043] RRC message;

[1044] Media Access Control (MAC) MAC layer messages;

[1045] Physical downlink control information (DCI);

[1046] PC5 news.

[1047] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[1048] A first identifier, used to determine a first security context;

[1049] The first indicator is used to indicate saving the first security context.

[1050] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[1051] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[1052] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[1053] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[1054] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[1055] In some embodiments, the first identifier includes at least one of the following:

[1056] A context identifier, used to identify the first security context;

[1057] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[1058] A device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context, and the device group identifier may indicate the security context that needs to be protected when entering the second state.

[1059] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[1060] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[1061] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[1062] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[1063] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[1064] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[1065] In some embodiments, the second device sends the first message through an RRC connection of the first device.

[1066] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[1067] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[1068] In some embodiments, the first message may be a message secured using a first security context.

[1069] In other embodiments, the first message may also be a message that is not protected by the first security context.

[1070] S4202: Receive the second message.

[1071] In some embodiments, the second device receives the second message sent by the first device.

[1072] In some embodiments, the second message is used to indicate whether the first device enters the second state.

[1073] In some embodiments, the second message is used to indicate whether the first device saves the first security context.

[1074] In some embodiments, the second message is used to instruct the first device to enter the second state and whether to save the first security context.

[1075] In some embodiments, the second message may be used to enable the first device to enter the second state and save the first security context.

[1076] Exemplarily, the second message may be an acknowledgement character (ACK), used to indicate that the first device has entered the second state and / or has saved the first security context.

[1077] In another exemplary embodiment, the second message may be a non-acknowledgement character (NACK) message, which is used to indicate that the first device has not entered the second state and / or has not saved the first security context. For example, the NACK may indicate that the first device has entered the second state but has not saved the first security context.

[1078] In some embodiments, the second message may be a message secured using the first security context.

[1079] In other embodiments, the second message may also be a message that is not protected by the first security context.

[1080] In some embodiments, the second message may be a message secured using the first security context.

[1081] In other embodiments, the second message may also be a message that is not protected by the first security context.

[1082] S4203: The first device that saves the second state uses the first security context in the first state.

[1083] S4204: Send the fifth message.

[1084] In some embodiments, the second device sends a fifth message to the first device.

[1085] In some embodiments, the fifth message is used to instruct the first device to enter the first state.

[1086] In some embodiments, the fifth message may be a broadcast message, a multicast message, or a unicast message.

[1087] In some embodiments, the fifth message may include, but is not limited to, a paging message.

[1088] In some embodiments, the fifth message includes at least one of the following:

[1089] A third identifier, used to identify a security context used by the first device to enter the first state;

[1090] The second verification information is used by the first device to verify the fifth message.

[1091] If the second device instructs the first device to use the first security context, the third identifier is the same as the first identifier.

[1092] In some embodiments, the fifth message may include second verification information, which can be used by the first device to verify the security of the fifth message.

[1093] In some embodiments, the fifth message may include second verification information generated according to the security context corresponding to the third identifier.

[1094] Exemplarily, the second verification information is generated according to the context identifier corresponding to the third identifier.

[1095] In some embodiments, the third identifier and / or the second verification information may be optional content of the fifth message.

[1096] In some embodiments, the fifth message causes the first device to enter the first state, and whether the first device uses the security context saved by the first device after entering the first state can be determined by protocol agreement, etc.

[1097] In some embodiments, the fifth message may include a third identifier but not the second verification information. Then, the security context used for entering the first state this time can be determined from one or more security contexts stored by itself based on the third identifier.

[1098] In some embodiments, if the fifth message includes the third verification information and the second verification information passes verification, the first device enters the first state. In some embodiments, if the fifth message includes the second verification information and the second verification information passes verification, the first device maintains the second state.

[1099] In some embodiments, the fifth message may include the second verification information but not the second identifier.

[1100] S4205: Receive the sixth message.

[1101] In some embodiments, the second device receives the sixth message from the first device.

[1102] In some embodiments, the sixth message is used to indicate whether the first device enters the first state.

[1103] In some embodiments, the sixth message is used by the first device to confirm with the second device whether it can enter the first state.

[1104] In some embodiments, the sixth message may include, but is not limited to, at least one of the following: an RRC connection establishment message, an RRC connection re-establishment message, or an RRC recovery message.

[1105] In some embodiments, the sixth message may be a message that is security-protected using the security context corresponding to the third identifier.

[1106] In other embodiments, the sixth message may be a message that is not security-protected.

[1107] In some embodiments, after receiving the fifth message, the first device confirms that it has entered the first state, and the first device does not need to determine again whether to request the second device to confirm whether to enter the first state. At this time, the first device sends a sixth message to the second device indicating that the first device has entered the first state or is determined to enter the first state.

[1108] S4206: Send an eighth message to the third device.

[1109] In some embodiments, the third device is a core network device.

[1110] In some embodiments, the third device includes at least one of the following:

[1111] Network functions NF of the core network CN;

[1112] Application function AF.

[1113] The CN NF may include but is not limited to: Access Management Function (AMF), Location Management Function (LMF), Session Management Function (SMF) and / or User Plane Function (UPF).

[1114] The AF may include but is not limited to an application server.

[1115] In some embodiments, the second device sends an eighth message to the third device when the first device enters the second state.

[1116] In some embodiments, the eighth message is used to indicate at least one of the following:

[1117] The first device enters a first state;

[1118] The first device re-enters the first state and continues to use the first security context;

[1119] The first security context of the first device continues to be used.

[1120] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the second device.

[1121] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the access network device.

[1122] In some embodiments, the first security context may be used for security protection of communications between the first device and the third device.

[1123] For example, the first security context may be used for security protection of Non Access Stratum (NAS) messages between the first device and the core network device.

[1124] In some embodiments, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[1125] It is worth noting that: some embodiments include S4201, and the remaining steps are optional steps. The second device can instruct the first device to save the first security context when entering the second state through the first message. The second device originally saves the first security context used by the first device in the first state.

[1126] It is worth noting that some embodiments include S4201 and S4206, and the remaining steps are optional. The second device can instruct the first device to save the first security context when entering the second state through the first message. The second device already saves the first security context used by the first device in the first state.

[1127] Some embodiments include S4201 to S4203, and the remaining steps are optional. After the first device enters the second state, it is shut down or stays in the second state for a long time or moves to another location, and then the second device may not be required to operate in the subsequent steps.

[1128] Some embodiments include S4201 to S4203 and S4206, and the remaining steps are optional. After the first device enters the second state, it is shut down or stays in the second state for a long time or moves to another location, then the second device may not be required to operate in the subsequent steps.

[1129] Some embodiments include S4201 and S4203, and the remaining steps are optional. For example, if the second device sends a first message without the first device responding to the first message, it is assumed that the first device will save the first security context when entering the second state. If the first device then enters the second state and then shuts down, remains in the second state for an extended period, or moves to another location, the second device may not be required to perform subsequent steps.

[1130] Some embodiments include S4201, S4203, and S4206, and the remaining steps are optional. For example, if the second device sends a first message without the first device responding to the first message, it is assumed that the first device will save the first security context when entering the second state. If the first device then enters the second state and then shuts down, remains in the second state for an extended period, or moves to another location, the second device may not be required to perform subsequent steps.

[1131] Some embodiments include S4201, S4203 to S4204, and the remaining steps are optional. For example, if the third device defaults to setting the first security context for the first device, the security context will be retained unless a specific reset event is met, and the second device defaults to the first device entering the first state when the second device sends the fifth message, then the second device does not need to receive the sixth message.

[1132] Some embodiments include S4201, S4203 to S4204, and S4206, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it is retained unless a specific reset event is met, and the second device sends the fifth message, which defaults to the first device entering the first state. In this case, the second device does not need to receive the sixth message.

[1133] Some embodiments include S4201 to S4206, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it can be continuously saved unless a specific reset event is met. In this case, the second device does not need to send the eighth message to the third device.

[1134] Some embodiments include S4201, S4203 to S4204, and S4206, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it is retained unless a specific reset event is met, and the second device sends the fifth message, which defaults to the first device entering the first state. In this case, the second device does not need to receive the sixth message.

[1135] As shown in FIG4C , a security context processing method according to an embodiment of the present disclosure includes:

[1136] S4301: The second device sends a first message.

[1137] In some embodiments, the second device may be a device that communicates with the first device based on a backscatter transmission mechanism.

[1138] In some embodiments, the second device may include at least one of the following:

[1139] A network node, which may also be referred to as a network device, may include but is not limited to an access network node;

[1140] Intermediate nodes can be other communication devices besides environmental IoT devices;

[1141] Auxiliary nodes, etc.

[1142] In some embodiments, the first message is used to instruct the first device to enter the second state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[1143] In some embodiments, the first message is used to instruct the first device to save the first security context when entering the second state.

[1144] In some embodiments, the first message is used to instruct the first device to exit the first state. In this case, the first device and the second device can both determine whether to save the first security context before, when, or after entering the second state based on a protocol agreement or pre-negotiation.

[1145] In some embodiments, the first message is used to instruct the second device to exit the first state and enter the second state and save the first security context used in the first state.

[1146] In some embodiments, the second state may be a state in which the first device suspends wireless communication.

[1147] In some embodiments, the second state may be a state in which the first device pauses performing reflection scattering communication with the second device.

[1148] In some embodiments, the second state may include, but is not limited to, an RRC idle state and / or an RRC inactive state.

[1149] In some embodiments, the second state may be a dormant state of the first device. The dormant state of the first device may be a state in which the first device suspends communication with other devices.

[1150] In some embodiments, the message type of the first message may include, but is not limited to, at least one of the following:

[1151] RRC message;

[1152] Media Access Control (MAC) MAC layer messages;

[1153] Physical downlink control information (DCI);

[1154] PC5 news.

[1155] In some embodiments, the message content of the first message may include, but is not limited to, at least one of the following:

[1156] A first identifier, used to determine a first security context;

[1157] The first indicator is used to indicate saving the first security context.

[1158] In some embodiments, the first security context of the first device is stored in both the first device and the second device. To distinguish the first security contexts of different devices, the first security context is assigned a security context identifier, which is the first identifier.

[1159] In some embodiments, the first indicator may include one or more bits for indicating that the first security context is saved.

[1160] In some embodiments, the first message includes a first indicator that does not include the first identifier. If the first indicator indicates to save the security context, in this case, the first device saves the first security context of wireless communication between itself and the second device that sent the first message according to the first message. If the first indicator indicates not to save the security context, in this case, the first device enters the second state according to the first message and does not save the first security context used in the first state.

[1161] In some embodiments, the first message includes the first identifier but does not include the first indicator. In the case where the first message includes the first identifier, it can be considered that the first device needs to save the first security context used in the first state when entering the second state.

[1162] In some embodiments, the first message may indicate that the first device enters the second state, and does not include the first identifier and the first indicator. After receiving the first message, the first device can determine whether to save the first security context according to the protocol agreement or prior negotiation.

[1163] In some embodiments, the first identifier includes at least one of the following:

[1164] A context identifier, used to identify the first security context;

[1165] The device identifier is used to identify the first device. The device identifier identifies the first device and identifies a first security context used by the first device.

[1166] A device group identifier is used to identify the device group to which the first device belongs. Exemplarily, different device groups use different security contexts. In another exemplary embodiment, different device groups may use the same security context, and the device group identifier may indicate the security context that needs to be protected when entering the second state.

[1167] In some embodiments, the context identifier may specifically identify an identifier of a security context.

[1168] In some embodiments, the device identifier may be various types of identifiers of the first device, including but not limited to International Mobile Subscriber Identification Number (IMSI), International Mobile Equipment Identity (IMEI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or (Subscription Concealed Identifier, SUCI) or User Information ID, etc.

[1169] In some embodiments, the device identifier may also be a dedicated device identifier for an environmental IoT device, etc. For example, the length of the dedicated device identifier for the environmental IoT device may be shorter than the identifier length of conventional communication terminals such as mobile phones and vehicle-mounted devices.

[1170] In some embodiments, the device identifier may also be a device identifier configured according to different functions or services. In this case, a first device may have multiple device identifiers, and different device identifiers may correspond to different security contexts.

[1171] In some embodiments, the device identifier may be a device identifier assigned to a cell accessed by the first device, etc. For example, when the first message is a broadcast message or a multicast message, the device identifier carried in the first message can not only inform which devices need to enter the second state but also use the device identifier to indicate whether the security context used by the device needs to be saved.

[1172] In some embodiments, the first message may include a device group identifier, where the device group identifier identifies a device group, and a device group may include one or more first devices.

[1173] In some embodiments, the second device sends the first message through an RRC link of the first device.

[1174] In some embodiments, the first message may include, but is not limited to, an RRC connection release message.

[1175] In some embodiments, the first message may be a suspend message or a persist message, indicating that the first security context needs to be continued to be used subsequently, and that the first security context cannot be released when the first device enters the second state, but continues to be stored. Releasing the first security context here may include but is not limited to deleting the first security context or discarding the first security context.

[1176] In some embodiments, the first message may be a message secured using a first security context.

[1177] In other embodiments, the first message may also be a message that is not protected by the first security context.

[1178] S4302: The second device receives the second message.

[1179] In some embodiments, the second device receives the second message sent by the first device.

[1180] In some embodiments, the second message is used to indicate whether the first device enters the second state.

[1181] In some embodiments, the second message is used to indicate whether the first device saves the first security context.

[1182] In some embodiments, the second message is used to instruct the first device to enter the second state and whether to save the first security context.

[1183] In some embodiments, the second message may be used to enable the first device to enter the second state and save the first security context.

[1184] Exemplarily, the second message may be an acknowledgement character (ACK), used to indicate that the first device has entered the second state and / or has saved the first security context.

[1185] In another exemplary embodiment, the second message may be a non-acknowledgement character (NACK) message, which is used to indicate that the first device has not entered the second state and / or has not saved the first security context. For example, the NACK may indicate that the first device has entered the second state but has not saved the first security context.

[1186] In some embodiments, the second message may be a message secured using the first security context.

[1187] In other embodiments, the second message may also be a message that is not protected by the first security context.

[1188] In some embodiments, the second message may be a message secured using the first security context.

[1189] In other embodiments, the second message may also be a message that is not protected by the first security context.

[1190] S4303: The first device that saves the second state uses the first security context in the first state.

[1191] S4304: The second device sends a fifth message.

[1192] In some embodiments, the second device sends a fifth message to the first device.

[1193] In some embodiments, the fifth message is used to instruct the first device to enter the first state.

[1194] In some embodiments, the fifth message may be a broadcast message, a multicast message, or a unicast message.

[1195] In some embodiments, the fifth message may include, but is not limited to, a paging message.

[1196] In some embodiments, the fifth message includes at least one of the following:

[1197] A third identifier, used to identify a security context used by the first device to enter the first state;

[1198] The second verification information is used by the first device to verify the fifth message.

[1199] If the second device instructs the first device to use the first security context, the third identifier is the same as the first identifier.

[1200] In some embodiments, the fifth message may include second verification information, which can be used by the first device to verify the security of the fifth message.

[1201] In some embodiments, the fifth message may include second verification information generated according to the third identifier.

[1202] Exemplarily, the second verification information is generated according to the context identifier corresponding to the third identifier.

[1203] In some embodiments, the third identifier and / or the second verification information may be optional content of the fifth message.

[1204] In some embodiments, the fifth message causes the first device to enter the first state, and whether the first device uses the security context saved by the first device after entering the first state can be determined by protocol agreement, etc.

[1205] In some embodiments, the fifth message may include a third identifier but not the second verification information. Then, the security context used for entering the first state this time can be determined from one or more security contexts stored by itself based on the third identifier.

[1206] In some embodiments, if the fifth message includes the third verification information and the second verification information passes verification, the first device enters the first state. In some embodiments, if the fifth message includes the second verification information and the second verification information passes verification, the first device maintains the second state.

[1207] In some embodiments, the fifth message may include the second verification information but not the second identifier.

[1208] S4305: The second device receives the sixth message.

[1209] In some embodiments, the second device receives the sixth message from the first device.

[1210] In some embodiments, the sixth message is used to indicate whether the first device enters the first state.

[1211] In some embodiments, the sixth message is used by the first device to confirm with the second device whether it can enter the first state.

[1212] In some embodiments, the sixth message may include, but is not limited to, at least one of the following: an RRC connection establishment message, an RRC connection re-establishment message, or an RRC recovery message.

[1213] In some embodiments, the sixth message may be a message that is security-protected using the security context corresponding to the third identifier.

[1214] In other embodiments, the sixth message may be a message that is not security-protected.

[1215] In some embodiments, after receiving the fifth message, the first device confirms that it has entered the first state, and the first device does not need to determine again whether to request the second device to confirm whether to enter the first state. At this time, the first device sends a sixth message to the second device indicating that the first device has entered the first state or is determined to enter the first state.

[1216] S4306: The second device sends a seventh message.

[1217] In some embodiments, the second device sends a seventh message to the first device.

[1218] In some embodiments, the second device sends a seventh message to the first device based on the sixth message.

[1219] In some embodiments, the seventh message is used to indicate whether to agree or confirm that the first device enters the first state.

[1220] In some embodiments, in some embodiments, the seventh message may be a message that is security-protected using the security context corresponding to the third identifier.

[1221] In other embodiments, the seventh message may be a message that is not security-protected.

[1222] In some embodiments, when the sixth message passes verification, the seventh message indicates consent for the first device to enter the first state.

[1223] In some embodiments, when the sixth message fails verification, the seventh message indicates disagreement with the first device entering the first state.

[1224] S4307: The second device sends an eighth message.

[1225] In some embodiments, the second device sends an eighth message to the third device.

[1226] In some embodiments, the third device is a core network device.

[1227] In some embodiments, the third device includes at least one of the following:

[1228] Network functions NF of the core network CN;

[1229] Application function AF.

[1230] The CN NF may include but is not limited to: Access Management Function (AMF), Location Management Function (LMF), Session Management Function (SMF) and / or User Plane Function (UPF).

[1231] The AF may include but is not limited to an application server.

[1232] In some embodiments, the second device sends an eighth message to the third device when the first device enters the second state.

[1233] In some embodiments, the eighth message is used to indicate at least one of the following:

[1234] The first device enters a first state;

[1235] The first device re-enters the first state and continues to use the first security context;

[1236] The first security context of the first device continues to be used.

[1237] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the second device.

[1238] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the access network device.

[1239] In some embodiments, the first security context may be used for security protection of communications between the first device and the third device.

[1240] For example, the first security context may be used for security protection of Non Access Stratum (NAS) messages between the first device and the core network device.

[1241] In some embodiments, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[1242] It is worth noting that: some embodiments include S4301, and the remaining steps are optional steps. The second device can instruct the first device to save the first security context when entering the second state through the first message. The second device originally saves the first security context used by the first device in the first state.

[1243] It is worth noting that some embodiments include S4301 and S4307, and the remaining steps are optional. The second device can instruct the first device to save the first security context when entering the second state through the first message. The second device already saves the first security context used by the first device in the first state.

[1244] Some embodiments include S4301 to S4303, and the remaining steps are optional. After the first device enters the second state, it is shut down or stays in the second state for a long time or moves to another location, then the second device may not be required to operate in the subsequent steps.

[1245] Some embodiments include S4301 to S4303 and S4307, and the remaining steps are optional. After the first device enters the second state, it is shut down or stays in the second state for a long time or moves to another location, then the second device may not be required to operate in the subsequent steps.

[1246] Some embodiments include S4301 and S4303, and the remaining steps are optional. For example, if the second device sends a first message without the first device responding to the first message, it is assumed that the first device will save the first security context when entering the second state. If the first device then enters the second state and then shuts down, remains in the second state for an extended period, or moves to another location, the second device may not be required to perform subsequent steps.

[1247] Some embodiments include S4301, S4303, and S4307, and the remaining steps are optional. For example, if the second device sends a first message without the first device responding to the first message, it is assumed that the first device will save the first security context when entering the second state. If the first device then enters the second state and then shuts down, remains in the second state for an extended period, or moves to another location, the second device may not be required to perform subsequent steps.

[1248] Some embodiments include S4301, S4303 to S4304, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it is retained unless a specific reset event is met, and the second device sends the fifth message, which defaults to the first device entering the first state. In this case, the second device does not need to receive the sixth message.

[1249] Some embodiments include S4301, S4303 to S4304 to S4306, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it is retained unless a specific reset event is met, and the second device sends the fifth message, which defaults to the first device entering the first state. In this case, the second device does not need to receive the sixth message.

[1250] Some embodiments include S4301 to S4306, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it can be continuously saved unless a specific reset event is met. In this case, the second device does not need to send the eighth message to the third device.

[1251] Some embodiments include S4301, S4303 to S4304, and S4306, and the remaining steps are optional. For example, once the third device sets the first security context for the first device, it is retained unless a specific reset event is met, and the second device sends the fifth message, which defaults to the first device entering the first state. In this case, the second device does not need to receive the sixth message.

[1252] As shown in FIG5 , an embodiment of the present disclosure provides a security context processing method, the method comprising:

[1253] S5101: The third device saves the first security context of the first device.

[1254] In some embodiments, the third device is a core network device.

[1255] In some embodiments, the third device includes at least one of the following:

[1256] Network functions NF of the core network CN;

[1257] Application function AF.

[1258] The CN NF may include but is not limited to: Access Management Function (AMF), Location Management Function (LMF), Session Management Function (SMF) and / or User Plane Function (UPF).

[1259] The AF may include but is not limited to an application server.

[1260] S5102: The third device receives the eighth message.

[1261] In some embodiments, the third device receives the eighth message sent by the second device.

[1262] In some embodiments, the eighth message is used to indicate at least one of the following:

[1263] The first device enters a first state;

[1264] The first device re-enters the first state and continues to use the first security context;

[1265] The first security context of the first device continues to be used.

[1266] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the second device.

[1267] In some embodiments, the first security context may be used for security protection of wireless communications between the first device and the access network device.

[1268] In some embodiments, the first security context may be used for security protection of communications between the first device and the third device.

[1269] For example, the first security context may be used for security protection of Non Access Stratum (NAS) messages between the first device and the core network device.

[1270] In some embodiments, since the first device saves the first security context when entering the second state, the device can continue to use the first security context when it enters the first state again, without the need to renegotiate the security context for wireless communication of the first device, thereby saving power consumption.

[1271] The disclosed embodiments aim to provide an optimized method for managing the security context between ambient IoT devices and gNBs, auxiliary nodes, intermediate nodes, or terminals, ensuring that ambient IoT devices can enter the RRC_CONNECTED state without regenerating a new security context. These disclosed embodiments define a user plane CIoT 5GC optimization method. This optimization enables the suspension and resumption of the RRC connection between an ambient IoT device and a gNB without releasing and re-establishing it. This eliminates the need for the ambient IoT device to regenerate a new security context each time it enters the connected state, significantly conserving the device's resources.

[1272] The disclosed embodiments are based on the user plane CIoT 5GC optimization method defined in 3GPP TS 33.501[2]. This optimization allows the RRC connection between an ambient IoT device and a gNB to be suspended and resumed without releasing and re-establishing it. This eliminates the need for the ambient IoT device to regenerate a new security context each time it enters a connected state, significantly saving resources on the ambient IoT device. The ambient IoT device is in the RRC_Connected / connected / active state. The security context is stored in the ambient IoT device and the gNB / intermediate node / assistant node / UE.

[1273] As shown in FIG6A , an embodiment of the present disclosure provides a method, which may include:

[1274] 1. The gNB / Intermediate Node / Assistance Node / Terminal triggers the suspension process based on service requirements or device capabilities. For example, to save power in ambient IoT devices, the gNB / Intermediate Node / Assistance Node / UE may terminate their connections after receiving stored / perceived information. The gNB / Intermediate Node / Assistance Node / Terminal may also initiate a suspension process triggered by a timer or other means.

[1275] 2. The gNB / intermediate node / assistant node / terminal sends a suspend request containing an identifier, suspend indication, and security parameters to the ambient IoT device. The suspend request is protected by the current security context.

[1276] Note: This identifier is used for context identification or device identification. The Ambient IoT Device ID portion of the identifier assigned by the gNB / intermediate node / assistant node / terminal must be different for consecutive connections of the same Ambient IoT Device.

[1277] 3. The ambient IoT device enters the Suspended / Inactive / IDLE state and stores its identifier along with the current security context. The ambient IoT device sends a Suspend Response to the gNB / intermediate node / assistant node / terminal. The Suspend Response message is protected by the current security context.

[1278] 4. Upon receiving the Suspend Response, the gNB / Intermediate Node / Assistant Node / UE stores the context identifier along with the current Ambient IoT Device security context and marks the state of the Ambient IoT Device as IDLE with Suspend Status / Inactive State.

[1279] As shown in FIG6B , an embodiment of the present disclosure provides a method, which may include:

[1280] 0. The ambient IoT device is in IDLE state and is suspended / inactive. The security context is stored along with the identifier and maintained by the ambient IoT device and the gNB / intermediate node / assistant node / UE.

[1281] 1. The Ambient IoT Device sends a Resume Request message to the gNB / Intermediate Node / Assistance Node / Terminal, including an identifier. This identifier should be the same as the identifier received by the Ambient IoT Device from the gNB / Intermediate Node / Assistance Node / UE in the Suspend Request message. The Resume Request message is unprotected and may include security information derived from the stored security context and the associated identifier.

[1282] 2. After receiving the Resume Request message, the gNB / intermediate node / assistant node / terminal uses the identifier to retrieve the security context and verify the security information.

[1283] NOTE: Ambient IoT devices and gNB / intermediate node / assistant node / terminal can generate the same security information based on the stored security context and associated identifiers.

[1284] 3. If the verification succeeds, the gNB / intermediate node / assistant node / UE returns a resume response, which is protected by the retrieved security context. The gNB / intermediate node / assistant node / UE marks the state of the ambient IoT device as connected / active.

[1285] 4. If the recovery response verification is successful, the ambient IoT device enters the connected state / active state.

[1286] 5. The gNB / intermediate node / assistant node / UE can notify the 5GC NF / AF by sending an ambient IoT device report message.

[1287] The ambient IoT device is in IDLE state and is suspended / inactive. The security context is stored along with the identifier and maintained by the ambient IoT device and the gNB / intermediate node / assistant node / UE.

[1288] As shown in FIG6C , an embodiment of the present disclosure provides a method, which may include:

[1289] 1. The gNB / Intermediate Node / Assistance Node / UE decides to perform a recovery procedure, which can be triggered by the 5GC NF / AF or by a pre-configured timer associated with the Ambient IoT service.

[1290] 2. The gNB / intermediate node / assistant node / terminal sends a Resume Request / Paging Request containing the identifier to the ambient IoT device. The Resume Request / Paging Request is unprotected and may include security information derived from the stored security context and associated identifier.

[1291] 3. If the identifier contained in the RRC Resume Request / Paging Request matches the identifier provided by the upper layer or the gNB / Intermediate Node / Assistance Node / UE in the previous Suspend Request, and the security information is verified, the Ambient IoT device sends a Reply Response message to the gNB / Intermediate Node / Assistance Node / UE, which is protected by the stored security context. The Ambient IoT device enters the Connected / Active state.

[1292] 4. The gNB / intermediate node / assistant node / terminal verifies the recovery response message. If verification succeeds, the gNB / intermediate node / assistant node / terminal marks the ambient IoT device status as connected / active.

[1293] 5. The gNB / intermediate node / assistant node / UE can notify the 5GC NF / AF by sending an ambient IoT device report message.

[1294] As shown in FIG6D , an embodiment of the present disclosure provides a method, which may include:

[1295] 1. The gNB / Intermediate Node / Assistance Node / UE decides to perform a recovery procedure, which can be triggered by the 5GC NF / AF or by a pre-configured timer associated with the Ambient IoT service.

[1296] 2. The gNB / intermediate node / assistant node / terminal sends a paging request containing the identifier to the ambient IoT device. The paging request is unprotected and may include security information derived from the stored security context and the associated identifier.

[1297] 3. If the identifier included in the Paging Request is the same as the identifier provided by the upper level or the gNB / Intermediate Node / Assistance Node / UE in the previous Suspend Request and the verification is successful, the Ambient IoT Device sends a Resume Request message to the gNB / Intermediate Node / Assistance Node / UE protected by the stored security context.

[1298] 4. The gNB, auxiliary node, intermediate node, or terminal sends a recovery response message, which is protected by the stored security context and marks the state of the ambient IoT device as connected / active.

[1299] 5. The ambient IoT device enters the connected / active state.

[1300] 6. The gNB / intermediate node / assistant node / UE can notify the 5GC NF / AF by sending an ambient IoT device report message.

[1301] If the verification is successful, the ambient IoT device becomes connected / active.

[1302] When an ambient IoT device enters IDLE and is in a suspended / inactive state, it should be able to store the security context.

[1303] Ambient IoT devices should be able to store an identifier along with the security context.

[1304] When an ambient IoT device receives a suspend request message from a gNB, auxiliary node, intermediate node or terminal, it should be able to enter the IDLE state and remain in the suspended state / inactive state.

[1305] Ambient IoT devices shall be able to send a resume request to the gNB / Assistant Node / Intermediate Node / UE.

[1306] Ambient IoT devices should be able to generate and verify security information using stored security context and identifiers.

[1307] The gNB, auxiliary node, intermediate node or terminal shall be able to store the security context of the ambient IoT device when it enters the IDLE state and has a suspended state / inactive state.

[1308] The gNB, auxiliary node, intermediate node or terminal shall be able to store the identifier together with the security context.

[1309] The gNB, auxiliary node, intermediate node or terminal shall be able to send suspend request and resume request to the ambient IoT devices.

[1310] The gNB, auxiliary node, intermediate node or terminal shall be able to generate and verify security information using the stored security context and identifier.

[1311] In the embodiments of the present disclosure, some or all of the steps and their optional implementations may be arbitrarily combined with some or all of the steps in other embodiments, or may be arbitrarily combined with optional implementations in other embodiments.

[1312] In the embodiments of the present disclosure, some or all of the steps and their optional implementations may be arbitrarily combined with some or all of the steps in other embodiments, or may be arbitrarily combined with optional implementations in other embodiments.

[1313] The embodiments of the present disclosure also provide an apparatus for implementing any of the above methods. For example, an apparatus is provided, comprising units or modules for implementing each step performed by a terminal in any of the above methods. For another example, another apparatus is provided, comprising units or modules for implementing each step performed by a network device (e.g., an access network device or a core network device) in any of the above methods.

[1314] It should be understood that the division of the various units or modules in the above devices is merely a division of logical functions. In actual implementation, they may be fully or partially integrated into a physical entity, or they may be physically separated. In addition, the units or modules in the device may be implemented in the form of a processor calling software: for example, the device includes a processor, the processor is connected to a memory, and the memory stores instructions. The processor calls the instructions stored in the memory to implement any of the above methods or implement the functions of the various units or modules of the above devices, wherein the processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is a memory within the device or a memory outside the device. Alternatively, the units or modules in the device can be implemented in the form of hardware circuits, and the functions of some or all of the units or modules can be realized by designing the hardware circuits. The above-mentioned hardware circuits can be understood as one or more processors; for example, in one implementation, the above-mentioned hardware circuit is an application-specific integrated circuit (ASIC), which realizes the functions of some or all of the above units or modules by designing the logical relationship of the components in the circuit; for example, in another implementation, the above-mentioned hardware circuit can be realized by a programmable logic device (PLD). Taking a field programmable gate array (FPGA) as an example, it can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by configuring the configuration file, thereby realizing the functions of some or all of the above units or modules. All units or modules of the above devices can be realized in the form of software called by the processor, or in the form of hardware circuits, or in part by the form of software called by the processor, and the rest by hardware circuits.

[1315] In the embodiments of the present disclosure, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationship of a hardware circuit. The logical relationship of the above-mentioned hardware circuit is fixed or reconfigurable. For example, the processor is a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units or modules. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[1316] FIG7A is a diagram of a first device provided by an embodiment of the present disclosure, including:

[1317] The processing module 7101 is configured to use a first security context in a first state;

[1318] The storage module 7102 is configured to enter the second state from the first state and save the first security context.

[1319] In some embodiments, the first device further includes a receiving module and / or a sending module. In some embodiments, the receiving module and / or the sending module may correspond to specific structures such as an antenna or a network interface of the first device.

[1320] It is worth noting that the processing module of the first device can perform any steps related to information processing in the security context processing method performed by the first device. The sending module can be used for any steps related to receiving in the security context processing method performed by the first device. The sending module can be used for any steps related to sending in the security context processing method performed by the first device.

[1321] FIG7B is a second device provided by an embodiment of the present disclosure, comprising:

[1322] The storage module 7201 is configured to save the first device in the second state using the first security context in the first state.

[1323] In some embodiments, the receiving module and the sending module may correspond to specific structures such as an antenna or a network interface of a network device.

[1324] Optionally, the second device further includes a processing module, which can be configured to execute steps related to information processing in the security context processing method performed by the master node.

[1325] FIG7C is a schematic diagram of a third device provided by an embodiment of the present disclosure. The third device may include:

[1326] The receiving module 7301 is configured to receive the eighth message.

[1327] In some embodiments, the eighth message is used to indicate at least one of the following:

[1328] The first device re-enters the first state;

[1329] The first device re-enters the first state and continues to use the first security context;

[1330] The first security context of the first device continues to be used.

[1331] In some embodiments, the third device may further include a sending module.

[1332] The sending module can execute any operation related to the sending step in the security context processing method executed by the third device.

[1333] The receiving module can execute any operation related to the receiving step in the security context processing method executed by the third device.

[1334] In some embodiments, the third device may further include a processing module.

[1335] The processing module can execute any operation related to information processing in the security context processing method executed by the third device.

[1336] The present disclosure provides a security context processing method, which may include:

[1337] The first device may execute the security context processing method provided by any one of the aforementioned technical solutions executed by the first device; and

[1338] The second device may execute any of the security context processing methods provided by the aforementioned technical solutions executed by the master node, and / or,

[1339] The third device can execute the security context processing method provided by any of the aforementioned technical solutions executed by the secondary node.

[1340] An embodiment of the present disclosure further provides a communication device, which may include: one or more processors; wherein the processor is used to call instructions to enable the communication device to execute a security context processing method that can be implemented in any of the aforementioned embodiments.

[1341] 8A and / or 8B , the communication device 8100 further includes one or more memories 8102 for storing instructions. Alternatively, all or part of the memories 8102 may be located outside the communication device 8100.

[1342] The communication device may be the aforementioned first device and the network device. In some embodiments, the network device may be a master node and / or an auxiliary node.

[1343] In some embodiments, the communication device 8100 further includes one or more transceivers 8103. When the communication device 8100 includes one or more transceivers 8103, the communication steps such as sending and receiving in the above method are performed by the transceiver 8103, and the other steps are performed by the processor 8101.

[1344] In some embodiments, a transceiver may include a receiver and a transmitter, which may be separate or integrated. Optionally, the terms transceiver, transceiver unit, transceiver, and transceiver circuit may be used interchangeably; the terms transmitter, transmitting unit, transmitter, and transmitting circuit may be used interchangeably; and the terms receiver, receiving unit, receiver, and receiving circuit may be used interchangeably.

[1345] Optionally, the communication device 8100 further includes one or more interface circuits 8104, which are connected to the memory 8102. The interface circuits 8104 can be used to receive signals from the memory 8102 or other devices, and can be used to send signals to the memory 8102 or other devices. For example, the interface circuits 8104 can read instructions stored in the memory 8102 and send the instructions to the processor 8101.

[1346] The communication device 8100 described in the above embodiment may be a network device or a first device, but the scope of the communication device 8100 described in the present disclosure is not limited thereto, and the structure of the communication device 8100 may not be limited by FIG. 8A. The communication device may be an independent device or may be part of a larger device. For example, the communication device may be: (1) an independent integrated circuit IC, or a chip, or a chip system or subsystem; (2) a collection of one or more ICs, optionally, the above IC collection may also include a storage component for storing data or programs; (3) an ASIC, such as a modem; (4) a module that can be embedded in other devices; (5) a receiver, a first device device, an intelligent first device device, a cellular phone, a wireless device, a handheld device, a mobile unit, an in-vehicle device, a network device, a cloud device, an artificial intelligence device, etc.; (6) others, etc.

[1347] FIG8B is a schematic diagram of the structure of a chip 8200 provided in an embodiment of the present disclosure. If the communication device 8100 can be a chip or a chip system, please refer to the schematic diagram of the structure of the chip 8200 shown in FIG8B , but the present disclosure is not limited thereto.

[1348] The chip 8200 includes one or more processors 8201, and the processor 8201 is used to call instructions to enable the chip 8200 to execute any of the above security context processing methods.

[1349] In some embodiments, chip 8200 further includes one or more interface circuits 8202, which are connected to memory 8203. Interface circuit 8202 can be used to receive signals from memory 8203 or other devices, and can be used to send signals to memory 8203 or other devices. For example, interface circuit 8202 can read instructions stored in memory 8203 and send the instructions to processor 8201. Optionally, the terms interface circuit, interface, transceiver pin, and transceiver are interchangeable.

[1350] In some embodiments, the chip 8200 further includes one or more memories 8203 for storing instructions. Alternatively, all or part of the memories 8203 may be outside the chip 8200.

[1351] The present disclosure also provides a storage medium having instructions stored thereon, which, when executed on the communication device 8100, causes the communication device 8100 to execute any of the above methods. Optionally, the storage medium is an electronic storage medium. Optionally, the storage medium is a computer-readable storage medium, but may also be a storage medium readable by other devices. Optionally, the storage medium may be a non-transitory storage medium, but may also be a transient storage medium.

[1352] The present disclosure further provides a program product, which, when executed by the communication device 8100, enables the communication device 8100 to perform any of the above security context processing methods. Optionally, the program product is a computer program product.

[1353] The present disclosure also provides a computer program, which, when executed on a computer, enables the computer to execute any one of the above security context processing methods.

[1354] Other embodiments of the present invention will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered as exemplary only, with the true scope and spirit of the present invention being indicated by the following claims.

[1355] It should be understood that the embodiments of the present disclosure are not limited to the precise structures described above and shown in the drawings, and various modifications and changes can be made without departing from the scope thereof. The scope of the embodiments of the present disclosure is limited only by the appended claims.

Claims

1. A security context processing method, wherein: Executed by a first device, the method includes: using a first security context in a first state; Entering from the first state to the second state, saving the first security context.

2. The method according to claim 1, wherein: Before entering the second state from the first state, the method further includes: A first message is received from the second device, where the first message is used to instruct the first device to enter the second state and save the first security context.

3. The method according to claim 1 or 2, wherein: The first message includes at least one of the following: A first identifier, used to determine a first security context; The first indicator is used to indicate saving the first security context.

4. The method according to claim 3, wherein: The first identifier includes at least one of the following: A context identifier, used to identify the first security context; A device identifier, used to identify the first device, where different first devices have different security contexts; The device group identifier is used to identify the device group to which the first device belongs. Different device groups use different security contexts.

5. The method according to any one of claims 1 to 4, wherein: The method further comprises: authenticating the first message using the first security context; In case the first message passes the verification, the first device enters the second state.

6. The method according to any one of claims 1 to 5, wherein: The method further comprises: Before entering the second state, a second message is sent to the second device; the second message is at least used to indicate whether the first device confirms entering the second state and saving the first security context.

7. The method according to claim 6, wherein: The method further comprises: The second message is protected using the first security context.

8. The method according to any one of claims 1 to 7, wherein: The method comprises: A third message is sent to the second device, where the third message is used by the first device to request to enter the first state.

9. The method according to claim 8, wherein: The third message includes at least one of the following: A second identifier, used to indicate a security context used after the first device enters the first state; First verification information; the first verification information is used by the second device to verify the third message.

10. The method according to claim 8 or 9, wherein: The method further comprises: A fourth message sent by the second device is received; the fourth message is used to indicate whether the first device is allowed to enter the first state.

11. The method according to claim 10, wherein: The fourth message includes: an acceptance message, used to indicate that the first device is allowed to enter the first state, or, The rejection message is used to indicate that the first device is not allowed to enter the first state.

12. The method according to any one of claims 1 to 7, wherein: The method further comprises: A fifth message sent by the second device is received; the fifth message is used to instruct the first device to enter a first state.

13. The method according to claim 12, wherein: The fifth message includes at least one of the following: a third identifier, used to identify a security context used by the first device to enter the first state; The second verification information is used by the first device to verify the fifth message.

14. The method according to claim 12 or 13, wherein: The method further comprises: generating third verification information based on the first security context; The first state is entered when the third verification information matches the second verification information.

15. The method according to any one of claims 12 to 14, wherein: The method further comprises: A sixth message is sent to the second device; the sixth message is used to indicate whether the first device enters the first state, or the sixth message is used by the first device to prepare to enter the first state to the second device.

16. The method according to claim 15, wherein: The method further comprises: Receive a seventh message sent by the second device; the seventh message is used to indicate whether to agree or confirm that the first device enters the first state.

17. The method according to claim 16, wherein: The method further comprises: According to the seventh message, it is determined whether to maintain the first state of the first device.

18. The method according to claim 17, wherein: The determining, according to the seventh message, whether to maintain the first state of the first device includes: When the seventh message indicates that the first device is not allowed to enter the first state, the first device returns to the second state, or, After the seventh message indicates that the first device is approved to enter the first state, the first device maintains the first state.

19. The method according to claim 16 or 17, wherein: The method further comprises: Verify the seventh message using the security context indicated by the third identifier; The determining, according to the seventh message, whether to maintain the first state of the first device includes: According to the verified seventh message, it is determined whether to maintain the first state of the first device.

20. The method according to claim 19, wherein: The method further comprises: If the seventh message fails to pass the verification, the first device returns to the second state or resends the sixth message to the second device.

21. The method according to any one of claims 1 to 20, wherein: The first device is an environmental physical network IoT device.

22. A security context processing method, wherein: Executed by a second device, the method includes: The first device storing the second state uses the first security context in the first state.

23. The method according to claim 22, wherein: The method further comprises: A first message is sent to the first device, where the first message is used to instruct the first device to enter the second state and save the first security context.

24. The method according to claim 23, wherein: The first message includes at least one of the following: A first identifier, used to indicate a first security context; The first indicator is used to indicate saving the first security context.

25. The method according to claim 24, wherein: The first identifier includes at least one of the following: A context identifier, used to identify the first security context; A device identifier, used to identify the first device, where different first devices have different security contexts; The device group identifier is used to identify the device group to which the first device belongs. Different device groups use different security contexts.

26. The method according to any one of claims 23 to 25, wherein: The method further comprises: Receive a second message sent by the first device; the second message is at least used to indicate whether the first device confirms entering the second state and saving the first security context.

27. The method according to claim 26, wherein: The method further comprises: When the second message passes the verification based on the first security context, it is recorded that the first device enters the second state.

28. The method according to any one of claims 22 to 27, wherein: The method further comprises: A third message sent by a first device is received, where the third message is used by the first device to request to enter a first state.

29. The method according to claim 28, wherein: The third message includes at least one of the following: A second identifier, used to indicate a security context used after the first device enters the first state; First verification information; the first verification information is used by the second device to verify the third message.

30. The method of claim 29, wherein: The method further comprises: generating fourth verification information based on the security context indicated by the second identifier; When the fourth verification information matches the first verification information, determining to allow the first device to enter the first state, recording the first device entering the first state, and saving the security context indicated by the second identifier, or, When the fourth verification information does not match the first verification information, it is determined that the first device is not allowed to enter the first state.

31. The method according to any one of claims 28 to 30, wherein: The method further comprises: A fourth message is sent to the first device; the fourth message is used to indicate whether the first device is allowed to enter the first state.

32. The method according to claim 31, wherein: The fourth message includes: an acceptance message, used to indicate that the first device is allowed to enter the first state, or, The rejection message is used to indicate that the first device is not allowed to enter the first state.

33. The method according to any one of claims 22 to 25, wherein: The method further comprises: A fifth message is sent to the first device; the fifth message is used to instruct the first device to enter a first state.

34. The method of claim 33, wherein: The fifth message includes at least one of the following: a third identifier, used to identify a security context used by the first device to enter the first state; The second verification information is used by the first device to verify the fifth message.

35. The method according to claim 33 or 34, wherein: The method further comprises: Receive a sixth message sent by the first device; the sixth message is used to indicate whether the first device enters the first state, or the sixth message is used by the first device to prepare to enter the first state to the second device.

36. The method of claim 35, wherein: The method further comprises: The verification result of the sixth message is verified based on the security context indicated by the third identifier, and a seventh message is sent to the first device; the seventh message is used to indicate whether the first device is allowed to enter the first state.

37. The method of claim 36, wherein: When the sixth message passes verification, the seventh message indicates that the first device is allowed to enter the first state, or, When the sixth message fails to pass the verification, the seventh message indicates that the first device is not allowed to enter the first state.

38. The method according to any one of claims 22 to 37, wherein: The method further comprises: Sending an eighth message to the third device; the eighth message is used to indicate at least one of the following: The first device enters the first state; The first device re-enters the first state and continues to use the first security context; Continue to use the first security context of the first device.

39. The method of claim 38, wherein: The third device includes at least one of the following: Network functions NF of the core network CN; Application functions AF.

40. A security context processing method, wherein: Executed by a third device, the method includes: An eighth message is received; the eighth message is used to indicate at least one of the following: The first device re-enters the first state; The first device re-enters the first state and continues to use the first security context; The first security context of the first device continues to be used.

41. A first device, wherein: include: A processing module configured to use a first security context in a first state; The storage module is configured to enter the second state from the first state and save the first security context.

42. A second device, wherein: include: The storage module is configured to save the first device in the second state using the first security context in the first state.

43. A third device, wherein: include: The receiving module is configured to receive an eighth message; the eighth message is used to indicate at least one of the following: The first device re-enters the first state; The first device re-enters the first state and continues to use the first security context; The first security context of the first device continues to be used.

44. A communication device, wherein: The communication device comprises: one or more processors; The processor is used to call instructions so that the communication device executes the security context processing method described in any one of claims 1 to 21, 22 to 40, and / or claim 40.

45. A storage medium, wherein: The storage medium stores instructions, which, when executed on a communication device, enable the communication device to execute the security context processing method described in any one of claims 1 to 21, 22 to 40, and / or claim 40.

Images