Support of slice-aware ue rach resource configuration selection function and resource prioritization

Abstract

A user equipment, UE, for a wireless communication network can be connected to two or more of a plurality of network slices of the wireless communication network, wherein slice-specific random access channel, RACH, resource configurations are associated with one or more of the plurality of slices. The UE, in response to a first RACH event associated with a first slice, determines whether there is an ongoing RACH procedure triggered by a second RACH event associated with a second slice. In the case of an ongoing RACH procedure, the UE will • prohibit an additional RACH procedure triggered by the first RACH event associated with the first slice, and / or • suspend the additional RACH procedure for a period of time, and / or • stop the ongoing RACH procedure and initiate the additional RACH procedure, and / or • modify the ongoing RACH procedure, and / or • modify the ongoing RACH procedure to initiate the additional RACH procedure.

Description

[0001] manual

[0002] This invention relates to the field of wireless communication systems or networks, and more particularly, to network architectures capable of multiplexing virtualized and independent logical networks, also known as slicing or network slicing, on the same physical network infrastructure. Embodiments relate to methods supporting slicing, such as methods for a user equipment (UE) to select a slice-specific random access channel (RACH) configuration, for example, using a UE RACH resource configuration selection function, and / or methods for a user equipment (UE) to prioritize random access channel (RACH) resources, and / or methods for handling UE-to-base station connections across multiple slices based on RACH events associated with a first slice.

[0003] Typically, different services use a corresponding number of dedicated communication networks, each tailored to the specific service being implemented. Another approach, known as slicing or network slicing, instead of using multiple specially designed networks, may use a single network architecture, such as a wireless communication network, to implement multiple different services. Figure 1 This is a schematic diagram of a system that uses the concept of network slicing to implement different services. The system includes physical resources, such as a radio access network RAN ​​100. RAN 100 may include one or more base stations for communicating with corresponding users. Furthermore, the physical resources may include a core network 102 with, for example, corresponding gateways, mobility management entities (MMEs), and home subscriber servers (HSSs) for connecting to other networks. Multiple slices #1 to #n, also known as network slices, logical networks, or logical subsystems, are used... Figure 1 The physical resources depicted are implemented as follows. For example, the first slice #1 may provide a specific service to one or more users. The second slice #2 may provide ultra-low reliability low latency communication (URLLC) with users or devices. The third slice #3 may provide universal mobile broadband (MBB) service to mobile users. The fourth slice #4 may provide massive machine-type communication (mMTC). The fifth slice #5 may provide medical services. However, additional slices #n may also be provided to implement other services. Slices #1 to #n may be implemented on the network side by corresponding entities of the core network 102, and access to services by one or more users of the wireless communication system involves the radio access network 100.

[0004] Figure 2 is a schematic diagram of an example of a terrestrial wireless network 100, which includes a core network 102 as shown in Figure 2(a) and one or more radio access networks RAN1, RAN2, ... RAN N Figure 2(b) shows the Radio Access Network (RAN). n A schematic diagram of an example, RANN This may include one or more base stations gNB1 to gNB5, each serving a specific area around the base station schematically represented by corresponding cells 1061 to 1065. The base stations are provided to serve users within the cell. One or more base stations may serve users in licensed and / or unlicensed frequency bands. The term base station (BS) refers to gNB in ​​a 5G network, eNB in ​​UMTS / LTE / LTE-A / LTE-APro, or simply BS in other mobile communication standards. Users may be fixed or mobile devices. The wireless communication system may be accessed by mobile or fixed IoT devices connected to the base station or the user. Mobile devices or IoT devices may include physical devices, ground vehicles such as robots or cars, aircraft (such as manned or unmanned aerial vehicles (UAVs), the latter also known as drones), buildings, and other items or devices (with embedded electronics, software, sensors, actuators, etc., and network connectivity enabling these devices to collect and exchange data over existing network infrastructure). Figure 2(b) shows an exemplary view of five cells; however, RAN n It can include more or fewer such cells, RAN nAlternatively, only one base station may be included. Figure 2(b) shows two users, UE1 and UE2, also referred to as user equipment (UE), located in cell 1062 and served by base station gNB2. Another user, UE3, is shown in cell 1064 served by base station gNB4. Arrows 1081, 1082, and 1083 schematically represent uplink / downlink connections used for transmitting data from users UE1, UE2, and UE3 to base stations gNB2 and gNB4, or for transmitting data from base stations gNB2 and gNB4 to users UE1, UE2, and UE3. This can be implemented on licensed or unlicensed frequency bands. Furthermore, Figure 2(b) shows two IoT devices, 1101 and 1102, in cell 1064, which can be fixed or mobile devices. IoT device 1101 accesses the wireless communication system via base station gNB4 to receive and transmit data, as schematically indicated by arrow 1121. IoT device 1102 accesses the wireless communication system via user UE3, as schematically indicated by arrow 1122. The corresponding base stations gNB1 to gNB5 can be connected to the core network 102, for example via the S1 interface, through the corresponding backhaul links 1141 to 1145, which are schematically represented in Figure 2(b) by arrows pointing to the "core". The core network 102 can be connected to one or more external networks. External networks can be the Internet or private networks, such as intranets or any other type of campus network, such as private WiFi or 4G or 5G mobile communication systems. Furthermore, some or all of the corresponding base stations gNB1 to gNB5 can be interconnected via the corresponding backhaul links 1161 to 1165, for example via the S1 or X2 interface or the XN interface in the NR, which are schematically represented in Figure 2(b) by arrows pointing to the "gNBs". The direct link channel allows direct communication between UEs, also known as device-to-device (D2D) communication. The direct link interface in 3GPP is named PC5.

[0005] For data transmission, a physical resource grid can be used. A physical resource grid can include a set of resource elements to which various physical channels and physical signals are mapped. For example, physical channels can include physical downlink, uplink, and direct link shared channels (PDSCH, PUSCH, PSSCH) carrying user-specific data (also referred to as downlink, uplink, and direct link payload data); physical broadcast channels (PBCH) carrying, for example, Master Information Blocks (MIBs) and one or more System Information Blocks (SIBs); and physical downlink, uplink, and direct link control channels (PDCCH, PUCCH, PSSCH) carrying, for example, downlink control information (DCI), uplink control information (UCI), and direct link control information (SCI). Note that the direct link interface may support two-step SCI. This refers to a first control area containing some portions of the SCI, and optionally, a second control area containing a second portion of the control information.

[0006] For the uplink, the physical channel may further include the physical random access channel (PRACH or RACH) used by the UE to access the network after UE synchronization and obtaining MIB and SIB. Physical signals may include reference signals or symbols (RS), synchronization signals, etc. The resource grid may include frames or radio frames with a certain duration in the time domain and a given bandwidth in the frequency domain. Frames may have a certain number of subframes of a predefined length (e.g., 1 ms). Depending on the length of the cyclic prefix (CP), each subframe may include one or more time slots of 12 or 14 OFDM symbols. Frames may also consist of fewer OFDM symbols, for example, when utilizing a shortened transmission time interval (sTTI) or a small time slot / non-time slot-based frame structure that includes only a few OFDM symbols.

[0007] The wireless communication system can be any single-tone or multi-carrier system using frequency division multiplexing, such as orthogonal frequency division multiplexing (OFDM), orthogonal frequency division multiple access (OFDMA), or any other IFFT-based signal with or without CP, such as DFT-s-OFDM. Other waveforms can be used, such as non-orthogonal waveforms for multiple access, such as filter bank multicarrier (FBMC), generalized frequency division multiplexing (GFDM), or universal filtered multicarrier (UFMC). The wireless communication system can operate, for example, according to the LTE-Advanced Pro standard, or 5G, or NR (New Radio) or NR-U (Unlicensed New Radio) standards.

[0008] The wireless network or communication system shown in Figure 2 can be a heterogeneous network with different overlapping networks, such as a macrocell network, each macrocell including macro base stations, such as base stations gNB1 to gNB5; and a small cell base station network (not shown in Figure 2), such as femtocells or picocells. In addition to the terrestrial wireless networks described above, there are also non-terrestrial wireless communication networks (NTNs), including satellite transceivers and / or airborne transceivers such as those used in unmanned aerial vehicle (UAV) systems. Non-terrestrial wireless communication networks or systems can operate in a manner similar to the terrestrial systems described above with reference to Figure 2, for example, according to the LTE-Advanced Pro standard or the 5G or NR (New Radio) standard.

[0009] In mobile communication networks, such as those described with reference to Figure 2 above, such as LTE or 5G / NR networks, there may be UEs that communicate directly with each other via one or more direct link (SL) channels, for example using PC5 / PC3 interfaces, WiFi Direct, or Bluetooth connections. UEs that communicate directly with each other via SL channels can include vehicles communicating directly with other vehicles (V2V communication), vehicles communicating with other entities in the wireless communication network (V2X communication), such as roadside units (RSUs), roadside entities such as traffic lights, traffic signs, or pedestrians. An RSU can have the functions of a BS or a UE, depending on the specific network configuration. Other UEs may not be vehicle-related UEs, but may include any of the devices described above. These devices can also communicate directly with each other using SL channels (D2D communication).

[0010] It should be noted that the information in the above section is only used to enhance the understanding of the background of the invention, and therefore may contain information that does not constitute prior art known to those skilled in the art.

[0011] Improvements may be needed to provide access to one or more slices of the wireless communication network.

[0012] Embodiments of the present invention will now be described in further detail with reference to the accompanying drawings:

[0013] Figure 1 This is a diagram illustrating a system that uses the concept of network slicing to implement different services;

[0014] Figure 2 is a schematic diagram of an example of a wireless communication system;

[0015] Figure 3 This diagram illustrates an example of mapping PRACH resources to network slice IDs;

[0016] Figure 4 The illustration shows an example of a network using network slices with multiple RACH resource configurations and a UE registered at multiple slices;

[0017] Figure 5 This is a schematic diagram of a wireless communication system, which includes a transmitter (such as a base station) and one or more receivers, such as user equipment (UE) capable of operating according to embodiments of the present invention.

[0018] Figure 6 The illustration shows a UE according to an embodiment of a first aspect of the present invention, the UE being connectable to one or more slices and holding a slice-specific RACH resource configuration list, the slice-specific RACH resource configuration defining dedicated RACH resources for the slice;

[0019] Figure 7 The schematic diagram illustrates the corresponding layer at the UE;

[0020] Figure 8 An embodiment for associating access identifiers and / or access categories with slice-specific RACH resource configurations is illustrated;

[0021] Figure 9 An embodiment of the process for handling uplink data arriving at the user plane is illustrated;

[0022] Figure 10 The illustration shows the differences in handling transmissions in the control plane and the user plane according to embodiments of the present invention;

[0023] Figure 11 A base station according to an embodiment of the first aspect of the present invention is illustrated;

[0024] Figure 12(a) illustrates a four-step contention-based random access (CBRA) process;

[0025] Figure 12(b) illustrates a two-step contention-based random access (CBRA) process;

[0026] Figure 12(c) illustrates an embodiment of the process performed at the base station and the UE when downlink data arrives at the base station;

[0027] Figure 13 The diagram illustrates the process of providing data from the base station to the UE in Figure 12(c) from the UE's perspective;

[0028] Figure 14 The illustration depicts a handover process according to an embodiment of the present invention;

[0029] Figure 15 An embodiment of the invention is illustrated, which exchanges information about slice-specific RACH resource configurations as part of a setup process between base stations used during handover.

[0030] Figure 16An embodiment of the invention is illustrated, which updates information about slice-specific RACH resource configuration as part of an update process between base stations used during handover;

[0031] Figure 17 The illustration depicts a conditional handover process according to an embodiment of the present invention;

[0032] Figure 18 An embodiment of the second aspect of the invention is illustrated, allowing UE processing that can be connected to two or more slices to trigger two or more RACH processes simultaneously or during an ongoing RACH process;

[0033] Figure 19 A base station according to an embodiment of the second aspect of the present invention is illustrated;

[0034] Figure 20 An example of a RACH process that prohibits any parallel execution is illustrated;

[0035] Figure 21 An embodiment for a time-shift appended RACH process is illustrated;

[0036] Figure 22 A further embodiment for a time-shifted additional RACH process is illustrated;

[0037] Figure 23 The illustration shows an example of preemption in the RACH process;

[0038] Figure 24 The illustration shows an example of signaling a UE capability, whereby the UE capability indicates the UE's ability to perform the RACH procedure in parallel.

[0039] Figure 25 An embodiment of the third aspect of the invention is illustrated, which allows a UE that can connect to two or more slices to not perform an additional RACH procedure after the UE connects to the base station in response to the initial RACH procedure;

[0040] Figure 26 The illustration shows the traditional MAC header of the MACRAR message modified to identify the slice-specific RACH resource configuration of the uplink used by the UE;

[0041] Figure 27 The diagram shows... Figure 25 The traditional MAC header is extended to identify the slice-specific RACH resource configuration of the uplink used by the UE;

[0042] Figure 28 The illustration shows a modified traditional MAC RAR message to identify the slice-specific RACH resource configuration of the uplink used by the UE;

[0043] Figure 29 The diagram shows... Figure 27 The traditional MAC RAR message, which is extended to identify the slice-specific RACH resource configuration of the uplink used by the UE;

[0044] Figure 30 An embodiment of a wireless communication network including C-RAN implementation is illustrated;

[0045] Figure 31 The illustration shows an example of providing slice-specific RACH resource configurations to one or more DUs via a CU;

[0046] Figure 32 illustrates an embodiment of a slice-specific RACH resource configuration update process, wherein Figure 32(a) illustrates a successful gNB-DU update process, and Figure 32(b) illustrates a failed gNB-DU update.

[0047] Figure 33 The illustration shows an example of the gNB-CU configuration update process; and

[0048] Figure 34 An example of a computer system is illustrated, on which the units or modules and steps of the method described in the present invention can be executed.

[0049] Embodiments of the invention will now be described in more detail with reference to the accompanying drawings, in which the same or similar elements have the same reference numerals assigned to them.

[0050] In the aforementioned wireless communication systems or networks, network slicing is a key function of the core network (such as the 5G core network (5GC)) and the radio access network (such as the 5G radio access network). Network slicing provides end-to-end (E2E) network behavior and is the basis for service level protocol and quality of service (QoS) support. A network slice is a complete logical network connected to a service or tenant, including a core network part (CN part) and a radio access network part (RAN part), and mapped to the same cell or different cells or carrier frequencies. The slicing requirements and principles of the next-generation radio access network (NG-RAN) are defined in reference [1]. A key principle of NG-RAN is resource isolation between slices, which is defined as follows: "NG-RAN supports resource isolation between slices. NG-RAN resource isolation can be achieved through RRM policies and protection mechanisms that can prevent a shortage of shared resources in one slice from breaking the service level protocol of another slice. NG-RAN resources should be able to be fully dedicated to a slice. How NG-RAN supports resource isolation depends on the implementation."

[0051] Slice-based scheduling for PUSCH and PDSCH is enabled through slice-specific scheduling or slice-specific radio bearer configuration. At RAN2#99, a unified random access channel (RACH) resource configuration across all slices was determined because RACH resource segmentation is considered inefficient and increases NR complexity and signaling overhead. The use of slices in 5G networks is considered increasingly common; however, using a unified RACH resource configuration across all slices could lead to RACH resource overload, thus failing to guarantee the QoS required for stable network operation or service. For example, in the case of large-scale IoT deployments, RACH access to an IoT slice would not affect any other slices implemented in the network. Such IoT services could be moved to different carrier frequencies; however, this could also lead to inefficiency. Regarding mission-critical networks, this assumes that such networks operate in a shared network, for example, operated by an existing commercial operator at least at a radio access network site. Such operators may be permitted to use additional frequency bands, such as the 700MHz band, but with the restriction that network access must be provided to mission-critical customers under all circumstances, especially in the event of public emergencies and disasters. Slice-based access control is likely a viable solution most of the time, even if access barriers are a hard rule and require strict user management upon network rollout. Blocking emergency calls from ordinary users in a shared network is not desirable behavior. On the other hand, if it is decided to allow emergency calls on a shared network, RACH resources may no longer be isolated. Therefore, this could hinder access to mission-critical services under RACH overload conditions, which could also be caused by users requesting lower-priority services (e.g., normal mobile broadband MBB services). Furthermore, the possibility of a large number of users requesting emergency calls during a disaster event, potentially overloading existing RACH resources, cannot be ruled out.

[0052] To avoid such problems or concerns, slice-based or slice-specific RACH resource configuration is proposed in reference [3], WO2018127505A1, “Access control for network slices of a wireless communication system”, which is hereby incorporated by reference. Multiple RACH resources can be configured by the gNB and associated with one or more different slices. For example, each slice may have its own RACH resources defined by the associated slice-specific RACH resource configuration, or two or more slices may share RACH resources defined by the slice-specific RACH resource configuration associated with these two or more slices. Configuring different physical time / frequency resources on a slice-by-slice basis allows for complete isolation of Physical Random Access Channel (PRACH) resources, also known as full PRACH resource isolation, and slice-specific RACH resource configuration can also be called slice-specific PRACH resource configuration. Slice-specific RACH resource configurations can be broadcast via RRC signaling, or they can be signaled to the UE using dedicated RRC signaling. Signaling notification of slice-specific RACH resource configurations for individual RACH resources can be accomplished either through an extended System Information Block 1 (SIB-1) or by introducing a new System Information Block for the slice (called an SIB slice, SIBS). Reusing SIB-1 can be beneficial because it is frequently sent and reliable. During mobility, the UE can read the SIB-1 of neighboring cells to understand all the parameters required for cell configuration and handover. However, the message size of SIB-1 should be kept small because it is read during cell selection or reselection, thus increasing UE processing requirements and consequently increasing UE power consumption. When using SIB slices, it can be provided to the UE via dedicated RRC signaling to configure slice-specific RACH resource configurations at the UE.

[0053] Slice-specific RACH resource configurations may include the same or similar parameters as those used in traditional RACH or PRACH configurations. For example, among other things, parameters for the RRC protocol may include the PRACH configuration index, the type and precision of FDM multiplexing, power control parameters and power ramp parameters, repetition parameters, random access window size, the number of preambles configured, preamble segmentation, root sequence, contention resolution timer, etc. Associating individual RACH resources with slices can be achieved in different ways.

[0054] Figure 3 The illustration shows an example of PRACH resource mapping to network slice IDs. Figure 3An example network is provided, which can be configured with N slices, such as hundreds of slices, and can achieve an N:1 slice-to-RACH resource mapping. Currently, NR supports a UE connecting to a maximum of 8 network slices simultaneously. As mentioned above, each slice may be associated with its own slice-specific RACH resource configuration, or many slices may share a slice-specific RACH resource configuration. This may also depend on the center frequency used by a particular slice; for example, slice 1 and slice 2 operating in frequency range (FR) 1 may share a slice-specific RACH configuration, while slice 3 and slice 4 operating in the cmWave or mmWave bands in FR2 may share different slice-specific RACH configurations. Figure 3 The illustration shows an example where the network supports two slice-specific RACH resource configurations, namely PRACH. i and PRACH j PRACH i Associated with network slices having slice IDs 1, 2, and 3, while PRACH j It is associated with the remaining slices having slice IDs 4 to N. Of course, any other mapping can be implemented, and more than two slice-specific RACH resource configurations can be used. This mapping can also be dynamic; for example, during an emergency, the network can be reconfigured to support a new slice-specific RACH resource configuration that can be mapped to one or more slices. The mapping from slice-specific RACH resource configurations to network slices is not unique (e.g., ...). Figure 3 As shown, also known as a one-to-many mapping, in this case, the UE can be configured with slice-specific RACH resources based on one or more of the following: Figure 3 PRACH in i or PRACH j A set of network slices associated with (e.g.) Figure 3 Select the slice to be used from slices 1-3 or slices 4 to N in the given list:

[0055] - Priority, for example, depending on the priority of the UE's network traffic, instead of selecting a delay-tolerant slice, a slice can be selected for fast, low-latency transmission.

[0056] - Randomly select from the possible group of network slices associated with a given slice-specific RACH resource configuration.

[0057] - The load, signal quality, or interference level in the slice.

[0058] In addition to slice-specific RACH resources defined by slice-specific RACH resource configuration, public RACH resources can also be provided. For example, slice selection can be initiated at the UE during the attachment process or when a new session is established. During initial registration, a default network slice can be used before a specific slice is selected by the slice selection function SSF in 5GC. As long as the UE is not connected to a specific slice or is still connected to the default slice, public or default RACH resources may exist, as described in detail in reference [3].

[0059] Therefore, in wireless communication systems or networks using network slice-specific RACH resources, such as RACH resources defined by slice-specific RACH resource configuration, RACH resources can be configured in the UE, for example, along with public RACH resources. Thus, each slice, or several slices, may have its own RACH resources for UEs connecting to that specific slice. The UE reads system information and pre-configures or configures itself via dedicated RRC signaling to learn about the RACH resources associated with its slice. Once the UE has registered a slice, it knows which RACH resource to use in the event of a RACH event.

[0060] Figure 4 The illustration shows an example of a network using network slices with multiple RACH resource configurations and a UE registered at multiple slices. Figure 4 The diagram illustrates three slices: slice #1 for mission-critical communications (MC-communication), slice #2 for enhanced mobile broadband (eMBB) services, and slice #3 for IoT services. Slice #1 has RACH resources for slice #1, defined by a first slice-specific RACH resource configuration associated with slice #1. For example, UE1 represents the aggregate of MC-UEs that only connect to MC slice or slice #1, and UE1 always uses RACH resource A. Figure 4 An example is illustrated in a 10-millisecond radio frame, where RACH resource A is provided in subframes 1 and 7. The eMBB slice (slice #2) and the IoT slice (slice #3) share a second slice-specific RACH resource configuration, which defines RACH resource B provided in subframes 0, 2, 4, 6, and 8.

[0061] In such Figure 4In the system or network shown, there may be multiple UEs, such as UE2 or UE3, which have the ability to connect to more than one slice in parallel. In other words, a UE can connect to multiple slices in parallel, and the current NR specification allows a UE to connect to a maximum of 8 slices simultaneously. For example, UE3 may connect to both the eMBB slice and the IoT slice using the same RACH resource, so UE3 always uses RACH resource B. On the other hand, there may be UE2 that may connect to both slice #1 and slice #2 using different RACH resources, so UE2 must determine whether to use RACH resource A or RACH resource B.

[0062] This invention addresses a problem / defect that the inventors discovered when allowing UEs to connect to multiple slices using different RACH resources in parallel or simultaneously.

[0063] First aspect

[0064] According to a first aspect of the invention, a solution is provided for UEs simultaneously connected to multiple slices using different RACH resources (e.g., Figure 4 The problem with UE2) is that the UE is configured with multiple RACH resources via multiple different slice-specific RACH resource configurations. In this case, if random access is triggered, the UE needs to decide which RACH resource to select. Therefore, according to a first aspect of the invention, in response to a RACH event, a UE that can simultaneously connect to multiple slices and has configured or pre-configured multiple slice-specific RACH resource configurations first determines the slice that triggered the RACH event and / or is associated with the RACH event, and then selects the slice-specific RACH resource configuration associated with the determined slice to perform the RACH procedure. According to an embodiment, a UE-based slice-specific RACH resource configuration selection function (SSF) is provided to support RACH resource isolation by using multiple dedicated RACH resources that can be configured by the gNB or pre-configured in the UE. Based on the configuration or pre-configuration, based on optional additional information provided by the system (such as the gNB), and based on the specific event that triggered the RACH, the UE selects a slice-specific RACH resource configuration, and the UE selects a specific RACH resource for the RACH procedure from this configuration. The specific RACH resource can be selected from a pool of RACH resources indicated in the slice-specific RACH resource configuration.

