System and method for low-overhead interoperability between 4G and 5G networks

Techniques described herein may allow for the seamless and efficient use of multiple radio access technologies (“RATs”), such as 4G and 5G RATs. A virtualized base station may be used, which processes traffic sent to and/or received from a user equipment (“UE”) via 4G and 5G RATs. The virtualized base station may include separate protocol stacks for the separate RATs. One RAT may be the “master” RAT, and the protocol stack for the master RAT may communicate with a core network via a General Packet Radio (“GPRS”) Tunneling Protocol (“GTP”) tunnel. In the downlink direction, the virtual base station may determine via which RAT traffic, received from the core network, should be sent to the UE by identifying quality of service class indicators (“QCIs”) associated with the downlink traffic.

BACKGROUND

Wireless telecommunications systems have been experiencing rapid growth in mobile data demand. In order to accommodate the rapidly growing demand for mobile data, wireless telecommunications providers may utilize wider and/or higher frequency bands than are traditionally used for Third Generation Partnership Project (“3GPP”) third generation (“3G”) or fourth generation (“4G”) radio access technologies (“RATs”). The wider and/or higher frequency next generation RATs may be capable of significantly higher throughput than 3G or 4G RATs. However, since current systems are not necessarily built to handle the increased throughout provided by next generation RATs, wireless telecommunications providers may face challenges and/or increased costs in moving data between base stations and their core networks.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Systems and/or methods, described herein, may allow for the seamless and efficient use of multiple different radio access technologies (“RATs”), such as Third Generation Partnership Project (“3GPP”) fourth generation (“4G”) and fifth generation (“5G”) RATs. For example, as shown inFIG. 1, a user equipment (“UE”) may be within the coverage area of both 4G radio equipment (e.g., radio transceivers) and 5G radio equipment. The UE may be capable of simultaneously communicating with both base stations. For instance, the UE may send and/or receive data (e.g., file downloads, web browsing, or the like) and/or voice communications to and/or from the 5G radio equipment, and may send and/or receive data and/or voice communications to and/or from the 4G radio equipment. In the specific example shown inFIG. 1, the UE may send and/or receive voice communications to and/or from the 4G radio equipment, and may send and/or receive data to and/or from the 5G radio equipment.

Conventionally, when a radio access network (“RAN”) communicates with a wireless telecommunications core network (e.g., when a Long-Term Evolution (“LTE”) evolved Node B (“eNB”) communicates with a Serving Gateway (“SGW”)), a specialized S1 interface is used to transport data between physical eNBs and one or more physical SGWs. However, since conventional systems require physical devices with specialized interfaces, such systems encounter difficulties in scalability.

For example, typically, a RAN may include Radio Equipment (“RE”) and Radio Controllers (“RCs” (the combination of RE and one or more RCs may be referred to herein as an “RE/RC”)) that process physical (“PHY”) layer (e.g., Open Systems Interconnection (“OSI”) Layer 1) user data (e.g., voice traffic, data traffic, etc.) that is sent to and/or received from a UE (e.g., wireless telephones or other devices) via an air interface. An RE may communicate PHY layer data (e.g., as In-phase/Quadrature (“IQ”) modulation data) with an RC using a fiber link, such as a Common Radio Public Interface (“CPRI”) link. The RC may generate higher layer (e.g., Media Access Control (“MAC”) layer (e.g., OSI Layer 2)) packets based on the PHY layer data. The RC may communicate with an eNB, may generate even higher layer packets (e.g., Packet Data Convergence Protocol (“PDCP”) layer (e.g., OSI Layer 3) packets) based on the MAC layer packets, and communicate with an Evolved Packet Core (“EPC”) (e.g., may send and/or receive user traffic to and/or from a Serving Gateway (“SGW”) of the EPC).

In order to handle additional data (such as when implementing a 5G RAT, which can provide a significantly greater throughput than 4G RATs), a solution within the existing system could include adding additional physical fiber links between (1) Radio Equipment (RE) and Radio Controllers (RCs), (2) between RCs and eNBs, and/or between (3) eNBs and SGWs. However, these solutions present the potential for extreme costs and/or other difficulties. Additionally, because 5G RATs have the potential for carrying such vast amounts of data (hundreds of times the amount of data that 4G RATs are designed to handle), the use of specialized 5G hardware could prove costly.

