Mobile IAB-MT barring management
By allowing mlAB-MT to access non-supporting cells under specific conditions and enabling mode reconfiguration, the patent addresses connectivity issues in mixed mobile IAB networks, ensuring seamless operation and reduced service disruptions.
Patent Information
- Application Number
- GB2024018118
- Authority / Receiving Office
- GB · GB
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-02-19
- Filing Date
- 2024-12-10
- Publication Date
- 2025-08-20
AI Technical Summary
Mobile IAB nodes (mlAB-MT) are barred from accessing cells that do not support mobile IAB, causing connectivity issues when moving through networks with varying support for mobile IAB, and existing solutions do not allow seamless transition between IAB and UE modes.
Allow mlAB-MT to access cells not broadcasting mobilelAB-Support under specific conditions, such as no other cells supporting mobilelAB-Support within a time limit, and enable reconfiguration to operate as a regular UE or IAB node as needed.
Enables mlAB-MT to maintain connectivity in non-supporting areas and transition smoothly between IAB and UE modes, enhancing mobility and reducing service disruptions.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
BACKGROUND Field Certain examples of the present disclosure provide one or more techniques for mobile IAB-MT barring management, for example in a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) network. Description of the Related Art Various acronyms, abbreviations and definitions used in the present disclosure are defined at the end of this description. Overview of IAB In 3GPP 5G NR, Integrated Access and Backhaul (IAB) is a technique for providing wireless backhaul as an alternative to a fibre backhaul network. An IAB network comprises IAB nodes, at which wireless resources are shared between wireless backhaul and access links. By means of such a configuration, it is possible to install nodes without the necessity of providing a fibre data connection, thereby allowing speedy and simple roll out of network coverage to locations where no such data connection is available or possible. Due to the limited coverage area of an IAB node, the backhaul network is typically implemented as a multi-hop network with backhaul traffic traversing multiple IAB nodes. Figure 1 shows a two-hop IAB network as described in 3GPP NR Rel-16 and further enhanced in Rel-17. 3GPP 5G Release 16 was the first release comprising the IAB feature. Release 17 comprised enhancements on top of the Release 16 baseline and is now frozen. Work on Release 18 is currently underway to develop and improve features relating to IAB relative to previous Releases, most notably the mobility of IAB nodes. Assumption in previous Releases was that IAB nodes are stationary. Overview of Barring A UE, or any other terminal device (such as IAB-MT, mIAB-MT or NCR-MT) may be barred from a cell. Being barred from a cell means that the UE shall not camp on a cell that is barred, and may in some cases not consider the cell in the cell selection or cell reselection algorithm. This may also sometimes be referred to as Cell status and cell reservations. A UE may be barred from a cell due to a range of reasons including one or more of the following: cellBarred is signalled with value true in MIB. This means that no UE can access the cell, unless there is nothing else signalled. This is useful as it allows as it allows for the UE to determine whether it is barred without having to acquire SIB1, thus saving power during for instance cell reselection. cellBarredXdue to any cell-wide feature is signalled in SIB1, for instance: o cellBarredNTN - indicates whether an NTN UE is barred from accessing the cell. In this case the cell will utilize the cellBarred in MIB to barr all legacy, non-NTN UEs from accessing the cell and then the cellBarredNTN in SIB1 is used to barr NTN UEs. o cellBarredATG, cellBarredRedCapI Rx, cellBarredNES all operate in the same manner. This is useful when the cell is enhanced and requires all UE to have implemented some feature in order to access the cell, such as an NTN UE, where without having implemented NTN features, the UE cannot access the cell. - X-Support in SIB1- Which is barring operation for specific types of UEs, for instance: o iab-Support - indicates whether IAB nodes are barred or not to connect to the cell. An lAB-node will ignore the cellBarred in MIB and only consider this bit whether it is barred from entering a UE. o ncr-Support operate in a similar manner. This is type of barring useful when there are multiple types of UEs in a network, and a network may not support certain types of UEs to access the cell. cellReservedForOtherUse - Allows the network to be reserved for a specific future use. If it is true then legacy UEs will be barred. Overview of Mobile IAB Mobile IAB is a 3GPP Release 18 work item whose focus is to enhance IAB to enable mobile lABs. The deployment purpose of the mobile IAB is to allow for lAB-DUs to provide connectivity on trains, buses etc. Mobile IAB does not support Dual Connectivity options (i.e. EN-DC or NR-DC). The focus is to provide good mobility support. The Work Item Description mentions the following enhancements [RP-222671, Mobile IAB (Integrated Access and Backhaul) for NR, Qualcomm, RAN#97, September 2022]: • Define Procedures for migration / topology adaptation to enable lAB-node mobility, including inter-donor migration of the entire mobile lAB-node (full migration) [RAN3, RAN2] o The mobile lAB-node can connect to a stationary (intermediate) lAB-node. Optimizations specific to the scenarios, where the mobile lAB-node connects to a stationary (intermediate) lAB-node, or where it directly connects to an IAB-donor-DU are de-prioritized. o The mobility of dual-connected lAB-nodes is down-prioritized. • Enhancements for mobility of an lAB-node together with its served UEs, including aspects related to group mobility. No optimizations for the targeting of surrounding UEs. [RAN3, RAN2] Note: Solutions should avoid touching upon topics where Rei-17 discussions already occurred and where the topic was excluded from Rel-17, except for enhancements that are specific to lAB-node mobility. • Mitigation of interference due to lAB-node mobility, including the avoidance of potential reference and control signal collisions (e.g. PCI, RACH). [RAN3, RAN2] For the purpose of the enhancements related to mobility two main enhancements were introduced: - RACH-less handover, which allows UEs to perform very fast handovers when the mlAB-MT perform DU migration. o This takes advantage of the fact that the handovers are performed to same physical mlAB cell. - Enhanced UE cell reselection prioritizing an mlAB cell if the UE detects that it is onboard a vehicle. o If the UE detects that it is onboard a vehicle, the UE will prioritize any cell that indicates that it is an mlAB cell. The indication of the mlAB being an mlAB cell is sent in SIB1. o The non-mlAB cells may also broadcast cell reselection assistance information that indicates that there are mlAB cells to prioritize if the UE is onboard a vehicle. The enhancements relating migration / topology enhancements include that there is the possibility for a donor gNB to indicate whether it supports mobile lABs connecting to it. This is similar to the indication introduced in Release 16 IAB whereby a donor gNB may indicate whether it supports IAB. For a release 16 IAB, the donor gNB must indicate that it is IAB-capable, otherwise the IAB-MT may not connect to the cell. Both the Rel-16 IAB indicator and the Rel-18 mlAB indicator are sent as part of PLMN-ldentitylnfoList in SIB1: -------------------------3GPPTS 38.331 V18.0.0------------------------- PLMN-ldentitylnfoList The IE PLMN-ldentitylnfoList includes a list of PLMN identity information. PLMN-ldentitylnfoList information element 3GPPTS 38.331 V18.0.0 The following was agreed at the RAN2#123bis meeting (Xiamen) on the issue of Rel-18 mlAB node’s capabilities and its ‘place’ in the Rel-16 / 17 IAB node evolution: => From R2 perspective It is not supported that Rel-18 mobile lAB-node concurrently operate as a Rel-16 / 17 lAB-node, as e.g. mobile-IAB doesn’t support child IAB nodes. => This means that there are restrictions for the network in configuring concurrent use of R-18 mlAB feature(s) and rel-16 / 17 IAB features (details FFS). => FFS if an lAB-node may send both MSG5 indications to the network, and the network decides (or if the lAB-node should decide). => RAN2 assumes that the mobilelAB-Nodelndication-r18 in Msg5 implies a preference / intention, with the purpose to help gNB select core network node at initial registration. => RAN2 assumes that the MT Idle mode behaviours is reflected by a Cap wo signalling in 38306. => FFS if a separate mobile-IAB capability (signalled) is introduced in Rel-18. The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present invention. SUMMARY It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein. The present invention is defined in the independent claims. Advantageous features are defined in the dependent claims. Embodiments or examples disclosed in the description and / or figures falling outside the scope of the claims are to be understood as examples useful for understanding the present invention. Other aspects, advantages and salient features of the invention will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 (from 3GPP TR 38.874, “Study on Integrated Access and Backhaul”, V16.0.0, December 2018) illustrates an exemplary two-hop IAB network; Figure 2 illustrates an mlAB node entering an area where cells do not support mlAB; Figure 3 is a flowchart of an exemplary method for allowing an mlAB-MT device to access a network not broadcasting mobilelAB-Support; Figure 4 is a call flow of an exemplary method in which an mlAB node is redirected to another network supporting mlAB; Figure 5 is a flowchart of an exemplary method of a terminal according to examples of the present disclosure; and Figure 6 is a block diagram of an exemplary network entity that may be used in certain examples of the present disclosure. DETAILED DESCRIPTION The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present invention, as defined by the claims. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention. The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings. Detailed descriptions of techniques, structures, functions, operations or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present invention. The terms and words used herein are not limited to the bibliographical or standard meanings, but, are merely used to enable a clear and consistent understanding of the invention. Throughout the description and claims of this specification, the words “comprise”, “include” and “contain” and variations of the words, for example “comprising” and “comprises”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof. Throughout the description and claims of this specification, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects. Throughout the description and claims of this specification, language in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y. Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim described herein unless incompatible therewith. The skilled person will appreciate that the techniques described herein may be used in any suitable combination. Certain examples of the present disclosure provide one or more techniques for mobile IAB-MT barring management, for example in a3GPP 5G NR network. However, the skilled person will appreciate that the present invention is not limited to these examples, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards, including any existing or future releases of the same standards specification, for example 3GPP 5G, 5G-advanced or 6th Generation (6G). The functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in the same or any other suitable communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function or purpose within the network. For example, the functionality of a base station or the like (e.g. eNB, gNB, NB, RAN node, access point, wireless point, transmission / reception point, central unit, distributed unit, radio unit, remote radio head, etc.) in the examples below may be applied to any other suitable type of entity performing RAN functions, and the functionality of a UE or other terminal device (e.g. IAB-MT, mlAB-MT, NCR-MT, electronic device, user device, mobile station, subscriber station, customer premises equipment, terminal, remote terminal, wireless terminal, vehicle terminal, etc.) in the examples below may be applied to any other suitable type of device. A particular network entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The skilled person will appreciate that the present invention is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements or entities may be added to the examples disclosed herein. • One or more non-essential elements or entities may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed and / or the order in which messages are transmitted may be modified, if possible, in alternative examples. Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Certain examples of the present disclosure may be provided in the form of a system (e.g. network or wireless communication system) comprising one or more such apparatuses / devices / network entities, and / or a method therefor. Certain examples of the present disclosure provide a UE (e.g. IAB-MT, mlAB-MT, NCR-MT) I network entity (e.g. AMF, SMF, NF) I base station (e.g. eNB, gNB) configured to perform a method according to any example, aspect, embodiment and / or claim disclosed herein. Certain examples of the present disclosure provide a network (or wireless communication system) comprising a UE (e.g. IAB-MT, mlAB-MT, NCR-MT), network entity (e.g. AMF, SMF, NF), base station (e.g. eNB, gNB) according to any examples, aspects, embodiments and / or claims disclosed herein. Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any example, aspect, embodiment and / or claim disclosed herein. Certain examples of the present disclosure provide a computer or processor-readable data carrier having stored thereon a computer program according to any example, aspect, embodiment and / or claim disclosed herein. At the most recent RAN2 meeting (RAN2#124, Chicago, November 2023), the following was agreed on the issue of mlAB vs. IAB operation, and: => A parent node indicates support of mobile IAB but not Rel-16 / 17 IAB by broadcasting the “mobile lABsupported” indicator but not the “lABsupported” indicator in SIB1. => A parent node indicates support of both, mobile IAB and Rel-16 / 17 IAB, by broadcasting “mobile lABsupported” and “lABsupported” in SIB1. => From AS / R2 point of view, an lAB-node indicates capabilities to the network and the use of these are configured by the network. => R2 assumes that the device can know whether it is intended to operate as R18 mlAB or R16 / 17-IAB node, (how the device knows is outside R2 scope, e.g. subscription, device internal param etc), the MSG5 indication is an indication of this intended mode of operation. This agreement is not intended to mandate that a mlAB node must support R16 / 17 operation (FFS pending cap discussion) => R2 assumes that the lAB-node only indicates either mobile IAB or Rel-16 / 17 IAB for MSG5, not both. Additionally, SA2 agreed the following at their January 2024 meeting: As defined in TS 38.331
[28] , when a MBSR includes the mobile lAB-indication when establishing the RRC connection, it shall not include the lAB-indication as described in clause 5.35.2. The table below (from 3GPP R2-2312148, given as an illustration of one possible interpretation of the current situation, with additional comments in italics part of the present disclosure) summarises certain access barring options for an mlAB / MBSR device: Rel-16 / Rel-17 IAB Rel-18 mobile IAB cell broadcasting “iab-Support" “iab-Nodelndication" in MSG5 This is legacy IAB behaviour. “iab-Nodelndication" in MSG5 and function as Rel-16 / Rel-17 IAB In line with agreement made in Chicago, although should be noted that an mlAB device need not be mandated to be able to operate as an IAB device. cell broadcasting “mobilelAB-Support” barred This is legacy behaviour (legacy node cannot understand mlAB indication). “mobilelAB-Nodelndication" in MSG5 Rules out the possibility of mlAB device operating as an IAB node, but in this case the network is not broadcasting iab-support and therefore the behaviour is as expected. cell broadcasting “mobilelAB-Support" and “iab-Support" “iab-Nodelndication" in MSG5 This is legacy IAB behaviour. 1) “iab-Nodelndication" and function as Rel-16 / Rel-17 IAB 2) “mobilelAB-Nodelndication" in MSG5 Both indications cannot be sent as per SA2 agreement, and as per RAN2 agreement device can know whether it is intended to operate as R18 mlAB or R16 / 17-IAB node. Therefore this is expected behaviour. cell broadcasting neither “mobilelAB-Support" nor “iab-Support" barred This is legacy IAB behaviour. barred Possible open Issue One open issue identified above is whether an mlAB-MT should be barred from accessing the network as a UE, when cell is broadcasting neither “mobilelAB-Support” nor “iab-Support”. For an IAB-MT there was little use for this (to allow access as regular UE) due to static deployments. But given the fact that an mlAB-MT is moving from areas where network supports mlAB into areas where there is no mlAB support, and back - it may make sense to allow connectivity as a UE for e.g. configuration purposes. This scenario where an mlAB is located on a train can be seen in Figure 2. According to certain examples of the present disclosure, this is allowed. As per the agreements referenced above, an ml AB would ‘know’ whether it should connect as mlAB or IAB (we assume any mlAB could do both, although this is not mandated, but does appear to be a reasonable assumption, although simultaneous operation as mlAB and IAB is not allowed or at least not supported by standards). First row of the Table above refers to an mlAB-MT detecting a cell broadcasting iab-Support. An mlAB which (at that point in time) views itself as an IAB node would then access this cell as an IAB node. While this is not a key scenario in certain examples of the present disclosure - certain examples relate to a node that is configured to act as an mlAB node, in the case where the detected cell does not broadcast mlAB support (i.e. last row of the Table) - in some examples access as a regular UE of an mlAB node configured to operate as an mlAB node is predicated on IAB support broadcast, and therefore the first-row scenario is also impacted. In certain examples of the present disclosure, an mlAB-MT device is allowed to access a network not broadcasting mobilelAB-Support. This brings certain benefits as disclosed herein but requires changes to the features of the current mobile networks, which are described in the examples below. As an mlAB node moves through a network, there will be cases when it will move through a network where there is no support for mlABs, i.e. there is no broadcasting of the mlAB-Support. Similarly, there can also be cases where the broadcasting of the mobilelAB-Support has stopped. The actions in certain examples can be seen in Figure 3. The step of deciding to access non-mlAB supporting cell is described below under the heading “mlAB decides to access non-mlAB supporting cell” and the (optional) step of re-configuring mlAB-MT is described below under heading “Actions after accessing non-mlAB cell ”. In certain examples of the present disclosure, being barred from a cell is equivalent to not being allowed to access a cell, and not being barred from a cell is equivalent to being allowed to access a cell. In certain examples, barring may be regarded as meaning temporarily not being allowed access (for example, where barring may be regarded as meaning delayed access). mlAB decides to access non-mlAB supporting cell In these cases, in certain examples, the mlAB-MT will be allowed to access the network, i.e. a cell or a gNB. An equivalent statement, would be that a mlAB-MT would not be barred from accessing a cell not broadcasting the mobilelAB-Support. However, while the above may be useful for a mlAB-MT in an area where there is no support for mobile IAB, it may also cause issues in areas where there are support for mlAB, i.e. the mlAB-MT may connect to cells that do not support mlAB, while there in fact are mlAB-capable cells. Thus there may need to be some refinements to the conditions. In a refinement, an mlAB-MT which is allowed to access the network as a regular UE even when a cell is not broadcasting mobilelAB-Support, enters an area where there is a mix of cells broadcasting mobilelAB-Support and not broadcasting mobilelAB-Support. In one scenario, the mlAB-MT is only allowed to select cells which do broadcast mobilelAB-Support. In another scenario, the network can override this by configuring the priority of various cells i.e. selection of cells which do not broadcast mobilelAB-Support may be allowed even in presence of cells which do broadcast mobilelAB-Support. Some further refined conditions on when a mlAB-MT may access a cell: - The mlAB-MT is allowed to access the network as a UE if there are no other cells broadcasting mobilelAB-Support, or alternatively the mlAB-MT is not barred to access a cell that does not broadcast mobilelAB-Support if there are no cells detected by the mlAB-MT that are broadcasting the mobilelAB-Support. o The condition can be further refined that there are no other cells broadcasting mobilelAB-Support on the frequency, no other cells broadcasting mobilelAB-Support on the PLMN, no other cells broadcasting mobilelAB-Support in a Tracking area o The condition can be that there are no cells broadcasting the mobilelAB-Support detected by the mlAB-MT within a time-limit. This time-limit can be hardcoded or configured. A suitable hardcoded, could be 300 seconds. ■ As refinement the mlAB-MT may be allowed to access a cell, i.e. is not barred to access a cell, if the mlAB-MT has been barred from accessing the cell for more than 300 seconds ■ Has been barred from accessing any cell for more than 300 seconds • This can be useful if the mlAB-MT is barred for other reasons from accessing other cells, other than not broadcasting mobilelAB-Support o This makes it so that the UE will always select a cell with mobilelAB-Support before selecting a cell that does not broadcast mobilelAB-Support - Any cell broadcasting mobilelAB-Support on any frequency will always have highest priority, i.e. the condition remains that the mlAB-MT is allowed to access a cell not broadcasting mobilelAB-Support, but that the mlAB-MT will always select a cell that broadcasts the mobilelAB-Support, if the cell is detected. o This priority may be configured by the network, for instance via dedicated signalling - Allowing an mlAB-MT to access the network as a regular UE even when a cell is not broadcasting mobilelAB-Support is predicated on said cell broadcasting iab-Support. It could be assumed that a cell that broadcasts iab-Support belongs to a part of the network which supports IAB operation and therefore may also support some aspects (features) of mlAB operation. - A further condition that can be combined with other conditions is that an mlAB-MT may access a non-mlAB cell if the mlAB-node has previously operated as an mlAB cell. The condition may for instance be that the mlAB-node has detected cells supporting mlAB, or that mlAB-MT has registered, authenticated or been authorized to operate as an lAB-node or an mlAB-node. o Further refine is that it must have done so within 24 hours. Further condition that can be combined with the other conditions is that mlAB can only access a non-mlAB supporting cell on network, PLMN or tracking area with which the mobile IAB has already registered. - Further condition that can be combined with the other conditions is that mlAB can only access a non-mlAB supporting cell on network, PLMN or tracking area with which the mobile IAB has not already registered. Further condition that can be combined is that the mlAB-MT has not been released by a network o For instance if the UE has been released by a network, i.e. via RRC release message, the UE may not access a cell that does not support mlAB. o This can have a time-limit, configured or hardcoded, for instance 300 seconds In certain examples, accessing a non-mlAB supporting cell can only be done during specific states of the mlAB: o During RRC re-establishment, i.e. if the mobile IAB-MT selects a cell that does not indicate mobilelAB-Support during the cell selection during RRC Reestablishment procedure o When the UE is in idle or inactive mode The cell not supporting mlAB may for instance be an 4G LTE cell, i.e. an E-UTRAN cell. This would mean that the mlAB node performs access to the E-UTRAN cell as a UE. The E-UTRAN cell may be a cell that supports IAB EN-DC, which means that the cell is broadcasting iab-Support, or the cell may be a cell that does not support IAB, i.e. the cell does not broadcast iab-Support. There may also be limitations on whether an mlAB node connecting as a UE is allowed to connected to an E-UTRAN cell that is connected via 5GC or EPC. For instance, the mlAB-node may only be allowed to connect as a UE to an E-UTRAN cell connected via 5GC, which is an NG-eNB. The conditions for connecting may be similar, i.e. that there are no cells which support mlAB detected, but there may also be further conditions such as no NR cells detected before the mlAB node can connect via E-UTRAN, or via EPC. Actions after accessing non-mlAB cell In certain examples, when the mlAB-MT accesses a cell that does not indicate mobilelAB-Support, the mlAB-MT (or IAB-MT, or “UE”) does not indicate the mobilelAB-Nodelndication or iab-Nodelndication. An mlAB-MT may be allowed to access the network as a regular UE to the network the mlAB-MT is attached to, which is not supporting mlAB-MT, leading to said mlAB-MT and UEs attaching to it being configured to access another operator’s network in the area which does support mlAB. In other words, the mlAB node may connect to the network it is already attached to as a UE, and then be redirected to another operators network to operate as an mlAB node. The call flow can be seen in Figure 4. Note that “Network” is intentionally broad, which can be different or same operator, different or same PLMNs, different AMFs etc. Network 1 does not broadcast mobile IAB support and according to prior art the mlAB-MT may not be allowed to access it at all and mlAB would not provide service to any UEs. If we allow it to access the network as a regular UE, the network can be made aware of its potential to operate as mlAB and could hand over to another network (which supports mobile IAB), based on a local roaming agreement. The mlAB node may be configured with new cells, new tracking areas or PLMNs that the mlAB-MT is allowed to access to. For instance the allowed tracking areas and allowed PLMNs may be reconfigured via NAS. The mlAB node may be authorized or configured or reconfigured to function as an IAB node (including declaring itself to the network as an IAB node) instead of functioning as a mlAB node. i.e. the mlAB may be re-configured to an IAB node. If a mlAB node is authorized to act as an mlAB node, and then receives an authorization to act as an IAB node, the actions may be one of the following: - The mlAB node is now authorized as an IAB node, and no longer authorized as an mlAB node. - The mlAB node is now authorized both to act as an mlAB node and an IAB node. The mlAB node may be set up to allow for UE emergency calls. For instance if the mlAB register to a cell, PLMN, or tracking area of another operator, the mlAB-node may continue to provide service for the new operator. This may allow some of the UEs to camp on the mlAB-node to provide emergency camping, i.e. the UE camps on the cell provided by the mlAB for emergency cells. The mlAB itself may alternatively be allowed to access their own operator network for purposes of making or forwarding emergency calls. Further aspects Prior art mainly assumes an lAB / mlAB node is tied to a specific network. Certain examples of the present disclosure build on this to cover access to other networks in cases where access to own network as an mlAB would not be possible - we allow access as a UE, which then gets handed over to another network to operate using its mlAB features, as covered above. Reverting to original configuration is an additional feature of certain examples of the present disclosure. How to revert to an original configuration is important if the mlAB node is PLMN specific, and the result of the original network (network 1) pushing the mlAB node to a different network (network 2) meaning that the customers of network 1 may lose all service apart from emergency calling. The commercial model would be complex, but also the technical reconfiguration of the mlAB node would be quite disruptive, so there should definitely be triggers defined to revert back to original configuration. It also means the mlAB node needs to store its original configuration, or at least, continue to seek a network 1 node advertising ‘mobilelAB-Support’, even when attached to network 2, and re-attach to network 1 as soon as a network 1 node becomes available. This could trigger either the reconfiguration of the mlAB node from storage, or the mlAB node to be reconfigured back to network 1 configuration by the network itself. Specification Example An example of how the existing specification may be modified to incorporate one or more of the above techniques will now be described. In the following examples, revisions are indicated with underline. Example 1 --------------------------3GPP TS 38.331 V18.0.0 Example 1 -------------------------- 5.2.2.4.2 Actions upon reception of the SIB1 Upon receiving the SIB1 the UE shall: 1> if in RRCCONNECTED while T311 is not running: 1> else: 3> else if UE is a mobile IAB-MT and if mobilelAB-Support is not provided for the selected PLMN nor the registered PLMN nor PLMN of the equivalent PLMN list nor the selected SNPN nor the registered SNPN nor SNPN of the equivalent SNPN list; and if. 3> the UE is a mobile IAB-MT which has detected other cell(s) broadcasting mobilelAB-Support for the selected PLMN or the registered PLMN or PLMN of the equivalent PLMN list or the selected SNPN or the registered SNPN or SNPN of the equivalent SNPN list: 4> consider the cell as barred in accordance with TS 38.304
[20] ; NOTE 1: If tire mobile IAB-MT detects no other cell broadcasting mobilelAB-Support. and performs RRC establishment, the mobile IAB-MT does not consider itself to be connecting as a mobile IAB-node, see 5,3,3,4. --------------------------3GPP TS 38.331 V18.0.0 Example 1 -------------------------- Figure 5 is a flowchart of an exemplary method of a terminal according to examples of the present disclosure. The terminal is capable of acting as a m-IAB-MT. In step 501 the method comprises determining to access a cell that is not broadcasting information indicating that the cell supports mobile IAB. In response to determining to access the cell that is not broadcasting information indicating that the cell supports mobile IAB, in step 502 the method comprises accessing the cell as a user equipment (UE) or accessing the cell as an IAB-MT. Figure 6 is a block diagram of an exemplary network entity that may be used in examples of the present disclosure. For example, a UE (e.g. IAB-MT, mlAB-MT, NCR-MT) I network entity (e.g. AMF, SMF, NF) I base station (e.g. eNB, gNB) in the examples of Figures 1-5 may comprise an entity of Figure 6. The skilled person will appreciate that a network entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The entity 600 comprises a processor (or controller) 601, a transmitter 603 and a receiver 605. The receiver 605 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 603 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 601 is configured for performing one or more operations, for example according to the operations as described above. The techniques described herein may be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system may be configured to perform a method according to any aspect, embodiment, example or claim disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software. It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment, aspect and / or claim disclosed herein, and / or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection. In a first example, there is provided a method of a terminal, wherein the terminal is capable of acting as a mobile integrated access and backhaul mobile terminal (mlAB-MT), the method comprising: determining to access a cell that is not broadcasting information indicating that the cell supports mobile IAB; in response to determining to access the cell that is not broadcasting information indicating that the cell supports mobile IAB, accessing the cell as a user equipment (UE) or accessing the cell as an IAB-MT. In a second example, there is provided the method of the first example, wherein accessing the cell as a UE comprises accessing the cell without providing backhaul services via the cell. In a third example, there is provided the method of the first or second example, wherein accessing the cell as a UE comprises accessing the cell for configuration purposes. In a fourth example, there is provided the method of any of the first to third examples, wherein accessing the cell as a UE comprises accessing the cell for operation, administration, and maintenance (OAM) access. In a fifth example, there is provided the method of any of the first to fourth examples, wherein accessing the cell as a UE or accessing the cell as an IAB-MT comprises accessing the cell without indicating that the terminal is a mobile IAB node. In a sixth example, there is provided the method of the fifth example, wherein accessing the cell as an IAB-MT comprises: determining whether the cell is broadcasting information indicating that the cell supports IAB; and in response to determining that the cell is broadcasting information indicating that the cell supports IAB, accessing the cell as an IAB-MT without indicating that the terminal is a mobile IAB node. In a seventh example, there is provided the method of the fifth example, wherein accessing the cell as a UE further comprises accessing the cell without indicating that the terminal is an IAB node In an eighth example, there is provided the method of any of the first to fourth examples, wherein the information indicating that the cell supports mobile IAB comprises mobilelAB-Support broadcast in SIB1. In a ninth example, there is provided a terminal capable of acting as a mobile integrated access and backhaul mobile terminal (mlAB-MT), wherein the terminal is configured to operate according to a method of any of the first to eighth examples. In a tenth example, there is provided a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any of the first to eighth examples. In an eleventh example, there is provided a computer or processor-readable data carrier having stored thereon a computer program according to the tenth example. While the invention has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention, as defined by the appended claims. Abbreviations / Definitions In the present disclosure, the following acronyms / definitions may be used. 3GPP 3rd Generation Partnership Project 4G 4th Generation 5G 5th Generation rr'r- ObU 5G Core 6G 6th Generation AMF Access and Mobility management Function ATG Air-to-Ground DU Distributed Unit eNB Base Station EN-DC E-UTRA NR Dual Connectivity EPC Evolved Packet Core E-UTRA Evolved Universal Terrestrial Radio Access E-UTRAN Evolved Universal Terrestrial Radio Access Network gNB 5G NR Base Station IAB Integrated Access and Backhaul ID Identity / ldentifi cation IE Information Element LTE Long Term Evolution MBSR Mobile Base Station Relay mlAB Mobile IAB MIB Master Information Block MSG Message MT Mobile Termination NAS Non Access Stratum NB Base Station NCR Network Controlled Repeater NF Network Function NG Next Generation NR New Radio NR-DC NR Dual Connectivity NTN Non-Terrestrial Network PCI Physical Cell ID PLMN Public Land Mobile Network RAN Radio Access Network RACH Random Access Channel RANAC RAN Area Code Rei Release RRC Radio Resource Control Rx Receive SIB System Information Block SMF Session Management Function SNPN Standalone Non-Public Network TAC Tracking Area Code TAG Timing Advance Group TR Technical Report TS Technical Specification UE User Equipment
Claims
1. A method of a terminal, wherein the terminal is capable of acting as a mobile integrated access and backhaul mobile terminal (mlAB-MT), the method comprising:determining to access a cell that is not broadcasting information indicating that the cell supports mobile IAB;in response to determining to access the cell that is not broadcasting information indicating that the cell supports mobile IAB, accessing the cell as a user equipment (UE) or accessing the cell as an IAB-MT.
2. The method of claim 1, wherein accessing the cell as a UE comprises accessing the cell without providing backhaul services via the cell.
3. The method of claim 1 or claim 2, wherein accessing the cell as a UE comprises accessing the cell for configuration purposes.
4. The method of any preceding claim, wherein accessing the cell as a UE comprises accessing the cell for operation, administration, and maintenance (OAM) access.
5. The method of any preceding claim, wherein accessing the cell as a UE or accessing the cell as an IAB-MT comprises accessing the cell without indicating that the terminal is a mobile IAB node.
6. The method of claim 5, wherein accessing the cell as an IAB-MT comprises:determining whether the cell is broadcasting information indicating that the cell supports IAB; andin response to determining that the cell is broadcasting information indicating that the cell supports IAB, accessing the cell as an IAB-MT without indicating that the terminal is a mobile IAB node.
7. The method of claim 5, wherein accessing the cell as a UE further comprises accessing the cell without indicating that the terminal is an IAB node8. The method of any preceding claim, wherein the information indicating that the cell supports mobile IAB comprises mobilelAB-Support broadcast in SIB1.
9. A terminal capable of acting as a mobile integrated access and backhaul mobile terminal (mlAB-MT), wherein the terminal is configured to operate according to a method of any preceding claim.
10. A computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any of claims 1 to 8.
11. A computer or processor-readable data carrier having stored thereon a computer program according to claim 10.