Multi-layered connectivity with multi-operator support for moving objects

Abstract

Systems and methods are disclosed for providing cellular service to first User Equipments (UEs) on a moving vehicle. In one embodiment, a system for providing cellular service to first UEs on a moving vehicle comprises a base station located at the moving vehicle and operable to provide radio access to first UEs for two or more overlay cellular service provider (CSP) networks. The base station comprises two or more Radio Access Network (RAN) - Core Network (CN) interfaces that provide respective interfaces between the base station and core networks of the two or more overlay CSP networks. The system further comprises an aggregator located at the moving vehicle and communicatively coupled to the two or more RAN-CN interfaces and a second UE(s). The aggregator is operable to send and receive aggregated traffic for the two or more overlay CSP networks over an underlay CSP network(s) via the second UE(s).

Description

[0001] MUL H-LA YERED CONNECTIVITY WITH MUL TI-OPERA TOR SUPPORT FOR MOVING OBJECTS

[0002] Technical Field

[0003] The present disclosure relates to providing cellular connectivity to User Equipments (UE) in a moving vehicle (e.g., a train or bus).

[0004] Background

[0005] I 5G Background

[0006] Standardization work has been ongoing on in the 3rdGeneration Partnership Project (3GPP) for the Next Generation Radio Access Network (NG-RAN) and 5thGeneration Core (5GC) as new radio access and new packet core network since 3GPP Release (Rel-) 15 (see 3GPP Technical Specification (TS) 23.501 V18.5.0 and 3GPP TS 23.502 V18.5.0 for stage-2 descriptions).

[0007] Figure 1, which is a reproduction of Figure 4.2.3-1 from 3GPP TS 23.501, shows the 5G System (5GS) architecture using the service-based representation.

[0008] Figure 2 shows the internal architecture for a gNodeB (gNB) i.e. referring to a base station supporting New Radio (NR) Radio Access Technology (RAT) in the (Radio) Access Network ((R)AN) of Figure 1, which is called NG-RAN in the case of the 5GS (see 3GPP TS 38.401 for stage-2 description of NG-RAN). Figure 2 assumes that both Higher Layer Split (HLS) and Control Plane (CP) and User Plane (UP) split (CP-UP split) have been adopted within the gNB.

[0009] II QoS Principles

[0010] A QoS in EPS

[0011] Quality of Service (QoS) is managed in the Evolved Packet System (EPS) on a per bearer level from the Core Network (CN). The evolved NodeB (eNB), i.e., a base station supporting the Long Term Evolution (LTE) RAT in the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) of the EPS, is responsible for setting up the radio bearers, radio resource management, and enforcing QoS according to the bearer QoS Profile - over the radio (e.g. LTE-Uu) interface in the downlink and over the transport network in the uplink. Figure 3 gives an overview of the QoS framework in EPS. Bearers including a QoS Profile are set up from the Packet Data Network (PDN) Gateway (GW) in the CN. QoS is enforced in the PDN GW and in the eNB for the downlink, and in the

[0012] UE and the eNB for the uplink.

[0013] Many services and subscribers share the same radio and network resources. Real-time services (voice, video, etc.) share the same resources as non-real-time services (Internet browsing, file download, etc.). One challenge in this area is how to ensure QoS (bit rates, packet delays, packet loss) for Real Time Services. 3GPP EPS (i.e. both E-UTRAN and Evolved Packet Core (EPC)) provides efficient QoS mechanisms to ensure that the user experience of different services sharing the same resources is acceptable. Examples of such mechanisms provided in 3GPP are:

[0014] • Traffic Separation: Different traffic types receive different treatment (queuing, etc.) in network;

[0015] • 3GPP provides for both relative QoS and absolute QoS (using Guaranteed Bit Rates);

[0016] • GBR (Guaranteed Bit Rate) based admission control is used to reserve resources before traffic is admitted into the network or rejected otherwise;

[0017] • Policy (Policy and Charging Control (PCC)) may determine what treatment to apply to the traffic streams.

[0018] 3GPP defines the concept of a PDN (Packet Data Network). A PDN is in most cases an Internet Protocol (IP) network, e.g. Internet or a Cellular Service Provider (CSP) IP Multimedia Subsystem (IMS) service network. A PDN has one or more names, where each name is defined in a string called an Access Point Name (APN). The PDN GW (PGW) is a gateway towards one or more PDNs. A UE may have one or more PDN connections. A PDN connection is a logical IP tunnel between UE and PGW, providing the UE access to a PDN. The setup of a PDN connection is initiated from the UE.

[0019] Every PDN connection consists of one or more bearers. See 3GPP TS 23.401 section 4.7.2 for a description of the bearer concept. A bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and a PGW. Each bearer on a particular access has a unique bearer identifier (ID). On the 3GPP access, the bearer is end-to-end between UE and PGW. Every PDN connection has at least one bearer and this bearer is called the default bearer. All additional bearers on the PDN connection are called dedicated bearers.

[0020] A bearer carries traffic in the form of IP packets or non-IP packets. Which traffic is carried on a bearer is defined by filters, i.e. how to map different applications and their corresponding application flows from a specific UE to different bearers in the network. A filter is an n-tuple where each element in the tuple contains a value, a range, or a wildcard. An n-tuple is also known as an IP flow. An example of a 5-tuple is (dst IP=83.50.20.110, src IP= 145.45.68.201, dst port=80, src port=*, prot=TCP). This 5-tuple defines a source and destination IP address, a source and destination port, and a protocol. The source port is a wildcard. Traffic matching this 5-tuple filter would be all TCP traffic from IP= 145.45.68.201to IP=83.50.20.110 and port= 80. A Traffic Flow Template (TFT) contains one or more filters. Every bearer has a TFT. One bearer within a PDN connection and access may lack an explicit TFT (this bearer is typically the default bearer). Implicitly such bearer has a TFT with a single filter matching all packets.

[0021] There are two types of bearers: GBR and non-GBR bearers. Every EPS bearer is associated with the following QoS parameters: QoS Class Identifier (QCI) and Allocation and Retention Priority (ARP). GBR bearers are in addition associated with bit rate parameters for Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR). Non-GBR bearers do not have bearer-level bit rate parameters. Instead, there is aggregate enforcement of all non-GBR bearers using Aggregate Maximum Bit Rates (AMBR) (APN- AMBR: defined per subscriber and Access Point Name, and UE-AMBR: defined per subscriber).

[0022] The QCI is signalled from the CN to the eNB and defines specific characteristics to be applied for all traffic on this bearer. These characteristics may include: resource type (GBR or Non-GBR), priority, Packet Delay Budget (PDB), Packet Error Loss Rate, Maximum Burst Size (for some GBR QCIs), and Data rate Averaging Window (for some GBR QCIs).

[0023] B QoS Principles in 5GS

[0024] QoS is managed in 5GS on a per QoS Flow level from the CN. The NG-RAN (i.e. gNB or next generation eNB (ng-eNB)) is responsible for setting up the radio bearers for QoS Flows, radio resource management, and enforcing QoS according to the QoS Flow Profile - over the radio interface in the downlink and over the transport network in the uplink. QoS Flows are identified by a QoS Flow ID (QFI). Figure 4 and Figure 5 give an overview of the QoS framework in 5GS. QoS Flows including a QoS Profile are set up between the User Plane Function (UPF) in the 5GC and the User Equipment (UE). In particular, Figure 4 illustrates an overview of the 5GS QoS framework, and Figure 5, which is a reproduction of Figure 5.7.1.5-1 of 3GPP TS 23.501, illustrates the principle for classification and User Plane marking for QoS Flows and mapping to Access Network resources.

