Wireless communication method, terminal device, and network device

Abstract

Provided are a wireless communication method, a terminal device, and a network device. The method comprises: a terminal device sends to a first core network element a first request, wherein the terminal device is used to perform access by using multiple types of radio access technologies (RATs), the multiple types of RATs including a first RAT, and the first request including one or more of the following: a request used to request to register the first RAT; a request used to request to register and update the first RAT; and a request used to request to deregister the first RAT. In the embodiments of the present application, registration state using an RAT as granularity is introduced, in other words, registration state can be maintained for each connection corresponding to multiple access devices. Compared with the traditional solution which maintains registration state on the basis of access types, the present invention facilitates the simplification of the complexity of maintaining registration states corresponding to multiple access devices in a multi-access scenario.

Description

Wireless communication methods, terminal equipment and network equipment Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a wireless communication method, terminal device, and network device. Background Technology

[0002] For terminal devices with a single Universal Subscriber Identity Module (USIM) card, only one registration state (e.g., registered or deregistered) can be maintained for the same access type. However, this scheme of maintaining registration state based on access type may not be suitable for multi-access devices.

[0003] Summary of the Invention

[0004] This application provides a wireless communication method, terminal device, and network device. The various aspects covered by this application are described below.

[0005] In a first aspect, a wireless communication method is provided, comprising: a terminal device sending a first request to a first core network element, the terminal device being used to access via multiple radio access technologies (RATs), the multiple RATs including a first RAT, the first request including one or more of the following: a request to register the first RAT; a request to register and update the first RAT; a request to unregister the first RAT.

[0006] In a second aspect, a wireless communication method is provided, comprising: a first core network element receiving a first request sent by a terminal device, the terminal device being used to access via a variety of wireless access technologies (RATs), the variety of RATs including a first RAT, the first request including one or more of the following: a request to register the first RAT; a request to register and update the first RAT; a request to deregister the first RAT.

[0007] Thirdly, a wireless communication method is provided, comprising: a terminal device receiving a third request sent by a first core network element, the third request being used to request to register a first RAT of the terminal device.

[0008] Fourthly, a wireless communication method is provided, comprising: a first core network element receiving a third request sent by a second core network element, the third request being used to request to register a first RAT of a terminal device.

[0009] Fifthly, a wireless communication method is provided, comprising: a second core network element sending a third request to a first core network element, the third request being used to request to register a first RAT of a terminal device.

[0010] In a sixth aspect, a terminal device is provided, comprising: a transmitting unit, configured to send a first request to a first core network element, the terminal device being configured to access via multiple Radio Access Technologies (RATs), the multiple RATs including a first RAT, the first request including one or more of the following: a request to register the first RAT; a request to register and update the first RAT; a request to deregister the first RAT.

[0011] In a seventh aspect, a network device is provided, the network device being a first core network element, comprising: a receiving unit, configured to receive a first request sent by a terminal device, the terminal device being configured to access via multiple Radio Access Technologies (RATs), the multiple RATs including a first RAT, the first request including one or more of the following: a request to register the first RAT; a request to register and update the first RAT; a request to deregister the first RAT.

[0012] Eighthly, a terminal device is provided, comprising: a receiving unit, configured to receive a third request sent by a first core network element, the third request being used to request to register a first RAT of the terminal device.

[0013] In a ninth aspect, a network device is provided, the network device being a first core network element, comprising: a receiving unit, configured to receive a third request sent by a second core network element, the third request being used to request to register a first RAT of a terminal device.

[0014] In a tenth aspect, a network device is provided, the network device being a second core network element, comprising: a sending unit, configured to send a third request to a first core network element, the third request being used to request the registration of a first RAT of a terminal device.

[0015] Eleventhly, a terminal device is provided, including a processor, a memory, and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to invoke the computer programs in the memory, causing the terminal device to perform some or all of the steps of the methods described above.

[0016] In a twelfth aspect, a network device is provided, including a processor, a memory, and a transceiver, wherein the memory is used to store one or more computer programs, and the processor is used to invoke the computer programs in the memory to cause the network device to perform some or all of the steps in the methods described above.

[0017] In a thirteenth aspect, embodiments of this application provide a communication system including the aforementioned terminal device and / or network device. In another possible design, the system may further include other devices that interact with the terminal device or network device as described in the embodiments of this application.

[0018] In a fourteenth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that causes a communication device (e.g., a terminal device or a network device) to perform some or all of the steps in the methods described above.

[0019] In a fifteenth aspect, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a communication device (e.g., a terminal device or a network device) to perform some or all of the steps of the methods described in the foregoing aspects. In some implementations, the computer program product may be a software installation package.

[0020] In a sixteenth aspect, embodiments of this application provide a chip including a memory and a processor, the processor being able to call and run a computer program from the memory to implement some or all of the steps described in the methods of the foregoing aspects.

[0021] This application introduces a registration state at the RAT level, meaning that a registration state can be maintained for each connection corresponding to multiple access devices. Compared to traditional solutions that maintain registration states based on access type, this simplifies the complexity of maintaining the registration states of multiple access devices in multi-access scenarios. Attached Figure Description

[0022] Figure 1 shows the wireless communication system 100 used in an embodiment of this application.

[0023] Figures 2(a) and 2(b) are schematic diagrams illustrating the transition process between two registration management (RM) states on the terminal device and the access and mobility management function (AMF).

[0024] Figure 3 is a schematic flowchart of the traditional registration process.

[0025] Figure 4 is a schematic diagram of the multi-access devices applicable to the embodiments of this application.

[0026] Figure 5 is a schematic diagram of the registration status switching based on RAT in an embodiment of this application.

[0027] Figure 6 is a schematic flowchart of a wireless communication method according to an embodiment of this application.

[0028] Figures 7 to 11 are schematic flowcharts of the registration management scheme with RAT as the granularity in the embodiments of this application.

[0029] Figure 12 is a schematic diagram of a terminal device according to an embodiment of this application.

[0030] Figure 13 is a schematic diagram of a network device according to an embodiment of this application.

[0031] Figure 14 is a schematic diagram of a terminal device according to an embodiment of this application.

[0032] Figure 15 is a schematic diagram of a network device according to an embodiment of this application.

[0033] Figure 16 is a schematic diagram of a network device according to an embodiment of this application.

[0034] Figure 17 is a schematic structural diagram of a communication device according to an embodiment of this application. Detailed Implementation

[0035] The technical solutions in this application will now be described with reference to the accompanying drawings. For ease of understanding, a schematic diagram of the communication system architecture of an embodiment of this application will be introduced below with reference to Figure 1. Figure 1 is a schematic diagram of a communication system architecture applicable to an embodiment of this application. The network architecture may include terminal devices, access network (AN) nodes, and core network nodes.

[0036] It should be understood that the technical solutions of the embodiments of this application can be applied to various communication systems, such as: 5th generation (5G) systems or new radio (NR), long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, etc. The technical solutions provided in this application can also be applied to future communication systems, such as 6th generation mobile communication systems, satellite communication systems, and so on.

[0037] The terminal device in this application embodiment can also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal, remote station, remote terminal, mobile device, user terminal, terminal, wireless core network node, user agent, or user device. The terminal device in this application embodiment can be a device that provides voice and / or data connectivity to a user, and can be used to connect people, objects, and machines, such as a handheld device with wireless connectivity, vehicle-mounted device, etc. The terminal devices in the embodiments of this application can be mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc. Optionally, the terminal device can be used to act as a base station. For example, the terminal device can act as a dispatching entity, providing sidelink signals between terminal devices in vehicle-to-everything (V2X) or device-to-device (D2D) communications. For example, cellular phones and cars communicate with each other using sidelink signals. Cellular phones and smart home devices communicate without relaying communication signals through base stations.

[0038] Access network nodes can be access network devices. Access network devices are devices that terminals use to wirelessly access the network architecture. They are primarily responsible for air interface-side radio resource management, Quality of Service (QoS) management, data compression, and encryption. Access network devices can also be called radio access network (RAN) devices, such as base stations. A base station can broadly encompass, or be replaced by, various names including: NodeB, evolved NodeB (eNB), next-generation NodeB (gNB), relay station, access point, transmitting and receiving point (TRP), transmitting point (TP), master eNB (MeNB), secondary eNB (SeNB), multi-standard radio (MSR) node, home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. A base station can be a macro base station, micro base station, relay node, donor node, or similar entities, or combinations thereof. A base station can also refer to a communication module, modem, or chip installed within the aforementioned equipment or apparatus. A base station can also be a mobile switching center, a device that performs base station functions in D2D, V2X, and machine-to-machine (M2M) communications, a network-side device in a 6G network, or a device that performs base station functions in future communication systems. A base station can support networks using the same or different access technologies. The embodiments of this application do not limit the specific technologies or device forms used in the access network equipment.

[0039] Base stations can be fixed or mobile. For example, a helicopter or drone can be configured to act as a mobile base station, and one or more cells can move depending on the location of the mobile base station. In other examples, a helicopter or drone can be configured as a device to communicate with another base station.

[0040] In some deployments, the access network device in this application embodiment may refer to a CU or a DU, or the access network device may include both a CU and a DU. The gNB may also include an AAU.

[0041] Core network nodes can be categorized into several types, including User Plane Function (UPF) nodes, Access and Mobility Management Function (AMF) nodes, Session Management Function (SMF) nodes, Policy Control Function (PCF) nodes, Application Function (AF) nodes, Data Network (DN) nodes, Network Slice Selection Function (NSSF) nodes, Authentication Server Function (AUSF) nodes, Unified Data Management (UDM) nodes, Network Exposure Function (NEF) nodes, Network Repository Function (NRF) nodes, and Network Slice-Specific Authentication and Authorization Function (NSSAAF) nodes. UPF nodes are primarily responsible for user data transmission, while the other nodes, often referred to as Control Plane Function nodes, are mainly responsible for authentication, authorization, registration management, session management, mobility management, and policy control to ensure reliable and stable user data transmission.

[0042] UPF nodes can be used to forward and receive data from terminals. For example, a UPF node can receive service data from the data network and transmit it to the terminal through access network equipment; a UPF node can also receive user data from the terminal through access network equipment and forward it to the data network. The transmission resources allocated and scheduled by the UPF node for the terminal are managed and controlled by the SMF node. The bearer between the terminal and the UPF node can include: the user plane connection between the UPF node and the access network equipment, and the establishment of a channel between the access network equipment and the terminal. The user plane connection is a QoS flow that can be established between the UPF node and the access network equipment for transmitting data.

[0043] AMF nodes can be used to manage terminal access to the core network, such as terminal location updates, network registration, access control, terminal mobility management, and terminal attachment and detachment. While providing services for a terminal's session, the AMF node can also provide control plane storage resources for that session to store the session identifier and the SMF node identifier associated with the session identifier.

[0044] SMF nodes can be used to select user plane nodes for terminals, redirect user plane nodes for terminals, assign Internet Protocol (IP) addresses to terminals, establish bearers (also known as sessions) between terminals and UPF nodes, modify and release sessions, and perform QoS control.

[0045] PCF nodes are used to provide policies to AMF and SMF nodes, such as QoS policies and slice selection policies.

[0046] AF nodes are used to interact with 3GPP core network nodes to support the routing of application-impacted data, access network exposure functions, and interact with PCF nodes for policy control, etc.

[0047] A Data Network (DN) can provide data services to users for networks such as IP Multimedia Service (IMS) and the Internet. A DN can contain various application servers (AS) that provide different application services, such as carrier services, Internet access, or third-party services. The AS can implement the functions of an Application Server (AF).