[0065] Second aspect

[0066] According to a second aspect of the invention, a problem arises in systems that allow UEs to connect to multiple slices in parallel or simultaneously. RACH events can occur simultaneously or at small offsets in different slices, allowing the UE to initiate two or more RACH procedures that are then executed at least partially in parallel. For example, based on the UE state, RACH triggering criteria, and the data type transmitted in the uplink or downlink, the UE can select a slice-specific RACH resource configuration to execute the RACH procedure; for instance, the UE can select parameters defined by the slice-specific RACH resource configuration to execute a slice-specific RACH procedure. However, when connected to multiple slices simultaneously or in parallel, two or more RACH procedures may occur, each associated with a different slice-specific RACH resource configuration, i.e., associated with different network slices. Multiple RACH procedures can be triggered simultaneously or while the initial RACH procedure is still in progress, i.e., not yet completed. In other words, there may be a problem where multiple RACH procedures initiated in response to RACH events in different slices at least partially overlap.

[0067] According to a second aspect of the invention, embodiments are provided for handling situations where multiple RACH procedures are triggered in a manner that is at least partially parallel. In other words, embodiments of the second aspect of the invention address the problem of potentially overlapping RACH procedures initiated by UEs connected to multiple slices in parallel or simultaneously. Embodiments of the second aspect of the invention address the problem of overlapping RACH procedures when multiple RACH procedures are triggered simultaneously or within a short time window and belong to different slices. It should be noted that the embodiments relate to the handling of RACH procedures initiated or triggered by different slices, and the parameters for the respective RACH procedures are defined by different slice-specific RACH resource configurations, such as slice-specific RACH resources. Embodiments of the second aspect do not involve handling multiple RACH procedures on the same RACH resource, which is still possible. For example, multiple RACH resources all originating from the same slice can be handled in a conventional manner using RACH resources specified by parameters of a slice-specific RACH resource configuration associated with the slice.

[0068] Third aspect

[0069] According to a third aspect of the invention, a problem arises in systems that allow UEs to connect to multiple slices in parallel or simultaneously and perform two or more RACH procedures on different slices. While resource isolation may be important for ensuring slice availability and resilience under overload conditions—that is, ensuring that RACH procedures can be performed using slice-specific RACH resources configured for a particular slice and unaffected by what might happen on other slices—radio efficiency and power efficiency must also be considered, and performing multiple or more RACH procedures on different slices may reduce efficiency. The RACH procedure serves three purposes: first, to synchronize the uplink; second, to establish an RRC connection if the RRC slice is not yet RRC-connected; and third, to acquire uplink resources to send messages or packets to the gNB or other network entities. When a UE is already connected to the gNB on a slice, this means that the UE has completed the RACH procedure for that slice, thus achieving uplink synchronization with the gNB and being RRC-connected. The gNB may also be configured with an uplink control channel, such as PUCCH, to provide the UE with a means to send uplink scheduling requests. Therefore, despite the fact that slice-specific RACH resource configurations are provided for different slices, performing another RACH procedure for a further or second slice may be neither radio efficient nor power efficient if the UE is already connected to the gNB on the first slice.

[0070] Embodiments of the third aspect of the invention address the aforementioned problems and provide a UE capable of connecting to two or more of a plurality of network slices. A slice-specific random access channel (RACH) configuration is associated with one or more of the plurality of slices, and the UE is connected, for example, by an RRC connection to a base station of a wireless communication network. In response to a first RACH event associated with the first slice, the UE performs a first RACH procedure using the slice-specific RACH resource configuration associated with the first slice, connecting to the base station. In response to a second event associated with the second slice and resulting in a second RACH procedure, the UE skips the second RACH procedure using the slice-specific RACH resource configuration associated with the second slice. The UE can skip the second RACH procedure associated with the first slice because it is already connected to the base station by the RRC, thus the UE is kept connected by the first slice, which allows data to be sent and received not only by the first slice but also by some or all other slices to which the UE can connect. This aspect is advantageous because it provides improvements in radio efficiency and power efficiency when operating the UE.

[0071] The present invention provides a method for implementing the first, second, and third aspects described above, and embodiments of the present invention can be implemented in... Figure 1Or it can be implemented in the wireless communication system shown in Figure 2, which includes a base station and users (such as mobile terminals or IoT devices). Figure 5 This is a schematic diagram of a wireless communication system including a transmitter 300 (such as a base station) and one or more receivers 302, 304 (such as user equipment UE). The transmitter 300 and receivers 302, 304 can communicate via one or more wireless communication links or channels 306a, 306b, 308 (such as radio links). The transmitter 300 may include one or more antennas ANT. T Alternatively, an antenna array with multiple antenna elements, a signal processor 300a, and a transceiver 300b may be coupled to each other. Receivers 302 and 304 include one or more antennas (ANTs). UE Alternatively, an antenna array with multiple antennas, signal processors 302a, 304a, and transceivers 302b, 304b may be coupled to each other. Base station 300 and UEs 302, 304 may communicate via corresponding first wireless communication links 306a and 306b (e.g., radio links using Uu interfaces), while UEs 302, 304 may communicate with each other via a second wireless communication link 308 (e.g., radio links using PC5 / Direct Link (SL) interfaces). When UEs are not served by the base station or are not connected to the base station, for example, when they are not in an RRC connection state, or more generally, when the base station does not provide SL resource allocation configuration or assistance, UEs may communicate with each other via the Direct Link (SL). Figure 5 Systems or networks Figure 5 One or more UEs 302, 304, and Figure 5 The base station 300 can be operated according to the invention teachings described herein.

[0072] First aspect

[0073] An embodiment of the first aspect of the present invention will now be described.

[0074] ---------------------------------------------------------------------

[0075] UE

[0076] ---------------------------------------------------------------------

[0077] According to a first aspect, the present invention provides a user equipment (UE) for a wireless communication network.

[0078] The UE can connect to two or more of multiple network slices of a wireless communication network, wherein a slice-specific random access channel (RACH) resource configuration is associated with one or more of the multiple slices.

[0079] The UE is configured or pre-configured with slice-specific RACH resource configurations for some or all of multiple slices.

[0080] In response to the RACH event, the UE will

[0081] • Identify the slice that triggered the RACH event and / or is associated with the RACH event.

[0082] • Select the slice-specific RACH resource configuration associated with the determined slice to perform the RACH process.

[0083] According to the embodiment of the first aspect,

[0084] The UE will perform the RACH procedure using the selected slice-specific RACH resource configuration, or

[0085] • The UE forwards the selected slice-specific RACH resource configuration to another device to perform the RACH procedure. The UE is directly connected to the other device, for example via a direct link connection or a different radio access technology (RAT), such as a Bluetooth connection.

[0086] According to an embodiment of the first aspect, the UE is simultaneously connected to at least two of a plurality of network slices.

[0087] According to the embodiment of the first aspect,

[0088] • The UE includes one or more tables to store the slice-specific RACH resource configuration, or

[0089] • Pre-configured slice-specific RACH resource configurations are hard-coded, for example, in the UE, or in storage media (such as a subscriber identification module) inserted into the UE, or in the modem firmware.

[0090] According to the embodiment of the first aspect, the UE will be configured with slice-specific RACH resource configuration in the following manner.

[0091] • Send a signal to notify the RRC system of information, or

[0092] • Dedicated RRC signaling;

[0093] The slice-specific RACH resource configuration can be stored in the RRC layer.

[0094] According to an embodiment of the first aspect, the UE is configured or pre-configured with a default or primary slice-specific RACH resource configuration policy that defines slice-specific RACH resource configuration.

[0095] According to an embodiment of the first aspect, in response to one or more criteria or in response to a request from the UE, the UE receives an updated or supplementary slice-specific RACH resource configuration policy from another entity in the wireless communication network, such as a gNB or a direct link UE or relay, and the UE replaces the current slice-specific RACH resource configuration policy (such as the default slice-specific RACH resource configuration policy) with the updated or supplementary slice-specific RACH resource configuration policy.

[0096] According to an embodiment of the first aspect, in response to a RACH event, the UE will perform a slice-specific RACH resource configuration selection function to determine the slice that triggered the RACH event and select a slice-specific RACH resource configuration associated with the determined slice.

[0097] According to an embodiment of the first aspect, the slice-specific UE RACH resource configuration selection function resides in any protocol layer, such as in the Radio Resource Protocol (RRC) layer or in the Media Access Control (MAC) layer.

[0098] According to an embodiment of the first aspect, the UE will determine the slice that triggered the RACH event, and select a slice-specific RACH resource configuration associated with the determined slice when or after successful admission or access control of the slice.

[0099] According to an embodiment of the first aspect, in order to perform the RACH procedure, the UE performs a general RACH resource selection function to select a specific physical RACH resource from a selected slice-specific RACH resource configuration.

[0100] According to an embodiment of the first aspect, in multiple slices,

[0101] • Slices have their own slice-specific RACH resource configurations, and / or

[0102] • Two or more slices share slice-specific RACH resource configurations.

[0103] According to an embodiment of the first aspect, a slice-specific RACH resource configuration is associated with one or more slices using one or more of the following identifiers:

[0104] • Slice identifiers, such as Network Slice Selection Assistance Information (NSSAI) identifiers, including, for example, Slice / Service Type (SST) and Optional Slice Differentiator (SD).

[0105] • PDU session identifier

[0106] • Data network identifier

[0107] • Data network name

[0108] ·PLMN logo,

[0109] • Access identifier

[0110] • Access categories

[0111] • User equipment type or user equipment category

[0112] QoS flow identifier,

[0113] • Radio carrier identification;

[0114] Logical channel identifier,

[0115] • Multicast or multicast identifier.

[0116] According to an embodiment of the first aspect, in order to determine the slice that triggered the RACH event, a non-access stratum protocol provides the slice identifier to the access stratum, and / or the RRC layer provides the slice identifier to the MAC layer.

[0117] According to the embodiment of the first aspect,

[0118] The UE will use a selected slice-specific RACH resource configuration to perform the RACH procedure for a predefined number of RACH events and / or PRACH transmission attempts, or during a predefined time period following the initial or first RACH event and / or the initial or first PRACH transmission attempt.

[0119] • For a predefined number of RACH events and / or PRACH transmission attempts or during a predefined time period, the UE is not expected to determine the slice that triggers the RACH event and select a slice-specific RACH resource configuration.

[0120] According to an embodiment of the first aspect, the UE includes

[0121] • A counter used to count the number of RACH events and / or PRACH transmission attempts, and / or

[0122] • A timer used to measure the initial or first RACH event and / or a predefined time period following the initial or first PRACH transmission attempt.

[0123] According to the embodiment of the first aspect,

[0124] The UE has configured or pre-configured counter thresholds and / or timer thresholds.

[0125] The counter threshold indicates the number of RACH events and / or PRACH transport attempts for which the selected slice-specific RACH resource configuration is valid.

[0126] The timer threshold setting is a predefined time period during which the selected slice-specific RACH resource configuration is valid.

[0127] According to an embodiment of the first aspect, the pre-configured counter threshold and / or timer threshold can be hard-coded, for example, in the UE, or in a storage medium (such as a subscriber identification module) inserted into the UE, or in the modem firmware.

[0128] According to the embodiment of the first aspect, in the event that the RACH procedure on the RACH resource fails, the UE will

[0129] • Repeat the RACH process using configured or pre-configured standby RACH resources, or

[0130] • Repeat the RACH process for the latest RACH resource configuration that was successfully configured using the RACH process, or

[0131] • Signal the RACH failure event to another UE via SL.

[0132] According to an embodiment of the first aspect, the RACH event includes one or more of the following:

[0133] • Radio link failure,

[0134] • Beam failure

[0135] Uplink data arrives in the user plane.

[0136] • Uplink data arrives in the control plane.

[0137] • Scheduling request or scheduling request failure

[0138] Downlink data arrives, at which point the UE is no longer in uplink synchronization state.

[0139] • Handover process,

[0140] • A conditional handover process

[0141] Initial visit,

[0142] • RRC connection re-established

[0143] • Response to paging

[0144] • Transition from RRC idle state

[0145] • Transition from RRC inactive state

[0146] • Triggering events received via the direct link SL, such as SCI or RRC signaling received via SL.

[0147] According to an embodiment of the first aspect, in the absence of an ongoing uplink transmission on the PUSCH resource and / or a configured scheduling request (SR) on the PUCCH resource, for an uplink transmission of a data message from an application or service performed by the UE, the UE will perform a RACH procedure using the physical RACH resource configured with the RACH resource associated with the slice that generated the user data, wherein the slice is identified by one or more of the following: slice identifier, PDU session identifier, data network identifier, data network name, PLMN identifier, access identifier, access category, QoS flow identifier, radio bearer identifier, or logical channel identifier.

[0148] According to an embodiment of the first aspect, in response to the failure of a PUCCH scheduling request for resources to be used for uplink transmission on the PUSCH, for uplink transmission of data messages from an application or service performed by the UE, the UE will perform a RACH procedure using physical RACH resources configured with RACH resources associated with the slice that generated the user data, wherein the slice is identified by one or more of the following: slice identifier, PDU session identifier, data network identifier, data network name, PLMN identifier, access identifier, access category, QoS flow identifier, radio bearer identifier, or logical channel identifier.

[0149] According to the embodiment of the first aspect,

[0150] • An application or service executed by the UE will provide data packets for uplink user data requests.

[0151] o to the uplink data queue, along with the identifier of the slice from which the data packet originated, or

[0152] o to the uplink data queue associated with the slice from which the packet originated.

[0153] In response to determining that no uplink data transmission is in progress on the PUSCH and there is no scheduling request on the pre-configured PUCCH, the MAC layer will select a slice-specific RACH resource configuration associated with the slice or uplink data queue indicated by the identifier, and

[0154] • Perform the RACH process using the physical RACH resources configured with the selected slice-specific RACH resources.

[0155] According to an embodiment of the first aspect, in the absence of a slice-specific RACH resource configuration associated with the slice from which the data packet originates, the UE will use the following physical RACH resources.

[0156] • Configured or pre-configured standby RACH resources, or

[0157] • Latest RACH resource configuration for a successful RACH process.

[0158] According to the embodiment of the first aspect, in the case that there is no ongoing uplink transmission on the PUSCH resource and / or no configured scheduling request (SR) on the PUCCH resource, the UE will perform the RACH procedure for uplink transmission of control messages using the following methods.

[0159] • When the control message includes information identifying the slice from which the uplink control data request originated, the physical RACH resources configured with slice-specific RACH resources associated with the slice that generated the uplink control data request, or

[0160] • The physical RACH resources of the primary RACH resource configuration, wherein one or more slice-specific RACH resource configurations are configured as the default or primary RACH resource configuration, for example, by the wireless communication system.

[0161] According to the embodiment of the first aspect, in order to receive data, the UE will

[0162] • Receive control messages from the sending network entity (such as a gNB or a directly linked UE), such as DCI in PDCCH or SCI in PSCCH, which include RACH requests to initiate RACH procedures. These control messages include...

[0163] o Identifier of the slice from which the data originates, such as the RACH resource configuration index

[0164] o An indication of a slice-specific RACH resource configuration, or

[0165] o Existing slice-specific RACH resource configurations for specific physical RACH resources, and

[0166] • Perform the RACH process using the physical RACH resource configured as indicated in the received control message, which is specific to the slice.

[0167] According to an embodiment of the first aspect, a slice-specific RACH resource configuration is selected from a subset of available slice-specific RACH resource configurations, for example, by one or more bits in a control message.

[0168] According to an embodiment of the first aspect, during a handover process or a conditional handover process from a source base station to a target base station, the UE will receive one or more slice-specific RACH resource configurations and / or one or more physical RACH resources from the slice-specific RACH resource configurations provided by the target base station via RRC signaling from the source base station, for use when connecting to the target base station using the RACH procedure.

[0169] According to the embodiment of the first aspect,

[0170] • Within a specific area, such as the Tracking Area (TA), the base station provides the same slice-specific RACH resource configuration for one or more slices, and

[0171] • During a handover process or conditional handover process from a source base station to a target base station within a specific area, the UE will receive an indication of one or more slice-specific RACH resource configurations and / or one or more physical RACH resources within a slice-specific RACH resource configuration from the target base station via RRC signaling from the source base station, for use when connecting to the target base station using the RACH procedure.

[0172] According to an embodiment of the first aspect, in the case where the RACH event includes re-establishing RRC, the UE will use a predefined RACH resource configuration that is not associated with a specific slice, such as the default or primary RACH resource configuration or a RACH resource configuration in ascending order of priority.

[0173] According to an embodiment of the first aspect, in the event that the RACH event includes one of the following: radio link failure, beam failure, response to paging, transition from IDLE state, or transition from RRC INACTIVE state, the UE will

[0174] • Resources configured using specific RACH resources pre-configured or configured by the UE, for example, via gNB or UE, or

[0175] • Resources that have been successfully configured using the latest RACH resource configuration through the RACH process.

[0176] According to the embodiment of the first aspect,

[0177] In response to a first RACH event associated with the first slice, the UE determines whether there is an ongoing RACH procedure triggered by a second RACH event associated with the second slice, and

[0178] In the case of an ongoing RACH procedure, the UE will

[0179] • Prohibit additional RACH processes triggered by the first RACH event associated with the first slice, and / or

[0180] • Suspend the additional RACH process for a period of time, and / or

[0181] • Stop the ongoing RACH process and start an additional RACH process, and / or

[0182] • Modify the ongoing RACH process, and / or

[0183] • Modify the ongoing RACH process to initiate an additional RACH process.

[0184] According to an embodiment of the first aspect, the UE is configured or pre-configured to support two or more parallel RACH processes, which are associated with different slices.

[0185] ---------------------------------------------------------------------

[0186] BS

[0187] ---------------------------------------------------------------------

[0188] According to a first aspect, the present invention provides a base station (BS) for a wireless communication network.

[0189] The BS will support one or more slices of a wireless communication network, with slice-specific random access channel (RACH) configurations associated with one or more slices.

[0190] The BS will use slice-specific RACH resource configurations for some or all of the multiple slices that the UE can connect to to configure one or more user equipments (UEs).

[0191] According to the embodiment of the first aspect, in response to receiving a RACH message, such as a RACH preamble, from the UE, the BS will

[0192] • Identify the slice that triggered the RACH message and / or is associated with the RACH message, and

[0193] • Perform one or more of the following:

[0194] o Respond to RACH messages based on slice-specific functions

[0195] o Creates an event with slice-specific parameters.

[0196] o Prioritize RACH responses in ascending / descending order based on associated slices

[0197] o Select resources for the response based on the slice.

[0198] According to an embodiment of the first aspect, the BS connects to a core network that supports one or more of multiple network slices, and the core network is able to register one or more user equipments (UEs) with the multiple network slices.

[0199] According to an embodiment of the first aspect, in response to receiving data to be transmitted to a specific UE, the BS will

[0200] • Identify the slice that triggers data transfer and / or is associated with data transfer.

[0201] • Select the slice-specific RACH resource configuration associated with the selected slice, and

[0202] • For example, the RACH procedure can be initiated at a specific UE using a selected slice-specific RACH resource configuration via the DCI in the PDCCH or the SCI in the PSCCH.

[0203] According to the embodiment of the first aspect, when it is determined that a particular UE is no longer in an uplink synchronization state, the BS will

[0204] • Determine the slice from which the data packet originates, and

[0205] • Provide control messages to the UE, such as DCI in PDCCH or SCI in PSCCH, which include RACH requests to initiate RACH procedures in the UE. These control messages include...

[0206] The identifier of the slice from which the data originates, such as the RACH resource configuration index, or

[0207] o An indication of a slice-specific RACH resource configuration, or

[0208] o A specific RACH resource in an existing slice-specific RACH resource configuration.

[0209] According to an embodiment of the first aspect, a slice-specific RACH resource configuration is selected from a subset of available slice-specific RACH resource configurations, for example, by one or more bits in a control message.

[0210] According to an embodiment of the first aspect, during a handover process or conditional handover process from a source base station to a target base station, the BS is the target base station and sends one or more slice-specific RACH resource configurations provided by the target base station to the source base station for use by the UE when connecting to the target base station using the RACH procedure.

[0211] According to an embodiment of the first aspect, during a handover process or a conditional handover process from a source base station to a target base station, the BS is the source base station, receives from the target base station one or more slice-specific RACH resource configurations provided by the target base station for the UE to use when connecting to the target base station using the RACH procedure, and sends the received one or more slice-specific RACH resource configurations to the UE.

[0212] According to the embodiment of the first aspect,

[0213] In the case of unconditional handover, one or more slice-specific RACH resource configurations are signaled during the handover request signaling, and

[0214] • In the case of conditional handover, one or more slice-specific RACH resource configurations are signaled during the conditional handover configuration signaling.

[0215] According to an embodiment of the first aspect, the BS stores slice-specific RACH resource configurations for some or all of a plurality of slices, and sends its stored slice-specific RACH resource configurations to one or more neighboring base stations, and / or receives and stores slice-specific RACH resource configurations of one or more neighboring base stations.

[0216] According to an embodiment of the first aspect, the BS will send and / or receive slice-specific RACH resource configurations via an inter-BS interface, such as an Xn interface, an X2 interface, an S1-MME interface, or an NG-C interface.

[0217] According to an embodiment of the first aspect, the BS will send and / or receive slice-specific RACH resource configurations during the BS setup or update process.

[0218] According to an embodiment of the first aspect, the BS stores slice-specific RACH resource configurations received from one or more neighboring BSs in a list of neighboring cells.

[0219] According to an embodiment of the first aspect, during a handover process from a source base station to a target base station or a conditional handover process, the BS is the source base station and sends one or more of the stored slice-specific RACH resource configurations of neighboring base stations that are the target base station to the UE.

[0220] According to the embodiment of the first aspect,

[0221] • Within a specific area, such as the Tracking Area (TA), the base station provides the same slice-specific RACH resource configuration for one or more slices, and

[0222] • During a handover or conditional handover process from the source base station to the target base station within a specific area, the BS is the target base station and sends an indication of one or more slice-specific RACH resource configurations for the UE to use when connecting to the target base station via the source base station.

[0223] According to an embodiment of the first aspect, the BS will configure one or more user equipments (UEs) to enable or disable the parallel RACH process.

[0224] ---------------------------------------------------------------------

[0225] system

[0226] ---------------------------------------------------------------------

[0227] According to a first aspect, the present invention provides a wireless communication system comprising one or more user equipment (UE) of the present invention and / or one or more base stations (BS) of the present invention.

[0228] ---------------------------------------------------------------------

[0229] method

[0230] ---------------------------------------------------------------------

