WO2019212544A1

WO2019212544A1 - Centralized cell admission control for self-backhaul

Info

Publication number: WO2019212544A1
Application number: PCT/US2018/030656
Authority: WO
Inventors: Charles Payette; Bruce Cilli; Sameerkumar Sharma
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2018-05-02
Filing date: 2018-05-02
Publication date: 2019-11-07

Abstract

Various communication systems may benefit from improved call admission. For example, it may be helpful to improve call admission in a self-backhaul network. A method, according to certain embodiments, may include receiving at ta network entity in a self-backhaul network a congestion level metric from one or more network nodes. The method may also include performing at the network entity radio admission control in the self-backhaul network. The radio admission control may be based on the congestion level metric. In addition, the method may include transmitting from the network entity a result of the performed radio admission control.

Description

TITLE:

CENTRALIZED CELL ADMISSION CONTROL FOR SELF-BACKHAUL

BACKGROUND:

Field:

[0001] Various communication systems may benefit from improved call admission. For example, it may be helpful to improve radio admission control in a self-backhaul network.

Description of the Related Art:

[0002] Third Generation Partnership Project (3GPP) technology, such as Long Term Evolution (LTE), Fifth Generation (5G), or New Radio (NR) utilize Radio Admission Control (RAC). RAC allows a network to authorize a user equipment (UE) and/or bearer admission only when the network statically supports the bearer or the UE. Given the dynamic nature of wireless networks, a RAC may have difficulty functioning since radio conditions may change over time, and drastically affect the resource utilization of any single UE. The complexities caused by the changing radio conditions may be independent of the time varying data rates of a single UE or bearer, which adds an additional layer of difficulty.

[0003] Certain wireless networks may employ wireless self-backhauling, in which a wireless base transceiver station (BTS) or base station can provide backhauling services for another BTS. A BTS may be deployed in any location and use another BTS for its backhaul link. A self-backhauling (sBH) BTS node may service a UE as a traditional base station, except that the backhaul of the sBH BTS node does not link to a core network, but rather to another BTS, which may be referred to as a donor BTS. The sBH BTS node, may simply be referred to as a sBH node. The sBH BTS node may include two different parts having distinct functioning. The first part of the node may function as a BTS, referred to sBH BTS, while the second may function as a UE, referred to sBH UE. The sBH UEs may aggregate the backhaul traffic into tunnels that may be referred to as so-called fat pipes. From the perspective of the donor BTS, the traffic transmitted from the one or more sBH BTS nodes in the fat pipes may look like a single UE. Multiple sBH BTS nodes may be chained together to support a multi-hop backhaul topology. The donor BTS may support the backhauling link to the sBH BTS node, while simultaneously supporting connections to other UEs.

[0004] In the context of 5G technology, the sBH node may be utilized in an environment with high frequency bands, such as an mmWave range that supports greater bandwidth. The mmWave band may not propagate through buildings or objects well, and may act as a line of sight wave that reaches very short distances, for example a couple of hundred meters. A large number of closely spaced BTS units or 5G NR Node (gNB) may be deployed in order to provide sufficient coverage for mmWave usage. Self-backhauling, however, may help to alleviate the number of costly fixed wired backhaul connections needed for the gNBs.

SUMMARY

[0005] According to certain embodiments, an apparatus may include at least one memory including computer program code, and at least one processor. The at least one memory and the computer program code may be configured, with the at least one processor, to cause die apparatus at least to receive at a selfbackhaul network a congestion level metric from one or more network nodes. The at least one memory and the computer program code may also be configured, with the at least one processor, to cause the apparatus at least to perform radio admission control in the self-backhaul network. The radio admission control may be based on the congestion level metric. In addition, the at least one memory and die computer program code may be configured, with the at least one processor, to cause the apparatus at least to transmit a result of the performed radio admission control.

[0006] A method, according to certain embodiments, may include receiving at a network entity in a self-backhaul network a congestion level metric from one or more network nodes. The method may also include performing at the network entity radio admission control in the self-backhaul network. The radio admission control may be based on the congestion level metric. In addition,, the method may include transmitting from the network entity a result of the performed radio admission control.

[0007] An apparatus, in certain embodiments, may include means for receiving at a self-backhaul network a congestion level metric from one or more network nodes. The apparatus may also include means for performing radio admission control in the self-backhaul network. The radio admission control may be based on the congestion level metric. In addition, the apparatus may include means for transmitting a result of the performed radio admission control.

[0008] According to certain embodiments, a n on-transitory computer-readable medium encoding instructions that, when executed in hardware, perform a process. The process may include receiving at a network entity in a selfbackhaul network a congestion level metric from one or more network nodes. The process may also include performing at the network entity radio admission control in the self-backhaul network. The radio admission control may be based on the congestion level metric. In addition, the process may include transmitting from the network entity a result of the performed radio admission control.

[0009] According to certain other embodiments, a computer program product may encode instructions for performing a process. The process may include receiving at a network entity in a self-backhaul network a congestion level metric from one or more network nodes. The process may also include performing at the network entity radio admission control in the self-backhaul network. The radio admission control may be based on the congestion level metric. In addition, the process may include transmitting from the network entity a result of the performed radio admission control.