[0048] NSSF is used for network slice selection and supports the following functions: selecting a set of network slice instance examples to serve the end device; determining allowed network slice selection assistance information (NSSAI), and, when necessary, determining the mapping to the subscribed single-network slice selection assistance information (S-NSSAI); determining the configured NSSAI, and, when necessary, determining the mapping to the subscribed S-NSSAI; determining the set of AMFs that may be used to query the end device, or determining a list of candidate AMFs based on the configuration.

[0049] AUSF is used to receive AMF requests for terminal authentication. It requests a key from UDM and then forwards the issued key to AMF for authentication processing.

[0050] UDM includes functions such as generating and storing user subscription information and managing authentication data, and supports interaction with external third-party servers.

[0051] NEF is used for capability exposure, meaning that based on NEF, network capabilities can be exported to external networks. Untrusted external applications can access core network data through NEF to ensure network security. NEF can provide functions such as QoS capability exposure for external applications, event subscription, and AF request distribution.

[0052] The NRF (Network Request Framework) is used for core network node registration, management, and status monitoring, thereby enabling automated management of core network nodes. When a core network node starts up, it must register with the NRF to provide services. Registration information may include, for example, the core network node's type, address, and service list.

[0053] In addition, some networks (such as 5G networks) have added network data analytics function (NWDAF) to the core network. Based on NWDAF, data can be collected from various nodes in the core network, network management system, etc., and big data statistics, analysis or intelligent data analysis can be performed to obtain network-side analysis or prediction data, thereby assisting each node to more effectively control the access of terminal devices based on the data analysis results.

[0054] In some communication systems (such as 5G systems), core network nodes can also be called network functions (NFs).

[0055] The nodes in Figure 1 can be network elements in hardware devices, software functions running on dedicated hardware, or virtualization functions implemented on a platform (e.g., a cloud platform). It should be noted that the network architecture shown in the above figures is merely an illustrative representation of the nodes included in the overall network architecture. In this application embodiment, the number of nodes included in the entire network architecture is not limited.

[0056] Those skilled in the art will understand that the network architecture shown in Figure 1 does not constitute a limitation on the network architecture. In specific implementations, the network architecture may include more or fewer nodes than shown, or combine certain nodes, etc. It should be understood that AN or RAN is represented in Figure 1 as (R)AN.

[0057] In some scenarios, network devices and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on airplanes, balloons, and satellites. This application does not limit the scenarios in which the network devices and terminal devices are located.

[0058] By way of example and not limitation, in the embodiments of this application, the network device may have mobility characteristics; for example, the network device may be a mobile device. In some embodiments of this application, the network device may be a satellite or a balloon station. For example, the satellite may be a low Earth orbit (LEO) satellite, a medium Earth orbit (MEO) satellite, a geostationary earth orbit (GEO) satellite, a high elliptical orbit (HEO) satellite, etc. In some embodiments of this application, the network device may also be a base station located on land, water, or other similar locations.

[0059] In this embodiment, the network device can provide services to a cell. The terminal device communicates with the network device through the transmission resources (e.g., frequency domain resources, or spectrum resources) used by the cell. The cell can be the cell corresponding to the network device (e.g., a base station). The cell can belong to a macro base station or to a base station corresponding to a small cell. The small cell can include: metro cell, micro cell, pico cell, femto cell, etc. These small cells have the characteristics of small coverage area and low transmission power, and are suitable for providing high-speed data transmission services.

[0060] RM

[0061] There are two RM states for terminal devices: RM-DEREGISTERED and RM-REGISTERED. When in the RM-DEREGISTERED state, the terminal device is not registered on the network, and the AMF (Activity Management Context) does not store valid location or routing information for the terminal device, making the terminal device unreachable from the AMF's perspective. However, some authentication-related terminal device contexts are stored in both the terminal device and the AMF, helping to avoid performing the authentication process on every registration, thus simplifying the terminal device's registration process. When in the RM-REGISTERED state, the terminal device is registered on the network and can conduct normal service communication through the network. At this time, the AMF stores the terminal device's mobility management context.

[0062] The following section describes the transition process of the two RM states on the terminal device and AMF, respectively, with reference to Figure 2(a) and Figure 2(b).

[0063] Referring to Figure 2(a), in a terminal device, if RM registration is rejected, the terminal device is in an RM deregistration state. Conversely, if RM registration is accepted, the terminal device transitions from an RM deregistration state to an RM registration state.

[0064] If the RM registration update is accepted in the terminal device, the terminal device is in the RM registration state.

[0065] If the deregistration request is accepted on the terminal device, the terminal device is in the RM deregistration state.

[0066] Referring to Figure 2(b), in the AMF, if RM registration is rejected, the terminal device is in the RM deregistration state. Conversely, if RM registration is accepted, the terminal device transitions from the RM deregistration state to the RM registration state.

[0067] In AMF, if the RM registration update is accepted, the terminal device is in the RM registration state.

[0068] In AMF, if the deregistration request is accepted, the terminal device is in the RM deregistration state.

[0069] Registration Area (RA) Management

[0070] In some implementations, the RA is managed at the access type granularity, meaning that the RA is managed separately for 3GPP access and non-3GPP access.

[0071] In some implementations, when a terminal device registers via a 3GPP access network, the AMF assigns it a set of tracking areas (TAs), which are listed in a TA identity (TAI) list. When the AMF assigns an RA (Registered Area) to a terminal device—that is, a set of TAs in the TAI list—various information may be considered (e.g., mobility patterns and permitted / unpermitted areas). If the AMF's entire public land mobile network (PLMN) serves as the area of ​​service, it may choose to assign the entire PLMN ("All PLMNs") as an RA to a terminal device in MICO mode. When the AMF assigns an RA to a terminal device registered for disaster roaming service, the AMF should only consider TAIs covering disaster areas.

[0072] In some implementations, 5G systems support the allocation of RAs using a single TAI list, which includes the TAs of any NG-RAN node within the RA for terminal device communication.

[0073] In some implementations, in the case of a stand-alone non-public (SNPN) network, the TAI list assigned by the AMF does not support TAs belonging to different SNPNs.

[0074] In some implementations, the TAI for non-3GPP access can be dedicated to non-3GPP access. TAI(s) dedicated to non-3GPP access can be defined in the PLMN and apply within that PLMN. Each non-3GPP interworking function (N3IWF), trusted non-3GPP gateway function (TNGF), trusted WLAN interworking function (TWIF), and wireline access gateway function (W-AGF) has a locally configured TAI value. Each N3IWF, TNGF, TWIF, and W-AGF can be configured with a different TAI value than other N3IWF, TNGF, TWIF, and / or W-AGF, or with the same TAI value. The TAI can be provided to the AMF during N2 interface setup and as part of the user location information in the terminal device association message. When a terminal device registers through a non-3GPP access network, the RA allocated by the AMF to the terminal device only includes the TAI received from the serving N3IWF, TNGF, TWIF, or W-AGF.

[0075] In some implementations, when a terminal device registers through a non-3GPP access network, the RA allocated by the AMF to the terminal device only includes the TAI received from the serving N3IWF, TNGF, TWIF, or W-AGF.

[0076] In some implementations, when a terminal device registers through a non-3GPP access network, the RA allocated by the AMF to the terminal device only includes the TAI received from the serving N3IWF, TNGF, TWIF, or W-AGF.

[0077] In some implementations, when generating the TAI list, the AMF should only include TAIs applicable to the access type (i.e., 3GPP access or non-3GPP access) for which the TAI list is sent.

[0078] It is important to note that, in order to prevent additional signaling load due to mobility registration updates every time a RAT changes, it is best to avoid generating a specific RAT's TAI list for terminal devices that support multiple RATs.

[0079] In addition, for 3GPP access, the AMF determines the RAT type of the terminal device based on the global RAN node ID associated with the N2 interface and the TA indicated by the NG-RAN.

[0080] Registration process

[0081] In some scenarios, terminal devices need to register with the network to obtain authorization to receive services, enable mobility tracking, and enable reachability. Currently, terminal devices use one of the following registration types to initiate the registration process: initial registration, mobility registration update, periodic registration update (due to predefined inactivity periods), emergency registration, disaster roaming initial registration, disaster roaming mobility registration update, and registration on SNPN to allow the terminal device to access ON-SNPN.

[0082] In some implementations, mobility registration updates can be triggered based on one or more of the following: the terminal device moves to a new TA outside the registration area while in CM-CONNECTED or CM-IDLE states; the terminal device needs to update its capabilities or protocol parameters negotiated during registration; the terminal device's preferred network behavior changes, resulting in incompatibility with supported network behaviors provided by the serving AMF; the terminal device is ready to retrieve LADN information; it moves to an appropriate cell indicating multiple TAs during NR satellite access, and all of these TAs are outside the terminal device's registration area, whether in CM-CONNECTED or CM-IDLE states; multiple USIM terminal devices require a new 5G globally unique temporary identifier (5G-GUTI) allocation; the terminal device needs to indicate or return from a period of unavailability; a terminal device using a RAN providing discontinuous coverage (e.g., satellite access with discontinuous coverage) is about to leave the satellite network coverage area; the terminal device notifies the network that it is unreachable and returns to coverage area via satellite or terrestrial access.

[0083] In some implementations, registration on the SNPN allows terminal devices to access the ON-SNPN. Its purpose is to configure SO-SNPN credentials for the terminal device to enable SO-SNPN access. Typically, registration on the SNPN only applies to initial registration when accessing the optical network node (ONN) using PLMN credentials, i.e., when the UE initiates initial registration.

[0084] It should be noted that when using NR satellite access, any cell in each PLMN can indicate multiple tracking area codes (TACs) to the terminal device.

[0085] In some implementations, if the terminal device does not have a NAS security context, the following plaintext information elements (IEs) can be sent in the registration request message: registration type; subscription concealed identifier (SUCI) or 5G-GUTI or permanent equipment identifier (PEI); security parameters; additional GUTI; 4G tracking area update; indication that the terminal device has moved from EPS; PLMN with disaster status; and if the terminal device registers using SNPN, the network identifier (NID) of the SNPN with 5G-GUTI assigned.

[0086] It should be noted that NID can be provided when 5G-GUTI is assigned by another SNPN other than the selected SNPN.

[0087] The traditional registration process is described below with reference to Figure 3. The registration process shown in Figure 3 includes steps S310 to S370.

[0088] In step S310, the terminal device sends an AN message to the AMF, which includes AN parameters and a registration request message. After the RAN selects an AMF based on the AN parameters, it sends an N2 message to the corresponding AMF, which includes N2 parameters and a registration request message.

[0089] In step S320, the AMF initiates an authentication process for the terminal device via the AUSF. Typically, the AUSF can select a UDM to obtain the terminal device's authentication data. If the NAS security context does not exist, the NAS secure boot process is executed. If the 5G-AN requests a terminal device context, the AMF initiates the NGAP process to provide the 5G-AN with a security context. The 5G-AN stores the security context and confirms it with the AMF. The 5G-AN uses the security context to protect messages exchanged by the terminal device.

[0090] In step S330, if one of the following conditions is met: the AMF has changed since the last registration procedure, the terminal device registration type is initial registration or emergency registration, the SUPI provided by the terminal device does not point to a valid context in the AMF, or the terminal device has registered with the same AMF that it has already registered for non-3GPP access (i.e., the terminal device registered through non-3GPP access and started this registration procedure to add 3GPP access), then the new AMF uses Nudm_UECM_Registration to register the access to be registered with the UDM (and subscribes to notifications about the UDM canceling this AMF event).

[0091] Accordingly, after the AMF successfully completes the Nudm_UECM_Registration operation, if the AMF does not have the terminal device's subscription data, the AMF uses Nudm_SDM_Get to retrieve access and mobility subscription data, the SMF selects subscription data, and the terminal device context data in the SMF.