[0025] 5GS has defined a new term called a Protocol Data Unit (PDU) session that is very similar to a PDN connection in the earlier mobile generations. One difference is that there is normally only a single N3 / NG-U tunnel (a General Packet Radio Service (GPRS) Tunneling Protocol GTP) User plane (GTP-U) tunnel) for each PDU session between the UPF and NG-RAN. This means that the mapping of different traffic / QoS flows to radio bearers is performed in the NG-RAN; for example, a radio bearer can carry one or more QoS Flows. A QoS Flow is the finest granularity of QoS differentiation in a PDU session. Each QoS Flow is associated with QoS parameters that are used to enforce the correct traffic forwarding treatment. Each packet belongs to a QoS Flow and one PDU session can carry one or several QoS Flows.

[0026] The mapping of different applications and their corresponding application flows from a specific UE to QoS flows is done by using Packet Filters (PF). PFs in 5GS are similar to the TFTs in EPS as described above.

[0027] The QoS Flow level QoS Parameters can be either non-dynamic or dynamic. The non-dynamic case is very similar to the QCI concept in EPS but is called a 5G QoS Identifier (5QI). The 5QI is a scalar that is a part of the 5G QoS parameters and it is used as a reference to standardized (i.e. pre-configured) 5G QoS characteristics that control QoS forwarding treatment for the QoS Flow (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), see 3GPP TS 23.501 clause 5.7.2 and particularly clause 5.7.2. 1. This means that the 5QI is signaled from 5GC to NG-RAN and defines the main characteristics for the QoS Flow. The dynamic case is somewhat different as in this case actual 5G QoS characteristics are also signaled from 5GC to NG-RAN. These signaled characteristics may include Priority Level, Packet Delay Budget, Packet Error Rate, Delay Critical, Averaging Window and Maximum Data Burst Volume, see 3GPP TS 23.501 clause 5.7.2.1 and particularly clause 5.7.3.

[0028] Ill Passenger Connectivity for Moving Vehicles

[0029] Connectivity to passengers in moving vehicles, e.g. trains and buses, is currently provided, either (a) directly from the CSP network to the subscriber inside the train or (b) via Wi-Fi. When Wi-Fi is used inside a train, the connection to the Internet is provided via a mobile link using a base station with coverage of the railway track and a UE on top of the train that terminates the mobile connection on the vehicle. For simplicity, a railway is used hereinafter as an example.

[0030] Figure 6 is an illustration of solution (a) CSP base stations and as well as railway operator base stations (labelled as "RO" base stations in Figure 6) for Future Railway Mobile Communication System (FRMCS) close to the railway track providing coverage, and hence communication to the UEs of passengers in the trains.

[0031] Figure 7 is an illustration of solution (b) where Wi-Fi uses mobile networks to provide an internet connection.

[0032] IV Aggregation Solutions

[0033] There are many different aggregation solutions. This description is given for Multipath Transmission Control Protocol (TCP) (MPTCP), but this is only to be seen as an example. Other possible solutions include for example Multipath Quick User Datagram Protocol (UDP) Internet Connections (MPQUIC) and Multipath UDP (MPUDP).

[0034] Most hosts today are multi-homed. Hence, they have multiple paths for connectivity via one or more access technologies. Regular Transmission Control Protocol (TCP) / IP communications restrict these multi-homed hosts to use only one of the available interfaces / paths per session, where path is defined as an (source, destination) IP address pair. Internet Engineering Task Force (IETF) has defined a mechanism which uses multiple paths between the communicating peers simultaneously during a communication session. RFC 8684 proposes a set of extensions to traditional TCP for multipath operations when multiple addresses are available. This is referred to as 'Multipath TCP' (MPTCP).

[0035] The advantages of using multiple paths concurrently are:

[0036] • Improves network resource utilization (e.g., increase bandwidth due to resource pooling);

[0037] • Improves user experience through higher throughput;

[0038] • Allows failover from one interface to another (e.g., mobile client);

[0039] • Allows a single data connection to use several interfaces simultaneously.

[0040] A usage scenario for MPTCP is illustrated in Figure 8. Two communicating hosts A and B are multi-homed and multi-addressed. Each host provides two separate connections to the Internet offering four different paths between them (Al-Bl, A1-B2, A2-B1 and A2-B2). A traditional TCP connection between the hosts A and B will make use of only one of the available paths whereas MPTCP connection makes use of all the four available paths between hosts A and B. An "MPTCP connection" is similar to a regular TCP connection and is defined in RFC 8684 as a set of one or more subflows, over which an application can communicate between two hosts. A "subflow" is defined in RFC 8684 as a flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similar to a regular TCP connection.

[0041] MPTCP is an end-to-end protocol which requires both hosts to support MPTCP to benefit from MPTCP. Since MPTCP is still in its early stage of deployment, probabilities that every host on the Internet supports MPTCP are very low. To overcome this problem and benefit from MPTCP even though both communicating hosts do not support MPTCP, an MPTCP proxy may be used to convert MPTCP flows to TCP and vice versa.

[0042] Figure 9 shows the differences between standard TCP and MPTCP protocol stacks. The application interface, i.e. the socket Application Programming Interface (API), is unchanged and the main changes are between this API and the IP-layer.

[0043] MPTCP provides the possibility to fully and maximally utilize the different TCP subflows. For example, in the case of one TCP subflow on 3GPP access and another one on Wi-Fi access, the total throughput could be the sum of these subflows.

[0044] Figure 10 shows an exemplary case of "MPTCP in action" when the UE is simultaneously connected to both LTE and Wi-Fi / Wireless Local Area Network (WLAN). The application in the UE has opened up one TCP socket and is sending a "stream of bytes" on the internal API. The MPTCP layer (also called MPTCP scheduler) has established two different TCP subflows, subflow 1 via WLAN / Wi-Fi (the bottom one as shown in Figure 10) and subflow 2 via LTE (the top one as shown in Figure 10). Both these subflows are in this example towards an MPTCP Proxy that further communicates with another server using plain TCP (shown to the right of the MPTCP Proxy in Figure 10). The MPTCP scheduler is the function that decides how the different packets are mapped to the two subflows. In this example, the MPTCP scheduler is applying "roundrobin" scheduling i.e. first TCP segment is sent on subflow 2, second on subflow 1, third again on subflow 2 etc. Another example is that MPTCP scheduler uses the subflow with the shortest round-trip time. Such approach is typically used in today's MPTCP kernel prototype implementations.

[0045] V Integrated Access Backhaul (IAB) 3GPP has defined the IAB solution in 3GPP TS 38.300 V18.1.0. The high level architecture is illustrated in Figure 11. Figure 11(a) illustrates an IAB node using Stand Alone (SA) mode with the Next Generation Core (NGC). Figure 11(b) illustrates an IAB node using E-UTRA / NR Dual Connectivity (EN-DCU).

[0046] With IAB, the TAB-node' connects to a 'IAB-Donor Node' for its backhaul connectivity. Spectrum from the Cellular Service Provider (CSP) providing the IAB solution is used for the wireless backhaul. For 3GPP releases 16 and 17, the lAB-node has been static. For release 18, a work item for what is called 'Mobile IAB' has been started.