[0010] An apparatus, in certain embodiments, may include circuitry for receiving at a self-backhaul network a congestion level metric from one or more network nodes. The apparatus may also include circuitry for performing radio admission control in the self-backhaul network. The radio admission control may be based on the congestion level metric. In addition, the apparatus may include circuitry for transmitting a result of the performed radio admission control.

[001 If According to certain embodiments, an apparatus may include at least one memory including computer program code, and at least one processor. The at least one memory and the computer program code may be configured, with the at least one processor, to cause the apparatus at least to transmit to a network entity in a self-backhaul network a congestion level metric. The at least one memory and the computer program code may also be configured, with the at least one processor, to cause the apparatus at least to receive a result of radio admission control in the self-backhaul network from the network entity. The radio admission control may be based on the congestion level metric.

[0012] A method, according to certain embodiments, may include transmitting from a network node to a network entity in a self-backhaul network a congestion level metric. The method may also include receiving at the network node a result of radio admission control in the self-backhaul network from the network entity. The radio admission control may be based on the congestion level metric.

[0013] An apparatus, in certain embodiments, may include means for transmitting to a network entity in a self-backhaul network a congestion level metric. The apparatus may also include means for receiving a result of radio admission control in the self-backhaul network from the network entity. The radio admission control may be based on the congestion level metric.

[0014] According to certain embodiments, a non-transitory computer-readable medium encoding instructions that, when executed in hardware, perform a process. The process may include transmitting from a network node to a network entity in a self-backhaul network a congestion level metric. The process may also include receiving at the network node a result of radio admission control in the self-backhaul network from the network entity. The radio admission control may be based on the congestion level metric. [0015] According to certain other embodiments, a computer program product may encode instructions for performing a process. The process may include transmitting from a network node to a network entity in a self-backhaul network a congestion level metric. The process may also include receiving at the network node a result of radio admission control in the self-backhaul network from the network entity. The radio admission control may be based on the congestion level metric.

[0016] An apparatus, in certain embodiments, may include circuitry for transmitting to a network entity in a self-backhaul network a congestion level metric. The apparatus may also include circuitry for receiving a result of radio admission control in the self-backhaul network from the network entity. The radio admission control may be based on the congestion level metric.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] For proper understanding of the invention, reference should be made to tiie accompanying drawings, wherein:

[0018] Figure 1 illustrates an example of a system according to certain embodiments.

[0019] Figure 2 illustrates an example of a system according to certain embodiments.

[0020] Figure 3 illustrates an example of a signal flow diagram according to certain embodiments.

[0021] Figure 4 illustrates an example of a signal flow diagram according to certain embodiments.

[0022] Figure 5 illustrates an example of a flow diagram according to certain embodiments.

[0023] Figure 6 illustrates an example of a flow diagram according to certain embodiments.

[0024] Figure 7 illustrates an example of a system according to certain embodiments. DETAILED DESCRIPTION

[0025] Radio admission control may be concerned with the admission of a new UE or bearer primarily based on available radio resources, combined with radio conditions of the various UEs and their quality of service (QoS) requirements. Traditionally, CAC decisions do not consider backhaul resources, which are preprovisioned or pre -configured at installation, and the backhaul resources may remain static because the resources are typically wired or microwaved connections. Certain embodiments, however, involve dynamic self-backhauling in which resources relating the backhaul change over time. As shown in Figures 2-6, in some embodiment the RAC may account for the changing resources caused by dynamic self-backhauling.

[0026] The dynamic nature of self-backhauling may lead to a complex RAC. For example, a donor gNB may subtract or add independent UEs, thereby changing the amount of resources available for the sBH gNB to access the donor gNB. The Signal-to-Interference Ratio (SINR) may also change between the sBH gNB and the donor gNB. In another embodiments, a sBH node may be added to the network or handed over to a new donor node. All of the above changes to the network may lead to a dynamic self-backhauling with changing resource availability among the different entities and nodes located within the network.

[0027] The traffic generated by the one or more UEs may be streamed or attached through the sBH gNB, and may be tunneled such that multiple bearers supported by the sBH gNB appear as a single bearer to the donor gNB. The aggregation of the multiple bearers may lead to the so-called fat pipes. Based on the tunneled traffic from the sBH gNB, the donor gNB may be able to account for the pressure or volume traffic experienced by the backhaul tunnel when performing a RAC decision or calculation. The complexity of the sBH network may be further increased in a multi-hop scenario in which multiple donor gNBs may be chained together. In addition to the access side of the sBH gNB, the RAC decision may also take into account the dynamic and frequently changing bandwidth and resources over the self-backhaul link provided by the donor gNB. Certain embodiments discussed below may be able to address the complexities caused by dynamic self-backhauiing networks.