As described herein, a virtualized system provides beneficial scalability and flexibility to wireless telecommunications systems, such that the throughput able to be handled by such systems may be significantly increased. Using the virtualized environment described herein, wireless telecommunications providers are able to offer 5G RATs to subscribers, and may further implement 5G RATs alongside existing 4G RATs. In some implementations, the virtualized system described herein may transport data, at layers higher than the PHY layer, from RE/RCs to a virtualized eNB (“V-eNB”), or a virtual base station, which may include a set of devices, such as a “cloud” system that implements the functionality of one or more eNBs. For instance, the RE/RCs may transport MAC layer data to and/or from the virtual eNB. By transporting MAC data instead of PHY data, the amount of overhead may be reduced (e.g., PHY layer header information), thereby reducing the need for specialized physical links to transport data between the RE/RCs and the V-eNB215. For example, since V-eNB215scan be implemented using any suitable hardware, the links between RE/RCs and V-eNB215scan be suitable transmission link, as opposed to a specialized fiber link. As mentioned above, the reduced need for physical links may be beneficial in systems where very large amounts of data need to be transported, such as in systems that implement 5G RATs.

FIG. 1illustrates an example overview of an example implementation described herein. As shown inFIG. 1, a UE may be located within the coverage areas of a 4G RAN and a 5G RAN. For example, as illustrated inFIG. 1, the UE may be able to communicate with the 4G RE and the 5G RE. In this example, different types of data may be communicated via different RANs. For instance, as shown, the 4G RAN may be used for voice traffic, and the 5G RAN may be used for data traffic (e.g., web browsing, text messaging, etc.).

The RE of each RAN may communicate with a respective RC. For example, PHY layer data may be communicated between respective REs and RCs. As mentioned above, the RCs may process data at the MAC layer (e.g., may receive MAC layer data and provide the data as PHY layer data to a respective RE, and/or may receive PHY layer data from a respective RE and process the data up to MAC layer data). The RC may communicate with a V-eNB215, which, as described herein, may implement eNB functionality with respect to multiple RATs (e.g., 4G and 5G RATs, in this example).

The V-eNB215may process General Packet Radio (“GPRS”) Tunneling Protocol (“GTP”) data, and may communicate with a core network (e.g., an EPC of a wireless telecommunication network) using GTP signaling. For example, the V-eNB215may receive MAC layer data from 4G and/or 5G RCs, and process the data up to GTP layer data (e.g., may encapsulate the MAC layer data in GTP packets), and/or may receive GTP layer data from the EPC and provide the data to respective 4G and/or 5G RCs as MAC layer data.

FIG. 2illustrates example environment200, in which systems and/or methods described herein may be implemented. As shown inFIG. 2, environment200may include UE205, 4G RE/RC210, 5G RE/RC212, V-eNB215, SGW220, mobility management entity device (“MME”)222, packet data network (“PDN”) gateway (“PGW”)225, policy and charging rules function (“PCRF”)230, home subscriber server (“HSS”)/authentication, authorization, accounting (“AAA”) server235(hereinafter referred to as “HSS/AAA server235”), and PDN240. While “direct” connections are shown inFIGS. 2-4between certain devices, some devices may communicate with each other via one or more intermediary devices (e.g., routers, switch, hubs, etc.) or networks (e.g., an Ethernet backhaul network (“EBH”) and/or some other type of network). Furthermore, some of the connections shown inFIGS. 2-4may be logical connections, and may represent the communication between different logical portions of a single device.

Environment200may include an evolved packet system (“EPS”) that includes an LTE network and/or an EPC network that operate based on a 3GPP wireless communication standard. The LTE network may be, or may include, one or more RANs that each include one or more RE and/or RCs (e.g., RE/RC210and/or RE/RC212), and/or base stations (e.g., V-eNB215), via which UE205may communicate with the EPC network. In some implementations, while not explicitly shown, environment200may also include one or more conventional eNBs. In this example, the EPC network may include one or more SGWs215, PGWs225, and/or MMEs222, and may enable UE205to communicate with PDN240and/or an Internet protocol (“IP”) multimedia subsystem (“IMS”) core network (not shown). The IMS core network may include and/or communicate with HSS/AAA server235, and may manage authentication, session initiation, account information, a user profile, etc., associated with UE205.

UE205may include a computation and communication device, such as a wireless mobile communication device that is capable of communicating with 4G RE/RC210, 5G RE/RC212, and/or PDN240. For example, UE205may include a “dual-band,” a “tri-band,” a “quad-band,” etc. device that is capable of simultaneously communicating via multiple RATs (e.g., via a 4G RAT, a 5G RAT, etc.). UE205may be, or may include, a radiotelephone; a personal communications system (“PCS”) terminal (e.g., a device that combines a cellular radiotelephone with data processing and data communications capabilities); a personal digital assistant (“PDA”) (e.g., a device that may include a radiotelephone, a pager, Internet/intranet access, etc.); a smart phone; a laptop computer; a tablet computer; a camera; a personal gaming system; or another type of mobile computation and communication device. UE205may send traffic to and/or receive traffic from PDN240via 4G RE/RC210, 5G RE/RC212, V-eNB215, SGW220, and/or PGW225.