[0231] According to a first aspect, the present invention provides a method for operating a user equipment (UE) of a wireless communication network, wherein the UE can be connected to two or more of a plurality of network slices of the wireless communication network, wherein a slice-specific random access channel (RACH) resource configuration is associated with one or more of the plurality of slices, and wherein the UE is configured or pre-configured with some or all of the slice-specific RACH resource configurations for the plurality of slices, the method comprising:

[0232] In response to a RACH event, determine the slice that triggered the RACH event and / or is associated with the RACH event, and

[0233] Select the slice-specific RACH resource configuration associated with the selected slice for performing the RACH process.

[0234] According to a first aspect, the present invention provides a method for operating a base station (BS) of a wireless communication network, wherein the BS supports one or more of a plurality of slices of the wireless communication network, wherein a slice-specific random access channel (RACH) configuration is associated with one or more of the plurality of slices, the method comprising:

[0235] Configure one or more user equipments (UEs) using slice-specific RACH resource configurations for some or all of the multiple slices that the UE can connect to.

[0236] Figure 6 The illustration depicts an embodiment of a UE that can connect to one or more slices and maintains a list of slice-specific RACH resource configurations that define dedicated RACH resources for the slice. In the event of a RACH event, the UE is able to determine the slice associated with the RACH event and select a slice-specific RACH resource configuration from the list to select the dedicated RACH resources associated with the slice. More specifically, Figure 6 The reference is illustrated schematically. Figure 4 The network described uses network slicing. UE 400 is connected to slice #1 and slice #2, as schematically shown by double-headed arrows #1 and #2. UE 400 includes a list 402 of slice-specific RACH resource configurations 402a, 402b associated with slice #1, slice #2, and slice #3. The slice-specific RACH resource configurations include or define RACH resource A and RACH resource B, among other parameters, from which UE 400 can select the RACH resource for responding to a RACH event in slice #1 or slice #2. In the case of a RACH event, the UE, for example via processor 404, is able to detect the slice that triggered the RACH event and / or is associated with the RACH event, as shown at 404a, and is able to select the slice-specific RACH resource configuration associated with the determined slice for performing the RACH procedure, for example, from table or list 402.

[0237] exist Figure 6 In one embodiment, the UE is connected to two slices; however, the invention is not limited to such an embodiment, and the UE may be connected to more than two slices in parallel.

[0238] exist Figure 6The diagram illustrates an example where a RACH event occurs in slice #2 within subframe 1. According to an embodiment of the invention, in response to a RACH event, the UE determines that the event originates in slice #2 and selects a slice-specific RACH resource configuration 402b from list 402 to perform a RACH procedure in response to the RACH event. For example, the UE can select a RACH resource defined by the slice-specific RACH resource configuration 402b for performing the RACH procedure, such as RACH resource B provided in subframe 2 or subframe 4.

[0239] According to one embodiment, the UE can use a selected slice-specific RACH resource configuration to perform the RACH procedure itself. According to another embodiment, the UE can forward the selected slice-specific RACH resource configuration to another device to perform the RACH procedure. For example, the UE can be a wearable computer, such as a smartwatch, which is directly connected to another entity, such as a mobile phone, for example, via a direct link connection or a different Radio Access Technology (RAT), such as Bluetooth, Wi-Fi, Zigbee, or any other IEEE or proprietary wireless communication standard. For example, the smartwatch may not be able to directly connect to the network and therefore cannot perform the RACH procedure to obtain UL resources to transmit data in a slice. In this case, the smartwatch can forward the selected slice-specific RACH resource configuration or RACH triggering event to the connected mobile phone. The RACH procedure can then be performed by the mobile phone, which has, for example, more available battery power, and the obtained UL resources can be signaled to the wearable computer, which can then attempt to transmit its data using the UL resources.

[0240] According to embodiments, UE 400 may include one or more tables 402 that store slice-specific RACH resource configurations 402a and 402b. For example, when connected to a network implementing multiple slices, the UE may have these slice-specific RACH resource configurations configured, for example, via a gNB. According to other embodiments, the UE may have slice-specific RACH resource configurations pre-configured, for example, by hardcoding them into the UE, or by inserting a storage medium into the UE storing the slice-specific RACH resource configurations. The storage medium may include a Subscriber Identity Module (SIM) or an Electronic SIM (eSIM). According to other embodiments, slice-specific RACH resource configurations may be provided in the UE's software or firmware (such as modem firmware). For example, the software or modem firmware of a cellular modem within the UE, such as the firmware of an NR modem, may provide the UE with slice-specific RACH resource configurations. Slice-specific RACH resource configurations may be updated as needed, for example, when a modem user's contract changes, or when the network configuration changes and supports more or other features.

[0241] According to embodiments, when a slice-specific RACH resource configuration is used, it can be configured via system information or dedicated RRC signaling. For example, a UE can configure a slice-specific RACH resource configuration via system information signaling or dedicated RRC signaling. The configured slice-specific RACH resource configuration may be stored in the RRC layer. That is, after receiving signaling via system information or dedicated RRC signaling, the information may be saved or stored in the RRC layer.

[0242] Therefore, although the RACH resource selection function is known in existing systems for general RACH resource selection, embodiments of the first aspect of the present invention provide a method that allows a UE to select a slice-specific RACH resource configuration in a system that provides the UE with the possibility of connecting to multiple slices in parallel or simultaneously. These slices can use dedicated or isolated RACH resources specified by different slice-specific RACH resource configurations. It should be noted that in existing systems, for example, see reference [5], there is only one or a general RACH resource configuration, and the RACH resource configuration specifies the RACH resources that the UE may use to perform the RACH procedure. The general RACH resource configuration typically includes multiple RACH resources distributed over time and / or frequency, such as Figure 4 and Figure 6 As shown. For example, there can be two RACH opportunities in a time-distributed radio frame, or two RACH opportunities in a frequency-distributed time slot. The number of RACH resources can be adapted to the RACH load, and during random access, the UE selects specific resources and specific preambles from a selected slice-specific RACH resource configuration for transmitting RACH in the uplink. Different sets of PRACH parameters can be selected from a general RACH resource configuration based on certain events, such as RACH triggering events or service requests. However, there is only a single general RACH resource configuration specifying a physical PRACH resource, which typically includes multiple time-frequency resources available for selection.

[0243] In contrast to such existing systems, embodiments of the first aspect of the invention provide multiple slice-specific RACH resource configurations, meaning the UE can select from different RACH resource configurations, each including multiple time-frequency resources available for selection. According to the first aspect of the invention, once a slice-specific RACH resource configuration is selected, the UE can apply different PRACH or RACH parameters specified by the selected configuration for random access transmissions.

[0244] Therefore, according to an embodiment of the first aspect of the invention, firstly, the UE selects a slice-related RACH resource configuration from multiple or more slice-specific RACH resource configurations (also referred to as dedicated RACH resource configurations – compared to general RACH resource configurations). For example, a slice-specific RACH resource configuration selection function can be used. Then, the UE can run a general RACH resource selection function in the selected slice-specific RACH resource configuration. In the following description, reference is made to the slice-specific RACH resource configuration selection function without confusing it with the equally used general RACH resource selection function, which, once a slice-specific RACH resource configuration is selected, allows the selection of the RACH resources to be actually used.

[0245] For example, when considering Figure 6 According to a first aspect of the invention, slice-specific RACH resource configurations 402a and 402b are configured or pre-configured in UE 400. The first slice-specific RACH resource configuration 402a includes or specifies RACH resource A for slice #1, such as... Figure 4 and Figure 6 As shown, the second slice-specific RACH resource configuration 402b includes or specifies RACH resources B for slices #2 and #3. According to an embodiment of the first aspect of the invention, firstly, a slice-specific RACH resource configuration selection function is performed to select, in configuration 402, a slice-specific RACH resource configuration for the slice from which the RACH event originates. Figure 6 This means that the slice-specific RACH resource configuration selection function selects the second slice-specific RACH resource configuration 402b associated with slice #2, because a RACH event was found in this slice. Following the slice-specific RACH resource configuration selection function, the general RACH resource selection function is used to select the actual resource for the UE to use in the RACH procedure from the available resources defined by the slice-specific RACH resource configuration 402b. Figure 6 In the embodiments, this means that after generating the slice-specific RACH resource configuration selection function of configuration 402b, the UE can use the known RACH resource selection function to select from RACH resource B, such as the resource provided in subframe 6 for performing or initiating a RACH procedure, for example, the resource for sending the first message of the RACH procedure to the gNB.

[0246] According to an embodiment, the slice-specific UE RACH resource configuration selection function provided by the embodiment of the first aspect of the present invention can be located in any protocol layer, preferably in the Radio Resource Protocol (RRC) layer that controls overall resources or the Media Access Control (MAC) layer that controls random access procedures. Figure 7The corresponding layer at UE 400 is schematically illustrated, and in a preferred embodiment, the slice-specific RACH resource configuration selection function is located at the MAC layer. This function can be implemented as a separate function or integrated into a general RACH resource selection function. In the integrated case, the general RACH resource configuration selection function is first executed to select a slice-specific RACH resource configuration, and then the general RACH resource selection function is executed again to select a specific RACH resource for performing the RACH procedure from the selected slice-specific RACH resource configuration.

[0247] RACH resource configuration policies can be stored in the core network (e.g., 5GC), and UEs can configure or pre-configure a default policy, which can be updated based on a criterion or at the request of the UE. For example, a UE can receive updated or supplemental slice-specific RACH resource configuration policies from another entity in the wireless communication network, such as a gNB, a directly linked UE, a relay, or an entity in the 5GC (5G core network), for example, through Access and Mobility Management Functions (AMF). The UE replaces its current slice-specific RACH resource configuration policy (such as the default slice-specific RACH resource configuration policy) with the updated or supplemental slice-specific RACH resource configuration policy. The default policy is likely the simplest type of network configuration applicable to all UEs authorized to perform random access to a given network. Updates may occur if the network is upgraded to support new or different network slices; for example, if the initial network only supported eMBB slices, and the upgraded network supports eMBB as well as URLLC services or slices. Upgrades may also occur on the UE side, for example, the UE owner purchases a license for a URLLC slice in order to be able to use the URLLC service, and the UE retrieves the updated RACH policy from a server in the core network (CN).

[0248] According to an embodiment, the slice-specific UE RACH resource configuration selection function can rely on information provided by the non-access stratum (NAS). The NAS mobility management (NAS-MM) function can communicate with the access mobility management function in the 5G core network (5GC). The NAS-session management (NAS-SM) function can communicate with the session management function in the 5GC. To enable PDU transmission in a network slice, as described in reference [2], if there is no established PDU session sufficient for PDU transmission, the UE can request the establishment of a PDU session for the data network (DN) in the network slice, which is associated with a single network slice selection assistance information (S-NSSAI) and data network name (DNN). The UE can also include the requested network slice selection assistance information (NSSAI), which includes the S-NSSAI corresponding to the slice that the UE intends to register or connect to in the NAS registration request message. For transmission, the NAS message can be passed to the RRC protocol and processed along the entire protocol stack using the signal radio bearer. All protocols below the NAS layer are called the access layer. Some side information is passed from the NAS layer to the layer below the access layer.

[0249] Association between network slices and slice-specific RACH resource configurations

[0250] The implementation example achieves a network including slice-specific RACH resource configurations by associating slice-specific UE RACH resource configurations with network slices.

[0251] UE association with slice-specific RACH resource configuration

[0252] According to an embodiment, the gNB can specifically assign the UE to one or more slice-specific RACH resource configurations. Each slice-specific RACH resource configuration may have an index, and the gNB can inform the UE which configuration to use. This association can be signaled to the UE, for example, via dedicated RRC signaling. The UE can store the association in its buffer, and once RACH is triggered, the UE can look up the information in the buffer and select the appropriate slice-specific RACH resource configuration, from which the actual RACH resource for performing the RACH procedure can be selected. The advantage of this embodiment is the explicit association between the UE and the slice-specific RACH resource configuration, as well as the simple RACH resource configuration selection function. Since the function is performed during each random access, it reduces UE processing and may limit the additional latency introduced by performing the function.

[0253] The slice or PDU session identifier is directly associated with the slice-specific RACH resource configuration.

[0254] According to a further embodiment, the slice identifier may be directly or indirectly linked to a slice-specific RACH resource configuration configured by the gNB. The slice identifier may be the Network Slice Selection Assistance Information (NSSAI) identifier described in reference [4] or any identifier derived therefrom. The NSSAI includes a mandatory Slice / Service Type (SST) and an optional Slice Differentiator (ST). According to other embodiments, a slice may be identified by a PDU session identifier, data network, data network name, PLMN identifier, access identifier, access category, user equipment type or user equipment class, QoS flow identifier, radio bearer identifier, logical channel identifier, or multicast / multicast identifier.

[0255] During a RACH attempt, i.e., when in response to a RACH event, the UE can perform an additional slice-specific RACH resource configuration selection procedure to assess which slice the random access is associated with and select the correct slice-specific RACH resource configuration.

[0256] According to an embodiment, the selected slice-specific RACH resource configuration may be considered valid for a certain period of time, so that after the first RACH attempt, the UE can assume that the initially selected slice-specific RACH resource configuration remains valid for a certain period of time. According to other embodiments, the UE may assume that the selected slice-specific RACH resource configuration is valid for a certain number of RACH attempts after the first RACH attempt. According to an embodiment, the UE may include a counter for counting the number of RACH events and / or PRACH transmission attempts, and / or a timer for measuring the initial or first RACH event and / or the predetermined period of time after the initial or first PRACH transmission attempt. According to an embodiment, the UE may configure or pre-configure counter thresholds and / or timer thresholds, which respectively indicate the number of RACH events and / or PRACH transmission attempts for which the selected slice-specific RACH resource configuration is valid, and the predetermined period of time for which the selected slice-specific RACH resource configuration is valid. The pre-configured counter thresholds or timer thresholds may be hard-coded in the UE or obtained from the UE's storage medium or modem firmware, as described above regarding the pre-configuration of slice-specific RACH resource configurations. To support this functionality on the UE side, according to embodiments, upper layers, such as NAS protocols, can provide additional information to lower layers, such as the RRC layer. This means that for each access attempt, each message, service, or registration request, the UE-side non-access stratum protocol can provide the relevant slice identifier to the access layer. The RRC protocol can further pass the information down to lower layers, such as the MAC layer.

[0257] For example, during the RRC connection establishment process, the NAS protocol can provide the slice identifier to the RRC protocol, which can store this information for use after the slice-specific RACH resource configuration selection function is executed, or forward this information to the MAC layer if this function is executed at the MAC layer as part of the RACH procedure. If this function is executed at the RRC layer, the RRC layer informs the MAC layer which slice-specific RACH resource configuration will be used for random access. A UE connected to a slice configured to use a separate RACH resource may have to read the new SIB slice before performing random access.

[0258] Association of access identifier and / or access category with slice-specific RACH resource configuration

[0259] According to an embodiment of the first aspect of the invention, the UE can determine the slice that triggered the RACH event and select a slice-specific RACH resource configuration associated with the determined slice when or after successful admission or access control of the slice. The slice-specific RACH resource configuration selection function can be performed together with admission and access control. This can be advantageous because access control functions can be performed in a slice-specific manner. Before performing an access attempt, the NAS layer may interact with the access layer to evaluate whether access to a specific slice is permitted. The slice-specific RACH resource configuration may have already been selected as part of this process, or it may be selected only after successful access control.

[0260] According to an embodiment, the NAS protocol can define that a UE initiating an access attempt determines one or more access identifiers from a set of standardized access identifiers and an access category from a set of standardized and / or operator-defined access categories. For example, access identifier #2 is defined for a UE configured for mission-critical services. Other access identifiers can be linked to access categories to implement access barriers.

[0261] Access categories are standardized in the NAS protocol, as shown in reference [2]. For example, access category #2 is defined for emergency services. Other examples are MMTel voice or MMTel video. Access categories can also be defined by the operator and are valid in the PLMN. The definition can be signaled to the UE via the NAS protocol. For example, the access category can be set to the data network name, operating system or operating system application identifier, or a PLMN-specific slice based on the slice identifier S-NSSAI.

[0262] The advantage of providing an access identifier / access category is that its definition can be more flexible than that of a slice identifier only. Implementation examples allow the network to flexibly map RACH resources to services, access types, slices, etc. Furthermore, an access identifier / access category is generated at the NAS layer for each access attempt, and this information is passed to the access layer during access control. Figure 8 The illustration depicts an embodiment for associating access identifiers and / or access categories with slice-specific RACH resource configurations. For example... Figure 8 As shown, first, the non-access layer derives an access category for the access attempt, as shown in "1". Then, as shown in "2", authorization is requested based on the access category, access identifier, and root cause. This is passed from the NAS layer to the access layer, where, as shown in "3", a barrier check is performed on the access category and access identifier, for example, against a barrier timer. After the barrier check at "3", as shown in "4", the access layer passes the result of the authorization process to the non-access layer to indicate whether the access is authorized or unauthorized, so that at "5", the non-access layer can continue access or block access. In the case of this access, the embodiment described above for selecting slice-specific RACH resource configuration can be used.

[0263] Mapping access categories, access identifiers, and root causes to slice-specific RACH resource configurations provides a flexible approach that works alongside signaling overhead, as a mapping table needs to be configured in the gNB and signaled to the UE. According to embodiments, the mapping table can be pre-configured or partially pre-configured in the UE, for example, for emergency systems, to specify default behavior in cases involving minimal or no signaling. Information can also be stored within the UE as it moves through the network, and updates are only required for differences or increments by signaling to the corresponding UE.

[0264] In the case of network sharing, the association with the PLMN identifier

[0265] According to a further embodiment, the first aspect of the invention can be extended to support PLMN sharing using different PLMN-specific RACH resources. Network slices can be defined in a PLMN, and network sharing can be performed between different PLMNs. In the case of network sharing, each PLMN sharing the NG-RAN defines and supports its PLMN-specific slice set supported by the public NG-RAN. In the case of shared NR access, the system information broadcast in the shared cell indicates the Tracking Area Code (TAC) and the cell identifier for each subset of up to 12 PLMNs, and NR access only provides the TAC and one cell identifier for each cell of each PLMN, as described in reference [1]. Typically, all networks use only the same RACH resources. According to an embodiment of the invention, slice-specific RACH resource configuration can be PLMN-specific and can be signaled, for example, via SIB slices. In this case, the slice-specific UE RACH resource configuration selection function can select the configuration associated with the PLMN when multiple RACH resources are configured for each PLMN, or select a specific slice of the PLMN. Since the UE is connected to different data networks and the gNB knows the association between the UE and the PLMN, the above principle can be maintained.

[0266] It should be noted that the present invention is not limited to the associations described above; they are merely examples, and any association can be used, such as any combination of the associations described above.

[0267] RACH process failed

[0268] Embodiments of the first aspect of the invention handle RACH procedure failures after selecting a slice-specific RACH resource configuration and choosing the actual RACH resource for the RACH procedure from the slice-specific configuration. In the event of a failure to access a RACH resource selected from the determined slice-specific RACH resource configuration, the UE may repeatedly perform random access using a RACH resource from a configured or pre-configured alternative RACH resource configuration, such as a RACH resource provided by an SIB slice. According to other embodiments, the UE may also remember the last RACH resource it has been using and can continue using that resource until a different RACH resource is configured.

[0269] In the event of radio link failure, beam failure, or RRC re-establishment, the UE can use a separate RACH resource previously configured by the gNB. Furthermore, in the event of radio link failure, beam failure, or RRC re-establishment, the UE can reread the SIB slice before performing the random access procedure.

[0270] According to an embodiment, a UE can signal a RACH failure event to another UE, for example, using a direct link communication. Signaling a RACH failure event to another UE via a direct link is advantageous because another UE, such as a group leader UE or a smartphone UE, might take over communication with the network. For example, considering a smartwatch failing to connect and transmit its data, the smartwatch can forward the data to its connected smartphone UE and signal the RACH failure event so that the smartphone UE can perform a PRACH attempt, which may succeed due to the smartphone's higher power level. After the smartphone UE successfully performs the RACH procedure, the data can be sent or relayed to the network.

[0271] RACH events that lead to the selection of slice-specific RACH resource configurations

[0272] According to the embodiments, as described above, the UE can connect to multiple slices simultaneously, and in response to a certain RACH event, the UE determines the slice from which the RACH event originates so as to be able to select the correct slice-specific RACH resource configuration for performing a RACH attempt or RACH procedure.

[0273] According to embodiments, RACH events include one or more of the following: radio link failure, beam failure, uplink data arriving at the user plane, uplink data arriving at the control plane, scheduling request or scheduling request failure, downlink data arrival, where the UE may no longer be in uplink synchronization state, handover process, conditional handover process, initial access, RRC connection re-establishment, response to paging, transition from RRC idle state, transition from RRC inactive state, or triggering events received via a direct link, such as SCI or RRC signaling on the direct link. A direct link triggering event may be one of the following:

[0274] • Changes in QoS requirements stemming from or due to variations in data packets from a given application. For example, if more UEs require high priority, logical channels (LCHs) on direct links can be mapped to resource pools with available or necessary resources to accommodate higher-priority transmissions.

[0275] The current RACH resource configuration is insufficient. For example, in the event of a sudden accumulation of vehicles due to accidents or traffic jams, the resource pool may experience very high congestion levels, as measured by CBR.

[0276] • User dynamics, for example, if more UEs perform unicast or multicast transmissions that require PSFCH-enabled resource pools, instead of broadcast transmissions without PSFCH configured.

[0277] In the following description, embodiments of the first aspect of the invention are described in more detail with reference to different events that trigger the random access process, and the slice-specific RACH resource configuration selection function may work differently depending on the RACH triggering event.

[0278] Uplink data reaches the user plane

[0279] Assuming the UE is registered or connected to two slices, as referenced above. Figure 6 In the described embodiments, each slice has a slice-specific RACH resource configuration, and assuming the UE is in an RRC connected or RRC inactive state, without any ongoing uplink transmission and without a scheduling request (SR) configured on the PUCCH resource, the UE needs to use RACH to connect to the gNB and request resources for the uplink. In other words, if there is no ongoing uplink transmission, and the UE receives data to be transmitted to the gNB, such as from an application running on the UE, to obtain resources on which to perform or transmit uplink, a RACH procedure needs to be performed. According to embodiments of the invention that provide RACH resource isolation between slices, the UE selects the RACH resource associated with the slice that generated the data request. More specifically, the UE determines the slice associated with the data request and the associated slice-specific RACH resource configuration. From this associated slice-specific RACH resource configuration, the UE selects the RACH resource for the RACH procedure, such as the RACH resource for sending the initial RACH message to the gNB.

[0280] Without the method of this invention, some transmissions may fail; for example, high-priority, mission-critical data transmissions may fail, or mission-critical RACH resources may be overloaded by low-priority data requests. This can be avoided by using slice-specific RACH resource configurations, which include slice-specific RACH resources associated with a particular slice for RACH attempts, thereby providing the aforementioned RACH resource isolation between slices.

