Patent Description:
Small cell radio access nodes (also referred to simply as small cells) are small base stations or eNodeBs (eNBs) which can be used in mobile communication networks of any generation, e.g. <NUM>, <NUM> or <NUM>. They are "small" compared to "macrocells" (which are served by a high power cellular base station), partly because they tend to have a shorter range (from <NUM> meters within urban and in-building locations to <NUM> for a rural location) and partly because they typically handle fewer concurrent calls or sessions. The term "small cell" may encompass, but is not limited to, "femtocells", "picocells", and "microcells". Benefits of small cells arise from the fact that they enable better use of available spectrum by re-using the same frequencies many times within a geographical area. In addition, they may allow the area served by a macrocell to be increased.

Small cells were first introduced in <NUM>, are becoming increasingly important in <NUM>, and may become a critical component of <NUM>. One of the challenges faced by network operators when deploying small cells is how best to form the backhaul in order to connect small cells to the core network in a timely and cost-effective way.

<CIT> describes a wireless local area network (WLAN) point-to-point communications link between an evolved universal terrestrial radio access network node B (eNB) and a user equipment device (or simply UE) which is identified by UE/eNB media access control (MAC) identifiers on a per UE or per data radio bearer (DRB) basis for offloading cellular data from a long term evolution (LTE) link to the WLAN point-to-point communications link. A wireless local area network tunneling protocol (WLTP) includes packet formats and network protocol stack arrangements to support functions facilitated by the WLAN point-to-point communications link, such as, for example, identification of control and data traffic messages, DRB identification for WLTP packets, quality of service (QoS) delay and packet loss measurement, support of bearer splitting, and support of a general framework for offloading cellular traffic at different depths of the 3rd Generation Partnership Project (3GPP) network protocol stack.

<CIT> describes apparatuses and methods that may allow a wireless device to process an Ethertype data packet encapsulated in a frame based on whether the frame contains an Ethertype Packet Discrimination (EPD) indicator. The wireless device may receive the frame from another wireless device over a wireless network, and may detect a presence of the EPD indicator in the received frame. Then, the wireless device may identify a protocol type of the Ethertype data packet according to an EPD operation based on the presence of the EPD indicator, or may identify the protocol type of the Ethertype data packet according to an LPD operation based on an absence of the EPD indicator.

LTE WLAN aggregation [Industry Perspectives], Pavan Nuggehalli, describes Long Term Evolution-WLAN aggregation (LWA), a Release <NUM> feature to harness the power of Wi-Fi to improve cellular performance, and a design of a prototype built for deployment of LWA.

For better understanding of the present application, reference will now be made, by way of example only, to the accompanying drawings in which:.

Wireless data network operators have recently started making use of a concept known as user equipment relay (UE Relay or Relay UE) in order to provide the backhaul connection between radio access nodes (RANs) and the core network. <FIG> illustrates an example of a mobile telecommunications radio access network <NUM> which includes a UE relay <NUM> and in the context of which various methods and apparatuses described herein may be implemented.

As illustrated in <FIG>, UE relay backhaul comprises using a user equipment (UE) <NUM> that is generally co-located with a radio access node (RAN) <NUM>, which may typically be a small cell RAN (or, more simply, a "small cell"), to provide a wireless backhaul connection to a network <NUM>. In the example of <FIG>, the UE relay <NUM> is directly connected to the small cell RAN <NUM>, via a local network connection <NUM> (wired or wireless) which may be, for instance, an Ethernet connection. The UE relay <NUM> is wirelessly connected with a macrocell <NUM> (or donor eNB) in a standard way, with the wireless connection with the macrocell <NUM> forming part of the backhaul for the small cell RAN <NUM>. In some implementations, the small cell RAN <NUM> and the UE relay <NUM> may be mounted on the same structural element, for instance on the same street-light pole. In some implementations, the small cell RAN <NUM> and the UE relay <NUM> may be provided in a common enclosure (or housing) while, in other implementations, they may be provided in separate enclosures. Put another way, the LAN connection may be internal or may be external. As will be discussed again later, the small cell RAN <NUM> and the UE relay <NUM> may utilise the same IP address.