4G RE/RC210may include one or more network devices that receive, process, and/or transmit traffic, such as calls, audio, video, text, and/or other data, destined for and/or received from UE205. In one example, 4G RE/RC210may be part of the LTE network, and may correspond to a 4G RAT (e.g., may communicate with UE205using one or more radio frequency bands associated with the 4G RAT). 4G RE/RC210may receive traffic, destined for UE205, from V-eNB215, SGW220, PGW225, and/or PDN240, and may output the traffic to UE205. 4G RE/RC210may also receive traffic from UE205, and may output the traffic to its intended destination via V-eNB215, SGW220, PGW225, and/or PDN240. 4G RE/RC210may include one or more REs, such as one or more radio transceivers, and one or more RCs, which aggregate and/or de-aggregate data that is received via and/or is to be sent via the REs. The RE and RC components of 4G RE/RC210may be communicatively coupled via a CPRI link and/or via some other type of physical link. As mentioned above, the RE component of 4G RE/RC210may communicate PHY layer data with the RC component, while the RC component communicates MAC layer data with V-eNB215.

5G RE/RC212may include one or more network devices that receive, process, and/or transmit traffic, such as calls, audio, video, text, and/or other data, destined for and/or received from UE205. In one example, 5G RE/RC212may be part of the LTE network, and may correspond to a 5G RAT (e.g., may communicate with UE205using one or more radio frequency bands associated with the 5G RAT). 5G RE/RC212may receive traffic, destined for UE205, from V-eNB215, SGW220, PGW225, and/or PDN240, and may output the traffic to UE205. 5G RE/RC212may also receive traffic from UE205, and may output the traffic to its intended destination via V-eNB215, SGW220, PGW225, and/or PDN240. 5G RE/RC212may include one or more REs, such as one or more radio transceivers, and one or more RCs, which aggregate and/or de-aggregate data that is received via and/or is to be sent via the REs. The RE and RC components of 5G RE/RC212may be communicatively coupled via a CPRI link and/or via some other type of physical link. As mentioned above, the RE component of 5G RE/RC212may communicate PHY layer data with the RC component, while the RC component communicates MAC layer data with V-eNB215.

As described in more detail herein (e.g., with respect toFIGS. 5-7), V-eNB215may include one or more devices that aggregate data from one or more RE/RCs (e.g., 4G RE/RC210and/or 5G RE/RC212), process data received from the RE/RCs (e.g., process MAC layer data into higher layer data, such as PDCP layer data), and communicate with SGW220using GTP communications. Additionally, V-eNB215may receive user data from SGW220via GTP communications, may process the user data into MAC layer data, and provide the MAC layer data to the appropriate RE/RC (e.g., to 4G RE/RC210and/or 5G RE/RC212).

V-eNB215may be implemented in a “cloud”-based environment. That is, V-eNB215may include the hardware resources of one or more distributed devices. In some implementations, the amount of resources provisioned for V-eNB215may be dynamically adjusted based on the demand for such resources. In this manner, the virtualized nature of V-eNB215may allow for flexibility and scalability of the traffic handling capabilities of the RAN(s) implemented by 4G RE/RC210, 5G RE/RC212, and/or V-eNB215.

SGW220may include one or more network devices that gather, process, search, store, and/or provide information in a manner described herein. SGW220may, for example, aggregate traffic received from one or more base stations210, and may send the aggregated traffic to PDN240via PGW225.

PGW225may include one or more network devices that gather, process, search, store, and/or provide information in a manner described herein. PGW225may aggregate traffic received from one or more SGWs215, etc. and may send the aggregated traffic to PDN240. PGW225may also, or alternatively, receive traffic from PDN240and may send the traffic toward UE205via base station210and/or SGW220.

MME222may include one or more computation and communication devices that perform operations to register UE205with the EPS, to establish bearer channels associated with a session with UE205, to hand off UE205from the EPS to another network, to hand off UE205from the other network to the EPS, and/or to perform other operations. MME222may perform policing operations on traffic destined for and/or received from UE205.

PCRF230may include one or more devices that aggregate information to and from the EPC network and/or other sources. PCRF230may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases and/or from one or more users (such as, for example, an administrator associated with PCRF230).

HSS/AAA server235may include one or more devices that manage, update, and/or store, in a memory associated with HSS/AAA server235, profile information associated with a subscriber. The profile information may identify applications and/or services that are permitted for and/or accessible by the subscriber; a mobile directory number (“MDN”) associated with the subscriber; bandwidth or data rate thresholds associated with the applications and/or services; information associated with the subscriber (e.g., a username, a password, etc.); rate information; minutes allowed for a subscriber (e.g., a subscriber associated with UE205); information regarding services to which particular subscribers are subscribed (e.g., communication services, such as video conferencing services, voice chat services, etc.); and/or other information. Additionally, or alternatively, HSS/AAA server235may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE205.

