WO2022009093A1 - Identités de cellules dans un réseau iab qui prend en charge une migration d'iab - Google Patents

Identités de cellules dans un réseau iab qui prend en charge une migration d'iab Download PDF

Info

Publication number
WO2022009093A1
WO2022009093A1 PCT/IB2021/056050 IB2021056050W WO2022009093A1 WO 2022009093 A1 WO2022009093 A1 WO 2022009093A1 IB 2021056050 W IB2021056050 W IB 2021056050W WO 2022009093 A1 WO2022009093 A1 WO 2022009093A1
Authority
WO
WIPO (PCT)
Prior art keywords
network node
iab
node
message
cells
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2021/056050
Other languages
English (en)
Inventor
Pradeepa Ramachandra
Oumer Teyeb
Mattias BERGSTRÖM
Angelo Centonza
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of WO2022009093A1 publication Critical patent/WO2022009093A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/047—Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations

Definitions

  • the present description generally relates to wireless communication systems and more specifically to cell identities in an Integrated Access and Backhaul (IAB) network that supports IAB migration.
  • IAB Integrated Access and Backhaul
  • the usage of short range mmWave spectrum in NR creates a need for densified deployment with multi-hop backhauling.
  • optical fiber to every base station will be too costly and sometimes not even possible (e.g. historical sites).
  • the main IAB principle is the use of wireless links for the backhaul (instead of fiber) to enable flexible and very dense deployment of cells without the need for densifying the transport network.
  • Use case scenarios for IAB can include coverage extension, deployment of massive number of small cells and fixed wireless access (FWA) (e.g. to residential/office buildings).
  • FWA fixed wireless access
  • the larger bandwidth available for NR in mmWave spectrum provides opportunity for self-backhauling, without limiting the spectrum to be used for the access links.
  • the inherent multi-beam and Multiple Input Multiple Output (MIMO) support in NR reduce cross-link interference between backhaul and access links allowing higher densification.
  • MIMO Multiple Input Multiple Output
  • the specifications for IAB strive to reuse existing functions and interfaces defined in NR.
  • MT, gNB-DU, gNB-CU, User Plane Function (UPF), Access and Mobility Management Function (AMF) and Session Management Function (SMF) as well as the corresponding interfaces NR Uu (between MT and gNB), FI, NG, X2 and N4 are used as baseline for the IAB architectures.
  • UPF User Plane Function
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • FI, NG, X2 and N4 are used as baseline for the IAB architectures.
  • Modifications or enhancements to these functions and interfaces for the support of IAB will be explained in the context of the architecture discussion. Additional functionality such as multi-hop forwarding is included in the architecture discussion as it is necessary for the understanding of IAB operation and since certain aspects may require standardization.
  • the MT function has been defined as a component of the IAB node.
  • MT is referred to as a function residing on an IAB-node that terminates the radio interface layers of the backhaul Uu interface toward the IAB-donor or other IAB-nodes.
  • Figure 1 shows a reference diagram for IAB architecture in standalone mode, which contains one IAB-donor and multiple IAB-nodes.
  • Figure 1 shows a high-level architectural view of an IAB network.
  • the IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP (Control Plane), gNB-CU-UP (User Plane) and potentially other functions.
  • the IAB-donor can be split according to these functions, which can all be either collocated or non-collocated as allowed by 3 GPP Next Generation- Radio Access Network (NG-RAN) architecture. IAB-related aspects may arise when such split is exercised.
  • some of the functions presently associated with the IAB-donor may eventually be moved outside of the donor in case it becomes evident that they do not perform IAB-specific tasks.
  • NG-RAN Next Generation- Radio Access Network
  • the chosen protocol stacks reuse the current CU-DU split specification in Release- 15, where the full UP Fl-U (GTP-U/UDP/IP) is terminated at the IAB node (like a normal DU) and the full control plane Fl-C (Fl-AP/SC TP/IP) is also terminated at the IAB node (like a normal DU).
  • NDS Network Domain Security
  • IPsec IPsec in the case of UP
  • DTLS Datagram Transport Layer Security
  • IPsec could also be used for the CP protection instead of DTLS (in this case no DTLS layer would be used).
  • BAP Backhaul Adaptation Protocol
  • IAB nodes A new protocol layer called Backhaul Adaptation Protocol (BAP) has been introduced in the IAB nodes and the IAB donor, which is used for routing packets to the appropriate downstream/upstream node and also mapping the User Equipment (UE) bearer data to the proper backhaul (BH) Radio Link Control (RLC) channel (and also between ingress and egress BH RLC channels in intermediate IAB nodes) to satisfy the end to end Quality of Service (QoS) requirements of bearers.
  • BAP Backhaul Adaptation Protocol
  • the BAP sublayer contains one BAP entity at the MT function and a separate collocated BAP entity at the DU function.
  • the BAP sublayer contains only one BAP entity.
  • Each BAP entity has a transmitting part and a receiving part. The transmitting part of the BAP entity has a corresponding receiving part of a BAP entity at the IAB- node or IAB-donor-DU across the backhaul link.
  • FIG. 4 shows one example of the functional view of the BAP sublayer. This functional view should not restrict implementation.
  • the figure is based on the radio interface protocol architecture defined in 3GPP TS 38.300.
  • the receiving part on the BAP entity delivers BAP Protocol Data Units (PDUs) to the transmitting part on the collocated BAP entity.
  • the receiving part may deliver BAP Service Data Units (SDUs) to the collocated transmitting part.
  • PDUs BAP Protocol Data Units
  • SDUs BAP Service Data Units
  • the receiving part removes the BAP header and the transmitting part adds the BAP header with the same BAP routing identity/identifier (ID) as carried on the BAP PDU header prior to removal.
  • ID BAP routing identity/identifier
  • BAP sublayer Passing BAP SDUs in this manner is therefore functionally equivalent to passing BAP PDUs, in implementation.
  • the following services are provided by the BAP sublayer to upper layers: data transfer.
  • a BAP sublayer expects the following services from lower layers per RLC entity (for a detailed description see 3GPP TS 38.322): acknowledged data transfer service; unacknowledged data transfer service.
  • the BAP sublayer supports the following functions:
  • IAB topology adaptation IAB migration, IAB relocation and IAB handover are used interchangeably to refer to the procedure where an IAB node changes its parent node.
  • IAB topology adaptation can be triggered due to several reasons, e.g. load or radio conditions at the source (overload at parent node or intermediate nodes between the donor CU and the IAB node, bad radio conditions on the backhaul link to the parent node and/or any of the intermediate hops towards the donor DU, etc.). Topology adaptation can be also due to mobility of the IAB node (which indirectly could be considered/treated the same way as topology adaptation due to radio conditions).
  • Figure 5 shows examples of possible IAB-node migration cases, listed in order of complexity:
  • Intra-CU Case (A) the IAB-node (E) along with it serving UEs is moved to a new parent node (IAB-node (B)) under the same donor-DU (1).
  • the successful intra-donor DU migration requires establishing UE context setup for the IAB-node (E) MT in the DU of the new parent node (IAB-node (B)), updating routing tables of IAB nodes along the path to IAB-node (E) and allocating resources on the new path.
  • the IP address for IAB-node (E) will not change, while the Fl-U tunnel/connection between donor-CU (1) and IAB-node (E) DU will be redirected through IAB-node (B).
  • Intra-CU Case (B) The procedural requirements/complexity of this case is the same as that of Case (A). Since the new IAB-donor DU (i.e. DU2) is connected to the same L2 network, the IAB-node (E) can use the same IP address under the new donor DU. However, the new donor DU (i.e. DU2) will need to inform the network using IAB-node (E) L2 address in order to get/keep the same IP address for IAB-node (E) by employing mechanisms such as Address Resolution Protocol (ARP).
  • ARP Address Resolution Protocol
  • Intra-CU Case (C) This case is more complex than Case (A) as it also needs allocation of new IP address for IAB-node (E).
  • IPsec is used for securing the Fl-U tunnel/connection between the Donor-CU (1) and IAB-node (E) DU, then it might be possible to use existing IP address along the path segment between the Donor-CU (1) and SeGW, and new IP address for the IPsec tunnel between SeGW and IAB-node (E) DU.
  • Inter-CU Case (D) This is the most complicated case in terms of procedural requirements and may need new specification procedures that are beyond the scope of 3GPP Rel-16.
  • An NR cell is uniquely identified within a Plain Land Mobile Network (PLMN) by the Cell Global Identifier (CGI).
  • CGI Cell Global Identifier
  • the CGI has a size of 36 bits.
  • the left most bits of the CGI identify the gNB uniquely, gNB ID (22 to 32 bits, depending on network implementation), while the rest (4 to 14 bits) identify the cell within that gNB, referred in this disclosure as cell identity _gnb (CI gnb).
  • CGI gNB ID + CI gnb.
  • SI system information
  • MIB Master Information Block
  • SIBs System information blocks
  • Minimum SI comprises basic information required for initial access and information for acquiring any other SI.
  • Minimum SI consists of:
  • MIB contains cell barred status information and essential physical layer information of the cell required to receive further system information, e.g. control resource set (CORSET)#0 configuration. MIB is periodically broadcast on BCH (broadcast channel).
  • BCH broadcast channel
  • SIB1 defines the scheduling of other system information blocks and contains information required for initial access. SIB1 is also referred to as Remaining Minimum SI (RMSI) and is periodically broadcast on DL-SCH (Downlink Shared Channel) or sent in a dedicated manner on DL-SCH to UEs in RRC C ONNEC TED .
  • RMSI Remaining Minimum SI
  • SIBs encompasses all SIBs not broadcast in the Minimum SI.
  • Those SIBs can either be periodically broadcast on DL-SCH, broadcast on-demand on DL-SCH (i.e. upon request from UEs in RRC IDLE or RRC INACTIVE), or RRC CONNECTED, or sent in a dedicated manner on DL-SCH to UEs in RRC CONNECTED (i.e., upon request from UEs in RRC CONNECTED or when the UE has an active BWP with no common search space configured).
  • the cell identity is included in SIB1.
  • the DU In a CU/DU split architecture, though all the SI broadcast is performed by the DU, the DU is responsible for setting the content of only a limited Sis, while the rest is determined by the CU and communicated to the DU, which transparently broadcasts it to the UEs. Specifically, the DU determines the content of the MIB and SIB1, while the CU determines the other Sis. [0044] The DU communicates the MIB/SIBl information to the CU using the FI setup request message (during FI setup procedure) and the gNB-DU configuration update message (any time after FI is setup).
  • the CU communicates the information about other SIBs to the DU using the F 1 setup response message (during F 1 setup procedure), and anytime after F 1 setup using the gNB-DU configuration update acknowledge message (as a response to DU configuration update) and gNB-CU configuration update (when CU configuration changes).
  • the DU upon FI setup (FI setup request), communicates the CGI information of the cells that it is serving to the CU.
  • the CU responds with FI setup response message, indicating the cells that it wants the DU to activate.
  • the CU can later on activate cells that were not activated during FI setup or deactivate those that were active using the gNB-CU update message.
  • the DU can also change information about the cells it is serving.
  • An IAB node contains an MT and a gNB-DU, which can re-connect to different gNB-CUs as a result of handover due to mobility or other reasons (e.g. balancing in the IAB network).
  • a gNB-DU which can re-connect to different gNB-CUs as a result of handover due to mobility or other reasons (e.g. balancing in the IAB network).
  • IAB-B is relocated from IAB donor DU1 to IAB donor DU2, which results in the change of the gNB-CU serving the IAB node (from IAB donor CU1, also referred to as gNB-CUl, to IAB donor CU2, also referred to as gNB-CU2). With such a change, the DU of IAB-B needs to setup or relocate the FI connection with gNB-CU2 and add new cells towards gNB-CU2.
  • some embodiments may comprise: [0051] A migrating LAB node can keep the old CI gnb for the cells that it is serving and change the gNB ID part of the CGI to be the same as the target CU/gNB’s identity and includes this in the FI setup request. If the CU detects a collision (i.e.
  • the CU could report (e.g. F 1 Setup Response) a CGI value to be used (or a list of possible CGI values) to be used by the IAB node for its cells.
  • F 1 Setup Response e.g. F 1 Setup Response
  • a migrating IAB node can keep the old PCI for the cells that it is serving. If the CU detects collision (i.e. another cell under the CU have the same PCI), the CU could report (e.g. FI Setup Response) a PCI value to be used (or a list of possible PCI values) to be used by the IAB node for its cells.
  • the CU could report (e.g. FI Setup Response) a PCI value to be used (or a list of possible PCI values) to be used by the IAB node for its cells.
  • the IAB node can be provided with a CGI mapping information, that includes the identity of a CU, and a list of CGIs that the IAB node can use when relocating to that CU. That information could be a semi-static information provided via Operation Administration and Management (OAM) during the initial IAB integration to the network and updated on a need basis (e.g. via Fl/RRC signaling).
  • OAM Operation Administration and Management
  • the IAB node can be provided with a PCI mapping information, that includes the identity of a CU, and a list of PCIs that the IAB node can use when relocating to that CU.
  • the PCI mapping information could be a semi-static information provided via OAM during initial IAB integration to the network and updated on a need basis (e.g. via Fl/RRC signaling).
  • the provided CGI and PCI mapping information could be either independent or related: [0056] Independent. It is up to the IAB node to select which CGI and PCI to use for its cells. [0057] Related the CGI and PCI are provided as a pair (i.e. if a certain CGI is assigned to a cell, the associated PCI in the list should be used for that cell). Other relations between the CGI and PCI can be considered as well.
  • the migrating IAB node during FI relocation (e.g. FI Setup Request), can include the old CGIs/PCIs used by its cell (e.g. if it has decided to change the CGIs based on the above embodiments).
  • a method may comprise: moving from being connected to a first network node to being connected to a second network node; and sending a first message to the second network node, wherein the first message comprises a Cell Identifier (Cl) determined based on one of a Cl associated with the first network node and cell identifier (Cl) mapping information.
  • the Cl can be a CGI or PCI or any other identifier of a cell.
  • Another method may comprise: receiving a first message from an LAB node that moves from a source network node to the target network node, wherein the first message comprises a Cl determined based on one of a Cl associated with the source network node and Cl mapping information; determining if the Cl collides with a Cl of one or more cells associated with the target network node; and in response to determining that the Cl collides with the Cl of one or more cells, sending a second message to the IAB node, the second message comprising an indication of CIs for the IAB node to use or an indication of cells to be inactivated.
  • some embodiments include a network node configured, or operable, to perform one or more functionalities (e.g. actions, operations, steps, etc.) as described herein.
  • the network node may comprise one or more communication interfaces configured to communicate with one or more other radio nodes and/or with one or more network nodes, and processing circuitry operatively connected to the communication interface, the processing circuitry being configured to perform one or more functionalities as described herein.
  • the processing circuitry may comprise at least one processor and at least one memory storing instructions which, upon being executed by the processor, configure the at least one processor to perform one or more functionalities as described herein.
  • the network node may comprise one or more functional modules configured to perform one or more functionalities as described herein.
  • some embodiments include a non-transitory computer- readable medium storing a computer program product comprising instructions which, upon being executed by processing circuitry (e.g., at least one processor) of the network node, configure the processing circuitry to perform one or more functionalities as described herein.
  • processing circuitry e.g., at least one processor
  • the advantages/technical benefits of the embodiments of the present disclosure are: [0066] In a non-IAB scenario, the DUs are always attached to the same CU and the network could assign the CGIs/PCIs to avoid CGI/PCI collision/confusion. This is not the case in IAB networks, specially where mobile IABs are involved.
  • the disclosure provides mechanisms to ensure that CGI/PCI collisions/confusions do not occur in IAB networks, where an IAB node migrates from one donor CU to another, either due to load balancing or mobility reasons.
  • Figure 1 illustrates a reference diagram for IAB -architectures (see for example 3GPP TR 38.874).
  • Figure 2 illustrates a baseline User Plane (UP) Protocol stack for IAB in rel-16.
  • UP User Plane
  • Figure 3 illustrates a baseline Control Plane (CP) Protocol stack for IAB in rel-16.
  • Figure 4 illustrates an example of functional view of BAP sublayer.
  • Figure 5 illustrates an example of different possible scenarios for IAB-node migration.
  • Figure 6 is a diagram of an IAB intra-CU topology adaptation procedure.
  • Figure 7 illustrates a migration scenario of an IAB node migrating from a first CU to a second CU.
  • Figure 8 is a flow chart of a method in a network node, in accordance with an embodiment.
  • Figure 9 is a flow chart of a method in a network node, in accordance with an embodiment.
  • Figure 10 illustrates one example of a wireless communications system in which embodiments of the present disclosure may be implemented.
  • Figures 11 and 12 are block diagrams that illustrate a wireless device according to some embodiments of the present disclosure.
  • Figures 13 and 14 are block diagrams that illustrate a network node according to some embodiments of the present disclosure.
  • Figure 15 illustrates a virtualized environment of a network node, according to some embodiments of the present disclosure.
  • references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • a collision of CGIs or a confusion of PCIs refers to different cells having the same ID, i.e. two or more cells have the same CGI or PCI.
  • an IAB node migrates from a first CU (or gNB-CU) to a second CU (or gNB-CU), see for example Figure 7.
  • the IAB node serves several cells. As such, those cells are associated with the IAB node or the first CU that serves the IAB node.
  • the cells have a cell identity (Cl), such as a CGI/PCI.
  • the second CU serves the IAB node so the DU of the IAB node (or the IAB node) needs to setup or relocate the FI connection with the second gNB-CU and add new cells towards the second gNB-CU.
  • the new cells need a new cell identifier (e.g. CGI/PCI) that is unique so that they do not collide with the CGIs/PCIs of the cells that are under (or being served by) the second CU.
  • CGI/PCI new cell identifier
  • a migrating IAB node when moving from a source CU to a target CU, can keep the old CI gnb for the cells that it serves but changes the gNB ID part of the CGI to correspond to the target CU/gNB’s ID.
  • This information i.e. new CGI
  • the IAB node could also keep the old PCIs used in the previous/source CU.
  • the old CGIs/PCIs could be also indicated in the FI setup request.
  • the target CU could report/send (e.g. FI Setup Response) a CGI/PCI value to be used (or a list of possible CGI/PCI values to be used) by the migrating IAB node for its cells. If more than one possible identity is provided, the DU (or IAB node) can respond to the target CU with the chosen cell identities (e.g. CGI/PCI), e.g. using a gNB-DU configuration update.
  • the chosen cell identities e.g. CGI/PCI
  • This message is sent by the gNB-CU to transfer information associated to an Fl-C interface instance.
  • the IAB node can confirm which one it has chosen by using the gNB-DU configuration update message, including the concerned cells in the served Cells To Modify List, and including the chosen CGI/PCI in the served cell Information for each cell (i.e. legacy rel-15/16 messages could be used for this case), for example.
  • the target CU can decide to deactivate the concerned cell(s). This could also be accomplished via the legacy FI Setup Response message (by not including the concerned cell(s) in the Cells To be Activated List). If the collision is resolved later on (e.g. the colliding cells belonged to another mobile LAB node, and that IAB node is no more being served by the target CU), the target CU could send a gNB- CU configuration update message to the IAB node to activate the concerned cell(s).
  • the target CU could deactivate the cells of other IAB nodes or DUs under it that have CGIs/PCIs that collide with the cells of the migrating IAB node, so that the cells of the migrating IAB node can be activated.
  • This could be used if there are not any (or only few) active UEs under the already active cells of the other DUs/IAB nodes whose CGI/PCI was colliding with the cells of the incoming IAB node, while the migrating IAB node is migrating with several UEs/IAB nodes under it (e.g. an IAB node attached to a bus/train).
  • the IAB node when an IAB node moves from a source CU to a target CU, the IAB node is provided with a CGI/PCI mapping information by the target CU.
  • the CGI/PCI mapping information can include the identities of CUs (i.e. CUs that the IAB node is expected to be served by at some point in time), and for each CU, a list of CGIs/PCIs that the IAB node can use when relocating to that CU. This could be provided per each cell of the IAB DU (e.g.
  • CU_1 [cell 1, CGI A, PCI A; cell 2: CGI B, PCI B], CU_2: [cell 1, CGI x, PCI x; cell 2: CGI_y, PCI_y], ....), or it could be just a list of all possible CGIs/PCIs that the IAB node can use under that CU and it is up to the IAB node to decide which CGI/PCI to use for each of its own cell (e.g. CU_1 : [CGI A, CGI B, PCI A, PCI B], CU_2: [CGI x, CGI_y, PCI x, PCI_y]
  • This list of CGIs/PCIs could be semi-static information provided via OAM during the initial IAB integration to the network, and optionally updated (from the OAM or via Fl/RRC signaling) on a need basis, while the IAB node is active.
  • the network can reserve a number/set of PCIs and CGIs for cells of mobile IAB nodes (or static IAB nodes that can relocate from one CU to another due to reasons other than mobility).
  • the IAB nodes can be configured with static CGIs/PCIs from this reserved set in a way that no two IAB nodes will use the same CGI/PCI for their cells. That way, the CGI/PCI collision problem is preemptively prevented.
  • This solution though the simplest of all of the above examples, from the implementation point of view, may not be applicable in very dense deployment as, for example, it prevents the reuse of the reserved PCIs through the network.
  • the migrating IAB node can also include the old cell identities (e.g. CGI/PCI) used for its cells during the FI relocation (e.g. FI Setup Request).
  • the served cell information IE that is included in the FI Setup Request message could be updated as below in order to include the old cell global identities (e.g. CGIs) and PCIs.
  • This IE contains cell configuration information of a cell in the gNB-DU.
  • a method 100 in an IAB node which can be a mobile IAB node, e.g. which can migrate from a source network node to a target network node, is illustrated in Figure 8.
  • Method 100 can be implemented in a network node (or an IAB node), such as 320 of Figure 11.
  • Method 100 comprises:
  • Step 110 moving from being connected to a first network node to being connected to a second network node; and [0105] Step 120: sending a first message to the second network node, wherein the first message comprises a Cell identity (Cl) determined based on one of a Cl associated with the first network node and Cl mapping information; and
  • Cl Cell identity
  • Step 120 receiving a second message from the second network node.
  • the IAB node/network node may receive a second message from the second network node or a third network node.
  • the Cl determined based on the Cl associated with the first network node has a first part that includes a cell identity associated with the first network node (or the cells associated with the IAB node) and has a second part that includes a network node identity that corresponds to an identity of the second network node.
  • the Cl could be a CGI and the first part of the Cl (or CGI in this case) is the old CI gnb and the second part of the Cl (or CGI in this case) is the ID of the new gNB-CU (or target network node).
  • the second message can include a Cl or a list of CIs for the IAB node to use for the cells associated with the IAB node, when the second network node detects that the Cl sent by the IAB node is already used by one or more cells associated with the second network node.
  • the IAB node can select or use the Cl received from the second network node. Or the IAB node can select a Cl from the list of CIs contained in the second message. [0111] In some examples, the IAB node can send or report the selected Cl to the second network node. For example, the IAB node can do so by sending a gNB-DU configuration update message, that contains the selected Cl. More specifically, the selected Cl can be contained in an Information Element called served cell Information.
  • the gNB-DU configuration update message can also comprise a list of cells associated with the IAB node (or the first network node), for example, the cells that are under the first network node or the IAB node.
  • the list of cells can be contained in an Information Element called served Cells To Modify list.
  • the second message can comprise an indication of cells to be inactivated when the second network node determines that the Cl sent by the IAB node collides with a Cl of those cells. Those cells can be associated with the second network node, for example.
  • the indication of cells to be inactivated can be provided by an Information Element (IE) called Cells To be Activated list, by not including the cells in that IE.
  • IE Information Element
  • the first message can comprise one or more CIs associated with the first network node (or the IAB node), i.e. the old CIs.
  • the first message can be a FI Setup Request.
  • the second message can be a FI Setup Response.
  • the first network node can be a source Centralized Unit (CU) or source gNB-CU.
  • CU Centralized Unit
  • gNB-CU source gNB-CU
  • the second network node can be a target Centralized Unit (CU) or target gNB-CU.
  • CU Centralized Unit
  • gNB-CU target gNB-CU
  • the Cl mapping information can comprise a list of centralized units (CUs) mapped to a list of CIs.
  • the Cl mapping information can provided for each cell of the IAB node. [0122] In some examples, the Cl mapping information is received in a semi-static way via Operation, Administration and Management (OAM) during an initial IAB integration.
  • OAM Operation, Administration and Management
  • the IAB node/network node can receive a message containing the Cl mapping information in response to sending a handover message to the second network node.
  • the message containing the Cl mapping information can be a FI message embedded within a handover command.
  • the Cl can at least one of a Cell Global Identity (CGI) and a Physical Cell identity (PCI).
  • CGI Cell Global Identity
  • PCI Physical Cell identity
  • the provided CGI and PCI mapping information could be either independent or related:
  • Figure 9 illustrates a method 200 for a network node, such as a gNB-CU or CU (or target network node), to handle an IAB node relocating to it from a first/source network node.
  • the network node can be the target network node, or the network node 320 of Figure 11.
  • Method 200 comprises:
  • Step 210 receiving a first message from an IAB node that moves from a source network node to the target network node, wherein the first message comprises a Cell Identifier (Cl) determined based on one of a Cl associated with the source network node (or the IAB node) and Cl mapping information;
  • Cl Cell Identifier
  • Step 220 determining if the Cl collides with (or is the same as) a Cl of one or more cells associated with the target network node; and [0132] Step 230: in response to determining that the Cl collides with the Cl of one or more cells, sending a second message to the IAB node, the second message comprising an indication of CIs for the IAB node to use or an indication of cells to be inactivated.
  • the Cl determined based on the Cl associated with the source network node has a first part that includes a cell identity associated with the source network node (or IAB node) and has a second part that includes a network node identity that corresponds to an identity of the target network node.
  • the Cl can be a CGI and the first part of the CGI is the old CI gnb and the second part of the CGI is the ID of the new gNB-CU (or target network node).
  • the network node can receive a third message from the IAB node, the third message comprising a CG selected by the IAB node to use.
  • the selected Cl can be sent in a gNB-DU configuration update message to the network node.
  • the selected Cl can be contained in an Information Element called served cell Information.
  • the indication of cells to be inactivated can be provided by an Information Element (IE) called Cells To be Activated list, by not including the cells in that IE.
  • IE Information Element
  • the first message can further comprise the CIs associated with the source network node (or IAB node).
  • the CIs are the old CIs of the cells of the IAB node when connected/attached to the source/first network node.
  • the first message can be a FI Setup Request.
  • the second message can be a FI Setup Response.
  • the source network node can be a source Centralized Unit (CU) or source gNB-CU.
  • CU Centralized Unit
  • gNB-CU source gNB-CU
  • the target network node can be a target Centralized Unit (CU) or target gNB-CU.
  • CU Centralized Unit
  • gNB-CU target gNB-CU
  • the Cl can be is at least one of a CGI and PCI.
  • FIG. 10 illustrates an example of a wireless network 300 that may be used for wireless communications.
  • Wireless network 300 includes UEs 310 and a plurality of radio network nodes 320 (e.g., Node Bs (NBs) Radio Network Controllers (RNCs), evolved NBs (eNBs), next generation NB (gNBs), etc.) directly or indirectly connected to a core network 330 which may comprise various core network nodes.
  • the network 300 may use any suitable radio access network (RAN) deployment scenarios, including Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (UTRAN), and Evolved UMTS Terrestrial Radio Access Network (EUTRAN).
  • UEs 310 may be capable of communicating directly with radio network nodes 320 over a wireless interface.
  • UMTS Universal Mobile Telecommunication System
  • UTRAN Universal Mobile Telecommunication System
  • EUTRAN Evolved UMTS Terrestrial Radio Access Network
  • UEs may also be capable of communicating with each other via device-to-device (D2D) communication.
  • network nodes 320 may also be capable of communicating with each other, e.g. via an interface (e.g. X2 in LTE or other suitable interface).
  • UE 310 may communicate with radio network node 320 over a wireless interface. That is, UE 310 may transmit wireless signals to and/or receive wireless signals from radio network node 320.
  • the wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information.
  • an area of wireless signal coverage associated with a radio network node 320 may be referred to as a cell.
  • a UE may be a wireless device, a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iPAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Universal Serial Bus (USB) dongles, Customer Premises Equipment (CPE) etc.
  • D2D device to device
  • M2M machine to machine communication
  • iPAD machine to machine communication
  • Tablet mobile terminals
  • smart phone laptop embedded equipped (LEE), laptop mounted equipment (LME), Universal Serial Bus (USB) dongles, Customer Premises Equipment (CPE) etc.
  • LEE laptop embedded equipped
  • LME laptop mounted equipment
  • USB Universal Serial Bus
  • the “network node” can be any kind of network node which may comprise of a radio network node such as a radio access node (which can include a base station, radio base station, base transceiver station, base station controller, network controller, gNB, NR BS, evolved Node B (eNB), Node B, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU), Remote Radio Head (RRH), a multi standard BS (also known as MSR BS), etc.), a core network node (e.g., MME, SON node, a coordinating node, positioning node, MDT node, etc.), or even an external node (e.g., 3rd party node, a node external to the current network), etc.
  • a radio network node such as a radio access node (which can include a base station, radio base station, base transceiver station, base station controller, network controller, gNB
  • the network node may also comprise a test equipment.
  • the network node 320 may be an IAB node, a child IAB node, a parent IAB node or an IAB donor. Furthermore, the IAB node 320 may have components as a MT and/or DU (see for example Figure 5).
  • network nodes 320 may interface with a radio network controller (not shown).
  • the radio network controller may control network nodes 320 and may provide certain radio resource management functions, mobility management functions, and/or other suitable functions.
  • the functions of the radio network controller may be included in the network node 320.
  • the radio network controller may interface with the core network node 340.
  • the radio network controller may interface with the core network node 340 via the interconnecting network 330.
  • the interconnecting network 330 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding.
  • the interconnecting network 330 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.
  • PSTN public switched telephone network
  • LAN local area network
  • MAN metropolitan area network
  • WAN wide area network
  • Internet a local, regional, or global communication or computer network
  • wireline or wireless network such as the Internet
  • enterprise intranet an enterprise intranet, or any other suitable communication link, including combinations thereof.
  • the core network node 340 may manage the establishment of communication sessions and various other functionalities for wireless devices 310.
  • Examples of core network node 340 may include MSC, MME, SGW, PGW, O&M, OSS, SON, positioning node (e.g. E-SMLC), MDT node, etc.
  • Wireless devices 110 may exchange certain signals with the core network node 340 using the non-access stratum layer. In non-access stratum signaling, signals between wireless devices 310 and the core network node 340 may be transparently passed through the radio access network.
  • network nodes 320 may interface with one or more other network nodes over an internode interface. For example, network nodes 320 may interface each other over an X2 interface.
  • network 300 may include any suitable number of wireless devices 310 and network nodes 320, as well as any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device (such as a landline telephone).
  • the embodiments may be implemented in any appropriate type of telecommunication system supporting any suitable communication standards and using any suitable components and are applicable to any radio access technology (RAT) or multi-RAT systems in which the wireless device receives and/or transmits signals (e.g., data).
  • RAT radio access technology
  • multi-RAT multi-RAT
  • the embodiments may be applicable to any RAT, such as UTRA, E-UTRA, narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT (NR, NX), 4G, 5G, LTE FDD/TDD, etc.
  • the communication system 300 may itself be connected to a host computer (see Figure 20 for example).
  • the network 300 (with the wireless devices 310 and network nodes 320) may be able to operate in LAA or unlicensed spectrum.
  • FIG 11 is a schematic block diagram of the wireless device 310 according to some embodiments of the present disclosure.
  • the wireless device 310 includes circuitry 400 comprising one or more processors 410 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like) and memory 420.
  • the wireless device 310 also includes one or more transceivers 430 each including one or more transmitters 440 and one or more receivers 450 coupled to one or more antennas 460.
  • the processing circuitry 400 may be connected to an input interface 480 and an output interface 485.
  • the input interface 480 and the output interface 485 may be referred to as communication interfaces.
  • the wireless device 310 may further comprise power source 490.
  • the functionality of the wireless device 310 described above may be fully or partially implemented in software that is, e.g., stored in the memory 420 and executed by the processor(s) 410.
  • the processor 410 is configured to perform all the functionalities performed by the wireless device 310.
  • a computer program including instructions which, when executed by the at least one processor 410, causes the at least one processor 410 to carry out the functionality of the wireless device 310 according to any of the embodiments described herein is provided.
  • a carrier containing the aforementioned computer program product is provided.
  • the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
  • Figure 12 is a schematic block diagram of the wireless device 310 according to some other embodiments of the present disclosure.
  • the wireless device 310 includes one or more modules 495, each of which is implemented in software.
  • the module(s) 495 provide the functionality of the wireless device 310 described herein.
  • FIG. 13 is a schematic block diagram of a network node 320 according to some embodiments of the present disclosure.
  • the network node 320 includes a processing circuitry 500 comprising one or more processors 510 (e.g., CPUs, ASICs, FPGAs, and/or the like) and memory 520.
  • the network node also comprises a network interface 530.
  • the network node 320 also includes one or more transceivers 540 that each include one or more transmitters 550 and one or more receivers 560 coupled to one or more antennas 570.
  • the functionality of the network node 320 described above may be fully or partially implemented in software that is, e.g., stored in the memory 520 and executed by the processor(s) 510.
  • the processor 510 can be configured to perform any steps of the methods 100 and 200 of Figures
  • the network node 320 is an IAB node or a gNB-CU.
  • FIG. 14 is a schematic block diagram of the network node 320 according to some other embodiments of the present disclosure.
  • the network node 320 includes one or more modules 580, each of which is implemented in software.
  • the module(s) 580 provide the functionality of the network node 320 described herein.
  • the module(s) 580 may comprise, for example, a determining module operable to perform step 220 of Figure 9, a sending module operable to perform step 120 of Figure 8 and step 230 of Figure 9, a receiving module operable to perform step 210 of Figure
  • FIG. 15 is a schematic block diagram that illustrates a virtualized embodiment of the wireless device 310 or network node 320, according to some embodiments of the present disclosure.
  • a “virtualized” node 1200 is a network node 320 or wireless device 310 in which at least a portion of the functionality of the network node 320 or wireless device 310 is implemented as a virtual component (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).
  • a virtual appliance 1220 implementing the methods or parts of the methods of some embodiments.
  • the one or more instance(s) runs in a cloud computing environment 1200.
  • the cloud computing environment provides processing circuits 1230 and memory 1290-1 for the one or more instance(s) or virtual applications 1220.
  • the memory 1290-1 contains instructions 1295 executable by the processing circuit 1260 whereby the instance 1220 is operative to execute the methods or part of the methods described herein in relation to some embodiments.
  • the cloud computing environment 1200 comprises one or more general-purpose network devices including hardware 1230 comprising a set of one or more processor(s) or processing circuits 1260, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or special purpose processors, and network interface controlled s) (NICs) 1270, also known as network interface cards, which include physical Network Interface 1280.
  • the general-purpose network device also includes non-transitory machine readable storage media 1290-2 having stored therein software and/or instructions 1295 executable by the processor 1260.
  • the processor(s)/processing circuits 1260 execute the software/instructions 1295 to instantiate a hypervisor 1250, sometimes referred to as a virtual machine monitor (VMM), and one or more virtual machines 1240 that are run by the hypervisor 1250.
  • a hypervisor 1250 sometimes referred to as a virtual machine monitor (VMM)
  • VMM virtual machine monitor
  • a virtual machine 1240 is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine; and applications generally do not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, though some systems provide para-virtualization which allows an operating system or application to be aware of the presence of virtualization for optimization purposes.
  • Each of the virtual machines 1240, and that part of the hardware 1230 that executes that virtual machine 1240 be it hardware 1230 dedicated to that virtual machine 1240 and/or time slices of hardware 1230 temporally shared by that virtual machine 1240 with others of the virtual machine(s) 1240, forms a separate virtual network element(s) (VNE).
  • VNE virtual network element
  • the hypervisor 1250 may present a virtual operating platform that appears like networking hardware to virtual machine 1240, and the virtual machine 1240 may be used to implement functionality such as control communication and configuration module(s) and forwarding table(s), this virtualization of the hardware is sometimes referred to as network function virtualization (NFV).
  • NFV network function virtualization
  • CPE customer premise equipment
  • Different embodiments of the instance or virtual application 1220 may be implemented on one or more of the virtual machine(s) 1240, and the implementations may be made differently.
  • a carrier comprising the aforementioned computer program product.
  • the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
  • Some embodiments may be represented as a non-transitory software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein).
  • the machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism.
  • the machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to one or more of the described embodiments.
  • Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine-readable medium.
  • Software running from the machine-readable medium may interface with circuitry to perform the described tasks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé dans un nœud de réseau (par exemple, un nœud IAB) qui peut comprendre : le passage d'une connexion à un premier nœud de réseau à une connexion à un second nœud de réseau ; et l'envoi d'un premier message au second nœud de réseau, le premier message comprenant un identifiant de cellule (CI) déterminé sur la base d'un CI associé au premier nœud de réseau ou à des informations de mappage de CI. L'invention concerne également un autre procédé qui peut comprendre : la réception d'un premier message provenant d'un nœud IAB qui passe d'un nœud de réseau source au nœud de réseau cible, le premier message comprenant un CI déterminé sur la base d'un CI associé au nœud de réseau source ou à des informations de mappage de CI ; la détermination du fait que le CI entre en collision ou non avec un CI d'au moins une cellule associée au nœud de réseau cible ; en réponse à la détermination du fait que le CI entre en collision avec le CI d'au moins une cellule, l'envoi d'un second message au nœud IAB, le second message comprenant une indication de CI pour le nœud IAB à utiliser ou une indication de cellules à désactiver.