[0281] According to an embodiment, the NAS layer can configure filters in the UE's user plane to map each packet to a QoS flow based on specific criteria such as source or destination IP address, port number, service field type, protocol identifier of a protocol above IP. According to an embodiment, the QoS flow used is the flow with the finest QoS differentiation granularity in the PDU session. The QoS flow can be configured on a per-slice basis and identified by a QoS flow identifier (QFI). In a 5G network or system, the QoS flow is controlled by the SMF and can be pre-configured or established via the PDU session establishment process or the PDU session correction process. One or more QoS rules and optional QoS traffic level QoS parameters associated with these QoS rules can be provided to the UE by the SMF via the AMF at the N1 reference point, and / or can be derived by the UE by applying the SDAP layer's reflection QoS control, as described in reference [2]. For uplink traffic, the UE can use stored QoS rules to determine the mapping between UL user plane traffic and QoS flows from the NAS layer. The UE can tag the UL PDU with the QoS rules containing the matching packet filter and transmit the UL PDU using the access-specific resources corresponding to the QoS flow based on the mapping provided by the RAN, as described in reference [1].

[0282] Each user plane slice can connect to a specific network identified by a PDU session identifier. At the access layer, radio bearers are defined and configured by the RRC protocol, which also configures a lower layer with specific configurations for each radio bearer. When a UE connects to multiple slices, different PDU sessions exist, each configured with a separate bearer for its corresponding slice. This allows each slice to have its own security features at the PDCP layer, providing security on a per-layer basis. Each PDU session and slice has an SDAP entity. The SDAP entity is responsible for mapping slice-specific QoS flows to slice-specific radio bearers according to the QoS flow-to-DRB mapping rules. A default DRB is configured at the SDAP layer.

[0283] Depending on the layer performing the RACH resource selection, different identifiers can be used in slice-specific RACH resource selection. The selection process can consider any of the above identifiers to derive the slice associated with the RACH.

[0284] According to an embodiment, the slice-specific RACH resource configuration selection function can be performed at the MAC layer. In such an embodiment, a device or service can send data packets within the UE. This data packet arrives at the UE's NAS layer as a service data stream and is filtered by an uplink packet filter. The IP address and port number, if known, correspond to a PDN session identifier and are mapped by a QoS stream filter. Data packets belonging to the QoS stream are mapped by the SDAP layer to the RLC channel at the PDCP layer via DRB, and then to a logical channel at the RRC layer. The data packet ends in the uplink data queue, and depending on the implementation, the data packet may be preprocessed to the RLC layer. The mapping scheduler is notified that there is new data in the data queue. Since no uplink data transmission is in progress on the PUSCH, and since there is no possibility of a scheduling request on the pre-configured PUCCH, random access is required. The RACH resource configuration selection function at the MAC layer is triggered to select a slice-specific RACH resource configuration and choose the RACH resource to use from the selected configuration. The upper layer may provide a PDN session identifier and / or associated slice identifier along the data packet, or may know that the data queue to which data has been added is associated with this PDN session identifier and / or associated slice identifier. Based on this information, according to an embodiment, the UE can consult a lookup table to identify the slice-specific RACH resource configuration to be used and select from it the RACH resource to actually use for the RACH attempt. Once the UE receives and decodes a system information block, such as an SIB slice, the lookup table is stored, containing slice-specific RACH resource configurations for different slices the UE may connect to. Once a slice-specific RACH resource configuration is selected, the specific RACH resource and preamble specified by this configuration are selected, and a random access message is transmitted at the next RACH resource.

[0285] Figure 9The process described above is illustrated. First, for example, when the UE connects to the system or network, system information can be read by the UE or received using dedicated RRC signaling so that the UE is configured with multiple slice-specific RACH resource configurations linked to the corresponding network slices, as shown in S100. Later, after the UE has connected to the system or network, a RACH event is determined, for example, determining that uplink packet data is available for transmission on the UE. In response to the trigger event detection at S102 to perform the Physical Random Access Channel procedure, based on the trigger event, a slice-specific RACH or PRACH resource configuration is selected from multiple slice-specific RACH or PRACH resource configurations at S104. Once the slice-specific RACH resource configuration is selected, a PRACH or RACH resource is selected from the selected slice-specific RACH resource configuration at S106, thereby determining the actual time-frequency resources, preamble, etc., used to perform the RACH procedure, and then the RACH procedure is performed at S108.

[0286] According to an embodiment, packets belonging to a PDN session identifier and / or slice identifier that do not have an entry in the lookup table can be found. For example, because such a configuration of no corresponding identifier or slice has been signaled by system information, the slice-specific RACH resource configuration selection function can select either the last used slice-specific RACH resource configuration or a configured or pre-configured alternative RACH resource configuration. In the lookup table, this may be a single entry, or a known RACH configuration used in 3GPP NR Rel.15 or Rel.16 may be signaled by the serving cell configuration of SIB-1.

[0287] Uplink data reaches the UE control plane

[0288] As described in the preceding embodiments, uplink data arriving at the UE's user plane can be mapped to QoS flows. However, other traffic can be generated at the NAS layer, RRC layer, or any other layer. Therefore, depending on the nature of the message—whether it's a control message or a data message—the slice-specific RACH resource configuration selection process may differ. For example, for control plane NAS, RRC packets are not mapped to QoS flows but to Signaling Radio Bearer 1 (SRB1) and Signaling Radio Bearer 2 (SRB2). NAS packets are transmitted via RRC in the corresponding UL information delivery message. The NAS and RRC messages submitted to the lower layer and triggering random access can provide some slice-related identifiers as side information to indicate which RACH resource they are mapped to. For example, in the case of sending NAS packets to the SMF in the 5GC, they can be assigned to a specific slice.

[0289] Other control functions may not be associated with a specific slice. For example, a NAS message sent to the AMF might be part of a common control function (i.e., a control function common to all slices). From a slice-specific or dedicated RACH resource configuration set, the network can configure one of the slice-specific RACH resource configurations for the UE as the primary RACH resource configuration for all common control messages. Ideally, a sufficient number of RACH resources should be provided in the primary RACH resource configuration to handle control messages for all slices.

[0290] Figure 10 The diagram illustrates the difference between the control plane and the user plane. Assume the core implements two slices, namely Slice 1 and Slice 2, associated with Data Network 1 and Data Network 2. As shown by the separate connections of Data Network 1 and Data Network 2 in the user plane, the user plane provides slice-specific RACH resource selection in the event of a RACH event occurring in one of the UEs coupled to the radio access network, as described above. On the other hand, the control plane handles common control functions for Slice 1 and Slice 2. More specifically, when a control message is received at the RAN, as shown in "3", the control message is forwarded to the common control plane block, which, after determining the default RACH configuration and selecting the slice to which the control information is applied, performs the RACH procedure for either the first or second slice.

[0291] If the UE is not registered when receiving a common control message, it may consider the slice identifier of the slice-specific RACH resource selection sent in the NAS registration request.

[0292] Scheduling request failed

[0293] According to an embodiment, a UE that receives data for uplink transmission but does not have uplink resources can use a PUCCH scheduling request on the PUSCH to utilize resources for uplink transmission. After sending the scheduling request, the UE waits for a PDCCH response in the downlink. If no response is received within a certain period, the scheduling request is considered to have failed, the UE initiates random access to connect to the gNB, and performs the aforementioned procedures regarding the arrival of uplink data at the UE.

[0294] Downlink data arrival

[0295] According to an embodiment, downlink data can reach the gNB for transmission to the UE. Assume the UE is connected in parallel to multiple slices, which support corresponding slice-specific or slice-dependent RACH resource configurations. For downlink transmission, the gNB may first use a RACH request to ensure the UE is uplink synchronized. For example, the UE may have moved, and therefore its location is different compared to the last downlink transmission, and the timing advance may have changed. In this case, the UE may no longer be uplink synchronized with the gNB. On the other hand, the UE may still be synchronized, for example, because it remains stationary. However, the gNB is unaware of the UE's state, nor whether the UE has moved, i.e., whether the UE is still in an uplink synchronized state. Therefore, when the gNB receives downlink data, it can use a RACH request to ensure uplink synchronization before transmitting the data to the UE. The gNB can send a RACH request at any time, independent of the UE's synchronization state, for example, to command the UE to perform a RACH procedure so that the gNB can perform uplink measurements based on the UE's RACH signal.

[0296] Downlink data may arrive at a specific QoS flow on the gNB belonging to a specific PDN connection. Before the gNB sends data to the UE, the UE will be synchronized uplink for the reasons mentioned above, such as by transmitting HARQ acknowledgments synchronously. The gNB sends a PDCCH with a RACH request to the UE requesting uplink RACH transmission. Once the UE is synchronized via a timing advance command received through the decoded random access response (RAR), the gNB can send data to the uplink-synchronized UE. Similar to any other uplink random access transmission, a slice-specific RACH resource configuration will be used, i.e., the resource configuration associated with the slice that triggered the RACH request. The UE is unaware of the slice from which it is receiving data or service requests; in this case, the gNB provides this information to the UE to allow it to select the correct RACH resource.

[0297] Generally speaking, embodiments of the first aspect of the present invention provide as follows Figure 11 The base station shown. Base station 420 supports one or more of multiple slices provided by a wireless communication network (such as a core network). Figure 11 In the above, assuming base station 420 supports as referenced... Figure 4 and Figure 6 The three slices are described. Base station 430, which supports such slices, can utilize slice-specific RACH resource configurations 422a and 422b to configure UEs connected to base station 420, for example, using RRC signaling.

[0298] The RACH procedure can be either a four-step or four-way contention-based random access (CBRA) procedure, as shown in Figures 12(a) and 12(b), or a two-step or two-way CBRA procedure. A four-step CBRA procedure involves four messages exchanged between the UE and the gNB. The UE sends RACH message 1 (Msg1) to the gNB, which includes an uplink PRACH preamble. The UE monitors the downlink RACH response, RAR, and Msg2. Msg2, from the gNB, includes the Random Access Radio Network Temporary Identifier (RA-RNTI) and the preamble identifier. In the uplink, the UE sends RACH message 3, Msg3, which optionally includes an RRC message. The CBRA procedure further includes a contention resolution message Msg4 in the downlink. A two-step CBRA procedure involves two messages exchanged between the UE and the gNB: an uplink message combining the aforementioned messages Msg1 and Msg3, and a downlink message combining the aforementioned messages Msg2 and Msg4. The 2-way RACH process in Figure 12(b) can be used specifically for small data, low-latency traffic, such as to support URLLC services, where Msg1 and Msg3 are compressed into MsgA, and Msg2 and Msg4 are compressed into MsgB.

[0299] According to an embodiment, base station 420 can receive a RACH message, such as a RACH preamble, from a UE performing a RACH procedure. In response to receiving the RACH message, the base station determines the segment that triggered the RACH message and / or is associated with it, and responds to the RACH message according to a segment-specific function. For example, the response may be an acknowledgment of a RACH resource configuration selection function that generates the PRACH response at the base station or gNB side, as described in more detail below with reference to FIG12(c). According to other embodiments, the response may be an additional segment-specific configuration message following message 4, such as message 5, which contains segment-specific information. According to an embodiment, using message 5, the UE can inform the gNB which segments it has performed a PRACH procedure for, so that the gNB can in turn prepare resources for those segments, for example, by sending an uplink grant to the UE for a specific segment. According to other embodiments, this information may also be included in Msg3, an RRC connection request, for example, using MAC CE. The content of Msg3 may vary depending on whether the UE already has a C-RNTI. The content of the corresponding message in the RACH procedure can be as described in http: / / howltestuffworks.blogspot.com / 2019 / 09 / 5g-nr-random-access-procedure.html.

[0300] According to other embodiments, in response to receiving a RACH message (such as message 5), the base station can create an event with slice-specific parameters. For example, it can trigger the scheduler to schedule uplink grants using slice-specific parameters (such as QoS, priority, delay budget, or expected packet size). Other events may include establishing, modifying, or publishing network slices, where modification may also be a remapping of network slices, such as performing handover, providing CHO information, setting / modifying / publishing measurement results, adding / modifying / publishing SCells, or transmitting dedicated NAS information from the gNB to the UE.

[0301] According to other embodiments, in response to receiving a RACH message, the base station can prioritize RACH responses in ascending / descending order based on the associated slice, as described in more detail below in a second aspect of the invention.

[0302] According to a further embodiment, in response to receiving a RACH message, the base station can select resources for the response based on the slice. For example, slice-specific data resources within a time / frequency / spatial resource grid, or slice-specific data resources from different frequency bands or frequency carriers or bandwidth portions associated with that network slice. For instance, a gNB might realize that it better serves a particular slice in different slice-specific bandwidth portions (BWPs) because it can only provide the required QoS there. Resources can also be selected to achieve a certain level of reliability, for example, by selecting the correct modulation and coding scheme (MCS), a lower frequency band for higher reliability, or a smaller subcarrier spacing to meet the delay budget.

[0303] Figure 12(c) illustrates the situation where downlink data arrives at the base station. Figure 11The process performed on base station 402 and the UE is as follows: As shown in S200, the UE is considered to be in an RRC connection state with base station 420. However, as mentioned above, the base station may not be able to determine that the UE is still in an uplink synchronization state, and therefore assumes or considers that the UE is no longer in a synchronization state as shown in S202. In S204, it is assumed that downlink data from the base station to the UE arrives at base station 420. Since base station 420 considers the UE to be no longer in a synchronization state, in S206, when downlink data arrives, base station 420 triggers a PDCCH command at the MAC layer, that is, the gNB can use downlink control information transmitted on the PDCCH, such as LTE DCI format 1A or NR DCI format 1_0, to send a RACH request. According to other embodiments, a newly defined DCI format can be used, for example, a DCI format in which the bits can be interpreted differently, so as to indicate not only the RACH request, but also a RACH resource configuration index pointing to a slice-specific RACH resource configuration that will be used by the UE for random access. According to the embodiment described, the slice-specific RACH resource configuration selection function resides in the gNB 420, because the gNB understands which control message or which packet of which PDN session / QoS flow the downlink transmission is waiting for. The gNB 420 can perform the slice-specific RACH resource configuration selection function based on inputs similar to those of the UE, such as the slice identifier or other identifiers mentioned above, and signal the actual slice-specific RACH resource configuration for the UE to use in the RACH procedure along with the RACH request. For example, multiple slice-specific RACH resource configurations, such as those previously signaled by RRC system information or dedicated RRC signaling, can be indexed, and additional bits (such as the RACH resource index) in the DCI format sent at S206 can point to the corresponding configuration. Once the UE receives the PDCCH DCI requesting random access, the UE decodes the DCI, which includes, for example, the RACH resource index, and selects the slice-specific RACH resource configuration based on the RACH resource index. The UE initiates the RACH procedure by selecting RACH resources and RACH preamble from the indicated slice-specific configuration, and then the RACH is transmitted from the UE to the gNB 420 as shown in S208.

[0304] According to the embodiments, the maximum number of configured RACH resources (2 or 4) can be defined to limit signaling overhead. For example, with a maximum of 2 RACH resources configured, the RACH resource index may have only 1 bit, while with a maximum of 4 RACH resources configured, the RACH resource index may have 2 bits. These bits can be added to the existing DCI format or be part of a new DCI format. For example, in the existing DCI format, some bits may be replaced.

[0305] According to other embodiments, the PDCCH command can indicate a specific RACH resource previously reserved by the gNB within an existing configuration for contention-free random access (CFRA). This resource can be defined by time-frequency resources, preamble indexes, synchronization signal and physical broadcast channel (SS / PBCH) indexes, PRACH mask indexes, etc. Assigning a previously reserved, very specific RACH resource can avoid conflicts with other UEs in contention-based random access. The RACH resource configuration index may be part of the signaling pointing to the very specific resource.

[0306] In Figure 12(c), after sending the PRACH preamble at S208, the gNB420 responds, sends a PRACH response at S210, and sends an RRC connection reconfiguration message at S212. The UE responds to the RRC connection reconfiguration message and sends an RRC connection reconfiguration complete message at S214. The UE is considered to be in a synchronized state with the gNB420, as shown in S216. After synchronization, downlink data transmission from the gNB420 to the UE is performed, as shown in S218.

[0307] Figure 13 The above process of providing data from base station 420 to UE from the UE's perspective is illustrated. First, for example, when the UE connects to the system, the UE reads system information or receives dedicated RRC signaling, which includes multiple slice-specific RACH resource configurations, such as multiple PRACH resource configurations linked to the corresponding network slice, as shown at S230. At S232, the UE receives a PDCCH command (see S206 in Figure 12(c)) and decodes a signal requesting a random access channel procedure, which includes an indication of which slice-specific PRACH resource configuration will be used for the random access channel procedure. At S234, the UE selects the resource configuration indicated by the PDCCH command from the multiple slice-specific PRACH resource configurations, and at S236 selects the resource to perform the RACH procedure using the selected resource at S238, i.e., to send the PRACH preamble (see S208 in Figure 12(c)).

[0308] transfer

[0309] An embodiment of the first aspect of the invention relating to a handover scenario or process will now be described. During the handover process, the UE expects to hand over its connection from a source gNB to a target gNB. Any UE connected to the serving cell is configured with neighbor cell measurements in preparation for a potential handover. Once a UE measures a strong neighbor cell, it may report this measurement to its source gNB to the potential target gNB. Figure 14The diagram illustrates the handover process. Before executing the handover process, the source gNB queries the target gNB, for example using a handover request "1" (Xn), whether to allow the handover of the UE. According to an embodiment of the invention, it is assumed that the target gNB also implements or supports the slice to which the UE requesting handover is connected in parallel or simultaneously. The target gNB performs admission control, and in response to positive admission control, the target gNB sends, for example, a handover confirmation message "2" (Xn) to the source gNB. The target gNB may provide some configuration parameters of its cell configuration back to the source gNB, and may also include parameters to be forwarded to the UE in an RRC handover command message "3" transmitted from the source gNB to the UE and supporting the UE's handover to the target cell. The handover message may be signaled by an RRC reconfiguration message. Due to the lack of uplink synchronization to the target gNB, it is expected that the UE will perform a random access to the target gNB, and the UE will receive a random access response with uplink grant. The UE finally sends an RRC handover completion message "4" to the target gNB to complete the handover.

[0310] although Figure 14 The process is interpreted as using the gNB inter-interface interface Xn (such as X2 in LTE), but it can also be run via the core network through the NG interface (such as the S1 interface in LTE).

[0311] During handover, the network needs to control the RACH configuration / resources used by the UE when performing random access to complete the handover. gNBs configure and control their own resources; that is, the target gNB's resources are controlled by the target gNB, not the source gNB. The UE obtains relevant information from the gNB by reading RRC system information, such as RACH resource configuration by reading SIB-1 or new SIB slices. However, during handover, the UE may not be able to read all system information because the UE is still within the coverage area of ​​the source gNB. When a set of minimum system information (such as MCS information blocks) or minimum system information or SIB-1 is signaled with higher quality (e.g., with higher power and a more conservative MCS or more frequent repetition), other SIBs may not be reliably transmitted and may not be received in neighboring cells outside the target gNB's coverage area. Therefore, during handover, when the UE is only close to the coverage area of ​​the new gNB (target gNB), it may not be able to receive SIBs, such as SIB slices. In this case, the UE is unaware of the slice-specific RACH resource configuration used by the target gNB, which may differ from the resource configuration used by the source gNB.

[0312] According to an embodiment of the present invention, to address this situation, after receiving the Xn handover request message "1" from the source gNB, the target gNB provides detailed information on the slice-specific RACH resource configuration. The source gNB transparently and unmodifiedly forwards this information to the UE in the RRC handover recommendation message "3," which the UE considers during the RACH resource selection process. For example, the information provided to the UE may be a slice-specific RACH resource configuration, or it may be provided by a system information block (such as an SIB slice).

[0313] The target gNB can perform slice-specific RACH resource configuration selection after successful admission control following a handover request from the source gNB. The slice-specific RACH resource configuration selection can be based on the target gNB configuration, and according to embodiments, can also determine the slice-RACH resource configuration to use based on information provided in the handover request message from the source gNB. This information provided in the handover request may, among other things, include a PDU session identifier or other PDU session resource information, which may include the slice identifier of the slice to which the UE is connected. For the user plane, this information may include the PDU session type, the QoS flows to be established in the uplink and downlink, and potential queue and data information regarding transmission status. For the control plane, it may include information about the core network entities to which the UE is connected, transport network layer parameter information, etc.

[0314] According to an embodiment, the target gNB may deny access to all resources, slices, QoS flows, etc., but only allow access to a subset of the requested resources, slices, PDU sessions, QoS flows, etc. The target gNB may notify the source gNB which resources, slices, PDU sessions, and QoS flows are permitted and which are not, for example, using a PDU session resource denial list and / or a PDU session resource permission list. Based on the permitted resources, slices, and QoS flows, a slice-specific RACH resource configuration to be used is selected.

[0315] In the case of contention-free random access, according to an embodiment, the target gNB can not only select slice-specific RACH resource configurations, but also select specific RACH resources, preamble indexes and other RACH resource configuration parameters used by the UE for the RACH procedure.

[0316] The target gNB can, for example using a transparent container, forward the RACH resource configuration selection function and the result of the RACH resource selection to the source gNB in ​​the handover confirmation message "2". Then, in the handover command, the transparent container is forwarded to the UE, that is, the slice-specific RACH resource configuration to be used when using a random access connection to the target gNB is notified to the UE using the RRC reconfiguration message "3".

[0317] The above embodiments provide the UE with all necessary information during the handover process; however, this also leads to an increase in the handover message size. The size of the handover message can be critical because UE reception quality degrades within the handover area. To address this issue, embodiments utilize the requirement in NR that the same slice be supported within a Tracking Area (TA). Therefore, according to other embodiments, all gNBs within a Tracking Area can provide the same slice-specific RACH resource configuration so that, for example, the same index of the slice-specific RACH resource configuration is used in both the source and target gNBs. During the handover, within the Tracking Area, this allows only the previously defined slice-specific RACH resource configuration index to be signaled, rather than the complete configuration. This avoids an increase in the handover message size, and the UE learns from system information that if the target gNB is in the same Tracking Area and broadcasts the same Tracking Area code, the same slice-specific RACH resource configuration is used in the target cell. This additional information can be defined by a new Information Element (IE) in the newly defined RRC handover command.

[0318] When considering the above embodiments regarding the handover process, even though the RACH resource configuration is relatively static, providing the RACH resource configuration in each handover or in each conditional handover increases signaling overhead. Therefore, according to a further embodiment, gNBs can exchange information about slice-specific RACH resource configurations via gNB-to-gNB interfaces such as Xn, X2, or S1-MME, NG-C interfaces. Figure 15 An embodiment is illustrated, according to which this information can be exchanged as part of the setup process. As shown, this information is provided when setting up a gNB via the setup process. A gNB1 requesting Xn setup can add its slice-specific RACH resource configuration to the Xn setup request message, while a responding gNB2 can include its slice-specific RACH resource configuration in the Xn setup response message.

[0319] If the configuration in a gNB changes, the gNB can provide an updated slice-specific RACH resource configuration via the Xn gNB configuration update process, such as... Figure 16 As shown.

[0320] According to a further embodiment, each base station can maintain a slice-specific RACH resource configuration for each neighbor cell in the neighbor cell list. In the case of handover or conditional handover, the source gNB already knows which slice-specific RACH resource configuration will be selected from the target gNB's configured slice-specific RACH resource configurations to perform the RACH procedure to complete the handover. This may be based on information contained in the handover request or handover response message, such as the explicit or implicit slice identifier requested.

[0321] Conditional transfer