[0028] Figure 1 illustrates an example of a system according to certain embodiments. In particular, Figure 1 illustrates a system that includes donor node 1 13, sBH node 1 110, sBH node 2 11 1, and sBH node 3 112. As can be seen in Figure 1, each of the sBH nodes has a gNB part and a UE part In other words, the sBH nodes may perform functions of both a gNB and/or a UE. The system shown in Figure 1 also includes UE 1 121, UE 2 122, UE 3 123, UE 4 124, and/or UE 5 125. In certain embodiments, when performing the RAC for a UE or a bearer, the network entity may consider whether the network resources are sufficient to support the UE or bearer locally, and in the donor gNBs at each upstream node toward the core. Local resources may be those resources at the serving sBH node. For example, when UE 2 122 requests service to sBH Node 2 1 11, the available resources of sBH Node 3 112 and donor node 113 may be considered by the network entity while performing RAC. In certain embodiments, each sBH gNB along the chain may admit die UE, and each network resources at each of the network nodes along the chain may be accounted for when performing RAC.

[0029] To help perform RAC, certain embodiments may utilize a congestion level metric, which may also be referred to as a congestion indicator. The congestion level metric, for example, may estimate the maximum resources that can be allocated to a single bearer or flow by a given network node. The estimated maximum resources that can be allocated by a given network node may be referred to as a physical resource block (PRB) metric. A low PRB metric may indicate a high level of congestion. The congestion level metric, in certain embodiments, may be reported separately for each flow type in the sBH node. The flow type may be identified by a QoS flow identity (QFT), for example. In other words, each sBH node may have its own flow, and may have QoS requirements associated with such flow.

[0030] When the sBH node is a donor node or base station, certain embodiments may be modified to normalize the resources allocated to all downstream sBH UEs. In Figure 1 , sBH Node 3 112 may have a backhaul load that tunnels flows for UE 1 , UE 2, and UE 3. Donor gNB may, for example, normalize the number of PRBs allocated to sBH Node 3 1 12 by a factor of three. The number of PRBs allocated to die most active UE may also be considered. Certain embodiments may therefore be able to determine the most resources a given UE may be able to receive if it attaches to a given gNB. Based on the UE SINR, the likely throughput of the UE may be estimated, and a decision may be made as to whether admit or reject the admission of the UE or bearer.

[0031] In some embodiments, a centralized server, such as a Topology Manager (TM) server may perform the RAC. The TM server may maintain a mapping of the one or more network nodes, such as sBH nodes and/or donor nodes. The mapping may be used as part of die RAC. The TM server, in certain embodiments, may also receive a congestion level metric, such as a PRB metric, from one or more network nodes, such as sBH nodes. The RAC may be based on the congestion level metric. In certain other embodiments, a network entity other than the TM server may depend on the TM server to obtain the mapping of the sBH nodes and/or the donor nodes. The network entity may then use die obtained mapping to aggregate the congestion level metrics in order to perform RAC.

[0032] The RAC, in certain embodiments, may be invoked by a given network node, such as a gNB. The RAC at the networknode may be invoked upon receipt of anN2 request message from a network entity, such as an access and mobility function (AMF) as part of die service request procedure initiated by UE. The gNB may accept or reject the UE’s request for service based on the type of flow or QFI being requested. N2 may be an interface used to connect the AMF and the radio access network (RAN), including the network node.

[0033] Figure 2 illustrates an example of a system according to certain embodiments. In particular, Figure 2 illustrates an embodiments of a system that includes a UE 1 210 that attempts to attach to sBH node 1 220. The system also includes sBH node 2 230, donor node 240, AMF 250, and TM 260. TM 260 may maintain a mapping of the one or more network nodes that includes sBH node 1, sBH node 2, and donor node. In some embodiments, a centralized TM 260 may perform a RAC and assess whether the donor gNB may admit the UE at each of die hops. As shown in Figure 2, TM 260 may receive in a sBH network a congestion level metrics from sBH node 1 220, sBH node 2 230, and donor node 240. An M2 session request may be transmitted from AMF 250 to sBH node 1 220, and sBH node 1 220 may transmit an N2 session response to AMF 250. TM 260 may receive a session request from sBHl from AMF 250. The request received at TM 260 may be similar to the N2 session request received by sBH node 1 210. N2 may be an interface located between AMF and the radio access network (RAN), including network nodes located within the RAM, such as sBH nodes. Because TM 260 has knowledge of the network topology/mapping and the current PRB metric for one or more network nodes, die TM may use the metric to determine the impact of the addition of the UE at the gNBs at each of the hops.

[0034] A network entity, such as TM 260 shown in Figure 2, in certain embodiments may perform RAC in a sBH network. The RAC may be based on the congestion level metrics received at the network entity from the one or more network nodes. The RAC may also be based on the network topology/mapping. In other words, in performing the RAC the network entity may take into account the available resources of the network nodes in the sBH network. The TM 260, for example, may reject the UE service request when a highest number of PRBs that can be allocated to the UE for uplink is less than a pre-provisioned or dynamically determined value. This is because the uplink load of the cel l may be congested, and TM 260 may not want to grant a UE’s service request that will only further congest the uplink load. In certain embodiments, the PRB threshold used by TM 260 to determine whether to allow or reject the UE’s service request may be modified up or down depending on the signal quality.

[0035] In some embodiments, TM 260 may reject the UE service request when a highest number of PRBs that can be allocated to the UE for downlink is less than a pre-provisioned or dynamic determined value. The rejection may be because the downlink load of the cell may be congested. In yet another embodiment, TM 260 may not accept the UE’s service request because a guaranteed bit rate required to support a flow’s QFI cannot be supported for either uplink or downlink. The criteria used by TM 260 to perform RAC may also be used by a network node, such as a sBH node 1, to perform a local RAC.