[0047] VI Network Sharing with Multi-Operator Core Network (MOCN) Network sharing may be used in multi-CSP (also referred to as multi-operator) scenarios where network sharing may be offered either by pureplay independent Infrastructure Companies, CSP-led tower / infrastructure companies, or joint-venture infrastructure companies. Network sharing may also be used in CSP offerings to an enterprise where the CSP public network may be partly reused as well as complement with a local dedicated for either only private use or for both private and public use.

[0048] Mobile Broadband services are demanded in more and more locations, and also indoors. Enterprises are increasingly operating also out of the enterprise premises, requiring the same connectivity and services inside and outside the office. There is a trend of Bring-Your-Own-Device (BYOD), implying that enterprise personnel (employees, consultants, etc.) bring their own devices, usually associated with or even locked to a specific CSP. The enterprise will thus often need to support several CSPs. A simple way is that all CSPs provide sufficiently good indoor coverage, which usually implies indoor networks for all CSPs. However, this option is not cost efficient, due to amount of radio equipment needed to cover many frequency bands. From a cost perspective it is preferred to use a single radio chain for all users, i.e. one spectrum band.

[0049] 3GPP has defined Multi-Operator Core Network (MOCN) for cooperation between different CSPs (i.e., different network operators) and without the need for separate frequency bands per CSP. In the MOCN case, the Radio Access Network is shared while the Core Networks are separate. MOCN is based on the RAN-CN interface being a business interface between the CSP handling the shared RAN and each participating CSP handling their respective CN. As a consequence, the RAN-CN interface is also a multivendor interface. The shared RAN cells typically indicate multiple Public Land Mobile Network (PLMN) IDs to the UEs (A-C in the case shown in Figure 12).

[0050] Systems and methods are disclosed for providing cellular service to first User Equipments (UEs) on a moving vehicle. In one embodiment, a system for providing cellular service to first UEs on a moving vehicle comprises a base station configured to be located at the moving vehicle and operable to provide radio access to first UEs for two or more overlay cellular service provider (CSP) networks. The base station comprises two or more Radio Access Network (RAN) - Core Network (CN) interfaces that provide respective interfaces between the base station and core networks of the two or more overlay CSP networks. The system further comprises an aggregator configured to be located at the moving vehicle and communicatively coupled to the two or more RAN-CN interfaces and one or more second UEs operable to send and receive aggregated traffic for the two or more overlay CSP networks over one or more underlay CSP networks via the one or more second UEs. In this manner, cellular service is provided to the first UEs (e.g., passenger UEs) on the moving vehicle in a way that may improve network resource utilization, improve user experience, allow for failover from one underlay CSP network to another, and allow the same data connection to use multiple underlay connections simultaneously.

[0051] In one embodiment, the system further comprises the one or more second UEs configured to be located at the moving vehicle and operable to wirelessly send and receive data to the one or more underlay CSP networks.

[0052] In one embodiment, in order to send aggregated traffic for the two or more overlay CSP networks over the one or more underlay CSP networks via the one or more second UEs, the aggregator is configured to receive traffic for at least two of the two or more overlay CSP networks from at least two respective RAN-CN interfaces of the two or more RAN-CN interfaces, aggregate the received traffic for the two or more overlay CSP networks to provide aggregated overlay network traffic, and send the aggregated overlay network traffic to at least one of the one or more second UEs to be sent to a second aggregator via a respective at least one of the one or more underlay CSP networks. In one embodiment, the one or more second UEs comprise two or more second UEs, and the aggregated overlay network traffic is duplicated and sent over at least two of the two or more second UEs. In one embodiment, the one or more second UEs comprise two or more second UEs, and the aggregated overlay network traffic is sent over at least one of the two or more second UEs having a radio link to the corresponding underlay CSP network that satisfies one or more conditions. In one embodiment, the one or more conditions comprise a condition of having a highest signal strength or highest signal quality among radio links between the two or more second UEs. In one embodiment, the one or more conditions comprise a condition of having a signal strength or signal quality that is greater than a certain signal strength or signal quality threshold.

[0053] In one embodiment, in order to receive aggregated overlay network traffic for the two or more overlay CSP networks over the one or more underlay CSP networks via the one or more second UEs, the aggregator is configured to receive aggregated overlay network traffic via at least one of the one or more second UEs, the aggregated overlay network traffic comprising first overlay network traffic for a first overlay CSP network of the two or more overlay CSP networks and second overlay network traffic for a second overlay CSP network of the two or more overlay CSP networks, send the first overlay network traffic to a first RAN-CN interface, and send the second overlay network traffic to a second RAN-CN interface.

[0054] Embodiments of a method performed by a first aggregator at a moving vehicle are also disclosed. In one embodiment, a method performed by a first aggregator, at a moving vehicle, for enabling sending and receiving of aggregated overlay network traffic for two or more overlay CSP networks over one or more underlay CSP networks comprises receiving first overlay network traffic from a first RAN-CN interface of a base station that is at the moving vehicle and supports two or more overlay CSP networks, the first RAN-CN interface being associated to a first overlay CSP network of the two or more overlay CSP networks. The method further comprises receiving second overlay network traffic from a second RAN-CN interface of the base station that supports the two or more overlay CSP networks, the second RAN-CN interface being associated to a second overlay CSP network of the two or more overlay CSP networks. The method further comprises sending aggregated overlay network traffic comprising the first overlay network traffic and the second overlay network traffic to a second aggregator over at least one of one or more underlay CSP networks via at least one UE.

[0055] In one embodiment, the method further comprises receiving third overlay network traffic from at least one of the one or more underlay CSP networks, the third overlay network traffic being for the first overlay CSP network. The method further comprises receiving fourth overlay network traffic from at least one of the one or more underlay CSP networks, the fourth overlay network traffic being for the second overlay CSP network. The method further comprises sending the third overlay network traffic to the first RAN-CN interface of the base station and sending the fourth overlay network traffic to the second RAN-CN interface of the base station.

[0056] Corresponding embodiments of a first aggregator for implementation at a moving vehicle are disclosed. In one embodiment, a first aggregator, for implementation at a moving vehicle, for enabling sending and receiving of aggregated overlay network traffic for two or more overlay CSP networks over one or more underlay CSP networks is adapted to receive first overlay network traffic from a first RAN-CN interface of a base station that is at the moving vehicle and supports two or more overlay CSP networks, the first RAN-CN interface being associated to a first overlay CSP network of the two or more overlay CSP networks. The first aggregator is further adapted to receive second overlay network traffic from a second RAN-CN interface of the base station that supports the two or more overlay CSP networks, the second RAN-CN interface being associated to a second overlay CSP network of the two or more overlay CSP networks. The first aggregator is further adapted to send aggregated overlay network traffic comprising the first overlay network traffic and the second overlay network traffic to a second aggregator over at least one of one or more underlay CSP networks via at least one UE.

[0057] Embodiments of a method performed by a first aggregator at a network-side are also disclosed. In one embodiment, a method performed by a first aggregator for enabling sending and receiving of aggregated overlay network traffic for two or more overlay CSP networks over one or more underlay CSP networks comprises receiving aggregated overlay network traffic from a second aggregator associated to a base station that supports two or more overlay CSP networks via at least one of one or more underlay CSP networks, the aggregated overlay network traffic comprising first overlay network traffic for a first overlay CSP network and second overlay network traffic for a second overlay CSP network. The method further comprises sending the first overlay network traffic to a first core network of the first overlay CSP network and sending the second overlay network traffic to a second core network of the second overlay CSP network.