[0322] The above embodiments primarily describe the handover process; however, the method of the present invention can also be applied to conditional handover scenarios (CHO scenarios). CHO is standardized in NR Rel.16. The actual handover decision is made by the UE based on gNB configuration, rather than by the gNB based on the UE's measurement reports. Figure 17 The diagram illustrates the conditional handover process, and Figure 14 The process is essentially the same, except that the UE receives the handover conditions to be monitored from the source node. Once the handover conditions are met, the UE performs the handover. In other words, if one or more predefined CHO criteria are met, such as a signal strength threshold, CHO is triggered, and the UE performs RACH in the target cell. The signaling required for performing RACH in the target cell is the same as described above regarding unconditional handover. In regular handover (HO), the gNB can provide details of the selected RACH resources in the HO command, while in CHO, the gNB can provide details of the selected RACH resource configuration in the CHO configuration. Once the CHO configuration is established, the source gNB sends a CHO request to the target gNB (see [link to relevant documentation]). Figure 17 The system receives confirmation messages from potential target nodes with configuration details. This also includes details of the RACH resource configuration for the corresponding slice, and the source gNB forwards this information to the UE when a CHO is configured using an RRC reconfiguration message.

[0323] Initial access from an RRC connection, such as when an RRC connection is re-established.

[0324] If a UE loses its link to its serving cell, it will declare a Radio Link Failure (RLF) after a period of time, such as when timer T310 expires. At some point in time, such as after timer T312 expires, an RRC re-establishment to the previous serving cell may be triggered. This process begins with random access. Since RRC re-establishment applies to all slices, according to the embodiment, instead of a slice-specific procedure, a cell-specific procedure is initiated, which triggers a RACH link to either the default RACH resource or a RACH resource in ascending priority. For example, the SIB slice can indicate which resources can be prioritized, for example, for cell-specific procedures such as RRC connection re-establishment.

[0325] The response to paging, the transition from idle state, and the transition from RRC inactive state.

[0326] According to other embodiments, a further process may be triggered on the RACH side at the UE. This process may be triggered by the gNB, for example, via paging, or by the UE itself, for example, by transmitting control messages in the uplink. According to embodiments, the RACH configuration employed may include a primary or process-specific RACH resource configuration for such control procedures. According to other embodiments, the UE may remember the last RACH resource configuration used. The UE may store information about the last used RACH resource configuration in its buffer, such as in a lookup table of several slice-specific RACH resource configurations, so that the last used RACH resource configuration can be used when performing RACH resource configuration functions once random access is triggered.

[0327] generally

[0328] Embodiments of the first aspect of the invention provide complete isolation of RACH resources in a slice- or PLNM-specific manner, which allows reliable random access without cutting off a large number of users from the communication system, such as in emergency call situations in high-load scenarios.

[0329] Second aspect

[0330] The second aspect of the embodiments addresses the problem of potentially overlapping RACH procedures performed by UEs connected in parallel or simultaneously to multiple different slices, wherein the corresponding RACH resources are triggered by RACH events on different slices.

[0331] ---------------------------------------------------------------------

[0332] Handling of multiple RACH procedures in UE

[0333] ---------------------------------------------------------------------

[0334] According to a second aspect, the present invention provides a user equipment (UE) for a wireless communication network.

[0335] The UE may connect to two or more of a plurality of network slices of the wireless communication network, wherein a slice-specific random access channel (RACH) resource configuration is associated with one or more of the plurality of slices.

[0336] Specifically, in response to a first RACH event associated with the first slice, the UE determines whether there is an ongoing RACH process triggered by a second RACH event associated with the second slice, and

[0337] In the case of an ongoing RACH procedure, the UE will

[0338] • Prohibit additional RACH processes triggered by the first RACH event associated with the first slice, and / or

[0339] • Suspend the additional RACH process for a period of time, and / or

[0340] • Stop the ongoing RACH process and start an additional RACH process, and / or

[0341] • Modify the ongoing RACH process, and / or

[0342] • Modify the ongoing RACH process to initiate an additional RACH process.

[0343] According to an embodiment of the second aspect, the slice-specific RACH resource configuration specifies one or more resource configurations and one or more parameters for the RACH procedure, such as...

[0344] • PRACH preamble, including, for example, preamble format, preamble sequence, sequence length, subcarrier spacing for the preamble, cyclic prefix, guard time length,

[0345] • Beam index

[0346] • Beam switching trigger event,

[0347] • Resources used for PRACH, such as time and / or frequency and / or space resources,

[0348] • One or more parameters used to determine one or more root sequences and their cyclic shifts in a set of PRACH preamble sequences.

[0349] • Index of the logical root sequence list

[0350] • Cyclic displacement, Ncs,

[0351] • Set type, such as unrestricted set A or restricted set B.

[0352] According to an embodiment of the second aspect, in the presence of an ongoing RACH process, the UE will abort any additional RACH processes so that at any given time, there is only a single ongoing RACH process.

[0353] According to the embodiment of the second aspect, the UE will suspend the additional RACH procedure until the ongoing RACH procedure is completed.

[0354] According to an embodiment of the second aspect, once the ongoing RACH procedure on the first slice is completed, the UE will store information related to the additional RACH procedure to be used when an additional RACH procedure is initiated on the second slice.

[0355] According to an embodiment of the second aspect, in response to the ongoing RACH procedure failing a predefined number of times, the UE will stop or postpone the ongoing RACH procedure and initiate an additional RACH procedure.

[0356] According to the embodiment of the second aspect, the UE disables or suspends the additional RACH procedure in the following circumstances.

[0357] • Parallel RACH procedures using different slice-specific RACH resource configurations are not permitted, for example, by some standard specification, by defined UE functions, and / or,

[0358] • Disable parallel RACH processes that use different slice-specific RACH resource configurations, such as those for a specific cell, UE, service type, priority level, slice, or RACH trigger event, and / or,

[0359] • An ongoing RACH process has a higher priority than an additional RACH process, and / or

[0360] • When compared to the ongoing RACH process, the additional RACH process uses a different configuration, such as different digitization, different subcarrier spacing, different frequency band or bandwidth portions, and / or

[0361] • Additional RACH processes are sent to a different BS or DU than the ongoing RACH process.

[0362] According to an embodiment of the second aspect, once the ongoing RACH procedure is partially completed, the UE will suspend any additional RACH procedures.

[0363] According to an embodiment of the second aspect, the UE will initiate an additional RACH procedure, such that there are no parallel uplink transmissions associated with the ongoing RACH procedure and the additional RACH procedure.

[0364] According to an embodiment of the second aspect, in response to a specific event associated with an ongoing RACH procedure, the UE will initiate an additional RACH procedure, the specific event including one or more of the following:

[0365] • The UE sends an RRC connection request message 3 in the uplink for the ongoing RACH procedure.

[0366] • The UE receives a RACH response (RAR) message 2 in the downlink for the ongoing RACH procedure.

[0367] • The UE sends RACH preamble message 1 in the uplink for the ongoing RACH procedure.

[0368] • The UE receives an RRC connection reconfiguration message in the downlink.

[0369] According to an embodiment of the second aspect, under the following conditions, the UE will stop the ongoing RACH procedure and initiate an additional RACH procedure.

[0370] • Throughout the entire ongoing RACH process or up to a certain stage of the ongoing RACH process, and / or

[0371] • Responds to the fulfillment of one or more preemption criteria.

[0372] According to an embodiment of the second aspect, one or more preemption criteria include one or more of the following:

[0373] Specific parameters in RRC RACH resource configuration, such as relative slice priority, or QoS flow or logical channel priority,

[0374] Events that trigger the RACH procedure, such as the PDCCH command, handover, or CHO or RRC re-establishment,

[0375] • The type of user plane message waiting to be transmitted, such as which logical channel, QoS stream, PDN session, or slice identifier the message belongs to.

[0376] • QoS attributes of user plane messages awaiting transmission, such as the priority, latency, or reliability of the logical channel or data stream to which the message belongs.

[0377] • Message types awaiting transmission, such as RRC control plane messages transmitted via signaling radio bearers, take precedence over user plane messages transmitted via data radio bearers.

[0378] • The entity that triggers the RACH procedure, such as the UE-triggered RACH procedure, takes precedence over the base station-triggered RACH procedure or the SL-UE-triggered RACH procedure, such as the group leader UE or RSU.

[0379] According to an embodiment of the second aspect, in order to correct an ongoing RACH process, the UE will correct a specific message transmitted by the UE during the ongoing RACH process, such as Msg3, in the following manner: in addition to the indication of the first slice, the specific message also includes an indication of the second slice, so as to allow the base station to provide parameters for the configuration of the first and second slices in response to the specific message.

[0380] According to an embodiment of the second aspect, in order to correct an ongoing RACH procedure to initiate an additional RACH procedure, the UE will correct a specific message transmitted by the UE in the ongoing RACH procedure, such as Msg3, by replacing the indication of the first slice with the indication of the second slice, so as to allow the base station to provide parameters for the configuration of the second slice in response to the specific message.

[0381] According to an embodiment of the second aspect, the additional RACH process and the ongoing RACH process are triggered simultaneously or within a certain time window.

[0382] According to an embodiment of the second aspect, the UE is configured or pre-configured to support two or more parallel RACH processes, which are associated with different slices.

[0383] According to the embodiment of the second aspect, if a slice is configured as one or more of the following, then the UE is only allowed to perform two or more PRACH procedures for different slices:

[0384] • Use different BWPs,

[0385] • Operate on different carrier frequencies, wherein the frequency gap between a first radio frequency, for example, operating on FR1, and a second radio frequency, for example, operating on FR2, is Δx.

[0386] ---------------------------------------------------------------------

[0387] UE - Allows multiple RACH procedures

[0388] ---------------------------------------------------------------------

[0389] According to a second aspect, the present invention provides a user equipment (UE) for a wireless communication network.

[0390] The UE can connect to two or more of multiple network slices of a wireless communication network, wherein a slice-specific random access channel (RACH) configuration is associated with one or more of the multiple slices.

[0391] The UE is configured or pre-configured to support two or more parallel RACH procedures, which are associated with different slices.

[0392] According to an embodiment of the second aspect, the possibility of having a parallel RACH process is designated as a UE capability, and the UE reports its capability to the base station or another UE, for example, when the UE first registers with the wireless communication system.

[0393] According to the embodiment of the second aspect, the UE will

[0394] • Receive queries from the base station, such as RRC UE capability query messages, and

[0395] • In response to a query, send capabilities to the base station, for example, using an RRC UE capability information message.

[0396] According to the embodiment of the second aspect, the UE will

[0397] • In response to signaling from the base station, enable parallel RACH procedures, for example, to reduce the latency of RACH procedures associated with slices supporting latency-critical services, and

[0398] • In response to signaling from the base station, disable the parallel RACH process, for example, for slices that support mission-critical communications.

[0399] ---------------------------------------------------------------------

[0400] UE - Monitoring multiple RAR messages

[0401] ---------------------------------------------------------------------

[0402] According to an embodiment of the second aspect, the UE will monitor two or more random access response (RAR) messages in the downlink corresponding to two or more slice-specific RACH resource configurations.

[0403] According to an embodiment of the second aspect, the UE will monitor one or more public resources or one or more slice-specific resources for two or more RAR messages.

[0404] According to the embodiment of the second aspect, the UE will monitor a common search space, such as the bandwidth portion (BWP), for two or more RAR messages, which is common to all slices.

[0405] According to an embodiment of the second aspect, the UE pre-configures or configures a control resource set (CORESET) for the public PDCCH search space in the public BWP to monitor two or more RAR messages.

[0406] According to an embodiment of the second aspect, RAR messages corresponding to different slice-specific RACH resource configurations are distinguished in the following manner.

[0407] • Split RACH resources and RA-RNTI, and / or

[0408] • Segmentation preamble identifier, and / or

[0409] Additional information, such as additional RA-RNTI or preamble identifiers, and / or the introduction of slice-specific RACH resource configuration indexes or slice resource indexes.

[0410] According to an embodiment of the second aspect, the additional information is signaled as part of the MAC PDU used for RAR.

[0411] According to the embodiment of the second aspect, the UE will monitor individual slice-specific search spaces, such as slice-specific bandwidth portion (BWP) and / or CORESET and / or PDCCH search spaces, and / or PSCCH search spaces, each individual slice-specific search space being associated with a slice-specific RACH resource configuration.

[0412] According to an embodiment of the second aspect, the UE is pre-configured or configured with one or more slice-specific search space downlink resources to be monitored.

[0413] According to an embodiment of the second aspect, the uplink grant received in the RAR message for a specific slice points to different uplink resources, such as different BWPs, previously configured for the specific slice.

[0414] According to an embodiment of the second aspect, in multiple slices,

[0415] • Slices have their own slice-specific RACH resource configurations, and / or

[0416] • Two or more slices share slice-specific RACH resource configurations.

[0417] According to an embodiment of the second aspect, the UE is configured or pre-configured with slice-specific RACH resource configurations for some or all of a plurality of slices.

[0418] According to the embodiment of the second aspect, in response to the RACH event, the UE will

[0419] • Identify the slice that triggered the RACH event and / or was associated with the RACH event, and

[0420] • Select the slice-specific RACH resource configuration associated with the selected slice for performing the RACH procedure.

[0421] ---------------------------------------------------------------------

[0422] base station

[0423] ---------------------------------------------------------------------

[0424] According to a second aspect, the present invention provides a base station (BS) for a wireless communication network.

[0425] The BS will support one or more slices of a wireless communication network, with slice-specific random access channel (RACH) configurations associated with one or more slices.

[0426] The BS will configure one or more user equipment (UEs) to enable or disable the parallel RACH process.

[0427] ---------------------------------------------------------------------

[0428] system

[0429] ---------------------------------------------------------------------

[0430] According to a first aspect, the present invention provides a wireless communication system comprising one or more inventive user equipment (UE) and / or one or more inventive base stations (BS).

[0431] ---------------------------------------------------------------------

[0432] method

[0433] ---------------------------------------------------------------------

[0434] According to a second aspect, the present invention provides a method for operating a user equipment (UE) in a wireless communication network, wherein the UE can connect to two or more of a plurality of network slices of the wireless communication network, wherein a slice-specific random access channel (RACH) resource configuration is associated with one or more of the plurality of slices, the method comprising:

[0435] In response to a first RACH event associated with a first slice, determine whether there is an ongoing RACH process triggered by a second RACH event associated with a second slice, and

[0436] In the case of the ongoing RACH process,

[0437] • Prohibit additional RACH processes triggered by the first RACH event associated with the first slice, and / or

[0438] • Suspend the additional RACH process for a period of time, and / or

[0439] • Stop the ongoing RACH process and start an additional RACH process, and / or

[0440] • Modify the ongoing RACH process, and / or

[0441] • Modify the ongoing RACH process to initiate an additional RACH process.

[0442] According to a second aspect, the present invention provides a method for operating a user equipment (UE) in a wireless communication network, wherein the UE can connect to two or more of a plurality of network slices of the wireless communication network, wherein a slice-specific random access channel (RACH) configuration is associated with one or more of the plurality of slices, the method comprising:

[0443] Configure or pre-configure the UE to support two or more parallel RACH procedures, which are associated with different slices.

[0444] According to a second aspect, the present invention provides a method for operating a base station (BS) of a wireless communication network, wherein the BS supports one or more of a plurality of slices of the wireless communication network, wherein a slice-specific random access channel (RACH) configuration is associated with one or more of the plurality of slices, the method comprising:

[0445] Configure one or more user equipment (UEs) to enable or disable the parallel RACH process.

[0446] Figure 18 An embodiment of the second aspect of the invention is illustrated, and more specifically, an embodiment of a UE 500 that is connectable to two or more slices and capable of handling two or more RACH processes triggered simultaneously or during an ongoing RACH process. It is assumed that the UE 500 is connected to a network using network slicing, for example, as referenced above. Figure 4 and Figure 6 The network mentioned above. Figure 18 The network configuration shown is the same as described above. Figure 4 or Figure 6 The network configurations shown are identical. UE 500 connects to two slices, namely slice #1 and slice #2, in parallel or simultaneously. The UE may include processor 502 to detect a RACH event X2 associated with slice #2, as shown in 502a. In response to detecting a RACH event in slice #2, UE 500 determines or checks whether there is any ongoing RACH procedure triggered by a different RACH event associated with a different slice. Figure 18 The document describes a scenario where there is an ongoing RACH procedure X1 that originates from the first RACH event in slice #1. After checking for an ongoing RACH procedure at 502b, if such an ongoing RACH procedure is found, the UE can handle one or more further or additional RACH procedures initiated in different ways at 502c.

[0447] exist Figure 18 In one embodiment, the UE is connected to two slices; however, the invention is not limited to such an embodiment, and the UE may be connected to more than two slices in parallel.

[0448] According to one embodiment, the UE can disable additional RACH procedures, such as a second RACH procedure triggered by RACH event X2 associated with slice #2. According to other embodiments, the UE can suspend additional RACH procedures for a period of time. According to still other embodiments, the UE can stop an ongoing RACH procedure, such as... Figure 18The UE initiates a RACH procedure triggered by RACH event X1 and starts an additional RACH procedure initiated by RACH event X2. According to even further embodiments, the UE can modify an ongoing RACH procedure or modify an ongoing RACH procedure to start an additional RACH procedure.

[0449] Further embodiments of the second aspect of the invention provide, as follows Figure 19 The base station shown. Base station 520 supports one or more of multiple slices provided by a wireless communication network (such as a core network). Figure 19 In the above, assuming base station 520 supports as referenced... Figure 4 and Figure 6 The three slices mentioned above. According to an embodiment of the second aspect, a base station 520 supporting such slices can configure a UE connected to the base station 520 to enable or disable parallel RACH procedures. In other words, the base station 520 can configure the UE to allow two or more parallel RACH procedures, or to disallow two or more parallel RACH procedures, for example, by disposing of parallel RACH procedures according to embodiments described later.

[0450] An embodiment for handling multiple overlapping RACH processes will now be described in more detail.

[0451] RACH processes that are prohibited from being performed in parallel

[0452] If the standard or specification implemented by the UE does not allow any further RACH procedures on different slice-specific RACH resource configurations at any point in time, or if the UE is configured by the base station or gNB to prohibit parallel processing of multiple ongoing RACH procedures, then there may only be a single ongoing RACH procedure.

[0453] According to an embodiment, the UE performs a first RACH procedure, also known as an ongoing RACH procedure, on a slice-specific RACH resource configuration, while simultaneously triggering a second RACH procedure, also known as an additional RACH procedure, on a second slice-specific RACH resource configuration. Although the embodiments described herein assume that the two RACH procedures for different slices occur in parallel or overlap, it should be noted that the method of the present invention is not limited to such embodiments. According to a further embodiment, more than two RACH procedures for different slices can occur in parallel or overlap.

[0454] To prevent parallel execution of RACH procedures, the second RACH procedure in different slices is always blocked or aborted until the first RACH procedure is completed. The UE detects that the first RACH procedure on the first slice or the first RACH procedure on the first slice-specific RACH resource configuration is in progress and blocks or aborts the second RACH procedure. Figure 20An embodiment of a RACH process that prohibits any parallel execution is illustrated. First, at S600, the UE, as... Figure 18 UE 500 reads system information or receives dedicated RRC signaling including multiple slice-specific RACH resource configurations, for example, in the manner described above with reference to the first aspect of the invention. The slice-specific RACH resource configuration specifies one or more resource configurations and one or more parameters for the RACH procedure for one or more slices. At S602, UE 500 detects trigger event X1 to execute a first RACH procedure in slice #1, also known as the Physical Random Access Channel (PRACH) procedure (see [link to documentation]). Figure 18 At S604, the UE selects a RACH or PRACH resource configuration for slice #1 from a set of slice-specific RACH or PRACH resource configurations, and selects a PRACH resource for transmission from the selected slice-specific PRACH resource configuration. The UE performs a conventional RACH procedure and sends RACH message 1 (e.g., uplink PRACH preamble) to a receiver, such as a base station or another network entity, such as a directly connected UE, at S606. At S608, the UE monitors for downlink RACH response RAR message 2 from the base station or other network entity. At S610, the UE finds the Random Access Radio Network Temporary Identifier RA-RNTI and its preamble identifier, and sends RACH message 3 in the uplink at S612, which optionally includes an RRC message. In the case of using a contention-based random access procedure, at S614 the UE waits for a contention resolution message in the downlink in case contention resolution is required. As shown at S616, this completes the first PRACH or RACH procedure.

[0455] While performing the first RACH procedure, the UE also monitors the network to obtain more RACH trigger events from slices other than slice #1. Figure 20 In the illustrated embodiment, it is assumed that the UE detects a second trigger event X2 at S618 in order to perform a second RACH or PRACH procedure in slice #2 (see Figure 18 In response to the detection of a trigger event for executing a second PRACH procedure, at S620 the UE determines that another RACH procedure is already in progress on another slice, namely another RACH procedure using a different slice-specific PRACH resource configuration, i.e., the first PRACH procedure mentioned above. It should be noted that as long as the procedures described in S602 to S614 above are not completed, the RACH procedure is considered to be in progress; that is, in progress also includes waiting for a response or waiting for contention resolution.

[0456] At S622, the UE prohibits the second RACH procedure by blocking or aborting the additional RACH procedure. For example, the second RACH triggering event may be ignored, and / or any parameters already obtained from the associated slice-specific RACH resource configuration may be discarded. In other words, according to the current embodiment, when a further RACH procedure other than the ongoing RACH procedure is detected, the UE does not execute the second or additional RACH procedure, such as... Figure 20 As shown at S622 in the diagram.

[0457] According to other embodiments, in order to prohibit parallel RACH processes, rather than blocking or terminating additional RACH processes as described above, the UE may suspend the second RACH process until the first RACH process is completed. Figure 20 This is also illustrated. In response to the detection of a parallel RACH process at S620, instead of suspending or blocking the second RACH process, the UE suspends the second RACH process at S624 until the first RACH process completes. That is, the execution of the second RACH process on the second slice #2 is delayed, as shown at S626, until the first RACH process completes, as shown at S616. After the first RACH process completes, the UE initiates the second RACH process by performing, for example, the same steps as the first RACH process, as shown at S606' and S608'. Therefore, according to the current embodiment, the second RACH process is only paused by adding some delay until the process is allowed to start. Once a parallel, ongoing first RACH process is detected on the first slice, the UE waits until the first RACH process completes. In this case, the UE can store information related to the second RACH process and initiate the second RACH process on the second slice once the first RACH process on the first slice completes.

[0458] According to an embodiment, once the ongoing RACH procedure on the first slice is completed, the UE can store information related to the additional RACH procedure used when initiating an additional RACH procedure on the second slice. In response to the ongoing RACH procedure failing a predefined number of times, the UE can stop or postpone the ongoing RACH procedure and initiate an additional RACH procedure.

[0459] According to an embodiment, the UE may disable or suspend an additional RACH procedure that is being executed in parallel with the ongoing RACH procedure under one or more of the following conditions:

[0460] • Parallel RACH procedures using different slice-specific RACH resource configurations are not permitted. For example, some standards specifications may not allow such parallel RACH procedures, or UE functions may not allow parallel RACH to be performed.

[0461] • Parallel RACH processes using different slice-specific RACH resource configurations are prohibited, such as those for a specific cell, UE, service type, priority level, slice, or RACH trigger event.