The network <NUM> comprises one or more macrocells <NUM> which are connected to a packet data network gateway (PGW) relay <NUM> via a network connection <NUM>. The PGW relay <NUM> may be connected to the network functionality <NUM> via another network connection <NUM>. As illustrated in <FIG>, the network functionality <NUM> may include, for instance, mobility management entity (MME) functionality <NUM>-<NUM>, element management system (EMS) functionality <NUM>-<NUM> and other gateway entities <NUM>-<NUM> which may include PGWs and/or serving gateways (SGWs).

The example shown is <FIG> is a "Network-In-Network" implementation with double tunnelling. More specifically, the system includes two "core networks". The first core network which includes the PGW relay <NUM> is the core network for the macrocell <NUM> serving the UE relay <NUM>. The second "core network", which includes the PGW <NUM>-<NUM>/EMS <NUM>-<NUM>/MME <NUM>-<NUM>, is the core network for the RAN <NUM> serving the UEs <NUM>. Traffic for the second core network (including PGW <NUM>-<NUM>/EMS <NUM>-<NUM>/MME <NUM>-<NUM>) is encapsulated inside the GTP tunnel terminating at the first core network (which includes the PGW relay <NUM>).

In order to provide the backhaul to the network <NUM> and the and the PGW <NUM>-<NUM>/EMS <NUM>-<NUM>/MME <NUM>-<NUM>, a GPRS tunnelling protocol (GTP) tunnel is set up between the UE relay <NUM> and the PGW relay <NUM>. Traffic which passes through the GTP tunnel includes data derived from, and intended for, one or more UEs <NUM> that are being served by the small RAN <NUM>. Such data may be referred to as user plane (U-plane) traffic. Management plane (M-plane) and control plane (C-plane) traffic for the small cell RAN <NUM> may also be transported via the GTP tunnel. All small cell traffic (regardless of the type of the traffic) may be carried in the GTP tunnel as bearer traffic of the UE relay <NUM>.

In the downlink direction, the UE relay <NUM> encapsulates the traffic and then sends it via the GTP tunnel to the PGW relay <NUM>. Upon arrival at the PGW Relay <NUM>, the traffic is GTP decapsulated and is then forwarded to the network functionalities <NUM>, as appropriate.

In the uplink direction, since the UE relay <NUM> and the small cell RAN <NUM> have the same IP address, the network <NUM> handles the traffic as if it is destined to the UE relay <NUM>. As such, the network sends it to the PGW relay <NUM>, since the PGW relay <NUM> represents the UE relay <NUM> in the network <NUM>. The PGW relay <NUM> encapsulates the data arriving from the network <NUM> and sends it to the UE relay <NUM>, via the GTP tunnel. When this traffic arrives at the UE relay <NUM>, the UE relay <NUM> decapsulates the traffic and forwards it to the small cell RAN <NUM>.

In current small cell network implementations, the small cell RAN <NUM> and the UE relay <NUM> are unable to communicate with one another in a direct fashion. This is at least in part because they have the same IP address. This inability to communicate, although not critical (in that current networks which include small cells with UE relays are able to function sufficiently well to provide service to UEs <NUM> served by the small cell), is sub-optimal.

The following describes methods and apparatuses for enabling communication between small cell RANs <NUM> and UE relays <NUM> over a local area network connection <NUM>, thereby to improve the performance of mobile data networks such as that described above with reference to <FIG>.