[0058] In one embodiment, the method further comprises receiving third overlay network traffic from the first core network of the first overlay CSP network, receiving fourth overlay network traffic from the second core network of the second overlay CSP network, and sending aggregated overlay network traffic comprising the third overlay network traffic and the fourth overlay network traffic to the second aggregator associated to the base station that supports the two or more overlay CSP networks via at least one of the one or more underlay CSP networks.

[0059] In one embodiment, the method further comprises receiving Operations and Maintenance (O&M) traffic from an O&M system, wherein the aggregated overlay traffic sent to the second aggregator further comprises the O&M traffic.

[0060] In one embodiment, the method further comprises receiving Operations and Maintenance (O&M) traffic from the second aggregator aggregated together with the aggregated overlay traffic and sending the O&M traffic to an O&M system.

[0061] Corresponding embodiments of a first aggregator for a network side are also disclosed. In one embodiment, a first aggregator for enabling sending and receiving of aggregated overlay network traffic for two or more overlay CSP networks over one or more underlay CSP networks is adapted to receive aggregated overlay network traffic from a second aggregator associated to a base station that supports two or more overlay CSP networks via at least one of one or more underlay CSP networks, the aggregated overlay network traffic comprising first overlay network traffic for a first overlay CSP network and second overlay network traffic for a second overlay CSP network. The first aggregator is further adapted to send the first overlay network traffic to a first core network of the first overlay CSP network and send the second overlay network traffic to a second core network of the second overlay CSP network.

[0062] Brief Description of the

[0063] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description, serve to explain the principles of the disclosure.

[0064] Figure 1, which is a reproduction of Figure 4.2.3-1 from 3rdGeneration Partnership Project (3GPP) Technical Specification (TS) 23.501 V18.5.0, shows the 5thGeneration (5G) System (5GS) architecture using the service-based representation;

[0065] Figure 2 shows the internal architecture for a gNodeB (gNB);

[0066] Figure 3 gives an overview of the Quality of Service (QoS) framework in Evolved Packet System (EPS);

[0067] Figure 4 illustrates an overview of the 5GS QoS framework; Figure 5, which is a reproduction of Figure 5.7.1.5-1 of 3GPP TS 23.501, illustrates the principle for classification and User Plane marking for QoS Flows and mapping to Access Network resources;

[0068] Figure 6 is an illustration of Cellular Service Provider (CSP) base stations and as well as railway operator base stations for Future Railway Mobile Communication System (FRMCS) close to the railway track providing coverage, and hence communication to the UEs of passengers in the trains;

[0069] Figure 7 is an illustration of Wi-Fi using mobile networks to provide an internet connection;

[0070] Figure 8 illustrates a usage scenario for Multi-Path Transmission Control Protocol (MPTCP);

[0071] Figure 9 shows the differences between the standard TCP protocol stack and the MPTCP protocol stack;

[0072] Figure 10 shows an exemplary case of "MPTCP in action" when a User Equipment (UE) is simultaneously connected to both Long Term Evolution (LTE) and Wi-Fi / Wireless Local Area Network (WLAN);

[0073] Figure 11 illustrates the high-level Integrated Access and Backhaul (IAB) solution defined in 3GPP TS 38.300;

[0074] Figure 12 illustrates an example of Multi-Operator Core Network (MOCN) as defined in 3GPP;

[0075] Figure 13 illustrates a system for providing cellular connectivity to UEs in a moving vehicle, in accordance with one example embodiment of the present disclosure;

[0076] Figure 14 illustrates the underlay connectivity of the system of Figure 13, in accordance with an example embodiment;

[0077] Figure 15 illustrates the overlay connectivity of the system of Figure 13, in accordance with an example embodiment;

[0078] Figure 16 is a schematic block diagram of a network node according to some embodiments of the present disclosure; and

[0079] Figure 17 is a schematic block diagram of a UE according to some embodiments of the present disclosure.

[0080] Detailed Description

[0081] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0082] There are certain challenges with existing solutions for passenger connectivity in moving vehicles, e.g., trains and buses. The problems with the currently known solutions include the following. For solution (a) "directly from the Cellular Service Provider (CSP) network to the subscriber inside the train", (see Background, subsection entitled "Passenger Connectivity for Moving Vehicles"): The connection from the CSP network does not (always) provide sufficient communication quality, since the radio signal has to diffract through around the edges of the windows and penetrate through the train windows. Currently, most trains are not 'radio friendly' and are coated with a metallic film that provide a penetration loss of 20-30 decibels (dB). Furthermore, when User Equipments (UEs) of all passengers have direct connections to the network, they will all have to do handovers at the same time when they move along the track from one base station to another, which may cause a high load in the network and may result in failures.

[0083] For solution (b) "via Wi-Fi", (see Background, subsection entitled "Passenger Connectivity for Moving Vehicles"): There is a preference from both subscribers and CSPs for UEs to use the 'regular' mobile connection directly to their CSP network and not go via Wi-Fi. The reasons for this are multifold, e.g. security, unwillingness of subscribers to use 'untrusted' Wi-Fi networks, poor Wi-Fi quality, CSP 'ownership' of subscribers, additional login methods, privacy revealing to third party, etc.

[0084] For IAB, (see Background, subsection entitled "Integrated Access and Backhaul (IAB)"): The 3rdGeneration Partnership Project (3GPP) release 18 'mobile-IAB' will likely have a number of limitations, one being that it can only use backhaul from one CSP. Coverage from multiple CSPs is desired to ensure coverage and capacity. Another potential problem is that even though 3GPP strives for open interfaces between entities, such as the between the 'IAB-node' and 'IAB-Donor Node', this is a quite complex interface and likely difficult to have different vendors for the nodes. This risk to cause an undesired lock-in effect. A related potential lock-in situation is that the CSP that have provided the IAB solution, and thus owns the spectrum used cannot easily be replaced. An additional problem is that trainlines often pass country borders, or areas were different CSPs have been allocated to deploy, this means that 'IAB-Nodes' would have to support roaming in a similar way as ordinary mobile devices, in this scenario also different vendors of 'IAB-Donor Node' are likely to occur.

[0085] Systems and methods are disclosed herein that address the aforementioned challenges and / or other problems associated to existing solutions for passenger connectivity in moving vehicles, e.g., trains and buses. Embodiments of the solution disclosed herein relate to supporting 3GPP-based connectivity for any devices (e.g. UEs of passengers) on any moving vehicles (e.g. trains or buses). Embodiments of the disclosed solution are based on a local base station with multi-CSP (i.e., multi-operator) support being positioned at (e.g., integrated with or attached to) a moving vehicle, where the local base station is connected to multiple (e.g., two or more) core networks of two or more CSPs participating in the multi-CSP solution. This part is referred to herein as "overlay connectivity." As the vehicle is a moving vehicle, a backhaul connectivity between the local base station and the multiple core networks is also provided using a separate 3GPP-based "underlay connectivity" (also referred to herein as an "underlay backhaul connectivity"). The underlay backhaul connectivity is preferably resilient and reliable both when it comes to supported coverage and capacity when the vehicle moves around. Therefore, at least in some embodiments, the backhaul connectivity is provided with a set of underlay CSP networks and with the possibility to use any one or more of these underlay CSP networks (e.g., use the best one(s) of these underlay CSP networks) at any time based on dynamic aggregation. The best CSP network(s) may be determined based on different radio conditions, network load, or the like.

[0086] Embodiments of the solution described herein may include any one or more of the following aspects:

[0087] • the system facilitates the use of a 3GPP based indoor solution in a moving vehicle,