[0462] • An ongoing RACH process has a higher priority than an additional RACH process.

[0463] • When compared to the ongoing RACH process, the additional RACH process uses a different configuration, such as different digits, different subcarrier spacing, different frequency bands, or different bandwidth portions.

[0464] • Compared to the ongoing RACH process, the additional RACH process is sent to a different base station, or, in the case of cloud RAN (C-RAN), to a different distributed unit (DU).

[0465] Disabling additional RACH procedures is advantageous, for example, in terms of UE power requirements. A UE's overall uplink transmission power is limited, and, for example, a UE located at the cell edge may periodically use its maximum power for transmission. Therefore, power partitioning between multiple concurrent RACH procedures is undesirable. This power partitioning can be avoided by blocking a second RACH procedure on a different slice or pausing the second RACH procedure until the first RACH procedure is complete.

[0466] Time-shifted RACH process

[0467] According to another embodiment of the second aspect of the invention, a method can be provided that allows for improvement in overall latency with minimal impact on the performance of the second RACH process on the second slice. To achieve this, the second RACH process can be initiated before the first RACH process completes; that is, the second RACH process does not wait for the entire first RACH process to complete. In other words, according to a further embodiment, as referenced above… Figure 20 The second RACH process is not paused during the entire duration of the first RACH process, but only during a portion of it.

[0468] According to an embodiment, the first RACH procedure is partially completed before the second RACH procedure can be initiated, without increasing the complexity and processing requirements on the UE. According to an embodiment, the second RACH procedure on the second slice can be initiated when message 3 of the first RACH procedure is sent on the uplink. This is the last message sent on the uplink before the RACH procedure completes. Since no other uplink messages of an ongoing process are expected, the additional RACH procedure may have already started without any uplink transmission conflicts. This reduces the latency of the additional RACH procedure because the UE will not wait to receive message 4.

[0469] According to a further embodiment, when RAR message 2 for the first RACH procedure is received in the downlink, the second RACH procedure on the second slice can be initiated. In RAR message 2, in particular, the uplink resource allocation for message 3 is sent from the gNB to the UE. Based on the received RAR, the UE knows the uplink transmission time of message 3 in the ongoing RACH procedure and shifts the uplink transmission of the RACH preamble message 1 for the additional RACH procedure. If an uplink conflict occurs, i.e., message 3 in the ongoing RACH procedure conflicts with message 1 in the additional RACH procedure, the UE can skip the corresponding RACH resource and select the next RACH resource. This makes the latency of the additional RACH procedure even lower, because the UE does not need to wait for the transmission of message 3.

[0470] According to a further embodiment, when the PRACH preamble message 1 of the first RACH process is transmitted on the uplink, the second RACH process on the second slice can be initiated. Parallel transmission of the RACH preamble should be avoided as much as possible because power splitting can have an even more severe impact on system performance compared to any other uplink data transmission. The main reason is that power is split between the two transmissions when the UE is not yet connected to the gNB, there is no timing advance, and link adaptive looping is not performed. The RACH preamble in message 1 is also the only message in the RACH process that does not support HARQ retransmission, including soft combinations of different versions that are retransmitted. Furthermore, RACH preamble transmission is a non-orthogonal resource, operating at low utilization to avoid excessive interference from other UEs. For these reasons, the receive quality required for PRACH, i.e., the receive SINR, is higher compared to the uplink / downlink shared channel. This can be compensated for by higher transmit power, making power splitting between two ongoing transmissions very difficult and potentially significantly reducing cell coverage and / or the reliability of PRACH reception. Initiating an additional RACH procedure when the PRACH preamble message 1 of the first RACH procedure is transmitted on the uplink minimizes the latency of the additional RACH procedure. Only the transmission of the RACH preamble of the additional RACH procedure is delayed. However, compared to initiating the additional RACH procedure after messages 2 and 3, as mentioned above, the transmission / reception of the following messages may conflict, thus potentially relying on HARQ retransmission or gNB scheduler coordination for the two RACH procedures.

[0471] Figure 21 The illustration shows an embodiment for a time-shift appended RACH procedure. In response to the configuration of a slice-specific RACH resource configuration at S600, the UE performs a first RACH procedure associated with a trigger event or RACH event X1 in slice #1 at S602-S614 (see [link to documentation]). Figure 18 When a second triggering event X2 exists in the second slice #2 (see...) Figure 18 When referring to the above... Figure 20 The UE detects this triggering event X2 at S618. In response to detecting the triggering event for executing a second PRACH procedure, at S621 the UE determines that another RACH procedure is already being performed on another slice, and selects a slice / to-RACH resource configuration from multiple slice-specific RACH resource configurations, thereby selecting the actual RACH resource for transmission (e.g., sending preamble message 1). (Refer to reference...) Figure 20Unlike the previous embodiments described, in the current embodiment, the UE delays the initiation of the second RACH procedure, as shown in S626, until the end or completion of the first RACH procedure, as shown in S616, but initiates the second RACH procedure by: receiving message 3 for the first RACH procedure as shown in S628, or receiving message 2 for the first RACH procedure as shown in S630, or having already responded to sending RACH preamble message 1 for the first RACH procedure as shown in S632, performing the same steps as the first RACH procedure as shown in S606' and S608'.

[0472] The second RACH process on the second slice #2, when initiated before the first RACH process is completed, can be performed such that, in response to any of the above messages 1-3, parallel transmission of uplink signals (such as the PRACH preamble in message 1) is avoided.

[0473] Initiating an additional RACH procedure before the ongoing RACH procedure concludes is advantageous, for example, in terms of UE latency and power requirements. The overall uplink transmission power of a UE is limited; for example, a UE located at the cell edge may periodically use its maximum power for transmission. Therefore, power splitting between multiple concurrent RACH procedures is not desirable. Such power splitting can also be avoided when allowing concurrent RACH procedures minimizes parallel transmission in the uplink. For example, if two RACH procedures are triggered simultaneously or with a certain offset on different slice-specific RACH resources so that the RACH procedures at least partially overlap, the UE can first transmit the first RACH preamble of the slice-specific RACH resource configuration associated with slice #1, and time-shift the second RACH preamble for the slice-specific RACH resource configuration of slice #2 to a later time. For example, instead of using the immediately available RACH resources specified in the slice #2-specific RACH resource configuration, the second RACH procedure uses the RACH resources of the next configuration after this configuration for uplink preamble transmission. Figure 22 An example of using this time shift is illustrated. Figure 22 The diagram illustrates the triggering of RACH procedures associated with different slices in a network that supports parallel connections by the UE to multiple slices. This network is similar to the one referenced above. Figure 4 , Figure 6 and Figure 18 Similar to what is described. In Figure 22In the diagram, the first RACH event "1" is illustrated in slice #1 as occurring in subframe 2, causing the first RACH procedure to use RACH resource A defined by the RACH resource configuration specific to slice #1. For example, the first RACH procedure could use RACH resource A in subframe 4 to transmit a preamble. Assume the UE detects the second RACH event "2" in subframe 3, and the RACH resource configuration specific to slice #2 specifies... Figure 22 The RACH resource B shown in subframes 0, 2, 4, 6, and 8. According to the embodiment of delaying or suspending the second RACH process for a period of time, as described above, in order to avoid simultaneous uplink transmission by the UE, the RACH process for the second slice #2 does not use the RACH resource B in subframe 4, but instead uses the RACH resource B provided in subframe 6 to send the preamble message 1, thereby avoiding simultaneous transmission and the need for power segmentation or distribution between the two transmission processes for the two RACH processes, thus avoiding the situation where one or both transmissions are not received at the receiver (such as a base station or another network entity).

[0474] Preemption during the RACH process

[0475] In the embodiments described so far, the additional or second RACH process is blocked or paused for a period of time; however, the second aspect of the invention is not limited to such embodiments. According to a further embodiment, preemption of an ongoing RACH process can be implemented instead of waiting until a previous RACH process on a certain slice is completed or at least partially completed, as described above. For example, preemption of the ongoing RACH process by the additional or second RACH process can be implemented if it is determined that a second RACH process detected on a second slice while the first RACH process is in progress has a higher priority than the first RACH process, or if the second RACH process belongs to a slice with a higher priority than the first slice.

[0476] Figure 23 The illustration shows an example of RACH process preemption. Figure 23 In the middle, assuming the above reference Figures 18 to 22 Similar to the situation described above, i.e. Figure 18 UE 500 and other UEs in the example have configured or pre-configured the RACH resource configuration for a specific slice as shown in S600. At S602, the UE detects a trigger event X1 for performing a RACH procedure in slice #1, and at S604 selects a resource from the slice #1 RACH resource configuration for sending preamble message 1. Once a resource is selected from the slice #1 RACH resource configuration, the UE waits until the selected RACH resource becomes available, as shown in S634. Figure 23In this embodiment, assuming that when the UE is waiting for RACH resources at S634 for sending a preamble message for the first RACH procedure, as shown in S618, a triggering event X2 for executing the second RACH procedure in slice #2 is detected, and at S620 it is further detected that the first RACH procedure is in progress, i.e., it has not yet terminated or completed. According to this embodiment, after detecting the ongoing first RACH procedure at S620, the UE performs a RACH procedure preemption function at S636 according to one or more preemption criteria, which causes the UE to stop the first RACH procedure, as shown in S638. Therefore, step S604 of the first RACH procedure, i.e., sending preamble message 1 on the selected RACH resource, will not be executed. For example, the first RACH procedure may be preempted to support the second RACH procedure associated with the second slice because the priority of the second slice is higher than that of the first slice, or the event in the second slice has a higher priority than the event in the first slice that triggered the first RACH procedure. After performing the preemption function at S636, the UE begins the RACH procedure for the second slice, as shown in steps S606' to S616'. Based on this step, the corresponding messages are transmitted, as referenced above. Figure 20 The first RACH process is described.

[0477] Implementations of RACH preemption result in the stopping or aborting of a first ongoing RACH process to support a second RACH process. For example, such preemption may be undesirable when considering radio efficiency, UE power consumption, and user service, at least from the perspective of the first network slice. For instance, some uplink signal transmissions may have already completed, and it may be necessary to restart the process after the second process has finished. This may only come at the cost of additional transmission power. Furthermore, if the first process is aborted and only restarted after the second process has finished, the latency requirements of the first process may no longer be met. The more advanced the first RACH process, the higher the cost of aborting or ending the first RACH process to support the second RACH process. In extreme cases, the first RACH process may even be close to completion when it is aborted.

[0478] To address these issues, according to a further embodiment of RACH resource preemption, an ongoing RACH process can only be suspended to a certain stage. Once that stage or step is reached, the first RACH process continues to complete, while the second RACH process can run in parallel or be paused for a period of time, for example, as referenced above. Figures 20 to 22 The aforementioned method. For example, once the UE sends the RACH preamble in message 1, or receives RAR message 2 with uplink grant for transmission, or once it transmits message 3, the first ongoing RACH process no longer stops.

[0479] As mentioned above, in Figure 23 At S636, the UE can perform a preemption function based on one or more preemption criteria. Figure 23 In the two RACH processes shown, which one is pending completion and which one is pending preemption can be defined in different ways according to one or more of the following preemption criteria:

[0480] - Preemption criteria may include one or more parameters configured by the gNB in ​​the slice-specific RACH resource configuration of RRC, such as the assignment or configuration of relative RACH priority with relation to relative slice priority, QoS flow priority or logical channel priority, so that the RACH process associated with higher priority can preempt the RACH process associated with lower priority.

[0481] - Preemption criteria may include one or more specific events that trigger the RACH procedure, such as PDCCH command, handover, conditional handover, and RRC re-establishment. Therefore, the RACH procedure associated with the PDCCH command can preempt the RACH procedure associated with the handover event, conditional handover event, or RRC re-establishment event.

[0482] - In the case of uplink data transmission triggering the RACH process, when there is no scheduling request configured via PUCCH, the preemption criteria may include the type of data packet waiting to be transmitted, such as which logical channel or QoS flow the data packet belongs to, which PDN session or which slice identifier.

[0483] - In the case of uplink data transmission, preemption criteria may include one or more QoS attributes, such as the priority, latency, or reliability of the logical channel or data stream to which the data packet belongs. Therefore, a higher-priority RACH procedure can preempt a lower-priority RACH procedure, or a RACH procedure with low latency and high reliability can replace a RACH procedure used for data packets with minor latency.

[0484] - Preemption criteria may prioritize RRC control plane messages transmitted via the Signalling Radio Bearer (SRB) over user plane packets transmitted via the Data Radio Bearer (DRB). For example, a RACH procedure triggered by a gNB (such as a PDCCH command) may have a different priority than a RACH procedure triggered by a UE.

[0485] - Preemption criteria can include the entity that triggers the RACH process, i.e., whether it is triggered by the UE itself, by the gNB, or by another UE via a direct link, such as by the group leader UE, the roadside unit (RSU), etc.

[0486] Correcting the ongoing RACH process

[0487] According to an embodiment, to correct an ongoing RACH procedure, the UE can correct a specific message transmitted during the ongoing RACH procedure by including an indication of a second slice in addition to an indication of a first slice, so that the base station can provide parameters for the configuration of the first and second slices in response to the specific message. The UE can change the content of Msg3 if it has not yet been transmitted to the gNB. The Msg3 content may contain a MAC CE that notifies the gNB of an additional slice, such as slice #2, that triggered the RACH procedure; therefore, the gNB may decide to change its Msg4 using a different C-RNTI for the UE's communication for slice #2. Furthermore, Msg4 may also contain a list of C-RNTIs for each specific communication for the slice, such as [C-RNTI#slice #1, CRNTI#slice #2, etc.]. If the UE has already provided a C-RNTI for slice #1, then the gNB can provide the C-RNTI in Msg4 only for the missing C-RNTIs. Therefore, a specific message might be Msg3, which is modified to contain a different C-RNTI MAC or a different CCCH SDU, containing information for the first and second slices. For example, in the four-step RACH process described above with reference to Figure 12(a), Msg3 could be allowed to carry data to reduce latency and overhead. Although the UE reconnects to the network via slice 1, this data can also be used for slice 2. Typically, the parameters for the configuration of the first and second slices can be any type of RRC message, including RRC configuration or reconfiguration or RRC parameters.

[0488] According to other embodiments, in order to correct an ongoing RACH procedure to initiate an additional RACH procedure, the UE corrects a specific message transmitted during the ongoing RACH procedure, such as Msg3 as described above, by replacing the indication of the first slice with an indication of the second slice, so that the base station can provide parameters for the configuration of the second slice in response to the specific message. Therefore, unlike in the above embodiments where RACH messages are corrected by adding information for the second slice, in this embodiment, the information for the first slice is removed and replaced with information for the second slice, so that the base station only provides parameters for the configuration of the second slice.

[0489] Allow two or more RACH processes from different slices to be executed at least partially in parallel.

[0490] According to the above embodiments of the second aspect of the present invention, except for reference Figure 20In addition to the first embodiment where the second RACH process is aborted, the UE may allow two or more RACH processes to be executed simultaneously in an overlapping manner. Whether parallel RACH processes are supported and can be executed depends on the UE's implementation and capabilities. There may be different types of UEs; some support parallel reception and / or parallel transmission, while others may not support such functionality.