PCT/IB2021/056050 2020-07-08 2021-07-06 Identités de cellules dans un réseau iab qui prend en charge une migration d'iab Ceased WO2022009093A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202063049300P 2020-07-08 2020-07-08
US63/049,300 2020-07-08
US202063050170P 2020-07-10 2020-07-10
US63/050,170 2020-07-10

Publications (1)

Publication Number Publication Date
WO2022009093A1 true WO2022009093A1 (fr) 2022-01-13

Family

ID=76999916

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2021/056050 Ceased WO2022009093A1 (fr) 2020-07-08 2021-07-06 Identités de cellules dans un réseau iab qui prend en charge une migration d'iab

Country Status (1)

Country Link
WO (1) WO2022009093A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230276315A1 (en) * 2020-07-13 2023-08-31 Datang Mobile Communications Equipment Co., Ltd. Cell global identifier configuration method and apparatus, and storage medium
WO2024017590A1 (fr) * 2022-07-21 2024-01-25 Canon Kabushiki Kaisha Évitement de collision pci dans un iab mobile 5g
WO2024065246A1 (fr) 2022-09-28 2024-04-04 Zte Corporation Configuration pour des communications avec des nœuds d'accès et de liaison terrestre intégrés
WO2024067224A1 (fr) * 2022-09-29 2024-04-04 华为技术有限公司 Procédé et appareil de mise à jour d'identité de cellule
WO2024066968A1 (fr) * 2022-09-27 2024-04-04 华为技术有限公司 Procédé de configuration d'identifiant et appareil de communication
WO2024067015A1 (fr) * 2022-09-27 2024-04-04 华为技术有限公司 Procédé de communication, appareil de communication et système de communication
WO2024231868A1 (fr) * 2023-05-08 2024-11-14 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'une nouvelle attribution d'identifiant de groupe de cellules radio pour des nœuds d'accès et de liaison terrestre intégrés mobiles
WO2024170503A3 (fr) * 2023-02-15 2024-11-21 Canon Kabushiki Kaisha Détection de collision pci dans un iab mobile 5g
WO2025036042A1 (fr) * 2023-08-11 2025-02-20 华为技术有限公司 Procédé et appareil de communication
WO2025066704A1 (fr) * 2023-09-27 2025-04-03 华为技术有限公司 Procédé de communication et dispositif associé
EP4557789A4 (fr) * 2022-08-11 2025-11-05 Huawei Tech Co Ltd Procédé, appareil et système de communication

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021098085A1 (fr) * 2020-03-06 2021-05-27 Zte Corporation Procédés et dispositifs pour mettre à jour des informations de configuration de nœud iab pendant une migration inter-donneur

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021098085A1 (fr) * 2020-03-06 2021-05-27 Zte Corporation Procédés et dispositifs pour mettre à jour des informations de configuration de nœud iab pendant une migration inter-donneur

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on Integrated Access and Backhaul; (Release 15)", 3GPP STANDARD; TECHNICAL REPORT; SPECIFICATIONS AND REPORTS FOR IMPLEMENTATION OF THE 3GPP TM SYSTEM SHOULD BE OBTAINED, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ;, vol. RAN WG2, no. 1.0.0, 3 December 2018 (2018-12-03), pages 1 - 111, XP051591008 *
QUALCOMM INCORPORATED: "Inter-donor topology adaptation procedures", vol. RAN WG3, no. E-meeting; 20210517 - 20210528, 6 May 2021 (2021-05-06), XP052001440, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_112-e/Docs/R3-211739.zip R3-211739 Inter-donor topology adaptation procedures.docx> [retrieved on 20210506] *
ZTE ET AL: "Views on Rel-17 IAB", vol. TSG RAN, no. Sitges, Spain; 20191209 - 20191212, 2 December 2019 (2019-12-02), XP051834225, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/TSG_RAN/TSGR_86/Docs/RP-192577.zip RP-192577 Views on Rel-17 IAB.doc> [retrieved on 20191202] *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230276315A1 (en) * 2020-07-13 2023-08-31 Datang Mobile Communications Equipment Co., Ltd. Cell global identifier configuration method and apparatus, and storage medium
WO2024017590A1 (fr) * 2022-07-21 2024-01-25 Canon Kabushiki Kaisha Évitement de collision pci dans un iab mobile 5g
EP4557789A4 (fr) * 2022-08-11 2025-11-05 Huawei Tech Co Ltd Procédé, appareil et système de communication
WO2024066968A1 (fr) * 2022-09-27 2024-04-04 华为技术有限公司 Procédé de configuration d'identifiant et appareil de communication
WO2024067015A1 (fr) * 2022-09-27 2024-04-04 华为技术有限公司 Procédé de communication, appareil de communication et système de communication
WO2024065246A1 (fr) 2022-09-28 2024-04-04 Zte Corporation Configuration pour des communications avec des nœuds d'accès et de liaison terrestre intégrés
EP4566365A4 (fr) * 2022-09-28 2025-09-03 Zte Corp Configuration pour des communications avec des noeuds d'accès et de liaison terrestre intégrés
WO2024067224A1 (fr) * 2022-09-29 2024-04-04 华为技术有限公司 Procédé et appareil de mise à jour d'identité de cellule
WO2024170503A3 (fr) * 2023-02-15 2024-11-21 Canon Kabushiki Kaisha Détection de collision pci dans un iab mobile 5g
WO2024231868A1 (fr) * 2023-05-08 2024-11-14 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'une nouvelle attribution d'identifiant de groupe de cellules radio pour des nœuds d'accès et de liaison terrestre intégrés mobiles
WO2025036042A1 (fr) * 2023-08-11 2025-02-20 华为技术有限公司 Procédé et appareil de communication
WO2025066704A1 (fr) * 2023-09-27 2025-04-03 华为技术有限公司 Procédé de communication et dispositif associé