[0088] • the system uses Multi-Operator Core Network (MOCN) in the 3GPP based indoor solution to enable a multi-CSP (i.e., multi-operator) solution for users onboard the moving vehicle,

[0089] • the system uses a set of 3GPP connections for the backhaul from the moving vehicle to the core networks of the CSPs participating in the indoor solution,

[0090] • the system facilitates that the 3GPP connections used for backhaul can be from multiple CSPs, • the system facilitates that the CSPs used for backhaul connections can change dynamically,

[0091] • the system facilitates that the CSPs participating in the indoor solutions and the CSPs used for backhaul connections are independent of each other, meaning that it can be same or different CSPs used for these parts and

[0092] • the system facilitates that the backhaul connections used at any point in time can be aggregated.

[0093] Embodiments of the solution(s) disclosed herein may provide a number of advantages over existing solutions. Embodiments of the solution disclosed herein provide a 3GPP based solution that facilitates very high bit rate to the moving object and to the end users inside the moving object using a flexible, dynamic, and reliable backhaul connectivity. Some example advantages of the disclosed solution as compared to the existing solutions include the possibility to:

[0094] • For solution (a) "directly from the CSP network to the subscriber inside the train": o Provide excellent radio connections to the end users, since it is provided from inside the train, and hence excellent communication quality; o Keep the 'not radio friendly' windows in the trains; o Keep the interference to the outside very low, since the train is effectively a Faraday's cage, particularly if keeping the 'not radio friendly' windows, and hence keep the radio signal inside and thus not leaking interference to the outside; o Keep the only handovers to be conducted to the ones corresponding to the mobility of the UEs providing the backhaul connection(s) from 3GPP equipment on the train to the network;

[0095] • For solution (b) "via Wi-Fi": o Provide a 'regular' 3GPP connection to the subscribers (= passengers);

[0096] • For the mobile IAB solution: o Provide a viable, flexible solution, given the likely limitations of the upcoming 'Mobile-IAB' solution.

[0097] In addition, the proposed solution is based on having all parts of the overlay RAN deployed within the moving vehicle. This provides the following benefits compared to a solution in which the RAN would be divided between the moving vehicle and outside the moving vehicle (e.g. on the other side of the underlay connectivity): • Any UE mobility within the moving vehicle can be solved within the moving vehicle, for example handovers between different parts of the moving vehicle such as multiple train carriages. This means that there is no related signaling load outside the moving vehicle and that the likelihood of mobility signaling succeeding is improved. Thus, handover within the moving vehicle may only be visible within the moving vehicle. This can be achieved in different ways, but the main principle is that RAN maintains an "anchor" point towards the outside world and that this "anchor point" is e.g. for the whole moving vehicle. One example is that the anchor point contains the Centralized Unit (CU)-Control Plane (CP) and the CU-User Plane (UP) of the base station, and the Distributed Units (DUs) of the base station can be located in different parts of the moving vehicle (e.g., for different coverage areas within the moving vehicle). This is for 5G and how it ended up standardized. For 6G, there may be another split known as Low Layer Split from a central function towards Radio Units (RUs), but the main principle is still the same, i.e., to have the "RAN anchor point" towards the outside world.

[0098] • It is possible to enable QoS between the overlay CSPs in the underlay. The MOCN logic is part of the RAN in the moving vehicle and therefore it is possible to identify the overlay connectivity for the different CSPs (i.e. MOCN CSPs) in the underlay. This could be realized for example as multiple CSP-specific tunnels over the underlay connectivity. This enables differentiated handling of the overlay CSPs within the underlay, for example if a specific CSP is paying for a better underlay service or if the communication is related to more critical services such as Future Railway Mobile Communication System (FRMCS).

[0099] • Finally, if the RAN parts for the overlay are driven by a Neutral Host (NH) (e.g. the train company) then it may be beneficial that all 3GPP RAN related equipment is solely based within the moving vehicle.

[0100] Figure 13 illustrates a system 1300 in accordance with one example embodiment of the present disclosure. As illustrated, the system 1300 includes the following entities:

[0101] • A Mobile Extender 1302, located within a moving vehicle 1304, exemplified by a train, and containing: o A base station 1306 with multi-CSP support, based on MOCN, meaning that UEs from multiple overlay CSPs / PLMNs can connect to this base station 1306, and that this base station 1306 is further connected to core networks 1308 and 1310 from these multiple overlay CSPs / PLMNs i.e. supporting related RAN-CN interfaces 1312 and 1314. In the illustrated example, there are two overlay CSPs / PLMNs, which are denoted as Overlay CSP-2 and Overlay CSP-4. The core network 1308 is that of the Overlay CSP-2, and the core network 1310 is that of the Overlay CSP-4. The RAN-CN interfaces 1312 and 1314 handle both user plane and control plane traffic. o Client Mobile Extender Aggregator (CMEA) 1316 supporting aggregation of the RAN-CN interfaces 1312 and 1314 over the underlay backhaul connectivity. o One (1) or more Moving Vehicle UEs, exemplified as train-UEl 1318 and Train-UE-3 1320, supporting underlay backhaul connectivity over multiple underlay CSP networks, which in the illustrated example include an underlay CSP-1 network 1322 and an underlay CSP-3 network 1324. o The RAN-CN interfaces are connected to the CMEA 1316 that is further connected to the moving vehicle UEs 1318 and 1320. o The Mobile Extender 1302 can be operated by any entity, for example in a similar way as a neutral host arrangement, e.g. by an entity related to the moving vehicle, 1304 or that any of the overlay or underlay CSPs takes this role.

[0102] • Passenger UEs belonging to any of the overlay CSP networks, exemplified with UE2 1326 from CSP-2 and UE4 1328 from CSP-4. These UEs are connected to the base station with multi-CSP support. o Note that while passenger UEs 1326 and 1328 are used for the description provided herein, it should be noted that embodiments of the present disclosure may also be utilized for non-passenger UEs belonging to any of the overlay CSP networks. Such non-passenger UEs may be, for example, UEs used to provide connectivity to persons operating the moving vehicle and / or to systems of the moving vehicle 1304 and / or systems utilized in the moving vehicle 1304.

[0103] • Underlay backhaul connectivity using multiple underlay CSP networks shown as the underlay CSP-1 network 1322 and the underlay CSP-3 network 1324 networks, both with their own RAN and core network.

[0104] • Proxy Mobile Extender Aggregator 1330 providing the network side support for the underlay connectivity that can then be used for any overlay connectivity, such as the RAN-CN interfaces 1312 and 1314. The Proxy Mobile Extender Aggregator 1330 also handles O&M traffic for the mobile extender 1302 to and from the Mobile Extender O&M system 1332.

[0105] • Core networks for overlay CSP wide-area networks, exemplified with the overlay core network 1308 for CSP-2 and the overlay core network 1310 for CSP-4. o It should be noted that while the overlay and underlay CSP networks are illustrated separately in Figure 13, it should be understood that a particular CSP network may be both an underlay CSP network and an overlay CSP network.

[0106] • Mobile Extender O&M system 1332 for operation and maintenance of the Mobile Extenders and the Proxy Mobile Extender Aggregator.

[0107] Mobile Extender 1302:

[0108] The base station 1306 with multi-CSP support within the Mobile Extender 1302 can support multiple overlay CSPs / PLMNs. For example, MOCN can support 12 PLMNs, which means that passengers from up to 12 PLMNs could be connected to the Mobile Extender 1302. This also means that up to 12 different RAN-CN interfaces and overlay CSP networks can be supported in the overlay connectivity.

