A communication method and apparatus
Patent Information
- Application Number
- CN202011175696.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-10-28
- Publication Date
- 2026-10-27
- Estimated Expiration
- 2040-10-28
AI Technical Summary
而终端设备通过漫游方式注册到PLMN后,如果再通过其他方式注册到PLMN,是冗余注册过程,而且通过N3IWF方式注册,流程较为复杂,需要耗费较多的资源
[0068]通过本申请实施例提供的方式,减少了终端设备的冗余注册过程,且由于终端设备无需进行本次注册过程,也减少了后续过程中所耗费的资源。
Smart Images

Figure CN114423074B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology
[0002] A non-public network (NPN) is a type of 5G network that is not publicly used. An NPN can be implemented with the support of a public land mobile network (PLMN), or it can be implemented without the support of a PLMN. For example, a standalone NPN (SNPN) within an NPN can be implemented without the support of a PLMN.
[0003] Currently, SNPN can interoperate with PLMN through a non-3GPP interworking function (N3IWF) architecture. For example, a terminal device can register with the SNPN. Within the SNPN, the terminal device can select an N3IWF within the PLMN to access the PLMN, and then register within the PLMN. In other words, the terminal device can access the PLMN's N3IWF through the SNPN to complete its registration with the PLMN. In addition to the N3IWF architecture, terminal devices can also achieve interoperability between the SNPN and PLMN through roaming. For example, a terminal device subscribed to by the PLMN can use its PLMN subscription configuration to select the corresponding SNPN and register with the PLMN by accessing the SNPN.
[0004] As can be seen, terminal devices can register to the PLMN in two ways. This raises the possibility that a terminal device, when accessing the SNPN, might register to the PLMN via roaming and then again via N3IWF, effectively registering twice with the PLMN through the SNPN. However, if a terminal device registers to the PLMN via roaming and then subsequently registers again via other methods, it constitutes a redundant registration process. Furthermore, registration via N3IWF is more complex and resource-intensive. Summary of the Invention
[0005] This application provides a communication method and apparatus to save resources consumed by redundant subscriptions of terminal devices.
[0006] In a first aspect, a first communication method is provided, which is executed, for example, by a first core network device or by a chip capable of implementing the functions of the first core network device. In a 5G system, the first core network device is, for example, a UDM (User Device Manager). The method includes: the first core network device within a first network receiving a first request message from a second core network device, the first request message being used by the second core network device to request services for a terminal device, the first request message including an initial registration type and information about a non-public network accessed by the terminal device, the initial registration type indicating that the first request message is an initial registration request for the terminal device, and the first network being the home network of the terminal device; the first core network device determining that the terminal device has registered to the first network through the non-public network; the first core network device sending a first response message to the second core network device, the first response message including a failure result indication, or including the registration context of the terminal device, or including indication information indicating that the terminal device has registered to the first network through the non-public network.
[0007] In this embodiment, the first network is, for example, a PLMN, a non-public network, or other networks. A non-public network is, for example, an SNPN. The first core network device receives a request message from a terminal device requesting to register with the first network via the SNPN. If it is determined that the terminal device has already registered with the first network via the SNPN, the first core network device will reject the terminal device's registration. Alternatively, the first core network device will send the terminal device's registration context or indication information to a second core network device, thereby enabling the second core network device to reject the terminal device's registration. This reduces redundant registration processes for the terminal device, and since the terminal device does not need to perform this registration process, it also reduces the resources consumed in subsequent processes.
[0008] In one alternative implementation, the information of the non-public network includes the identifier of the non-public network and / or, a non-public network access mode indication.
[0009] SNPN information may include, for example, the SNPN identifier, or the SNPN access mode indication, or both the SNPN identifier and the SNPN access mode indication.
[0010] In an optional implementation, the method further includes: the first core network device receiving a second request message from a third core network device, the second request message being used by the third core network device to request services for a terminal device, the second request message including information about the non-public network; the first core network device recording the registration context of the terminal device, the registration context of the terminal device including information about the non-public network; and the first core network device sending a second response message to the third core network device, the second response message being used to indicate that the third core network device has successfully registered to provide services for the terminal device.
[0011] This is the last registration process on the terminal device; that is, through this registration, the terminal device has registered with the first network. During this registration process, the first core network device can record the SNPN information of the terminal device. Therefore, if the terminal device subsequently registers with the first network again using the same SNPN, the first core network device can refuse the terminal device's registration.
[0012] In one optional implementation, the first core network device determines that the terminal device has registered with the first network through the non-public network, including:
[0013] The first core network device determines, based on the initial registration type, the information of the non-public network, and the recorded registration context of the terminal device, that the terminal device has registered to the first network through the non-public network.
[0014] The initial registration type indicates that the terminal device is registering for the first time. The first core network device records the registration context of the terminal device's previous registration. If the SNPN information included in the first request message corresponds to the same SNPN as the SNPN information included in the terminal device's registration context recorded by the first core network device, then the first core network device can determine that the terminal device has already registered with the first network through that SNPN. Through the records of the first core network device, it can compare the SNPNs of the terminal device's two registrations, thereby rejecting the terminal device's dual registration.
[0015] In one alternative implementation, the first response message further includes a reason value, which indicates that the terminal device has registered with the first network through the non-public network.
[0016] If the first response message includes a failure result indication, it can also include a reason value, so that the second core network device can understand why the first core network device rejected this registration.
[0017] In an optional implementation, the method further includes: the first core network device deleting the registration context of the second core network device corresponding to the non-public network; or, the first core network device receiving a fourth request message from the second core network device, the fourth request message being used to request the first core network device to deregister the second core network device in the first core network device, and the first core network device deleting the registration context of the second core network device corresponding to the non-public network.
[0018] If the first core network device rejects the terminal device's registration, it can delete the registration context of the second core network device corresponding to that SNPN, meaning it deletes the information related to the second core network device's registration. Alternatively, if the second core network device rejects the terminal device's registration, meaning the first core network device lacks decision-making power, it can request the first core network device to deregister from its own SNPN via a fourth request message. In this case, the first core network device can delete the registration context of the second core network device corresponding to that SNPN. Thus, regardless of whether the first core network device can decide to reject the terminal device's registration, it can delete the registration context of the second core network device corresponding to that SNPN, saving storage space and preventing the storage of incorrect information.
[0019] Secondly, a second communication method is provided, which is executed, for example, by a second core network device or by a chip capable of implementing the functions of the second core network device. In a 5G system, the second core network device is, for example, an AMF (Advanced Network Component). The method includes: the second core network device within a first network receiving a third request message from a terminal device via the first network device, the third request message being used by the terminal device to request registration with the first network, the first network being the home network of the terminal device; the second core network device obtaining information about a non-public network accessed by the terminal device; the second core network device sending a first request message to the first core network device, the first request message being used by the second core network device to request services for the terminal device, the first request message including an initial registration type and information about the non-public network, the initial registration type being used to indicate that the first request message is an initial registration request for the terminal device; the second core network device receiving a first response message from the first core network device, the first response message including a failure result indication, or including the registration context of the terminal device, or including indication information indicating that the terminal device has registered with the first network via the non-public network; and the second core network device sending a third response message, the third response message being used to reject the registration of the terminal device.
[0020] In one alternative implementation, the information of the non-public network includes the identifier of the non-public network and / or, a non-public network access mode indication.
[0021] In one optional implementation, the second core network device obtains information about the non-public network accessed by the terminal device, including: the second core network device obtaining the information about the non-public network from the third request message; or, the second core network device receiving the information about the non-public network from the first network device. The first network device is, for example, an N3IWF, or it could be other network devices.
[0022] The terminal device can include the SNPN information in the third request message, from which the second core network device can obtain the SNPN information, a relatively simple method. Alternatively, the N3IWF can determine the SNPN information and send it to the second core network device. In this case, the terminal device does not need to determine the SNPN information, and the message sent by the terminal device to the N3IWF does not need to include the SNPN information, which helps to save signaling overhead.
[0023] In one optional implementation, the third response message further includes a reason value, which indicates that the terminal device has registered with the first network through the non-public network.
[0024] In an optional implementation, the method further includes: the second core network device sending a fourth request message to the first core network device, the fourth request message being used to request the first core network device to deregister the second core network device from its registration in the first core network device.
[0025] In one alternative implementation, before the second core network device sends the third response message, the method further includes: the second core network device determining, based on the first response message, to reject the registration of the terminal device.
[0026] For the technical effects of the second aspect or various alternative implementation methods, please refer to the introduction of the technical effects of the first aspect or corresponding implementation methods.
[0027] Thirdly, a third communication method is provided, which is executed, for example, by a first core network device or by a chip capable of implementing the functions of the first core network device. In a 5G system, the first core network device is, for example, a UDM (Unified Device Manager). The method includes: the first core network device within a first network receiving a first request message from a second core network device, the first request message being used by the second core network device to request services to a terminal device, and the first request message further including mobile registration type and information about a second non-public network, the mobile registration type being used to indicate that the first request message is a registration request triggered by the terminal device due to mobility, and the first network being the home network of the terminal device; the first core network device sending a first response message to the second core network device, the first response message being used to indicate that the second core network device has successfully registered to provide services to the terminal device.
[0028] In this embodiment of the application, when a terminal device moves from a first non-public network to a second non-public network, the first network can accept the terminal device's registration on the first network through the second non-public network, enabling the terminal device to function normally.
[0029] In an optional implementation, the method further includes: the first core network device deregistering the terminal device through the registration of the first non-public network on the first network.
[0030] Since the first core network device has accepted the terminal device's registration in the first network through the second SNPN, it can then register the terminal device's registration in the first network through the first SNPN, thus avoiding the terminal device registering twice in the first network.
[0031] In one optional implementation, the first core network device deregisters the terminal device from its registration on the first network via the first non-public network, including: the first core network device deleting the registration context of the third core network device corresponding to the first non-public network; or, the first core network device receiving a second request message from the second core network device, the second request message indicating that the terminal device should be deregistered from its registration on the first network via the first non-public network, and the first core network device deleting the registration context of the third core network device corresponding to the first non-public network.
[0032] If the first core network device decides to accept the terminal device's registration, it can automatically delete the registration context of the third core network device corresponding to the first SNPN; that is, the first core network device deletes the information related to the third core network device's registration for this purpose. Alternatively, if the second core network device accepts the terminal device's registration, meaning the first core network device lacks decision-making power, it can request the first core network device to deregister the third core network device from the first network via a second request message. In this case, the first core network device can delete the registration context of the third core network device corresponding to the first SNPN. Thus, regardless of whether the first core network device can decide to reject the terminal device's registration, it can delete the registration context of the third core network device corresponding to the first SNPN, saving storage space, preventing the storage of incorrect information, and avoiding dual registration of the terminal device within the first network.
[0033] In one alternative implementation, the information of the second non-public network includes the identifier of the second non-public network and / or, a non-public network access mode indication.
[0034] The information of the second SNPN may include, for example, the identifier of the second SNPN, or the access mode indication of the second SNPN, or both the identifier of the second SNPN and the access mode indication of the second SNPN.
[0035] In an optional implementation, the method further includes: the first core network device receiving a second request message from the third core network device, the second request message being used by the third core network device to request services for the terminal device, the second request message including information about the first non-public network; the first core network device recording the registration context of the terminal device, the registration context of the terminal device including information about the first non-public network; and the first core network device sending a second response message to the third core network device, the second response message being used to indicate that the third core network device has successfully registered to provide services for the terminal device.
[0036] This is the registration process of the terminal device's last registration, that is, through this registration, the terminal device registered with the first network via the first SNPN. During this registration process, the first core network device can record the information of the first SNPN, so that the first core network device can subsequently determine whether to accept the terminal device's re-registration after it moves.
[0037] In one alternative implementation, the information of the first non-public network includes the identifier of the first non-public network and / or, a non-public network access mode indication.
[0038] The information of the first SNPN may include, for example, the identifier of the first SNPN, or the access mode indication of the first SNPN, or both the identifier of the first SNPN and the access mode indication of the first SNPN.
[0039] In one alternative implementation, the first response message includes the registration context of the terminal device.
[0040] The first response message can indicate that the PLMN AMF has successfully registered to provide services to the UE. One indication method is implicit indication, for example, the first core network device carries the terminal device's registration context in the first response message, which implicitly indicates that the second core network device has successfully registered to provide services to the terminal device. Alternatively, another indication method is explicit indication, where the first core network device can also carry indication information in the first response message. This indication information can indicate that the terminal device has registered to the first network through the second SNPN, or indicate that the second core network device has successfully registered to provide services to the terminal device. The indication information has a smaller amount of information, which can save signaling overhead.
[0041] In one optional implementation, before the first core network device sends the first response message to the second core network device, the method further includes:
[0042] The first core network device determines that the second core network device has successfully registered to provide services to the terminal device based on the mobile registration type, the information of the second non-public network, and the recorded registration context of the terminal device.
[0043] The first core network device determines that the terminal device has registered after relocation based on the mobile registration type. However, the second SNPN and the first SNPN information included in the terminal device's registration context are not the same SNPN. The first core network device can determine that the terminal device registered with the first network again after relocation through a different SNPN. Therefore, the first core network device can determine that the second core network device has successfully registered to provide services to the terminal device, which enables the terminal device to function normally after relocation.
[0044] Fourthly, a fourth communication method is provided, which is executed, for example, by a second core network device or by a chip capable of implementing the functions of a second core network device. In a 5G system, the second core network device is, for example, an AMF (Advanced Network Provider). The method includes: the second core network device within a first network receiving a third request message from a terminal device via the first network device, the third request message being used by the terminal device to request registration with the first network, the third request message further including a mobile registration type indicating that the third request message is a registration request triggered by the terminal device due to mobility, and the first network being the home network of the terminal device; the second core network device sending a first request message to the first core network device, the first request message being used by the second core network device to request service for the terminal device, the first request message including the mobile registration type and information about a second non-public network; the second core network device receiving a first response message from the first core network device, the first response message indicating that the second core network device has successfully registered to provide service to the terminal device; and the second core network device sending a third response message to the terminal device, the third response message indicating that the terminal device has successfully registered with the first network.
[0045] In one alternative implementation, the information of the second non-public network includes the identifier of the second non-public network and / or, a non-public network access mode indication.
[0046] In one alternative implementation, the first response message includes the registration context of the terminal device.
[0047] In an optional implementation, before the second core network device sends a third response message to the terminal device, the method further includes: the second core network device determining, based on the mobile registration type, the information of the second non-public network, and the registration context of the terminal device, that the terminal device has successfully registered to the first network.
[0048] In an optional implementation, the method further includes: the second core network device sending a second request message to the first core network device, the second request message being used to instruct the terminal device to deregister from its registration on the first network via the first non-public network.
[0049] For the technical effects of the fourth aspect or various alternative implementation methods, please refer to the introduction of the technical effects of the third aspect or corresponding implementation methods.
[0050] Fifthly, a fifth communication method is provided, which is executed, for example, by a first network device or by a chip capable of implementing the functions of the first network device. In a 5G system, the first network device is, for example, an N3IWF. The method includes: the first network device within the first network receiving a fourth request message from a terminal device, the fourth request message being used by the terminal device to request registration with the first network, the first network being the home network of the terminal device; the first network device determining information about a non-public network accessed by the terminal device; and the first network device sending the non-public network information to a second core network device.
[0051] If the N3IWF can determine the SNPN information and send it to the second core network device, then the terminal device does not need to determine the SNPN information. Therefore, the fourth request message sent by the terminal device to the N3IWF does not need to include the SNPN information, which helps to save signaling overhead.
[0052] In one optional implementation, the first network device determines information about the non-public network accessed by the terminal device, including: the first network device determining information about the non-public network accessed by the terminal device based on the correspondence between the non-public network and the tunnel or IP address; or, the first network device determining information about the non-public network accessed by the terminal device based on the correspondence between the non-public network and the first network device.
[0053] For example, the mapping between SNPN and tunnel is pre-configured (or specified by the protocol), or the tunnel is, for example, between the terminal device and the N3IWF, or between the SNPN UPF and the N3IWF. This mapping is also known to the terminal device or the UPF, for example, a one-to-one correspondence between SNPN and tunnel. Then, when the UE sends a fourth request message, or when the UPF forwards the fourth request message from the terminal device, it can select the tunnel corresponding to the SNPN accessed by the terminal device to send the message. The N3IWF can then determine the SNPN information accessed by the terminal device based on the tunnel from which the fourth request message is received. As another example, the mapping between the IP addresses of SNPN and SNPN UPF is pre-configured (or specified by the protocol), for example, a one-to-one correspondence between the IP addresses of SNPN and SNPN UPF. Then, when the N3IWF receives a fourth request message from the SNPN UPF, it can determine the information of the fourth accessed SNPN based on the detected IP address of the SNPN UPF. For example, a pre-configured (or protocol-defined) correspondence between SNPNs and N3IWFs is established, and this correspondence is known to the terminal device; for instance, there is a one-to-one correspondence between SNPNs and N3IWF IDs. When the terminal device sends a fourth request message, it can select the N3IWF corresponding to the SNPN it has accessed. If the corresponding N3IWF receives the fourth request message from the terminal device, it can determine that the SNPN accessed by the terminal device is the SNPN corresponding to that N3IWF. Alternatively, besides the above methods, the N3IWF can also determine the SNPN information through other means, which are not limited in this embodiment.
[0054] Sixthly, a communication device is provided, which may be a first core network device, a second core network device, or a first network device, or the communication device may be a chip. The communication device has the functions of implementing the embodiments of any one of the first, second, third, fourth, or fifth aspects described above. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.
[0055] A seventh aspect provides a communication device, including a processor and a communication interface. Optionally, it may also include a memory, or the communication device may not include a memory, which may be located externally to the communication device. The memory is used to store a computer program. When the communication device is running, the processor executes the computer program stored in the memory to cause the communication device to perform a method executed by a first core network device as described in the first aspect or any optional embodiment of the first aspect, or to cause the device to perform a method executed by a second core network device as described in the second aspect or any optional embodiment of the second aspect, or to cause the device to perform a method executed by a first core network device as described in the third aspect or any optional embodiment of the third aspect, or to cause the device to perform a method executed by a second core network device as described in the fourth aspect or any optional embodiment of the fourth aspect, or to cause the device to perform a method executed by a first network device as described in the fifth aspect or any optional embodiment of the fifth aspect.
[0056] Eighthly, a first communication system is provided, the first communication system comprising a communication device as described in the sixth aspect (performing the method described in the first aspect or various optional embodiments of the first aspect) or a communication device as described in the seventh aspect (performing the method described in the first aspect or various optional embodiments of the first aspect), a communication device as described in the sixth aspect (performing the method described in the second aspect or various optional embodiments of the second aspect) or a communication device as described in the seventh aspect (performing the method described in the second aspect or various optional embodiments of the second aspect), and a communication device as described in the sixth aspect (performing the method described in the fifth aspect or various optional embodiments of the fifth aspect) or a communication device as described in the seventh aspect (performing the method described in the fifth aspect or various optional embodiments of the fifth aspect).
[0057] Ninth aspect, providing a second communication system, the second communication system comprising the communication device of the sixth aspect (performing the method described in the third aspect or various optional embodiments of the third aspect) or the communication device of the seventh aspect (performing the method described in the third aspect or various optional embodiments of the third aspect), comprising the communication device of the sixth aspect (performing the method described in the fourth aspect or various optional embodiments of the fourth aspect) or the communication device of the seventh aspect (performing the method described in the fourth aspect or various optional embodiments of the fourth aspect), and comprising the communication device of the sixth aspect (performing the method described in the fifth aspect or various optional embodiments of the fifth aspect) or the communication device of the seventh aspect (performing the method described in the fifth aspect or various optional embodiments of the fifth aspect).
[0058] A tenth aspect provides a computer-readable storage medium for storing a computer program that, when run on a computer, causes the computer to perform the methods described in the first aspect or any of the optional embodiments.
[0059] Eleventhly, a computer-readable storage medium is provided for storing a computer program that, when run on a computer, causes the computer to perform the methods described in the second aspect or any of the optional embodiments described above.
[0060] In a twelfth aspect, a computer-readable storage medium is provided for storing a computer program that, when run on a computer, causes the computer to perform the methods described in the third aspect or any of the alternative embodiments described above.
[0061] In a thirteenth aspect, a computer-readable storage medium is provided for storing a computer program that, when run on a computer, causes the computer to perform the methods described in the fourth aspect or any of the alternative embodiments described above.
[0062] In a fourteenth aspect, a computer-readable storage medium is provided for storing a computer program that, when run on a computer, causes the computer to perform the methods described in the fifth aspect or any of the alternative embodiments described above.
[0063] In a fifteenth aspect, a computer program product comprising instructions is provided, the computer program product being used to store a computer program that, when the computer program is run on a computer, causes the computer to perform the method described in any of the first aspects or any of the optional embodiments described above.
[0064] In a sixteenth aspect, a computer program product comprising instructions is provided, the computer program product being used to store a computer program that, when the computer program is run on a computer, causes the computer to perform the method described in the second aspect or any of the alternative embodiments described above.
[0065] In a seventeenth aspect, a computer program product comprising instructions is provided, the computer program product being used to store a computer program that, when the computer program is run on a computer, causes the computer to perform the method described in any of the alternative embodiments of the third aspect above.
[0066] Eighteenthly, a computer program product comprising instructions is provided, the computer program product being used to store a computer program that, when the computer program is run on a computer, causes the computer to perform the method described in the fourth aspect or any of the optional embodiments described above.
[0067] In a nineteenth aspect, a computer program product comprising instructions is provided, the computer program product being used to store a computer program that, when the computer program is run on a computer, causes the computer to perform the method described in any of the optional embodiments of the fifth aspect above.
[0068] The method provided in this application reduces redundant registration processes for terminal devices, and since the terminal device does not need to perform this registration process, it also reduces the resources consumed in subsequent processes. Attached Figure Description
[0069] Figure 1 This is a schematic diagram of a 5G communication system architecture;
[0070] Figure 2 A more detailed schematic diagram of the 5G communication system architecture;
[0071] Figure 3A A schematic diagram of a UE accessing PNI-NPN;
[0072] Figure 3B A schematic diagram of a UE accessing SNPN;
[0073] Figure 4A A schematic diagram illustrating the interoperability between SNPN and PLMN via N3IWF;
[0074] Figure 4B A schematic diagram illustrating the interoperability between SNPN and PLMN via a roaming architecture;
[0075] Figure 5 This is a diagram illustrating how a PLMN may support UE registration in different ways.
[0076] Figure 6 A flowchart illustrating the first communication method provided in this application embodiment;
[0077] Figure 7 A flowchart illustrating the second communication method provided in this application embodiment;
[0078] Figure 8 This is a schematic diagram illustrating how a UE might re-register with the PLMN after moving.
[0079] Figure 9 A flowchart illustrating the third communication method provided in the embodiments of this application;
[0080] Figure 10 A flowchart illustrating the fourth communication method provided in this application embodiment;
[0081] Figure 11 A schematic diagram of an apparatus provided in an embodiment of this application;
[0082] Figure 12 This is a schematic diagram of another device provided in an embodiment of this application. Detailed Implementation
[0083] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.
[0084] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.
[0085] In this embodiment, the terminal device is a device with wireless transceiver capabilities, which can be a fixed device, mobile device, handheld device, wearable device, vehicle-mounted device, or a wireless device (e.g., a communication module or chip system) built into the aforementioned devices. The terminal device is used to connect people, objects, machines, etc., and can be widely used in various scenarios, including but not limited to the following: cellular communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine / machine-type communication (M2M / MTC) communication, Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, self-driving, remote medical care, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart city, drones, robots, and other similar scenarios. The terminal device may sometimes be referred to as user equipment (UE), terminal, access station, UE station, remote station, wireless communication equipment, or user device, etc. For ease of description, the terminal device in this application embodiment will be described using UE as an example.
[0086] The network devices in this application embodiment include, for example, access network devices and / or core network devices. The access network device is a device with wireless transceiver capabilities, used to communicate with the terminal device. The access network device includes, but is not limited to, base stations (BTS, Node B, eNodeB / eNB, or gNodeB / gNB), transmission reception points (TRPs), 3GPP subsequent evolution base stations, access nodes, wireless relay nodes, and wireless backhaul nodes in wireless fidelity (WiFi) systems. The base station can be: macro base station, micro base station, pico base station, small cell, relay station, etc. Multiple base stations can support networks using the same access technology mentioned above, or they can support networks using different access technologies mentioned above. A base station can include one or more co-located or non-co-located transmission and reception points. The network device can also be a radio controller, centralized unit (CU), and / or distributed unit (DU) in a cloud radio access network (CRAN) scenario. The network device can also be a server, wearable device, or vehicle-mounted device, etc. For example, network devices in vehicle-to-everything (V2X) technology can be roadside units (RSUs). The following description of access network devices uses base stations as an example. Multiple network devices in the communication system can be base stations of the same type or different types. Base stations can communicate with terminal devices, or they can communicate with terminal devices through relay stations. Terminal devices can communicate with multiple base stations in different access technologies. The core network devices are used to implement functions such as mobility management, data processing, session management, policy and charging. The names of devices implementing core network functions can differ in systems using different access technologies, and this application does not limit this. Taking a 5G system as an example, the core network devices include: access and mobility management function (AMF), unified data management (UDM), or user plane function (UPF), etc.
[0087] In this application embodiment, the device for implementing the function of the network device can be the network device itself, or it can be a device capable of supporting the network device in implementing that function, such as a chip system, which can be installed in the network device. In the technical solutions provided in this application embodiment, the example of a network device being used to implement the function of the network device is used to describe the technical solutions provided in this application embodiment.
[0088] In this application, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns," i.e., "one or more." "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.
[0089] Currently, UEs can access mobile networks including 2G, 3G, and 4G networks, which provide data transmission channels for UEs' voice, video, and web services. However, the explosive growth of new services such as connected vehicles, virtual reality, mobile office, and the Internet of Things requires mobile networks to provide fiber-optic-like access speeds, a "zero" latency user experience, the ability to connect hundreds of billions of devices, consistent services across multiple scenarios with ultra-high traffic density, ultra-high connection density, and ultra-high mobility, intelligent optimization of services and user experience, and energy efficiency improvements and bit cost reductions of over 100 times. These are all weaknesses of traditional networks and cannot safeguard the rapid development of future services.
[0090] The 5G communication system architecture defined by the 3rd Generation Partnership Project (3GPP) consists of four components, which can be referenced. Figure 1 . Figure 1This includes the next-generation UE (UE), next-generation radio access network (RAN), next-generation core network, and data network. NextGen (or NG) is short for next-generation (i.e., 5G) mobile communication system architecture, consisting of UE, AN, Core, and data network. Among these, UE, AN, and Core are the main components of the architecture, logically divided into user plane and control plane. The control plane is responsible for mobile network management, while the user plane is responsible for service data transmission. Figure 1 In this context, the NG2 reference point is located between the AN control plane and the Core control plane, the NG3 reference point is located between the AN user plane and the Core user plane, and the NG6 reference point is located between the Core user plane and the data network.
[0091] The UE (User Equipment) serves as the entry point for mobile users to interact with the network, providing basic computing and storage capabilities, displaying service windows to users, and accepting user input. NextGen UEs will employ new air interface (NII) technology to establish signal and data connections with the AN (Anti-Network Controller), thereby transmitting control signals and service data to the mobile network.
[0092] An AN (Access Provider) is similar to a base station in a traditional network, deployed close to the UE (User Equipment). It provides network access to authorized users in a specific area and can determine different quality transmission tunnels to transmit user data based on the user's level and service requirements. The AN can manage its own resources, utilize them rationally, provide access services to the UE on demand, and is responsible for forwarding control signals and user data between the UE and the core network.
[0093] The Core can include multiple network elements, which are responsible for maintaining the subscription data of the mobile network, managing the network elements of the mobile network, and providing the UE with functions such as session management, mobility management, policy management, and security authentication. When the UE attaches, it provides network access authentication; when the UE has a service request, it allocates network resources for the UE; when the UE moves, it updates network resources for the UE; when the UE is idle, it provides a fast recovery mechanism for the UE; when the UE detaches, it releases network resources for the UE; and when the UE has service data, it provides data routing functions, such as forwarding uplink data to the data network; or receiving downlink data from the UE from the data network, forwarding it to the AN, and then sending it to the UE.
[0094] A data network is a network that provides business services to users. A data network can include multiple application servers, which provide services to corresponding applications. Application clients are typically installed in the User Equipment (UE), while the application servers reside within the data network. A data network can be a private network, such as a local area network (LAN), or an external network not controlled by the operator, such as the Internet. It can also be a dedicated network jointly deployed by operators, such as a network providing IP multimedia core network subsystem (IMS) services.
[0095] Please refer to the following. Figure 2 It is Figure 1 Based on this, the core network architecture of 5G networks has been further refined. The core network user plane includes UPF; the core network control plane includes authentication server function (AUSF), AMF, session management function (SMF), network slice selection function (NSSF), network exposure function (NEF), network function repository function (NRF), UDM, policy control function (PCF), and application function (AF). The core network control plane adopts a service-oriented architecture, and the interaction between control plane network elements uses service calls to replace the point-to-point communication method in the traditional architecture. In the service-oriented architecture, one control plane network element exposes services to other control plane network elements for them to call; in point-to-point communication, the communication interface between control plane network elements uses a specific set of messages that can only be used by the control plane network elements at both ends of the interface during communication.
[0096] The functions of network elements in the core network are described below:
[0097] UPF performs user packet forwarding according to the routing rules of SMF, such as sending uplink data to DN or other UPF, and forwarding downlink data to other UPF or RAN.
[0098] AUSF performs security authentication for the UE.
[0099] AMF (Access Management Function) manages the UE's access and mobility. It is responsible for maintaining the UE's state, managing UE reachability, forwarding non-access-stratum (NAS) messages (mobility management, MM), and forwarding N2 messages (session management, SM).
[0100] SMF, or UE Session Management, allocates and releases resources for UE sessions. These resources include Session Quality of Service (QoS), session paths, forwarding rules, etc.
[0101] NSSF selects a network slice for the UE.
[0102] NEF exposes its network functionality to third parties through a northbound application programming interface (API).
[0103] NRF provides other network elements with the functions of storing and selecting network function entity information.
[0104] UDM, User Subscription Context Management.
[0105] PCF, User Policy Management.
[0106] AF, Application Management.
[0107] Next, we will introduce the concept of NPN.
[0108] NPN is a non-public 5G network. NPN can be implemented with the support of PLMN. NPN implemented with the support of PLMN is called public network integrated NPN (PNI-NPN). Alternatively, NPN can be implemented without the network functions of PLMN. NPN implemented without the support of PLMN is called SNPN.
[0109] PNI-NPN can be implemented using network slices or proprietary data network names (DNNs) within a PLMN. To prevent unauthorized UEs from attempting to access and select PNI-NPN, PNI-NPN additionally utilizes the Closed Access Group (CAG) feature. Some UEs permitted to access PNI-NPN can be configured with available CAG IDs and CAG indicators. These CAG indicators specify that the UE is only allowed to access the 5GS via a CAG cell. The UE's subscription data stored in the UDM will also include the available CAG IDs and CAG indicators for that UE. The CAG cell broadcasts the CAG IDs supported by that cell, and the UE determines whether it is authorized to access that cell based on the received CAG IDs.
[0110] Please refer to Figure 3A This is a schematic diagram of UE accessing PNI-NPN. Figure 3A The system includes two base stations. Base station A provides a CAG cell, which issues PLMNID A and CAG ID X via a system information block (SIB). Base station B provides a cell that is not a PNI-NPN and is therefore not a CAG cell. This cell issues PLMN ID A via the SIB but not a CAG ID. For example, if UE1 is configured with CAG ID X, then UE1 can access both base station A and base station B. If UE2 is configured with both CAG ID X and CAG indication, then UE2 can access base station A but cannot access base station B. If UE3 is not configured with either CAG ID or CAG indication, meaning UE3 is not allowed to access PNI-NPN, then UE3 cannot access base station A, but UE3 can access base station B.
[0111] SNPN is deployed independently and does not rely on the PLMN network. SNPN is identified using PLMN ID + network identifier (NID), where PLMN ID can be a pre-reserved inherent value from a third-party operator or a specific value from the PLMN operator deploying the SNPN. Within the SNPN, cells belonging to the SNPN broadcast their PLMN ID + NID. The UE selects a cell based on the broadcast information and the network selection information configured for that UE. The network selection information configured for the UE may include PLMN ID + NID. For example, if the UE determines that its configured network selection information is different from the PLMN ID and / or NID broadcast by the cell, the UE will not access that cell.
[0112] Please refer to Figure 3B This is a schematic diagram of a UE accessing an SNPN. Among them, Figure 3BIn the non-public network ID, N means that the ID of the non-public network is N. For example, if a base station belonging to an SNPN broadcasts PLMN ID+NID, and UE4's network selection information includes this PLMN ID+NID, then UE4 can access the base station.
[0113] Currently, through the N3IWF architecture, SNPN can interoperate with PLMN. For example... Figure 4A As shown, the UE uses the SNPN's private network subscription to select the SNPN ID and access the SNPN base station to perform 3GPP registration in the SNPN network; the UE uses the PLMN's public network subscription to select the PLMN ID, selects the PLMN N3IWF, establishes a connection with the PLMN N3IWF through a PDU session in the SNPN network to access the PLMN N3IWF, and then performs non-3GPP access registration in the PLMN network through the N3IWF. Figure 4A In this context, SNPN 3GPP access means that the UE accesses the SNPN via 3GPP technology over the air interface. PLMN Nwu (Nwu for PLMN) means that the UE accesses the PLMN using the Nwu interface between the UE and the PLMN's N3IWF. PLMN N1 (N1 for PLMN) is the interface between the UE and the PLMN AMF, indicating that the UE uses the N1 interface between the UE and the PLMN AMF to send information to the PLMN AMF. NPN N1 (N1 for NPN) is the interface between the UE and the SNPN AMF, indicating that the UE uses the N1 interface between the UE and the SNPN AMF to send information to the SNPN AMF.
[0114] In addition to achieving interoperability between SNPN and PLMN through the N3IWF architecture, interoperability between SNPN and PLMN is also currently supported through a roaming architecture. For example... Figure 4B The diagram illustrates the roaming architecture. The UE subscribes to the PLMN. Within the SNPN's coverage area, the UE uses the PLMN's public network subscription to select an SNPN ID and accesses the SNPN using this public network subscription. It registers with the PLMN through the SNPN and can subsequently establish PDU sessions within the SNPN. The SNPN determines the roaming mode of the PDU session based on the UE's public network subscription. The roaming mode can be, for example, local breakout (LBO) mode or home routed (HR) mode. Figure 4B The portion to the right of the central vertical line belongs to the PLMN, and the portion to the left belongs to the SNPN. In this method, the UE registers with the PLMN for 3GPP access via the SNPN.
[0115] As described above, PLMN can simultaneously support... Figure 4A or Figure 4B Interoperability with SNPN is achieved through various methods. Figure 5 As shown, PLMN1 supports interoperability with SNPN1 via roaming and also via N3IWF. For example, a UE can register with PLMN1 via roaming using a PLMN1 subscription. Figure 5 As shown, the UE uses its PLMN1 subscription and registers with SNPN1 via the Security Edge Protection Proxy (SEPP) / Inter-PLMN UP Security (IPUPS). Subsequently, the UE may re-register with PLMN1 via SNPN1 using N3IWF. However, if the UE registers with PLMN1 through roaming and then re-registers via other methods, it's a redundant registration process. Furthermore, registration via N3IWF is more complex and resource-intensive. Using N3IWF also lacks control over the UE's services, leading to a waste of private network resources and a loss of control over the UE's service access.
[0116] Therefore, the technical solution of this application embodiment is provided. In this application embodiment, the first core network device receives a request message from a terminal device, which requests to register with the first network through the SNPN. If it is determined that the terminal device has already registered with the first network through the SNPN, the first core network device will reject the terminal device's registration, thereby reducing the redundant registration process of the terminal device. Furthermore, since the terminal device does not need to perform this registration process, it can prevent the UE from abusing private network resources or preventing the UE from accessing public network services.
[0117] The technical solutions provided in this application can be applied to 5G systems, such as NR systems, or to next-generation mobile communication systems or other similar communication systems, without any specific limitations.
[0118] The method provided in the embodiments of this application is described below with reference to the accompanying drawings.
[0119] This application provides a first communication method, please refer to [link to relevant documentation]. Figure 6 This is a flowchart of the method. It should be noted that in describing the various embodiments in this article, the application is always described as... Figure 5 The network architecture shown is an example.
[0120] For ease of explanation, the embodiments described below will be executed by the method being performed by a network device and a terminal device. The UE described in the various embodiments herein is... Figure 5The network architecture shown depicts a UE. The first network described in the various embodiments of this document is the UE's home network, for example... Figure 5 In the architecture shown, PLMN 1, or the first network, may also be an SNPN, for example, another SNPN different from SNPN1. The various embodiments of this application mainly use PLMN as an example of the first network being a PLMN. The various embodiments herein involve a first core network device, a second core network device, a third core network device, and a first network device. The first core network device is, for example, a... Figure 5 In the architecture shown, the UDM within PLMN1 can be simply referred to as UDM; the second core network device is, for example, Figure 5 In the architecture shown, the AMF within PLMN1 can be abbreviated as PLMN AMF; the third core network device is, for example, Figure 5 In the architecture shown, the AMF within SNPN1 can be simply referred to as SNPN AMF; the first network device is, for example, Figure 5 The N3IWF within PLMN1 in the architecture shown can be simply referred to as N3IWF.
[0121] S601, the UE sends a registration request message to the SNPN AMF, and the SNPN AMF receives the registration request message from the UE. To distinguish it from other registration request messages, this registration request message is referred to as Registration Request Message 1.
[0122] The registration request message 1 may include the UE's subscription concealed identifier (SUCI) or subscription permanent identifier (SUPI), and may also include the initial registration type. The initial registration type may indicate whether the UE's current registration is its first registration or an initial registration.
[0123] Additionally, the SNPN RAN can send the SNPN ID to the SNPN AMF. The SNPN AMF receives the SNPN identifier from the SNPN RAN. The SNPN identifier is, for example, the SNPN identity number (ID), or other information used to identify the SNPN. This SNPN is the SNPN to which the UE currently resides. The SNPN ID may include, for example, the PLMN ID and NID.
[0124] S602, the SNPN AMF sends a Nudm_UECM_Registration request message to the UDM, and the UDM receives the Nudm_UECM_Registration request message from the SNPNAMF. For simplicity, this Nudm_UECM_Registration request message can also be referred to as registration request message 2, or the second request message.
[0125] Registration request message 2 may include the UE's SUPI, initial registration type, SNPN AMF ID, and 3GPP access type. Additionally, registration request message 2 may include SNPN information, such as the SNPN identifier, an SNPN access mode indication, or both. The SNPN access mode indication can instruct the UE to enable SNPN access mode and access the SNPN via the Uu air interface. That is, the SNPN AMF can send the UE's currently accessed SNPN information to the UDM.
[0126] S603, UDM records the SNPN AMF context of the UE.
[0127] The UE's SNPN AMF context, also known as the UE's registration context, includes SNPN information, as well as information such as the SNPN AMF ID and 3GPP access type. If the UDM detects a non-3GPP access type AMF context of the UE in another SNPN, meaning the UE has moved from another SNPN to the current SNPN, the UDM can deregister the UE from the non-3GPP access type AMF context in the other SNPN. In other words, the UDM deletes the non-3GPP access type AMF context, or, to put it another way, the UDM can deregister the UE from its registration in other SNPNs.
[0128] S604, the UDM sends a Nudm_UECM_Registration response message to the SNPN AMF, and the SNPN AMF receives the Nudm_UECM_Registration response message from the UDM. For simplicity, this Nudm_UECM_Registration response message can also be called Registration Response Message 2, or the response message to Registration Request Message 2, or the second response message. Registration Response Message 2 indicates that the SNPN AMF has successfully registered to provide services for the UE.
[0129] S605, the SNPN AMF sends a registration response message to the UE, and the UE receives the registration response message from the SNPN AMF. To distinguish it from other registration response messages, this registration response message is referred to as Registration Response Message 1, or the response message to Registration Request Message 1. Registration Response Message 1 indicates that the UE has successfully registered with the PLMN.
[0130] After executing S601 to S605, the UE registers with the PLMN in roaming mode by accessing SNPN1. After receiving registration response message 1, the UE can establish a PDU session on SNPN1 to execute corresponding services.
[0131] S606. The UE sends a registration request message to the PLMN AMF via the N3IWF, and the PLMN AMF receives the registration request message from the UE via the N3IWF. This registration request message can be used by the UE to request registration with the PLMN. Therefore, after registering with the PLMN via roaming, the UE can establish a connection to the PLMN N3IWF through the PDU session of SNPN1, and then request to register with the PLMN again via the N3IWF.
[0132] The UE first establishes an IPsec connection with the N3IWF through a PDU session established within the SNPN, and then sends a registration request message 3 to the N3IWF through this IPsec connection. Upon receiving the registration request message 3, the N3IWF sends an N2 message to the PLMN AMF, carrying the registration request message 3. This N2 message can also be called a third request message or a registration request message 4. Alternatively, the registration request message 3 can also be called a fourth request message. The registration request message 3 may include the UE's SUPI or SUCI, as well as the initial registration type. Additionally, the N2 message may also include the PLMN ID.
[0133] Optionally, the registration request message 3 may also include the SNPN information. In this case, the UE sends the SNPN information to the PLMN AMF through the registration request message 3, without the PLMN AMF needing to obtain the SNPN information through other means, which helps to simplify the registration process.
[0134] Alternatively, registration request message 3 may not include SNPN information; the PLMN AMF can obtain the SNPN information from the N3IWF. For example, the N3IWF determines the SNPN information for the UE's access and sends it to the PLMN AMF via an N2 message, thus allowing the PLMN AMF to receive the SNPN information from the N3IWF. In this way, the UE does not need to carry SNPN information in registration request message 3, reducing the amount of information in the message.
[0135] The N3IWF can determine the SNPN information in different ways. For example, the mapping between SNPN and tunnel is pre-configured (or specified by the protocol), or the mapping between SNPN ID and tunnel is pre-configured (or specified by the protocol). This tunnel could be, for example, between the UE and the N3IWF, or between the SNPN UPF and the N3IWF. This mapping is known to the UE or UPF; for example, there is a one-to-one correspondence between the SNPN ID and the tunnel. Then, when the UE sends registration request message 3, or when the UPF forwards the UE's registration request message 3, it can select the tunnel corresponding to the SNPN the UE is accessing. The N3IWF can then determine the SNPN information accessed by the UE based on the tunnel from which registration request message 3 is received.
[0136] For example, the mapping between the IP addresses of the SNPN and the SNPN UPF is pre-configured (or specified by the protocol), or the mapping between the SNPN ID and the SNPN UPF is pre-configured (or specified by the protocol), for example, a one-to-one correspondence between the SNPN ID and the SNPN UPF IP address. Then, when the N3IWF receives the registration request message 3 from the SNPN UPF, it can determine the SNPN information accessed by the UE based on the detected IP address of the SNPN UPF.
[0137] For example, the mapping between SNPN and N3IWF is pre-configured (or specified by the protocol), or the mapping between SNPN ID and N3IWF ID is pre-configured (or specified by the protocol). This mapping is known to the UE, for example, there is a one-to-one correspondence between SNPN ID and N3IWF ID. Then, when the UE sends registration request message 3, it can select the N3IWF corresponding to the SNPN that the UE accesses. If the corresponding N3IWF receives registration request message 3 from the UE, it can determine that the SNPN accessed by the UE is the SNPN corresponding to that N3IWF.
[0138] The above methods are just examples. N3IWF can also determine the SNPN information in other ways, and this application does not limit this.
[0139] S607, the PLMN AMF sends a Nudm_UECM_Registration request message to the UDM, and the UDM receives the Nudm_UECM_Registration request message from the PLMN AMF. For simplicity, this Nudm_UECM_Registration request message can also be referred to as registration request message 5, or the first request message.
[0140] Registration Request Message 5 can be used by the PLMN AMF to request services for the UE. Registration Request Message 5 may include the UE's SUPI, initial registration type, and information including the PLMN AMF ID and non-3GPP access type. Additionally, Registration Request Message 5 may also include SNPN information; that is, the PLMN AMF can send the obtained SNPN information to the UDM.
[0141] S608, UDM determines that the UE has registered with the PLMN through the SNPN.
[0142] The UDM can obtain the SNPN information included in Registration Request Message 5. Additionally, the UDM can query the recorded registration context of the UE, specifically, the UE's SNPN AMF context. If the UE's SNPN AMF context includes SNPN information and the initial registration type, and this SNPN is the same SNPN as the one corresponding to the SNPN information included in Registration Request Message 5, then the UDM can determine that the UE has registered with the PLMN through this SNPN. To prevent the UE from registering multiple times within the same PLMN, the UDM will reject the registration request from the PLMN AMF to provide services to the UE; that is, it will reject the registration requested in Registration Request Message 5.
[0143] S609, UDM sends a Nudm_UECM_Registration response message to PLMN AMF, and PLMN AMF receives the Nudm_UECM_Registration response message from UDM. For simplicity, this Nudm_UECM_Registration response message can also be referred to as registration response message 3, or the response message to registration request message 5, or the first response message.
[0144] Registration response message 3 may include a failure result indication, which may indicate that the registration request for the PLMNAMF to provide services to the UE is rejected. Optionally, registration response message 3 may also include a reason value, which may indicate the reason for the rejection of registration, such as the reason that the UE has already registered with the PLMN through the SNPN.
[0145] In S610, the PLMN AMF sends a registration rejection message to the UE, and the UE receives the registration rejection message from the PLMN AMF. This registration rejection message can also be called registration response message 4, or the third response message, or the response message to registration request message 3, or the response message to registration request message 4 (i.e., message N2 in S606).
[0146] The registration rejection message may include a reason value indicating that the UE has already registered with the PLMN via SNPN. After receiving this registration rejection message, the UE may no longer request to register with the PLMN via N3IWF.
[0147] In this embodiment, the UDM can record the information of the SNPN accessed by the UE during its first 3GPP registration with the PLMN via the SNPN. Therefore, when the UE attempts a second non-3GPP registration with the PLMN via the SNPN, the UDM can reject the UE's non-3GPP registration, preventing the UE from registering to the PLMN again via the same SNPN. This saves resources consumed in the UE's second registration process. Furthermore, since the UE can no longer register to the PLMN via N3IWF, control over the UE's access to public network services via the SNPN is achieved.
[0148] The following embodiments of this application provide a second communication method, please refer to... Figure 7 Here is a flowchart of the method.
[0149] S701, the UE sends a registration request message to the SNPN AMF, and the SNPN AMF receives the registration request message from the UE. To distinguish it from other registration request messages, this registration request message is referred to as Registration Request Message 1.
[0150] For more information about the S701, please refer to [link / reference]. Figure 6 The embodiment shown describes S601.
[0151] S702, the SNPN AMF sends a Nudm_UECM_Registration request message to the UDM, and the UDM receives the Nudm_UECM_Registration request message from the SNPNAMF. For simplicity, this Nudm_UECM_Registration request message can also be referred to as registration request message 2, or the second request message.
[0152] For more information about the S702, please refer to [link / reference]. Figure 6 The embodiment shown describes S602.
[0153] S703, UDM records the SNPN AMF context of the UE.
[0154] For more information about the S703, please refer to [link / reference]. Figure 6 The embodiment shown describes S603.
[0155] S704, the UDM sends a Nudm_UECM_Registration response message to the SNPN AMF, and the SNPN AMF receives the Nudm_UECM_Registration response message from the UDM. For simplicity, this Nudm_UECM_Registration response message can also be called Registration Response Message 2, or the response message to Registration Request Message 2, or the second response message. Registration Response Message 2 indicates that the SNPN AMF has successfully registered to provide services for the UE.
[0156] S705, the SNPN AMF sends a registration response message to the UE, and the UE receives the registration response message from the SNPN AMF. To distinguish it from other registration response messages, this registration response message is referred to as Registration Response Message 1, or the response message to Registration Request Message 1. Registration Response Message 1 indicates that the UE has successfully registered with the PLMN.
[0157] For more information about the S705, please refer to [link / reference]. Figure 6 The embodiment shown describes S605.
[0158] S706. The UE sends a registration request message to the PLMN AMF via the N3IWF, and the PLMN AMF receives the registration request message from the UE via the N3IWF. This registration request message can be used by the UE to request registration with the PLMN. Therefore, after registering with the PLMN via roaming, the UE can establish a connection to the PLMN N3IWF through the PDU session of SNPN1, and then request to register with the PLMN again via the N3IWF.
[0159] The UE first establishes an IPsec connection with the N3IWF through a PDU session established within the SNPN, and then sends a registration request message 3 to the N3IWF through this IPsec connection. After receiving the registration request message 3, the N3IWF sends an N2 message to the PLMN AMF, which carries the registration request message 3. For example, this N2 message can also be called a third request message or a registration request message 4. The registration request message 3 can also be called a fourth request message.
[0160] For more information about the S706, please refer to [link / reference]. Figure 6 The embodiment shown describes S606.
[0161] S707 and PLMN AMF send a Nudm_UECM_Registration request message to UDM, and UDM receives the Nudm_UECM_Registration request message from PLMNAMF. For simplicity, this Nudm_UECM_Registration request message can also be referred to as registration request message 5, or the first request message.
[0162] For more information about the S707, please refer to [link / reference]. Figure 6 The embodiment shown describes S607.
[0163] S708, UDM determines that the UE has registered with the PLMN through the SNPN.
[0164] The UDM can obtain the SNPN information included in Registration Request Message 5. Additionally, the UDM can query the recorded registration context of the UE, specifically, the UE's SNPN AMF context. If the UE's SNPN AMF context includes SNPN information and the initial registration type, and this SNPN is the same SNPN as the one corresponding to the SNPN information included in Registration Request Message 5, then the UDM can determine that the UE has registered with the PLMN through this SNPN.
[0165] S709, UDM sends a Nudm_UECM_Registration response message to PLMN AMF, and PLMN AMF receives the Nudm_UECM_Registration response message from UDM. For simplicity, this Nudm_UECM_Registration response message can also be referred to as registration response message 3, or the response message to registration request message 5, or the first response message.
[0166] Registration response message 3 can implicitly indicate that the UE has registered with the current PLMN through the SNPN. For example, if registration response message 3 includes the UE's registration context (i.e., the UE's SNPN AMF context), including the UE's registration context is equivalent to implicitly indicating that the UE has registered with the PLMN through the SNPN.
[0167] Alternatively, registration response message 3 can explicitly indicate that the UE has registered with the current PLMN via the SNPN. For example, registration response message 3 includes indication information that indicates the UE has registered with the PLMN via the SNPN. Compared to the UE's registration context, the indication information is less information-intensive, which helps reduce signaling overhead.
[0168] S710 and PLMN AMF determined to reject the UE's registration request.
[0169] After receiving Registration Response Message 3, the PLMN AMF can determine to reject the UE's current non-3GPP registration. For example, the PLMN AMF can determine to reject the UE's current registration based on the SNPN information, the initial registration type, and the UE's registration context; or, if Registration Response Message 3 includes indication information, the PLMN AMF can determine based on the indication information that the UE has already registered with the current PLMN through the SNPN, thereby rejecting the UE's current registration.
[0170] S711, the PLMN AMF sends a Nudm_UECM_DeRegistration request message to the UDM, and the UDM receives the Nudm_UECM_DeRegistration request message from the PLMN AMF. For simplicity, this Nudm_UECM_DeRegistration request message is also referred to as the deregistration request message, or the fourth request message.
[0171] The deregistration request message can be used to request the UDM to deregister the PLMN AMF from its registration in the UDM. That is, if the PLMNAMF sends registration request message 5 to the UDM in S707, the deregistration request message is used to deregister the PLMN AMF from its registration in this instance. In this embodiment, the PLMN AMF decides to reject the UE's registration request, rather than the UDM. Therefore, the UDM may not proactively deregister the PLMN AMF from its registration in the UDM. Thus, if the PLMNAMF rejects the UE's registration request, the PLMN AMF can still request the UDM to deregister the PLMN AMF from its registration in the UDM. The fourth request message may include the PLMN ID, the PLMN AMF ID, the UE's SUPI, and the N3GPP AccessType.
[0172] S712, UDM removes the registration context of the PLMN AMF corresponding to the SNPN from the UE's context. That is, UDM deregisters the PLMN AMF for this registration.
[0173] In S713, the PLMN AMF sends a registration rejection message to the UE, and the UE receives the registration rejection message from the PLMN AMF. This registration rejection message can also be called registration response message 4, or the third response message, or the response message to registration request message 3, or the response message to registration request message 4 (i.e., message N2 in S706).
[0174] Registration response message 4 may include a reason value indicating that the UE has already registered with the PLMN via SNPN. After receiving this registration rejection message, the UE may no longer request to register with the PLMN via N3IWF.
[0175] In this embodiment, the UDM can record the information of the SNPN accessed by the UE during its first 3GPP registration with the PLMN via the SNPN. Therefore, when the UE performs a second non-3GPP registration with the PLMN via the SNPN, the UDM can send the corresponding information to the PLMN AMF, allowing the PLMN AMF to reject the UE's non-3GPP registration and prevent the UE from registering with the PLMN again via the same SNPN. This saves resources consumed in the UE's second registration process. Furthermore, since the UE can no longer register with the PLMN via N3IWF, control over the UE's access to public network services via the SNPN is achieved.
[0176] Next, consider another problem. Figure 8 As shown, PLMN1 supports interoperability with SNPN1 via roaming. For example, a UE registers with PLMN1 via roaming using a subscription on SNPN1. Subsequently, the UE may move, for example, to SNPN2. After moving to SNPN2, because the UE is also a subscriber on SNPN2, it can access SNPN2 and request to register with the PLMN via N3IWF. If the PLMN rejects the UE's registration request because it has already registered with the PLMN through SNPN1, the UE may malfunction. Therefore, this application proposes that the PLMN should not reject the UE's re-registration process when the UE moves. The following examples illustrate the solution provided by this application.
[0177] This application provides a third communication method; please refer to [reference needed]. Figure 9 Here is a flowchart of the method.
[0178] First, the UE uses a PLMN to sign up and registers with the PLMN via roaming on SNPN1. For more information on this, please refer to [link / reference needed]. Figure 6 The following describes the relevant steps S601 to S605 in the illustrated embodiment. After registration, the UE moves to the second SNPN, which is, for example, a... Figure 8 The SNPN2 shown.
[0179] S901, the UE uses SNPN2 to sign up and register with SNPN2. The process of UE registration to SNPN2 will not be described in detail.
[0180] S902 and UE establish PDU sessions on SNPN2, which will not be elaborated on further.
[0181] S903, the UE sends a registration request message to the PLMN AMF via the N3IWF, and the PLMN AMF receives the registration request message from the UE via the N3IWF. This registration request message can be used by the UE to request registration with the PLMN. Therefore, after moving, the UE can access a new SNPN and then request to register with the PLMN again via the PLMN N3IWF.
[0182] The UE first establishes an IPsec connection with the N3IWF through a PDU session established within SNPN2, and then sends a registration request message 3 to the N3IWF through this IPsec connection. Upon receiving the registration request message 3, the N3IWF sends an N2 message to the PLMN AMF, carrying the registration request message 3. For example, the registration request message 3 can also be called a third request message or registration request message 4. The registration request message 3 may include the UE's SUPI or SUCI, and the mobility registration type. Additionally, the N2 message may also include the PLMN ID. The mobility registration type can indicate that the registration request message 3 is a registration request triggered by the UE's mobility, or indicate that this registration is triggered by the UE's mobility.
[0183] Optionally, registration request message 3 may also include SNPN2 information. In this case, the UE sends the SNPN2 information to the PLMN AMF via registration request message 3, eliminating the need for the PLMN AMF to obtain the SNPN2 information through other means, thus simplifying the registration process.
[0184] Alternatively, registration request message 3 may not include SNPN2 information, and the PLMN AMF can obtain the SNPN2 information from the N3IWF. For example, the N3IWF determines the SNPN2 information for the UE's access and sends this information to the PLMN AMF via an N2 message, thus allowing the PLMN AMF to receive the SNPN2 information from the N3IWF. In this way, the UE does not need to carry the SNPN2 information in registration request message 3, reducing the amount of information in the message.
[0185] For more information about S903, such as how N3IWF determines SNPN2 information, please refer to [link / reference needed]. Figure 6 The embodiment shown describes S606.
[0186] S904, the PLMN AMF sends a Nudm_UECM_Registration request message to the UDM, and the UDM receives the Nudm_UECM_Registration request message from the PLMN AMF. For simplicity, this Nudm_UECM_Registration request message can also be referred to as registration request message 5, or the first request message.
[0187] Registration request message 5 can be used by the PLMN AMF to request services for the UE. Registration request message 5 may include the UE's SUPI, as well as the PLMN AMF ID and non-3GPP access type. Additionally, registration request message 5 may also include SNPN2 information and the mobile registration type.
[0188] S905 and UDM confirm that PLMN AMF will provide services to UE.
[0189] The UDM determines that the UE is a post-mobile registration based on the mobile registration type. Furthermore, based on the SNPN2 information and the recorded UE SNPN AMF context, the UDM determines that the UE previously registered with the PLMN via SNPN1. Therefore, the UDM decides to accept the PLMNAMF to provide services to the UE.
[0190] Furthermore, since the UDM accepts the PLMN AMF to provide services to the UE, the UDM can deregister the UE through the registration of SNPN1 in the PLMN to avoid the UE registering twice within the PLMN. For example, the UDM can delete the registration context of SNPN1 corresponding to the AMF in SNPN1, that is, delete the context information of SNPN1AMF from the UE's context, thereby enabling the UE to deregister through the registration of SNPN1 in the PLMN.
[0191] S906, the UDM sends a Nudm_UECM_Registration response message to the PLMN AMF, and the PLMN AMF receives the Nudm_UECM_Registration response message from the UDM. For simplicity, this Nudm_UECM_Registration response message can also be called registration response message 3, or the response message to registration request message 5, or the first response message. The first response message indicates that the PLMN AMF has successfully registered to provide services for the UE.
[0192] In S907, the PLMN AMF sends a registration response message to the UE, and the UE receives the registration response message from the PLMN AMF. This registration response message can also be called registration response message 4, or the third response message, or the response message to registration request message 3, or the response message to registration request message 4 (i.e., the N2 message in S903). Registration response message 4 indicates that the UE has successfully registered with the PLMN, that is, the UE has successfully registered with the PLMN through SNPN2.
[0193] In this embodiment, when a UE moves from SNPN1 to SNPN2, the PLMN can accept the UE's non-3GPP registration with the PLMN via SNPN2, enabling the UE to function normally. Furthermore, it can also register the UE's 3GPP registration with the PLMN via SNPN1, thus avoiding the UE registering twice within the PLMN.
[0194] Next, this application provides a fourth communication method, please refer to... Figure 10 Here is a flowchart of the method.
[0195] First, the UE uses a PLMN contract and registers with the PLMN via roaming on SNPN1. For more information on this, please refer to [link / reference needed]. Figure 6 The following describes the relevant steps S601 to S605 in the illustrated embodiment. After registration, the UE moves to the second SNPN, which is, for example, a... Figure 8 The SNPN2 shown.
[0196] S1001. The UE uses SNPN2 to sign up and register with SNPN2. The process of UE registration with SNPN2 will not be described in detail.
[0197] S1002, the UE establishes a PDU session in SNPN2, which will not be elaborated on further.
[0198] S1003, the UE sends a registration request message to the PLMN AMF via the N3IWF, and the PLMN AMF receives the registration request message from the UE via the N3IWF. This registration request message can be used by the UE to request registration with the PLMN. Therefore, after moving, the UE can access a new SNPN and then request to register with the PLMN again via the PLMN N3IWF.
[0199] For more information about S1003, please refer to [link / reference]. Figure 9 The embodiment shown describes S903.
[0200] S1004, the PLMN AMF sends a Nudm_UECM_Registration request message to the UDM, and the UDM receives the Nudm_UECM_Registration request message from the PLMN AMF. For simplicity, this Nudm_UECM_Registration request message can also be referred to as registration request message 5, or the first request message.
[0201] For more information about S1004, please refer to [link / reference]. Figure 9 The embodiment shown describes S904.
[0202] S1005, the UDM sends a Nudm_UECM_Registration response message to the PLMN AMF, and the PLMN AMF receives the Nudm_UECM_Registration response message from the UDM. For simplicity, this Nudm_UECM_Registration response message can also be called registration response message 3, or the response message to registration request message 5, or the first response message. The first response message indicates that the PLMN AMF has successfully registered to provide services for the UE. The UDM determines that the UE is registered after moving based on the mobile registration type. Based on the SNPN2 information and the recorded UE SNPN AMF context, the UDM determines that the UE last registered to the PLMN through SNPN1. Therefore, the UDM decides to accept the PLMN AMF to provide services to the UE and carries the UE's registration context (i.e., the UE's SNPN AMF context) in the first response message. The UE's registration context can implicitly indicate that the PLMN AMF has successfully registered to provide services to the UE. Alternatively, the UDM can also carry indication information in the first response message, which can indicate that the UE has registered to the PLMN through SNPN or indicate that the PLMN AMF has successfully registered to provide services to the UE.
[0203] S1006 and PLMN AMF have confirmed that they will accept the UE's registration for this time.
[0204] The PLMN AMF determines that the UE is registered after moving based on the mobile registration type. Furthermore, the PLMN AMF determines to accept the UE's current registration with the PLMN based on the SNPN2 information, the mobile registration type, and the UE's registration context in the first response message.
[0205] S1007, the PLMN AMF sends a Nudm_UECM_DeRegistration request message to the UDM, and the UDM receives the Nudm_UECM_DeRegistration request message from the PLMN AMF. For simplicity, this Nudm_UECM_DeRegistration request message is also referred to as the deregistration request message, or the second request message.
[0206] A deregistration request message can request (or instruct) the UE to deregister from its registration within the PLMN via SNPN1. Figure 9 In the illustrated embodiment, the UDM determines whether to accept the PLMN AMF's service for the UE accessing SNPN2. Therefore, the UDM can independently deregister from the SNPN1 AMF without notification from the PLMN AMF. However, in this embodiment, the PLMN AMF determines whether to accept the UE's registration with the PLMN through SNPN2. Therefore, the PLMN AMF can also request the UDM to deregister from the SNPN1 AMF. The deregistration request message may include the PLMN ID, PLMN AMF ID, the UE's SUPI, and the 3GPP Access Type.
[0207] S1008, UDM deletes the registration context of SNPN1 corresponding to the AMF within SNPN1. For example, UDM deletes the context information of the SNPN1 AMF from the UE's context, thereby enabling the UE to deregister from the PLMN through SNPN1.
[0208] In S1009, the PLMN AMF sends a registration response message to the UE, and the UE receives the registration response message from the PLMN AMF. This registration response message can also be called registration response message 4, or the third response message, or the response message to registration request message 3, or the response message to registration request message 4 (i.e., the N2 message in S1003). Registration response message 4 indicates that the UE has successfully registered with the PLMN, that is, the UE has successfully registered with the PLMN through SNPN2.
[0209] In this embodiment, when a UE moves from SNPN1 to SNPN2, the PLMN can accept the UE's non-3GPP registration with the PLMN via SNPN2, enabling the UE to function normally. Furthermore, it can also register the UE's 3GPP registration with the PLMN via SNPN1, thus avoiding the UE registering twice within the PLMN.
[0210] Based on the same inventive concept, such as Figure 11The diagram shown is a schematic of an apparatus provided in this application. This apparatus can be a first core network device, a second core network device, a first network device, or a chip. When the apparatus is a first core network device or a chip, the apparatus 1100 can be used to perform... Figure 6 The illustrated embodiments Figure 7 The illustrated embodiments Figure 9 The illustrated embodiments or Figure 10 The operations shown in the embodiment are performed by the PLMN UDM. When the device is a second core network device or chip, the device 1100 can be used to perform... Figure 6 The illustrated embodiments Figure 7 The illustrated embodiments Figure 9 The illustrated embodiments or Figure 10 The operations shown in the embodiment are performed by the PLMN AMF. When the device is the first network device or chip, the device 1100 can be used to perform... Figure 6 The illustrated embodiments Figure 7 The illustrated embodiments Figure 9 The illustrated embodiments or Figure 10 The operations performed by N3IWF in the illustrated embodiment.
[0211] The device 1100 includes at least one processor 1101, a communication line 1102, and at least one communication interface 1104. As an optional implementation, the device 1100 may also include a memory 1103. Because the memory 1103 is not a mandatory functional module but only an optional one, therefore... Figure 11 The dashed box indicates the area.
[0212] Processor 1101 may include a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the present application.
[0213] Communication line 1102 may include a path for transmitting information between the aforementioned components.
[0214] Communication interface 1104 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), wired access network, etc.
[0215] The memory 1103 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 1103 may exist independently and be connected to the processor 1101 via communication line 1102. Alternatively, the memory 1103 may be integrated with the processor 1101.
[0216] The memory 1103 stores computer execution instructions for carrying out the embodiments of this application, and its execution is controlled by the processor 1101. The processor 1101 executes the computer execution instructions stored in the memory 1103, thereby implementing the communication method provided in the above embodiments of this application.
[0217] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.
[0218] In a specific implementation, as one example, the processor 1101 may include one or more CPUs, for example... Figure 11 CPU0 and CPU1 in the CPU.
[0219] In a specific implementation, as one embodiment, device 1100 may include multiple processors, for example... Figure 11 Processors 1101 and 1108 are mentioned. Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).
[0220] when Figure 11When the device shown is a chip, such as a chip for a first core network device, a chip for a second core network device, or a chip for a first network device, the chip includes a processor 1101 (which may also include a processor 1108), a communication line 1102, a memory 1103, and a communication interface 1104. Specifically, the communication interface 1104 may be an input interface, pins, or circuits, etc. The memory 1103 may be a register, cache, etc. The processor 1101 and processor 1108 may be a general-purpose CPU, microprocessor, ASIC, or one or more integrated circuits for controlling the execution of a program that controls the communication method of any of the above embodiments.
[0221] This application embodiment can divide the device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. For example, when dividing the device into functional modules according to each function, Figure 12 A schematic diagram of an apparatus is shown. The apparatus 1200 may be the first core network device involved in the above embodiments, or the second core network device involved in the above embodiments, or the first network device involved in the above embodiments, or a chip in the first core network device, or a chip in the second core network device, or a chip in the first network device. The apparatus 1200 includes a transmitting unit 1201, a processing unit 1202, and a receiving unit 1203.
[0222] In one embodiment, when device 1200 is as described above Figure 6 The illustrated embodiments or Figure 7 When the first core network device or the chip of the first core network device in the embodiment shown is used, then:
[0223] Receiving unit 1203 is used to receive a first request message from a second core network device. The first request message is used by the second core network device to request services to a terminal device. The first request message includes an initial registration type and information about the non-public network accessed by the terminal device. The initial registration type is used to indicate that the first request message is an initial registration request for the terminal device. The device 1200 is located in a first network, which is the home network of the terminal device.
[0224] Processing unit 1202 is used to determine that the terminal device has registered to the first network through the non-public network;
[0225] The sending unit 1201 is used to send a first response message to the second core network device. The first response message includes a failure result indication, or includes the registration context of the terminal device, or includes indication information indicating that the terminal device has registered to the first network through the non-public network.
[0226] As an optional implementation, the information of the non-public network includes the identifier of the non-public network and / or, a non-public network access mode indication.
[0227] As an optional implementation, the receiving unit 1203 is configured to receive a second request message from a third core network device, the second request message being used by the third core network device to request services for the terminal device, and the second request message including information about the non-public network. The processing unit 1202 is configured to record the registration context of the terminal device, the registration context including information about the non-public network. The sending unit 1201 is configured to send a second response message to the third core network device, the second response message indicating that the third core network device has successfully registered to provide services to the terminal device.
[0228] As an optional implementation, the processing unit 1202 is configured to determine that the terminal device has registered to the first network through the non-public network by: determining that the terminal device has registered to the first network through the non-public network based on the initial registration type, the information of the non-public network, and the recorded registration context of the terminal device.
[0229] As an optional implementation, the first response message further includes a cause value, which indicates that the terminal device has registered with the first network through the non-public network.
[0230] As an optional implementation, the processing unit 1202 is further configured to delete the registration context of the second core network device corresponding to the non-public network; or, the receiving unit 1203 is further configured to receive a fourth request message from the second core network device, the fourth request message being used to request the device 1200 to deregister the second core network device in the device 1200, and the processing unit 1202 is further configured to delete the registration context of the second core network device corresponding to the non-public network.
[0231] In one embodiment, when device 1200 is as described above Figure 6 The illustrated embodiments or Figure 7 When the second core network device or the chip of the second core network device in the embodiment shown is used, then:
[0232] Receiving unit 1203 is used to receive a third request message from a terminal device through a first network device. The third request message is used by the terminal device to request registration with the first network. The device 1200 is located in the first network, which is the home network of the terminal device.
[0233] Processing unit 1202 is used to obtain information about the non-public network accessed by the terminal device;
[0234] The sending unit 1201 is used to send a first request message to the first core network device. The first request message is used by the device 1200 to request services to the terminal device. The first request message includes an initial registration type and information about the non-public network. The initial registration type is used to indicate that the first request message is an initial registration request for the terminal device.
[0235] The receiving unit 1203 is further configured to receive a first response message from the first core network device. The first response message includes a failure result indication, or includes the registration context of the terminal device, or includes indication information indicating that the terminal device has registered to the first network through the non-public network.
[0236] The sending unit 1201 is also configured to send a third response message, which is used to reject the registration of the terminal device.
[0237] As an optional implementation, the information of the non-public network includes the identifier of the non-public network and / or, a non-public network access mode indication.
[0238] As an optional implementation, the processing unit 1202 is used to obtain information about the non-public network accessed by the terminal device in the following ways: obtaining information about the non-public network from the third request message; or receiving information about the non-public network from the first network device through the receiving unit 1203.
[0239] As an optional implementation, the third response message also includes a cause value, which indicates that the terminal device has registered with the first network through the non-public network.
[0240] As an optional implementation, the sending unit 1201 is further configured to send a fourth request message to the first core network device, the fourth request message being used to request the first core network device to deregister the device 1200 from the first core network device.
[0241] As an optional implementation, before the sending unit 1201 sends the third response message, the processing unit 1202 is further configured to determine, based on the first response message, to reject the registration of the terminal device.
[0242] In one embodiment, when device 1200 is as described above Figure 9 The illustrated embodiments or Figure 10 When the first core network device or the chip of the first core network device in the embodiment shown is used, then:
[0243] The receiving unit 1203 is used to receive a first request message from a second core network device. The first request message is used by the second core network device to request services to the terminal device. The first request message also includes information on the mobile registration type and a second non-public network. The mobile registration type is used to indicate that the first request message is a registration request triggered by the terminal device due to mobility. The device 1200 is located in a first network, which is the home network of the terminal device.
[0244] The sending unit 1201 is used to send a first response message to the second core network device, the first response message being used to indicate that the second core network device has successfully registered to provide services to the terminal device.
[0245] As an optional implementation, the processing unit 1202 is used to deregister the terminal device from its registration on the first network via the first non-public network.
[0246] As an optional implementation, the processing unit 1202 is configured to deregister the terminal device from its registration on the first network via the first non-public network by deleting the registration context of the third core network device corresponding to the first non-public network; or, by receiving a second request message from the second core network device via the receiving unit 1203, the second request message being used to instruct the deregistration of the terminal device from its registration on the first network via the first non-public network, and deleting the registration context of the third core network device corresponding to the first non-public network.
[0247] As an optional implementation, the information of the second non-public network includes the identifier of the second non-public network and / or, a non-public network access mode indication.
[0248] As an optional implementation, the receiving unit 1203 is further configured to receive a second request message from the third core network device, the second request message being used by the third core network device to request services for the terminal device, the second request message including information of the first non-public network; the processing unit 1202 is further configured to record the registration context of the terminal device, the registration context of the terminal device including information of the first non-public network; and the sending unit 1201 is further configured to send a second response message to the third core network device, the second response message being used to indicate that the third core network device has successfully registered to provide services for the terminal device.
[0249] As an optional implementation, the information of the first non-public network includes the identifier of the first non-public network and / or, a non-public network access mode indication.
[0250] As an optional implementation, the first response message includes the registration context of the terminal device.
[0251] As an optional implementation, the processing unit 1202 is further configured to determine, before the sending unit 1201 sends the first response message to the second core network device, that the second core network device has successfully registered to provide services to the terminal device, based on the mobile registration type, the information of the second non-public network, and the recorded registration context of the terminal device.
[0252] In one embodiment, when device 1200 is as described above Figure 9 The illustrated embodiments or Figure 10 When the second core network device or the chip of the second core network device in the embodiment shown is used, then:
[0253] The receiving unit 1203 is configured to receive a third request message from a terminal device through a first network device. The third request message is used by the terminal device to request registration with the first network. The third request message also includes a mobile registration type, which indicates that the third request message is a registration request triggered by the terminal device due to mobility. The first network is the home network of the terminal device.
[0254] The sending unit 1201 is used to send a first request message to the first core network device. The first request message is used by the device 1200 to request services to the terminal device. The first request message includes the mobile registration type and information about the second non-public network.
[0255] The receiving unit 1203 is also configured to receive a first response message from the first core network device, wherein the first response message is used to indicate that the device 1200 has successfully registered to provide services to the terminal device;
[0256] The sending unit 1201 is further configured to send a third response message to the terminal device, the third response message being used to indicate that the terminal device has successfully registered to the first network.
[0257] As an optional implementation, the information of the second non-public network includes the identifier of the second non-public network and / or, a non-public network access mode indication.
[0258] As an optional implementation, the first response message may also include the registration context of the terminal device.
[0259] As an optional implementation, the processing unit 1202 is further configured to determine, before the sending unit 1201 sends a third response message to the terminal device, that the terminal device has successfully registered to the first network based on the mobile registration type, the information of the second non-public network, and the registration context of the terminal device.
[0260] As an optional implementation, the sending unit 1201 is further configured to send a second request message to the first core network device, the second request message being used to instruct the terminal device to deregister from the registration of the terminal device on the first network through the first non-public network.
[0261] In one embodiment, when device 1200 is as described above Figure 6 The illustrated embodiments Figure 7 The illustrated embodiments Figure 9 The illustrated embodiments or Figure 10 When the chip of the first network device in the embodiment shown is used, then:
[0262] Receiving unit 1203 is used to receive a fourth request message from a terminal device. The fourth request message is used for the terminal device to request registration with a first network. The device 1200 is located in the first network, which is the home network of the terminal device.
[0263] Processing unit 1202 is used to determine information about the non-public network accessed by the terminal device;
[0264] The sending unit 1201 is used to send information about the non-public network to the second core network device.
[0265] As an optional implementation, the processing unit 1202 is used to determine the information of the non-public network accessed by the terminal device in the following ways: determining the information of the non-public network accessed by the terminal device based on the correspondence between the non-public network and the tunnel or IP address; or, determining the information of the non-public network accessed by the terminal device based on the correspondence between the non-public network and the first network device.
[0266] It should be understood that the device 1200 can be used to implement the steps performed by the first core network device, the second core network device or the first network device in the method of the embodiments of this application. The relevant features can be referred to above, and will not be repeated here.
[0267] Specifically, Figure 12 The functions / implementation processes of the transmitting unit 1201, receiving unit 1203, and processing unit 1202 can be understood through... Figure 11 The processor 1101 in the memory calls computer execution instructions stored in memory 1103 to implement this. Or, Figure 12 The function / implementation process of the processing unit 1202 can be achieved through... Figure 11 The processor 1101 in the memory calls computer execution instructions stored in memory 1103 to implement this. Figure 12 The functions / implementation process of the transmitting unit 1201 and the receiving unit 1203 can be obtained through Figure 11 It is implemented using the communication interface 1104.
[0268] Optionally, when the device 1100 is a chip or circuit, the functions / implementation processes of the transmitting unit 1201 and the receiving unit 1203 can also be implemented through pins or circuits within the device 1100. Optionally, when the device 1100 is a chip, the memory 1103 can be a storage unit within the chip, such as a register or cache. Of course, when the device 1100 is a first core network device, such as the UDM in the above embodiment, the memory 1103 can also be a storage unit located outside the chip within the first core network device; this application embodiment does not specifically limit this. When the device 1100 is a second core network device, the memory 1103 can also be a storage unit located outside the chip within the second core network device; this application embodiment does not specifically limit this. When the device 1100 is a first network device, the memory 1103 can also be a storage unit located outside the chip within the first network device; this application embodiment does not specifically limit this.
[0269] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).
[0270] The various illustrative logic units and circuits described in the embodiments of this application can be implemented or operate the described functions using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor can be a microprocessor; alternatively, it can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented using a combination of computing devices, such as a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.
[0271] The steps of the methods or algorithms described in the embodiments of this application can be directly embedded in hardware, software units executed by a processor, or a combination of both. The software units can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and storage medium can be housed in an ASIC, which can be housed in a terminal device. Optionally, the processor and storage medium can also be housed in different components within the terminal device.
[0272] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0273] Although embodiments of this application have been described in conjunction with specific features and examples, it is obvious that various modifications and combinations can be made without departing from the spirit and scope of the embodiments of this application. Accordingly, the embodiments and drawings of this application are merely exemplary illustrations of the embodiments of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of the embodiments of this application. Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the scope of the embodiments of this application. Thus, if these modifications and variations of the embodiments of this application fall within the scope of the claims of the embodiments of this application and their equivalents, then the embodiments of this application are also intended to include these modifications and variations.
Claims
1. A communication method, characterized in that, include: A first core network device within a first network receives a first request message from a second core network device. The first request message is used by the second core network device to request services for a terminal device. The first request message includes an initial registration type and information about the non-public network accessed by the terminal device. The initial registration type is used to indicate that the first request message is an initial registration request for the terminal device, and the first network is the home network of the terminal device. The first core network device determines that the terminal device has registered to the first network through the non-public network; The first core network device sends a first response message to the second core network device. The first response message includes a failure result indication, or includes the registration context of the terminal device, or includes indication information indicating that the terminal device has registered to the first network through the non-public network.
2. The method according to claim 1, characterized in that, The information of the non-public network includes the identifier of the non-public network and / or, the non-public network access mode indication.
3. The method according to claim 1 or 2, characterized in that, The method further includes: The first core network device receives a second request message from the third core network device. The second request message is used by the third core network device to request services to the terminal device. The second request message includes information about the non-public network. The first core network device records the registration context of the terminal device, the registration context of the terminal device including information about the non-public network; and, The first core network device sends a second response message to the third core network device, the second response message being used to indicate that the third core network device has successfully registered to provide services to the terminal device.
4. The method according to claim 3, characterized in that, The first core network device determines that the terminal device has registered to the first network through the non-public network, including: The first core network device determines, based on the initial registration type, the information of the non-public network, and the recorded registration context of the terminal device, that the terminal device has registered to the first network through the non-public network.
5. The method according to any one of claims 1, 2, and 4, characterized in that, The first response message also includes a reason value, which indicates that the terminal device has registered with the first network through the non-public network.
6. The method according to any one of claims 1, 2, and 4, characterized in that, The method further includes: The first core network device deletes the registration context of the second core network device corresponding to the non-public network; or, The first core network device receives a fourth request message from the second core network device, the fourth request message being used to request the first core network device to deregister the second core network device from the first core network device; The first core network device deletes the registration context of the second core network device corresponding to the non-public network.
7. A communication method, characterized in that, include: The second core network device within the first network receives a third request message from the terminal device through the first network device. The third request message is used by the terminal device to request registration with the first network, where the first network is the home network of the terminal device. The second core network device obtains information about the non-public network accessed by the terminal device; The second core network device sends a first request message to the first core network device. The first request message is used by the second core network device to request services for the terminal device. The first request message includes an initial registration type and information about the non-public network. The initial registration type is used to indicate that the first request message is an initial registration request for the terminal device. The second core network device receives a first response message from the first core network device. The first response message includes a failure result indication, or includes the registration context of the terminal device, or includes indication information indicating that the terminal device has registered to the first network through the non-public network. The second core network device sends a third response message, which is used to reject the registration of the terminal device.
8. The method according to claim 7, characterized in that, The information of the non-public network includes the identifier of the non-public network and / or, the non-public network access mode indication.
9. The method according to claim 7 or 8, characterized in that, The second core network device obtains information about the non-public network accessed by the terminal device, including: The second core network device obtains information about the non-public network from the third request message; or, The second core network device receives information from the non-public network of the first network device.
10. The method according to claim 7 or 8, characterized in that, The third response message also includes a reason value, which indicates that the terminal device has registered with the first network through the non-public network.
11. The method according to claim 7 or 8, characterized in that, The method further includes: The second core network device sends a fourth request message to the first core network device, the fourth request message being used to request the first core network device to deregister the second core network device from the first core network device.
12. The method according to claim 7 or 8, characterized in that, Before the second core network device sends the third response message, the method further includes: The second core network device determines to reject the registration of the terminal device based on the first response message.
13. A communication device, characterized in that, It includes a processor and a memory; the memory is used to store one or more computer programs that, when the one or more computer programs are run, cause the method as described in any one of claims 1 to 6 to be performed, or cause the method as described in any one of claims 7 to 12 to be performed.
14. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 6, or causes the computer to perform the method as described in any one of claims 7 to 12.
15. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 6, or causes the computer to perform the method as described in any one of claims 7 to 12.
16. A communication system, characterized in that, This includes first core network equipment and second core network equipment, among which, The first core network device is used to perform the method as described in any one of claims 1 to 6; The second core network device is used to perform the method as described in any one of claims 7 to 12.
Citation Information
Patent Citations
Connection processing method and device in multi-access scene
CN108574969A
Interworking function using untrusted network
CN110268734A