PDN240may include one or more wired and/or wireless networks. For example, PDN240may include an IP-based PDN, a wide area network (“WAN”) such as the Internet, a core network of a telecommunications provider, a private enterprise network, and/or one or more other networks. UE205may connect, through PGW225, to data servers, application servers, other UEs205, and/or to other servers or applications that are coupled to PDN240. PDN240may be connected to one or more other networks, such as a public switched telephone network (“PSTN”), a public land mobile network (“PLMN”), and/or another network. PDN240may be connected to one or more devices, such as content providers, applications, web servers, and/or other devices, with which UE205may communicate.

FIG. 3illustrates another example environment300, in which systems and/or methods described herein may be implemented. As shown inFIG. 3, environment300may include UE205, one or more base stations310, virtualized gateway (“VGW”)315, PGW225, PCRF230, HSS/AAA server235, and PDN240. Some of the devices, shown inFIG. 3, are similar to devices described above with respect toFIG. 2, and will not be described in detail below.

Environment300may include an evolved packet system (“EPS”) that includes an LTE network and/or an EPC network that operate based on a 3GPP wireless communication standard and/or another advanced wireless standard. The LTE network may be, or may include, one or more RANs that each include one or more base stations310, via which UE205may communicate with the EPC network. Base stations310may include, or may be, a conventional (or standard) LTE eNB. In this example, the EPC network may include VGW315and PGW225, and may enable UE205to communicate with PDN240and/or an IMS core network (not shown).

Base station310may include one or more network devices that receive, process, and/or transmit traffic, such as calls, audio, video, text, television programming content, and/or other data, destined for and/or received from UE205. Base station310may be an eNB device and may be part of the LTE network. Base station310may receive traffic from and/or send traffic to PDN240via VGW315and PGW225. Base station310may send traffic to and/or receive traffic from UE205via an air interface. In some implementations, base station310, or multiple base stations310, may include multiple radio transceivers and/or other hardware or logic that is capable of implementing RANs that correspond to multiple different RATs. For example, base station310may implement a 4G RAT and a 5G RAT, or one base station310may implement a 4G RAT while another base station310implements a 5G RAT.

VGW315may include one or more devices that perform functions similar to an SGW and/or an MME (e.g., SGW220and/or MME222, as described above). VGW315may be implemented in a “cloud”-based environment. That is, VGW315may include the hardware resources of one or more distributed devices. In some implementations, the amount of resources provisioned for VGW315may be adjusted based on the demand for such resources. In this manner, the virtualized nature of VGW315may allow for flexibility and scalability of the traffic handling capabilities of the RAN(s) implemented by base station(s)310.

Environment400may include a combination of several of the devices described above with respect toFIGS. 3 and 4. For instance, as compared to conventional systems, environment400may employ virtualized devices to implement base stations (e.g., eNBs) as well as the entry point to the EPC (e.g., an SGW). Further, environment400may make use of 4G RE/RC210and 5G RE/RC212, which may add to the scalability and flexibility of the implementation shown inFIG. 4.

FIGS. 5, 7, and 9-11illustrate example functional components of one or more RE/RCs and/or V-eNB215sdiscussed above, as well as protocol stacks and communication pathways between RE/RCs, V-eNB215s, UE205, and/or an EPC.FIGS. 6, 8, and 12illustrate example signal flows that may occur between functional components of some implementations described with respect toFIGS. 5, 7, and/or9-11.

For example, as shown inFIG. 5, UE205may be communicatively coupled to 4G RE/RC210and 5G RE/RC212. This communication may occur via an air interface, according to a corresponding RAT. For instance, UE205may communicate with 4G RE/RC210via a 4G RAT, and may communicate with 5G RE/RC212via a 5G RAT. More specifically, for instance, UE205may communicate with 4G RE/RC210and 5G RE/RC212via the PHY layer (e.g., may send and/or receive traffic according to an Orthogonal Frequency-Division Multiple Access (“OFDMA”) modulation scheme to and/or from 4G RE/RC210and 5G RE/RC212). In the downlink direction, 4G RE/RC210and 5G RE/RC212may receive MAC layer protocol data units (“PDUs”) destined for UE205(e.g., from V-eNB215505), and may process the MAC PDUs to PHY layer traffic (e.g., according to an OFDMA modulation scheme).

