Mobility management and access control method

Abstract

The invention discloses a method, a device and a system for mobility management and access control in a wireless communication system. In one example aspect, a method for wireless communication includes receiving, by a wireless device from a network device, configuration information including handover configuration information; and initiating, by the wireless device, a handover procedure based on the configuration information.

Description

Technical Field

[0001] This disclosure relates to wireless communication. Background Art

[0002] Mobile telecommunication technologies are driving the world towards an increasingly interconnected and networked society. Compared with existing wireless networks, next-generation systems and communication technologies need to support a wider range of use case characteristics and provide more flexible and complex access requirements and flexibility.

[0003] Long-Term Evolution (LTE) is a standard for wireless communication of mobile devices and data terminals developed by the 3rd Generation Partnership Project (3GPP). LTE Advanced (LTE-A) is a wireless communication standard that enhances the LTE standard. The 5th generation wireless system, namely 5G, advances the LTE and LTE-A wireless standards and aims to support higher data rates, massive connections, ultra-low latency, high reliability, and other emerging service requirements. Summary of the Invention

[0004] This disclosure discloses, among other things, technologies related to mobility management and access control in a wireless communication network.

[0005] In one exemplary aspect, a wireless communication method is disclosed. The method includes: a wireless device receiving configuration information including handover configuration information from a network device; and the wireless device initiating a handover process based on the configuration information.

[0006] In another exemplary aspect, another wireless communication method is disclosed. The method includes a network device sending configuration information including handover configuration information related to a handover process to a wireless device.

[0007] In yet another exemplary aspect, a wireless communication device including a process configured or operable to perform the above method is disclosed.

[0008] In yet another exemplary aspect, a computer-readable storage medium is disclosed. The computer-readable storage medium stores code that, when executed by a processor, causes the processor to implement the above method. Brief Description of the Drawings

[0009] Figure 1 An example diagram showing an overall illustration of a non-terrestrial network (NTN).

[0010] Figure 2A An example diagram showing contention-based random access (CBRA) indicating a 4-step RA type.

[0011] Figure 2B Shows an example diagram indicating a CBRA with a 2-step RA type.

[0012] Figure 2C Shows an example diagram indicating a CFRA with a 4-step RA type.

[0013] Figure 2D Shows an example diagram indicating contention-free random access (CFRA) with a 2-step RA type.

[0014] Figure 3 Shows an example diagram indicating the backoff of a CBRA with a 2-step RA type.

[0015] Figure 4 Shows an example diagram of user equipment (UE) capability transfer.

[0016] Figure 5 Shows an example diagram indicating a timing advance reporting MAC control element (CE).

[0017] Figures 6 to 7 Shows an example of a signaling flow diagram for the purpose of UE location for network (NW) authentication.

[0018] Figure 8 Shows an example block diagram of a hardware platform that can be part of a network device or a communication device according to some embodiments of this document.

[0019] Figure 9 Shows an example of network communication, including a network device (base station) and a wireless device based on some implementations of the disclosed technology.

[0020] Figures 10 to 11 Is a flowchart representing a method for wireless communication according to one or more embodiments of the present technology. Detailed implementation

[0021] In this document, section headings are used for ease of understanding and do not limit the scope of the disclosed technology to specific sections. Additionally, certain terms referring to 5G and Third Generation Partnership Project (3GPP) protocols are used as illustrative examples, and the disclosed technology is also applicable to other wireless protocols.

[0022] Various exemplary embodiments of the present solution are described in detail below with reference to the following figures or drawings. The drawings are provided for illustrative purposes only and depict only the exemplary embodiments of the present solution to facilitate the reader's understanding of the present solution. Therefore, the drawings should not be considered as a limitation on the breadth, scope, or applicability of the present solution. It should be noted that, for clarity and convenience of illustration, these drawings are not necessarily drawn to scale. It should be noted that in the disclosure of the present disclosure, a network node may be at least one of the following: a base station (BS) (e.g., gNB or ng-eNB), a component of the BS (e.g., CU or DU), a functional entity hosted by the BS (e.g., OAM), a core network (CN), a component of the CN, a functional entity hosted by the CN (e.g., location management function (LMF)).

[0023] Handover is a fundamental feature of connected-mode mobility management. Since satellite movement is predictable, as the satellite moves, a large number of UEs may simultaneously hand over to the same target cell. In this case, the UEs may also initiate a Random Access Channel (RACH) to the target cell to obtain uplink synchronization, resulting in significant RACH contention and additional access delay on the UE side. Multiple UEs initiating RACH simultaneously may increase the collision rate and reduce the success chance of each UE.

[0024] The handover disclosed in the present disclosure may refer to, but is not limited to, conventional HO, conditional HO, Dual Active Protocol Stack (DAPS) HO, RACH-free HO, or other handover types that may be supported for communication.

[0025] The current Non-Terrestrial Network (NTN) is based on the premise that the transmission delay between the UE and the satellite can be pre-compensated by the user equipment (UE) and / or the network (NW). In the case where the serving link is pre-compensated by the UE, the UE can report its location to the NW. When the NW knows the location of the UE, the NW can derive the serving link delay of the UE and adjust the scheduling policy to meet the service requirements and comply with the regulatory policies of different countries or regions. However, the UE may report a false location, which may mislead the NW. Therefore, methods can be defined to assist the NW in understanding whether the location reported by the UE is accurate. The NW can manage the access of the UE to the NW based on the verification result. For example, the NW can decide to release the UE or reject the connection request of the UE.

[0026] To assist in mobility parameter adjustment, for example, to select an appropriate target cell for handover or adjust cell reselection priorities, a UE may be configured to perform measurements on neighboring cells and / or frequencies. However, since NTN coverage (e.g., coverage provided by satellites) can be much larger than that of a terrestrial network (TN), there may be areas where only NTN coverage is available and no TN coverage is available. In such a case, performing measurements on TN frequencies when there is no TN coverage is a waste of power. One way to help the UE relax or not perform measurements on TN frequencies in such scenarios is to provide the UE with information that can be used to deduce TN coverage. However, considering that there may be different NTN deployments and non-uniform TN coverage distributions, using a fixed granularity to provide TN coverage may be inefficient and require more signaling overhead. For example, for LEO, a typical footprint size can be a diameter of 20 - 1000 km, while for GEO, the footprint size diameter can range from 200 - 3500 km. Since GEO coverage can be hundreds of times that of LEO coverage, if the same granularity is used to provide TN coverage information, multiple times the signaling overhead is required to provide TN coverage. However, a larger granularity suitable for GEO coverage levels may not meet the accuracy requirements of LEO. To save signaling overhead and provide information to the UE with sufficient accuracy, a method of providing TN coverage using configurable granularity is introduced.

[0027] The present disclosure provides methods and procedures for mobility management and access control to address the above problems and others.