In the various examples described below, one or both of the two entities participating in the communication (that is the small cell RAN <NUM> and the UE relay <NUM>) are configured to generate a message for communication over the LAN connection <NUM> between the two entities. The message includes control information for eliciting, prompting or otherwise causing performance of a responsive operation by the one of the small cell RAN <NUM> and the UE relay <NUM> which receives the message (also referred to as "the receiving entity). In addition, the message includes an identifier for indicating to the receiving entity that the message includes the control information. After generation, the message is caused to be transmitted (by the "transmitting entity") over the LAN connection <NUM> between the two entities.

The messages exchanged between the small cell RAN <NUM> and the UE relay <NUM>, which include the control information, may be referred to as a "Relay Control Protocol over LAN" (RCPoL) messages. The identifier may therefore serve to indicate that a received message is an RCPoL message. As such, the receiving entity may respond to detection of the presence of the identifier in a received message, by extracting the control information from the message and responding accordingly.

Put another way, one or both of the entities (that is the small cell RAN <NUM> and the UE relay <NUM>) are configured to determine that a message received over the LAN connection <NUM> includes the identifier, the identifier indicating that the message includes control information for prompting performance of a responsive operation by the receiving entity. The receiving entity is further configured to respond to determining that the message includes the identifier by causing performance of the responsive operation based on the control information.

The control information included in the message may serve a variety of different purposes. For instance, the control information may serve to request a modification of a behaviour of the receiving entity. In such examples, the responsive operation may be the receiving entity modifying its behaviour. In other examples, the control information may be for notifying the receiving entity as to a status of the transmitting entity, with the receiving entity performing a responsive operation in dependence on the nature of the notification. In yet other examples, the control information may be for soliciting a status indication from the receiving entity. The responsive action may, in this example, be the provision of the status indication by the receiving entity to the transmitting entity.

As discussed above, the LAN connection <NUM> is a wired connection, which may be an Ethernet connection. In implementations in which the LAN connection is an Ethernet connection, the message may include an Ethernet frame. The identifier may be included in an EtherType field of the Ethernet frame.

The message may include a frame which has a format similar to that of the frame <NUM> illustrated in <FIG>. In the example of <FIG>, the frame <NUM> includes a first field <NUM> which indicates the MAC address of the destination of the frame. As such, when the frame <NUM> is transmitted across the LAN connection <NUM> from the UE relay <NUM> to the small cell RAN <NUM>, the first field indicates MAC address of the small cell RAN and vice versa. In a second field <NUM>, the frame <NUM> indicates the MAC address of the source of the frame <NUM>. As will be appreciated, the MAC addresses of the two entities <NUM>, <NUM> are different and so can be used for addressing the message.

The identifier for indicating presence of the control information may be included in a third field <NUM> which, in an Ethernet implementation, may be referred to as the Ethertype field. The payload of the frame <NUM> may be included in a fourth field <NUM>. The control information which is carried by the frame <NUM> may be included in the payload field. In a fifth field <NUM>, the frame <NUM> may include error check data (e.g. CRC data). In some implementations, the frame <NUM> may additionally include an <NUM>. 1Q tag field <NUM>.

In Ethernet implementations, a new Ethertype identifier (ID), which is present in the Ethertype field <NUM>, may be defined which allows the exchange of messages between the small cell RAN <NUM> and the UE relay <NUM> at layer <NUM>. Put another way, the new Ethertype ID may serve indicate that a received message is a RCPoL message.

The following is a discussion of four specific examples of control information which may be transmitted using RCPoL messages. However, as will be appreciated, the methods and apparatuses described herein are not limited to these specific examples.

This type of RCPoL message may be transmitted from the small cell RAN <NUM> to the UE relay <NUM>. A relay reset message may include control information for prompting performance by the UE relay <NUM> of a reset operation. As such, in response to receiving a message of this type from the small cell RAN <NUM>, the UE relay <NUM> may perform a reset operation, in which it resets itself.

A relay reset message may be generated and transmitted by the small cell RAN <NUM> in response to a recognition by the small cell RAN <NUM> that the UE relay <NUM> backhaul is not functioning correctly. In response, the UE relay <NUM> resets itself in order to recover from the error condition.

This type of RCPoL message may be transmitted from the small cell RAN <NUM> to the UE relay <NUM>. A relay bearer modification message may include control information for prompting performance by the UE relay <NUM> of a modification of bandwidth allocated to a dedicated bearer. The dedicated bearers, which may be configured with a guaranteed bit rate (GBR) and/or a maximum bit rate (MBR) in either of the uplink or downlink directions, may be used by the UE relay <NUM> to transport the small cell traffic types that require a higher quality of service (QoS) than other traffic types transported in the default bearer.

The small cell RAN <NUM> may be configured to generate and transmit a relay bearer modification message in response to a request from a UE <NUM>, which is being served by the small cell RAN <NUM>, to establish or tear down a high priority communication session, e.g. a call session, for instance using VoIP (which in an LTE network may be referred to as VoLTE). Such high priority communication sessions require higher bandwidth and QoS.

The UE relay <NUM> may be configured to respond to receiving a relay bearer modification message by increasing or decreasing, as required, a pre-established dedicated bearer bandwidth which is reserved for high priority communication sessions (e.g. VoLTE etc.).

This type of RCPoL message may be transmitted from the UE relay <NUM> to the small cell RAN <NUM>. A congestion notification message may include control information, which notifies the receiving entity (in this case the small cell RAN <NUM>), that the UE relay <NUM> is congested. As such, the UE relay <NUM> may be configured to generate and transmit a congestion notification message in response to determining that it is congested.

The small cell RAN <NUM> may be configured to respond to the notification that the UE relay <NUM> is congested by triggering a congestion control mechanism. Such a congestion control mechanism may include, for instance, not accepting (or denying) requests for new communication sessions from UEs <NUM> which are currently not being served and/or reducing the bandwidth allocated to (or throttling) low priority communication sessions.

The congestion notification message may alternatively include control information, which notifies the receiving entity (in this case the small cell RAN <NUM>), that the UE relay <NUM> is no longer congested. The small cell RAN <NUM> may be configured to respond to the notification that the UE relay <NUM> is no longer congested by terminating/stopping the congestion control mechanism.

This type of RCPoL message may be transmitted from the UE relay <NUM> to the small cell RAN <NUM>. A relay recovery message may include control information which notifies the small cell RAN <NUM> that the UE relay <NUM> has just re-attached to the macrocell after having been previously detached from the macrocell. Alternatively or additionally, the control information may notify the small cell RAN <NUM> that the UE relay <NUM> has just restored its PDN connection that is bridged to the small cell RAN after a PDN connection loss. As such, the UE relay <NUM> may be configured to generate and transmit a relay recovery message in response to re-attachment to the macrocell and/or to restoration of a PDN connection.

The small cell RAN <NUM> may be configured to respond to receipt of a relay recovery message by performing necessary responsive operations. For instance, in response to being notified that the PDN connection has been restored or that the UE relay <NUM> has just re-attached to the macrocell, the small cell RAN <NUM> may be configured to re-trigger performance of the Dynamic Host Configuration Protocol (DHCP) in order to obtain an IP address (since loss of PDN connection and detachment from the macrocell result in the PGW relay <NUM>, releasing the IP address previously allocated to the small cell RAN <NUM>).

As will be appreciated from the above description, the ability for the small cell RAN <NUM> and the UE relay <NUM> to communicate with one another allows the two devices to operate synchronously and in dependence on one another. As such, it allows the UE relay backhaul to evolve from a crude backhaul solution to a more finely tuned one. For instance, the communication (e.g. using bearer modification messages and/or congestion notification messages) may ensure high QoS requirements may be met. Also, communication between the two entities (e.g. using relay reset and/or relay recovery messages) may allow recovery of the backhaul without manual intervention. In general, the ability of the small cell RAN <NUM> to communicate with the UE relay <NUM> significantly improves the UE relay backhaul solution.

<FIG> are flow charts illustrating operations which may be performed by UE relays <NUM> and small cell RANs <NUM> when communicating with one another over a LAN connection <NUM>. More specifically, <FIG> includes operations which may be performed by a transmitting one of the two entities and <FIG> includes operations which may be performed by the receiving entity.

Referring first to <FIG>, in operation S3A-<NUM>, the transmitting one of the UE relay <NUM> and the small cell RAN <NUM> detects, or determines occurrence of, a particular event. Such events, in response to which the transmitting entity may generate and transmit a message over the LAN connection <NUM> to receiving entity, may include one or more of, for instance: a determination by the UE relay <NUM> that it has become congested or is no longer congested, a determination by the UE relay <NUM> that it has reattached to the macrocell, a determination by the UE relay <NUM> that it has restored its PDN connection, a determination by the small cell RAN <NUM> that the UE relay <NUM> is not functioning correctly, and a request, received at the small cell RAN <NUM> from one of the UEs <NUM> that it is currently serving, for the establishment or tearing down of a high priority communication session.

In operation S3A-<NUM>, the transmitting one of the UE relay <NUM> and the small cell RAN <NUM> generates the message. The message includes control information for prompting the receiving entity to perform a responsive operation. The nature of the control information and responsive operation may depend on the type of event detected. In addition to the control information, the message also includes the identifier which indicates the presence of the control information in the message. As discussed above, the identifier may be provided in an Ethertype field <NUM> of an Ethernet frame <NUM>. The control information may be included in the payload. The message may additionally include a field which includes address information, for instance, in the form of a MAC address, of the receiving entity.

After generating the message, the transmitting one of the UE relay <NUM> and the small cell RAN <NUM>, in operation S3A-<NUM>, causes transmission of the message across the LAN connection <NUM> to the receiving entity. As discussed above, in some examples, the LAN connection <NUM> is an Ethernet connection.

Referring now to <FIG>, in operation S3B-<NUM>, the receiving one of the UE relay <NUM> and the small cell RAN <NUM> receives the message via the LAN connection <NUM>.

In operation S3B-<NUM>, the receiving entity detects the presence of the identifier in the message, which indicates that the message includes control information for prompting a responsive action by the receiving entity. Detection of the identifier may be achieved by examining a relevant field of the message, for instance, the Ethertype field. Based on the presence of the identifier in the message, the receiving entity is able to determine that the message is a RCP0L message.

In response to detecting the presence of the identifier in the message, the receiving one of the UE relay <NUM> and the small cell RAN <NUM>, in operation S3B-<NUM>, reads the control information from the message. In operation S3B-<NUM>, the receiving one of the UE relay <NUM> and the small cell RAN <NUM> performs a responsive action, which is based on the control information read from the received message.

As discussed previously, the responsive action may include, for instance, the UE relay <NUM> resetting itself in response to the control information signifying a reset request or the UE relay <NUM> modifying an amount of bandwidth that is allocated to a dedicated bearer in response to the control information signifying a relay bearer modification request. Other examples of the responsive action include the small cell RAN <NUM> triggering a congestion control mechanism in response to the control information indicating that the UE relay <NUM> is congested, stopping a congestion control mechanism in response to the control information indicating that the UE relay <NUM> is no longer congested or the small cell RAN <NUM> taking responsive action (e.g. retriggering DHCP) when the control information indicates that the backhaul has recovered (e.g., the UE relay has reattached to the macrocell and/or the PDN connection has been restored).

As will be appreciated, these are only examples of the types of control information that may be sent and responsive actions that may be caused using RCPoL messages. Various other types of control information/responsive actions may be envisaged by the person skilled in the art.

<FIG> is a schematic illustration of an example configuration of a RAN <NUM> such as described with reference to <FIG>, which may make use of a UE relay backhaul.

The RAN <NUM>, which may be referred to a base station or access point (AP), may comprise a radio frequency antenna array <NUM> configured to receive and transmit radio frequency signals. Although the RAN <NUM> in <FIG> is shown as having an array <NUM> of four antennas, this is illustrative only and the number of antennas may vary.

The RAN <NUM> further comprises a radio frequency interface <NUM>, which is configured to interface the radio frequency signals received and transmitted by the antenna <NUM>. The radio frequency interface <NUM> may also be known as a transceiver. The RAN <NUM> also comprises a LAN physical interface <NUM> via which it can communicate with the UE relay <NUM> over the LAN connection <NUM>.

In addition, the RAN <NUM> comprises a control apparatus <NUM>. The RAN control apparatus <NUM> may be configured to process signals received from the radio frequency interface <NUM> and to control the radio frequency interface <NUM> to generate suitable RF signals to communicate information to the UEs <NUM> via a wireless communications link. The RAN control apparatus <NUM> may be configured to cause messages to be generated and transmitted to, and received from, the UE relay <NUM>, across the LAN connection <NUM>.

The control apparatus <NUM> may comprise processing apparatus <NUM> and memory <NUM>. Computer-readable code <NUM>-2A may be stored on the memory <NUM> and may, when executed by the processing apparatus <NUM>, cause the control apparatus <NUM> to perform any of the operations described with reference to <FIG> , as well as any other operations assigned to the RAN <NUM> and described with reference to <FIG> and <FIG>.

<FIG> is a schematic illustration of an example configuration of a UE relay <NUM> such as described with reference to <FIG>, which may be used to provide the backhaul for a radio access node (such as a small cell radio access node). The UE relay <NUM> may be any device capable of forming a wireless connection with a macrocell <NUM>, participating in a LAN connection with the RAN <NUM> and of performing the various operations described above with respect to UE relay <NUM> (for instance the operations described with reference to the flow charts of <FIG>).

The UE relay <NUM> may be configured to communicate with the macrocell <NUM> via an appropriate radio interface arrangement <NUM>. The interface arrangement <NUM> may be provided for example by means of a radio part <NUM>-<NUM> (e.g. a transceiver) and an associated antenna arrangement <NUM>-<NUM>. The antenna arrangement <NUM>-<NUM> may be arranged internally or externally to the UE relay <NUM>.

In addition, the UE relay <NUM> comprises a LAN physical interface <NUM> for receiving a LAN cable, thereby to form the LAN connection <NUM> with the RAN <NUM>. The LAN physical interface <NUM> may be of any suitable type. For instance, in some specific examples, the LAN physical interface <NUM> may be an Ethernet port.

The UE relay <NUM> comprises control apparatus <NUM> which is operable to control the other components of the UE relay <NUM>. In addition, the control apparatus <NUM> of the UE relay <NUM> is configured to cause performance of the operations described in connection with the UE relay <NUM> with reference to <FIG>, <FIG> and particularly with reference to <FIG>. The control apparatus <NUM> may comprise processing apparatus <NUM> and memory <NUM>. Computer-readable code <NUM>-2A may be stored on the memory <NUM> which, when executed by the processing apparatus <NUM>, causes the control apparatus <NUM> to perform any of the operations described herein in relation to the UE relay <NUM>. Example configurations of the memory <NUM> and processing apparatus <NUM> will be discussed in more detail below.

As should of course be appreciated, the UE relay <NUM> and the RAN <NUM> shown in <FIG> and described above may comprise further elements which are not directly involved with processes and operations in respect which this application is focussed.

Some further details of components and features of the above-described entities (i.e. the UE relay <NUM> and the RAN <NUM>) and alternatives for them will now be described.

The control apparatuses <NUM>, <NUM> described above may comprise processing apparatus <NUM>, <NUM> communicatively coupled with memory <NUM>, <NUM>. The memory <NUM>, <NUM> has computer readable instructions <NUM>-2A, <NUM>-2A stored thereon which, when executed by the processing apparatus <NUM>, <NUM> causes the control apparatus <NUM>, <NUM> to cause performance of various ones of the operations described with reference to <FIG>. The control apparatus <NUM>, <NUM> may, in some instances, be referred to as simply "apparatus".

The processing apparatus <NUM>, <NUM> may be of any suitable composition and may include one or more processors 501A, 402A of any suitable type or suitable combination of types. Indeed, the term "processing apparatus" should be understood to encompass computers having differing architectures such as single/multi-processor architectures and sequencers/parallel architectures. For example, the processing apparatus <NUM>, <NUM> may be a programmable processor that interprets computer program instructions <NUM>-2A, <NUM>-2A and processes data. The processing apparatus <NUM>, <NUM> may include plural programmable processors. Alternatively, the processing apparatus <NUM>, <NUM> may be, for example, programmable hardware with embedded firmware.

The processing apparatus <NUM>, <NUM> may alternatively or additionally include one or more specialised circuit such as field programmable gate arrays FPGA, Application Specific Integrated Circuits (ASICs), signal processing devices etc. In some instances, processing apparatus <NUM>, <NUM> may be referred to as computing apparatus or processing means.

The processing apparatus <NUM>, <NUM> is coupled to the memory <NUM>, <NUM> and is operable to read/write data to/from the memory <NUM>, <NUM>. The memory <NUM>, <NUM> may comprise a single memory unit or a plurality of memory units, upon which the computer readable instructions (or code) <NUM>-2A, <NUM>-2A is stored. For example, the memory <NUM>, <NUM> may comprise both volatile memory <NUM>-<NUM>, <NUM>-<NUM> and non-volatile memory <NUM>-<NUM>, <NUM>-<NUM>. In such examples, the computer readable instructions/program code <NUM>-2A, <NUM>-2A may be stored in the non-volatile memory <NUM>-<NUM>, <NUM>-<NUM> and may be executed by the processing apparatus <NUM>, <NUM> using the volatile memory <NUM>-<NUM>, <NUM>-<NUM> for temporary storage of data or data and instructions. Examples of volatile memory include RAM, DRAM, and SDRAM etc. Examples of non-volatile memory include ROM, PROM, EEPROM, flash memory, optical storage, magnetic storage, etc..

The memory <NUM>, <NUM> may be referred to as one or more non-transitory computer readable memory medium or one or more storage devices. Further, the term 'memory', in addition to covering memory comprising both one or more non-volatile memory and one or more volatile memory, may also cover one or more volatile memories only, one or more non-volatile memories only. In the context of this document, a "memory" or "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

The computer readable instructions/program code <NUM>-2A, <NUM>-2A may be pre-programmed into the control apparatus <NUM>, <NUM>. Alternatively, the computer readable instructions <NUM>-2A, <NUM>-2A may arrive at the control apparatus <NUM>, <NUM> via an electromagnetic carrier signal or may be copied from a physical entity <NUM> such as a computer program product, a memory device or a record medium such as a CD-ROM or DVD, an example of which is illustrated in <FIG>. The computer readable instructions <NUM>-2A, <NUM>-2A may provide the logic and routines that enables the entities <NUM>, <NUM> to perform the functionality described above. The combination of computer-readable instructions stored on memory (of any of the types described above) may be referred to as a computer program product. In general, references to computer program, instructions, code etc. should be understood to express software for a programmable processor firmware such as the programmable content of a hardware device as instructions for a processor or configured or configuration settings for a fixed function device, gate array, programmable logic device, etc. If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other.

Claim 1:
A transmitting entity for use in the provision of a user equipment relay backhaul connection between a small cell radio access node (<NUM>) and a core network (<NUM>) via a user equipment relay (<NUM>), the transmitting entity being one of the small cell radio access node and the user equipment relay and comprising means for:
generating a message for communication over a local area network connection (<NUM>) between the transmitting entity and a receiving entity, the receiving entity being the other one of the small cell radio access node and the user equipment relay, the message including:
an identifier for indicating that the message includes control information for eliciting a responsive operation by the receiving entity, and
the control information; and
transmitting the generated message over the local area network connection from the transmitting entity to the receiving entity,
wherein the local area network connection is an ethernet connection between the small cell radio access node and the user equipment relay, and
additionally wherein the identifier is included in an EtherType field of the generated message.