In the example shown inFIG. 5, the 5G RAT may be the “master” RAT. For example, as described below, UE205may have first established communications with 5G RE/RC212(i.e., prior to connecting to, or communicating with, 4G RE/RC210). 4G RE/RC210and 5G RE/RC212may each respectively process PHY layer traffic received from UE205up to the MAC layer. For example, 4G RE/RC210and 5G RE/RC212may each construct MAC PDUs based on PHY layer traffic received from UE205, and may communicate the MAC PDUs to V-eNB215505. In some implementations, separate bearers (e.g., Layer 2 bearers, such as guaranteed bitrate (“GBR”) or non-GBR bearers) may be established between UE205and V-eNB215505(e.g., via 4G RE/RC210and 5G RE/RC212). In some implementations, the different bearers may correspond to different Quality of Service (“QoS”) levels. For example, in an LTE implementation, different QoS levels may be mapped to different QoS Class Indicators (“QCIs”). As similarly discussed above, different bearers may be used for different applications (e.g., which can correspond to different QCIs). For instance, a bearer on the 4G RAT may be used for voice calls, while a bearer on the 5G RAT may be used for data traffic.

A first bearer, corresponding to a first QCI (or a first set of bearers, corresponding to a first set of different QCIs), may be established between UE205and V-eNB215505(e.g., via 4G RE/RC210), while a second bearer, corresponding to a second QCI (or a second set of bearers, corresponding to a second set of different QCIs), may be established between UE and205(e.g., via 5G RE/RC212). The traffic, sent to and/or received via 4G RE/RC210, may be processed by 4G protocol stack (hereinafter referred to as “4G stack”)510, while the traffic, sent to and/or received via 5G RE/RC212, may be processed by 5G protocol stack (hereinafter referred to as “5G stack”)515. The MAC PDUs, sent and/or received by 4G RE/RC210and/or 5G RE/RC212, may be marked with QCI markings (e.g., in the header of the MAC PDUs), which indicate the QCI that corresponds to each particular MAC PDU.

V-eNB215505may include 4G stack510and 5G stack515, each of which may be implemented as one or more hardware devices, software logic, or a combination thereof. As shown, 4G RE/RC210may communicate with 4G stack510, while 5G RE/RC212may communicate with 5G stack515. In some implementations, some or all components of V-eNB215505may be implemented in a virtualized manner. For example, one or more devices (e.g., a “cloud” system) may be used to implement 4G stack510, and/or 5G stack515. In some implementations, 4G stack510and/or 5G stack515may be implemented using one or more virtual machines provisioned on a single device or a collection of devices (e.g., a distributed system). The communication between RE/RCs210and212and V-eNB215505may occur via any suitable communication link. For example, dedicated fiber lines (e.g., a CPRI link) may be used to carry communications between RE/RCs210and212and V-eNB215505. Additionally, or alternatively, other types of suitable communication pathways, which are not limited to dedicated fiber lines. For example, when not needed for carrying communications between RE/RCs210and212and V-eNB215505, such communication pathways may be used or provisioned for other purposes. In some implementations, V-eNB215505may be implemented on the same device, or set of devices, as 4G RE/RC210and/or 5G RE/RC212. In some such implementations, the communication pathways between RE/RCs210and212and V-eNB215505may include an intra-device bus.

Generally speaking, 4G stack510may process traffic sent to and/or received from UE205via the 4G RAT, while 5G stack515may process traffic sent to and/or received from UE205via the 5G RAT. Furthermore, as mentioned above and as described in more detail below, 5G stack515may perform additional functions, due to being associated with the “master” RAT in this scenario. 4G stack510may, for example, process MAC PDUs, received from 4G RE/RC210, up to Radio Link Control (“RLC”) PDUs (e.g., may construct RLC PDUs from multiple MAC PDUs). 5G stack515may process MAC PDUs, received from UE205, up to PDCP PDUs (e.g., process MAC PDUs up to RLC PDUs, and then to PDCP PDUs). 5G stack515may also process RLC PDUs, from 4G stack510, (e.g., which correspond to 4G traffic from UE205), up to PDCP PDUs. For example, 4G stack510may output the RLC PDUs to 5G stack515, which may generate PDCP PDUs based on the RLC PDUs from 4G stack510.

In some implementations, 5G stack515may preserve QoS treatment of traffic received via 4G RE/RC210and 5G RE/RC212by generating separate PDCP PDUs for traffic received via each of 4G RE/RC210and 5G RE/RC212. For example, one PDCP PDU, generated by 5G stack515, may be made up of RLC PDUs processed by 5G stack515, while another PDCP PDU generated by 5G stack515may be made up only of RLC PDUs received from 4G stack510.