[0092] In some implementations, the new AMF provides the UDM with the access type it serves for the terminal device and sets the access type to "3GPP Access". The UDM stores the access type associated with the serving AMF and does not delete the AMF identity associated with any other access type. The UDM can update the information stored in the UDR during AMF registration via Nudr_DM_Update.

[0093] In some implementations, when the UDM stores the access type (e.g., 3GPP) associated with the serving AMF, it will cause the UDM to initiate a Nudm_UECM_DeregistrationNotification to the old AMF (e.g., 3GPP access). The old AMF may then delete the terminal device context of the same access type. If the reason for removing the serving NF indicated by the UDM is initial registration, the communication protocol specifies that the old AMF calls the Nsmf_PDUSession_ReleaseSMContext (e.g., SM context ID) service operation to all relevant SMFs of the terminal device to notify the terminal device that it has deregistered the same access type from the old AMF. Upon receiving this notification, the SMF should release the PDU session.

[0094] In step S340, the AMF selects a PCF for the terminal device based on the terminal device context obtained from the old AMF or the PCF Selection Assistance information obtained from the UDM.

[0095] In step S350, the AMF performs AM policy association establishment / modification.

[0096] In step S360, if the registration request message carries a list of PDU sessions to be activated, the AMF sends a PDU session update SM context request (Nsmf_PDUSession_UpdateSMContext Request) to the corresponding SMF to activate the user plane connection of these PDU sessions. If the terminal device indicates that the PDU session has been released on the terminal device side or the terminal device has entered a region that does not support the slice associated with the PDU session, the AMF requests the SMF to release these PDU sessions.

[0097] In step S370, the AMF sends a registration acceptance message to the terminal device, which includes parameters such as the 5G-GUTI assigned to the terminal device by the network and the registration area.

[0098] Multiple access devices

[0099] In some implementations, devices that support multiple access technologies can be called multi-access devices or dual-access devices.

[0100] In some implementations, the difference between multi-access technology and dual connectivity technology lies in the fact that dual connectivity (DC) technology requires different access network devices to work together to exchange control information and user data. This is primarily controlled by the primary access network device's load signaling. In other words, in a DC scenario, there is only one non-access stratum (NAS) connection between the terminal device and the core network, and the secondary access network device is not perceived by the core network. For the terminal device in the DC, there is only one next-generation access protocol (NGAP) connection.

[0101] For multiple access technologies, the multiple access network devices accessed by the terminal device are all connected to the core network, and the mobility management network element has an NGAP connection for each of the multiple access network devices.

[0102] In addition, for multi-access technology, the control signaling corresponding to multiple access network devices is independent of each other.

[0103] In addition, for multi-access technologies, the collaborative work between multiple connections mainly occurs on the network side.

[0104] In some implementations, a multi-access device includes one or more of the following: a device that accesses multiple access networks; a device that registers with the core network through multiple access networks; a device that establishes connections with the core network through multiple access networks; and a device that has multiple NAS connections with mobility management network elements.

[0105] The following description, in conjunction with Figure 4, introduces the multi-access device applicable to the embodiments of this application. Referring to Figure 4, assuming the multi-access device is an MS, the MS may have one or more Universal Subscriber Identity Module (USIM) cards (e.g., USIM-1 and / or USIM-2 shown in Figure 4). That is to say, the multi-access device in the embodiments of this application can be a single-card terminal device.

[0106] In some implementations, the MS may include mobile equipment (ME), which can be understood as a mobile terminal without a USIM. The mobile terminal (MT) within the ME provides wireless transmission-related functions and / or provides physical connectivity to the network. Accordingly, the MT supports connecting various terminal equipment (TE) to the MT through terminal adaptation functions (TAF). The TE within the ME provides the user interface to implement end-to-end application functions.

[0107] In this application, the framework for multiple access devices is not limited. In some implementations, multiple access devices can deploy multiple MTs and one USIM, with different MTs supporting different protocol stacks, and each of the various protocol stacks corresponding to one NAS connection. In other implementations, multiple access devices can deploy one MT and one USIM, in which case one MT supports multiple different protocol stacks, and each of the various protocol stacks corresponding to one NAS connection.

[0108] As mentioned earlier, for a terminal device with a single USIM card, only one registration state (e.g., registered or deregistered) can be maintained for the same access type. However, this scheme of maintaining registration state based on access type may not be suitable for multi-access devices.

[0109] For example, for multi-access devices, there may be multiple connections between the multi-access device and the core network, and these connections may have the same access type. In this case, if the registration status is still maintained based on the access type, then when a multi-access device registers with the core network on one connection but not on another, it is impossible to determine whether the multi-access device's registration status on the core network side is registered or unregistered, which may lead to inconsistencies between the terminal device and the network device.

[0110] For example, for multi-access devices, there may be multiple connections between the device and the core network, and these connections may have the same access type. In this case, should the terminal device and the mobility management network element maintain a single registration state for all connections, or a separate registration state for each connection? Furthermore, if the multiple connections of a multi-access device correspond to different mobility management network elements, how should the registration state for all connections be maintained?

[0111] For example, in the case of multi-access devices, there may be multiple connections between the multi-access device and the core network, and these connections may have the same access type. In this case, when a terminal device deregisters for one of these connections, it may also deregister for the other connections.

[0112] For example, for multi-access devices, there may be multiple connections between the device and the core network, and these connections may have the same access type. In this case, when a terminal device initiates a mobility registration update, should the registration status be updated simultaneously for all multiple connections, or should the registration status be updated separately for each of the multiple connections?

[0113] Therefore, to address the aforementioned problems, this application provides a wireless communication method that introduces a registration state at the RAT (Registration Atlas) granularity. In other words, it allows for the maintenance of a registration state for each connection corresponding to multiple access devices. Compared to traditional solutions that maintain registration states based on access type, this simplifies the complexity of maintaining the registration states of multiple access devices in multi-access scenarios.

[0114] In some scenarios, registration status at the RAT level can be replaced by registration management based on RAT, or registration management based on a combination of network and RAT, or the terminal device can adjust the registration status of a certain RAT based on a first request.

[0115] For ease of understanding, the following section will first describe the RAT-based registration status in the embodiments of this application with reference to Figure 5. Terminal devices and network devices (e.g., mobility management network elements) can manage and maintain the registration status of each RAT type (or for each RAT) separately. Accordingly, a terminal device can register / deregister only for a specific RAT without affecting the registration status of other RATs on the terminal device.

[0116] Referring to Figure 5, assume that the terminal device corresponds to multiple RATs, including RAT-a and RAT-b. When the terminal device is in a deregistered state on RAT-a and in a registered state on RAT-b, the terminal device can initiate a registration request for RAT-a. After successful registration (e.g., receiving a registration acceptance message for RAT-a), the registration status for RAT-a maintained by the terminal device and the network device changes from deregistered to registered, while the registration status for RAT-b remains registered. Similarly, when the terminal device is in a deregistered state on RAT-a (e.g., receiving a registration rejection message for RAT-a) and in a registered state on RAT-b, the network device can initiate a deregistration request for RAT-b. After successful deregistration, the registration status for RAT-a maintained by the terminal device and the network device changes from registered to deregistered, while the registration status for RAT-b remains deregistered.

[0117] In some scenarios, when allocating RAs (Regional Areas) to terminal devices, mobility management network elements (MLEs) need to consider mobility patterns and permitted / unpermitted areas. In such cases, the permitted / unpermitted areas for a terminal device differ across different networks (e.g., PLMNs). If a traditional RA allocation method assigns an RA at the terminal device level, it means that connections across multiple networks corresponding to the terminal device would share a single RA. When the MLE takes the intersection of permitted areas across multiple networks as the RA, it might result in an empty RA. Therefore, this embodiment introduces RA allocation at the RAT (Regional Access Point) level, which helps avoid the problem of an empty RA leading to terminal device registration failure when connections across multiple networks share a single RA.

[0118] In other words, the mobility management network element can assign independent RAs to each of the multiple RATs of the terminal device. In the embodiments of this application, the RAs of each RAT in the multiple RATs can be the same or different.

[0119] In some implementations, if the RA of each RAT in multiple RATs can be the same, then a RAT-level service area restriction can be provided to indicate the allowed area and non-allowed area corresponding to each RAT.

[0120] In some implementations, after the terminal device initiates registration for the first RAT, the mobility management network element can assign the service area restriction corresponding to the first RAT to the terminal device based on the terminal device's subscription message and / or local configuration information.

[0121] The following is a schematic flowchart of a wireless communication method according to an embodiment of this application, with reference to FIG6. The method shown in FIG6 includes step S610.

[0122] In step S610, the terminal device sends a first request to the first core network element.

[0123] In some implementations, the first core network element can be a mobility management network element, such as the AMF mentioned earlier. Alternatively, it could be a mobile management (MM) network element in a future 6G system.

[0124] In some implementations, the terminal device sending a first request to the first core network element can be understood as the terminal device sending a first request to the first core network element through the access network device.

[0125] In some implementations, the terminal device is used to access the network through multiple RATs, including a first RAT, or in other words, the first RAT is one of the multiple RATs. In other implementations, the terminal device is the multi-access device described above.

[0126] In some implementations, the first request includes one or more of the following: a request to register a first RAT; a request to register an update of the first RAT; or a request to deregister the first RAT. These are described below in conjunction with Embodiments 1 to 3.

[0127] It should be noted that if the first request includes a request to register a first RAT, the terminal device may not have accessed the network through multiple RATs before sending the first request. If the first request includes a request to register or update a first RAT, the terminal device may have already accessed the network through the first RAT among multiple RATs before sending the first request. If the first request includes a request to deregister a first RAT, the terminal device may have already accessed the network through the first RAT among multiple RATs before sending the first request.

[0128] Example 1: The first request includes a request to register the first RAT. In this case, the first request can also be called a "registration request".

[0129] In some implementations, the first request includes one or more of the following: information indicating that the terminal device is a multi-access device; information indicating that the terminal device supports RAT-based registration; one or more RAT types; and information indicating that a target registration area is to be allocated to the terminal device.

[0130] Taking the first request including information for indicating that the terminal device is a multi-access device as an example, the information for indicating that the terminal device is a multi-access device can be understood as information for indicating that the terminal device has multi-access capabilities.

[0131] In some implementations, the above information can be used to determine whether a terminal device supports RAT-based registration. For example, assuming that multiple access devices are specified to support RAT-based registration, if the first core network element receives information indicating that the terminal device is a multiple access device, the first core network element can determine that the terminal device supports RAT-based registration.

[0132] For example, if the first request includes information indicating that the terminal device supports RAT-based registration, this information can be understood as indicating that the registration requested in the first request is based on RAT.

[0133] In some implementations, the information used to indicate that the terminal device supports RAT-based registration can be understood as the terminal device's capability information, for example, the capability information could be one of the UE MM Core Network Capabilities.

[0134] Taking the first request including one or more RAT types as an example, where the one or more RAT types include the RAT type of the first RAT. In some implementations, the one or more RAT types can be RATs supported by multiple access devices, or in other words, the one or more RAT types are the RAT types that the terminal device requests to register.

[0135] In some implementations, the one or more RAT types mentioned above can be RAT types supported by the access network device, which is an access network device that forwards the first request from the terminal device to the core network element. Alternatively, the one or more RAT types mentioned above can be the RAT corresponding to the cell or TA selected by the terminal device. Of course, in the embodiments of this application, the one or more RAT types mentioned above can be RAT types that the access network device does not support.

[0136] In some implementations, one or more RAT types can be housed in a list, which is also known as a "List of RAT types".

[0137] In this application embodiment, the RAT type is not limited. In some implementations, the RAT type can include two main categories of technologies: 3GPP and non-3GPP. 3GPP RATs mainly include one or more of the following: NTN-based RAT, TN-based RAT, LTE-based RAT, NR-based RAT, and 6G-based RAT. NR-based RATs can include LEO-based RAT and / or MEO-based RAT. Non-3GPP RATs can include one or more of the following: Wireless Fidelity (Wi-Fi), World Interoperability for Microwave Access (WiMAX), and Code Division Multiple Access (CDMA).