[0036] Certain embodiments may help to facilitate RAC in a sBH network. For example, a centralized RAC may be performed, thereby relieving die necessity of tire RAC processing at each individual gNB. In some embodiments, the RAC in sBH may be performed based on the congestion level metric provided by the one or more network nodes. Taking into account the congestion level metric may allow the network entity, such as tire TM, to perform RAC in the sBH network.

[0037] Figure 3 illustrates an example of a signal flow diagram according to certain embodiments. In particular, Figure 3 illustrates the performance of a RAC in a sBH network to determine whether to accept a UE service request The sBH network shown in Figure 3 includes UE 301, sBH gNB 2 302, sBH UE 2 303, sBH gNB 1 304, sBH UE 1 305, donor gNB 306, a core network entity or AMF 307, and TM 308. sBH gNB 2 302 and sBH UE 2 303 may be part of a single sBH node, such as sBH node 1 220 shown in Figure 2, while sBH gNB 1 304 and sBH UE 1 305 may be part of another single sBH node, such as sBH node 2 230 shown in Figures 2. UE 301, donor gNB 306, AMF 307, and TM 308, shown in Figure 3 maybe similar to UE 210, donor node 240, AMF 250, and TM 260 shown in Figure 2.

[0038] In steps 310, 31 1, and 312, one or more network nodes, such as sBH gNB 2 302, sBH gNB 1 304, and donor node 306, may transmit to a network entity in the sBH network, such as TM 308, a congestion level metric. In other words, the network entity may receive in the sBH network a congestion level metric from foe one or more network nodes. The congestion level metrics, for example, may be a PRB metric. As shown in Figure 3, the one or more network nodes may include both a sBH node and a donor node. In step 313, an entity located in the network core, such as AMF 307, may receive a service request from UE 301 to activate a user plane connection. [0039] After AMF 307 receives the service request of UE 301 , AMF 307 may discover a service level agreement of the UE In step 314, network node sBH gNB 2 302 may receive a request from AMF 307. The request may be an N2 request to a target gNB, such as sBH gNB 2 302. The request may include QoS information for all flows in a protocol data unit (PDU) session with the UE requesting service. In other words, AMF 307 may obtain the QoS information for the PDU from the discovered service level agreement of the UE. For example, the QoS information associated with the flows may include a best effort flow and a guaranteed titrate (GBR) flow at 2 megabytes per second (mpbs). The network node may then perform a local RAC. The local RAC may be based on the QoS information received from AMF 307 in step 314. As part of the local RAC, the network node may determine which flows associated with tiie QoS information it may support The flows may be referred to as QoS flows. For example, the network node may allow admission of UE 301 based on the received QoS information for all the flows in the PDU session. In step 315, the network node may transmit a response, for example an N2 response, to AMF 307. The response may include a list of accepted QoS flows on the accepted PDU session. In certain other embodiments, not illustrated in Figure 3, the response transmitted from the network node to AMF 307 maybe a rejection of the UE service request, at which point the procedure may end.

[0040] In step 316, AMF 307 may transmit a request to TM 308. The request may be similar to an N2 request, but may be modified to reflect the accepted QoS flows by the network node, such as sBH gNB 2 302. In other words, step 316 illustrates TM 308 receiving a request from AMF 307, where the request includes QoS flows accepted by the network node. TM 308 may then perform RAC in the sBH network. The RAC may be based on the congestion level metric received from the one or more network nodes in steps 310, 311, and 312. In some embodiments, the RAC at TM 308 may be performed based on the accepted QoS flows. TM 308 may also account for the mapping of the one or more nodes, or the sBH network topology, as part of the performed RAC.

[0041] In step 317, TM 308 may transmit from the network entity a result of the performed radio admission control. The result may be an acceptance and/or a rejection of the UE service request, and may be included in a N2 response message transmitted from TM 308 to AMF 307. The transmitting of the result, for example in an N2 response message, may include information indicating congestion levels for at least one uplink or downlink network link in the sBH network. The network links may be radio links connecting the UE, the sBH nodes, and/or tire donor node shown in Figure 1. In one embodiment, the congestion level may indicate the most congested uplink or downlink radio link in the sBH network.

[0042] After receiving the result from TM 308, AMF 307 may forward or transmit the TM RAC result to the network node, such as sBH gNB 2 302, as shown in step 318. In other words, in step 318 die network node may receive a result of the RAC in die sBH network from the network entity. As discussed above, the RAC may be based on at least the congestion level metric transmitted from the network node in step 310. Upon being notified of the RAC result, in some embodiments the network node may determine whether or not to accept the result of the RAC. If die network node rejects the RAC result reached by TM 308, the network node may undergo an optional negotiation. The optional negotiation may allow the network node to modify die list of QoS flows based on the result of the RAC and/or the congestion levels indicated by TM 308. sBH gNB2 may therefore modify the accepted list of QoS using the received congestion information or level, and resubmit the modified list of accepted QoS to AMF 307. Steps 315 to 318 may then be repeated by the network until the network node accepts the RAC result