In some implementations, however, 5G stack515may generate PDCP PDUs that are made up of RLC PDUs that were processed by 5G stack515and received from 4G stack510. In some such implementations, 5G stack515may mark and/or treat each PDCP PDUs according to the highest QoS (e.g., QCI) associated with a RLC PDU that is included in each PDCP PDU. 5G stack515may generate GTP PDUs based on one or more PDCP PDUs, and communicate the GTP PDUs to VGW315. In some implementations, instead of communicating the GTP PDUs to VGW315, 5G stack515may communicate the GTP PDUs to an SGW, such as SGW220(e.g., through an established GTP tunnel between 5G stack515and VGW315and/or SGW220).

FIG. 6illustrates an example signal flow between the components shown inFIG. 5. As shown, a bearer setup process may occur (at605) between UE205, 5G RE/RC212, V-eNB215505(e.g., 5G stack515), and VGW315. For example, UE205may enter a communications range of 5G RE/RC212, power on while in communications range of 5G RE/RC212, etc. The bearer setup process may occur according to known standards and/or some other suitable process. As a result of the bearer setup process, one or more bearers (each with a corresponding QCI) may be established between UE205and, ultimately, VGW315. As mentioned above, VGW315may be the entry point to a core network, which may provide connectivity, for UE205, to PDN240(e.g., the Internet).

VGW315may locate (at610) a suitable 4G RE/RC210, from a pool of candidate RE/RCs210, to serve 4G communications to and/or from UE205. For example, VGW315may locate a particular 4G RE/RC210that is geographically located nearest to the location of UE205, nearest to the location of 5G RE/RC212, and/or may use one or more other factors in locating a suitable 4G RE/RC210(e.g., how loaded or overloaded the candidate RE/RCs210are, etc.). In some implementations, 4G RE/RC210may be located by MME222in lieu of, or in addition to, VGW315. Once 4G RE/RC210has been located, one or more bearers may be set up (at615) between UE205, 4G RE/RC210, V-eNB215505(e.g., 4G stack510), and VGW315.

Arrows620-635, inFIG. 6, illustrate how uplink traffic (i.e., traffic from UE205) may be handled, while arrows640-660illustrate how downlink traffic (i.e., traffic to UE205) may be handled, in accordance with some implementations. As shown, UE205may send (at620) traffic, using the 5G RAT, to 5G RE/RC212. The traffic may be sent as PHY layer traffic using the 5G RAT (e.g., according to an OFDMA modulation scheme). 5G RE/RC212may receive the traffic from UE205, and may construct MAC PDUs based on the received traffic. 5G RE/RC212may provide the MAC PDUs to V-eNB215505(e.g., 5G stack515). 5G stack515may construct PDCP PDUs based on the MAC PDUs.

UE205may also send (at625) traffic, using the 4G RAT, to 4G RE/RC210. In some implementations, UE205may send traffic to 4G RE/RC210and 5G RE/RC212simultaneously, such as in scenarios where UE205uses the 4G RAT for voice calls, and the 5G RAT for data. 4G RE/RC210may construct MAC PDUs from the traffic sent to 5G RE/RC212, and provide the MAC PDUs to V-eNB215505(e.g., 4G stack510). 4G stack510may process the MAC PDUs up to the RLC layer (e.g., may construct RLC PDUs based on the MAC PDUs).

Since the 4G RAT is not the “master” RAT in this implementation, 4G stack510may pass the RLC PDUs to 5G stack515(e.g., via an intra-device bus when 4G stack510and 5G stack515are implemented by the same device, or via some other type of inter-device communication pathway when 4G stack510and 5G stack515are implemented by different devices). 5G stack515may construct PDCP PDUs based on the RLC PDUs received from 4G stack510. As mentioned above, these PDCP PDUs may be distinct from PDCP PDUs that are constructed by 5G stack515based on traffic received from UE205via the 5G RAT. For instance, each PDCP PDU, generated by 5G stack515, may be associated only with traffic that is associated with one QCI. In some implementations, each PDCP PDU may be associated with traffic that is associated with more than one QCI. As mentioned above, in such implementations, the PDCP PDU may be marked with a QoS marking that is based on one of the QCIs with which traffic, included in the PDCP PDU, is associated (e.g., the highest level of QoS, which corresponds to lower QCI numbers).

5G stack515may construct GTP PDUs based on the PDCP PDUs. As with the PDCP PDUs, each GTP PDU may correspond to one QoS level, or may include traffic that corresponds to multiple QoS levels. 5G stack515may output (at635) the GTP PDUs to VGW315. VGW315may proceed to route the traffic toward their intended destination (e.g., to PDN240and/or some other network or device).