Similar Documents

Publication Publication Date Title
US12543086B2 (en) Inter-CU migration in IAB network
US12382531B2 (en) IAB-node handover in inter-CU migration, recursive F1 and RRC signaling aspects
WO2022009093A1 (fr) Identités de cellules dans un réseau iab qui prend en charge une migration d&#39;iab
US12375979B2 (en) Implicit indication of centralized unit (CU) integrated access backhaul (IAB) capability
CN115997413B (zh) Cu间迁移中的iab节点切换
US12483944B2 (en) F1 setup during IAB handover
CN114026913B (zh) 能够实现支持集成接入回程网络中的多连接性的上行链路路由
US12317147B2 (en) Handling of buffered traffic during inter-CU migration of an integrated access backhaul (IAB) node
WO2019240646A1 (fr) Attribution d&#39;adresse de protocole internet (ip) dans des réseaux à raccordement d&#39;accès intégré (iab)
JP7357158B2 (ja) Ｉａｂネットワークにおけるデフォルトパス割り当て
CN110546992A (zh) 用于双连接通信系统中切换的系统和方法
EP4014675B1 (fr) Mise en correspondance entre des canaux rlc de liaison terrestre d&#39;entrée et de sortie dans des réseaux de liaison terrestre à accès intégré (iab)
US20230328604A1 (en) Handling of buffered traffic during inter-cu migration of an ancestor integrated access backhaul (iab) node
US12477405B2 (en) N2 aspects of integrated access and wireless access backhaul node inter-donor migration
WO2022025816A1 (fr) Signalisation e1 pour transfert intercellulaire en groupe
US20230269634A1 (en) Self organizing network report handling in mobile integrated access and backhaul scenarios
WO2021019332A1 (fr) Remappage sensible à une unité cu de donneur iab de supports dans un réseau iab
WO2022153249A1 (fr) Dispositifs et procédés de gestion de trafic de plan utilisateur en attente au niveau de nœuds ancêtres (parents) d&#39;un nœud d&#39;iab migrant
WO2022097119A1 (fr) Procédés et nœuds pour informer une cu de donneur iab au sujet de décisions locales

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21743584

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21743584

Country of ref document: EP

Kind code of ref document: A1