[0109] In a similar way, the number of the Moving Vehicle UEs can be higher than shown in the example of two different Train UEs 1318 and 1320. The number of these UEs is related to the number of underlay CSP networks providing the underlay backhaul connectivity. It is also possible to have more than one Moving Vehicle UE connected to a single underlay CSP network.

[0110] Any signaling (i.e., control plane), user plane, or management traffic (referred to herein as backhaul traffic) in the overlay connectivity is logically part of the overlay but is transported using the available underlay connectivity at any given point in time. The base station 1306 with multi-CSP support within the Mobile Extender 1302 is part of the overlay connectivity. The division into overlay and underlay connectivity also means that the overlay connectivity part does not need to know anything about the underlay connectivity, and vice versa.

[0111] The CMEA 1316 is part of the underlay connectivity and provides a single API and point-of-contact to the base station 1306 with multi-CSP support, shown as Internal API#1 in Figure 13. The CMEA 1316 also provides multi-path aggregation by using the available Train-UEs 1318 and 1320 via the set of Internal API#2s in Figure 13. The Train-UEs 1318 and 1320 are further connected to the underlay CSP networks 1322 and 1324. The multi-path aggregation is supported by the Proxy Mobile Extender Aggregator 1330 on the network side.

[0112] IP-address and IP prefix handling for the Mobile Extender 1302 can be performed in different ways. The Moving Vehicle UEs, i.e. the Train-UEs 1318 and 1320, will receive IP-addresses and / or IP-prefixes from the underlay CSP networks 1322 and 1324. The base station 1306 with multi-CSP support will also need one or more IPaddresses. The following are examples of how IP-addressing can be supported for the base station 1306:

[0113] • In a first example, the base station 1306 uses Dynamic Host Configuration Protocol (DHCP) to retrieve one or more IP-addresses. The CMEA 1316 may contain a DHCP server and return private IP-addresses and / or IP-prefixes to the base station 1306. The actual traffic handling is then based on the CMEA 1316 performing e.g. Network Address Translation (NAT) between the private IP- address / prefixes and the available underlay CSP network IP-addresses / prefixes.

[0114] • In a second example, the base station 1306 uses DHCP to retrieve one or more IP-addresses. The DHCP signaling is forwarded by the CMEA 1316 to the Proxy Mobile Extender Aggregator 1330 on the network side. The Proxy Mobile Extender Aggregator 1330 contains a DHCP server and returns private IP- addresses and / or IP-prefixes to the base station 1306. The actual traffic handling is then based on the Proxy Mobile Extender Aggregator 1330 performing e.g. NAT between the private IP-address / prefixes and any available public IP- addresses / prefixes that the Proxy Mobile Extender Aggregator 1330 has.

[0115] • A third example is similar to the second example, but the Proxy Mobile Extender Aggregator 1330 proxies also the received DHCP signaling to an external DHCP server handling public IP-addresses and / or IP-prefixes. In this case, the base station 1306 will get allocated one or more public IP-addresses and / or IP- prefixes.

[0116] Underlay Connectivity:

[0117] Figure 14 illustrates the underlay connectivity in accordance with an example embodiment. The shown example is with the two Train UEs 1318 and 1320 and underlay CSP networks 1322 and 1324. However, it is to be clear that the number of both Train-UEs and underlay CSP networks can be more than two, and that the number of used Train-UEs and underlay CSP networks may vary at any given point in time. This also means that all Train UEs are not always connected to an underlay CSP network. In a similar way, there is also dynamics in the level of coverage and capacity provided from the different underlay CSP networks, both when it comes to the train movements but also depending on e.g. traffic load situations within these CSP networks.

[0118] Figure 14 also illustrates the operation of the underlay layer for the uplink direction, i.e., from the moving vehicle 1304 towards the network, in accordance with an embodiment of the present disclosure. The steps of the procedure of Figure 14 are described below.

[0119] Step 1400: The overlay layer (i.e., the RAN-CN interfaces 1312 and 1314 of the Mobile Extender 1302) sends overlay traffic to the underlay layer (i.e., to the CMEA Y416) using the internal API#1. This overlay traffic may for example be any of the traffic shown in Figure 15.

[0120] Step 1402: The multipath aggregation function within the CMEA 1316 aggregates the overlay traffic received over the available underlay CSP networks 1322 and 1324. This aggregation can be done in different ways, for example:

[0121] • All overlay traffic is sent over all available underlay CSP networks 1322 and 1324 to really ensure that the overlay traffic is forwarded successfully by the underlay layer;

[0122] • The overlay traffic is divided between all available underlay CSP networks 1322 and 1324, e.g. if there are two available underlay CSP networks, then the overlay traffic is divided evenly between these two available underlay CSP networks;

[0123] • The overlay traffic is initially sent on one of the available underlay CSP networks. If the sending is not successful, then the overlay traffic is sent again on another one of the available underlay CSP networks.

[0124] Step 1404: This step just shows that the overlay traffic could be sent using any set of the available underlay CSP networks 1322 and 1324.

[0125] Step 1406: The multipath aggregation function within the Proxy Mobile Extended Aggregator 1330 performs the receiving side of the aggregation over the available underlay CSP networks 1322 and 1324. This could include removing any possible duplicates and reporting to the sender (i.e. CMEA 1316) that a specific part of the overlay traffic has been, or has not been, received correctly.