[0028] The first embodiment presents methods and apparatuses related to configuration information that is sent to a UE to introduce a randomly generated time delay to increase the success rate of the UE's access procedure. The proposed method is at least beneficial for increasing the efficiency of mobility management in a wireless communication network. To improve or enhance access control accuracy and efficiency, the systems and methods discussed herein may include processes, procedures, and / or implementations for signaling.

[0029] The second embodiment presents methods and apparatuses related to a UE-assisted information reporting scheme for verifying the location of the UE. The proposed method is at least beneficial for increasing the efficiency of mobility management of network nodes. The systems and methods discussed herein may include processes, procedures, and / or implementations for signaling.

[0030] The example embodiments disclosed herein are intended to address problems related to one or more challenges presented in the prior art and to provide additional features that will become apparent when the following detailed description is considered in conjunction with the accompanying drawings. According to various embodiments, example systems, methods, devices, and computer program products are disclosed herein.

[0031] However, it is understood that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art reading this document that various modifications can be made to the disclosed embodiments while remaining within the scope of the present disclosure.

[0032] Preliminary Introduction

[0033] NTN Deployment

[0034] Figure 1 An example of a non-terrestrial network (NTN) that provides non-terrestrial NR access to a UE via an NTN payload and an NTN gateway is shown, depicting a service link between the NTN payload and the UE and a feeder link between the NTN gateway and the NTN payload.

[0035] The NTN payload supports the following connections:

[0036] · - The NTN gateway can serve multiple NTN payloads;

[0037] · - The NTN payload can be served by multiple NTN gateways.

[0038] Three types of service links are supported:

[0039] · - Relative to the Earth fixed: Provided by a beam that continuously covers the same geographical area (e.g., in the case of a geosynchronous orbit (GSO) satellite);

[0040] · - Approximately relative to the Earth fixed: Provided by a beam that covers a geographical area within a limited time period and covers a different geographical area during another time period (e.g., in the case of a non-geosynchronous orbit (NGSO) satellite forming a steerable beam);

[0041] · - Relative to the Earth moving: Provided by a beam whose coverage area slides across the Earth's surface (e.g., in the case of an NGSO satellite generating a fixed or non-steerable beam). Here, the beam can be either fixed or non-fixed.

[0042] Using NGSO satellites, the gNB can provide both quasi-Earth fixed service links and Earth moving service links, while the gNB operating with GSO satellites can provide Earth fixed service links.

[0043] RACH Procedure

[0044] Supports two types of random access procedures: the 4-step RA type using MSG1 and the 2-step RA type using MSGA. Both types of RA procedures support contention-based random access (CBRA) and contention-free random access (CFRA), as follows Figure 2A as shown.

[0045] The UE selects the random access type at the initiation of the random access procedure based on network configuration:

[0046] · When CFRA resources are not configured, the UE uses the RSRP threshold to select between the 2-step RA type and the 4-step RA type;

[0047] · When CFRA resources for the 4-step RA type are configured, the UE performs random access using the 4-step RA type;

[0048] · When CFRA resources for the 2-step RA type are configured, the UE performs random access using the 2-step RA type.

[0049] The network does not configure CFRA resources for both the 4-step and 2-step RA types for a bandwidth part (BWP). CFRA with the 2-step RA type only supports handover.

[0050] The MSG1 of the 4-step RA type consists of a preamble on the Physical Random Access Channel (PRACH). After the MSG1 transmission, the UE monitors the response from the network within the configured window. For CFRA, a dedicated preamble for MSG1 transmission is assigned by the network. After receiving the random access response from the network, the UE ends the random access procedure, as Figure 2C shown. For CBRA, after receiving the random access response, the UE sends MSG3 using the UL grant scheduled in the response and monitors contention resolution, as Figure 2A shown. If contention resolution is not successful after the MSG3 (re)transmission, the UE returns to the MSG1 transmission.

[0051] The MSGA of the 2-step RA type includes a preamble on the PRACH and a payload on the PUSCH. After the MSGA transmission, the UE monitors the response from the network within the configured window. For CFRA, dedicated preamble and PUSCH resources are configured for MSGA transmission, and after receiving the network response, the UE ends the random access procedure, as Figure 2DAs shown, for CBRA, if contention resolution is successful after receiving a network response, the UE ends the random access procedure, as shown in Figure 9 .2.6-1(b); while if a fallback indication is received in MSGB, the UE uses the UL grant scheduled in the fallback indication to perform MSG3 transmission and monitors contention resolution, as shown in Figure 2B . If contention resolution is not successful after (re)transmission of MSG3, the UE returns to MSGA transmission.

[0052] If the random access procedure with a 2-step RA type is not completed after multiple transmissions from MSGA, the UE can be configured to switch to CBRA with a 4-step RA type.

[0053] Example 1:

[0054] Overall:

[0055] Step 1: The UE receives and stores (conditionally) the handover configuration from the NW, which includes the RACH configuration

[0056] Step 2: The UE obtains access to the target cell according to the stored configuration, including initiating RACH to obtain uplink synchronization

[0057] During the RACH procedure, the UE selects RACH resources, including time-domain and frequency-domain resources and code-domain resources. At least one of the three domain resources is different and can ensure that the NW can distinguish the RACH requests received from the UE, thus avoiding contention. The following options can be considered to mitigate RACH contention. Option 1: Based on Time Domain Dispersion:

[0058] For step 1, the configuration can include at least one of the following information to mitigate the RACH contention problem: A timing offset parameter can be included in the configuration, which indicates the maximum delay time by which the UE delays the initiation of the RACH procedure to the target. For the UE, multiple options can be used to determine the received timing offset value.

[0059] In one example, the timing offset can be a duration, which indicates the maximum time by which the UE delays the initiation of the RACH procedure to the target cell.

[0060] In another example, the timing offset can be an index, where each index refers to a duration. The duration is the maximum time by which the UE delays the initiation of the RACH procedure to the target cell.

[0061] In some examples, the above configuration for mitigating RACH contention issues may be included as part of the RACH configuration. For some examples, the configuration received in step 1 may include other parameters, such as cell-specific and / or UE-specific parameters as specified in 3GPP specification 38.331.

[0062] Although the RACH procedure is mentioned in the example explanation as a procedure for mitigating contention using timing offset. The use of the discussed timing offset can be used to solve contention issues occurring for other uplink (UL) transmission types, such as UL transmission using configured grant resources, or UL transmission scheduled by downlink control information (DCI), etc.

[0063] For step 1, the received configuration can be delivered to the UE according to one or more of the following methods: 1) system information, 2) Radio Resource Control (RRC) message (e.g., RRC reconfiguration), 3) non-access stratum (NAS) message, 4) Medium Access Control control element (MAC CE), 5) multicast or broadcast message, such as a common RNTI (or group RNTI) that can be assigned to the UE. The UE will use this assigned common RNTI to monitor and receive downlink control information for scheduling messages including the configuration, or 6) paging message.