[0138] The first request includes information for instructing the request to allocate a target RA to the terminal device, wherein the target RA includes one or more TAIs corresponding to the first RAT. For example, the target RA may only contain one or more TAIs corresponding to the first RAT, or the target RA may be a dedicated RA for the first RAT, which helps to prevent the terminal device from switching to another RAT.

[0139] It should be noted that one or more TAIs corresponding to the first RAT can be replaced with one or more TAs corresponding to the first RAT. TA can be represented by TAI. Of course, in the embodiments of this application, TA can be represented by other identifiers.

[0140] In some implementations, if the target RA is a dedicated RA for the first RAT, then if the terminal device needs to use the first RAT to communicate with the network in an area outside the target RA, the terminal device can initiate a mobility registration update process to the network side.

[0141] It should be noted that the information carried in the first request is not limited in the embodiments of this application. For example, the first request may also carry one or more of the following: the identifier of the terminal device (e.g., SUCI, 5G-GUTI, or PEI), the registration type (e.g., initial registration), and security parameters.

[0142] In some implementations, the above method further includes: a first core network element sending a first response message to a terminal device in response to the first request. The first response message indicates whether the registration of the first RAT is rejected or accepted. In some scenarios, if the first response message indicates rejection of the first RAT's registration, it is also called a "registration rejection." In other scenarios, if the first response message indicates acceptance of the first RAT's registration, it is also called a "registration acceptance."

[0143] In some implementations, mobility management network elements can determine whether the network supports the terminal device's registration at the RAT granularity based on the terminal device's subscription message and / or local configuration information.

[0144] In some implementations, if the first response message is used to indicate that the registration of the first RAT is rejected, the reason for rejecting the registration of the first RAT is that RAT-based registration is not supported.

[0145] In some implementations, the aforementioned reason can be indicated by a cause value. For example, the cause value could be a 5G Mobility Management (5GMM) cause, which could occupy 8 bits. Of course, in the embodiments of this application, the cause value could be specifically introduced to indicate that RAT-based registration is not supported.

[0146] In the embodiments of this application, the cause values ​​corresponding to the above-mentioned reasons are not limited. In some implementations, the cause indicating that RAT-based registration is not supported can use values ​​not used in the traditional 5GMM cause values. For example, a 5GMM cause value of "01110000" is used to indicate that RAT-based registration is not supported. In other implementations, the cause indicating that RAT-based registration is not supported can reuse values ​​already used in the traditional 5GMM cause values, which helps to avoid increasing the number of bits in the cause value due to the introduction of new causes. For example, a 5GMM cause value of "00001100" is used to indicate that the location is in a non-tracking area; in this case, this cause value can be reused to indicate that RAT-based registration is not supported. As another example, a 5GMM cause value of "00011100" is used to indicate that the location is in a restricted service area; in this case, this cause value can be reused to indicate that RAT-based registration is not supported.

[0147] In some implementations, the first response message is used to indicate acceptance of registration for the first RAT. The first response message includes one or more of the following: one or more TAIs corresponding to the first RAT; mobility restriction information corresponding to the first RAT; and periodic registration timer corresponding to the first RAT.

[0148] In some implementations, one or more TAIs corresponding to the first RAT can be indicated by the RA of the first RAT, which may include one or more TAs. Of course, in the embodiments of this application, the first response message may also directly indicate the TAIs of one or more TAs. For example, the one or more TAs indicated by the above information may be one or more TAs specific to the first RAT. In some scenarios, the TAIs of one or more TAs specific to the first RAT may be carried in a list, which may be called a "RAT-specific TAI list".

[0149] In some implementations, the mobility restriction information corresponding to the first RAT is used to indicate the permitted and / or prohibited areas of the first RAT. Within the prohibited areas, terminal devices and networks are not allowed to initiate service requests and / or connection requests through the first RAT. Connection requests include one or more of the following: transmitting user plane data, control plane data, abnormal data reports, and SM signaling (excluding PSData Off state change reports), in order to obtain user services unrelated to mobility.

[0150] In some implementations, the periodic registration timer corresponding to the first RAT is used to indicate the duration for which the terminal device initiates a periodic registration request.

[0151] In some implementations, the mobility management network element can start a mobile reachable timer (MRT) based on the RAT granularity. Correspondingly, if the mobility management network element has not received a periodic registration request from the terminal device after the MRT expires, it starts an implicit deregistration timer based on the RAT granularity for the RAT corresponding to the terminal device. If the implicit deregistration timer expires, the mobility management network element switches the state of the terminal device from the registered state to the deregistered state.

[0152] In this embodiment of the application, the information carried by the first response message is not limited. For example, the first response message may also carry the identifier of the terminal device and / or the identifier information of the access network device.

[0153] For example, the first response message may not carry information indicating the RAT type. In this case, the first core network element can determine the RAT type selected by the terminal device by using the access device's identification information (Global RAN Node ID) and the TAI indicated by the access network device.

[0154] The RAT-based registration process in this application embodiment has been described above with reference to Embodiment 1. In some implementations, the terminal device can be a multi-access device supporting multiple RATs. In this case, the terminal device registers multiple RATs with a first core network element, as described below with reference to Figure 7. In other implementations, the terminal device can be a multi-access device supporting multiple RATs. In this case, the terminal device registers multiple RATs with multiple different first core network elements respectively, as described below with reference to Figure 8.

[0155] Example 2: The first request includes information for requesting registration and updating of the first RAT. In this case, the first request can also be referred to as a "registration and update request".

[0156] In some implementations, the first request carries one or more of the following: information indicating that the terminal device requests a registration update based on the RAT; or information indicating one or more RAT types to be registered for update.

[0157] For example, the first request carries information indicating that the terminal device requests a registration update based on RAT. In other words, the information indicates that the registration update requested by the first request is based on RAT.

[0158] Taking the first request carrying information indicating one or more RAT types to be registered for update as an example, in some implementations, one or more RAT types include the RAT type of the first RAT, where an introduction to RAT types can be found above.

[0159] In some implementations, the one or more RAT types to be registered and updated mentioned above can be RAT types already registered by the terminal device.

[0160] It should be noted that the first request may not carry information indicating one or more RAT types to be registered and updated, which helps reduce the overhead of transmitting the first request. In this case, the first core network element and the mobility management network element can determine the RAT type selected by the terminal device through the identification information (Global RAN Node ID) of the access device and the TA indicated by the access network device.

[0161] In this embodiment of the application, the information carried by the first request is not limited. For example, the first request may also carry information indicating one or more of the following: the identifier of the terminal device (e.g., SUCI or 5G-GUTI); the registration type (e.g., mobility registration update or periodic registration update); and security parameters.

[0162] In some implementations, the above method further includes: a first core network element sending a first response message to a terminal device in response to the first request. The first response message is used to indicate whether to reject or accept the registration update of the first RAT. In some scenarios, the first response message is also called a "registration update response message". The registration update response message is similar to the registration response message in Embodiment 1, as detailed in the above description.

[0163] The foregoing, in conjunction with Embodiments 1 and 2, described the interaction between the terminal device and the first core network element in the registration and registration update scenarios of this application. The following describes the subsequent processing scheme of the first core network element after receiving the first request. It should be understood that the scheme described below can be used in conjunction with Embodiments 1 and 2.

[0164] In some implementations, the above method further includes: in response to accepting the registration of the first RAT, the first core network element records the context associated with the first RAT in the UE context.

[0165] In some implementations, the context associated with the first RAT includes one or more of the following: information indicating the RAT type of the first RAT; information indicating the RM status of the first RAT; information indicating the registration area of ​​the first RAT; information indicating the TAI corresponding to the last access request initiated by the first RAT before sending the first request; information indicating the location of the terminal device; information indicating mobility restrictions associated with the first RAT; information indicating security information of the control plane associated with the first RAT; information indicating security information of the user plane associated with the first RAT; information indicating allowed NSSAI associated with the first RAT; and information indicating that the RAT associated with the PDU session of the terminal device is the first RAT.

[0166] For example, the context includes information indicating the RAT type of the first RAT, which can be found in the description above.

[0167] For example, if the context includes information indicating the RM status of the first RAT, the RM status indicated by the information may include a registered status and / or a deregistered status, as described above.

[0168] For example, the context may include information about the RA used to indicate the first RAT. The RA indicated by this information may include one or more TAIs, wherein the one or more TAIs may be specific to the first RAT, as can be described above.

[0169] For example, the context may include information indicating the TAI corresponding to the last access request initiated through the first RAT before the first request was sent. This information may include, for example, the TAI of the last time the terminal device initiated a registration request on the first RAT, where "last time" can be understood as the time before the transmission of the first request.

[0170] For example, if the context includes information indicating the location of the terminal device, this information may include, for instance, the TAI where the terminal device is located, and / or the cell identifier of the cell where the terminal device is located.

[0171] For example, if the context includes information indicating mobility restrictions associated with the first RAT, this information may be used to indicate one or more of the following: access type restriction information for the terminal device; forbidden area for the terminal device; service area restriction corresponding to the first RAT; core network type restriction corresponding to the first RAT.

[0172] In some implementations, the access type restriction information of the terminal device is used to indicate which RAT types cannot be used to access the network for the terminal device.

[0173] In some implementations, the prohibited zone of the terminal device (or the prohibition of the first RAT) can be understood as the terminal device being prohibited from initiating any communication with the network based on the first RAT within the prohibited zone.

[0174] In some implementations, the service area restriction associated with the first RAT is used to indicate the permitted and / or prohibited areas associated with the first RAT. For details regarding permitted and prohibited areas, please refer to the above text.

[0175] In some implementations, the core network type restriction corresponding to the first RAT is used to indicate the limitations of the first RAT under a specific core network type. For example, the core network type supporting the first RAT is a specific core network.

[0176] For example, if the context includes information indicating security information for the control plane associated with the first RAT, the security information indicated by this information can be understood as the security information used when transmitting control plane information through the first RAT.

[0177] For example, the context includes information indicating security information for the user plane associated with the first RAT. This security information can be understood as the security information used when transmitting user plane information through the first RAT.

[0178] Taking the context including information for indicating the allowed network slice selection assistance information (NSSAI) for the first RAT association as an example, the allowed NSSAI can be understood as the NSSAI that allows service within the PLMN of the RA of the first RAT association, where the NSSAI may include one or more single network slice selection assistance information (S-NSSAI).

[0179] For example, if the context includes information indicating that the RAT associated with the PDU session of the terminal device is the first RAT, this information can be replaced with the RAT type indicating that the RAT type associated with the PDU session of the terminal device is the first RAT.

[0180] It should be noted that the embodiments of this application do not limit the information in the context. For example, the context may also include other information as shown in Table 1 below.

[0181] In some implementations, the first core network element can instruct the second core network element to register one or more RATs or to update the registration of one or more RATs requested by the terminal device. The second core network element can be, for example, a UDM. That is, the method further includes: in response to accepting the registration of the first RAT, the first core network element sends first information to the second core network element, the first information indicating one or more RATs for which the first core network element provides services to the terminal device, wherein the one or more RATs include the first RAT.

[0182] In some implementations, the first core network element can provide services such as registration management and / or mobility management for the first RAT of the terminal equipment.

[0183] In some implementations, the first core network element may store the context associated with multiple RATs of the terminal device. In this case, if the core network element that provides services to the first RAT among the multiple RATs is the third core network element, the third core network element may request to obtain the context associated with the first RAT from the first core network element. The context associated with the first RAT can be found in the above description.