[0126] Step 1408: The underlay layer (i.e., the Proxy Mobile Extender Aggregator 1330) forwards the traffic, after aggregation in Step 1406, to the appropriate overlay core network 1308 or 1310 (i.e., the overlay core network 1308 or 1310 corresponding to the passenger UE 1326 or 1328 from which the traffic originated (i.e., overlay core network 1308 for CSP-2 if the traffic originated from passenger UE2 1326 or overlay core network 130 for CSP-4 if the traffic originated from passenger UE4 1328).

[0127] The same principles as described above in steps 1400-1408 also be applied for the downlink direction from the network to the moving vehicle 1304, but in the reverse direction. In particular, for the downlink, the Proxy Mobile Extender Aggregator 1330 receives overlay traffic from the overlay core network 1308 and / or the overlay core network 1310 and sends aggregated overlay traffic including the overlay traffic from the overlay core network 1308 and / or the overlay core network 1310, to the CMEA 1316 over at least one of the underlay CSP networks 1322 and 1324. At the moving vehicle 1304, the CEMA 1316 receives the aggregated overlay traffic from the corresponding Train UE(s) 1318 and / or 1320. If the aggregated overlay traffic includes overlay traffic for the overlay CSP-2 network, the CMEA 1316 sends this overlay traffic (e.g., after removing duplicates and / or merging data received over multiple underlay networks) to the RAN-CN interface 1312 for the overlay CSP-2 network. Likewise, if the aggregated overlay traffic includes overlay traffic for the overlay CSP-4 network, the CMEA 1316 sends this overlay traffic (e.g., after removing duplicates and / or merging data received over multiple underlay networks) to the RAN-CN interface 1314 for the overlay CSP-4 network.

[0128] Note that the Proxy Mobile Extender Aggregator 1330 may also handle O&M traffic for the Mobile Extender 1302. For the uplink direction, this O&M traffic may be aggregated together with the overlay network traffic from the passenger UEs 1326 and 1328 (see optional aspect of step 1402). Then, at the Proxy Mobile Extender Aggregator 1330, this O&M traffic is extracted and sent to the Mobile Extender O&M system 1332 (optional step 1409). For the downlink direction, O&M traffic from the Mobile Extender O&M is aggregated together with the downlink overlay network traffic from the overlay CNs 1308 and 1310. Then, at the mobile extender 1302 at the moving vehicle 1304, the CMEA 1316 extracts the O&M traffic and, in the examples illustrated herein, processes the O&M traffic or provides the O&M traffic to another entity at the mobile extender 1302 for processing.

[0129] Once the underlay connectivity is established via one or more underlay CSP networks, the overlay connectivity can be established and used as explained below. Logical Overlay Connectivity:

[0130] Figure 15 illustrates the operation of the overlay layer, in accordance with an example embodiment. The example in Figure 15 is shown with the passenger UE2 1326 for the overlay CSP-2 network. Once the Mobile Extender 1302 is started, it will connect to the defined overlay CSP networks, which in this example are the overlay CSP-2 core network 1308 and the overlay CSP-4 core network 1310. This could for example be based on Domain Name System (DNS) lookups for configured overlay CSP PLMN-IDs for CSP-2 and CSP-4 and / or network names. First, the N2 / NG-C interface, i.e. the control plane interface, is established from the base station 1306, which is also referred to herein as a local base station at the moving vehicle 1304, to the overlay CSP-2 core network 1308 (e.g., to the AMF in the overlay CSP-2 core network 1308 in the case of a 5G system). Once this is done, the base station 1306 may start broadcasting the PLMN- ID of CSP-2 within the moving vehicle 1304 (e.g., with the train), i.e. using existing MOCN principles. The passenger UE2 1326 detects that CSP-2 network is available within the moving vehicle 1304 and signals the wish to connect to the CSP-2 network. The related signaling, shown as UE2 control plane, is transported using the established N2 / NG-C interface. As part of this signaling, the passenger UE2 1326 will also request connectivity, e.g. IP-based connectivity for one or more PDU sessions. These are established as shown with the N3 / NG-U path, carrying the UE2 user plane.

[0131] The passenger UE4 1328 for the CSP-4 network, and the overlay CSP-4 network connectivity can be established in a similar way.

[0132] The Subscriber Identity Module (SIM) cards used in mobile phones and Internet of Things (loT) devices have traditionally been of legacy Universal Integrated Circuit Card (UICC) type, which hold only one 'SIM profile' provided by the Home PLMN (HPLMN) operator. Most UICC content can be remotely updated but not the entire SIM profile including e.g. security credentials used for authentication. With the emergence of embedded UICC (eUICC) technology (also known as eSIM), there is a new possibility to load and / or enable a complete new 'SIM profile' when needed. This functionality can be used to achieve several means, e.g. secure continuous connectivity without excessive use of (expensive) roaming by initiating a change of SIM profile when e.g. a moving vehicle (e.g., the moving vehicle 1304) with a communication device (holding one or more Moving Vehicle UEs e.g., Train UEs 1318 and 1320) is about to enter another country, prior to loss of coverage from the current serving PLMN. Figure 16 is a schematic block diagram of a network node 1600 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 1600 may be, for example, the base station 1306, a network node implementing the CMEA 1316 or a combination of the base station 1306 and the CMEA 1316, a network node that implements the Proxy Mobile Extender Aggregator 1330 described herein. As illustrated, the network node 1600 includes a control system 1602 that includes one or more processors 1604 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1606, and a network interface 1608. The one or more processors 1604 are also referred to herein as processing circuitry. In addition, if the network node 1600 is a radio access node (e.g., the base station 1306 or network node that implements at least some of the functionality of the base station 1306), the network node 1600 may include one or more radio units 1610 that each includes one or more transmitters 1612 and one or more receivers 1614 coupled to one or more antennas 1616. The radio units 1610 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 1610 is external to the control system 1602 and connected to the control system 1602 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 1610 and potentially the antenna(s) 1616 are integrated together with the control system 1602. The one or more processors 1604 cause the network node 1100 to provide one or more functions of the base station 1306, one or more functions of the CMEA 1316, one or more combined functions of the base station 1306 and the CMEA 1316, or one or more functions of the Proxy Mobile Extender Aggregator 1330, as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1606 and executed by the one or more processors 1604.

[0133] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 1600 or a node implementing one or more of the functions of the network node 1600 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). Figure 17 is a schematic block diagram of a UE 1700 according to some embodiments of the present disclosure. The UE 1700 may be, for example, a passenger UE 1326 or 1328 or a moving vehicle UE (e.g., the Train UE 1318 or the Train UE 1320). As illustrated, the UE 1700 includes one or more processors 1702 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1704, and one or more transceivers 1706 each including one or more transmitters 1708 and one or more receivers 1710 coupled to one or more antennas 1712. The transceiver(s) 1706 includes radio-front end circuitry connected to the antenna(s) 1712 that is configured to condition signals communicated between the antenna(s) 1712 and the processor(s) 1702, as will be appreciated by one of ordinary skill in the art. The processors 1702 are also referred to herein as processing circuitry. The transceivers 1706 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 1700 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1704 and executed by the processor(s) 1702. Note that the UE 1700 may include additional components not illustrated in Figure 17 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the UE 1700 and / or allowing output of information from the UE 1700), a power supply (e.g., a battery and associated power circuitry), etc.

[0134] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 1700 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0135] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0136] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0137] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims1. A system (1302) for providing cellular service to first User Equipments, UEs, (1326, 1328) on a moving vehicle (1304), the system (1302) comprising: a base station (1306) configured to be located at the moving vehicle (1304) and operable to provide radio access to first UEs (1326, 1328) for two or more overlay cellular service provider, CSP, networks, the base station (1306) comprising two or more Radio Access Network, RAN, - Core Network, CN, interfaces (1312, 1314) that provide respective interfaces between the base station (1306) and core networks (1308, 1310) of the two or more overlay CSP networks; and an aggregator (1316) configured to be located at the moving vehicle (1304) and communicatively coupled to the two or more RAN-CN interfaces (1312, 1314) and one or more second UEs (1318, 1320), the aggregator (1316) is operable to send and receive aggregated traffic for the two or more overlay CSP networks over one or more underlay CSP networks (1322, 1324) via the one or more second UEs (1318, 1320).

2. The system (1302) of claim 1, further comprising the one or more second UEs (1318, 1320) configured to be located at the moving vehicle (1304) and operable to wirelessly send and receive data to the one or more underlay CSP networks (1322, 1324).

3. The system (1302) of claim 1 or 2, wherein, in order to send aggregated traffic for the two or more overlay CSP networks over the one or more underlay CSP networks (1322, 1324) via the one or more second UEs (1318, 1320), the aggregator (1316) is configured to: receive traffic for at least two of the two or more overlay CSP networks from at least two respective RAN-CN interfaces (1312, 1314) of the two or more RAN-CN interfaces (1312, 1314); aggregate the received traffic for the two or more overlay CSP networks to provide aggregated overlay network traffic; and send the aggregated overlay network traffic to at least one of the one or more second UEs (1318, 1320) to be sent to a second aggregator (1330) via a respective at least one of the one or more underlay CSP networks (1322; 1324).

4. The system (1302) of claim 3, wherein the one or more second UEs (1318, 1320) comprise two or more second UEs (1318, 1320), and the aggregated overlay network traffic is duplicated and sent over at least two of the two or more second UEs (1318, 1320).

5. The system (1302) of claim 3, wherein the one or more second UEs (1318, 1320) comprise two or more second UEs (1318, 1320), and the aggregated overlay network traffic is sent over at least one of the two or more second UEs (1318, 1320) having a radio link to the corresponding underlay CSP network that satisfies one or more conditions.