[0064] Combinations of the above-given methods can also be used. For example, part of the configuration (e.g., cell-specific configuration common to all UEs) can be assigned to the UE via common signaling (e.g., via system information or multicast or broadcast message), while the UE can receive UE-specific configuration (e.g., C-RNTI) via dedicated RRC signaling. In another example, the UE can receive the configuration via common signaling (e.g., via system information or multicast or broadcast), and the NW can update / modify or release the received configuration based on dedicated RRC signaling.

[0065] All of the above methods can also be used to add, modify, or release the received configuration.

[0066] For Step 2: Determine the Applicability of the Received Timing Offset

[0067] The following options can be used for the UE to determine whether the timing offset parameter received in step 1 is applicable. When it is determined that the timing offset parameter is applicable, the UE applies the timing offset when initiating the RACH according to the examples discussed in the following sections. Otherwise (i.e., if the timing offset is considered inapplicable), the UE will initiate the RACH based on the timing specified in the specification (i.e., without considering the timing offset discussed in step 1).

[0068] In one example, the presence of a timing offset parameter can be used to indicate that a timing offset is applicable.

[0069] In another example, an indication can be used to indicate whether a received timing offset parameter is applicable. In yet another example, a one-bit indication can be used. For example, a value of 1 indicates that the received timing offset parameter is applicable, while zero means it is not applicable. Vice versa.

[0070] In another example, an indication with an enumerated type can be used. For example, the presence of this indication with a true value indicates that the received timing offset parameter is applicable, while the absence means the timing offset is not applicable.

[0071] In another example, an indication is used to prohibit the use of a timing offset value. For example, one example is to use this disable indication together with Example 1. For example, the UE always uses the received timing offset parameter as applicable. But if it receives the disable indication, the UE considers this timing offset to be inapplicable.

[0072] In yet another example, the NW type can be used to determine the applicability of a timing offset parameter. For example, when determining that the NW type is NTN, the UE considers the timing offset to be applicable. Otherwise, the UE considers the timing offset inapplicable. The NW type can be NTN or TN, or a Radio Access Technology (RAT) type (e.g., 4G, 5G, and 6G), or any type of communication system used.

[0073] The information used by the UE to determine whether a timing offset can be included in one or more methods is as follows:

[0074] · In system information, such as MIB or SIBx;

[0075] · In an RRC message, such as an RRC reconfiguration message. In some examples, it can be included in otherConfig or TAR-Config.

[0076] · In a NAS message

[0077] · In a MAC CE

[0078] · In a paging message;

[0079] · In multicast signaling, for example, a message scrambled with a common RNTI can notify the UE with this information.

[0080] For Step 2: Determine the Timing for Initiating RACH

[0081] The following steps are used for the UE to determine the value of the timing offset to be used and accordingly perform the RACH procedure as part of a conditional (HO) procedure.

[0082] Step 1: When the UE determines that the timing offset is applicable to this (conditional) HO, the UE randomly generates a value between [0, the received timing offset], and the UE determines that the timing offset value is equal to the generated value.

[0083] Step 2: The UE performs RACH resource selection after the timing offset time and sends the first message of the RACH procedure according to the selected resource. The RACH procedure can be a two-step RACH, a four-step RACH, or another specified RACH.

[0084] The following are examples of how the timing offset will be used in the RACH procedure:

[0085] In some examples, the timing offset is applicable only to the first RACH attempt associated with this HO procedure. This means that for this HO procedure, the UE will delay the initiation of the RACH procedure only once with this timing offset and only for the first RACH resource.

[0086] In one example, Step 1 occurs only once during the initialization process of the RACH procedure, and a variable can be used to store the generated timing offset value. After the first RACH selection is performed, the variable will be reset to zero.

[0087] In some examples, the timing offset is applicable to each attempt of the RACH procedure until the handover fails (e.g., T304 expires).

[0088] In one example, Step 1 occurs during the initialization process of the RACH procedure, and a variable can be used to store the generated timing offset value. For each RACH resource selection, the UE delays for the time indicated by the timing offset.

[0089] In one example, Step 1 occurs just before the RACH resource selection. For example, the UE generates the timing offset time each time it performs RACH resource selection.

[0090] In some examples, the timing offset only applies to the first transmission of the first message of the same type of RACH. In one example, for each RA type, step 1 occurs at most once during the initialization of the RACH procedure. For example, 2-step RA is first selected, the UE generates a timing offset and uses it for the first MsgA transmission. During the RACH procedure, the RA type switches to a 4-step RA type, and the UE then generates a new timing offset and uses it for the first Msg1 transmission (e.g., preamble) of the 4-step RA type. In some examples, variables can be used to assist this behavior. For example, when the variable for the selected RACH type for initialization, the variable is set to the timing offset generated by the UE and reset to zero after the first RACH resource selection of the selected RA type.

[0091] For Step 1: Capability Signaling

[0092] Example 1: The use of the timing offset can be an optional feature of the UE. This feature can be optional without signaling. If the UE does not support this feature, it can simply ignore the received timing offset.

[0093] Example 2: The use of the timing offset can be an optional feature of the UE. An ability is used to indicate whether the UE supports this feature.

[0094] As specified in 3GPP specification 38.331 and 3GPP specification 38.306, the ability bit can be transmitted in the UE ability signaling. An example is as follows:

[0095] Example 3: The use of the timing offset can be conditionally optional for the UE, which means that the support for this feature can depend on some specified conditions. For example, if the UE supports group-based (conditional) HO, the UE supports this feature. For example, if the UE supports NTN, the UE supports this feature. For example, if the UE supports receiving (conditional) HO configuration in the system information, the UE supports this feature.

[0096] Example 4: The UE is forced to support this feature.

[0097] The following are examples of how to query the UE to report UE ability information to the NW.

[0098] The NW can send a first message to query the UE's ability, and the UE can send ability information to inform the NW of its ability. In some examples, the NW can use the received ability to decide whether to configure timing offset parameters for the UE. In another example, the NW can pass the received UE ability information between different nodes. Or in some examples, if the UE does not support this feature, the UE can ignore the configured timing offset parameters.

[0099] Option 2: Based on Code Domain Discrimination:

[0100] For Step 2: A New Preamble Format Can Be Used

[0101] Code domain differentiation can be accomplished by introducing a new preamble format, which can be done by one or more of the following options:

[0102] The UE ID can be used to scramble the preamble sent to the NW.

[0103] In one example, the C-RNTI included in the received (conditional) HO configuration can be used. In another example, only a part of the C-RNTI (e.g., the leftmost X bits or the rightmost Y bits) is used.

[0104] In another example, the security key included in the received (conditional) HO configuration can be used. In another example, only a part of the security (e.g., the leftmost X bits or the rightmost Y bits) is used.