[0184] In other words, the above method also includes: upon accepting the registration of the first RAT, the first core network element receives a second request sent by the third core network element, the second request being used to request the context associated with the first RAT. In some implementations, the third core network element can be the AMF described above, or the MM in a 6G network.

[0185] In some implementations, the third core network element can determine the first core network element based on the 5G-GUTI of the terminal device, since some information in the 5G-GUTI is determined based on the identifier of the first core network element.

[0186] In some implementations, the above method further includes: the first core network element sending a response message to the third core network element in response to the second request, the response message carrying the context associated with the first RAT.

[0187] Example 3: The first request includes information for requesting to register a first RAT. In this case, the first request can also be called a "registration request".

[0188] In some implementations, the first request carries one or more of the following: information indicating that the terminal device requests deregistration based on the RAT; and information indicating one or more RAT types to be deregistered, wherein the one or more RAT types include the RAT type of the first RAT.

[0189] For example, the first request carries information indicating that the terminal device requests deregistration based on RAT, or in other words, the information indicates that the deregistration requested by the first request is based on RAT.

[0190] Taking the first request carrying information indicating one or more RAT types to be registered as an example, in some implementations, one or more RAT types include the RAT type of the first RAT, where an introduction to RAT types can be found above.

[0191] In some implementations, the one or more RAT types to be deregistered mentioned above can be RAT types that have already been registered by the terminal device.

[0192] In this embodiment of the application, the information carried by the first request is not limited. For example, the first request may also carry information indicating one or more of the following: the identifier of the terminal device (e.g., GUTI); the deregistration type (e.g., power off or deregister a certain RAT type).

[0193] In some implementations, multiple RATs include a second RAT, and the first request is used to request to register the first RAT. Step S610 includes: the terminal device sending the first request to the first core network element through the second RAT.

[0194] For ease of understanding, the registration management scheme at the RAT granularity in the embodiments of this application is described below with reference to Figures 7 to 10. Figure 7 shows the registration management scheme in which a terminal device, as a multi-access device, can register multiple RATs with a mobility management network element. The method shown in Figure 7 includes steps S710 to S720.

[0195] In step S710, the terminal device sends a first request to the mobility management network element.

[0196] In some implementations, when the terminal device supports RAT-based registration, or in other words, the terminal device supports RAT-granular registration, or in other words, the terminal device supports separate registration management for a certain RAT type, or in other words, the terminal device wants to enable RAT-based registration, the terminal device sends a first request to the mobility management network element.

[0197] In some implementations, the first request includes one or more of the following: information indicating that the terminal device is a multi-access device; information indicating that the terminal device supports RAT-based registration; one or more RAT types; and information indicating a request to allocate a target registration region to the terminal device. See above for related information.

[0198] In step S720, the mobility management network element sends a first response message to the terminal device in response to the first request.

[0199] In some implementations, mobility management network elements can determine whether the network supports registration at the RAT granularity based on the terminal device's subscription message and / or local configuration information.

[0200] In some implementations, if registration at the RAT granularity is not supported, the registration request of the terminal device is rejected, and the reason for rejecting the registration request is carried in the registration rejection message (as an example of the first response message) because registration at the RAT granularity is not supported. Alternatively, the network may not reject the registration request of the terminal device and register the terminal device according to the normal registration process.

[0201] In some implementations, if registration at the RAT level is supported, the mobility management network element can determine the RAT type currently registered by the terminal device from the RAT type carried by the terminal device in the NAS message (registration request message), or it can determine the RAT type selected by the terminal device through the identification information of the access device and the TAI indicated by the access network device.

[0202] In some implementations, mobility management network elements can instruct terminal devices to support registration at the RAT granularity in the locally stored terminal device context, and if the terminal device registration is accepted, include the RAT type that the terminal device has already registered in the terminal device context.

[0203] In some implementations, the first response message is used to indicate acceptance of registration for the first RAT (e.g., it can be a registration acceptance message). The first response message includes one or more of the following: one or more TAIs corresponding to the first RAT; mobility restriction information corresponding to the first RAT; and a periodic registration timer corresponding to the first RAT. For related information, please refer to the above.

[0204] Figure 8 illustrates the registration management scheme in which a terminal device, acting as a multi-access device, can register multiple RATs with multiple mobility management network elements through multiple registration processes. These multiple RATs include RAT-A and TAT-B. The method shown in Figure 8 includes steps S810 to S880.

[0205] In step S810, the terminal device sends Request 1 to Mobility Management Network Element 1, which requests to register RAT-A with the network.

[0206] In some implementations, request 1 includes one or more of the following: information indicating that the terminal device is a multi-access device; information indicating that the terminal device supports RAT-based registration; RAT type of RAT-A; information indicating that a target registration area is requested for the terminal device. For related information, please refer to the above text.

[0207] In some implementations, the terminal device sends AN parameters and request 1 to the mobility management network element 1 through the access network device 1. Accordingly, the access network device 1 can select the mobility management network element 1 based on the AN parameters.

[0208] In step S820, if the request 1 from the terminal device is accepted, the mobility management network element 1 updates the locally stored context of the terminal device.

[0209] In some implementations, mobility management element 1 determines whether the network supports registration at the RAT granularity based on the terminal device's subscription message and / or local configuration information, and determines that the RAT type corresponding to the registration is RAT-A. If RAT-A registration is accepted, mobility management element 1 creates or updates the stored terminal device context (also known as UE context).

[0210] In some implementations, the terminal device context related to RAT registration stored on the mobility management network element 1 is detailed in Table 1, which shows the entries for each RAT type level context within the UE access and mobility context.

[0211] In some implementations, the above entries include one or more of the following: information indicating the RAT type of the first RAT; information indicating the RM status of the first RAT; information indicating the registration area of ​​the first RAT; information indicating the TAI corresponding to the last access request initiated by the first RAT before sending the first request; information indicating the location of the terminal device; information indicating the mobility restrictions associated with the first RAT; information indicating the security information of the control plane associated with the first RAT; information indicating the security information of the user plane associated with the first RAT; information indicating the allowed NSSAI associated with the first RAT; and information indicating that the RAT associated with the PDU session of the terminal device is the first RAT.

[0212] Table 1 Note 1: During PDU session establishment, the AMF passes the PCF ID to the SMF. The SMF can select the PCF identified by the PCF ID. In HR roaming, the AMF transmits the identifier of the H-PCF. In LBO roaming, the AMF transmits the identifier of the V-PCF. Note 2: In non-roaming situations, the PCF ID in the AM policy association information must be the same as the PCF ID in the UE policy association information. In roaming situations, the V-PCF ID in the AM policy association information and the V-PCF ID in the UE policy association information must be the same. Note 3: During AMF migration, not all parameters stored in the AMF need to be transferred between AMFs. The parameters that need to be transferred between AMFs are defined in TS29.518

[0018] . Note 4: Validity information is not provided to the NG-RAN. The AMF shall, in accordance with the description in Clause 5.30.3 of TS23.501[2], consider the validity information related to the CAG identifier and determine the CAG identifiers to be provided to the NG-RAN in the list of allowed CAGs.

[0213] In step S830, Mobility Management Element 1 sends Information 1 to UDM. Information 1 includes the successfully registered RAT type and / or the corresponding service mobility management element of the RAT type: Mobility Management Element 1, so that UDM can include it in the UE context it maintains.

[0214] In some implementations, Mobility Management Element 1 invokes the Registration Service Operation (represented as Nudm_UECM_Registration service operation) and carries one or more of the following parameters: NF ID (Mobility Management Element 1 ID); SUPI; NF type: Mobility Management Element; Access type (3GPP access or non-3GPP access); Registration type; RAT type (RAT-A).

[0215] In some implementations, if authorization is successful, the UE context related to the serving mobility management network element stored in the UE context on the UDM includes one or more of the following information: terminal device identifier (e.g., SUPI); identifier of the serving mobility management network element (e.g., GUTI and / or GUAMI); and a list of RAT types indicating that the terminal device is registered with one or more RAT types on this mobility management network element 1.

[0216] It should be noted that the context of the terminal device differs from that of a traditional terminal device in that, in the context of the terminal device in this embodiment, one terminal device can have multiple Serving Mobility Management Network Elements (SMNs), and these multiple SMNs can correspond to multiple RAT types. Furthermore, multiple RAT types can also be registered on each SMN.

[0217] In step S840, the mobility management network element 1 sends a registration acceptance message to the terminal device. The registration acceptance message includes the GUTI, the registration area (containing a list of RAT-specific TAIs consisting of tracking areas corresponding to the same type of RAT-A), the mobility restrictions of the RAT-A, the periodic update timer of the RAT-A, etc. For related information, please refer to the above text.

[0218] In step S850, the terminal device sends request 2 to mobility management network element 2, which is used to request to register RAT-B with the network.

[0219] In some implementations, after a terminal device successfully registers with the network on RAT-A, it may re-initiate a registration request on RAT-B. In this case, the terminal device sends an AN message to the access network device 2 corresponding to RAT-B, containing AN parameters and a registration request. Access network device 2 can select Mobility Management Element 2 based on the AN parameters. Mobility Management Element 2 and Mobility Management Element 1 can be the same element, or they can be different elements.

[0220] In some implementations, request 2 includes one or more of the following: information indicating that the terminal device is a multi-access device; information indicating that the terminal device supports RAT-based registration; RAT type of RAT-B; information indicating that a target registration area is requested for the terminal device. For related information, please refer to the above text.

[0221] In step S860, if the request 2 from the terminal device is accepted, the mobility management network element 2 updates the locally stored context of the terminal device.

[0222] In some implementations, mobility management element 2 determines whether the network supports registration at the RAT granularity based on the UE's subscription message and / or local configuration information, and determines that the RAT type corresponding to the registration is RAT-B. If RAT-B registration is accepted, mobility management element 2 creates or updates the stored UE context.

[0223] In some implementations, Mobility Management Element 2 creates or updates the RAT-B context in the local UE context. If Mobility Management Element 2 determines Mobility Management Element 1 based on the 5G-GUTI provided by the terminal device, Mobility Management Element 2 can obtain the terminal device context from Mobility Management Element 1, for example, only obtaining the RAT-B context from Mobility Management Element 1.

[0224] In step S870, the mobility management network element 2 sends information 2 to the UDM, which includes the successfully registered RAT type and / or the corresponding service mobility management network element: mobility management network element 2, so that the UDM can include it in the UE context it maintains.

[0225] In some implementations, Mobility Management Element 2 calls the Registration Service Operation (represented as Nudm_UECM_Registration service operation) and carries one or more of the following parameters: NF ID (Mobility Management Element 1 ID); SUPI; NF type: Mobility Management Element; Access type (3GPP access or non-3GPP access); Registration type; RAT type (RAT-B).

[0226] In some implementations, if authorization is successful, the UE context related to the serving mobility management network element stored in the UE context on the UDM includes one or more of the following information: terminal device identifier (e.g., SUPI); identifier of the serving mobility management network element (e.g., GUTI and / or GUAMI of mobility management network element 1 corresponding to RAT-A; GUTI and / or GUAMI of mobility management network element 2 corresponding to RAT-B); and a list of RAT types (e.g., RAT-A and RAT-B).

[0227] It should be noted that if RAT-A is the same as RAT-B, then UDM updates the UE context and cancels the registration of Mobility Management Element 1.

[0228] In step S880, the mobility management network element 2 sends a registration acceptance message to the terminal device. The registration acceptance message includes the GUTI, the registration area (containing a list of RAT-specific TAIs consisting of tracking areas corresponding to the same type of RAT-B), the mobility restrictions of the RAT-B, the periodic update timer of the RAT-B, etc. For related information, please refer to the above text.