[0043] Once the network node allows admission of the UE service request based on die receive RAC, the network node, such as sBH gNB 2 302, may transmit an Xn backhaul notification to another network node, such as sBH gNB 1 304 via sBH UE 2 303, as shown in step 319. The backhaul notification may be transmitted using an Xn interface, which may be used to connect the sBH nodes. In certain embodiments, the backhaul notification may include the QoS information based on the accepted QoS flows and/or the received congestion level information. In step 320, the Xn backhaul notification may be forwarded or transmitted from sBH gNB 1 304 to donor node 306, via a sBH UE l 305. In steps 321 and 322, an Xn acknowledgement may be transmitted from donor gNB 306 to sBH gNB 2 302, via sBH UE 1 305, sBH gNB 1 304, and sBH UE 2 303. The Xn backhaul notification may help to inform all of the sBH nodes in die network about the added UE, and/or the change in network resource usage associated with the added UE.

[0044] As shown in Figure 3, each of the one or more network nodes may be updated with the required QoS information to account for the UE attaching anywhere within the path of its sBH network via Xn signaling. The QoS information, in certain embodiments, may be used to normalize the PRB metric reports. Since the PRB metric reports may represent the resources obtained by tire most active UE, die network entity, in certain embodiments, may not be able to simply view die resources used by die fat pipe for the backhaul link as a single UE. The QoS information may therefore inform the network entity that, for example, resources supporting four UEs are being carried in the fat pipe. Resource usage for the fat pipe may then be normalized to approximate resources used by a single UE supported by the pipe. In other words, in the above embodiment the fat pipe resources may be divided by four, which represents the number of UEs whose resources are supported by the fat pipe. In some embodiments, the scheduler at the network entity may be designed to share the resources in a proportional, fair shared manner. In the above example, if one UE is directly connected to the network entity, die one UE may get 1/5 of resources, for example PRBs, while the fat pipe may get 4/5 of the resources.

[0045] In the embodiments illustrated in Figure 3, the network entity may perform RAC after the originally target network node received the N2 request. The example embodiment may be meant to allow the network node to determine which QoS flows the network node may support before asking the network entity whether the sBH network may support the QoS flow. In certain embodiments, however, it may be feasible to perform RAC at the network entity before the network node, such as target gNB, receives the N2 request from AMF 307.

[0046] Figure 4 illustrates an example of a signal flow diagram according to certain embodiments. In particular, Figure 4 il lustrates an example of a sBH in which the RAC at the network entity occurs before any local RAC at the network node is performed. The sBH network shown in Figure 4 includes UE 401, sBH gNB 2 402, sBH UE 2403, sBH gNB 1 404, sBH UE 1 405, donor gNB 406, a core network entity or AMF 407, and TM 408. UE 401, sBH gNB 2 402, sBH UE 2403, sBH gNB 1 404, sBH UE 1 405, donor gNB 406, AMF 407, and TM 408, as shown in Figure 4 may be similar to UE 301 , sBH gNB 2302, sBH UE 2 303, sBH gNB 1 304, sBH UE 1 305, donor gNB 306, a core network entity or AMF 307, and TM 308, as shown in Figure 3.

[0047] In steps410, 411, and 412, one or more network nodes, such as sBH gNB 2 402, sBH gNB 1 404, and donor node 406, may transmit to a network entity in the sBH network, for example TM 408, a congestion level metric. The congestion level metric, for example, may be a PRB metric. In other words, the network entity may receive a congestion level metric from the one or more network nodes. As shown in Figure 4, the one or more network nodes may include both a sBH node and a donor node. In step 413, a network entity located in the network core, such as AMF 407, may receive a service request from UE 401 to activate a user plane connection. In step 414, AMF 407 may transmit a request to TM 408. The request may be similar to an N2 request, but may include information for all QoS flows in the PDU session. TM 408 may then perform RAC in the sBH network. The RAC may be based on the congestion level metric received from the one or more network nodes in steps 410, 411, and 412. In some embodiments, the RAC at TM 408 may also be performed based on the information associated with QoS flows, as received in step 414. In step 415, the network entity may transmit a result of the performed RAC. The result may be an acceptance and/or a rejection of the UE service request, and may be included in a N2 response message transmitted from TM 408 to AMF 407.

[0048] After receiving the result from TM 408, AMF 407 may forward or transmit the TM RAC result to the network node, such as sBH gNB 2 402, as shown in step 416. The RAC result may be included as part of the request transmitted to the network node. The request may also include information associated with the QoS flows. In certain embodiments, the request may be an N2 request message received by sBH gNB 2 402. In other words, in step 416 the network node may receive a result of the RAC in the sBH network from the network entity before a local RAC is performed. After receiving die RAC result, die network node may accept or reject the result. In addition, in certain embodiments the network node may perform a local RAC. The local RAC may be based on the information associated with the QoS flows received from AMF 407. In some embodiments, the local RAC may be performed by sBH gNB 2 402 only when the RAC result was accepted.