[0105] Since this information is known at both the NW side and the UE side, the NW can attempt to detect the preamble based on the scrambling information.

[0106] Alternatively, the UE ID can be used to generate the preamble.

[0107] In one example, the C-RNTI included in the received (conditional) HO configuration can be used. In another example, only a part of the C-RNTI (e.g., the leftmost X bits or the rightmost Y bits) is used.

[0108] A combination of the above examples can be used as the new preamble format.

[0109] For Step 2: Determine the Use of the New Preamble

[0110] The following options can be used for the UE to determine whether to use the new preamble in the RACH.

[0111] In one example, an indication can be used to indicate whether to use the new preamble format in the RACH. For example, a one-bit indication can be used. For example, the value 1 indicates using the new preamble format, while zero means not using the new preamble format. Vice versa.

[0112] In another example, an indication of an enumerated type can be used. For example, the presence of an indication with the value true indicates using the new preamble format, while the absence means not using it.

[0113] In another example, the NW type can be used to determine whether to use a new preamble format. For example, when it is determined that the NW type is NTN, the UE decides to use the new preamble format. Otherwise, the UE will not use the new preamble format. The NW type can be NTN or TN, or a radio access technology (RAT) type (e.g., 4G, 5G, and 6G), or any type of communication system or communication technology used.

[0114] In another example, the HO type can be used to determine whether to use a new preamble format. When partial or all (conditional) HO configurations are received in common signaling (e.g., in group signaling or in system information or in a paging message), the UE decides to use the new preamble format. Otherwise, the UE will not use the new preamble format.

[0115] In another example, an indication is used to prohibit the use of the new preamble format. For example, the UE always uses the new preamble format. However, if the UE receives a disabling indication, the UE will not use the new preamble format. This example can be used in combination with the above examples. For example, one example is to use this disabling indication together with Example 4. When a (conditional) HO configuration is received in common signaling, the UE treats the new preamble as the default RACH configuration. If the disabling indication is not received, the UE uses the new preamble format discussed above, otherwise, if the disabling indication is received, the UE will not use the new preamble format.

[0116] For Step 1: Capability Signaling

[0117] The solutions discussed in the above sections for signaling the UE's ability to support the timing offset feature can also be considered for signaling the UE's ability to support this new preamble format.

[0118] Option 1 and Option 2 can be used independently or in combination with each other.

[0119] Example 2: UE-Assisted Information Reporting for NW to Verify UE Location

[0120] Timing advance is considered equivalent information for the UE to calculate the round trip time (RTT) between the UE and the NW, which can be further used to estimate the UE's location. In one example, assuming that multiple TA information can be received during a measurement period, the NW can derive the propagation delay between the UE and the NW at different time instances based on the TA information. The NW can draw circles for each derived propagation delay, and the intersection points of the drawn circles will be the possible ranges where the UE is located. The accuracy will depend on the frequency of TA reporting and the TA reporting granularity. Another approach is to report the RTT instead of the TA, which can achieve the same purpose.

[0121] Overview:

[0122] The following steps can be used to configure the UE to report assistance information to help the NW verify the UE's location. The steps for the NW to receive the location reported by the UE are not shown. It can be provided together with or independently of the steps discussed below.

[0123] · Step 1: The NW provides the configuration for the multi-XXX report

[0124] · Step 2: The NW receives the multi-XXX report from the UE

[0125] · Step 3: The NW derives the UE location based on the received TA information

[0126] · Step 4: The NW determines whether the location information reported by the UE is trustworthy

[0127] The NW can be one or more of the following:

[0128] · The core network (CN) or one or more entities hosting the functions of the CN, such as the Location Management Function (LMF) or the Access Management Function (AMF).

[0129] · The NG-RAN node, or one or more entities hosting the functions of the NG-RAN node, such as OAM. The NG-RAN node can be a gNB, an ng-gNB, or any component of other base stations or base stations specified in the 3GPP specifications.

[0130] In some examples, if XXX can be RTT, and the UE report content is RTT-related information. In another example, the report content can be TA-related information. In this case, XXX can be TA. However, all of this is just for reference. The exact terms used may still be different. Note that the multi-XXX report here is just an example term. The reports discussed here can also consider other terms.

[0131] For Step 1:

[0132] Question 1: Which nodes generate the multi-XXX report configuration

[0133] This configuration can come from at least one of the following NW nodes:

[0134] Case 1: The configuration is generated by the CN.

[0135] Case 2: The configuration is generated by the NG-RAN node (e.g., gNB).

[0136] Case 3: A combination of Case 1 and Case 2.

[0137] Example 1: The CN generates this configuration and delivers it to the gNB. The gNB may modify or update or release the received configuration and deliver it to the UE.

[0138] For Case 1, when the multi-TA report configuration comes from the CN, the configuration can be either transparent to the NG-RAN node or known to the NG-RAN node. When the multi-TA report is transparent, the NG-RAN node only forwards the received message to the UE, including the configuration of the NW-verified UE location. When the multi-TA report is known to the NG-RAN node, in some examples, the NG-RAN node can decide whether to update the configuration when configuring the UE based on the configuration in step 2.

[0139] Question 2: Content of the multi-XXX report configuration

[0140] This configuration includes at least one of the following:

[0141] Report interval, which specifies the period for the UE to perform reporting

[0142] Measurement interval, which specifies the period for the UE to perform measurements. In some examples, the report interval can also be used to perform measurements and vice versa.

[0143] Report quantity, which specifies the number of reports to be reported

[0144] Report duration, which specifies the duration for the UE to perform reporting

[0145] Measurement duration, which specifies the duration for the UE to perform measurements. In some examples, the report duration can also be used for measurements and vice versa.

[0146] Activation indication, which indicates that the NW or the UE starts measuring and / or reporting upon receiving this indication for NW-based UE location verification

[0147] Purpose indication or type indication, which indicates the purpose or type of this configuration / task, and this configuration / task is for NW-based UE location verification.

[0148] Report content indication, which indicates the content of the information to be reported. In one example, this indication can have a value that is the name of the content to be reported. For example, when the report content indication value is 'TA', the UE reports TA information. If the report content indication value is 'RTT', then the UE reports RTT information. In another example, this indication can indicate an index, where each index refers to a type of the content to be reported.

[0149] A threshold, which is used to trigger reporting. For example, if the difference between the current measurement and the continuously reported measurement is equal to or greater than the threshold, the UE initiates a reporting procedure.

[0150] An indication, which indicates whether the scheduling request procedure can be used to request UL resources for this reporting.

[0151] Question 3: Methods for configuring the delivery of multi-XXX reports to the UE

[0152] The configuration comes from one or more of the following options:

[0153] Option 1: Via a DL NAS message, such as DLInformationTransfer.