[0229] Figure 9 illustrates the registration management scheme, where a terminal device, acting as a multi-access device, can register and update an already registered RAT-A. Assume the terminal device, acting as a multi-access device, corresponds to RATs A and B. The method shown in Figure 9 includes steps S910 to S950.

[0230] In step S910, the terminal device can initiate a registration request to the network through the access network device corresponding to RAT-A.

[0231] In some implementations, when the periodic registration update timer of the terminal device expires, or when the terminal device leaves the registration area corresponding to a certain RAT-A but still communicates with the network on this RAT-A, the terminal device can initiate a registration request to the network again through the access network device corresponding to the RAT-A.

[0232] In some implementations, the registration request message includes the following parameters: identification information of the terminal device (e.g., SUCI or 5G-GUTI); registration type (e.g., mobility registration update or periodic registration update); security parameters; instruction information to instruct the terminal device to perform a RAT-based registration update; and one or more RAT types to be registered and updated (including RAT-A).

[0233] It should be noted that the registration request message may not contain the RAT type to be registered and updated. In this case, the mobility management network element can determine the corresponding RAT type based on the identification information of the access network device that sent the N2 message and the tracking area it indicated.

[0234] In step S920, mobility management element 1 obtains the UE context corresponding to RAT-A from mobility management element 2.

[0235] In some implementations, Mobility Management Element 1 can determine via GUTI that the terminal device has previously registered with Mobility Management Element 2, and then request UE context corresponding to RAT-A from Mobility Management Element 12. Mobility Management Element 1 creates / updates its local UE context and adds the UE context corresponding to RAT-A to its local UE context.

[0236] It should be noted that if the GUTI indicates that the mobility management network element is mobility management network element 1, then steps S920 and S940 can be skipped.

[0237] In step S930, mobility management element 1 registers RAT-A with UDM.

[0238] In some implementations, Mobility Management Element 1 invokes the Registration Service Operation (represented as Nudm_UECM_Registration service operation) and carries one or more of the following parameters: NF ID (Mobility Management Element 1 ID); SUPI; NF type: Mobility Management Element; Access type (3GPP access or non-3GPP access); Registration type; RAT type (RAT-A).

[0239] In some implementations, the service mobility management element corresponding to RAT-A is added to the UE context on the UDM as mobility management element 1.

[0240] In step S940, if the service mobility management network element associated with RAT-A in the UE context in the UDM is mobility management network element 2, then mobility management network element 2 needs to be updated to mobility management network element 1, and a notification message is sent to mobility management network element 2 to notify it to remove the context corresponding to RAT-A of the terminal device on mobility management network element 2.

[0241] In some implementations, the notification message may be represented as "Nudm_UECM_DeregistrationNotification". This notification message contains the following parameters: SUPI; access type; Serving Mobility Management Element ID; RAT type;

[0242] In step S950, the mobility management network element 1 sends a registration acceptance message to the terminal device. The registration acceptance message includes the GUTI, the registration area (containing a list of RAT-specific TAIs consisting of tracking areas corresponding to the same type of RAT-A), the mobility restrictions of the RAT-A, the periodic update timer of the RAT-A, etc. For related information, please refer to the above text.

[0243] Figure 10 illustrates the registration management scheme, where a terminal device, acting as a multi-access device, can deregister an already registered RAT-A. Assume the terminal device, acting as a multi-access device, corresponds to RATs A and B. The method shown in Figure 10 includes steps S1010 to S1020.

[0244] In step S1010, the terminal device sends Request 1 (also known as Deregistration Request) to Mobility Management Network Element 1 to request deregistration with RAT-A.

[0245] In some implementations, request 1 carries one or more of the following: GUTI, which is the identification information assigned to the terminal device by the mobility management network element in the registration acceptance message; deregistration type (e.g., power off, or deregistering a certain RAT type); information indicating that the terminal device requests deregistration based on RAT; and one or more RAT types (including RAT-A) to be deregistered, wherein the one or more RAT types include the RAT type of the first RAT.

[0246] It should be noted that the terminal device can indicate whether it is performing RAT deregistration by specifying the deregistration type, or it can indicate RAT deregistration by using a separate indication message. Of course, in this embodiment, the RAT type can also be directly included in request 1 to indicate that the current deregistration request is based on RAT.

[0247] It should be noted that the registration request may not include the RAT type. Instead, the registration request may be sent through the access network device corresponding to a certain RAT type. In this case, the mobility management network element can determine the RAT type that the terminal device needs to register through the access network device identifier and its indicated TAI.

[0248] In step S1020, the mobility management network element 1 sends a response message to the terminal device in response to request 1 (also known as deregistration request) to indicate whether to accept or refuse to register with RAT-A.

[0249] In some implementations, the MM updates the locally maintained registration status of the terminal device on the RAT-A to deregister.

[0250] In some implementations, if the MM finds that the GUTI indicates another mobility management element, then mobility management element 1 notifies the other mobility management element to register the RAT-A corresponding to the terminal device.

[0251] In some implementations, if the RAT-A to be deregistered indicated in Request 1 does not have a corresponding UE context on Mobility Management Element 1, then Mobility Management Element 1 needs to find the service Mobility Management Element that manages this RAT type context through UDM, or request UDM to initiate deregistration of the terminal device on RAT-A.

[0252] The above section, in conjunction with Embodiment 3, described the scheme for a terminal device to request RAT-based deregistration in this application. In other implementations, the RAT-based deregistration scheme can also be triggered by a second core network element. This will be described below in conjunction with Embodiment 4.

[0253] In some implementations, the second core network element sends a third request to the first core network element. The third request is used to request the registration of the first RAT of the terminal device.

[0254] In some implementations, the third request carries one or more of the following: information indicating the RAT type of the first RAT; information indicating the reason for registering the first RAT. Of course, in the embodiments of this application, the third request may also carry a terminal device identifier.

[0255] In this embodiment, the reasons described above are not limited. For example, the reasons may include the absence of an S-NSSAI that supports the first RAT among the allowed NSSAIs. Another example is that the PLMN registered to the terminal device does not allow the terminal device to use the first RAT at its current location.

[0256] In some implementations, the above method also includes: the first core network element sending a third request to the terminal device.

[0257] In some implementations, the above method also includes: the first core network element deleting the context associated with the first RAT, wherein the context associated with the first RAT can be found in the above description.

[0258] For ease of understanding, the deregistration scheme triggered by the second core network element in this application embodiment is described below with reference to Figure 11. Assume the second core network element is a UDM, and the RAT corresponding to the terminal device as a multi-access device includes RAT-A and RAT-B. The method shown in Figure 11 includes steps S1110 to S1140.

[0259] In step S1110, UDM sends Request 1 (also known as Deregistration Request) to Mobility Management Network Element 1 to request deregistration with RAT-A.

