Steering roaming enhancements during registration rejection
By introducing the SoR update mechanism during registration rejection, the collaborative work between the terminal device, AMF and UDM solves the problems of SoR data tampering and incomplete ACK confirmation, realizes the integrity protection of SoR data and the reliable transmission of ACK, and improves the security and reliability of roaming services.
Patent Information
- Application Number
- CN202480015524.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-04-04
- Filing Date
- 2024-03-11
- Publication Date
- 2025-10-10
AI Technical Summary
During the registration rejection period, the SoR data in the prior art may be tampered with, and the ACK confirmation mechanism is imperfect, resulting in the roaming service for the roaming user being unable to be effectively carried out.
By introducing the SoR update mechanism in the Registration Reject message, the terminal device sends a Registration Request indicating SoR update support to the AMF, and receives a Registration Reject message containing MAC-I for integrity protection verification to ensure the security of SoR data and reliable transmission of ACK.
It implements integrity protection of SoR data and reliable transmission of ACK during registration rejection, ensuring that roaming users can safely select and reside in the recommended VPLMN, and improving the reliability and security of roaming services.
Smart Images

Figure CN120770191A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] Embodiments of the present disclosure generally relate to the field of telecommunications, and in particular, to devices, methods, apparatuses, and computer-readable storage media for steering of roaming (SoR) enhancements during registration reject. BACKGROUND
[0002] Roaming value added services (RVAS) form part of the roaming service ecosystem and have been discussed in the Global System for Mobile Communications Association (GSMA). RVAS can be provided by a public land mobile network (PLMN) or outsourced by a PLMN to a fully trusted entity behaving like an RVAS provider, an Internet Protocol Exchange (IPX) provider, or a roaming hub provider. RVAS is consumed by a roaming subscriber or the roaming subscriber’s home network. SUMMARY
[0003] Generally, example embodiments of the present disclosure provide solutions for SoR enhancements during registration reject.
[0004] In a first aspect, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to send, to an access and mobility management function (AMF), a registration request indicating at least that SoR update is supported in a registration reject message, the AMF being associated with a visited public land mobile network (VPLMN) on which the apparatus is intended to camp; receive a registration reject message including an acknowledgement request, SoR information, and a message authentication code-integrity (MAC-I) of a home network.
[0005] In a second aspect, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to receive, from a terminal device, a registration request indicating at least that SoR update is supported in a registration reject message, the apparatus being associated with a VPLMN on which the terminal device is intended to camp; and provide, to a unified data management (UDM) function, an indication that SoR update is supported in a registration reject message.
[0006] In a third aspect, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to receive, from an AMF, an indication that SoR update is supported in a registration reject message, the AMF being associated with a VPLMN on which a terminal device is intended to camp; and determine that a registration reject message is to be sent to the terminal device.
[0007] In a fourth aspect, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least receive an indication from a UDM function that SoR update is supported in a registration reject message; and based on determining that the registration reject message is to be sent to a terminal device, provide the UDM with at least one recommended VPLMN on which the terminal device is to reside.
[0008] In a fifth aspect, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least send an authentication response to the AMF, the authentication response including a confirmation request, SoR information, and a MAC-I of a home network.
[0009] In a sixth aspect, a method is provided. The method comprises sending a registration request from a terminal device to an AMF, the registration request indicating at least that SoR update is supported in a registration reject message, the AMF being associated with a VPLMN on which the terminal device is to reside; and receiving a registration reject message including an acknowledgement request, SoR information, and a MAC-I of a home network.
[0010] In a seventh aspect, a method is provided. The method comprises receiving, at an AMF, from a terminal device a registration request, the registration request indicating at least that SoR update is supported in a registration reject message, the AMF being associated with a VPLMN on which the terminal device is to reside; and providing an indication that SoR update is supported in the registration reject message to a UDM function.
[0011] In an eighth aspect, a method is provided. The method includes receiving, at a UDM and from an AMF, an indication that SoR update is supported in a registration reject message, the AMF being associated with a VPLMN on which a terminal device is to reside; and determining that a registration reject message is to be sent to the terminal device.
[0012] In a ninth aspect, a method is provided, comprising receiving, at a SoR application, an indication from a UDM function in a registration reject message that SoR update is supported, and providing, to the UDM function, at least one recommended VPLMN on which the terminal device is to reside based on a determination that the registration reject message is to be sent to the terminal device.
[0013] In a tenth aspect, a method is provided. The method includes sending an authentication response from the AUSF to the AMF, the authentication response including a confirmation request, SoR information and a MAC-I of the home network.
[0014] In an eleventh aspect, an apparatus is provided, comprising means for sending a registration request to an AMF, the registration request indicating at least that SoR update is supported in a registration reject message, the AMF being associated with a VPLMN on which the apparatus is to reside; and means for receiving a registration reject message, the registration reject message including a confirmation request, SoR information, and a MAC-I of a home network.
[0015] In a twelfth aspect, an apparatus is provided, comprising means for receiving a registration request from a terminal device, the registration request indicating at least that SoR updates are supported in a registration reject message, the apparatus being associated with a VPLMN on which the terminal device is intended to reside; and means for providing an indication that SoR updates are supported in the registration reject message to a UDM function.
[0016] In a thirteenth aspect, an apparatus is provided, comprising means for receiving an indication that SoR update is supported in a registration reject message from an AMF, the AMF being associated with a VPLMN on which a terminal device is to reside; and means for determining that a registration reject message is to be sent to the terminal device.
[0017] In a fourteenth aspect, an apparatus is provided comprising means for receiving an indication from a UDM function that SoR update is supported in a registration reject message; and means for providing the UDM with at least one recommended VPLMN in which the terminal device is to reside based on determining that the registration reject message is to be sent to the terminal device.
[0018] In a fifteenth aspect, an apparatus is provided, comprising means for sending an authentication response to an AMF, the authentication response comprising a confirmation request, SoR information, and a MAC-I of a home network.
[0019] In the sixteenth aspect, a computer-readable medium having a computer program stored thereon is provided, which, when the computer program is executed by at least one processor of an apparatus, causes the apparatus to perform a method according to the sixth aspect, the seventh aspect, the eighth aspect, the ninth aspect or the tenth aspect.
[0020] Other features and advantages of the embodiments of the present disclosure will become apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The embodiments of the present disclosure are presented by way of example, and advantages thereof will be explained in more detail below with reference to the accompanying drawings.
[0022] Figure 1 illustrates an example environment in which example embodiments of the present disclosure may be implemented;
[0023] Figure 2 shows a signaling diagram illustrating an example of a flow according to some example embodiments of the present disclosure;
[0024] Figure 3 shows a signaling diagram illustrating an example of a flow according to some example embodiments of the present disclosure;
[0025] Figure 4 A flowchart illustrating an example method of SoR enhancement during registration rejection according to some example embodiments of the present disclosure;
[0026] Figure 5 A flowchart illustrating an example method of SoR enhancement during registration rejection according to some example embodiments of the present disclosure;
[0027] Figure 6 A flowchart illustrating an example method of SoR enhancement during registration rejection according to some example embodiments of the present disclosure;
[0028] Figure 7 A flowchart illustrating an example method of SoR enhancement during registration rejection according to some example embodiments of the present disclosure;
[0029] Figure 8 A flowchart illustrating an example method of SoR enhancement during registration rejection according to some example embodiments of the present disclosure;
[0030] Figure 9 shows a simplified block diagram of a device suitable for implementing an example embodiment of the present disclosure; and
[0031] Figure 10 A block diagram of an example computer-readable medium is shown, according to some embodiments of the present disclosure.
[0032] The same or similar reference numbers may be used throughout the drawings to refer to the same or similar elements. DETAILED DESCRIPTION
[0033] The principles of the present disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described only for the purpose of illustrating and helping those skilled in the art to understand and implement the present disclosure, and do not represent any limitation on the scope of the present disclosure. The embodiments described herein can be implemented in various other ways in addition to the ways described below.
[0034] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein may have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.
[0035] In this disclosure, references to “one embodiment,” “an embodiment,” “example embodiments,” etc. mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
[0036] It should be understood that, although the terms “first,” “second,” etc. can be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element without departing from the scope of the example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed terms.
[0037] As used herein, “at least one of ” and “one or more of ” and similar phrases, where the list of two or more elements is preceded by “and” or “or,” means at least any one element, or at least any two or more elements, or at least all elements.
[0038] As used herein, unless expressly stated otherwise, performing a step “in response to A” does not indicate that the step is performed immediately after A occurs, and can include one or more intervening steps.
[0039] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “has,” “having,” “includes” and / or “including” when used herein, specify the presence of stated features, elements and / or components etc. but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.
[0040] As used in this application, the term “circuitry” can refer to one or more or all of the following:
[0041] (a) hardware-only circuitry implementations (such as implementations in only analog and / or digital circuitry) and (a) hardware-only circuitry implementations (such as implementations in only analog and / or digital circuitry) and
[0042] (b) a combination of hardware circuitry and software such as (as applicable):
[0043] (i) a combination of (one or more) analog and / or digital hardware circuits and software / firmware, and
[0044] (ii) any portion of hardware processor(s) (including digital signal processor(s)), software and memory(s) with software that work together to enable a device (such as a mobile phone or server) to perform various functions, and
[0045] (c)(one or more) hardware circuits and / or(one or more) processors, such as(one or more) microprocessors or portions of(one or more) microprocessors, that require software (e.g., firmware) to operate, but the software may not be present when not required for operation.
[0046] This definition of "circuitry" applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term "circuitry" also covers an implementation of merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its accompanying software and / or firmware. For example, if applicable to the particular claim element, the term "circuitry" also covers a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or networking device.
[0047] As used herein, the term "communication network" refers to a network that complies with any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), Advanced LTE (LTE-A), Wideband Code Division Multiple Access (WCDMA), High Speed Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), Enhanced Machine Type Communication (eMTC), etc. In addition, the communication between the terminal device and the network device in the communication network can be performed according to any suitable generation of communication protocol, including but not limited to first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G), sixth generation (6G) communication protocols, and / or any other protocol currently known or to be developed in the future. The embodiments of the present disclosure can be applied to various communication systems. Considering the rapid development of communications, there will certainly be future types of communication technologies and systems that can embody the present disclosure. The scope of the present disclosure should not be limited to the above-mentioned systems.
[0048] As used herein, the terms “network device,” “radio network device,” and / or “radio access network device” refer to a node terminal device through which a node accesses a network and receives services therefrom in a communication network. The network device can refer to a base station (BS) or an access point (AP), e.g., a Node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also known as gNB), a remote radio unit (RRU), a remote radio head (RRH), a relay, an integrated access and backhaul (IAB) node, a low power node (such as a femto, pico), a non-terrestrial network (NTN) or non-terrestrial network device (such as a satellite network device, low earth orbit (LEO) satellite, and geosynchronous earth orbit (GEO) satellite), an airplane network device, etc., depending on the terminology applied and the technology. In some example embodiments, a near-earth orbit (RAN) split architecture includes a centralized unit (CU) and a distributed unit (DU). In some other example embodiments, part or all of the radio access network device can be piggybacked on an airborne or spaceborne NTN aircraft.
[0049] The term “terminal device” refers to any terminal device that can be capable of wireless communication. By way of example, and without limitation, a terminal device can also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). A terminal device can include, but is not limited to, a mobile telephone, a cellular telephone, a smart phone, a voice over Internet Protocol (VoIP) telephone, a wireless local loop phone, a tablet, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, an image capture terminal device, such as a digital camera, a game terminal device, a music storage and playback appliance, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a USB dongle, a smart device, a wireless customer-premise equipment (CPE), an Internet of Things (loT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), consumer electronics, devices operating on a business and / or industrial wireless network, etc. A terminal device can also correspond to a mobile terminal (MT) part of an IAB node (e.g., a relay node). In the following description, the terms “terminal device,” “communication device,” “terminal,” “user equipment,” and “UE” can be used interchangeably.
[0050] As used herein, the terms "resource", "transmission resource", "resource block", "physical resource block" (PRB), "uplink resource" or "downlink resource" may refer to any resource used to perform communication (e.g., communication between a terminal device and a network device), such as a resource in the time domain, a resource in the frequency domain, a resource in the space domain, a resource in the code domain, or any other resource that enables communication. Hereinafter, unless explicitly stated otherwise, some example embodiments of the present disclosure will be described using resources in both the frequency domain and the time domain as examples of transmission resources. It should be noted that the example embodiments of the present disclosure are also applicable to other resources in other domains.
[0051] Figure 1 1 shows an example communication environment 100 in which embodiments of the present disclosure may be implemented. Figure 1 As shown, the communication environment 100 may include a terminal device 110. Hereinafter, the terminal device 110 may also be referred to as a user equipment (UE).
[0052] The communication environment 100 may also include multiple core network (CN) nodes. For example, the communication environment 100 may include a first AMF 120-1 (also referred to as an AMF in this disclosure) and a second AMF 120-2 (also referred to as another AMF in this disclosure). The first AMF 120-1 and the second AMF 120-2 may be associated with different VPLMNs.
[0053] The AMF receives information related to all connections and sessions from the UE and is responsible for handling connection and mobility management tasks. The UE specifies a globally unique AMF identifier (GUAMI) in the first non-access stratum (NAS) message it sends, which is routed to the desired AMF by the radio access network (RAN). Furthermore, the AMF is responsible for managing handovers between gNBs within the next-generation radio access network (NG-RAN).
[0054] The communication environment 100 may also include an authentication server function (AUSF) 140, which may be responsible for security procedures for authentication. For example, the AMF 120-1 (acting as a service consumer) may request authentication of the UE from the AUSF 140 (acting as a service provider) by providing information associated with the terminal device 110. The AUSF may provide one or more keys for authentication of the terminal device 110.
[0055] In addition, the communication environment 100 may also include a UDM 130. The UDM 130 may be responsible for AKA authentication credentials, access authorization based on subscription data (e.g., roaming restrictions), and NF registration management of service end devices. For example, the AUSF 140 (acting as a service provider) may provide the SoR MAC-I to the UDM 130 (acting as a service consumer) via the SoR protection service. AUSF To prevent the information list from being tampered with or deleted by the VPLMN.
[0056] The communication environment 100 may also include an application function (AF) that may communicate with the UDM 130, such as the SoR AF 150. For example, the SoR AF may provide SoR services to the UDM 130 (acting as a service consumer) via an Nsoraf service-based interface to enable retrieval of SoR information to be communicated to the terminal device 110.
[0057] It should be understood that Figure 1 The number of network nodes and terminal devices shown is given for illustrative purposes and does not imply any limitation. Communication environment 100 may include any suitable number of network nodes and terminal devices.
[0058] Communications in the communication environment 100 may be implemented according to any suitable communication protocol, including but not limited to first generation (1G), second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G), sixth generation (6G), etc. cellular communication protocols, wireless local area network communication protocols such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, and / or any other protocol currently known or to be developed in the future. In addition, communications may utilize any suitable wireless communication technology, including but not limited to: code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), frequency division duplex (FDD), time division duplex (TDD), multiple input multiple output (MIMO), orthogonal frequency division multiplexing (OFDM), discrete Fourier transform spread OFDM (DFT-s-OFDM), and / or any other technology currently known or to be developed in the future.
[0059] As mentioned above, RVAS can be consumed by a roaming subscriber or the home network of a roaming subscriber, and the discussion of RVAS can focus on RVAS for 5GS roaming enabled by PLMN. There are several use cases of RVAS in 5GS enabled by PLMN, such as welcome short message service (SMS), SoR during the registration process, and international mobile subscriber identity (IMSI)-based routing to a specific core network.
[0060] In the case of roaming, the Home Public Land Mobile Network (HPLMN) can direct its subscribers to a preferred partner network by issuing commands using SMS or via signaling and updating the operator-controlled PLMN selector list on the Universal Subscriber Identity Module (USIM).
[0061] In addition, to balance the distribution among VPLMNs in the short term, operators use mechanisms to reject registration attempts from certain shared UEs to certain VPLMNs, causing them to select different VPLMNs.
[0062] Both mechanisms may be applied in parallel by the HPLMN, ie SoR as defined in 3GPP and SoR during the registration procedure as described herein.
[0063] The use case described below explains how the home operator can identify that a roaming user is attempting to register in a new network and trigger a rejection message to the UE, causing the UE to attempt to register in another VPLMN.
[0064] For example, users X and Y subscribe to operator HPLMN1. Both users travel to another country where two networks are available: VPLMN1 and VPLMN2. Both networks have roaming agreements with HPLMN1. VPLMN1 has a higher priority for both users.
[0065] When users X and Y arrive in the country and connect their UEs, both UEs can select VPLMN1 as their first choice for registration and attempt to register on that network. VPLMN1 forwards the registration request messages from users X and Y's UEs to HPLMN1. HPLMN1 recognizes the registration attempts and invokes a bootstrapping service via a northbound API. The bootstrapping service, hosted by the HPLMN or a trusted third party, determines whether any bootstrapping actions are required for either UE. In this use case, it decides to allow user X's UE to register on VPLMN1, while user Y's UE should not use VPLMN1.
[0066] The bootstrapping service may use the northbound application programming interface (API) of user Y's UE to trigger a bootstrapping action, which results in a rejection message including an appropriate rejection reason being sent to user Y's UE. The registration process for user Y's UE is not affected.
[0067] When user X's UE successfully registers with VPLMN1, user Y's UE can select VPLMN2 as the only other available network and register there. If more than one remaining VPLMN is available, user Y's UE can select one of them according to the network selection process. The rejection process can be repeated as needed.
[0068] In the use case described above, during initial registration, if authentication is not completed or authentication is rejected (or registration is rejected), the UE does not have the latest K AUSF In this scenario, the UE may not perform integrity protection checks, i.e. the UE cannot generate a MAC.
[0069] Therefore, if the SoR container (ie, SoR information) is transmitted in the Registration Reject, the UE may not perform an integrity protection check on the SoR container, and the SoR data may be tampered with.
[0070] Furthermore, if a SoR is sent in a Registration Reject, another issue with acknowledgment (ACK) may arise. Specifically, if the UDM has requested the UE to send an ACK for the SoR data, how will the UE send the ACK if the UE's connection to the network is closed after the Registration Reject? Without an ACK, the UDM may assume that the ACK was not received and mark the PLMN as untrustworthy. Therefore, if a SoR is sent in a Registration Reject, a way should be defined for the UE to send an ACK back to the UDM.
[0071] Therefore, embodiments of the present disclosure propose an enhanced mechanism during registration rejection. In this solution, the terminal device 110 sends a registration request to the AMF associated with the VPLMN on which the device is to reside, the registration request at least indicating that SoR update is supported in the registration reject message, and the terminal device 110 receives a registration reject message from the AMF, the registration reject message including an ACK request, SoR information, and the MAC-I of the home network.
[0072] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.
[0073] In some scenarios, SoR information may be included during initial registration / authentication rejection of the terminal device 110, which may be referenced as follows: Figure 2 To describe.
[0074] Now refer to Figure 2 , which shows a signaling diagram 200 for communication according to some example embodiments of the present disclosure. Figure 2 As shown, the signaling diagram 200 includes the terminal device 110, the first AMF 120-1, the second AMF 120-2, the AUS F 140, the UDM 130 and the SoR AF 150. For the purpose of discussion, reference is made to Figure 1 2. Signaling diagram 200 is described below.
[0075] AMF 120-1 may be associated with a first VPLMN, and AMF 120-2 may be associated with a second VPLMN.
[0076] like Figure 2 As shown, the terminal device 110 may send (202) a registration request to the AMF 120-1 to camp on the first VPLMN. The registration request may at least indicate that SoR update is supported in the registration reject message. For example, the support of SoR update in the registration reject message may be indicated by a flag in the registration request. The flag may also indicate that support for SoR update is not set in the registration reject message. This flag may distinguish UEs that do not support this new feature from UEs that support this new feature at the UDM 130, regardless of whether the SoR container (i.e., SoR information) in the registration reject message is accepted.
[0077] AMF 120-1 may send (204) an authentication request with the same flag indicating support for SoR update in the Registration Reject message to UDM 130 via AUSF 140. UDM 130 may then store the UE capability, ie, support for SoR update, in the Registration Reject message.
[0078] UDM 130 may then notify SoR AF 150 (208) of the authentication request with UE capabilities. SoR AF 150 may provide UDM 130 (210) a security packet including at least a list of recommended VPLMNs and request that the packet be sent in the Registration Reject message. Alternatively, UDM 130 may also generate one or more recommended VPLMNs for the SoR information, which may be provided as a security packet in the Registration Reject message.
[0079] In addition, UDM 130 may also inform AUSF 140 (212) that SoR information is to be sent in the Registration Reject message. AUSF 140 may then generate (214) the MAC-I of the home network, ie, MAC-I HN and provides it (216) to UDM 130. HN The details will be described later.
[0080] Based on the generated MAC-I HN , the SoR information is integrity protected. If an ACK is expected from the terminal device 110, the generated MAC-I may be stored. HN Used for later verification.
[0081] The UDM 130 may then send (218) a registration reject message to the terminal device 110 because the first VPLMN is not a recommended VPLMN in which the terminal device should reside. The registration reject message sent (218) from the UDM 130 may first reach the AMF 120-1, and then the AMF 120-1 may send the registration reject message to the terminal device 110. The registration reject message may include at least one recommended VPLMN and other parameters such as a request for ACK, SoR information, and MAC-I HN .
[0082] Since the UDM 130 expects the terminal device 110 to respond with an ACK in the next registration process, which may or may not occur immediately, the UDM 130 may send the expected MAC-I HN Stored in the UDR storage device and wait for the next registration process.
[0083] Since SoR update is supported, the terminal device 110 can accept the SoR data in the registration rejection message and update the SoR data based on the MAC-I HN The received SoR information is integrity-protected and verified. The security packet is sent to the USIM for de-hiding and storage. The USIM stores the received recommended VPLMN.
[0084] The terminal device 110 may also generate (220) a MAC-I for the SoR ACK. UE How to generate MAC-I UE The details will be described later.
[0085] The terminal device 110 may then send (222) a next registration request to, for example, the AMF 120-2 associated with the recommended VPLMN (i.e., the second VPLMN) in which the terminal device is to reside. The next registration request may include the SoR ACK and the generated MAC-I UE .
[0086] The AMF 120-2 may then forward (224) the SoR ACK and the generated MAC-I to the UDM 130. UE , and authentication requests.
[0087] After UDM 130 receives the new SoR ACK, UDM 130 may use the stored expected MAC-I HN To verify (226) the received MAC-I UE Because terminal device 110 has successfully attempted to register on the recommended VPLMN, UDM 130 may generate an authentication and key agreement (AKA) challenge for the attempted registration request.
[0088] Now refer to Figure 3 , which shows a signaling diagram 300 for communication according to some example embodiments of the present disclosure. Figure 3 As shown, the signaling diagram 300 involves the terminal device 110, the first AMF 120-1, the second AMF 120-2, the AUSF 140, the UDM 130 and the SoR AF 150. For the purpose of discussion, reference is made to Figure 1 3. Signaling diagram 300 is described below.
[0089] AMF 120-1 may be associated with a first VPLMN, and AMF 120-2 may be associated with a second VPLMN.
[0090] Similar to signaling diagram 200, Figure 3 As shown, the terminal device 110 may send (302) a registration request to the AMF 120-1 to camp on the first VPLMN. The registration request may at least indicate that SoR update is supported in the registration reject message. For example, the support of SoR update in the registration reject message may be indicated by a flag in the registration request. The flag may also indicate that support for SoR update is not set in the registration reject message. This flag may distinguish UEs that do not support this new feature from UEs that support this new feature at the UDM 130, regardless of whether the SoR container (i.e., SoR information) in the registration reject message is accepted.
[0091] If the AMF 120-1 successfully performs (304) authentication, the AMF 120-1 may also send an authentication request or a registration request with the same flag indicating support for SoR update in the registration reject message to the UDM 130. The UDM 130 may then store the UE capability, i.e., support for SoR update, in the registration reject message.
[0092] The AMF 120-1 may then send (306) a User Equipment Context Management (UECM) registration request (i.e., Nudm_UECM_Registration) to the UDM 130 indicating support for SoR update in a Registration Reject message.
[0093] UDM 130 may then request (308) SoR AF 150 to generate SoR information with a recommended VPLMN list for terminal device 110, and the SoR information may be provided (310) as a secure packet from SoR AF 150 to UDM 130. SoRAF 150 may request UDM 130 to send the SoR information in a registration reject message.
[0094] When authentication is successfully performed, the terminal device and the network can store K AUSFThus, the normal SoR procedure would be sufficient, and the AUSF 140 can perform (312) integrity protection of the SoR information, e.g., by generating a MAC-I AUSF based on K HN MAC-I HN for later verification.
[0095] The UDM 130 can reject the current registration requested by the SoR AF 150. The UDM 130 can send (314) a registration reject message containing parameters such as a request for an ACK, the SoR information, and the MAC-I HN to the AMF 120-1. The AMF 120-1 can then forward (316) the registration reject message to the terminal device 110.
[0096] The UDM 130 can expect the terminal device 110 to respond with the echo ACK in the next registration procedure (associated with the same VPLMN or a new VPLMN), which can or can not happen immediately. The UDM 130 can store the expected MAC-I HN in the UDR storage and wait for the next registration procedure.
[0097] Due to the support of SoR update, the terminal device 110 can accept the SoR data in the registration reject message and perform integrity protection verification on the received SoR information based on the MAC-I HN . The security packet is sent to the USIM for de-concealing and storage. The USIM stores the received recommended VPLMN.
[0098] The terminal device 110 can also generate (318) a MAC-I UE for the SoR ACK. Details on how to generate the MAC-I UE will be described later.
[0099] The terminal device 110 can then send (320) a next registration request to, for example, the AMF 120-2 associated with the recommended VPLMN (i.e., the second VPLMN) that the terminal device is to camp on. The next registration request can include the SoR ACK and the generated MAC-I UE . Alternatively, the terminal device 110 can send the next registration request to the AMF 120-1.
[0100] The AMF 120-2 can then forward (322) the SoR ACK and the generated MAC-I UE , as well as an authentication request or a registration request, to the UDM 130 / home network.
[0101] After UDM 130 receives the new SoR ACK, UDM 130 may use the stored expected MAC-I HN To verify (324) the received MAC-I UE .
[0102] In this way, the SoR data can be sent via the registration reject message and integrity protected via the new key. In addition, the UE can send an ACK via another registration (next registration), and the network can wait for and accept the ACK.
[0103] Hereinafter, embodiments for generating a MAC-I of a home network and a terminal device may be additionally described as follows.
[0104] For example, the UDM and USIM are already equipped with a long-term key K, which can be used for MAC-I during the initial registration process at the USIM and in the UDM. HN generate.
[0105] In addition, MAC-I HN The generation of the AUTN can also be based on the integrity key (IK). When an initial registration request is received in the UDM and if the request is not for a recommended VPLMN, an authentication token (AUTN) is generated. No RES or K is generated during AUTN generation. AUSF During AUTN generation, IK is generated. AUTN can be sent to the terminal device in a registration reject message.
[0106] As another option, the UDM and USIM can generate the bootstrapping roaming key (i.e., K) from the long-term key using the new RAND. SoR ) as the derived key. The RAND can be sent by the UDM to the terminal device in the registration rejection message. The terminal device can use the RAND and the long-term key to generate K SoR Key. The derived key K SoR Can be used for UDM and MAC-I generation in UE.
[0107] The UDM and USIM can also store the previous K AUSF This old or previous K can be used between the terminal device and the home network during the next registration and until a security context is established. AUSF .
[0108] Figure 4 A flow chart illustrating an example method 400 for SoR enhancement during registration rejection according to some example embodiments of the present disclosure is shown. The method 400 may be implemented as follows: Figure 1For the purpose of discussion, reference will be made to the terminal device 410. Figure 1 Method 400 is described.
[0109] At 410 , the terminal device 110 sends a registration request from the terminal device to an AMF associated with the VPLMN on which the terminal device is to camp, the registration request indicating at least that SoR update is supported in a registration reject message.
[0110] At 420 , the terminal device 110 receives a registration reject message including a confirmation request, SoR information, and a MAC-I of the home network.
[0111] In some example embodiments, SoR update is supported as indicated in the Registration Reject message by a flag in the Registration Request.
[0112] In some example embodiments, the registration reject message is received during an initial registration process or an authentication process of the terminal device.
[0113] In some example embodiments, the SoR information includes at least one recommended VPLMN to be camped on by the terminal device.
[0114] In some example embodiments, the terminal device may verify the SoR information for integrity protection based on the MAC-I of the home network.
[0115] In some example embodiments, the terminal device may generate a MAC-I of the terminal device for use in SoR confirmation.
[0116] In some example embodiments, the MAC-I of the terminal device is generated based on at least one of the following: a long-term key, an integrity key, a SoR key, or a previous K AUSF .
[0117] In some example embodiments, the terminal device may store the previous K AUSF , until the security context is established during the next registration process.
[0118] In some example embodiments, the terminal device may send another registration request indicating at least the SoR confirmation and the MAC-I generated by the terminal device to the AMF or another AMF associated with the recommended VPLMN to be camped by the terminal device.
[0119] Figure 5 A flow chart illustrating an example method 500 for SoR enhancement during registration rejection according to some example embodiments of the present disclosure is shown. The method 500 may be implemented in a manner such as Figure 1For the purpose of discussion, reference will be made to the first AMF 120-1. Figure 1 Method 500 is described.
[0120] At 510 , the first AMF 120 - 1 receives a registration request from a terminal device at an AMF associated with a VPLMN on which the terminal device intends to camp, the registration request indicating at least that SoR update is supported in a registration reject message.
[0121] At 520 , the first AMF 120 - 1 provides an indication to the UDM function that SoR update is supported in a Registration Reject message.
[0122] In some example embodiments, an indication that SoR update is supported in a Registration Reject message is provided from the first AMF to the UDM function in an Authentication Request or in a User Equipment Context Management (UECM) Registration Request.
[0123] In some example embodiments, SoR update is supported as indicated in the Registration Reject message by a flag in the Authentication Request or in the User Equipment Context Management (UECM) Registration Request.
[0124] In some example embodiments, the indication is provided in an authentication request from the first AMF via the Authentication Server Function AUSF to the UDM function.
[0125] In some example embodiments, the first AMF 120-1 may receive a confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network from the UDM function via an error indication for the UECM registration request or authentication request; and send a registration reject message to the terminal device, the registration reject message including the confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network.
[0126] In some example embodiments, the first AMF 120-1 may receive, from the terminal device, another registration request indicating at least the SoR confirmation and the MAC-I of the terminal device; and forward the another registration request to the UDM function.
[0127] Figure 6 A flow chart illustrating an example method 600 for SoR enhancement during registration rejection according to some example embodiments of the present disclosure is shown. The method 600 may be implemented in a manner such as Figure 1 For the purposes of this discussion, reference will be made to the UDM 130. Figure 1 Method 600 is described.
[0128] At 610 , the UDM 130 receives an indication at the UDM from an AMF associated with the VPLMN on which the terminal device is to reside that SoR update is supported in a Registration Reject message.
[0129] At 620 , the UDM 130 determines that a registration reject message is to be sent to the terminal device.
[0130] In some example embodiments, an indication that SoR update is supported in a Registration Reject message is provided from the AMF to the UDM in an Authentication Request or in a User Equipment Context Management Registration Request.
[0131] In some example embodiments, the indication is provided in an authentication request from the AMF via the Authentication Server Function AUSF to the UDM function.
[0132] In some example embodiments, the UDM may generate at least one recommended VPLMN to be camped by the terminal device, or notify the SoR application function that SoR update is supported in a registration reject message and obtain at least one recommended VPLMN to be camped by the terminal device from the SoR application function.
[0133] In some example embodiments, the UDM may inform the AUSF that the SoR information will be sent in the Registration Reject message.
[0134] In some example embodiments, the UDM may send a confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network to the AMF via an error indication for the user equipment context management registration request.
[0135] In some example embodiments, the UDM may send a confirmation request, SoR information, and a Message Authentication Code Integrity MAC-I of the home network to the AMF via an error indication for the authentication request.
[0136] In some example embodiments, the UDM may receive another User Equipment Context Management (UECM) Registration Request or another Authentication Request indicating at least the SoR confirmation and the MAC-I of the terminal device from the AMF or another AMF associated with the recommended VPLMN to be camped by the terminal device.
[0137] In some example embodiments, another UECM Registration Request Indication SoR Indication is supported in the Registration Reject message.
[0138] Figure 7 A flow chart illustrating an example method 700 for SoR enhancement during registration rejection according to some example embodiments of the present disclosure is shown. The method 700 may be implemented as follows: Figure 1 The SoR AF 150 is shown as being implemented. For the purposes of this discussion, reference will be made to Figure 1 Method 700 is described.
[0139] At 710 , the SoR AF 150 receives an indication from the UDM function at the SoR application that SoR updates are supported in a registration reject message.
[0140] At 720 , if SoR AF 150 determines that a registration reject message is to be sent to the terminal device, then at 730 , SoR AF 150 provides the UDM with at least one recommended VPLMN on which the terminal device is to camp.
[0141] Figure 8 A flow chart illustrating an example method 800 for SoR enhancement during registration rejection according to some example embodiments of the present disclosure is shown. The method 800 may be implemented in a manner such as Figure 1 For the purpose of discussion, reference will be made to the AUSF 140. Figure 1 Method 800 is described.
[0142] At 810, the AUSF 140 sends an authentication response from the AUSF to the AMF, the authentication response including the confirmation request, the SoR information, and the MAC-I of the home network.
[0143] In some example embodiments, upon determining the unified data management (UDM) function, AUSF 140 may notify that SoR information will be sent in the registration reject message such that the SoR information is integrity protected; and generate a MAC-I of the home network.
[0144] In some example embodiments, the MAC-I of the home network is generated based on at least one of the following: a long-term key, an integrity key, a SoR key, or a previous K AUSF .
[0145] In some example embodiments, the AUSF 140 may store the previous K AUSF , until the security context is established during the next registration process.
[0146] In some example embodiments, the AUSF 140 may receive an authentication request from an access and mobility management function, AMF, indicating at least that SoR update is supported in a registration reject message, the AMF being associated with a visited public land mobile network, VPLMN, on which the terminal device is intended to reside; and forward the authentication request to a unified data management, UDM function.
[0147] In some example embodiments, the AUSF 140 may receive another authentication request indicating at least the SoR confirmation and the MAC-I of the terminal device from another AMF associated with the recommended VPLMN to be camped by the terminal device.
[0148] In some example embodiments, an apparatus capable of performing the method 400 (e.g., implemented at the terminal device 110) can include means for performing the respective steps of the method 400. The means can be implemented in any suitable form. For example, the means can be implemented in circuitry or a software module.
[0149] In some example embodiments, the apparatus includes means for sending, to an AMF, a registration request indicating at least that SoR update is supported in a registration reject message, the AMF being associated with a VPLMN on which the apparatus is intended to camp; means for receiving a registration reject message including a confirmation request, SoR information, and a MAC-I of a home network.
[0150] In some example embodiments, the indication that SoR update is supported in a registration reject message is indicated by a flag in the registration request.
[0151] In some example embodiments, the registration reject message is received during an initial registration procedure or an authentication procedure of the apparatus.
[0152] In some example embodiments, the SoR information contains at least one recommended VPLMN on which the apparatus is intended to camp.
[0153] In some example embodiments, the apparatus can further include means for verifying the SoR information for integrity protection based on the MAC-I of the home network.
[0154] In some example embodiments, the apparatus can further include means for generating a MAC-I of the apparatus for SoR confirmation.
[0155] In some example embodiments, the MAC-I of the apparatus is generated based on at least one of: a long-term key, an integrity key, a SoR key, or a previous K AUSF .
[0156] In some example embodiments, the apparatus can further include means for storing the previous K AUSF , until a security context is established during a next registration procedure.
[0157] In some example embodiments, the apparatus can further include means for sending, to the AMF or another AMF, another registration request indicating at least the SoR confirmation and the MAC-I generated by the apparatus, the other AMF being associated with a recommended VPLMN on which the apparatus is intended to camp.
[0158] In some example embodiments, an apparatus capable of performing method 500 (e.g., implemented at AMF 120-1) may include components for performing the corresponding steps of method 500. The components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.
[0159] In some example embodiments, the apparatus comprises means for receiving a registration request from a terminal device, the registration request indicating at least that SoR updates are supported in a registration reject message, the apparatus being associated with a VPLMN on which the terminal device is to reside; and means for providing an indication that SoR updates are supported in the registration reject message to the UDM function.
[0160] In some example embodiments, in an authentication request or in a User Equipment Context Management (UECM) registration request, an indication that SoR update is supported is provided from the device to the UDM function in a registration reject message.
[0161] In some example embodiments, SoR update is supported as indicated in the Registration Reject message by a flag in the Authentication Request or in the User Equipment Context Management (UECM) Registration Request.
[0162] In some example embodiments, the slave device provides the indication in an authentication request to the UDM function via the Authentication Server Function AUSF.
[0163] In some example embodiments, the apparatus may further include means for receiving a confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network from the UDM function via an error indication for the UECM registration request or authentication request; and means for sending a registration reject message to the terminal device, the registration reject message including the confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network.
[0164] In some example embodiments, the apparatus may further comprise means for receiving, from the terminal device, a further registration request indicating at least the SoR confirmation and the MAC-I of the terminal device; and means for forwarding the further registration request to the UDM function.
[0165] In some example embodiments, an apparatus capable of performing method 600 (e.g., implemented at UDM 130) may include components for performing the corresponding steps of method 600. The components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.
[0166] In some example embodiments, an apparatus capable of performing method 600 (e.g., implemented at UDM 130) may include components for performing the various steps of method 600. The components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.
[0167] In some example embodiments, an indication that SoR update is supported in a Registration Reject message is provided from the AMF to the device in an Authentication Request or in a User Equipment Context Management Registration Request.
[0168] In some example embodiments, the indication is provided to the device in an authentication request from the AMF via the Authentication Server Function AUSF.
[0169] In some example embodiments, the apparatus may further comprise means for generating at least one recommended VPLMN on which the terminal device is to reside, or means for notifying the SoR application function that SoR update is supported in a registration reject message, and means for obtaining from the SoR application function the at least one recommended VPLMN on which the terminal device is to reside.
[0170] In some example embodiments, the apparatus may further comprise means for notifying the AUSF that the SoR information is to be sent in the registration reject message.
[0171] In some example embodiments, the apparatus may further comprise means for sending a confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network to the AMF via an error indication for the user equipment context management registration request.
[0172] In some example embodiments, the apparatus may further comprise means for sending a confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network to the AMF via an error indication for the authentication request.
[0173] In some example embodiments, the apparatus may further comprise means for receiving another User Equipment Context Management (UECM) Registration Request or another Authentication Request indicating at least the SoR confirmation and the MAC-I of the terminal device from the AMF or another AMF associated with the recommended VPLMN to be camped by the terminal device.
[0174] In some example embodiments, another UECM Registration Request Indication SoR Indication is supported in the Registration Reject message.
[0175] In some example embodiments, an apparatus capable of performing the method 700 (e.g., implemented at the SoR AF 150) can include means for performing the respective steps of the method 700. The means can be implemented in any suitable form. For example, the means can be implemented in circuitry or a software module.
[0176] In some example embodiments, the apparatus comprises means for receiving, from a UDM function, an indication that SoR updates are supported in a registration reject message; and means for providing, to the UDM, at least one recommended VPLMN to be camped by the terminal device in dependence on a determination that the registration reject message is to be sent to the terminal device.
[0177] In some example embodiments, an apparatus capable of performing the method 800 (e.g., implemented at the AUSF 140) can include means for performing the respective steps of the method 800. The means can be implemented in any suitable form. For example, the means can be implemented in circuitry or a software module.
[0178] In some example embodiments, the apparatus comprises means for sending, to an AMF, an authentication response comprising a confirmation request, SoR information, and a MAC-I of a home network.
[0179] In some example embodiments, the apparatus can further comprise means for causing the SoR information to be integrity protected in dependence on a determination that a unified data management, UDM, function, is to be notified that the SoR information is to be sent in a registration reject message; and generating a MAC-I of the home network.
[0180] In some example embodiments, the MAC-I of the apparatus is generated based on at least one of: a long-term key, an integrity key, a SoR key, or a previous K AUSF .
[0181] In some example embodiments, the apparatus can further comprise means for storing, in a previous registration procedure, a previous K AUSF , until a security context is established during a next registration procedure.
[0182] In some example embodiments, the apparatus can further comprise means for receiving, from an access and mobility management function, AMF, an authentication request indicating at least that SoR updates are supported in a registration reject message, the AMF being associated with a visited public land mobile network, VPLMN, on which the terminal device is to be camped; and means for forwarding the authentication request to a unified data management, UDM, function.
[0183] In some example embodiments, the apparatus may further comprise means for receiving, from another AMF, a further authentication request indicating at least the SoR confirmation and the MAC-I of the terminal device, the other AMF being associated with the recommended VPLMN to be camped on by the terminal device.
[0184] Figure 9 is a simplified block diagram of a device 900 suitable for implementing an example embodiment of the present disclosure. The device 900 may be provided to implement a communication device, such as Figure 1 The terminal device 110, the first AMF 120-1, the second AMF 120-2, the AUSF 140, the UDM 130 and the SoR AF 150 are shown. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processor 910, and one or more communication modules 940 coupled to the processor 910.
[0185] The communication module 940 is configured for bidirectional communication. The communication module 940 has one or more communication interfaces to facilitate communication with one or more other modules or devices. A communication interface may represent any interface necessary to communicate with other network elements. In some example embodiments, the communication module 940 may include at least one antenna.
[0186] Processor 910 can be of any type suitable for the local technology network and, as non-limiting examples, can include one or more of the following: a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 900 can have multiple processors, such as application-specific integrated circuit chips, which are time-slave to a clock synchronized with a main processor.
[0187] The memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 924, electrically programmable read-only memory (EPROM), flash memory, hard disks, compact disks (CDs), digital video disks (DVDs), optical disks, laser disks, and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 922 and other volatile memories that will not persist during a power outage.
[0188] The computer program 930 includes computer-executable instructions executed by the associated processor 910. The instructions of the program 930 may include instructions for performing the operations / actions of some example embodiments of the present disclosure. The program 930 may be stored in a memory such as ROM 924. The processor 910 may perform any suitable actions and processes by loading the program 930 into the RAM 922.
[0189] Example embodiments of the present disclosure can be implemented with the aid of program 930, which enables device 900 to perform any of the processes of the present disclosure as discussed above, with reference to Figures 2 to 7 Example embodiments of the present disclosure can also be implemented by hardware, or by a combination of software and hardware.
[0190] In some example embodiments, program 930 can be tangibly embodied in a computer-readable medium, which can be included in device 900 (for example, in memory 920) or in another storage device accessible by device 900. Device 900 can load program 930 from the computer-readable medium into RAM 922 to execute the program. In some example embodiments, the computer-readable medium can include any type of non-transitory storage medium, such as ROM, EPROM, flash memory, a hard disk, CD-ROM, DVD, etc. The term "non-transitory" as used herein is a limitation of the medium itself (i.e., tangible, not a signal) and not a limitation of the durability of data stored thereon (e.g., RAM vs. ROM).
[0191] Figure 10 An example of a computer-readable medium 1000 is shown, which can be in the form of a CD, DVD, or other optical storage disk. Program 930 is stored on computer-readable medium 1000.
[0192] In general, the various embodiments of the present disclosure can be implemented in hardware or special-purpose circuits, software, logic or any combination thereof. Some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software which can be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein can be implemented in hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controler or other computing devices, or some combination thereof.
[0193] Some example embodiments of the present disclosure also provide at least one computer program product which is tangibly stored on a computer-readable medium, such as a non-transitory computer-readable medium. The computer program product includes instructions that are executable by a device having a processor or virtual processor on a target physical or virtual processor to perform any of the methods described above. In general, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules can be combined or split between program modules as desired in various embodiments. Machine executable instructions for a program module can be executed within a local or distributed device. In a distributed device, program modules can be located in both local and remote memory storage media.
[0194] Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can execute entirely on a machine, partly on a machine, as a stand-alone software package, partly on a machine and partly on a remote machine or entirely on a remote machine or server.
[0195] In the context of the present disclosure, computer program code or related data can be embodied by any suitable carrier wave, including a signal, computer readable medium, etc.
[0196] The computer readable medium can be a computer readable signal medium or a computer readable storage medium. The computer readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0197] Moreover, while operations can be depicted in a particular order, this should not be understood as requiring such order, unless otherwise specifically stated, nor requiring all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Likewise, while several specific implementation details have been discussed, such details are not to be interpreted in a limiting sense and should be understood to be merely representative of a number of possible implementations. Certain features described in the context of separate embodiments can be implemented together in a single embodiment. Conversely, various features described in the context of a single embodiment can be implemented separately or in any suitable subcombination. It will be appreciated that certain features and / or aspects of the disclosure, which have been described in the context of separate embodiments, can also be implemented in combination in a single embodiment. Conversely, various features and / or aspects of the disclosure, which have been described in the context of a single embodiment, can also be implemented separately or in any suitable subcombination.
[0198] While the present disclosure has been described with reference to specific implementations thereof, it will be understood that variations and modifications can be made to the disclosed implementations without departing from the scope of the present disclosure. Other implementations can be utilized, and other changes can be made, without departing from the scope of the present disclosure. By way of example, those skilled in the art will recognize that a state machine can be implemented in hardware, software, or a combination thereof. Similarly, those skilled in the art will recognize that the state machine can be embodied by a processor, a controller, or a programmable logic array that is programmed to perform the functions of the state machine.
Claims
1. A device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: sending a registration request to an access and mobility management function (AMF), the registration request indicating at least that directed roaming SoR update is supported in a registration reject message, the AMF being associated with a visited public land mobile network (VPLMN) on which the apparatus is to camp; as well as The registration reject message is received, where the registration reject message includes a confirmation request, SoR information, and a message authentication code integrity MAC-I of the home network. 2 . The apparatus of claim 1 , wherein the SoR update is supported in the registration reject message as indicated by a flag in the registration request. 3 . The apparatus of claim 1 , wherein the registration rejection message is received during an initial registration process or an authentication process of the apparatus.
4. The device of claim 1, wherein the SoR information comprises at least one recommended VPLMN to be camped by the device.
5. The apparatus of claim 1 , wherein the apparatus is further configured to: The SoR information for integrity protection is verified based on the MAC-I of the home network.
6. The apparatus of claim 1 , wherein the apparatus is further configured to: Generate a MAC-I of the device for SoR confirmation.
7. The apparatus of claim 6 , wherein the MAC-I of the apparatus is generated based on at least one of: Long-term key, integrity key, SoR key, or Previous K AUSF .
8. The apparatus of claim 7, wherein the apparatus is further configured to: Store the previous K in the previous registration process AUSF , until the security context is established during the next registration process.
9. The apparatus of claim 7, wherein the apparatus is further configured to: Sending another registration request to the AMF or another AMF associated with a recommended VPLMN to be camped by the apparatus, the another registration request indicating at least the SoR confirmation and the MAC-I generated by the apparatus.
10. A device comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving a registration request from a terminal device, the registration request indicating at least that directed roaming SoR update is supported in a registration reject message, the apparatus being associated with a visited public land mobile network (VPLMN) on which the terminal device is to camp; as well as An indication is provided to a unified data management (UDM) function that the SoR update is supported in the registration reject message.
11. The apparatus of claim 10, wherein the indication that the SoR update is supported in the registration reject message is provided from the apparatus to the UDM function in an authentication request or in a User Equipment Context Management (UECM) registration request.
12. The apparatus of claim 10, wherein the SoR update is supported in the registration reject message is indicated by a flag in the authentication request or in the UECM registration request.
13. The apparatus of claim 11, wherein the indication is provided from the apparatus to the UDM function via an Authentication Server Function (AUSF) in the authentication request.
14. The apparatus of claim 11, wherein the apparatus is further configured to: receiving a confirmation request, SoR information, and a message authentication code integrity MAC-I of a home network from the UDM function via an error indication for the UECM registration request or the authentication request; and Sending the registration rejection message to the terminal device, where the registration rejection message includes: The confirmation request, the SoR information, and the message authentication code integrity MAC-I of the home network.
15. The apparatus of claim 10, wherein the device is further caused to: receiving from the terminal device another registration request indicating at least the SoR confirmation and a MAC-I of the terminal device; and The further registration request is forwarded to the UDM function.
16. An apparatus comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving an indication from an Access and Mobility Management Function (AMF) associated with a Visited Public Land Mobile Network (VPLMN) on which the terminal device is to camp that Directed Roaming SoR Update is supported in the Registration Reject message; and It is determined that the registration rejection message is to be sent to the terminal device.
17. The apparatus according to claim 16, wherein the indication that the SoR update is supported in the registration reject message is provided from the AMF to the apparatus in an authentication request or in a user equipment context management registration request.
18. The apparatus according to claim 17, wherein the indication is provided to the apparatus from the AMF via an Authentication Server Function (AUSF) in the authentication request.
19. The apparatus of claim 16, wherein the apparatus is further configured to at least one of: generating at least one recommended VPLMN on which the terminal device will reside, or notifying the SoR application function that the SoR update is supported in the registration reject message, and At least one recommended VPLMN to be camped on by the terminal device is obtained from the SoR application function.
20. The apparatus of claim 18, wherein the apparatus is further configured to: The AUSF is informed that the SoR information is sent in the Registration Reject message.