[0049] In certain embodiments, in step 417 the network node may transmit a response, such as an N2 response, to AMF 407. The response may include an indication of die local RAC performed by sBH gNB 2 402, and/or an indication that the network node accepted the result of the RAC performed by TM 408. In addition, the response may include a list of accepted QoS flows for the PDU session. If die result of the RAC performed by TM 408 was accepted, and one or more of the QoS flows are supported, the network node may proceed to perform steps 319-322 as shown in Figure 3. In step 418, the network node may transmit a response, such as an N2 response, to AMF 407 indicating that the network node rejected the result of the RAC performed by TM 408. Upon rejecting the RAC result, sBH gNB 2 402 may modify the list of QoS flows using the congestion level or congestion information received from TM 408. The response transmitted by the network node may include both the rejection and the modified list of QoS flows.

[00501 Upon transmission of the response in step 418, the network may enter a negotiation procedure in steps 419-421. In step 419, AMF 407 may transmit an sBH request to TM 408. The request may be an N2 request, and the request may be modified to reflect the QoS flows accepted by sBH gNB 2402. The network entity may then perform a RAC in the sBH network based on the congestion level metric. The RAC may also be performed by the network topology or the mapping of the one or more network nodes. In step 420, the network entity, such as TM 408, may transmit a result of the RAC. The result may include an indication of whether the UE service request was accepted or rejected. The result may be included as part of an N2 response, and may also include an indication of the congestion level for at least one uplink or downlink. For example, the congestion level may include an indication of die most congested radio link in tiie network.

[0051] In step 421 , network node sBH gNB 2 402 may receive the result of the RAC performed by TM 408. If the result is accepted, the network node may proceed to perform steps 319-322 as shown in Figure 3. If the result is rejected, steps 418-421 may be repeated. In certain embodiments all of the impacted nodes may be notified when existing PDU sessions are modified, new sessions are added, and/or a UE may be detached or handed over. The notification may be in tiie form of an Xn backhaul notification transmitted between one or more network nodes.

[0052] Figure 5 illustrates an example of a flow diagram according to certain embodiments. In particular, Figure 5 illustrates an example of a method performed by a network entity, such the TM shown in Figured 2-4. In step 510, tiie network entity may maintain a mapping of the one or more network nodes, and the mapping may be used as part of the radio admission control. The mapping may be similar to an sBH network topology. In step 520, the network entity in a sBH network may receive a congestion level metric from one or more network nodes. The one or more network nodes may include at least one of a sBH node or a donor node. The congestion level metric may indicate maximum resources allocated to a single bearer at the one or more network nodes. The congestion level metric may be used by the network entity to determine whether or not to accept the UE’s service request.

[0053] In step 530, the network entity may receive a request The request may include Qos flows accepted by the one or more network nodes. The request, in some embodiments, maybe received by the AMF. In step 540, the network entity may perform a RAC in the sBH network. The RAC may be based on the congestion level metric. In other embodiments, the RAC may be performed based on the accepted QoS flows, which may be received in step 530 as part of the request In step 550, the network entity may transmit a result of the performed RAC. The result of the RAC may include a rejection or an acceptance of a UE service request In certain embodiments, the network entity may reject the UE service request as part of the RAC when the congestion level metric is less than a pre-provisioned or dynamically determined value. The pre-provisioned and/or the dynamically determined value may be set by an upper layer network entity, or the network operator.

[0054] Figure 6 illustrates an example of a flow diagram according to certain embodiments. In particular, Figure 6 illustrates an example of a method performed by a network node, such as the sBH gNB 2 shown in Figures 2-4. The network node shown in Figure 6 may communicate with the network entity illustrated in Figure 5. In step 610, the network node may transmit to the network entity in a sBH network a congestion level metric. In step 620, the network node may receive a request, where the request includes QoS information for all flows in the PDU session. In step 630, the network node may perform a local RAC, where the local RAC includes accepting a PDU session. In certain embodiments, the local RAC may be performed before the RAC performed at the network entity, and the list of accepted quality of service flows may be transmitted to the network entity.

[0055] In step 640, the network node may determine a list of accepted QoS flows on the accepted PDU session. In some embodiments, the network node may modify the list of accepted QoS flows based on the result of the RAC performed at the network entity. In step 650, the network node may transmit a response based on the performed local RAC, where the response includes the list of accepted QoS flows. In some embodiments, the response may be transmitted from the network node to an AMF. In step 660, the network node may receive a result of RAC in the sBH network from the network entity. The RAC may be based on the congestion level metric. The congestion level metric may indicate maximum resources allocated to a single bearer at the network node. The result received from the network entity may include the congestion level metric of the another network node. In certain embodiments, the performing of the local RAC at the network node may account for the congestion level metric of the another network node.

[0056] In step 670, the network node may determine whether to accept or reject the result of the RAC received from the network entity. In certain embodiments, the local RAC at the network node may be performed after the RAC at the network entity. In step 680, the network node may allow admission of a UE based on the received result of the RAC. In some other embodiments, the network node may allow admission of a UE based on the received QoS information for all of the flows in the PDU session, as received in step 620. In step 690, the network node may transmit a backhaul notification based on the result of the RAC to another network node. The backhaul notification may include QoS information.

[0057] Figure 7 illustrates a system according to certain embodiments. It should be understood that each table, signal, or block in Figures 1-6 may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry. In one embodiment, a system may include several devices, such as, for example, network entity 720 or UE 710. The system may include more than one UE 710 and more than one network entity 720. Network entity 220 may be a base station, an access point, an access node, an enhanced NodeB (eNB), a 5G or New Radio NodeB (gNB), a server, a host, or any other network entity that may communicate with the UE. Network entity 720 may also be an sBH node that may include an sBH gNB part and an sBH UE part. In some other embodiments, network entity 720 may be the AMF shown in Figures 2-4.

[0058] Each of these devices may include at least one processor or control unit or module, respectively indicated as 711 and 721. At least one memory may be provided in each device, and indicated as 712 and 722, respectively. The memory may include computer program instructions or computer code contained therein. One or more transceiver 713 and 723 may be provided, and each device may also include an antenna, respectively illustrated as 714 and 724. Although only one antenna each is shown, many antennas and multiple antenna elements may be provided to each of the devices. Other configurations of these devices, for example, may be provided. For example, network entity 720 and UE 710 may be additionally configured for wired communication, in addition to wireless communication, and in such a case antennas 714 and 724 may illustrate any form of communication hardware, without being limited to merely an antenna.

[0059] Transceivers 713 and 723 may each, independently, be a transmitter, a receiver, or both a transmitter and a receiver, or a unit or device that may be configured both for transmission and reception. The transmitter and/or receiver (as far as radio parts are concerned) may also be implemented as a remote radio head which is not located in the device itself, but in a mast, for example. The operations and functionalities may be performed in different entities, such as nodes, hosts or servers, in a flexible manner. In other words, division of labor may vary case by case. One possible use is to make a network entity deliver local content. One or more functionalities may also be implemented as virtual application^) in software that can run on a server.