[0491] Therefore, according to an embodiment of the second aspect of the present invention, a UE is provided, such as Figure 18 UE 500, which is configured or pre-configured to support two or more concurrent RACH processes, each ongoing RACH process corresponding to a different slice of the network (e.g., Figure 18 Slices #1 and #2 in the network are associated. For example, a UE may be allowed to perform two or more PRACH procedures on different slices if the slices use different BWPs or operate on different carrier frequencies, where the frequency gap between a first radio frequency operating, for example on FR1, and a second radio frequency operating, for example on FR2, is Δx. The UE500 may indicate its ability to allow parallel PRACH procedures as a UE capability in its specification. The UE may report its capability to the gNB so that the network knows that the UE can perform two or more PRACH procedures simultaneously in parallel or overlapping manner. Figure 24 An embodiment for signaling UE capabilities is illustrated. The base station may send an RRC UE capability query "1" to the UE, and the UE responds by providing its capabilities in an RRC UE capability information message "2" sent to the base station. For example, when the UE first registers with the network, the gNB can query the UE by sending the aforementioned message "1," causing the UE to send its capabilities in the RRC UE capability query message "2." RRC signaling transmitted via the signaling radio bearer is received, decoded, and processed by the UE. The UE then responds to query "1" by sending the RRC UE capability information message "2" to the gNB. This message may contain slice-specific process-related information, such as the UE supporting multiple RACH configurations, supporting the RACH resource configuration selection function as described above with reference to the first aspect of the invention, and / or the UE supporting parallel RACH processes. This capability may relate to the overall RACH process capability, the capability of the receive portion (e.g., the capability to receive random access response messages in parallel), or the capability of the transmit portion (e.g., the capability to transmit RACH preambles in parallel), the capability of the entire RACH process, or the capability of only a part of the RACH process.

[0492] According to a further embodiment, in a wireless communication system or network, some or all UEs can support parallel RACH procedures. In this scenario, the gNB can adaptively configure whether to enable or disable parallel RACH procedures. According to embodiments, to reduce RACH procedure latency, it may be desirable to enable RACH procedures, for example, in the case of supporting slices with latency-critical services. On the other hand, disabling may be preferred for slices supporting mission-critical communications. For example, if an ongoing RACH procedure is associated with a mission-critical communications slice, it will not be preempted or aborted by another RACH procedure, and if the second procedure comes from a slice supporting mission-critical communications, an ongoing RACH procedure from another slice may be aborted to immediately allow the execution of the mission-critical communications RACH procedure. Allowing parallel RACH procedures may be a compromise when it comes to the reliability of RACH procedures. As mentioned above, when performing parallel RACH procedures, it may be necessary to divide the overall transmission power during parallel uplink transmission. For example, this parallel performance of the ongoing RACH procedure may be allowed for UEs near the cell center that are not transmitting at full power, while for UEs near the cell edge, this parallel performance may not be allowed / disabled.

[0493] According to an embodiment, the enabling / disabling of parallel RACH procedures can be signaled using RRC system information on a cell-by-cell basis or by sending an RRC reconfiguration message to the UE on a UE-specific basis. For example, information elements for enabling / disabling parallel RACH procedures can be added to the RRC rach-Config public or rach-Config private radio resource control information elements.

[0494] According to a further embodiment of the second aspect of the invention, UE 500 can execute up to N parallel RACH procedures with multiple (i.e., two or more) slice-specific RACH resource configurations, wherein the RACH procedures may be associated with certain priorities or preemption criteria. In other words, for each ongoing RACH procedure, UE can store the selected slice-specific RACH resource configuration, the RACH physical resources selected from the slice-specific RACH resource configuration, and the associated RA-RNTI, preamble identifier, and other relevant transmission parameters, such as transmission power, number of RACH attempts, etc.

[0495] Third aspect

[0496] An embodiment of the third aspect of the present invention will now be described.

[0497] ---------------------------------------------------------------------

[0498] UE

[0499] ---------------------------------------------------------------------

[0500] According to a third aspect, the present invention provides a user equipment (UE) for a wireless communication network.

[0501] The UE can connect to two or more of multiple network slices of a wireless communication network, wherein a slice-specific random access channel (RACH) configuration is associated with one or more of the multiple slices.

[0502] In this UE connection, for example, an RRC connection to a base station in a wireless communication network, the UE connects to the base station by performing a first RACH procedure using slice-specific RACH resource configuration associated with the first slice in response to a first RACH event associated with the first slice.

[0503] In response to a second event associated with the second slice and causing a second RACH procedure, the UE will skip the second RACH procedure using the slice-specific RACH resource configuration associated with the second slice.

[0504] According to an embodiment of the third aspect, the RACH process performed on the first slice or the second slice is followed by...

[0505] • Before executing the RACH procedure, if the UE is in RRC idle state, the RRC connection establishment procedure, or

[0506] • Before executing the RACH procedure, if the UE is in an RRC inactive state, the RRC connection recovery procedure will be performed.

[0507] According to an embodiment of the third aspect, the second event associated with the second slice and causing the second RACH process includes one or more of the following:

[0508] ·RACH incident,

[0509] • RRC connection established

[0510] • RRC connection restored.

[0511] According to an embodiment of the third aspect, the UE will use one or more connection parameters obtained through the first RACH and / or RRC connection establishment procedure for the second slice, wherein the one or more connection parameters may include one or more of the following:

[0512] • Schedule in advance

[0513] • Power control, such as transmission power,

[0514] • UE synchronization status

[0515] • UE connection status

[0516] • Cell-specific identifiers, such as C-RNTI,

[0517] • Intermittent reception (DRX) status, such as no DRX, short DRX, or long DRX.

[0518] • Radio link control status information, such as radio link failure (RLF) measurements and declarations.

[0519] • UE's RRC connection status

[0520] Beam ID,

[0521] MIMO mode

[0522] MCS

[0523] Channel state information, such as CSI, CQI, PMI, RI,

[0524] • Measurement results from neighboring communities

[0525] • Handover (HO) configuration or conditional HO configuration,

[0526] • Direct link measurement results, such as Channel Busy Ratio (CBR) or Congestion Ratio (CR) on a direct link.

[0527] According to an embodiment of the third aspect, the UE updates one or more connection parameters for the second slice via the first slice.

[0528] According to an embodiment of the third aspect, if the UE is transitioning from an RRC inactive state to an RRC connected state on the first slice before a second event associated with the second slice, the UE will send an RRC connection recovery request for the second slice.

[0529] According to an embodiment of the third aspect, the UE will use the first slice to maintain uplink synchronization with the base station, for example, by using a regular timing advance command sent from a MAC control element received from the base station on the first slice.

[0530] According to an embodiment of the third aspect, the UE will use the first slice to monitor the downlink radio link of the base station, for example, to monitor the quality of the downlink signal received from the signal transmitted by the base station on the first slice.

[0531] According to an embodiment of the third aspect, the UE will use the first slice to maintain DRX status with the base station, for example, by using a regular DRX command sent by the base station on the first slice through a MAC control element based on the regular uplink measurement results of the base station.

[0532] According to an embodiment of the third aspect, the UE will notify the second slice if it loses synchronization or radio link with the base station while in a connected state.

[0533] According to an embodiment of the third aspect, the UE applies the DRX state maintained by the first slice in the second slice, for example, by using slice-specific information exchanged directly between the first and second slices at the MAC layer or via a common RRC layer.

[0534] According to an embodiment of the third aspect, the UE applies uplink timing advance and / or power control maintained by the first slice to uplink transmission in the second slice, for example, by using slice-specific information exchanged directly between the first and second slices at the MAC layer or via a common RRC layer.

[0535] According to an embodiment of the third aspect, the UE configures or pre-configures a common control search space for the first and second slices, such as a common PDCCH search space, and a separate resource set for each of the first and second slices, such as a separate BWP, so that the UE can receive data on the first and second slices without performing a RACH procedure on one or more second slices.

[0536] According to an embodiment of the third aspect, in response to completing the RACH procedure on the first slice and becoming an RRC connection, the UE will receive one or more reconfiguration messages, which will use slice-specific uplink control resources (such as PUCCH) for scheduling requests on the first slice and one or more second slices to configure the UE.

[0537] According to an embodiment of the third aspect, one or more RRC reconfiguration messages include a separate RRC message for each slice or a single reconfiguration message for two or more slices, or a combination of both.

[0538] According to an embodiment of the third aspect, in response to an event triggering an uplink scheduling request in a slice, the UE will

[0539] • Select the uplink control resources for the appropriate slice to request uplink resources from the base station, for example, by performing the uplink control resource selection function or the PUCCH selection function.

[0540] • Receive downlink control signaling in the search space associated with the corresponding slice. The downlink control signaling includes the base station's allocation of uplink resources to the corresponding slice, and...

[0541] • Use slice-specific radio resources in the received uplink resource allocation to transmit user or control packets associated with the corresponding slice.

[0542] According to an embodiment of the third aspect, in response to completing the RACH procedure and becoming an RRC connection on the first slice, the UE will request downlink or uplink resources for the second slice.

[0543] • Send a scheduling request (SR) to the base station, where SR

[0544] o is the SR for the first slice that carries the SR for the second slice, or

[0545] o includes information that allows the base station to identify the second slice.

[0546] According to the embodiment of the third aspect, in response to the SR, the UE will receive one or more of the following from the base station:

[0547] • For DL ​​or UL grants of user or control data associated with the second slice,

[0548] • Rejection of providing resources for the second slice

[0549] • Notification sent to the UE regarding PRACHing of the first or second slice on different BWPs (e.g., FR2).

[0550] gNB only supports the second slice and discards notifications for the first slice.

[0551] According to an embodiment of the third aspect, in response to an event that triggers a corresponding uplink scheduling request simultaneously or within a certain time window in two or more slices, the UE prioritizes or preempts the scheduling request, wherein preemption may take into account the association between uplink data and slices and the event that triggers uplink data transmission.

[0552] According to an embodiment of the third aspect, the user equipment includes one or more of the following: a mobile terminal, or a fixed terminal, or a cellular IoT-UE, or an in-vehicle UE, or an in-vehicle group leader (GL) UE, or a direct link relay, or an IoT or narrowband IoT (NB-IoT) device or a wearable device (such as a smartwatch, or a fitness tracker, or smart glasses), or a ground vehicle, or an aircraft, or a drone, or a mobile base station, or a roadside unit (RSU), or a building, or any other item or device (e.g., a sensor or actuator) that provides network connectivity enabling the item / device to communicate using a wireless communication network; or any other item or device (e.g., a sensor or actuator) that provides network connectivity enabling the item / device to communicate using a direct link of a wireless communication network, or any network entity with direct link capability.

[0553] ---------------------------------------------------------------------

[0554] system

[0555] ---------------------------------------------------------------------

[0556] According to a third aspect, the present invention provides a wireless communication system comprising one or more inventive user equipment (UE) and / or one or more inventive base stations (BS).

[0557] ---------------------------------------------------------------------

[0558] method

[0559] ---------------------------------------------------------------------

[0560] According to a third aspect, the present invention provides a method for operating a user equipment (UE) in a wireless communication network, wherein the UE can connect to two or more of a plurality of network slices of the wireless communication network, wherein a slice-specific random access channel (RACH) configuration is associated with one or more of the plurality of slices, wherein the UE connects, for example, an RRC connection, to a base station of the wireless communication network, and the UE connects to the base station by performing a first RACH procedure using a slice-specific RACH resource configuration associated with the first slice in response to a first RACH event associated with the first slice, the method comprising:

[0561] In response to a second event associated with the second slice and causing a second RACH process, the second RACH process is skipped using the slice-specific RACH resource configuration associated with the second slice.

[0562] Figure 25 The illustration depicts an embodiment of a UE 700 that can connect to two or more network slices of a wireless communication network. Slice-specific RACH resource configurations are associated with one or more of the multiple slices. Figure 25 In the illustrated embodiment, it is assumed that UE 700 is connected to the reference above. Figure 4 , Figure 6 and Figure 18 The network mentioned above. Figure 25 The network configuration shown is as described above. UE 700 is connected to two slices, namely slice #1 and slice #2, in parallel or simultaneously. The UE may include a processor 702, which, in response to a first RACH event X1 detectable by the UE, as shown in 702a, executes an X1 RACH procedure, as shown in 702b. Assuming the X1 RACH procedure has completed, in response to the first RACH procedure, UE 700 is connected to the base station by RRC and is also uplink synchronized. At a later time, for example in subframe 5, a second RACH event X2 occurs after the X1 RACH procedure has completed. This second RACH event X2 is detected by UE 700, as shown in 700c, and according to the third aspect of the invention, UE 700, because it is already uplink synchronized and connected to the base station by RRC, does not execute any X2 RACH procedure, as shown in 702d. In other words, after completing the first RACH procedure, in response to the second RACH event associated with the second slice, the UE uses the slice-specific RACH resource configuration associated with the second slice to not perform or skip the second RACH procedure.

[0563] exist Figure 25In one embodiment, the UE is connected to two slices; however, the invention is not limited to such an embodiment, and the UE may be connected to more than two slices in parallel. In such an embodiment, if the UE has completed the RACH procedure for one slice (the first slice), it will skip one or more RACH procedures for any other slice (one or more second slices) to which the UE is also connected.

[0564] Therefore, according to an embodiment of the third aspect of the invention, the UE can maintain a connection by one of the slices, while data can be sent and received by all other slices to which the UE is connected. In other words, there is only a single RRC state across all slices to which the UE is connected. On the UE and gNB sides, since there is a single RRC state on all slices, all slices know that the UE has moved to the RRC connected state and uplink synchronization has been performed. Based on the UE identifier and the UE context information stored in the RRC layer, the gNB knows which slice the UE has actually registered to or connected to. The first slice to which the UE performs the first RACH procedure can be called the primary slice.

[0565] According to the embodiment, after the RACH procedure performed on the first slice, if the UE was in an RRC idle state before performing the RACH procedure, the next step can be an RRC connection establishment procedure; or if the UE was in an RRC inactive state before performing the RACH procedure, the next step can be an RRC connection recovery procedure.

[0566] According to an embodiment, the second event associated with the second slice and causing the second RACH process may include one or more of the following: RACH event, RRC connection establishment, and RRC connection recovery.

[0567] According to an embodiment, the UE can use one or more connection parameters obtained through the first RACH and / or RRC connection establishment procedure for the second slice. The one or more connection parameters may include one or more of the following:

[0568] • Scheduled advance (TA)

[0569] • Power control, such as transmission power,

[0570] • UE synchronization status

[0571] • UE connection status

[0572] • Cell-specific identifiers, such as C-RNTI,

[0573] • Intermittent reception (DRX) status, such as no DRX, short DRX, or long DRX.

[0574] • Radio link control status information, such as radio link failure (RLF) measurements and declarations.

[0575] • UE's RRC connection status

[0576] Beam ID,

[0577] MIMO mode

[0578] MCS

[0579] Channel state information, such as CSI, CQI, PMI, RI,

[0580] • Measurement results from neighboring communities

[0581] • Handover (HO) configuration or conditional HO configuration,

[0582] • Direct link measurement results, such as Channel Busy Ratio (CBR) or Congestion Ratio (CR) on a direct link.

[0583] According to an embodiment, the UE updates one or more connection parameters for the second slice via the first slice.

[0584] According to an embodiment, when the UE transitions from an RRC inactive state to an RRC connected state on the first slice prior to an event associated with the second slice, it sends an RRC connection restoration request for the second slice. In other words, events in the second slice are considered to originate from an inactive state, not from an idle state. This is advantageous because it saves RRC signaling.

[0585] According to an embodiment, the primary slice may be responsible for monitoring the downlink radio link of the base station using the first slice, for example, monitoring the downlink signal quality received from signals transmitted by the base station on the first slice. For UE-initiated traffic, in the 5G QoS framework, the UE maps UL packets to QoS flows, and then maps the QoS flows to resources in the access network (AN). If the UE sees stable resources on the first slice, it may notify the application to trigger a "PRACH" for services requiring this QoS. Alternatively, the UE can maintain this state, allowing the "PRACH" to continue only if the QoS flow can be supported, for example, when the AN resources are good enough or have been good enough for a certain period of time according to a threshold. As used above, "PRACH" refers to the UE not actually performing a PRACH, but rather using the communication channel established by the PRACH on the first slice for the second slice.

[0586] According to an embodiment, the primary slice may be responsible for maintaining the DRX state with the base station using the first slice, for example, by using regular DRX commands sent by the base station on the first slice through the MAC control element based on the base station's regular uplink measurement results. For example, the UE may apply the DRX state maintained by the first slice to the DRX state in the second slice, for example, by using slice-specific information exchanged directly between the first and second slices at the MAC layer or via the common RRC layer.

[0587] According to an embodiment, the primary slice is responsible for maintaining uplink synchronization. Uplink synchronization can be maintained periodically, such as by sending timing advance commands from the base station to the UE at fixed times or time intervals, which may be based on uplink measurements at the gNB. The primary slice can be configured for frequent uplink transmissions by the UE to allow the gNB to perform uplink measurements and respond to them, for example, by sending timing advance commands via a MAC control element. This method can be used, for example, when the UE transmits data periodically (e.g., at intervals not exceeding a certain threshold). If there is no such periodic data transmission, or if the UE does not transmit data for a certain period, the UE can transmit a Sounding Reference Symbol (SRS) configured by the gNB. The gNB can measure the UE's uplink timing based on the SRS transmitted by the UE. In the event of uplink synchronization loss, when the UE is in an RRC connected state, according to an embodiment, the primary slice will also notify other slices of the synchronization loss.

[0588] According to an embodiment of the third aspect of the invention, one or more additional slices, also known as auxiliary slices, are aware of the uplink timing advance obtained when performing the RACH procedure on the primary slice. The auxiliary slice applies the uplink timing advance maintained by the primary slice. If slice-specific MAC entities are provided, information about the timing advance can be exchanged between the MAC entities of the primary and auxiliary slices, either directly or via a common RRC layer. Since the timing advance is maintained by a single slice, the primary slice, any overhead for maintaining the timing advance on all slices is reduced. For example, the uplink timing advance loop can be executed only on the primary slice, rather than independently in each slice.

[0589] According to further embodiments, the UE may configure or pre-configure a common control search space, such as a common PDDCH search space, and a dedicated data search space, such as a dedicated bandwidth portion (BWP), for each slice, so that the data search space uses isolated resources for the corresponding slice. Configuration can be performed via system information or via dedicated RRC signaling. According to these embodiments, once the primary slice connects the UE to the base station and provides uplink synchronization via the RRC procedure, the gNB can signal downlink data transmissions to any slice via the common PDDCH search space and send data to the data space known to the UE for any slice.

[0590] Uplink control resource configuration selection function

[0591] According to a further embodiment of the third aspect of the invention, an uplink control resource configuration selection function is provided. Once the UE completes the RACH procedure on the primary slice, the UE enters an RRC connected state and begins monitoring the control search space of the primary slice, and, if configured or pre-configured, also monitors the control search space of one or more secondary slices. The control search space can be a BWP, CORESET, or PDDCH search space.

[0592] In response to information indicating that the UE has moved to an RRC connected state, the RRC layer can configure uplink control resources, such as PUCCH, for scheduling requests on one or more secondary slices, unless these have been previously configured or pre-configured. In other words, the UE can receive, for example, one or more reconfiguration messages from the base station to configure uplink control resources for a slice, allowing the corresponding slice to send resource scheduling requests to the base station for uplink transmission. The RRC reconfiguration message can be dedicated to each slice in a separate RRC message or be a single reconfiguration message for all slices. Once configured, the UE has uplink control resources to send scheduling requests for the first or primary slice and one or more additional or secondary slices. Therefore, the gNB configures multiple slice-specific uplink control resources for sending slice-specific scheduling requests, and once data packets need to be transmitted in the uplink, the UE can perform an uplink control resource selection function, also known as a PUCCH selection function, which can reside within the UE transceiver.

[0593] On the UE side, the UE selects uplink control resources for the corresponding slice based on the event that triggers the uplink scheduling request, in order to request uplink resources from the gNB. This process is essentially the same as the process or mechanism of the RACH resource configuration selection function described above with reference to the first aspect of the present invention, except that, in response to the RACH triggering event, an appropriate slice-specific uplink control resource is selected for the slice from which the triggering event originated.

[0594] Upon receiving an uplink scheduling request, the gNB determines which slice the UE is requesting uplink data resources for, based on uplink control resources or the specific PUCCH channel selected by the UE. Based on this association, the gNB responds by allocating uplink resources for the corresponding slice by transmitting downlink control signaling, such as PDCCH, in the common control search space or the control search space associated with the slice. In response to receiving the uplink resource allocation, the UE uses slice-specific radio resources and transmits data packets associated with the slice.

[0595] According to this embodiment of the third aspect of the invention, the UE does not need to perform a slice-specific RACH resource configuration selection function because the RACH procedure has already been performed, for example, on the primary slice, and the UE has already been RRC connected. Instead, the UE, having already configured multiple uplink control resources for an uplink scheduling request, can perform a slice-specific PUCCH resource configuration selection function to obtain PUCCH resources for an uplink scheduling request associated with a particular slice. Control packets or data packets can be associated with the slice from which they originate, for example, by a slice identifier, as described above with reference to the first aspect of the invention.

[0596] According to embodiments, the uplink control resource selection function may only be required when uplink data transmission is suspended and when the UE is already connected via RRC. When the UE moves from an RRC connected state to an RRC inactive or RRC idle state, any suspended uplink data transmission on a slice requires a RACH procedure to reconnect the UE to the network or base station. Therefore, according to embodiments, when the UE reconnects from an RRC idle or RRC inactive state to an RRC connected state, and if the network supports slice-specific RACH resource configuration, a slice-specific RACH resource configuration selection function can be performed. On the other hand, the PUCCH uplink control resource selection function can be performed when the UE is in an RRC connected state and multiple slice-specific uplink control resources for uplink scheduling requests are configured on the corresponding slice as described above, and a slice buffer status report is sent when there is no other ongoing data on the slice.

[0597] According to other embodiments regarding resource requests, in response to completing the RACH procedure on the first slice and becoming an RRC connected state, the UE sends a scheduling request (SR) to the base station, requesting downlink or uplink resources for the second slice. The SR may be an SR for the first slice carrying an SR for the second slice, or it may include information allowing the base station to identify the second slice. In response to the SR, the UE may receive one or more of the following from the base station:

[0598] • DL or UL grants for receiving user or control data associated with the second slice from the base station.

[0599] • Rejection of providing resources for the second slice

[0600] • Notification sent to the UE regarding PRACHing of the first or second slice on different BWPs (e.g., FR2).

[0601] gNB only supports the second slice and discards notifications for the first slice.

[0602] Prioritization / preemption of scheduling requests

[0603] According to a further embodiment of the third aspect of the invention, scheduling requests on slice-specific PUCCH uplink control resources can be prioritized or preempted. When multiple slice-specific scheduling requests are configured and multiple uplink packets arrive simultaneously or within a certain time window, prioritization or preemption of the scheduling requests can be performed on the PUCCH, for example, in a manner similar to the prioritization / preemption of the RACH process described above according to the second aspect of the invention. Preemption can take into account the association between uplink data and the slice in the event that triggers uplink data transmission; that is, the same preemption criteria described above with respect to the second aspect of the invention can be used.

[0604] generally

[0605] Although relevant aspects and embodiments of the method of the present invention have been described separately, it should be noted that each aspect / embodiment may be implemented independently of the other, or some or all aspects / embodiments may be combined. Furthermore, the embodiments described subsequently can be used in conjunction with the various aspects / embodiments described so far.

[0606] Monitoring multiple Random Access Response (RAR) messages

[0607] In the above-described embodiment of the second aspect of the invention, the UE monitors RAR messages for any RACH procedure being executed. In the case of parallel execution of RACH procedures, for example, by prohibiting or time-shifting the parallel transmission of multiple PRACH preambles (message 1), the UE is allowed to monitor multiple Random Access Response (RAR) messages, message 2, in the downlink corresponding to multiple RACH resource configurations. The RAR response messages can be provided on normally configured downlink resources or on separately configured downlink resources (e.g., slice-specific downlink resources).

[0608] Further Examples

[0609] The following embodiments can be used in all aspects of the invention described herein.

[0610] According to an embodiment regarding monitoring multiple random access response messages, a common search space or bandwidth portion (BWP) shared by all slices can be used. If downlink resource isolation requirements between corresponding slices are not stringent, a common downlink resource can be configured for the UE to receive RAR messages. This is advantageous because it is more radio efficient due to the multiplexed resources and lower complexity, and more power efficient for the UE because only one downlink resource needs to be monitored. According to an embodiment, the common search space can be a bandwidth portion, and the UE can have only one common or default bandwidth portion (BWP), within which a control resource set (COREST) ​​for the common PDCCH search space can be configured. The UE continuously monitors the same common search space to receive RAR messages. The UE can also receive paging messages for all slices on the same common search space. According to this embodiment, different RAR messages corresponding to different slice-specific RACH resource configurations can be distinguished, for example, by splitting the RACH resource and RA-RNTI, or by splitting the preamble identifier, or by adding an additional RA-RNTI or preamble identifier, or by introducing a slice-specific RACH resource configuration index or slice resource index to be sent in the downlink.

[0611] According to an embodiment, the additional information used to distinguish RAR messages described above can be signaled as part of a MAC PDU used for random access response MAC RAR. MAC RAR is described in reference [6]. The UE can transmit RACH on any slice-specific RACH resource configuration. The RACH resource configuration selection function selects the appropriate resource. In addition to the regular RA-RNTI and regular random access preamble identifier (RAPID) corresponding to the RACH resource, the UE can also store a new RACH resource configuration index or any other index associated with a specific slice. After the uplink transmission of message 1, the UE monitors the PDCCH common control resource using the specific RA-RNTI corresponding to the specific resource RACH. The UE decodes the data packet and looks up the RAPID stored in the MAC header.

[0612] Figure 27 The diagram illustrates a traditional MAC header including the extended field E, which is a flag indicating the presence of additional fields in the MAC header. A value of "1" for the E field indicates that at least one more field is present, such as... Figure 27The MAC header contains the T and RAPID fields. The T field is a flag indicating whether the MAC header contains a Random Access ID or a Backoff indicator. A T value of 0 indicates the presence of a Backoff indicator field, and a T value of 1 indicates the presence of a Random Access Preamble ID (RAPID) field. The RAPID field, or Random Access Preamble Identifier field, identifies the transmitted random access preamble and may be 6 bits in size.

[0613] According to other embodiments, Figure 27 The MAC header can be like Figure 27 The method is extended to identify the slice-specific RACH resource configuration of the uplink used by the UE. For example, a second octet, 8 bits, can be added to uniquely identify the uplink RACH resource configuration. The first octet corresponds to... Figure 27 The header structure is expanded by the second octet mentioned above. The UE can compare the slice / RACH resource configuration index with the slice / RACH resource configuration index stored in the uplink transmission, and if the indices are the same, the UE continues to read the MAC RAR message.

[0614] According to other embodiments, the slice / RACH resource configuration index can also be in, for example... Figure 28 The traditional MAC RAR message shown is added to the MAC RAR message. The traditional RAR message consists of 7 octets. The first octet includes the reserved field R and the timing advance command, which also extends to the second octet. The second part of the second to fifth octets includes uplink grant information, while the sixth and seventh octets include the temporary C-RNTI to be used.

[0615] Figure 29 An example of a modified MAC RAR message is illustrated, which includes an eighth octet for defining a slice, bandwidth portion, or uplink resource index. The UE can be configured such that the uplink grant of the received MAC RAR points to a different uplink resource previously configured, for example, via RRC signaling for this slice. This can be achieved, for example, by configuring a different carrier, a different BWP, or any other uplink resource configuration. The UE previously receives and stores a slice or RACH resource configuration-specific configuration via RRC system information or dedicated RRC signaling. Based on which slice-specific RAC resource configuration is used during random access, the UE knows which carrier, bandwidth portion, etc., the uplink grant of the MAC RAR points to. Where a fixed mapping is not desired, a slice, bandwidth portion, or any other uplink resource configuration index can be added to the MAC RAR at the expense of additional signaling overhead, such as... Figure 29 As shown.

[0616] According to other embodiments, instead of using a common search space, a separate search space or bandwidth portion, such as a slice-specific search space, can be used. With such an embodiment, complete resource isolation in the downlink is expected, requiring separate physical downlink resources to be configured to receive different RARs corresponding to different RACH procedures associated with different slice-specific RACH resource configurations. The UE monitors slice-specific bandwidth portions and / or CORESET and / or PDCCH search spaces to receive downlink control information related to specific uplink random access associated with a specific slice. The gNB can configure the UE using system information and / or dedicated RRC signaling to inform the UE of the specific downlink resources that need to be monitored, depending on the RACH resource configuration already used in the uplink.

[0617] According to one embodiment, to limit UE complexity, parallel RACH processes on different RACH resource configurations can be prohibited; otherwise, the UE would have to monitor multiple downlink control resource configurations and different frequency bands. In other embodiments, different TDM modes can be configured for different slices, and the modes can be arranged such that the UE only needs to monitor a single downlink control resource configuration at a time.

[0618] Parameters for slice-specific RACH resource configuration

[0619] According to embodiments of all aspects of the present invention, slice-specific RACH resource configurations specify one or more resource configurations and one or more parameters for the RACH process, such as

[0620] • PRACH preamble, including, for example, preamble format, preamble sequence, sequence length, subcarrier spacing for the preamble, cyclic prefix, guard time length,

[0621] • Beam index

[0622] • Triggering events for switching beams

[0623] • Resources used for PRACH, such as time and / or frequency and / or space resources,

[0624] • One or more parameters used to determine one or more root sequences and their cyclic shifts in a set of PRACH preamble sequences.

[0625] • Index of the logical root sequence list

[0626] • Cyclic displacement, N CS ,

[0627] • Set type, such as unrestricted set A or restricted set B.

[0628] Cloud RAN Implementation

[0629] In the above description of embodiments of the first, second, and third aspects of the present invention, it is assumed that the wireless communication network includes a radio access network and a core network, wherein the radio access network is formed by non-distributed devices. However, the present invention is not limited to such a RAN implementation, and, according to further embodiments of the first, second, and third aspects of the present invention, the RAN can be embedded as a cloud RAN (C-RAN).

[0630] The present invention provides a wireless communication system comprising one or more inventive user equipment (UE) and / or one or more inventive base stations (BS).

[0631] According to an embodiment,

[0632] • Wireless communication networks provide multiple network slices, and

[0633] The radio access network (RAN) of a wireless communication network includes a cloud RAN (C-RAN), which comprises multiple slice-specific distributed units (DUs) and one or more central units (CUs) shared by some or all slices.

[0634] According to an embodiment,

[0635] • One or more of the slice-specific DUs in C-RAN support a single slice, and / or

[0636] One or more slice-specific DUs in C-RAN support multiple slices.

[0637] According to an embodiment, the wireless communication network depends on one or more specific requirements of a slice, such as depending on one or more of the items, to provide slice-specific DUs for the C-RAN:

[0638] • Required redundancy level,

[0639] • Required fronthaul interface and power supply

[0640] • Reliability, such as error rate, BER, PER,

[0641] • Delay

[0642] • Throughput

[0643] • Service type, such as special services like emergency services,

[0644] • Subscriber groups, for example, only UEs belonging to a specific subscriber group are authorized to use this service.

[0645] • Tenants or customers.

[0646] According to an embodiment, each DU has one or more slice-specific RACH resource configurations for slices supported by the respective DU.

[0647] According to an embodiment,

[0648] • The DU is configured or pre-configured with one or more slice-specific RACH resource configurations for slices supported by the DU, or

[0649] The CU will configure the DU using one or more slice-specific RACH resource configurations for slices supported by the DU.

[0650] According to an embodiment, the DU will send or receive one or more slice-specific RACH resource configurations to or from the CU via a specific interface protocol, such as the fronthaul interface 1 (F1) protocol.

[0651] According to an embodiment, the DU will send or receive one or more slice-specific RACH resource configurations during the DU setup process or DU update process.

[0652] According to the embodiments, the DU update process includes a DU configuration update process or a CU configuration update process.

[0653] In the case of a DU configuration update, the DU will update one or more slice-specific RACH resource configurations for the slices it supports, and

[0654] In the case of a CU configuration update process, the CU will update one or more slice-specific RACH resource configurations for slices supported by the DU.

[0655] According to an embodiment, in the case of two or more parallel RACH processes, each RACH process is associated with a different slice, and the DU will coordinate the parallel RACH processes to avoid any parallel transmission or reception during the two or more parallel RACH processes.

[0656] According to an embodiment, the DU will coordinate some or all of the RACH messages in parallel RACH processes, such as RACH preamble messages 1 and 2, 3 and 4 in a 4-step RACH process, or messages A and B in a 2-step RACH process, so as to avoid any parallel transmission or reception during two or more parallel RACH processes.

[0657] According to an embodiment, in order to coordinate the ongoing RACH process, DUs communicate with each other only via CUs, thereby avoiding inter-DU signaling.

[0658] According to the implementation example, coordination is done on a slicing basis.

[0659] While slice-specific RACH resource configurations can be determined within a base station or gNB in ​​the RAN in the embodiments described so far, further embodiments of the invention may require coordination between different entities. Without excluding inter-gNB signaling for coordinating slice-specific RACH resource configurations via the Xn / X2 interface, distributed units (DUs) can be used in the C-RAN to coordinate different slice-specific RACH resource configurations. A 5G network supporting a wide range of slices can be provided, and the network can deploy slice-specific DUs, with the central unit (CU) in the C-RAN potentially shared by some or all slices provided by the network.

[0660] Figure 30 The illustration shows an embodiment of a wireless communication network including a C-RAN implementation. More specifically, Figure 30 The diagram illustrates an NG-RAN architecture according to 3GPP TS38.300. The wireless communication network includes a radio access network 750 and a core network 752. The radio access network 750 includes a first non-distributed base station 754 and a distributed base station 756. In other words, RAN 750 includes a non-distributed RAN 750a and a distributed RAN or C-RAN 750b. The C-RAN implemented base station 756 includes a central unit CU 758 and two distributed units DU 760a and 760b in the depicted embodiment. The respective base stations 754 and 756 communicate with the core network 752 via their respective NG interfaces and with each other via an Xn interface. In the distributed base station 756, the distributed units 760a and 760b communicate with the central unit 758 via a fronthaul interface 1 (F1).

[0661] There may be different reasons for sharing slice-specific DUs in a multi-slice network. For example, services associated with different slices may require different DUs.

[0662] ·DU's sites are protected in different ways, or

[0663] Different redundancy levels, or

[0664] Different fronthaul or backhaul interfaces, or

[0665] Different power sources.

[0666] For example, mission-critical networks may use different DU hardware compared to commercial DU hardware to meet the higher requirements associated with the mission-critical services provided. Because the CU is located more centrally, it may be easier to provide the required levels of security and redundancy across all network slices. Therefore, a DU operating a mission-critical service, such as emergency calls, can only be configured to support a specific "emergency" slice. CUs connected to or associated with the aforementioned DUs may still support additional services, such as eMBB services, which operate in different networks, thus using different networks for the DUs. It is important to note that DU networks can also include nodes configured to use integrated access and backhaul (IAB) networks with specific fronthaul and backhaul technologies.

[0667] According to a further embodiment, the slice-specific DU of C-RAN may be provided based on one or more specific requirements of the slice, for example, based on one or more of the following:

[0668] • Required redundancy level,

[0669] • Required front-end or back-end interface, power supply

[0670] • Reliability, such as error rate, BER, PER,

[0671] • Delay

[0672] • Throughput

[0673] • Service type, such as special services like emergency services,

[0674] • Subscriber groups, for example, only UEs belonging to a special subscriber group are authorized to use this service.

[0675] • Tenant or customer.

[0676] When the RAN is implemented as C-RAN, the UE is unaware that connecting to two or more network slices may be via different DUs. However, when slice-specific DUs are implemented in a C-RAN network, different DUs require a corresponding number of RACH procedures because they may be located in different physical locations, and therefore each DU may apply different independent timing advances, which is necessary to keep each site synchronized. When DUs are located in different physical locations, each DU may have its own slice-specific RACH resource configuration. The slice-specific RACH resource configuration can be determined by the CU or the DU. According to an embodiment, when a DU is being set up, it is pre-configured before installation, for example, as part of radio and network planning, or it will establish a secure connection with the management network based on internal configuration and download configuration parameters from the operations and maintenance server. This operation may be proprietary. The configuration parameters specifically include the slices the DU will support, the CU the DU will connect to, etc. This pre-configuration of the DU may also include slice-specific RACH resource configurations. Some of these parameters may be passed from the DU to the CU in an F1 setup request message. While it might be desirable for each DU to determine its own radio resource configuration to optimize resources within the cell, according to a further embodiment, the CU can determine the configuration because it has better knowledge of efficiently coordinating resources across multiple cells and / or multiple DUs. The respective entities need to communicate with each other and share configuration data. Embodiments for sharing configuration data, i.e., the corresponding slice-specific RACH resource configuration, are now described.

[0677] Figure 31 The illustration depicts an embodiment of providing slice-specific RACH resource configurations to the DU via the CU. The configuration details of the slice-specific RACH resource configuration can be exchanged over the Fronthaul Interface 1 (F1) protocol defined in 3GPP TS38.473. Figure 31 As shown, the initial configuration can be exchanged as part of a setup process, which includes an F1 setup request transmitted from the DU to the CU, and the CU responding with a setup response, which includes a slice-specific RACH resource configuration for the corresponding DU.

[0678] According to a further embodiment, for example, changes in the configuration can be transmitted using a gNB-DU or a configuration update procedure. Figure 32 illustrates an embodiment of a slice-specific RACH resource configuration update procedure, where Figure 32(a) illustrates a successful gNB-DU update procedure, and Figure 32(b) illustrates a failed gNB-DU update. In Figure 32(a), the gNB-DU performs cell-level measurements, such as RACH load, RACH failure rate, etc. For example, depending on the RACH load, the gNB-DU can increase or decrease slice-specific RACH resources for a corresponding slice-specific RACH resource configuration configured or pre-configured by the gNB-DU. Depending on the RACH failure rate, the gNB-DU can configure different preamble formats in the slice-specific RACH resource configuration. These updates or changes are performed on the DU and the update is signaled to the gNB-CU using a gNB-DU configuration update message, which in turn confirms the update with a gNB-DU configuration update acknowledgment message, as shown in Figure 32(a). In response to the acknowledgment, the gNB-DU begins further RACH procedures using the updated configuration. If the update sent to the gNB-CU is not accepted or is not possible, the gNB-CU will respond with a gNB-DU configuration update failure, as shown in Figure 32(b). Therefore, in response to the failure message, the UE will not use the updated parameters, but will retain the current or original parameters.

[0679] According to other embodiments, as mentioned above, the gNB-CU can also make decisions regarding modifications to slice-specific RACH resource configurations. Making such decisions in the gNB-CU can be advantageous because the CU can also consider slice-specific RACH resource configurations of neighboring cells (such as neighboring DUs), thereby potentially avoiding resource conflicts, for example. Figure 33 The illustration shows an embodiment of the gNB-CU configuration update process, in which the CU sends a gNB-DU resource coordination request to the DU after deciding to update the configuration. The DU responds with a gNB-DU response coordination response, which indicates that the update has been received and is being used at the DU.

[0680] According to an embodiment, when the CU makes a decision regarding the slice-specific RACH resource configuration update of the DU, the DU can support the CU, for example, by providing the CU with cell-level measurements such as RACH utilization, load factor, or RACH failure / success rate. Alternatively, when the DU makes a decision, the CU can provide information about resources used or not used in neighboring cells for RACH, or information about certain resources expected to experience low interference, which may then be used as other resources in the RACH process. This additional information can be exchanged in corresponding signaling messages between the CU and the DU.

[0681] RACH process coordination across gNB-DU

[0682] As described above with reference to the second aspect of the invention, parallel RACH processes can be allowed because such parallel RACH processes can benefit latency reduction in 5G networks that extensively utilize slices. However, depending on UE capabilities and transmit / receive requirements, it may be desirable to avoid parallel transmission and reception of RACH messages. As part of the gNB implementation, the base station can internally coordinate any additional RACH processes with already performed RACH processes. Within a certain window, for example, the RACH reception window for message 2, during which the UE that has sent the RACH preamble waits for downlink RAR message 2, the gNB can schedule its downlink messages 2 and 4, as well as allocate the transmission of uplink message 3 for the UE. Therefore, according to an embodiment, the gNB can shift the corresponding messages to avoid parallel transmission or reception during two or more parallel RACH processes from different slices. According to a further embodiment, in C-RAN, as described above with reference to Figure 30 The scheduling decisions are made by the DUs, and DUs associated with different network slices communicate these scheduling decisions. According to an embodiment, communication between DUs is conducted via the CU, thereby avoiding signaling between DUs. According to an embodiment, excessive signaling can be avoided by performing resource coordination for slice-specific RACH procedures on a slice-by-slice basis, rather than on a UE-by-UE basis. Therefore, according to an embodiment, in addition to the coordinated slice-specific RACH preamble, resources for RACH messages 2, 3, and 4 can also be coordinated to avoid conflicting transmission or reception. This will result in some scheduling constraints on corresponding messages on the uplink and downlink shared channel PUSCH / PDSCH, leading to some latency. This latency is acceptable because message conflicts in RACH procedures of different slices can be avoided. According to an embodiment, this scheme is only required if the network supports UEs that can connect to multiple slices simultaneously. In addition to the messages for four-step or four-way CBRA procedures described above, messages for two-step or two-way CBRA procedures can also be coordinated in the manner described above.

[0683] generally

[0684] According to embodiments, a wireless communication system may include a terrestrial network, or a non-terrestrial network, or a network or network segment that uses an airborne or spaceborne aircraft as a receiver, or a combination thereof.

[0685] According to embodiments of the present invention, the user equipment includes one or more of the following: a power-limited UE, or a handheld UE, such as a UE used by pedestrians and referred to as a vulnerable road user (VRU) or pedestrian UE (P-UE), or a personal or handheld UE used by public safety personnel and first responders and referred to as a public safety UE (PS-UE), or an IoT device. UE, such as sensors, actuators, or UEs that provide repetitive tasks and require periodic input from gateway nodes on a campus network, mobile terminals, or fixed terminals, or cellular IoT-UEs, or vehicle-mounted UEs, or vehicle group leader (GL) UEs, or direct link relays, or IoT or narrowband IoT (NB-IoT) devices, or wearable devices such as smartwatches, or fitness trackers, or smart glasses, or ground vehicles, or aircraft, or drones, or mobile base stations, or roadside units (RSUs), or buildings, or any other item or device that provides network connectivity enabling the item / device to communicate using a wireless communication network (e.g., sensors or actuators), or any other item or device that provides network connectivity enabling the item / device to communicate using a direct link to a wireless communication network (e.g., sensors or actuators), or any network entity with direct link capability.

[0686] According to embodiments of the present invention, a base station includes one or more of the following: a macro cell base station, or a small cell base station, or a central unit of a base station, or a distributed unit of a base station, or a roadside unit (RSU), or a UE, or a group leader (GL), such as a GL-UE, or a relay or remote radio head, or an AMF, or an MME, or an SMF, or a core network entity, or a mobile edge computing (MEC) entity, or a network slice in an NR or 5G core environment, or any transmit / receive point (TRP) that enables an item or device to communicate using a wireless communication network, wherein the item or device is provided with network connectivity to communicate using a wireless communication network.

[0687] Although certain aspects of the described concepts have already been described in the context of the apparatus, it is clear that these aspects also represent a description of the corresponding method, where boxes or devices correspond to method steps or features of method steps. Similarly, aspects described in the context of method steps also represent a description of corresponding boxes, items, or features of the corresponding apparatus.

[0688] The various elements and features of this invention can be implemented in hardware using analog and / or digital circuits, in software by executing instructions through one or more general-purpose or special-purpose processors, or as a combination of hardware and software. For example, embodiments of this invention can be implemented in the environment of a computer system or another processing system. Figure 34An example of a computer system 800 is illustrated. Units or modules, and the steps of methods performed by these units, can be executed on one or more computer systems 800. The computer system 800 includes one or more processors 802, such as dedicated or general-purpose digital signal processors. The processors 802 are connected to a communication infrastructure 804, such as a bus or network. The computer system 800 includes main memory 806, such as random access memory (RAM); and secondary memory 808, such as a hard disk drive and / or a removable storage drive. The secondary memory 808 allows computer programs or other instructions to be loaded into the computer system 800. The computer system 800 may further include a communication interface 810 to allow the transfer of software and data between the computer system 800 and external devices. Communication can originate from electronic, electromagnetic, optical, or other signals that can be handled by the communication interface. This communication can use wires or cables, optical fibers, telephone lines, cellular telephone links, RF links, and other communication channels 812.

[0689] The terms "computer program medium" and "computer-readable medium" generally refer to tangible storage media, such as removable storage units or hard disks installed in hard disk drives. These computer program products are means for providing software to computer system 800. The computer program, also known as computer control logic, is stored in main memory 806 and / or auxiliary memory 808. The computer program may also be received via communication interface 810. When executed, the computer program enables computer system 800 to implement the present invention. Specifically, when executed, the computer program enables processor 802 to implement the processes of the present invention, such as any of the methods described herein. Thus, such a computer program can represent a controller of computer system 800. In the case of implementing this disclosure using software, the software may be stored in the computer program product and loaded into computer system 800 using a removable storage drive or an interface (such as communication interface 810).

[0690] The implementation in hardware or software can be executed using a digital storage medium, such as a cloud storage device, floppy disk, DVD, Blu-ray disc, CD, ROM, PROM, EPROM, EEPROM, or FLASH memory, which stores electronically readable control signals that cooperate with or are capable of cooperating with a programmable computer system to execute corresponding methods. Therefore, the digital storage medium can be computer-readable.

[0691] Some embodiments of the invention include a data carrier having electronically readable control signals that are capable of cooperating with a programmable computer system to perform one of the methods described herein.

[0692] Typically, embodiments of the present invention can be implemented as a computer program product having program code that, when run on a computer, is operable to perform one of the methods. For example, the program code can be stored on a machine-readable medium.

[0693] Other embodiments include a computer program for performing one of the methods described herein, the computer program being stored on a machine-readable medium. In other words, therefore, embodiments of the methods of the present invention are computer programs having program code that, when run on a computer, performs one of the methods described herein.

[0694] Therefore, a further embodiment of the method of the present invention is a data carrier or digital storage medium or computer-readable medium comprising a computer program recorded thereon for performing one of the methods described herein. Therefore, a further embodiment of the method of the present invention is a data stream or signal sequence representing a computer program for performing one of the methods described herein. For example, the data stream or signal sequence may be configured to be transmitted via a data communication connection, such as via the Internet. Further embodiments include processing means, such as a computer or programmable logic device, configured or adapted to perform one of the methods described herein. Further embodiments include a computer on which a computer program for performing one of the methods described herein is installed.

[0695] In some embodiments, a programmable logic device, such as a field-programmable gate array (FPGA), can be used to perform some or all of the functions of the methods described herein. In some embodiments, the FPGA can cooperate with a microprocessor to perform one of the methods described herein. Generally, the methods are preferably performed by any hardware device.

[0696] The above embodiments are merely illustrative of the principles of the invention. It will be understood that modifications and variations to the arrangements and details described herein will be apparent to those skilled in the art. Therefore, the intent is limited only by the scope of the forthcoming patent claims, and not by the specific details presented through the description and explanation of the embodiments herein.

[0697] References

[0698] [1]3GPP TS38.300 NR and NG-RAN Overall Description; Stage 2(Release16)

[0699] [2]3GPP TS 24.501Non-Access-Stratum(NAS)protocol for 5G System(5GS); Stage 3

[0700] [3]WO2018127505A1,“Access control for network slices of a wirelesscommunication system”

[0701] [4]3GPP TS23.003,“Numbering,addressing and identification”

[0702] [5]US20180368179A1-Differentiated random-access in new radio”

[0703] [6]3GPP TS38.321 NR Medium Access Control(MAC)protocol specification

Claims

1. A user equipment (UE) for a wireless communication network, The UE may connect to two or more of a plurality of network slices of the wireless communication network, wherein a slice-specific random access channel (RACH) resource configuration is associated with one or more of the plurality of slices. in, In response to a first RACH event associated with the first slice, the UE determines whether there is an ongoing RACH procedure triggered by a second RACH event associated with the second slice, and In the case of an ongoing RACH procedure, the UE will • Prohibit additional RACH processes triggered by the first RACH event associated with the first slice, and / or • Suspend the additional RACH process for a period of time, and / or • Stop the ongoing RACH process and start an additional RACH process, and / or • Modify the ongoing RACH process, and / or • Modify the ongoing RACH process to initiate an additional RACH process.

2. The User Equipment (UE) as claimed in claim 1, wherein the slice-specific RACH resource configuration specifies one or more resource configurations and one or more parameters for the RACH procedure, wherein the one or more resource configurations and one or more parameters for the RACH procedure include: ·PRACH preamble, • Beam index • Beam switching trigger event, Resources used for PRACH • One or more parameters used to determine one or more root sequences and their cyclic shifts in a set of PRACH preamble sequences. • Indexes to the logical root sequence list · Circular displacement N CS , • Collection type.

3. The User Equipment (UE) as claimed in claim 1, wherein in the presence of an ongoing RACH procedure, the UE will abort any additional RACH procedure so that at any given time, there is only a single ongoing RACH procedure.

4. The User Equipment (UE) as claimed in claim 1, wherein the UE will suspend the additional RACH procedure until the ongoing RACH procedure is completed.

5. The user equipment (UE) as described in claim 4, wherein, Once the ongoing RACH procedure on the first slice is completed, the UE will store information related to the additional RACH procedure to be used when the additional RACH procedure is initiated on the second slice.

6. The user equipment (UE) as described in claim 5, wherein, If an ongoing RACH procedure fails a predefined number of times, the UE will stop or postpone the ongoing RACH procedure and initiate an additional RACH procedure.

7. The User Equipment (UE) as claimed in claim 1, wherein the UE will disable or suspend the additional RACH procedure under the following conditions. • No parallel RACH processes are allowed to use different slice-specific RACH resource configurations, and / or, • Disable parallel RACH processes that use different slice-specific RACH resource configurations, and / or, • An ongoing RACH process has a higher priority than an additional RACH process, and / or • When compared to the ongoing RACH process, the additional RACH process uses a different configuration, and / or • Additional RACH processes are sent to a different BS or DU than the ongoing RACH process.

8. The User Equipment (UE) as claimed in claim 1, wherein once the ongoing RACH procedure is partially completed, the UE will suspend any additional RACH procedures.

9. The User Equipment (UE) of claim 8, wherein the UE initiates an additional RACH procedure such that there are no parallel uplink transmissions associated with the ongoing RACH procedure and the additional RACH procedure.

10. The user equipment (UE) of claim 8, wherein in response to a specific event associated with an ongoing RACH procedure, the UE initiates an additional RACH procedure, the specific event including one or more of the following: • The UE sends an RRC connection request message 3 in the uplink for the ongoing RACH procedure. • The UE receives a RACH response RAR message 2 in the downlink for the ongoing RACH procedure. • The UE sends RACH preamble message 1 in the uplink for the ongoing RACH procedure. • The UE receives an RRC connection reconfiguration message in the downlink.

11. The User Equipment (UE) of claim 1, wherein the UE will stop the ongoing RACH procedure and initiate an additional RACH procedure under the following conditions. • Throughout the entire ongoing RACH process or up to a certain stage of the ongoing RACH process, and / or • Responds to the fulfillment of one or more preemption criteria.

12. The user equipment (UE) as described in claim 11, wherein one or more preemption criteria include one or more of the following: ·Specific parameters in RRC RACH resource configuration, • Events that trigger the RACH process • User plane message types waiting to be transmitted • QoS attributes of user plane messages awaiting transmission • Message types waiting to be transmitted • The entity that triggers the RACH process.

13. The user equipment as claimed in claim 1, wherein, To correct an ongoing RACH process, the UE will correct a specific message transmitted during the ongoing RACH process by including, in addition to an indication of the first slice, an indication of the second slice in the specific message, so as to allow the base station to provide parameters for the configuration of the first and second slices in response to the specific message.

14. The user equipment as claimed in claim 1, wherein, In order to correct an ongoing RACH procedure to initiate an additional RACH procedure, the UE will correct a specific message transmitted by the UE during the ongoing RACH procedure by replacing the indication of the first slice with the indication of the second slice, so as to allow the base station to provide parameters for the configuration of the second slice in response to the specific message.

15. The User Equipment (UE) as claimed in claim 1, wherein the additional RACH procedure and the ongoing RACH procedure are triggered simultaneously or within a certain time window.

16. The user equipment (UE) of claim 1, wherein the UE is configured or pre-configured to support two or more parallel RACH procedures, the parallel RACH procedures being associated with different slices.

17. The User Equipment (UE) of claim 16, wherein the UE is only permitted to perform two or more PRACH procedures on different slices if the slice is configured as one or more of the following: • Use different BWPs, • Operate on different carrier frequencies, wherein the frequency gap between the first radio frequency and the second radio frequency is Δx.

18. A wireless communication system comprising one or more user equipment (UE) as described in claim 1.

19. The wireless communication system of claim 18, wherein Wireless communication networks provide multiple network slices, and • The radio access network (RAN) of a wireless communication network includes cloud RAN and C-RAN. C-RAN includes multiple slice-specific distributed units (DU) and one or more central units (CU) shared by some or all slices.

20. A method for operating a user equipment (UE) in a wireless communication network, wherein the UE can be connected to two or more of a plurality of network slices of the wireless communication network, wherein a slice-specific random access channel (RACH) resource configuration is associated with one or more of the plurality of slices, the method comprising: In response to a first RACH event associated with the first slice, determine whether there is an ongoing RACH process triggered by a second RACH event associated with the second slice, and In the case of the ongoing RACH process, • Prohibit additional RACH processes triggered by the first RACH event associated with the first slice, and / or • Suspend the additional RACH process for a period of time, and / or • Stop the ongoing RACH process and start an additional RACH process, and / or • Modify the ongoing RACH process, and / or • Modify the ongoing RACH process to initiate an additional RACH process.

Images