In the uplink direction (i.e., for traffic intended for UE205), VGW315may output (at640) GTP PDUs to V-eNB215505(e.g., to 5G stack515). Each GTP PDU may be associated with a particular QoS level (e.g., may include traffic that is associated with only one QCI). In some implementations, a particular GTP PDU may include traffic that is associate with multiple QoS levels, and may include a QoS marking that indicates one of the multiple QoS levels (e.g., a highest QoS level, of the multiple QoS levels). 5G stack515may decapsulate (at645) the GTP PDUs, which may yield PDCP PDUs. As similarly discussed above, the PDCP PDUs may each be associated with one particular QoS level (e.g., may include traffic that is associated with one QCI). 5G stack515may determine the QoS level, of each PDCP PDU (and/or of GTP PDUs that include the PDCP PDUs), by inspecting a header of the PDU (e.g., by inspecting a PDCP header of a PDCP PDU or by inspecting a GTP header of a GTP PDU). Additionally, or alternatively, 5G stack515may determine the QoS level by inspecting lower layers of the PDCP PDUs (e.g., by performing deep packet inspection), or by determining the QoS level after decapsulating the PDCP PDUs to yield RLC PDUs. That is, 5G stack515may decapsulate the PDCP PDUs to yield RLC PDUs, and then may determine the QoS level by inspecting RLC headers of the RLC PDUs.

5G stack515may, in some implementations, maintain a mapping of QoS levels to the appropriate RAT. For example, the 5G RAT may be associated with one set of QCIs, while the 4G RAT may be associated with another set of QCIs. 5G stack515may use this mapping to determine which RLC PDUs should be processed according to which RAT. For instance, after determining the QoS levels associated with the RLC PDUs, 5G stack515may output (at650) certain RLC PDUs (i.e., the RLC PDUs that have a QoS level that, according to the mapping, is associated with the 4G RAT) to 4G stack510, and may process the other RLC PDUs (i.e., the RLC PDUs that have a QoS level that is associated with the 5G RAT).

4G stack510may process the RLC PDUs (received at650) by decapsulating the RLC PDUs to yield MAC PDUs, and may output (at655) the MAC PDUs toward UE205(e.g., by outputting the MAC PDUs to 4G RE/RC210). 4G RE/RC210may decapsulate the MAC PDUs, and provide the traffic associated with the MAC PDUs to UE205as PHY traffic, via the 4G RAT.

Similarly, 5G stack515may process the RLC PDUs (decapsulated at645) by decapsulating the RLC PDUs to yield MAC PDUs, and may output (at660) the MAC PDUs toward UE205(e.g., by outputting the MAC PDUs to 5G RE/RC212). 5G RE/RC212may decapsulate the MAC PDUs, and provide the traffic associated with the MAC PDUs to UE205as PHY traffic, via the 5G RAT.

FIG. 7illustrates example components of V-eNB215705, in an implementation in which the 4G RAT is the “master” RAT. In contrast with the example shown inFIG. 5, 5G stack710may process MAC PDUs up to the RLC layer, and provide RLC PDUs to 4G stack715for processing.

An example signal flow, which relates to the components shown inFIG. 7, is shown inFIG. 8. The signals shown in this figure are similar to those shown inFIG. 6, with the exception of the 4G RAT being the “master” RAT in this example. Thus, as shown, instead of 5G stack515constructing PDCP and GTP PDUs (in the uplink direction) and decapsualting GTP and PDCP PDUs (in the downlink direction), 4G stack715may perform these operations in the example ofFIG. 8.

FIGS. 9 and 10illustrate alternate implementations ofFIGS. 5 and 7, respectively. The example components shown inFIGS. 9 and 10may be useful in implementations where PDUs of the 4G and 5G protocol stacks are not interoperable (e.g., where 5G stack515is not able to encapsulate or decapsulate PDUs destined for or received from 4G stack510, or where 4G stack715is not able to encapsulate or decapsulate PDUs destined for or received from 5G stack710).

InFIG. 9, V-eNB215905may include the components of V-eNB215505, with the addition of 4G-5G transcoder910. 4G-5G transcoder910may transcode RLC PDUs, received from 4G stack510, into a format that is decipherable by 5G stack515(e.g., may transcode RLC PDUs, according to 4G standards, into RLC and/or PDCP PDUs according to 5G standards). V-eNB215905may also transcode PDCP and/or RLC PDUs, received from 5G stack515, into a format that is decipherable by 4G stack510(e.g., may transcode PDCP and/or RLC PDUs, according to 5G standards, into RLC and/or PDCP PDUs according to 4G standards).

InFIG. 10, V-eNB2151005may include the components of V-eNB215705, with the addition of 4G-5G transcoder1010. 4G-5G transcoder1010may transcode RLC PDUs, received from 5G stack710, into a format that is decipherable by 4G stack715(e.g., may transcode RLC PDUs, according to 5G standards, into RLC and/or PDCP PDUs according to 4G standards). V-eNB2151005may also transcode PDCP and/or RLC PDUs, received from 4G stack715, into a format that is decipherable by 5G stack710(e.g., may transcode PDCP and/or RLC PDUs, according to 4G standards, into RLC and/or PDCP PDUs according to 5G standards).