[0060] A user device or UE 710 may be a mobile station (MS), such as a mobile phone or smart phone or multimedia device, an loT cellular device, a computer, such as a tablet, provided with wireless communication capabilities, personal data or digital assistant (PDA) provided with wireless communication capabilities, portable media player, digital camera, pocket video camera, navigation unit provided with wireless communication capabilities or any combinations thereof. In other embodiments, the user equipment may be replaced with a machine communication device that does not require any human interaction, such as a sensor, meter, or robot.

[0061] ¾ some embodiments, an apparatus, such as a user equipment or a network entity, may include means for carrying out embodiments described above in relation to Figures 1-6. In certain embodiments, at least one memory including computer program code can be configured to, with the at least one processor, cause the apparatus at least to perform any of the processes described herein.

[0062] Processors 71 1 and 721 maybe embodied by any computational or data processing device, such as a central processing unit (CPU), digital signal processor (DSP), application specific integrated circuit (ASIC), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), digitally enhanced circuits, or comparable device or a combination thereof. The processors may be implemented as a single controller, or a plurality of controllers or processors.

100631 For firmware or software, the implementation may include modules or unit of at least one chip set (for example, procedures, functions, and so on). Memories 712 and 722 may independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used. The memories may be combined on a single integrated circuit as the processor, or may be separate therefrom. Furthermore, the computer program instructions may be stored in the memory and which may be processed by the processors can be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language. The memory or data storage entity is typically internal but may also be external or a combination thereof, such as in the case when additional memory capacity is obtained from a service provider. The memory may be fixed or removable.

[0064] The memory and the computer program instructions may be configured, with the processor for the particular device, to cause a hardware apparatus such to network entity 720 or UE 710, to perform any of the processes described above (see, for example, Figures 1-6). Therefore, in certain embodiments, a non-transitory computer-readable medium may be encoded with computer instructions or one or more computer program (such as added or updated software routine, applet or macro) that, when executed in hardware, may perform a process such as one of the processes described herein. Computer programs may be coded by a programming language, which may be a high-level programming language, such as objective-C, C, C++, C#, Java, etc., or a low-level programming language, such as a machine language, or assembler. Alternatively, certain embodiments may be performed entirely in hardware.

[0065] In certain embodiments, an apparatus may include circuitry configured to perform any of the processes or functions illustrated in Figures 1-6. Circuitry, in one example, may be hardware-only circuit implementations, such as analog and/or digital circuitry. Circuitry, in another example, may be a combination of hardware circuits and software, such as a combination of analog and/or digital hardware circuits) with software or firmware, and/or any portions of hardware processor(s) with software (including digital signal processors)), software, and at least one memory that work together to cause an apparatus to perform various processes or functions. In yet another example, circuitry may be hardware circuit(s) and or processors), such as a microprocessors) or a portion of a microprocessors), that include software, such as firmware for operation. Software in circuitry may not be present when it is not needed for the operation of the hardware.

[0066] Furthermore, although Figure 7 illustrates a system including a network entity 720 and UE 710, certain embodiments may be applicable to other configurations, and configurations involving additional elements, as illustrated and discussed herein. For example, multiple user equipment devices and multiple base stations may be present, or other nodes providing similar functionality, such as nodes that combine the functionality of a user equipment and a base station, such as a relay node. The UE 710 may likewise be provided with a variety of configurations for communication other than communicating with network entity 620. For example, the UE 710 may be configured for device-to-device, machine-to-machine, or vehicle-to-vehicle communication.