[0260] In some implementations, the mobility management element 1 may initiate a network-initiated deregistration procedure for explicit reasons (e.g., through operational and maintenance interventions, or if the mobility management element determines that S-NSSAI cannot be provided in the terminal device's allowed NSSAI, or the PLMN to which the terminal device is registered does not allow operation at the current terminal device location, or the disaster conditions are no longer applicable), to trigger the terminal device to return to the PLMN that previously had the disaster conditions.

[0261] In other implementations, the deregistration process is initiated for implicit reasons (e.g., the implicit RAT deregistration timer expires). For example, the UDM may trigger this process for operator-determined purposes (e.g., disaster recovery conditions are no longer applicable) to request the deletion of the terminal device's RAT registration management context and PDU session.

[0262] In some implementations, request 1 includes the following parameters: the identification information of the terminal device; the type of RAT to be registered (RAT-A); and the reason for registration (e.g., the terminal device requests registration on this RAT-A through another mobility management network element, and the operator determines that it will not provide services to the terminal device on the RAT-A).

[0263] In some implementations, UDM can select the mobility management network element to register notifications based on the serving mobility management network element of the terminal device corresponding to RAT-A in the terminal device context.

[0264] In step S1120, the mobility management network element 1 deletes the context corresponding to RAT-A in the UE context. The context corresponding to RAT-A can be found in Table 1.

[0265] In step S1130, the mobility management network element 1 sends a deregistration request message to the terminal device. The deregistration request message contains the following parameters: one or more RAT types (including RAT-A) indicating deregistration; and the reason for deregistration (e.g., there is no S-NSSAI that supports the RAT type among the allowed NSSAIs, or the PLMN to which the terminal device is registered does not allow the terminal device to use RAT-A at the current location).

[0266] In step S1140, the terminal device sends a response message to the mobility management network element 1, which is a request to register.

[0267] It should be noted that during the deregistration process described above in conjunction with Figures 10 and 11, the deregistration request can be transmitted via RAT-B. For example, when the terminal device moves out of the RA allocated by RAT-A, and the signal strength of the connection corresponding to RAT-B in the current area is high (e.g., high RSRP and / or SINR), and there are sufficient available radio resources, the terminal device can send a deregistration request for RAT-A over the RAT-B connection. For example, in the scheme shown in Figure 10, the registration request message carries RAT-A and / or RAT-based registration management indication information, indicating that the current deregistration request is a RAT-based deregistration request, and the RAT type for deregistration is RAT-A. If the mobility management network element 1 that receives this deregistration request has a terminal device context related to RAT-A for this terminal device, the corresponding part of RAT-A is deleted, and the UDM is notified to register the terminal device regarding the RAT-A registration information. If the terminal device context on the UDM indicates that the serving mobility management network element corresponding to RAT-A is mobility management network element 2, then the UE context of the terminal device regarding RAT-A on mobility management network element 2 is registered according to the scheme shown in Figure 11.

[0268] The method embodiments of this application have been described in detail above with reference to Figures 1 to 11. The apparatus embodiments of this application will be described in detail below with reference to Figures 12 to 17. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be referred to the preceding method embodiments.

[0269] Figure 12 is a schematic diagram of a terminal device according to an embodiment of this application. The terminal device 1200 shown in Figure 12 includes: a transmitting unit 1210.

[0270] The sending unit 1210 is used to send a first request to a first core network element. The terminal device is used to access the network through multiple radio access technologies (RATs), including a first RAT. The first request includes one or more of the following: a request to register the first RAT; a request to register and update the first RAT; or a request to unregister the first RAT.

[0271] In some implementations, the first request includes a request to register the first RAT, the first request including one or more of the following: information indicating that the terminal device is a multi-access device; information indicating that the terminal device supports RAT-based registration; one or more RAT types, the one or more RAT types including the RAT type of the first RAT; information indicating a request to allocate a target registration region to the terminal device, the target registration region including one or more TAIs corresponding to the first RAT.

[0272] In some implementations, the target registration region includes only one or more TAIs corresponding to the first RAT.

[0273] In some implementations, the first request includes a request to register the first RAT, and the terminal device further includes: a first receiving unit, configured to receive a first response message sent by the first core network element in response to the first request, the first response message being used to indicate rejection or acceptance of the registration of the first RAT.

[0274] In some implementations, the first response message is used to indicate that the registration of the first RAT is rejected, and / or the first response message is used to indicate that the reason for rejecting the registration of the first RAT is that RAT-based registration is not supported.

[0275] In some implementations, the first response message is used to indicate acceptance of the registration of the first RAT, and the first response message includes one or more of the following: one or more TAIs corresponding to the first RAT; mobility restriction information corresponding to the first RAT; and periodic registration timer corresponding to the first RAT.

[0276] In some implementations, the first request includes a request to request registration and update of the first RAT, the first request carrying one or more of the following: information indicating that the terminal device requests registration and update based on the RAT; and information indicating one or more RAT types to be registered and updated, the one or more RAT types including the RAT type of the first RAT.

[0277] In some implementations, the first request includes a request to request deregister the first RAT, the first request carrying one or more of the following: information indicating that the terminal device requests deregistration based on the RAT; and information indicating one or more RAT types to be deregistered, the one or more RAT types including the RAT type of the first RAT.

[0278] In some implementations, the multiple RATs include a second RAT, and the first request is used to request to register the first RAT. The sending unit is further used to send the first request to the first core network element through the second RAT.

[0279] Figure 13 is a schematic diagram of a network device according to an embodiment of this application. The network device 1300 shown in Figure 13 is a first core network element, and the network device 1300 includes a receiving unit 1310.

[0280] The receiving unit 1310 is configured to receive a first request sent by a terminal device, the terminal device being configured to access the network via a variety of wireless access technologies (RATs), the variety of RATs including a first RAT, and the first request including one or more of the following: a request to register the first RAT; a request to register and update the first RAT; or a request to unregister the first RAT.

[0281] In some implementations, the first request includes a request to register the first RAT, the first request including one or more of the following: information indicating that the terminal device is a multi-access device; information indicating that the terminal device supports RAT-based registration; one or more RAT types, the one or more RAT types including the RAT type of the first RAT; information indicating a request to allocate a target registration region to the terminal device, the target registration region including one or more TAIs corresponding to the first RAT.

[0282] In some implementations, the first request includes a request to register the first RAT, and the network device further includes: a first sending unit, configured to send a first response message to the terminal device in response to the first request, the first response message indicating whether to reject or accept the registration of the first RAT.

[0283] In some implementations, the first response message is used to indicate that the registration of the first RAT is rejected, and / or the first response message is used to indicate that the reason for rejecting the registration of the first RAT is that RAT-based registration is not supported.

[0284] In some implementations, the first response message is used to indicate acceptance of the registration of the first RAT, and the first response message includes one or more of the following: one or more TAIs corresponding to the first RAT; mobility restriction information corresponding to the first RAT; and periodic registration timer corresponding to the first RAT.

[0285] In some implementations, the first request includes a request to request registration and update of the first RAT, the first request carrying one or more of the following: information indicating that the terminal device requests registration and update based on the RAT; and information indicating one or more RAT types to be registered and updated, the one or more RAT types including the RAT type of the first RAT.

[0286] In some implementations, the first request includes a request to register or register an update of the first RAT, and the network device further includes: in response to accepting the registration of the first RAT, a processing unit for recording the context associated with the first RAT in the UE context.

[0287] In some implementations, the context associated with the first RAT includes one or more of the following: information indicating the RAT type of the first RAT; information indicating the RM status of the first RAT; information indicating the registration area of ​​the first RAT; information indicating the TAI corresponding to the last access request initiated by the first RAT before sending the first request; information indicating the location of the terminal device; information indicating mobility restrictions associated with the first RAT; security information of the control plane associated with the first RAT; security information of the user plane associated with the first RAT; an allowed NSSAI associated with the first RAT; and information indicating that the RAT associated with the PDU session of the terminal device is the first RAT.

[0288] In some implementations, the information used to indicate the mobility restrictions associated with the first RAT includes one or more of the following: access type restriction information of the terminal device; prohibited area information of the terminal device; service area restriction information associated with the first RAT; and core network type restriction information associated with the first RAT.

[0289] In some implementations, the first request includes a request to register or register an update of the first RAT. The network device further includes: in response to accepting the registration of the first RAT, a second sending unit for sending first information to a second core network element, the first information being used to instruct the first core network element to provide services to one or more RATs for the terminal device, the one or more RATs including the first RAT.

[0290] In some implementations, the first request includes a request to register or register an update of the first RAT, and the receiving unit is configured to: if the registration of the first RAT is accepted, receive a second request sent by a third core network element, the second request being used to request to obtain the context associated with the first RAT, the third core network element being used to provide services to the first RAT.

[0291] In some implementations, the network device further includes a third sending unit, configured to send a response message to the third core network element in response to the second request, the response message carrying the context associated with the first RAT.

[0292] In some implementations, the first request includes a request to request deregister the first RAT, the first request carrying one or more of the following: information indicating that the terminal device requests deregistration based on the RAT; and information indicating one or more RAT types to be deregistered, the one or more RAT types including the RAT type of the first RAT.

[0293] In some implementations, the multiple RATs include a second RAT, and the first request is used to request to register the first RAT. The receiving unit is used to receive the first request sent by the terminal device through the second RAT.

[0294] In some implementations, the RAT type of the first RAT is determined based on one or more of the following: the RAT type of the first RAT indicated in the first request; the identification information of the access network device that sent the first request; and the TAI associated with the access network device.

[0295] Figure 14 is a schematic diagram of a terminal device according to an embodiment of this application. The terminal device 1400 shown in Figure 14 includes a receiving unit 1410.

[0296] The receiving unit 1410 is used to receive a third request sent by the first core network element, the third request being used to request to register the first RAT of the terminal device.

[0297] In some implementations, the third request carries one or more of the following: information indicating the RAT type of the first RAT; information indicating the reason for registering the first RAT.

[0298] Figure 15 is a schematic diagram of a network device according to an embodiment of this application. The network device 1500 shown in Figure 15 is a first core network element, and the network device 1500 includes: a receiving unit 1510.

[0299] The receiving unit 1510 is used to receive a third request sent by the second core network element, the third request being used to request to register the first RAT of the terminal device.

[0300] In some implementations, the third request carries one or more of the following: information indicating the RAT type of the first RAT; information indicating the reason for registering the first RAT.

[0301] In some implementations, the network device further includes a sending unit for sending the third request to the terminal device.

[0302] In some implementations, the network device further includes a processing unit for deleting the context associated with the first RAT.

[0303] Figure 16 is a schematic diagram of a network device according to an embodiment of this application. The network device 1600 shown in Figure 16 is a second core network element, and the network device 1600 includes: a transmitting unit 1610.

[0304] The sending unit 1610 is used to send a third request to the first core network element, the third request being used to request the first RAT of the terminal device to be registered.

[0305] In some implementations, the third request carries one or more of the following: information indicating the RAT type of the first RAT; information indicating the reason for registering the first RAT.

[0306] Figure 17 is a schematic structural diagram of a communication device according to an embodiment of this application. The dashed lines in Figure 17 indicate that the unit or module is optional. This device 1700 can be used to implement the methods described in the above method embodiments. Device 1700 can be a chip, a terminal device, or a network device.

[0307] Apparatus 1700 may include one or more processors 1710. The processor 1710 may support apparatus 1700 in implementing the methods described in the preceding method embodiments. The processor 1710 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0308] The apparatus 1700 may further include one or more memories 1720. The memories 1720 store a program that can be executed by the processor 1710, causing the processor 1710 to perform the methods described in the preceding method embodiments. The memories 1720 may be independent of the processor 1710 or integrated within the processor 1710.

[0309] The device 1700 may also include a transceiver 1730. The processor 1710 can communicate with other devices or chips via the transceiver 1730. For example, the processor 1710 can send and receive data with other devices or chips via the transceiver 1730.

[0310] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to a terminal or network device provided in this application, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0311] This application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to a terminal or network device provided in this application embodiment, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0312] This application also provides a computer program. This computer program can be applied to the terminal or network device provided in this application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0313] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0314] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0315] In the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0316] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship such as instruction and being instructed, configuration and being configured.

[0317] In this application embodiment, "predefined" or "preconfigured" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0318] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0319] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0320] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0321] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0322] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0323] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0324] 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 read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0325] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of wireless communication, comprising: include: The terminal device sends a first request to a first core network element. The terminal device is configured to access the network via multiple Radio Access Technologies (RATs), including a first RAT. The first request includes one or more of the following: A request used to request registration of the first RAT; A request used to request registration and update of the first RAT; This is used to request the registration of the first RAT.

2. The method of claim 1, wherein, The first request includes a request to register the first RAT, and the first request includes one or more of the following: Information used to indicate that the terminal device is a multi-access device; Information used to indicate that the terminal device supports RAT-based registration; One or more RAT types, wherein the one or more RAT types include the RAT type of the first RAT; Information used to indicate a request to allocate a target registration region to the terminal device, the target registration region including one or more Tracking Region Identifiers (TAIs) corresponding to the first RAT.

3. The method of claim 2, wherein, The target registration region includes only one or more TAIs corresponding to the first RAT.

4. The method of any one of claims 1-3, wherein, The first request includes a request to register the first RAT, and the method further includes: The terminal device receives a first response message from the first core network element in response to the first request. The first response message is used to indicate whether to reject or accept the registration of the first RAT.

5. The method of claim 4, wherein, The first response message is used to indicate that the registration of the first RAT is rejected, and / or the first response message is used to indicate that the reason for rejecting the registration of the first RAT is that RAT-based registration is not supported.

6. The method of claim 4, wherein, The first response message is used to indicate acceptance of the registration of the first RAT, and the first response message includes one or more of the following: One or more TAIs corresponding to the first RAT; Mobility restriction information corresponding to the first RAT; The periodic registration timer corresponding to the first RAT.

7. The method of claim 1, wherein, The first request includes a request to request registration and update of the first RAT, and the first request carries one or more of the following: Information used to instruct the terminal device to request a registration update based on RAT; This is used to indicate one or more RAT types to be registered for update, the one or more RAT types including the RAT type of the first RAT.

8. The method of claim 1, wherein, The first request includes a request to register the first RAT, and the first request carries one or more of the following: Used to instruct the terminal device to request information for deregistration based on RAT; Used to indicate one or more RAT types to be registered, the one or more RAT types including the RAT type of the first RAT.

9. The method of claim 1, wherein, The multiple RATs include a second RAT, and the first request is used to request to register the first RAT. The terminal device sends the first request to the first core network element, including: The terminal device sends the first request to the first core network element through the second RAT.

10. A method of wireless communication, comprising: include: A first core network element receives a first request sent by a terminal device, the terminal device being used to access the network via a variety of radio access technologies (RATs), the variety of RATs including a first RAT, and the first request including one or more of the following: A request used to request registration of the first RAT; A request used to request registration and update of the first RAT; This is used to request the registration of the first RAT.

11. The method of claim 10, wherein, The first request includes a request to register the first RAT, and the first request includes one or more of the following: Information used to indicate that the terminal device is a multi-access device; Information used to indicate that the terminal device supports RAT-based registration; One or more RAT types, wherein the one or more RAT types include the RAT type of the first RAT; Information used to indicate a request to allocate a target registration region to the terminal device, the target registration region including one or more TAIs corresponding to the first RAT.

12. The method of claim 10 or 11, wherein, The first request includes a request to register the first RAT, and the method further includes: The first core network element sends a first response message to the terminal device in response to the first request. The first response message is used to indicate whether to reject or accept the registration of the first RAT.

13. The method of claim 12, wherein, The first response message is used to indicate that the registration of the first RAT is rejected, and / or the first response message is used to indicate that the reason for rejecting the registration of the first RAT is that RAT-based registration is not supported.

14. The method of claim 12, wherein, The first response message is used to indicate acceptance of the registration of the first RAT, and the first response message includes one or more of the following: One or more TAIs corresponding to the first RAT; Mobility restriction information corresponding to the first RAT; The periodic registration timer corresponding to the first RAT.

15. The method of claim 10, wherein, The first request includes a request to request registration and update of the first RAT, and the first request carries one or more of the following: Information used to instruct the terminal device to request a registration update based on RAT; This is used to indicate one or more RAT types to be registered for update, the one or more RAT types including the RAT type of the first RAT.

16. The method of any one of claims 10-15, wherein, The first request includes a request to register or register an update of the first RAT, and the method further includes: In response to accepting the registration of the first RAT, the first core network element records the context associated with the first RAT in the UE context.