[0154] Option 2: Via a DL RRC message. For example, RRCReconfiguration, RRCResume or RRCSetup message. It can be included in different positions within the RRC message, for example, in the measurement target (e.g., measObjectNR) or in otherConfig or in TAR-Config.

[0155] Option 3: Via system information. An example is SIB19.

[0156] Option 4: Via the paging message.

[0157] Option 5: Via a common message qualified for multicast or broadcast.

[0158] Option 6: Combinations of the above options can also be considered. For example, the configuration can be provided in SIB19 and modified / released via DL RRC signaling.

[0159] The above options can also be considered for updating, adding, modifying or releasing the configuration.

[0160] Question 5: How to activate the NW-verified UE location task

[0161] Option 1: After receiving a message including the corresponding configuration, the UE starts TA measurement and reports after receiving this configuration.

[0162] Option 2: Based on the received activation indication

[0163] For Option 2, the UE stores the received configuration and waits until it receives an activation command from the NW to start measurement and reporting. The following are examples of how to deliver the activation indication:

[0164] Example 1: As discussed above, the activation indication can be carried in the same message that carries the configuration for the NW-verified UE location.

[0165] Example 2: In another example, it can be carried in the MAC CE.

[0166] Example 3: It can be carried in a message (e.g., a location activation message for NW authentication) for activating the UE location information task for NW authentication, and this message can be a NAS message or an RRC message.

[0167] Example 4: It can be a one-bit indication included in the system information, in paging, or in an RRC message.

[0168] Question 6: Configuration Release

[0169] The following options can be considered to release the received configuration

[0170] Option 1: The UE releases the configuration after receiving a release message from the NW.

[0171] Option 2: The UE releases the configuration after completing the transmission of the message, including reporting.

[0172] Option 3: The UE releases the configuration after receiving an explicit indication from the NW. The solutions for activation indication discussed above can also be used to deliver the release indication to the UE.

[0173] Option 4: The UE releases the configuration after a certain amount of time.

[0174] Question 7: Capability Signaling and Transmission

[0175] In one example, this feature can be optionally supported. A capability bit can be used to indicate whether the UE supports providing auxiliary information to the NW for the purpose of UE location for NW authentication. This indication can be transmitted through one or more of the following options:

[0176] · A capability message for transmitting capabilities related to the positioning function. For example, LPP provides capabilities

[0177] · The UE capability query procedure, as specified in the 3GPP 38.331 specification

[0178] In another example, this feature can be conditionally supported. For example, if the UE supports NTN, then the UE supports this feature.

[0179] In another example, this feature is mandatory and supported.

[0180] For the above options for capability signaling, the NW is able to transfer this UE capability information between different RAN nodes.

[0181] For Step 2:

[0182] Question 1: Report content, or in other words, auxiliary information

[0183] The content of the report can be at least one of the following:

[0184] Option 1: UE-specific TA. In one example, it can be the timing advance report specified in 3GPP specification 38.321. In one example, the UE-specific TA refers to the sum of the serving link delay and the feeder link delay.

[0185] Option 2: Differential UE-specific TA. The UE-specific TA can be the TA discussed in Option 1 above.

[0186] Option 2-1: The first measurement is the UE-specific TA, and the subsequent TAs are the TA differences compared to the first reported / measured TA.

[0187] Option 2-2: The first measurement is the UE-specific TA, and the subsequent TAs are the TA differences compared to the previous reported / measured TA.

[0188] Option 3: Serving link delay estimated by the UE.

[0189] Option 4: Differential serving link delay estimated by the UE.

[0190] Option 2-1: The first measurement is the UE-estimated serving link delay, and the subsequent measurements are the delay differences compared to the first reported / measured serving link delay.

[0191] Option 2-2: The first measurement is the UE-estimated serving link delay, and the subsequent measurements are the delay differences compared to the previously reported / measured serving link delay.

[0192] Option 5: UE-gNB RTT as specified in 3GPP specification 38.331.

[0193] When differential values are reported, negative values can be reported if the latest TA or RTT or serving link delay decreases. To help the NW understand this situation, the following options can be considered.

[0194] Reserve one bit to indicate whether the reported value is positive or negative. For example, zero means positive and 1 means negative, and vice versa. This one bit can be placed in the leftmost or rightmost position. Or another position can be reserved for this bit.

[0195] The granularity of the above-reported TA or RTT or serving link delay can be at least one of the following options:

[0196] Option 1: The number of time slots when the subcarrier spacing (SCS) is equal to a certain frequency. For example, the SCS can be a fixed value, e.g., 15 KHz. In another example, the SCS can be the SCS of the PUSCH resource used to send the report.

[0197] Option 2: The number in nanoseconds or tens of nanoseconds.

[0198] Option 3: The number in milliseconds.

[0199] Option 4: The number in microseconds.

[0200] Option 5: The number in symbols.

[0201] Option 6: The number in SFN.

[0202] Option 7: If the timing advance report is enhanced to provide auxiliary information on the UE location for NW verification. Then different granularities can be defined for TA reports for different purposes, which can be configured by the NW. And the following alternatives can be considered:

[0203] Alternative 1: The granularity is explicitly configured by the NW through at least one or more of the methods mentioned here: NAS signaling or RRC signaling or system information or MAC CE signaling or multicast / broadcast or paging.

[0204] Alternative 2: Use the default granularity unless another granularity is configured.

[0205] Question 2: Which message is used to receive the report

[0206] Option 1: MAC CE

[0207] Option 2: UL RRC message. The following are some examples that can be considered for delivering the report:

[0208] · In the measurement report

[0209] · In the UEInformationResponse

[0210] · In the UE auxiliary information

[0211] · In the RRCResumComplete message

[0212] · In the RRCReconfigurationComplete message

[0213] · In the RRCSetupComplete message or

[0214] · In the newly defined RRC message

[0215] Other RRC messages as defined in the specification may also be considered, such as the RRC Resume Request message.

[0216] Option 3: UL NAS message. For delivery reports, the following examples may be considered:

[0217] · UL Information Transfer

[0218] · UE Positioning Assistance Info or

[0219] · Newly defined NAS message

[0220] Other RRC messages as specified in the specification may also be considered.

[0221] If the timing advance report is enhanced to provide auxiliary information on the UE position for NW verification, then this method needs to be considered to allow the NW to know the unit of the TA report. One option is to modify the reserved bits of the timing advance report MAC CE to indicate which granularity is used as the unit of the timing advance value indicated by the timing advance field in the timing advance report MAC CE. For example, a granularity bit 'G' can be introduced. If G is set to zero, it means that the unit defined in Release 17 for the timing advance report MAC CE is used (e.g., the number of time slots when using a 15 KHz subcarrier), and G being set to 1 means that a new granularity defined for the purpose of UE position for NW verification is used (e.g., a finer granularity). The following figure gives an example:

[0222] The timing advance report MAC CE is identified by a MAC sub-header with an LCID. It has a fixed size and consists of two octets as defined below, as Figure 5 shown.

[0223] · R: Reserved bit, set to 0;

[0224] · G: Granularity bit, which will indicate which granularity is used for the timing advance field.

[0225] · Timing advance: In FR1, if G is set to zero, the timing advance field indicates the minimum integer number of time slots (using a 15 KHz subcarrier spacing) greater than or equal to the timing advance value (see TS38.211 [8], section 4.3.1). If G is set to 1, the timing advance field indicates the timing advance value in microseconds. The length of the field is 14 bits.

[0226] Here, the disclosed examples given above are only for explanatory purposes. The indicated positions may be different, the terms used may be different. In addition, the example units in the explanatory fields may also be different. For Step 3:

[0227] Question 1: Which nodes can derive the UE location

[0228] At least one of the following NW nodes can derive the UE location based on the received assistance information.

[0229] Case 1: The CN or an entity hosting one or more functions of the CN (e.g., LMF) receives the assistance information and derives the UE location

[0230] Case 2: The NG-RAN node (e.g., gNB) or an entity hosting one or more functions of the NG-RAN node (e.g., OAM) receives the assistance information and derives the UE location

[0231] Case 3: Both entities mentioned in Case 1 and Case 2 can independently calculate the UE location based on the received assistance information.

[0232] For Step 4:

[0233] Question 1: Which nodes can perform verification

[0234] At least one of the following NW nodes can derive the UE location based on the received assistance information.

[0235] Case 1: Only the CN or an entity hosting one or more functions of the CN (e.g., LMF) can perform verification

[0236] Case 2: The entity that receives the assistance information and derives the location information can perform verification

[0237] For Case 1, if the UE location is derived in a node other than the CN or the entity hosting the CN function (e.g., LMF). Then that node needs to deliver at least the derived UE location to the CN. Additional information can also be provided, e.g., the assistance information for calculation and / or the method for calculation.

[0238] For Case 2, there may be more than one entity that can perform this verification. Then the CN can request another entity to provide one of the following for double verification:

[0239] · The verification result, which may include one or more of the contents discussed in the next chapter.

[0240] · The assistance information for calculation

[0241] · The method for calculating the UE location

[0242] Question 2: Verification result content

[0243] The verification result may include at least one of the following:

[0244] · A flag indicating whether the location reported by the UE is correct;

[0245] · A flag indicating whether the UE location report is trustworthy;

[0246] · A flag indicating whether the UE is allowed to access the NW;

[0247] · A duration indicating how long the UE is considered untrustworthy;

[0248] · A duration indicating how long the UE is considered trustworthy;

[0249] · Areas where the UE is considered untrustworthy or not allowed to access the NW;

[0250] · Areas where the UE is considered trustworthy or allowed to access the NW;

[0251] · The UE identifier is used to uniquely identify the UE within the NW;

[0252] · Auxiliary information for calculation;

[0253] · The method for calculating the UE location;

[0254] · The location reported by the UE;

[0255] · The location of the UE estimated by the NW;

[0256] · A confidence interval, which indicates the confidence level of the estimated result;

[0257] · An estimation error, which indicates the error range of the estimated result;

[0258] In some examples, if the NW determines that the UE has reported a false location, then one or more of the following actions may be considered by the NW.

[0259] Release the connection of the UE:

[0260] · A purpose indication can be used to indicate the purpose of the release. For example, the indication is used to indicate that the UE is released because it fails the NW-based UE location verification task.

[0261] · The message used to release the UE connection may also include one or more of the contents discussed above in the verification result content section.

[0262] Reject the UE's request to connect to the NW within a certain time period. This time can be indicated as a verification result or included in the message for releasing the UE connection.

[0263] Reject the UE's request to connect to the NW within a certain area. This area can be indicated as part of the verification result or included in the message for releasing the UE connection.

[0264] Figure 6 An example of the signaling flow diagram for the NW's task of verifying the UE's location is given.

[0265] In step 1, the LMF triggers the NW's task of verifying the UE's location by sending a multi-XXX report configuration to the AMF. Step 2, as Figure 6 shown, is optional. For example, when the UE is in the idle or inactive state, paging is required to send the UE to the connected mode for data transmission. In step 3, the AMF delivers the received configuration to the UE via a NAS message. In this example, the configuration is included in the DL positioning message.

[0266] Step 4. The UE performs measurements and calculations accordingly after receiving the configuration. And reports the measurement results in the UL NAS message to the AMF in step 5. In this example, the auxiliary information reported by the UE is included in the UL positioning message. In step 6, the AMF forwards the received measurement to the LMF. After receiving the measurement, the LMF calculates the UE's location and performs verification.

[0267] Steps 8-10, as Figure 6 shown, are also optional. For example, if the verification result indicates that the UE has reported a false location, the LMF decides to notify the AMF. After receiving such information, the AMF can choose to release the UE connection, as illustrated in steps 9 and 10.

[0268] As Figure 7 shown, the following is another example assuming that the TA is the auxiliary information for the NW to verify the UE's location. This auxiliary information can be specified in the specification or other parameters discussed in this disclosure.

[0269] Step 1: The CN triggers the NW's task of verifying the UE's location and notifies the NG-RAN;

[0270] Step 2: After receiving the message for triggering the NW's task of verifying the UE's location, the NG-RAN configures the UE with the TA report configuration (e.g., in TAR-Config);

[0271] Step 3: The UE performs TA measurements and reports to the NG-RAN accordingly;

[0272] Step 4: The NG-RAN processes the received TA measurement (e.g., subtracts the feeder link delay) and sends the result to the CN;

[0273] Step 5: The CN performs verification based on the received TA measurement.

[0274] Example 3: Method for Providing Information with Appropriate Granularity for TN Coverage Estimation

[0275] In this embodiment, a method for providing information to the UE to determine the granularity for TN coverage calculation is discussed. At least one of the following options can be considered so that the UE can determine the granularity for TN coverage estimation based on the information provided by the NW:

[0276] Option 1: A fixed granularity can be defined. For example, this fixed granularity can be at the cell level. For example, TN coverage is counted as the number of cells. Other granularities can also be considered, such as the coverage level similar to the tracking area, the coverage level similar to the RAN notification area, etc. Or in some examples, if the geometry identifies an area, then the fixed unit used for the calculation of the geometry can be considered as the granularity for presenting TN coverage. For example, if TN coverage is indicated by a circular area presented by the cell center and radius, then the granularity can be presented as a radius of x kilometers, and the TN coverage in this example is x square kilometers (x refers to a mathematical number). However, other units or granularities can also be considered.

[0277] Option 2: A configurable granularity can be used. For example, the NW can provide the granularity for the UE to calculate TN coverage. For this option, the granularity can refer to the granularity examples discussed in Option 1. At least one of the following alternatives can be considered for configuring the granularity for the UE:

[0278] Alternative 1: Explicitly provide the granularity when providing the auxiliary information for TN coverage calculation.

[0279] Alternative 2: Provide granularity levels, where each granularity level corresponds to a specified granularity. The granularity can increase or decrease as the granularity level increases. For example, granularity level 1 uses km as the unit, level 2 uses 5 times x km as the unit, level 3 uses 10 times x km as the unit, etc., where x refers to a mathematical number. The mapping between the granularity level to be used and the granularity can be predefined in the specification or configured by the NW. The granularity level can be indicated by an index or a mathematical value.

[0280] Alternative 3: A scaling factor can be provided, which is used to scale up or scale down the granularity used for calculating TN coverage. In one example, the UE determines the granularity used by multiplying the default granularity by the configured scaling factor. In some examples, the granularity to be multiplied can be the currently used granularity or the granularity configured by the NW. The scaling factor can be a number greater than, equal to, or less than 1.

[0281] Option 3: Different granularities can be used for different NTN deployments. In one example, the NTN deployment can be GEO, LEO, or HAPS. Or the NTN deployment can be a relative-earth mobile system, a GSO system, or an approximately relative-earth fixed system. For example, the UE decides which granularity to use for calculating TN coverage based on the NTN deployment. Or in another example, the NW configures different granularities for different NTN deployments. Or in another example, the NW configures different granularities for different NW types. Or the granularity for a specific NW type is defined in the specification, and the UE decides which granularity is used for calculating TN coverage based on the NW type. For this option, the granularity can refer to the granularity examples discussed in Option 1.

[0282] Option 4: A minimum granularity can be defined, such as using a radius of 2 km. The NW can provide TN coverage equal to or greater than this granularity. The minimum granularity can be determined based on the methods discussed in Option 1 and Option 2. In one example, the NTN deployment can be GEO, LEO, or HAPS. Or the NTN deployment can be a relative-earth mobile system, a GSO system, or an approximately relative-earth fixed system. In another example, different minimum granularities can be provided for different NW types.

[0283] The information discussed in the above options can be provided to the UE in one or more ways as follows:

[0284] · In system information, such as MIB or SIBx (e.g., SIB19);

[0285] · In an RRC message, such as an RRC reconfiguration message. In some examples, it can be included in otherConfig or measurement configuration (e.g., measObjectNR);

[0286] · In a NAS message;

[0287] · In a paging message;

[0288] · In multicast or broadcast signaling. For example, a message scrambled by a common RNTI can be used to notify the UE of this information.

[0289] · In MAC CE signaling.

[0290] After receiving information indicating the granularity for calculating TN coverage, the UE will use the indicated granularity to estimate TN coverage.

[0291] Figure 8 An exemplary block diagram of a hardware platform 800 that can be part of a network device (e.g., a base station BS) or a communication device (e.g., a user equipment (UE)) is shown. The hardware platform 800 includes at least one processor 810 and a memory 805 storing instructions. The instructions, when executed by the processor 810, configure the hardware platform 800 to perform Figure 8 and the operations described in various embodiments described in this disclosure document. A transmitter 815 conveys or transmits information or data to another device. For example, a network device transmitter can send a message to a user equipment. A receiver 820 receives information or data conveyed or transmitted by another device. For example, a user equipment can receive a message from a network device.

[0292] The embodiments discussed above will apply to network communication. Figure 9 An example of a communication system (e.g., a 6G or NR cellular network) including a base station 920 and one or more user equipments (UEs) 911, 912, and 913 is shown. In some embodiments, the UE accesses the BS (e.g., the network) using a communication link to the network (sometimes referred to as the uplink direction, as shown by the dashed arrows 931, 932, 933), which then enables subsequent communication from the BS to the UE (e.g., shown in the direction from the network to the UE, sometimes referred to as the downlink direction, as shown by the arrows 941, 942, 943). In some embodiments, the BS sends information to the UE (sometimes referred to as the downlink direction, as shown by the arrows 941, 942, 943), which then enables subsequent communication from the UE to the BS (e.g., shown in the direction from the UE to the BS, sometimes referred to as the uplink direction, as shown by the dashed arrows 931, 932, 933). The UE can be, for example, a smart phone, a tablet computer, a mobile computer, a machine-to-machine (M2M) device, an Internet of Things (IoT) device, and so on.

[0293] In one example aspect (e.g., as Figure 10 depicted), a wireless communication method is disclosed. The method includes: receiving (1002), by a wireless device, configuration information including handover configuration information from a network device; and initiating (1004), by the wireless device, a handover process based on the configuration information.

[0294] In another example aspect (e.g., as Figure 11(depicted in) discloses another wireless communication method. The method includes a network device sending (1102) configuration information to a wireless device, the configuration information including handover configuration information related to a handover process.

[0295] In some embodiments, the configuration information includes a time offset parameter, the time offset parameter indicating a maximum time delay for the wireless device to start message transmission.

[0296] In some embodiments, the configuration information is sent in at least one of the following ways: 1) system information, 2) dedicated signaling, 3) multicast or broadcast, or 4) paging message.

[0297] In some embodiments, the method disclosed above further includes: the wireless device determining whether the time offset parameter is applicable based on an indication; when determining that the time offset parameter is applicable, applying the time offset parameter in initiating message transmission; and when determining that the time offset parameter is not applicable, avoiding using the time offset parameter in initiating message transmission.

[0298] In some embodiments, the indication is at least one of the following: 1) the presence of the time offset parameter, 2) an integer indication indicating that the time offset is applicable, 3) an enumerated indication, or 5) network type.

[0299] In some embodiments, the indication indicates that the time offset parameter is disabled.

[0300] In some embodiments, the indication is sent in at least one of the following ways: 1) system information, 2) NAS message, 3) RRC message, 4) MAC CE, 5) multicast or broadcast, or 6) paging message.

[0301] In some embodiments, the message may be the first message of a RACH process, the RACH process including at least one RACH attempt, wherein each RACH attempt requires an initial step to initiate the RACH attempt.

[0302] In some embodiments, initiating includes the wireless device generating a value between 0 and the time offset parameter and initiating the RACH process after a duration equal to the value.

[0303] In some embodiments, the value is generated based on a random method.

[0304] In some embodiments, each RACH attempt requires a new value.

[0305] In some embodiments, each RACH attempt requires the same value.

[0306] In some embodiments, when a wireless device determines a change in the RACH procedure type, a new value is required for the RACH attempt.

[0307] In some embodiments, the method disclosed above further includes determining, by the wireless device based on the capabilities of the wireless device, whether to apply a time offset to determine the timing of initiating message transmission.

[0308] In some embodiments, the method disclosed above further includes: determining, by the network device based on the capabilities of the wireless device, whether to include a time offset in the configuration information of the handover information.