[0067] The above embodiments are directed to computer-related technology, and provide for significant improvements to the functioning of a network and/or to the functioning of the network entities within the network, or the user equipment communicating with the netwoik. For example, certain embodiments help self-backhauling technology to be deployed in mmWave spectrum. In particular, the above embodiments may help to facilitate efficient RAC that may take into account a congestion level metric received from each node in the sBH network or path. The RAC may also be performed by a centralized network entity, which may help to relieve the need for individual network nodes in a path to perform RAC. This helps to reduce the amount of resources used by the network as part of RAC, while also reducing the time it takes to make a decision on the RAC.

[0068] The features, structures, or characteristics of certain embodiments described throughout this specification maybe combined in any suitable manner in one or more embodiments. For example, the usage of the phrases“certain embodiments,”“some embodiments,”“other embodiments,” or other similar language, throughout this specification refers to the feet that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearance of the phrases“in certain embodiments,”“in some embodiments,”“in other embodiments,” or other similar language, throughout this specification does not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0069] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. Although the above embodiments refer to 5G or NR technology, the above embodiments may apply to any other 3GPP technology

Claims

WE CLAIM:

1. A method comprising:

receiving at a network entity in a self-backhaul network a congestion level metric from one or more network nodes;

performing at the network entity radio admission control in the self- backhaul network, wherein the radio admission control is based on the congestion level metric; and

transmitting from the network entity a result of the performed radio admission control.

2. The method according to claim 1 , wherein the result of the performed radio admission control comprises information indicating congestion levels for at least one uplink or downlink in the self-backhaul network.

3. The method according to claim 2 or 3, wherein the one or more network nodes comprises at least one of a self-backhauling node or a donor node.

4. The method according to any of claims 1-3, further comprising: receiving a request at the network entity, wherein the request comprises quality of service flows accepted by the one or more network nodes, and wherein the radio admission control is performed based on the accepted quality of service flows.

5. The method according to any of claims 1-4, wherein the congestion level metric indicates maximum resources allocated to a single bearer at the one or more network nodes.

6. The method according to any of claims 1-5, further comprising: maintaining at the network entity a mapping of the one or more network nodes, wherein the mapping is used as part of the radio admission control.

7. The method according to any of claims 1 -6, wherein the result of the radio admission control comprises a rejection or an acceptance of a user equipment service request.

8. The method according to claim 7, further comprising:

rejecting the user equipment service request as part of the radio admission control when the congestion level metric is less than a preprovisioned or dynamically determined value.

9. A method comprising:

transmitting from a network node to a network entity in a self-backhaul network a congestion level metric; and

receiving at the network node a result of radio admission control in the self-backhaul network from the network entity, wherein the radio admission control is based on the congestion level metric.

10. The method according to claim 9, further comprising:

transmitting a backhaul notification based on the result of the radio admission control to another network node, wherein the backhaul notification comprises quality of service information.

1 1. The method according to claim 9 or 10, further comprising:

performing a local radio admission control at the network node, wherein the local radio admission control comprises accepting a protocol data unit session;

determining a list of accepted quality of service flows on the accepted protocol data unit session; and

transmitting a response based on the performed local radio admission control, wherein the response includes the list of accepted quality of service flows.

12. The method according to claim 11, wherein the local radio admission control at the network node is performed before the radio admission control at the network entity, and wherein the list of accepted quality of service flows is transmitted to the network entity.

13. The method according to any of claims 9-12, further comprising: receiving a request at the network node, wherein the request comprises quality of service information for all flows in the protocol data unit session, and wherein the determining of the list of accepted quality of service flows is based on the received request

14. The method according to claim 13, further comprising:

modifying at the network node the list of accepted quality of service flows based on the result of the radio admission control at the network entity.

15. The method according to any of claims 9-14, wherein the congestion level metric indicates maximum resources allocated to a single bearer at the netwoik node.

16. The method according to any of claims 9-15, further comprising: determining whether to accept or reject the result of the radio admission control received from the network entity, wherein the local radio admission control at the network node is performed after the radio admission control at the netwoik entity.

17. The method according to any of claims 9-16, further comprising: allowing admission of a user equipment based on the received result of the radio admission control.

18. The method according to any of claims 9-17, further comprising: allowing admission of a user equipment based on the received quality of service information for all of the flows in the protocol data unit session.

19. The method according to any of claims 9-18, wherein the result received from the network entity comprises the congestion level metric of the another network node, wherein the performing of the local radio admission control at the network node accounts for the congestion level metric of the another network node.

20. An apparatus comprising:

at least one memory comprising computer program code;

at least one processor;

wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to: receive in a self-backhaul network a congestion level metric from one or more network nodes;

perform radio admission control in the self-backhaul network, wherein die radio admission control is based on the congestion level metric; and

transmit a result of the performed radio admission control.

21. An apparatus comprising:

at least one memory comprising computer program code;

at least one processor;

wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to: transmit to a network entity in a self-backhaul network a congestion level metric; and

receive a result of radio admission control in the self-backhaul network from the network entity, wherein the radio admission control is based on the congestion level metric.