17. The method of claim 16, wherein, The context associated with the first RAT includes one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the RM status of the first RAT; Information used to indicate the registration area of ​​the first RAT; Information used to indicate the TAI corresponding to the last access request initiated through the first RAT before sending the first request; Information used to indicate the location of the terminal device; Information used to indicate mobility restrictions associated with the first RAT; Security information used to indicate the control plane associated with the first RAT; Security information used to indicate the user plane associated with the first RAT; Used to indicate the allowed NSSAI associated with the first RAT; The RAT used to indicate that the PDU session associated with the terminal device is the first RAT.

18. The method of claim 17, wherein, Information used to indicate mobility restrictions associated with the first RAT includes one or more of the following: Access type restriction information for the terminal device; The prohibited area information of the terminal device; Service area restriction information associated with the first RAT; The core network type restriction information associated with the first RAT.

19. The method of any one of claims 10-18, wherein, The first request includes a request to register or register an update of the first RAT, and the method further includes: In response to accepting the registration of the first RAT, the first core network element sends first information to the second core network element. The first information is used to instruct the first core network element to provide services to one or more RATs for the terminal device, and the one or more RATs include the first RAT.

20. The method of any one of claims 10-19, wherein, The first request includes a request to register or register an update of the first RAT, and the method further includes: Upon accepting the registration of the first RAT, the first core network element receives a second request from a third core network element. The second request is used to request the context associated with the first RAT, and the third core network element is used to provide services to the first RAT.

21. The method of claim 20, wherein, The method further includes: The first core network element sends a response message to the third core network element in response to the second request, the response message carrying the context associated with the first RAT.

22. The method of claim 10, wherein, The first request includes a request to register the first RAT, and the first request carries one or more of the following: Used to instruct the terminal device to request information for deregistration based on RAT; Used to indicate one or more RAT types to be registered, the one or more RAT types including the RAT type of the first RAT.

23. The method of claim 10, wherein, The multiple RATs include a second RAT, and the first request is used to request to register the first RAT. The first core network element receives the first request sent by the terminal device, including: The first core network element receives the first request sent by the terminal device through the second RAT.

24. The method of any one of claims 10-23, wherein, The RAT type of the first RAT is determined based on one or more of the following: The RAT type of the first RAT indicated in the first request; The identification information of the access network device that sent the first request and the TAI associated with the access network device.

25. A method of wireless communication, comprising: include: The terminal device receives a third request sent by a first core network element, the third request being used to request to register the first RAT of the terminal device.

26. The method of claim 25, wherein, The third request carries one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the reason for registering the first RAT.

27. A method of wireless communication, the method comprising: include: The first core network element receives a third request sent by the second core network element, the third request being used to request the registration of the first RAT of the terminal device.

28. The method of claim 27, wherein, The third request carries one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the reason for registering the first RAT.

29. The method of claim 27 or 28, wherein, The method further includes: The first core network element sends the third request to the terminal device.

30. [Rule 91 Correction 21.11.2024] The method of any one of claims 27-29, wherein, The method further includes: The first core network element deletes the context associated with the first RAT.

31. A method of wireless communication, comprising: include: The second core network element sends a third request to the first core network element, the third request being used to request the registration of the first RAT of the terminal device.

32. The method of claim 31, wherein, The third request carries one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the reason for registering the first RAT.

33. A terminal device, comprising: include: A sending unit is configured to send a first request to a first core network element. The terminal device is configured to access the network via multiple Radio Access Technologies (RATs), including a first RAT. The first request includes one or more of the following: A request used to request registration of the first RAT; A request used to request registration and update of the first RAT; This is used to request the registration of the first RAT.

34. The terminal device of claim 33, wherein, The first request includes a request to register the first RAT, and the first request includes one or more of the following: Information used to indicate that the terminal device is a multi-access device; Information used to indicate that the terminal device supports RAT-based registration; One or more RAT types, wherein the one or more RAT types include the RAT type of the first RAT; Information used to indicate a request to allocate a target registration region to the terminal device, the target registration region including one or more TAIs corresponding to the first RAT.

35. The terminal device according to claim 34, characterized by The target registration region includes only one or more TAIs corresponding to the first RAT.

36. The terminal device of any one of claims 33-35, wherein, The first request includes a request to register the first RAT, and the terminal device further includes: The first receiving unit is configured to receive a first response message sent by the first core network element in response to the first request, wherein the first response message is used to indicate whether to reject or accept the registration of the first RAT.

37. The terminal device of claim 36, wherein, The first response message is used to indicate that the registration of the first RAT is rejected, and / or the first response message is used to indicate that the reason for rejecting the registration of the first RAT is that RAT-based registration is not supported.

38. The terminal device of claim 36, wherein, The first response message is used to indicate acceptance of the registration of the first RAT, and the first response message includes one or more of the following: One or more TAIs corresponding to the first RAT; Mobility restriction information corresponding to the first RAT; The periodic registration timer corresponding to the first RAT.

39. The terminal device of claim 33, wherein, The first request includes a request to request registration and update of the first RAT, and the first request carries one or more of the following: Information used to instruct the terminal device to request a registration update based on RAT; This is used to indicate one or more RAT types to be registered for update, the one or more RAT types including the RAT type of the first RAT.

40. The terminal device of claim 33, wherein, The first request includes a request to register the first RAT, and the first request carries one or more of the following: Used to instruct the terminal device to request information for deregistration based on RAT; Used to indicate one or more RAT types to be registered, the one or more RAT types including the RAT type of the first RAT.

41. The terminal device of claim 33, wherein, The plurality of RATs includes a second RAT, and the first request is used to request to register the first RAT, the sending unit is further used to: The first request is sent to the first core network element via the second RAT.

42. A network device, comprising: The network device is a first core network element, including: A receiving unit is configured to receive a first request sent by a terminal device, the terminal device being configured to access the network via a variety of wireless access technologies (RATs), the variety of RATs including a first RAT, and the first request including one or more of the following: A request used to request registration of the first RAT; A request used to request registration and update of the first RAT; This is used to request the registration of the first RAT.

43. The network device of claim 42, wherein, The first request includes a request to register the first RAT, and the first request includes one or more of the following: Information used to indicate that the terminal device is a multi-access device; Information used to indicate that the terminal device supports RAT-based registration; One or more RAT types, wherein the one or more RAT types include the RAT type of the first RAT; Information used to indicate a request to allocate a target registration area to the terminal device, the target registration area including one or more tracking areas (TAs) corresponding to the first RAT.

44. The network device of claim 42 or 43, wherein, The first request includes a request to register the first RAT, and the network device further includes: The first sending unit is configured to send a first response message to the terminal device in response to the first request, wherein the first response message is used to indicate whether to reject or accept the registration of the first RAT.

45. The network device of claim 44, wherein, The first response message is used to indicate that the registration of the first RAT is rejected, and / or the first response message is used to indicate that the reason for rejecting the registration of the first RAT is that RAT-based registration is not supported.

46. The network device of claim 44, wherein, The first response message is used to indicate acceptance of the registration of the first RAT, and the first response message includes one or more of the following: One or more TAs corresponding to the first RAT; Mobility restriction information corresponding to the first RAT; The periodic registration timer corresponding to the first RAT.

47. The network device of claim 42, wherein, The first request includes a request to request registration and update of the first RAT, and the first request carries one or more of the following: Information used to instruct the terminal device to request a registration update based on RAT; This is used to indicate one or more RAT types to be registered for update, the one or more RAT types including the RAT type of the first RAT.

48. The network device as described in any one of claims 42-47, characterized in that, The first request includes a request to register or register an update of the first RAT, and the network device further includes: In response to accepting the registration of the first RAT, the processing unit is configured to record the context associated with the first RAT in the UE context.

49. The network device as described in claim 48, characterized in that, The context associated with the first RAT includes one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the RM status of the first RAT; Information used to indicate the registration area of ​​the first RAT; Information used to indicate the TA corresponding to the last access request initiated through the first RAT before sending the first request; Information used to indicate the location of the terminal device; Information used to indicate mobility restrictions associated with the first RAT; Security information used to indicate the control plane associated with the first RAT; Security information used to indicate the user plane associated with the first RAT; Used to indicate the allowed NSSAI associated with the first RAT; The RAT used to indicate that the PDU session associated with the terminal device is the first RAT.

50. The network device as described in claim 49, characterized in that, Information used to indicate mobility restrictions associated with the first RAT includes one or more of the following: Access type restriction information for the terminal device; The prohibited area information of the terminal device; Service area restriction information associated with the first RAT; The core network type restriction information associated with the first RAT.

51. The network device as described in any one of claims 42-50, characterized in that, The first request includes a request to register or register an update of the first RAT, and the network device further includes: In response to accepting the registration of the first RAT, the second sending unit is configured to send first information to the second core network element, the first information being used to instruct the first core network element to provide services to one or more RATs for the terminal device, the one or more RATs including the first RAT.

52. The network device as described in any one of claims 42-51, characterized in that, The first request includes a request to register or register an update of the first RAT, and the receiving unit is configured to: Upon accepting the registration of the first RAT, a second request is received from a third core network element. The second request is used to request the context associated with the first RAT, and the third core network element is used to provide services to the first RAT.

53. The network device as described in claim 52, characterized in that, The network device also includes: The third sending unit is used to send a response message to the third core network element in response to the second request, the response message carrying the context associated with the first RAT.

54. The network device as described in claim 42, characterized in that, The first request includes a request to register the first RAT, and the first request carries one or more of the following: Used to instruct the terminal device to request information for deregistration based on RAT; Used to indicate one or more RAT types to be registered, the one or more RAT types including the RAT type of the first RAT.

55. The network device as described in claim 42, characterized in that, The plurality of RATs includes a second RAT, and the first request is used to request to register the first RAT. The receiving unit is used to: Receive the first request sent by the terminal device through the second RAT.

56. The network device as described in any one of claims 42-55, characterized in that, The RAT type of the first RAT is determined based on one or more of the following: The RAT type of the first RAT indicated in the first request; The identification information of the access network device that sent the first request and the TA associated with the access network device.

57. A terminal device, characterized in that, include: The receiving unit is used to receive a third request sent by the first core network element, the third request being used to request to register the first RAT of the terminal device.

58. The terminal device as described in claim 57, characterized in that, The third request carries one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the reason for registering the first RAT.

59. A network device, characterized in that, The network device is a first core network element, including: The receiving unit is used to receive a third request sent by the second core network element, the third request being used to request the first RAT of the terminal device to be registered.

60. The network device as described in claim 59, characterized in that, The third request carries one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the reason for registering the first RAT.

61. The network device as described in claim 59 or 60, characterized in that, The network device also includes: The sending unit is used to send the third request to the terminal device.

62. The network device as described in any one of claims 59-61, characterized in that, The network device also includes: A processing unit is used to delete the context associated with the first RAT.

63. A network device, characterized in that, The network device is a second core network element, including: The sending unit is used to send a third request to the first core network element, the third request being used to request the first RAT of the terminal device to be registered.

64. The network device as described in claim 63, characterized in that, The third request carries one or more of the following: Information used to indicate the RAT type of the first RAT; Information used to indicate the reason for registering the first RAT.

65. A terminal device, characterized in that, The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or transmit signals so that the terminal device performs the method as described in any one of claims 1-9, or performs the method as described in claim 25 or 26.

66. A network device, characterized in that, The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or transmit signals to cause the network device to perform the method as described in any one of claims 10-24, or to perform the method as described in any one of claims 27-32.

67. An apparatus, characterized in that, Includes a processor for calling a program from memory to cause the apparatus to perform the method as described in any one of claims 1-32.

68. A chip, characterized in that, Includes a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1-32.

69. A computer-readable storage medium, characterized in that, It contains a program that causes a computer to perform the method as described in any one of claims 1-32.

70. A computer program product, characterized in that, Includes a program that causes a computer to perform the method as described in any one of claims 1-32.

71. A computer program, characterized in that, The computer program causes the computer to perform the method as described in any one of claims 1-32.

Images