[0309] Figures 8 to 9 Various preferred embodiments and additional features of the above method. Further examples are described with reference to Embodiments 1 to 3.

[0310] It should be understood that this document discloses methods and apparatuses related to mobility management and access control in a wireless communication system. Two embodiments are proposed in this application. The first embodiment proposes methods and apparatuses related to configuration information that is sent to a UE to introduce a randomly generated time delay to increase the success rate of the UE's access procedure. The proposed method is at least beneficial for increasing the efficiency of mobility management in a wireless communication network. To improve or enhance access control accuracy and efficiency, the systems and methods discussed herein may include procedures, programs, and / or implementations for signaling. The second embodiment proposes methods and apparatuses related to a UE-assisted information reporting scheme for verifying the location of the UE. The proposed method is at least beneficial for increasing the efficiency of mobility management of network nodes. The systems and methods discussed herein may include procedures, programs, and / or implementations for signaling.

[0311] The modules and functional operations disclosed in this document and in other embodiments can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a combination of substances affecting a machine-readable propagated signal, or a combination of one or more of them. The term "data processing apparatus" includes all apparatuses, devices, and machines for processing data, such as including programmable processors, computers, or multiple processors or computers. The apparatus can also include code for creating an execution environment for the computer programs being discussed, in addition to hardware, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, such as a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver apparatus.

[0312] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including a compiled language or an interpreted language, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program being discussed, or in multiple coordinated files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0313] The processes and logical flows described in this document can be executed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be executed by dedicated logic circuitry, and the apparatus can also be implemented as dedicated logic circuitry, such as an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit).

[0314] Processors suitable for executing computer programs include, by way of example, both general and special purpose microprocessors, as well as any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include or be operatively coupled to receive data from and / or transmit data to one or more mass storage devices for storing data (such as magnetic disks, magneto-optical disks, or optical disks) or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0315] Although this document contains many details, these should not be construed as limitations on the scope of the claimed invention or of inventions that may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments may also be implemented in combination within a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments. Additionally, while the above features may be described as acting in certain combinations and even initially claimed in such a manner, in some cases, one or more features from a claimed combination may be excluded from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, although operations are depicted in the figures in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[0316] Embodiments are described herein in detail with reference to the accompanying drawings, and specific examples of the embodiments are shown by way of illustration. Note, however, that the present disclosure may be embodied in many different forms and thus the subject matter covered or claimed is intended to be construed as not limited to any embodiment set forth below.

[0317] Throughout the specification and claims, terms may have nuances of meaning that go beyond the explicitly stated meaning suggested or implied by the context. Similarly, as used herein, the phrase "in one embodiment" or "in some embodiments" does not necessarily refer to the same embodiment, and the phrase "in another embodiment" or "in other embodiments" as used herein does not necessarily refer to different embodiments. As used herein, the phrase "in one implementation" or "in some implementations" does not necessarily refer to the same implementation, and the phrase "in another implementation" or "in other implementations" as used herein does not necessarily refer to different implementations. For example, the claimed subject matter is intended to include combinations of all or parts of the exemplary embodiments or implementations.

[0318] Generally speaking, terms can be understood at least in part from their usage in context. For example, as used herein, the terms "and", "or", or "and / or" can include multiple meanings, which can depend at least in part on the context in which such terms are used. Typically, "or" if used in connection with a list, such as A, B, or C, is intended to mean A, B, and C, used here in an inclusive sense, as well as A, B, or C, used here in an exclusive sense. Additionally, depending at least in part on the context, the term "one or more" or "at least one" as used herein can be used to describe any feature, structure, or characteristic in the singular sense or can be used to describe features, structures, or characteristics in the plural sense. Similarly, terms such as "a", "an", or "the" can also be understood to convey singular usage or convey plural usage, at least in part depending on the context. Further, the terms "based on" or "determined by" can be understood to not necessarily be intended to convey a set of exclusive factors and can instead allow for the existence of additional factors that are not necessarily explicitly described, again, at least in part depending on the context.

[0319] Only a few examples and implementations are disclosed. Variations, modifications, and enhancements to the described examples and implementations and other implementations can be made based on the disclosed content.

Claims

1. A method for wireless communication, comprising: receiving, by a wireless device, configuration information including handover configuration information from a network device; and initiating, by the wireless device, a handover process based on the configuration information.

2. A method for wireless communication, comprising: sending, by a network device, configuration information including handover configuration information related to a handover process to a wireless device.

3. The method according to claim 1 or 2, wherein, The configuration information includes a time offset parameter, and the time offset parameter indicates a maximum time delay for the wireless device to start message transmission.

4. The method according to claim 1 or 2, wherein The configuration is sent in at least one of the following ways: 1) system information, 2) radio resource control (RRC) message, 3) non-access stratum (NAS message), 4) MAC control element (CE), 5) multicast or broadcast, or 6) paging message.

5. The method according to claim 3, further comprising: determining, by the wireless device, whether the time offset parameter is applicable based on an indication; when it is determined that the time offset parameter is applicable, applying the time offset parameter when initiating the transmission of the message; and when it is determined that the time offset parameter is not applicable, avoiding using the time offset parameter when initiating the transmission of the message.

6. The method according to claim 5, wherein, The indication is at least one of the following: 1) the existence of the time offset parameter, 2) an indication indicating that the time offset is applicable, 3) an enumerated indication, or 5) network type.

7. The method according to claim 5, wherein The indication indicates that the time offset parameter is disabled.

8. The method according to claim 5, wherein The indication is sent in at least one of the following ways: 1) system information, 2) dedicated signaling, 3) multicast or broadcast, or 4) paging message.

9. The method according to claim 3, wherein The message can be the first message of a RACH process, and the RACH process includes at least one RACH attempt, wherein each RACH attempt requires an initial step to initiate the RACH attempt.

10. The method according to claim 9, wherein, Initiating includes generating, by the wireless device, a value between 0 and the time offset parameter, and initiating the RACH process after a duration equal to the value.

11. The method according to claim 10, wherein, The value is generated based on a random method.

12. The method according to claim 10, wherein, Each RACH attempt requires a new value.

13. The method according to claim 10, wherein, Each RACH attempt requires the same value.

14. The method according to claim 10, wherein, When the wireless device determines a change in the RACH process type, the RACH attempt requires a new value.

15. The method according to claim 3, further comprising determining, by the wireless device, whether to apply the time offset to determine the timing of initiating the message transmission based on the capabilities of the wireless device.

16. The method according to claim 3 further comprises: Determining, by the network device, whether to include the time offset in the configuration information of the handover information based on the capabilities of the wireless device.

17. A device for a communication network, comprising: A processor configured to implement the method according to any one of claims 1 to 16.

18. A computer-readable storage medium having code stored thereon, which when executed by a processor causes the processor to implement the method according to any one of claims 1 to 16.

Images