FIG. 11illustrates example components of V-eNB2151105, in accordance with some implementations. In the example shown inFIG. 11, 4G stack1110and 5G stack1115may process traffic separately (i.e., without interacting with each other). Thus, in this example, 4G stack1110and 5G stack1115may each have distinct GTP tunnels established to VGW315(i.e., 4G stack1110may have established a first GTP tunnel to VGW315, while 5G stack1115has established a second GTP tunnel to VGW315).

In some implementations, UE205may simultaneously connect to both 4G and 5G RATs (e.g., to 4G RE/RC210and 5G RE/RC212), and may send and/or receive traffic simultaneously to and/or from both 4G RE/RC210and 5G RE/RC212. In some implementations, traffic for the same application may be sent over both RATs. For instance, in the uplink direction, UE205may send a portion of the traffic for a particular application via 4G RE/RC210, and may send another portion of the traffic for the same application via 5G RE/RC212. Similarly, in the downlink direction, traffic for a particular application may be sent to UE205via both 4G RE/RC210and 5G RE/RC212. For instance, VGW315may split the traffic for a particular application into two portions, and may send a first portion of the traffic via 4G RE/RC210(e.g., via 4G stack1110), and may send another portion of the traffic for the same application to UE205via 5G RE/RC212(e.g., via 5G stack1115). The multiple portions of the traffic may be processed and re-sequenced at UE205before being processed by the application layer of UE205. In some implementations, the different portions of the traffic may be sent via respective “Best Effort” bearers (i.e., a “Best Effort” bearer on the 4G RAT, and another “Best Effort” bearer on the 5G RAT).

FIG. 12illustrates example signals that may occur with respect to the components shown inFIG. 12. As shown, one or more 5G bearers may be set up (at1205) for the UE. The 5G bearer setup process may include establishing bearers and/or other communication pathways between UE205and 5G RE/RC212, between 5G RE/RC212and 5G stack1115, and 5G stack1115and VGW315(e.g., one or more GTP tunnels between 5G stack1115and VGW315). Additionally, one or more 4G bearers may be set up (at1210) for the UE. The 4G bearer setup process may include establishing bearers and/or other communication pathways between UE205and 4G RE/RC210, between 4G RE/RC210and 4G stack1110, and 4G stack1110and VGW315(e.g., one or more GTP tunnels between 4G stack1110and VGW315).

FIG. 13is a diagram of example components of device1300. One or more of the devices described above may include one or more devices1300. Device1300may include bus1310, processor1320, memory1330, input component1340, output component1350, and communication interface1360. In another implementation, device1300may include additional, fewer, different, or differently arranged components.

Bus1310may include one or more communication paths that permit communication among the components of device1300. Processor1320may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory1330may include any type of dynamic storage device that may store information and instructions for execution by processor1320, and/or any type of non-volatile storage device that may store information for use by processor1320.

Input component1340may include a mechanism that permits an operator to input information to device1300, such as a keyboard, a keypad, a button, a switch, etc. Output component1350may include a mechanism that outputs information to the operator, such as a display, a speaker, one or more light emitting diodes (“LEDs”), etc.

Communication interface1360may include any transceiver-like mechanism that enables device1300to communicate with other devices and/or systems. For example, communication interface1360may include an Ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface1360may include a wireless communication device, such as an infrared (“IR”) receiver, a Bluetooth® radio, or the like. The wireless communication device may be coupled to an external device, such as a remote control, a wireless keyboard, a mobile telephone, etc. In some embodiments, device1300may include more than one communication interface1360. For instance, device1300may include an optical interface and an Ethernet interface.

For instance, while some examples were described above in the context of a VGW315, similar concepts may be practiced with a conventional SGW220and/or MME222(albeit without the benefits of a VGW, which can include scalability and more efficient use of resources, thus resulting in reduced costs). Additionally, while concepts were described above in the context of 4G and 5G RATs, similar concepts can be used with other types of RATs. For instance, the term “5G,” as used herein, may more broadly refer to “next generation” standards (e.g., standards that have been introduced after the 4G standard). Thus, in figures and descriptions that include the term “5G,” other terms that describe other standards and/or protocols may be substituted without departing from the spirit of the invention.

As another example, while series of signals have been described with regard toFIGS. 6, 8, and12, the order of the signals may be modified in other implementations. Further, non-dependent signals may be performed in parallel. Additionally, whileFIGS. 6, 8, and 12have been described in the context of particular devices performing particular acts, in practice, one or more other devices may perform some or all of these acts in lieu of, or in addition to, the above-mentioned devices.