6. The system (1302) of claim 5, wherein the one or more conditions comprise a condition of having a highest signal strength or highest signal quality among radio links between the two or more second UEs (1318, 1320).

7. The system (1302) of claim 5, wherein the one or more conditions comprise a condition of having a signal strength or signal quality that is greater than a certain signal strength or signal quality threshold.

8. The system (1302) of claim 1 or 2, wherein, in order to receive aggregated overlay network traffic for the two or more overlay CSP networks over the one or more underlay CSP networks (1322, 1324) via the one or more second UEs (1318, 1320), the aggregator (1316) is configured to: receive aggregated overlay network traffic via at least one of the one or more second UEs (1318, 1320), the aggregated overlay network traffic comprising first overlay network traffic for a first overlay CSP network of the two or more overlay CSP networks and second overlay network traffic for a second overlay CSP network of the two or more overlay CSP networks; send the first overlay network traffic to a first RAN-CN interface (1312); and send the second overlay network traffic to a second RAN-CN interface (1314).

9. A method performed by a first aggregator (1316), at a moving vehicle (1304), for enabling sending and receiving of aggregated overlay network traffic for two or moreoverlay Cellular Service Provider, CSP, networks over one or more underlay CSP networks (1322, 1324), the method comprising: receiving (1400) first overlay network traffic from a first Radio Access Network, RAN, - Core Network, CN, interface (1312) of a base station (1306) that is at the moving vehicle (1304) and supports two or more overlay CSP networks, the first RAN- CN interface (1312) being associated to a first overlay CSP network of the two or more overlay CSP networks; receiving (1400) second overlay network traffic from a second RAN-CN interface (1314) of the base station (1306) that supports the two or more overlay CSP networks, the second RAN-CN interface (1314) being associated to a second overlay CSP network of the two or more overlay CSP networks; and sending (1402) aggregated overlay network traffic comprising the first overlay network traffic and the second overlay network traffic to a second aggregator (1330) over at least one of one or more underlay CSP networks (1322, 1324) via at least one User Equipment, UE, (1318, 1320).

10. The method of claim 9, further comprising: receiving third overlay network traffic from at least one of the one or more underlay CSP networks (1322, 1324), the third overlay network traffic being for the first overlay CSP network; receiving fourth overlay network traffic from at least one of the one or more underlay CSP networks (1322, 1324), the fourth overlay network traffic being for the second overlay CSP network; sending the third overlay network traffic to the first RAN-CN interface (1312) of the base station (1306); and sending the fourth overlay network traffic to the second RAN-CN interface (1314) of the base station (1306).

11. A first aggregator (1316), for implementation at a moving vehicle (1304), for enabling sending and receiving of aggregated overlay network traffic for two or more overlay Cellular Service Provider, CSP, networks over one or more underlay CSP networks (1322, 1324), the first aggregator (1316) adapted to: receive (1400) first overlay network traffic from a first Radio Access Network, RAN, - Core Network, CN, interface (1312) of a base station (1306) that is at themoving vehicle (1304) and supports two or more overlay CSP networks, the first RAN-CN interface (1312) being associated to a first overlay CSP network of the two or more overlay CSP networks; receive (1400) second overlay network traffic from a second RAN-CN interface (1314) of the base station (1306) that supports the two or more overlay CSP networks, the second RAN-CN interface (1314) being associated to a second overlay CSP network of the two or more overlay CSP networks; and send (1402) aggregated overlay network traffic comprising the first overlay network traffic and the second overlay network traffic to a second aggregator (1330) over at least one of one or more underlay CSP networks (1322, 1324) via at least one User Equipment, UE, (1318, 1320).

12. The first aggregator (1316) of claim 11, further adapted to: receive third overlay network traffic from at least one of the one or more underlay CSP networks (1322, 1324), the third overlay network traffic being for the first overlay CSP network; receive fourth overlay network traffic from at least one of the one or more underlay CSP networks (1322, 1324), the fourth overlay network traffic being for the second overlay CSP network; send the third overlay network traffic to the first RAN-CN interface (1312) of the base station (1306); and send the fourth overlay network traffic to the second RAN-CN interface (1314) of the base station (1306).

13. A method performed by a first aggregator (1330) for enabling sending and receiving of aggregated overlay network traffic for two or more overlay Cellular Service Provider, CSP, networks over one or more underlay CSP networks (1322, 1324), the method comprising: receiving (1406) aggregated overlay network traffic from a second aggregator (1316) associated to a base station (1306) that supports two or more overlay CSP networks via at least one of one or more underlay CSP networks (1322, 1324), the aggregated overlay network traffic comprising first overlay network traffic for a first overlay CSP network and second overlay network traffic for a second overlay CSP network;sending (1408) the first overlay network traffic to a first core network (1308) of the first overlay CSP network; and sending (1408) the second overlay network traffic to a second core network (1310) of the second overlay CSP network.

14. The method of claim 13, further comprising: receiving third overlay network traffic from the first core network (1308) of the first overlay CSP network; receiving fourth overlay network traffic from the second core network (1310) of the second overlay CSP network; and sending aggregated overlay network traffic comprising the third overlay network traffic and the fourth overlay network traffic to the second aggregator (1316) associated to the base station (1306) that supports the two or more overlay CSP networks via at least one of the one or more underlay CSP networks (1322, 1324).

15. The method of claim 14, further comprising: receiving Operations and Maintenance, O8iM, traffic from an O&M system (1332), wherein the aggregated overlay traffic sent to the second aggregator (1316) further comprises the O8iM traffic.

16. The method of claim 13, further comprising: receiving (1406) Operations and Maintenance, O8iM, traffic from the second aggregator (1316) aggregated together with the aggregated overlay traffic; and sending (1409) the O8iM traffic to an O8iM system (1332).

17. A first aggregator (1330) for enabling sending and receiving of aggregated overlay network traffic for two or more overlay Cellular Service Provider, CSP, networks over one or more underlay CSP networks (1322, 1324), the first aggregator (1330) adapted to: receive (1406) aggregated overlay network traffic from a second aggregator (1316) associated to a base station (1306) that supports two or more overlay CSP networks via at least one of one or more underlay CSP networks (1322, 1324), the aggregated overlay network traffic comprising first overlay network traffic for a firstoverlay CSP network and second overlay network traffic for a second overlay CSP network; send (1408) the first overlay network traffic to a first core network (1308) of the first overlay CSP network; and send (1408) the second overlay network traffic to a second core network (1310) of the second overlay CSP network.

18. The first aggregator (1330) of claim 17, further adapted to: receive third overlay network traffic from the first core network (1308) of the first overlay CSP network; receive fourth overlay network traffic from the second core network (1310) of the second overlay CSP network; and send aggregated overlay network traffic comprising the third overlay network traffic and the fourth overlay network traffic to the second aggregator (1316) associated to the base station (1306) that supports the two or more overlay CSP networks via at least one of the one or more underlay CSP networks (1322, 1324).

19. The first aggregator (1330) of claim 18, further adapted to: receive Operations and Maintenance, O&M, traffic from an O&M system (1332), wherein the aggregated overlay traffic sent to the second aggregator (1316) further comprises the O&M traffic.

20. The first aggregator (1330) of claim 17, further adapted to: receive (1406) Operations and Maintenance, O&M, traffic from the second aggregator (1316) aggregated together with the aggregated overlay traffic; and send (1409) the O&M traffic to an O&M system (1332).

Images