Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
VOIP AND NATIVE CARRIER CALL INTEGRATION
Cross-Reference to Related Applications
[0001] This application is a continuation-in-part of, and claims the benefit
of an earlier filing
date under 35 U.S.C. 120 based on, U.S. Patent App. No. 16/736,380, having
attorney
docket no. PWS-71819U504, filed January 7, 2020, and entitled "VoIP and Native
Carrier
Call Integration", which itself is a continuation of, and claims the benefit
of an earlier filing
date under 35 U.S.C. 120 based on, U.S. Patent App. No. 15/706,663, having
attorney
docket no. PWS-71819U502, filed September 15, 2017, and entitled "VoIP and
Native
Carrier Call Integration", which itself is a continuation-in-part of, and
claims priority under 35
U.S.C. 120 to, U.S. Pat. App. No. 15/678,104, titled "S2 Proxy for Multi-
Architecture
Virtualization" and filed on August 15, 2017, itself a non-provisional
conversion of, and
claiming priority under 35 U.S.C. 119(e) to, U.S. Provisional Pat. App. No.
62/375,341 and
U.S. Provisional Pat. App. No. 62/395,354, both titled "VoIP and Native
Carrier Call
Integration" and filed on August 15, 2016 and September 15, 2016,
respectively, each hereby
incorporated by reference in its entirety for all purposes. This application
is also a non-
provisional conversion of and claiming priority under 35 U.S.C. 119(e) to
U.S. Provisional
Pat, App. No. 63/023,236 titled "HetNet Gateway Software for Network Builds"
filed on
May 11, 2020 and incorporated by reference in its entirety for all purposes
The present
application also hereby incorporates by reference for all purposes U.S. Pat.
No. 8,879,416,
"Heterogeneous Mesh Network and Multi-RAT Node Used Therein," filed May 8,
2013; U.S.
Pat. No. 9,113,352, "Heterogeneous Self-Organizing Network for Access and
Backhaul,"
filed September 12, 2013; U.S. Pat. App. No. 15/464,333, "IuGW Architecture,"
filed March
20, 2017; U.S. Pat. App. No. 14/642,544, "Federated X2 Gateway," filed on
March 9, 2015;
U.S. Pat. App. No. 14/936,267, "Self-Calibrating and Self-Adjusting Network,"
filed on
November 9, 2015; U.S. Pat. App. No. 14/806,594, "Signaling Storm Reduction
from Radio
Networks," filed July 22, 2015; U.S. Pat. App. No. 14/822,839, "Congestion and
Overload
Reduction," filed August 10, 2015; and U.S. Pat. App. No. 61/724,312, "Method
of
optimizing Paging over LTE radio," filed November 9, 2012. In addition, IETF
RFC 3261,
1
Date Recue/Date Received 2022-05-10
"SIP: Session Initiation Protocol," dated 2002, is also hereby incorporated by
reference in its
entirety for all purpose
[0002] The present application also hereby incorporates by reference for all
purposes U.S.
Pat. No. 8,879,416, "Heterogeneous Mesh Network and Multi-RAT Node Used
Therein,"
filed May 8, 2013; U.S. Pat. No. 9,113,352, "Heterogeneous Self-Organizing
Network for
Access and Backhaul," filed September 12, 2013; U.S. Pat. App. No. 15/464,333,
"IuGW
Architecture," filed March 20, 2017; U.S. Pat. App. No. 14/642,544, "Federated
X2
Gateway," filed on March 9, 2015; U.S. Pat. App. No. 14/936,267, "Self-
Calibrating and Self-
Adjusting Network," filed on November 9, 2015; U.S. Pat. App. No. 14/806,594,
"Signaling
Storm Reduction from Radio Networks," filed July 22, 2015; U.S. Pat. App. No.
14/822,839,
"Congestion and Overload Reduction," filed August 10, 2015; and U.S. Pat. App.
No.
61/724,312, "Method of optimizing Paging over LTE radio," filed November 9,
2012. In
addition, IETF RFC 3261, "SIP: Session Initiation Protocol," dated 2002, is
also hereby
incorporated by reference in its entirety for all purpose
Background
[0003] In many environments, it is important to support voice calling,
including in networks
where Long Term Evolution (LTE) is deployed. However, LTE does not support
voice calling
over legacy networks, instead providing voice capability via its own standard,
Voice over
LTE (VoLTE). There is consequently a need for compatibility with legacy voice
calling,
including circuit-switched (CS) voice calling, that is currently met
imperfectly, typically by
providing both a 2G/3G core network and a parallel LTE core network. As both
networks
have cumulative maintenance and operational expense (opex) requirements, the
new network
is significantly more expensive.
[0004] As well, with the requirement that wireless operators support all
generations of radio
technologies, and the expense of maintaining 2G, 3G, 4G and upcoming 5G
infrastructures,
operators have desired to transition their core infrastructure to remove
legacy components and
converge to a single IP core. This will help them move to all IP, an all-
virtualized core
network infrastructure and reduce not only capital expenditures (capex) but
also operational
expenditures (opex) significantly.
2
Date Recue/Date Received 2022-05-10
Summary
[0005] Systems and methods are disclosed for a network convergence gateway
providing
VoIP and native call integration.
[0006] In one embodiment, a method is disclosed, comprising: receiving, at a
switch in a
mobile operator network, an incoming call for a mobile device; querying a
convergence
gateway from the soft switch via an application programming interface (API) at
the
convergence gateway to determine whether the mobile device is currently
engaged in a voice
over IP (VoIP) call using a VoIP calling software application on the mobile
device; delivering
the incoming call via the soft switch over IP as a VoIP call to the VoIP
calling software
application on the mobile device.
[0007] The method may further comprise providing call waiting, call hold, call
swap, or call
joining at the mobile device using the VoIP calling software application. The
method may
further comprise delivering a second incoming call via a mobile operator
network as a native
call to the mobile device, and providing call waiting, call hold, call swap,
or call joining at the
mobile device using operator network-assisted native call functions. The
method may further
comprise performing evaluation of the incoming call using a number portability
database to
determine whether the incoming call is able to be rerouted to a soft switch;
and routing the
incoming call to the soft switch. The convergence gateway may be situated in
an operator
network as a gateway between a plurality of base stations and a network
switching subsystem
in a 2G, 3G, or 4G LTE network. The API may be enabled to be accessed by the
VoIP calling
software application on the mobile device for handling VoIP calls and for
determining a
current call state of the mobile device. The API may be enabled to be accessed
by an operator
core network for handling native calls and for determining a current call
state of the mobile
device.
[0008] In another embodiment, a non-transitory computer-readable medium is
disclosed,
comprising instructions which, when executed on a processor at a gateway,
cause the gateway
to perform steps comprising: receiving a request to deliver an incoming call;
determining
whether a mobile device is currently engaged on a Voice over IP (VoIP) call
using a VoIP
application on the mobile device; delivering the incoming call via a mobile
switching station
3
Date Recue/Date Received 2022-05-10
in a mobile operator network as a native telephone call to the mobile device,
if the mobile
device is not currently engaged on a VoIP call; delivering the incoming call
as a second VoIP
call via the VoIP application, if the mobile device is currently engaged on a
VoIP call.
[0009] The steps may further comprise providing call waiting, call hold, call
swap, or call
joining at the mobile device using the VoIP calling software application. The
steps may
further comprise delivering a second incoming call via a mobile operator
network as a native
call to the mobile device, and providing call waiting, call hold, call swap,
or call joining at the
mobile device using operator network-assisted native call functions. The steps
may further
comprise performing evaluation of the incoming call using a number portability
database to
determine whether the incoming call is able to be rerouted to a soft switch;
and routing the
incoming call to the soft switch. The convergence gateway may be situated in
an operator
network as a gateway between a plurality of base stations and a network
switching subsystem
in a 2G, 3G, 4G LTE. Or 5G network. The API may be enabled to be accessed by
the VoIP
calling software application on the mobile device for handling VoIP calls and
for determining
a current call state of the mobile device. The API may be enabled to be
accessed by an
operator core network for handling native calls and for determining a current
call state of the
mobile device.
[0010] In another embodiment a method for providing local breakout is
described. The
method includes identifying data within a network requiring latency reduction,
wherein the
network is at least one of a 4G network or 5G network; and routing the data
requiring latency
reduction to a destination from a source bypassing a cellular core network
gateway as an
intermediate node.
Brief Description of the Drawings
[0011] FIG. 1 depicts a prior art core network architecture.
[0012] FIG. 2 is a network architecture diagram showing integration of Wi-Fi
into an LTE
core network, in accordance with some embodiments.
4
Date Recue/Date Received 2022-05-10
[0013] FIG. 3 is a network architecture diagram showing a first phase of
introduction of a
convergence gateway into a wireless operator network, in accordance with some
embodiments.
[0014] FIG. 4 is a network architecture diagram showing a second phase of
introduction of a
convergence gateway into a wireless operator network, in accordance with some
embodiments.
[0015] FIG. 5 is a network architecture diagram showing a third phase of
introduction of a
convergence gateway into a wireless operator network, in accordance with some
embodiments.
[0016] FIG. 6 is a network architecture diagram showing a fourth phase of
introduction of a
convergence gateway into a wireless operator network, in accordance with some
embodiments.
[0017] FIG. 7 is a network architecture diagram showing providing applications
(apps) for
machine-to-machine (M2M) applications, smaiiphones, femto cells, access points
(APs), etc.,
in accordance with some embodiments.
[0018] FIG. 8 is a network architecture diagram showing a block diagram of a
convergence
gateway, in accordance with some embodiments.
[0019] FIG. 9 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having IuCS/IuPS and
Si
interfaces toward a core network, in accordance with some embodiments.
[0020] FIG. 10 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having IuCS and local
breakout
interfaces toward a core network, in accordance with some embodiments.
[0021] FIG. 11 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having IuCS, Si, and
local
breakout interfaces toward a core network, in accordance with some
embodiments.
Date Recue/Date Received 2022-05-10
[0022] FIG. 12 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having Si and local
breakout
interfaces toward a core network, in accordance with some embodiments.
[0023] FIG. 13 is a network architecture diagram showing a first delivery of a
call using a soft
switch, in accordance with some embodiments.
[0024] FIG. 14 is a network architecture diagram showing a second delivery of
a call using a
soft switch, in accordance with some embodiments.
[0025] FIG. 15 is a diagram showing am all G platform 1500 enabling agility,
in accordance
with some embodiments.
[0026] FIG. 16 is a diagram showing a platform having an all IP network on RAN
side, and a
reduced number of interfaces for core, in accordance with some embodiments.
[0027] FIG. 17 is a diagram showing LTE traffic optimization with Local
Breakout, in
accordance with some embodiments.
[0028] FIG. 18 is a diagram showing LTE/5G traffic optimization with Local
Breakout, in
accordance with some embodiments.
[0029] FIG. 19 is a diagram of a multiple core network, in accordance with
some
embodiments.
[0030] FIG. 20 is a network diagram, in accordance with some embodiments.
[0031] FIG. 21 is an enhanced eNodeB, in accordance with some embodiments.
Detailed Description
[0032] In currently-available systems, multiple radio access technologies are
supported by the
use of separate infrastructure for each radio access technology. For example,
LTE eNodeBs
are supported by MMEs, SGWs, PGWs, etc., and UMTS nodeBs are supported by
SGSNs,
GGSNs, MSCs etc., with little or no functionality shared between core network
nodes. FIG. 1
shows the current architecture.
6
Date Recue/Date Received 2022-05-10
[0033] Reducing complexity by eliminating one or more network nodes in the
core network
has been difficult due to differences in functional divisions in the various
RATs, as well as the
difficulty in building and supporting backwards compatibility layers for each
RAT. When
interworking is required between each pair of RATs, development becomes
expensive. Even
when companies have attempted to build combination nodes, integration is
expensive because
supporting the superset of features on a given RAT (e.g., authentication,
circuit switching,
legacy protocol interworking) is difficult and expensive.
[0034] For example, an Si interworking proxy node may be placed between an LTE
eNodeB
and an LTE core network (MME, SGW, PGW); an Iuh interworking proxy may be
placed
between a 3G nodeB and a 3G core network (SGSN, GGSN); an IuCS interworking
proxy
may be placed between a 3G nodeB and a 3G MSC; a circuit-switched media
gateway may be
placed between a 2G BTS and a 2G core network (SGSN and MSC); a Wi-Fi gateway
according to the 3GPP spec could be placed between a Wi-Fi user device and a
PGW; and so
on. However, a multiplicity of devices is required to support all scenarios,
leading to
increased expense in operation of the core network.
[0035] Additionally, network operators are typically unwilling to decommission
core network
equipment that has been well-tested and continues to operate well. For
example, this is the
case for 2G and 3G legacy voice equipment, which provides voice call quality
superior in
many cases to VoLTE, which is not widely deployed. Elimination of these legacy
network
nodes is additionally difficult as a result.
[0036] Thus, although LTE hypothetically has the ability to unify all network
protocols in an
IP-only system, few or no LTE core network nodes exist today that can support
all of the
functions that are supported by the core network nodes of the UMTS network.
[0037] Various approaches are provided herein that provides connectivity and
mobility to
users using any of a plurality of radio access technologies, including LTE/LTE-
A/LTE-U, 3G
(UMTS), 3G (CDMA), 2G and 2.5G (EDGE), and Wi-Fi within a single architecture.
In some
embodiments a system is described wherein one or more RATs may be supported
using a
single front-end plugin for each RAT supporting a subset of RAT features, and
without
requiring support to be built out for all RAT features. In some embodiments
support can be
7
Date Recue/Date Received 2022-05-10
rolled out in sequential stages, for example, for network operators that have
existing
investments in infrastructure.
[0038] In some embodiments, a convergence gateway is enabled to interwork
other radio
access network interfaces with Si or Iu, thereby providing connectivity to the
RAN toward
the core network and vital core network nodes such as authentication and
mobility nodes. To
the core network, a call or packet data session appears as an LTE call or
bearer. To the user
device, the call or session appears as a native RAT call/session, whether it
is 2G, 3G, CDMA,
or Wi-Fi.
[0039] The S2 interface (52a, 52b) is an important interface for enabling the
system described
herein. S2, as described in 3GPP TS 23.402 and TR 23.852 (each hereby
incorporated by
reference in their entirety), is an interface for enabling wireless access
gateways to permit
mobile devices on non-3GPP networks to join 3GPP networks. Specifically, the
S2 interface
was designed to enable Wi-Fi and other IEEE networks to expose control
functionality as well
as data routing functionality, and to enable 3GPP networks to interoperate
with eHRPD and
CDMA networks, such as WiMAX and WCDMA networks, and interworking them to a
3GPP PGW gateway. Authentication and call anchoring is passed through the S2
interface
and performed using the 3GPP network. In some embodiments the convergence
proxy does
not use S2 interface and uses local breakout or for data traffic while
interworking the
signaling messages with legacy components such as MSC and SGSN.
[0040] An additional important interface for enabling the system described
herein is the Si
interface. While the Si-AP interface is used for providing signaling support
for LTE
eNodeBs, the Si-U interface is a tunneling interface suitable for tunneling IP
data through to
an LTE core network. Re-encapsulating packets received over another packet
session, such as
EDGE, Gb, IuPS, etc. into a GTP-U tunnel over the Si-U interface enables the
Si interface to
be used for multiple RATs.
[0041] A third important building block of the solution described herein is
the use of local
breakout techniques for handling IP traffic. Other than voice calls connected
over a circuit-
switched protocol, the majority of traffic on wireless operator networks at
this time travels
over the operator network to a gateway, such as an LTE packet data network
gateway (PGW),
8
Date Recue/Date Received 2022-05-10
which then provides access to the Internet. This includes VoIP, web (HTTP),
and other user-
driven IP traffic. Certain IP traffic terminates within a mobile operator
network and not on the
public Internet, such as voice calls performed over VoLTE within the same
operator's
network; however, such calls may also be made by routing an IP session out to
the public
Internet and back to the operator's own network (e.g., hairpin routing).
[0042] Local breakout also is desirable sine in most or all deployments, the
wireless base
station has some backhaul that enables it to connect to an operator core
network using
underlying IP backhaul connectivity to the global Internet. The inventors have
appreciated,
and the embodiments described herein show, that it is possible to simplify the
operator core
network by directing most connections to traverse the Internet via this
backhaul connection
instead of using designated 2G, 3G, or 4G nodes within a core network to
provide service.
This technique, sometimes also called "local breakout," Selective IP traffic
offload (SIPTO),
or local IP access (LIPA) when used to refer to the use of non-operator-
controlled IP
networks, particularly by small cells, is enhanced and expanded upon to
provide additional
functionality in this disclosure.
[0043] Fourthly, as described above, many operators already have 3G core
networks in place.
In some embodiments, a simple approach is taken to retain compatibility with
3G voice calls
at minimal expense. Instead of replacing the 3G core network completely, an
existing 3G core
network is left in place and pared down to the minimum of required components.
By reusing
and inexpensively maintaining the existing 3G core, compatibility is
maintained with 3G
technology, at no additional cost relative to the present day, without
requiring the expense of
purchasing new devices to replace the 3G core.
[0044] Otherwise, if an operator core network is a "greenfield" network, where
3G core
networks have not been provisioned or built out, the core network can be built
to support
voice calling without a 3G core network and only with an IMS network, to
provide voice over
IP (VOIP)/VoLTE voice calling. This core network architecture enables the use
of an all-IP
network without legacy 3G circuit-switched calling.
[0045] FIG. 1 depicts a prior art core network architecture. On the left side
of the diagram,
four radio access technologies (RATs) are depicted, namely: 2G (otherwise
known as
9
Date Recue/Date Received 2022-05-10
GERAN), 3G (otherwise known as UTRAN), 4G (LTE or EUTRAN), and Wi-Fi access.
The
RATs correspond to different wireless access technologies supported by
wireless clients, such
as 3GPP user equipments (UEs) and Wi-Fi-equipped computers and mobile devices.
In the
middle of the diagram, each of the RATs has a corresponding core network that
handles
functions that include mobility management (e.g., handovers) and radio access
coordination.
[0046] FIG. 1 is a schematic network architecture diagram for 3G and other-G
prior art
networks. The diagram shows a plurality of "Gs," including 2G, 3G, 4G, and Wi-
Fi. 2G is
represented by GERAN 101, which includes a 2G device 101a, BTS 101b, and BSC
101c. 3G
is represented by UTRAN 102, which includes a 3G UE 102a, nodeB 102b, RNC
102c, and
femto gateway (FGW, which in 3GPP namespace is also known as a Home nodeB
Gateway
or HNBGW) 102d. 4G is represented by EUTRAN or E-RAN 103, which includes an
LTE
UE 103a and LTE eNodeB 103b. Wi-Fi is represented by Wi-Fi access network 104,
which
includes a trusted Wi-Fi access point 104c and an untrusted Wi-Fi access point
104d. The Wi-
Fi devices 104a and 104b may access either AP 104c or 104d. In the current
network
architecture, each "G" has a core network. 2G circuit core network 105
includes a 2G
MSC/VLR; 2G/3G packet core network 106 includes an SGSN/GGSN (for EDGE or UMTS
packet traffic); 3G circuit core 107 includes a 3G MSC/VLR; 4G circuit core
108 includes an
evolved packet core (EPC); and in some embodiments the Wi-Fi access network
may be
connected via an ePDG/TTG using S2a/S2b. Each of these nodes are connected via
a number
of different protocols and interfaces, as shown, to other, non-"G"-specific
network nodes,
such as the SCP 110, the SMSC 111, PCRF 112, HLR/HSS 113, Authentication,
Authorization, and Accounting server (AAA) 114, and IP Multimedia Subsystem
(IMS) 115.
An HeMS/AAA 116 is present in some cases for use by the 3G UTRAN. The diagram
is used
to indicate schematically the basic functions of each network as known to one
of skill in the
art, and is not intended to be exhaustive.
[0047] Noteworthy is that the RANs 101, 102, 103, 104 rely on specialized core
networks
105, 106, 107, 108, 109, but share essential management databases 110, 111,
112, 113, 114,
115. More specifically, for the 2G GERAN, a BSC 101c is required for Abis
compatibility
with BTS 101b, while for the 3G UTRAN, an RNC 102c is required for Iub
compatibility and
an FGW 102d is required for Iuh compatibility. These core network functions
are separate
Date Recue/Date Received 2022-05-10
because each RAT uses different methods and techniques. On the right side of
the diagram are
disparate functions that are shared by each of the separate RAT core networks.
These shared
functions include, e.g., PCRF policy functions, AAA authentication functions,
and the like.
Letters on the lines indicate well-defined interfaces and protocols for
communication between
the identified nodes.
[0048] While the core network architecture as shown is effective, it is
expensive to maintain
and unnecessarily duplicates infrastructure. Conceptually only two main
functions are
provided to users: voice calls and packetized data. However, each RAT requires
a different
core network to be put in place to handle the same function. In the case of
3G, two core
networks are put into place, one to handle circuit-based calls and one to
handle packet-based
calls and data. Wi-Fi is also not effectively integrated into the network.
Additionally, no
synergies are realized between the networks, as each operates independently of
the others,
even though many of them operate on the same IP-based underlying network. Not
shown are
the expensive air conditioning, power conditioning, property leasing
agreements, and other
physical plant expenses required to maintain each of these duplicate core
networks.
[0049] An approach is described for combining each of the core networks into a
minimal core
network suitable for providing radio access to user devices that support LTE
and beyond,
while providing legacy support for other RATs. Each legacy RAT may be
supported at the
RAN level, but the core network for each RAT may be replaced by a single
converged core
network. To provide data service, the converged core network shall use the LTE
framework,
and shall use IP. To provide voice service, the converged core network shall
use either a 3G
circuit core network infrastructure (MSC, VLR) or a packet-based LTE
infrastructure such as
VoLTE. Interworking shall be provided to enable legacy core network nodes to
be removed
from the network.
[0050] The described approach has the advantage that several functions
previously separated
among several disparate core networks may be reunited into a single core
network node, here
called the convergence proxy/gateway. This enables network operators to
perform
optimizations across several RATs. As well, the convergence proxy may be built
with modern
hardware and software virtualization techniques that enable it to be scaled up
and down as
11
Date Recue/Date Received 2022-05-10
needed within the network to meet needs on any of the supported RATs, thereby
enabling
network expansion and virtualization. This architecture thus paves the way for
increased
numbers of connected nodes (e.g., for Internet of Things (IoT)), and for the
increased
bandwidth and densification as projected to be required by 5G.
[0051] The described approach also enables increased intelligence to be pushed
to the edge of
the network. When combined with the virtualization technology described in
U.S. Pat. Pub.
No. 20140133456 (PWS-71700US03), hereby incorporated by reference in its
entirety for all
purposes, which allows a virtualization gateway to act as a proxy to enable a
large radio
access network to be subdivided into independently managed sections,
intelligence may be
added in a large scale way to a large, heterogeneous radio access network by
pushing the
required intelligence out from the expensive to maintain core network to
virtualization/convergence nodes situated one hop away from the edge of the
network. This
architecture allows new services to be provided, such as: content delivery
caching, scaling,
and optimization; data offload for local voice or local data breakout;
specialized APIs for
smartphone apps; VoIP and VoWiFi integration; within network free calling
without using
expensive international or long distance circuits or trunks; femto cell
integration; machine-to-
machine applications; integration of private enterprise RANs with the core
network; core
network sharing; and other services, each of which could provide an additional
revenue
stream.
[0052] A detailed explanation of how each RAT will be supported follows.
[0053] In some embodiments, 2G services may be provided by enabling a standard
base
station, or BTS, to connect to the convergence gateway directly via a standard
BTS-MSC
interface, the A interface. Software and hardware to enable 2G base stations
according to the
Global System for Mobile Communications (GSM) are readily available, including
base
station software to enable radio baseband functions and to handle interactions
with a 2G GSM
handset, such as the open source OpenBTS project. Such BTS software is often
configured to
use the A interface over an IP protocol backhaul link, and many operators have
migrated their
networks to run on IP and use a modified version of the A interface over IP
links (A-over-IP).
12
Date Recue/Date Received 2022-05-10
The convergence gateway may be configured with the appropriate A interface
compatibility
to enable it to interoperate with such BTSes from multiple vendors.
[0054] In some embodiments, the convergence gateway operates as a back-to-back
user agent
(B2BUA) or BTS/MSC proxy between a BTS and the 2G/3G MSC core network node,
virtualizing the BTSes from the MSC and the MSC from the BTSes. The existing
legacy
2G/3G MSC is able to handle circuit-switched calls, SS7 calls, and other types
of calls that
are difficult to simulate or interwork in the modern IP-based environment.
This mode of
operation does utilize an existing 2G/3G MSC core network node. However, as
mentioned
above, it is advantageous to be able to leverage the existing 2G/3G
infrastructure to provide a
solution that "just works" and preserves legacy compatibility without
introducing additional
cost.
[0055] In some embodiments the convergence gateway may use the Iuh interface,
not the A
interface, to enable an enhanced 2G base station or combined 2G/3G base
station to
communicate with it. Iuh is the interface used according to certain UMTS
standards for
communication over an IP link between a femto cell and a femto cell gateway,
otherwise
known as a home nodeB gateway, including nodeB registration (e.g., HNBAP) as
well as
control and user data messages (e.g., RANAP); Iuh supports transport of IuPS
and IuCS user
data flows, as well as signaling flows, and is therefore suitable for handling
2G calls. The base
station in this case could be responsible for interworking between the A
interface (or the Um
interface) and the Iuh interface. The enhanced 2G base station could operate
as a small cell as
described below in relation to 3G services. The convergence gateway may use
Iuh to provide
signaling capability to the base stations.
[0056] In some embodiments, 3G services may be provided using a convergence
gateway that
is configured to act as a standard RNC, SGSN, and GGSN in relation to standard
nodeB base
stations. The base stations may communicate to the convergence gateway via the
IuPS and
IuCS interfaces. The convergence gateway may be configured to act as a B2BUA
and proxy
for the nodeBs toward communicating with a 3G MSC/VLR. The convergence gateway
may
be configured to virtualize the nodeB toward the core network. Alternately the
convergence
gateway may provide RNC, SGSN, and/or GGSN functions internally as software
modules.
13
Date Recue/Date Received 2022-05-10
[0057] In some embodiments, 3G services may be provided using a nodeB in
communication
with the convergence gateway via the Iuh interface, as described above. The
nodeB may be
configured to act as a small cell according to the standard femto cell
specifications, and the
convergence gateway may treat the 3G nodeB as a standard 3G home nodeB.
[0058] IuCS interface communications may be proxied by the convergence gateway
toward a
3G circuit core network node, the 3G MSC/VLR. Iuh and IuPS interface
communications
may be handled in several different ways: forwarding Iuh circuit-switched
communications to
an existing 3G core, interworking of IuPS to LTE or directly to IP, such as
for local breakout,
or terminating IuPS communications at the convergence gateway and providing
the
underlying IP packet data services via an underlying IP backhaul connection at
the
convergence gateway (e.g., local IP breakout). Each of the inbound service
requests that is a
request for IP is handled via interworking, and service requests for circuit
connections are
handled by forwarding to the 3G core. It is noted that voice calls in the
present architecture
are often provided using RTP and packet-based MSC nodes, and as such, the
convergence
gateway may make use of RTP that is encoded by the BTS or nodeB to provide 3G
voice
services. The use of RTP and IP provides advantages for both 3G and 4G
services as
described hereinbelow.
[0059] Additional functions may be provided by the convergence gateway in
conjunction
with 3G service, in some embodiments. In some embodiments, RTP streams that
originate
and terminate within a single RAN, or within a single sub-network managed by
the
convergence gateway, may be redirected at the convergence gateway back toward
the RAN
instead of unnecessarily traversing the core network; this is known as RTP
localization. RTP
streams are typically used by many 3G nodeBs to encode and transport voice
calls over IP. In
order to provide RTP localization in this fashion, no change in signaling on
the control plane
is required, and network address translation may be sufficient in many cases
to provide this
functionality for the data packets themselves.
[0060] In some embodiments, handover optimization and paging optimization may
be
performed, to reduce signaling and load due to handovers or paging on the core
network. The
term optimization here and throughout this disclosure is used only to mean
enhancement or
14
Date Recue/Date Received 2022-05-10
improvement, not to mean identification of a single best method. Handovers
within the same
RAN or sub-network managed by the convergence gateway may be performed without
interaction with the core network. Paging may be reduced by keeping track of
UEs within the
RAN or sub-network. Further detail about paging and handover optimizations may
be found
in U.S. Pat. App. Nos. 14/806594, 14/822839, and 61/724312, each hereby
incorporated by
reference in their entirety.
[0061] In some embodiments, data traffic may be redirected away from the 3G
core network
to the Internet. According to the conventional UMTS architecture, packet-
switched (PS)
UMTS bearers are GTP-U tunnels for data that is intended to go to or from the
public Internet
are terminated on one end at the UE and at the other end at a core network
gateway, such as a
GGSN that provides connectivity to other networks, such as the public
Internet. In the
conventional UMTS architecture, the GGSN extracts an IP payload from the GTP-U
tunnel
and sends it over the Internet. By contrast, in the present disclosure, the
convergence gateway
may identify that certain traffic is intended for the public Internet or for
other connected
networks, and may perform the de-encapsulation function previously performed
by the
GGSN, thereby eliminating the need for the GGSN to perform this function.
[0062] In some embodiments, SGSN functionality may be performed at the
convergence
gateway. For example, the SGSN in the conventional UMTS architecture is
responsible for
tracking UEs as they have mobility across different nodeBs. A convergence
gateway
according to the present disclosure is capable of tracking UEs within its
managed sub-network
of RANs, and may perform mobility management so that when data or calls come
in from the
core network or from the public Internet, the convergence gateway may direct
the inbound
traffic to the appropriate RAN directly. Each RAN being connected via IP to
the convergence
gateway, the convergence gateway can perform this tracking by IP address and
can perform
network address translation to ensure the core network has a single IP address
for the UE at
any particular time.
[0063] In some embodiments, the convergence gateway may interface with a
conventional
radio network controller (RNC) as a virtual MSC. The convergence gateway may
use the
standard IuCS and IuPS interfaces to communicate with the RNC, for example, to
allow the
Date Recue/Date Received 2022-05-10
RNC to interoperate with a conventional macro cell or nodeB. This enables the
convergence
gateway to provide 3G services to conventional nodeBs without having to
emulate or reverse
engineer any proprietary Tub interface, as that communication is performed by
the RNC. In
some embodiments the convergence gateway may use an Iur interface to
communicate with
conventional RNCs as a virtual RNC. In this case convergence gateway acts as a
IuCS and
IuPS proxy towards 3G MSC and 3G SGSN respectively. In some case convergence
gateway
may simply act as IuCS proxy while doing local breakout of data traffic.
[0064] 4G LTE services may be provided as follows. Several possible
embodiments are
contemplated. In the conventional LTE architecture, voice call services are
provided either as
3G voice (circuit-switched fallback or CSFB) or as data. Initial LTE
deployments did not
have a capability for native voice calls over LTE, and voice over LTE (VoLTE)
is currently in
the process of being deployed. VoLTE uses a data infrastructure known as IP
Multimedia
Subsystem (IMS) to provide signaling support, and uses data-based protocols
such as SIP and
RTP to provide voice data transport. According to conventional VoLTE, an LTE
UE is
attached to an LTE network and registered with an IMS core network, which then
provides
the ability to call other phone numbers. In the present disclosure voice calls
can either be
interworked to 3G CS calls or delivered using a VoLTE IMS core network; each
approach has
different advantages.
[0065] An LTE eNodeB is provided that is in communication with a UE. The
eNodeB is also
in communication with a convergence gateway, which may enable virtualization
of the
eNodeB and other eNodeBs by virtue of the convergence gateway acting as a
B2BUA and
proxy toward the LTE core network, as described elsewhere herein. When a UE
attempts to
connect and register with the LTE and IMS core networks, the convergence
gateway
establishes a data bearer for the UE with the core network, but instead of
registering via IMS,
performs a registration of the UE as a 3G client with the 3G MSC/VLR. The UE
and the
eNodeB receive confirmation that the UE is permitted to use both the LTE and
IMS core
networks. Next, when the UE initiates a call according to a conventional VoLTE
protocol, the
UE sends the appropriate SIP protocol messages toward the core network, which
are
interworked by the convergence gateway into 3G messages for the 3G MSC, e.g.,
SIP to IuCS
interworking. Once the call is connected, the UE will send RTP data packets
carrying voice
16
Date Recue/Date Received 2022-05-10
data to the convergence gateway, which will then forward them to the
aforementioned 3G
RTP and IP-based MSC. This allows for transparent interworking of 4G LTE VoLTE
calls to
3G calls without the need for an IMS core.
[0066] In some embodiments, the convergence gateway may enable integration of
VoIP calls
with ordinary cellular voice calls. Carriers want to provide mobile App to
offer value added
services along with VoIP calling. Typically VoIP apps are not tightly coupled
with mobile
OS, but are instead pushed to the background when mobile phone receives a
phone call,
which can create unwanted results (e.g., termination of the VoIP call) when
VoIP apps are in
middle of phone calls. It is desired to coordinate native mobile calls with
mobile apps to
improve the user experience.
[0067] In some embodiments, IN triggers are used to provide integration. IN
Triggers are a
well-known way of creating triggers to enable intelligent services. See
Reference
(http://www.3g4g.co.uk/Tutorial/ZG/zgcamel.html). While they work well for
popular IN
services e.g. Number Portability, 800 number lookup etc., they are difficult
and very
expensive for new & innovative services due to the old/unsupported nature of
this technology.
[0068] In some embodiments, a Number Portability Trigger may be used. This
approach
assumes a SIP soft switch that handles VoIP app calling. Normal SIP related
call features are
assumed i.e. active registration status, active call status, SIP call forking
etc. LRN (Local
Routing Number) in the number portability database is registered for the VoIP
app users.
LRN resides on SIP Soft Switch. In case of actual ported number, Soft Switch
needs to take
care of final LRN. The soft switch is provided at the convergence gateway, in
some
embodiments.
[0069] In some embodiments, a call flow using a Next hop soft switch provided
at the
convergence gateway is detailed. This approach assumes a SIP soft switch that
handles VoIP
app calling. Normal SIP related call features are assumed i.e. active
registration status, active
call status, SIP call forking etc. All calls before going to MSC are routed
via Soft Switch
(using numbering plan/ routing tables). Soft Switch decides if it should
deliver call to the App
via VoIP or native dialer via MSC.
17
Date Recue/Date Received 2022-05-10
[0070] In some embodiments, a further call flow using a convergence gateway is
detailed,
based on idea to use the convergence gateway as a virtual decentralized core.
This is a call
flow using a next-hop soft switch. The convergence gateway is configured to
enable an API
for VoIP app to leverage and achieve similar result, i.e. get trigger for
incoming calls and
many other innovative services e.g. location based trigger. This convergence
gateway based
solution allows a user or operator to bypass long distance/international
carriers (among
subscribers) by local breakout for even native dialer calls.
[0071] In some embodiments, a mobile OS native dialer is integrated with a
VoIP dialer,
streamlining the UI to improve presentation of the problem, and treating VoIP
calls as equal
to native calls for, e.g., phonebook presentation for outgoing calls and
incoming call
identification, hold and merge.
[0072] In some embodiments, a convergence gateway API may be made available to
reroute
ordinary circuit-switched (CS) calls. This API may be configured and exposed
at the
convergence gateway, and may be accessed using a specially configured phone or
using an
app on a smaiiphone. This may reroute existing CS calls from the smartphone to
directly
connect to other nodes that are accessible on the network, creating a peer-to-
peer or local
network topology, and avoiding a "hairpinning" route topology that goes out to
a gateway and
back into the same local network.
[0073] This also allows for non-VoLTE voice calls to be handled in a similar
manner,
transparent to the UE. For example, mobile apps such as Skype [TM], WhatsApp
[TM], and
other applications installed on handsets may be treated as peers and may be
given the ability
to make calls through the 3G MSC. However, handling of native voice calls and
VoIP calls is
currently limited. For example, In Apple's iOS 10, the dialer app has been
reworked so that a
VoIP call can be made from the phone's native address book. See
http://www.noj Ater. com/post/240171745/apple-reinvents-m obile-uc,
incorporated by
reference in its entirety. Google Android offers native dialer integration by
the applications as
well. However, while these approaches may help streamline the UI, this still
does not fix the
issue of native mobile call suspending the VoIP calls.
18
Date Recue/Date Received 2022-05-10
[0074] In some embodiments, a user may be on a VoIP app call. The user's
mobile device
may be equipped to perform call management functions. such as call waiting,
swap, or hold,
for native phone calls delivered via a 2G/3G/4G or other cellular network
(also identified
herein as standard phone calls, legacy phone calls, circuit-switched phone
calls, or SS7-
compatible phone calls). In certain cases, the user's mobile device may also
be equipped to
enable the VoIP app to perform call management functions for VoIP app calls,
so that the
mobile device is able to provide, for example, call waiting, swap, or hold for
VoIP app calls.
However, the user's mobile device typically is not configured to provide call
waiting, etc. if a
VoIP call is interrupted by a native phone call, or if a native phone call is
interrupted by a
VoIP call or app call. These functions can be made possible to be performed by
the following
method.
[0075] In some embodiments, a convergence gateway may be in the flow of a call
currently in
progress with the mobile device. The convergence gateway may determine what
kind of call
is in progress. For example, the convergence gateway may decrypt a GTP-U
tunnel or
otherwise de-encapsulate a tunnel, may intercept or proxy Si or other operator
signaling or
SIP/RTP signaling, or may perform other types of packet
inspection/characterization or
inspection of data inside a tunnel. Many other examples may be known in the
art of ways to
determine whether, at a gateway node, a call is currently in progress
according to VoIP, RTP,
CS, SIP, or another protocol. The convergence gateway may use this state to
enable the API
functionality described below.
[0076] Special application programming interfaces (APIs) or triggers may be
used to enable
special treatment of such calls, with some embodiments thereto described
below. The API
may be used to: request handover from a special VoIP protocol to a non-VoIP
legacy
connection; request information regarding whether a specific call is a VoIP
call or a non-VoIP
call; request information regarding information such as originating party or
IP address or
underlying protocol; request features such as call forwarding, call hold,
multi-way calling,
etc., or SIP functions such as active registration status, active call status,
call forking to be
enabled on a VoIP call; request transcoding or transrating of a VoIP call;
provide
authentication credentials for a VoIP call device requesting to be handed over
or connected to
a legacy connection; and other functions.
19
Date Recue/Date Received 2022-05-10
[0077] The API may be enabled for access at the convergence gateway by network
nodes in
the operator core network such as a soft switch or number portability
database, or by native
call infrastructure such as a MSC or circuit-switched core network node. The
API may
provide an interface via HTTP, XML/SOAP, or another protocol, over an IP
transport or
another transport. The API may be enabled for and/or accessed by a UE app, in
some
embodiments, or by a server in communication with a UE app (e.g., a Skype or
Apple
FaceTime server), or both.
[0078] The API may provide operator network support or UE app support for one
or more
call support functions, such as, for example, call waiting, call hold, call
swap, or call joining.
The API may cause the convergence gateway to perform one or more SIP functions
or other
call management functions. The convergence gateway may be a SIP endpoint or
back-to-back
user agent (B2BUA) or SIP proxy for SIP calls, which may include both native
calls delivered
using SIP and VoIP SIP calls.
[0079] In operation, when a call is initiated by a VoIP app, the VoIP app may
inquire (either
from the UE app itself or from a server component of the app) with a
convergence gateway
using the API as part of initial call setup whether a call should be completed
via a native
dialer call or a VoIP protocol. The VoIP app may indicate whether it prefers
to terminate the
call via VoIP or via native call. The convergence gateway may take the
requests and
parameters in the request into account, as well as other information
pertaining to the UE, such
as whether the UE is currently in the middle of a VoIP call or a native dialer
call, or whether
the UE is currently available or unavailable for circuit-switched calls, and
may return
information to the VoIP app regarding call termination. The VoIP app may then
be permitted
to complete the call. The same procedure could be performed by a gateway
making native
calls. In either situation, the convergence gateway may transcode or transrate
a call from VoIP
to native, or vice versa, as appropriate to enable an app to deliver calls
over native, and vice
versa, even when the app does not have this capability built in.
[0080] In some embodiments, the convergence gateway could go further and
enable direct
connection/termination of calls, regardless of whether the call is a VoIP call
or native call,
where the source and destination of the call are within a certain local
network domain, thus
Date Recue/Date Received 2022-05-10
avoiding undesirable hairpin routing (e.g., traffic that is routed out of a
network and
immediately is routed back into the originating network). RTP localization is
another term
that refers to this functionality or similar functionality, which could be
enabled using the API
at the convergence gateway.
[0081] In some embodiments the dialing app may also determine whether the
native dialer
has integration built in for VoIP apps, such as the Apple iPhone dialer for
Apple iOS 10 and
up, and may allow the UE to choose its own app to terminate the call to the
user.
[0082] Traditional SIP-based virtual call routing systems like Google Voice
permit the use of
SIP call forking, etc. to terminate calls at a plurality of devices. However,
the present
disclosure differs from SIP-based call routing systems such as Google Voice
[TM], for
example, at least in that it takes into account whether a call is currently
ongoing, whether the
call is a VoIP or native dialer call, and provides ways for a mobile network
operator and/or
mobile device to terminate a call at a mobile device in the most appropriate
or effective
format. The present disclosure also describes performing interworking,
transcoding, etc. at,
e.g., a convergence gateway to enable this functionality for a wide variety of
terminal devices
and mobile operator networks. The present disclosure also describes providing
an API at the
convergence gateway to enable control of this functionality.
[0083] The convergence gateway may be enabled to aggregate SCTP and Si-AP
toward the
core, in some embodiments, specifically for enabling a single MME to handle
all of the
subnetworks and eNodeBs under the convergence gateway. RTP and other IP
traffic may be
handled using the underlying IP backhaul connection (e.g., local breakout), in
some
embodiments, providing a reduction of data traffic towards the LTE SGW and
PGW. RTP
localization may also be provided. In some embodiments, signaling toward the
core, handover
optimization, paging optimization, and message retransmit reduction may be
performed by the
convergence gateway for subnetworks managed by the convergence gateway, as
described
elsewhere herein.
[0084] In some embodiments the convergence gateway may take over all of the
functions of
the MME, SGW, and PGW inside the LTE core network gateway. In such an
embodiment,
21
Date Recue/Date Received 2022-05-10
multiple convergence gateways may be used to cover a large geographic area,
such as a
country.
[0085] Additional functions are described for enabling Wi-Fi and small cell
interoperability
with the described convergence gateway. Wi-Fi and small cells may need to be
authenticated
before being able to connect to an operator core network, and in the
conventional art two
types of gateways, trusted wireless access gateways (TWAGs) and evolved packet
data
gateways (ePDGs) are known. The convergence gateway may be an ePDG, a TWAG, or
both,
in some embodiments, acting as an ePDG for untrusted Wi-Fi access points and
as a TWAG
for trusted Wi-Fi access points. S2 and S2x interfaces may be used to cause
packet flows to be
allowed entry into the LTE core network at the PGW, thus allowing Wi-Fi users
to access the
LTE core network. However, since 2G, 3G, and Wi-Fi are all processed as IP
packets in the
above scenario, S2 and S2x can be used to provide entry for sessions using
each of these
RATs into the LTE core network, thereby allowing a single LTE core network to
provide the
necessary core support for 2G, 3G, 4G LTE, and Wi-Fi. Enterprise femto
networks, private
LTE networks, and public safety networks can also be treated as LTE networks
using the
TWAG and S2/S2x approach, enabling the convergence gateway to act as a
virtualized hosted
small cell gateway. In some cases, a convergence gateway may do local breakout
of Wi-Fi
data and eliminate the need for PGW.
[0086] As 2G, 3G, 4G LTE, and Wi-Fi technologies as configured above are all
able to be
routed through a convergence gateway, opportunities arise for improving the
performance of
all the networks synergistically, such as by sharing resources or information
across RATs.
Self-organizing network (SON) capabilities may be leveraged across multiple
technologies.
For example, users can be moved to the least loaded access network by
combining visibility at
the convergence gateway across 3G, LTE, and Wi-Fi. Some additional techniques
that may be
used on the convergence gateway are described in U.S. Pat. Pub. 20140233412
and U.S. Pat.
Pub. No. U520160135132, each of which is incorporated by reference in its
entirety.
[0087] In some embodiments, within the convergence gateway, an access module
(frontend
module) is configured with a modular architecture. The access module supports
a stub module
for each access component. The access components depicted include: a HNB
access
22
Date Recue/Date Received 2022-05-10
component for 2G/3G packet-switched data and circuit-switched voice,
communicating with
one or more 2G/3G BTSes or nodeBs via Iuh; a HeNB access component for LTE
packet-
switched voice (VoLTE) and data, communicating to an eNodeB via Si; an ePDG
access
component for untrusted Wi-Fi access; and a SaMOG access component for trusted
Wi-Fi
access. Other access components may be added as well, in some embodiments.
[0088] The convergence gateway may have specific modules for: RTP-Iuh
interworking; 2G
data to LTE interworking via a 2G proxy; 3G data to LTE interworking via a 3G
proxy; IMS
to LTE interworking via an IMS proxy; 2G voice to 3G voice interworking via a
3G proxy;
VolP to 3G voice interworking via a 3G proxy; and inbound protocol switching
to bind each
of these RATs together.
[0089] Each of the access components provides stateless or minimally stateful
forwarding and
interworking of inputs from the one or more access networks to the core
network components
described below. Interworking may be done to a standard interface, such as S2
itself, or to a
non-standard interface abstracting a subset of the input interface for
communicating with the
core network.
[0090] Each access component may be connected to a 52x core component (52x
backend).
The 52x core component provides packet data services using one (or more) LTE
core
networks. The 52x core component performs interworking as necessary so that it
may output
on an S2 interface to its connection point in the LTE core network at the PGW.
The PGW
admits the packet flow from the convergence gateway as coming from another
trusted
network within the LTE core network, and permits access to, e.g., security
gateways and
authentication servers via packet data networks accessible from the PGW,
thereby enabling
user devices on non-LTE networks to use the LTE packet data connection.
[0091] The 52x core component and IuCS core component may be coupled together.
As all
RANs benefit from access to packet data, all front end access components are
coupled to the
52x core component. The 52x core component may perform minimal inspection of
inbound
data to determine if circuit-switched call processing is needed, for example,
using envelope
inspection or fingerprinting. When the 52x core component identifies a circuit-
switched call,
23
Date Recue/Date Received 2022-05-10
the S2 core component may pass the inbound data stream to the IuCS core
component. In
some embodiments, circuit-switched RANs may connect directly to the IuCS core
component.
[0092] Circuit-switched calls may be transported over IP and/or SCTP to the
convergence
gateway over an arbitrary physical medium. The convergence gateway may
communicate
using a BSSAP or RANAP interface to the 2G/3G cells, taking the place of
and/or emulating
a 2G/3G RNC in communicating with the 2G/3G RAN. Instead of communicating with
an
MSC, however, the convergence gateway may perform, encoding, encapsulation,
and
interworking of the circuit-switched calls before sending the calls to the LTE
core network.
For handling circuit-switched voice calls from a 2G/3G RAN, these functions
may be handled
by a circuit-switched component, the IuCS code component, not the S2x core
component. In
addition to the above interworking functions, the IuCS core component performs
proxying for
the 2G/3G RAN, hiding the complexity of the core network from the RAN and vice
versa, so
that any 2G/3G RAN will be able to interoperate with the LTE core network. Via
such
proxying, 2G/3G CS calls can be converted to SIP calls and handled the same as
VoLTE calls
by the LTE IMS core network. The Iu interface used for communicating with the
RAN is
standardized, and therefore the convergence gateway will be able to
interoperate with a RAN
from any vendor providing the standard interface. If a base station uses the
IuPS interface, the
convergence gateway may perform interworking from Iuh to IuPS, and perform
interworking
form IuPS to Si. In that way, 2G/3G/4G traffic can all be served in the
unified way by one
single 4G core.
[0093] In some embodiments, a transcoding gateway will not be needed. In some
cases, audio
for calls that originate from a 2G base station will be encoded in the half
rate or full rate GSM
codec. These codecs are also supported by 2.5G, 3G, and 4G handsets and base
stations, so if
one end of the call uses a codec that is not supported by the other, the IuCS
core component
can request a codec downgrade to a lowest common denominator codec. However,
it may be
possible for the IuCS core component to perform audio transcoding, in some
embodiments.
As well, the IuCS core component may perform IP-IP interworking of audio
before sending
the audio to the circuit-switched RAN or core.
24
Date Recue/Date Received 2022-05-10
[0094] As described above, from the radio network side, the convergence
gateway presents
itself as an SGSN (for packet-switched connectivity) and an RNC (for circuit-
switched
connectivity). At the core network, packet-switched calls may be handled as
though they were
VoLTE calls. This will be transparent to the core network, and will not
require resources
beyond what is required for support of VoLTE. 2G and 3G voice calls and
circuit-switched
calls may be handled by handing off to the existing 3G MSC core network node,
via the IuCS
interface.
[0095] Handovers between radio access networks managed by the convergence
gateway may
be hidden from the network. From the core network side, the calls pass through
the same
PGW, and no handover is needed. From the radio network side, the convergence
gateway acts
as an MME or RNC, and performs handover in a manner transparent to the radio
network.
Handovers for packet-switched calls and bearers may be performed internally
within the S2x
core module, and handovers for packet and circuit-switched calls may be
performed between
the S2x and IuCS core modules. In some embodiments, an ATCF module may be
present
between the S2x and IuCS core components to facilitate handover capability
between circuit
and packet-switched calls.
[0096] Wi-Fi local breakout and enterprise functionality may also be
supported, in some
embodiments. An enterprise gateway or PBX may present itself as an untrusted
Wi-Fi
gateway, and the convergence gateway may present itself as a ePDG to the
enterprise
gateway, including by using MSCHAPv2 authentication, while hiding complexity
to the core
network by connecting directly to the PGW. For unwanted data traffic, instead
of sending the
traffic to the operator's PGW, the convergence gateway may transparently
redirect the traffic
from the S2x core module to another network interface, thereby ejecting the
traffic from the
network.
[0097] The benefits of the above solution include the following. A network
operator may
install the convergence gateway and immediately enable voice calls over the
LTE core
network for one or more RANs. The operator may test the performance of the
rollout
gradually. The operator may, when satisfied with performance, completely
deactivate both the
3G packet core and the 2G/3G circuit core, thereby reducing power and
footprint
Date Recue/Date Received 2022-05-10
requirements for their core network infrastructure. Additionally, the LTE core
network itself
may be simplified, as the SGW and MME nodes themselves may be subsumed by the
convergence gateway. Additionally, the operator is also enabled to interwork
VoLTE or Wi-
Fi calls to 2G voice calls and deliver these calls over a standard 2G BTS.
[0098] Table 1 summarizes some characteristics of certain embodiments of a
convergence
gateway in accordance with FIG. 12.
RAT Signaling type HNG input HNG output signal
signal
2G Signaling A/IP or Gb/IP Interworking to VoLTE
or absorbed at local
GGSN/SGSN
Signaling (Iuh) Iuh IuCS to VoLTE and
IuPS to local breakout
or Si-U
Calls A/IP Interworking to VoLTE
Data Gb/IP Local breakout or Sl-U
3G Signaling Iuh Absorbed at local
SGSN/GGSN, or
interworking to VoLTE
and local breakout or
Sl-U
Calls IuCS Interworking to VoLTE
Data IuPS Local breakout or Sl-U
4G Signaling Si-AP Absorbed at local
MME, or Si-AP to 4G
core
Calls 51-U (VoLTE) Local breakout or
interworking to
VoLTE, IMS core via
Sl-U
26
Date Recue/Date Received 2022-05-10
Data Si-U Local breakout or
Si-U
Wi-Fi, etc. Signaling 52a/52b Absorbed at local
MME, or 52a/52b to
4G core, or local
breakout
Calls 52a/52b (VoLTE) 52a/52b to PGW to
IMS core, or local
breakout
Data 52a/52b 52a/52b to 4G core, or
local breakout
TABLE 1
[0099] In some embodiments, a phased approach could be used to introduce
convergence
gateway architecture to an operator's wireless network. Four proposed phases
are described
below.
[0100] In Phase 1, shown as FIG. 3, a wireless operator could introduce a
convergence
gateway into the network for LTE, for 3G, and for Wi-Fi, maintaining an
existing 3G packet
core and 3G circuit core, as well as 4G packet core/EPC. This architecture
provides
advantages for scalability of existing services. Additionally, it enables Wi-
Fi calling, as well
as 3G access, 4G access, and standards-compliant femto cells (original device
manufacturer,
or ODM, femtos) from a variety of manufacturers, and also provides the
convergence
gateway's virtualization, scalability, SON, and other advantages. Use of
enhanced nodeBs as
described herein can also permit all RAN traffic to be on IP, providing cost
savings.
[0101] In an alternative Phase 1 deployment, a wireless operator could
introduce a
convergence gateway into the network for LTE, with support for outdoor macro,
enhanced
multi-RAT base stations (such as the Parallel Wireless CWS [TM] base station),
and generic
femto cells (residential, enterprise); introduce a convergence gateway for 3G,
with Parallel
Wireless CWS, generic femto cells (residential, enterprise); and introduce a
convergence
gateway for Wi-Fi, enabling a VoWiFi calling offering and a carrier Wi-Fi
offering. Benefits
include: virtualizing the existing core and adding more capacity by offloading
signaling &
27
Date Recue/Date Received 2022-05-10
data; enabling Femto offerings; VoWiFi; SON & Inter cell Interference
coordination;
CAPEX/OPEX savings; and public transport Wi-Fi and small cells.
[0102] In phase 2, shown as FIG. 4, an operator may enable LTE local breakout
in the
convergence gateway, which reduces traffic towards PGW and thereby eliminates
the need to
scale it; call detail record (CDR) generation; legal intercept (LI)
integration; and may enable
3G data local breakout in the convergence gateway, which reduces traffic
towards GGSN
(eliminates the need to scale it); CDR generation; LI integration.
Virtualizing the data offload
frees up (or eliminates) PGW, SGSN, and enables the following functions: Femto
offerings
with local breakout; Low latency traffic to the internet (including cached
video); Private LTE
network; and CAPEX/OPEX savings.
[0103] In Phase 3, shown as FIG. 5, an operator may enable a virtual MSC on
the
convergence gateway for existing 3G Macros. This enables RTP localization;
enables
optimized HO; eliminates need for MSC, SGSN, GGSN scaling. This also provides
the
following feature advantages: SON; API Enablement; smaiiphone apps; IOT/M2M;
Femto
support. Virtualizing the MSC adds more capacity in the network by offloading
the existing
MSC. An app framework for innovative smartphone applications may be enabled.
This phase
also enables: RTP localization; optimized handover; and eliminates the need
for MSC, SGSN,
GGSN scaling; New revenue streams from apps and CAPEX/OPEX savings may also
result.
[0104] In phase 4, shown as FIG. 6, the convergence gateway absorbs MME and
SGSN
functionality. While the operator may continue to use circuit switched voice
MSC for voice
for legacy applications (including non-VoLTE), the operator may enable mobile
edge
computing (MEC) for exotic applications. This Simplified Virtualized Core
Network is
scalable on commodity hardware in a data center, and ready for 5G, with
significant CAPEX
and OPEX Savings, and on modern management interfaces.
[0105] FIG. 7 shows a conceptual architecture for providing apps for machine-
to-machine
(M2M) applications, smaiiphones, femto cells, APs, etc. Apps may be supported
using APIs
that are provided at the convergence gateway, with EMS/management aggregation
of the
smartphones and M2M clients being enabled via the apps and the convergence
gateway using
an element management system (EMS) accessing records and data collected at the
28
Date Recue/Date Received 2022-05-10
convergence gateway. The convergence gateway may use an Si-flex interface or
another
interface to interact with a wireless network.
[0106] FIG. 8 is a network architecture diagram showing a block diagram of a
convergence
gateway, in accordance with some embodiments. Signaling coordinator 800
includes
processor 802 and memory 804, which are configured to provide the functions
described
herein. Also present are radio access network coordination/signaling (RAN
Coordination and
signaling) module 806, RAN proxying module 808, and routing virtualization
module 810.
[0107] RAN coordination module 806 may include database 806a, which may store
associated UE signal quality parameters and location information as described
herein. In some
embodiments, SON coordinator server 800 may coordinate multiple RANs using
coordination
module 806. If multiple RANs are coordinated, database 806a may include
information from
UEs on each of the multiple RANs.
[0108] In some embodiments, the coordination server may also provide proxying,
routing
virtualization and RAN virtualization, via modules 810 and 808. In some
embodiments, a
downstream network interface 812 is provided for interfacing with the RANs,
which may be a
radio interface (e.g., LTE), and an upstream network interface 814 is provided
for interfacing
with the core network, which may be either a radio interface (e.g., LTE) or a
wired interface
(e.g., Ethernet). Signaling storm reduction functions may be performed in
module 806.
[0109] SON coordinator 800 includes local evolved packet core (EPC) module
820, for
authenticating users, storing and caching priority profile information, and
performing other
EPC-dependent functions when no backhaul link is available. Local EPC 820 may
include
local HSS 822, local MME 824, local SGW 826, and local PGW 828, as well as
other
modules. Local EPC 820 may incorporate these modules as software modules,
processes, or
containers. Local EPC 820 may alternatively incorporate these modules as a
small number of
monolithic software processes. Modules 806, 808, 810 and local EPC 820 may
each run on
processor 802 or on another processor, or may be located within another
device.
[0110] FIG. 9 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having IuCS/IuPS and
Si
interfaces toward a 3G and 4G-capable core network, in accordance with some
embodiments.
29
Date Recue/Date Received 2022-05-10
CWS 900 is a Parallel Wireless enhanced base station, with 2G RAT 901
including BTS and
BSC, as well as Iuh interworking; 3G RAT nodeB 902, with Iuh as well; and a 4G
eNodeB
903. CWS 900 is in communication with HNG 904, which is a Parallel Wireless
convergence
gateway, over four interfaces: 2G Iuh; 3G Iuh; S1-AP/S1-U for 4G; and a SON
interface.
101111 HNG 904 includes 2G interworking module 905, 3G interworking module
906, and Iu
proxy module 907. 2G interworking module 905 takes Iuh and interworks it to
IuCS and
IuPS. Similarly, 3G interworking module 906 takes Iuh and interworks it to
IuCS and IuPS.
Once converted to IuCS or IuPS, IuCS/IuPS proxy 907 acts as a proxy for
communications
with a 3G core network, which natively supports IuCS/IuPS, over IuCS/IuPS
interface 910.
[0112] As well, HNG 904 is in communication with a standard 2G or 3G base
station, shown
as 911 2G BTS/BSC or 3G RNC. This communication is over IuCS/IuPS and not over
Iuh;
however, IuPS and IuCS are able to be handled by HNG 904 and can be proxied
over to the
3G core network via interface 910.
[0113] HNG 904 also includes 4G gateway 908 and multi-RAT SON module 909. The
4G
gateway simply provides a proxy and gateway for the 4G eNodeB 903 to S 1-AP/S1-
U
interface 911, which connects natively to the 4G EPC. The SON module performs
SON
functionality as described herein, which generally includes looking at load
statistics and
changing thresholds; looking at all data being collected, including subscriber
information and
call state information; analytics; intelligent decisions; and proactive, as
well as reactive
action. The SON module is connected to all RATs, all proxies, and all core
networks, and can
use that information to provide multi-RAT SON functionality.
[0114] FIG. 10 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having IuCS and local
breakout
interfaces toward a core network, in accordance with some embodiments. Similar
to FIG. 9,
multi-RAT CWS 1000 includes 2G BTS/BSC 1001, which has its own built-in Iuh
interworking; 3G NodeB with Iuh 1002; and 4G eNodeB 1003. Similar to FIG. 9,
2G Iuh, 3G
Iuh, 51, and SON are the four inbound interfaces to HNG 1004. However, HNG
1004 has two
outbound interfaces: an IuCS interface 1011, toward a 3G core network, and a
data local
Date Recue/Date Received 2022-05-10
breakout interface 1012, directly facing the Internet. This architecture is
suitable when a
network operator is using a public network for backhaul, for instance.
[0115] A 2G Iuh-IuCS/IuPS proxy 1005 and a 3G Iuh-IuCS/IuPS proxy 1006 may be
provided, as well as an IuCS proxy, an IuPS proxy, and an IuPS local breakout
module 1007.
[0116] Since IuCS is available, 2G and 3G circuit-switched calls are
interworked to IuCS, and
they are sent out over IuCS interface 1011. However, since IuPS is not
available and Si is not
available, all data connections, including Si-U and IuPS, are interworked to
GTP-U tunnels
or bare IP packets and are sent out over data local breakout interface 1012.
[0117] In some embodiments, an MME and an SGSN function are built into the HNG
1004 to
absorb these communications before they are sent to the core network, thereby
reducing
demand for signaling data. A SON module 1010 is also provided.
[0118] FIG. 11 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having IuCS, Si, and
local
breakout interfaces toward a core network, in accordance with some
embodiments. Similar to
FIG. 9, multi-RAT CWS 1100 includes 2G BTS/BSC 1101, which has its own built-
in Iuh
interworking; 3G NodeB with Iuh 1102; and 4G eNodeB 1103. Similar to FIG. 9,
2G Iuh, 3G
Iuh, Si, and SON are the four inbound interfaces to HNG 1104. However, HNG
1104 has
three outbound interfaces: an IuCS interface 1111, toward a 3G core network,
an Si-U
interface 1113, toward a 4G core network, and a data local breakout interface
1112, directly
facing the Internet. This configuration is suitable when backhaul directly to
a 4G core network
is available.
[0119] HNG 1104 also includes, in addition to interworking modules 1105, 1106,
1107 and
SON module 1110, additional MME/SGSN/GGSN functions 1108 and SIP to IuCS
interworking 1109. SIP interworking enables VOLTE and VOIP to be interworked
to 3G and
completed over IuCS interface 1111.
[0120] FIG. 12 is a network architecture diagram showing a block diagram of a
multi-RAT
node and a convergence gateway, the convergence gateway having Si and local
breakout
interfaces toward a core network, in accordance with some embodiments. CWS
1200 is
31
Date Recue/Date Received 2022-05-10
similar to CWS 1100. Base station 1210 is a 2G BTS/BSC or 3G RNC, and uses
either
IuCS/IuPS, A over IP/Gb over IP, or both, to connect to HNG 1204. HNG 1204 has
two
outbound connections: Si connection 1211 and data local breakout 1212. HNG
1204 does not
have a circuit-switched outbound connection; this configuration does not
require a 3G core
network and uses IMS to complete all calls. As a result, A/IP and IuCS must be
interworked
to VoLTE using an interworking proxy. This interworking proxy may require
transcoding.
[0121] FIG. 13 is a network architecture diagram showing a first delivery of a
call using a soft
switch, in accordance with some embodiments. In some embodiments, a call for a
mobile
device 1313 is received 1312 at switch 1311, which may be an N-1 All Call
Query switch in a
mobile operator network. Switch 1311 may check (1308) with a number
portability database
1305 to help determine how to route the call. If the call can be routed via a
soft switch 1303,
for example because the mobile device 1313 is in an area handled by the soft
switch, the call
is routed (1304) by switch 1311 to soft switch 1303 using the location routing
number of the
soft switch. In some embodiments a mobile app call may be routed through
switch 1311, for
example, a mobile app call placed to a telephone number via SIP. In some
embodiments
switch 1311 may be configured to permit VoIP calls to be placed directly to it
over the
Internet. In some embodiments, VoIP over-the-top (e.g., IP) calls may be
directed directly to
soft switch 1303 without going through switch 1311. Soft switch 1303 may be a
next hop soft
switch.
[0122] In some embodiments, at the soft switch 1303, additional processing is
performed to
determine, for example, whether the user is in an active app call or in an
active native call.
This may be done by querying an API at a convergence gateway. The convergence
gateway is
located at the soft switch, in some embodiments, and is situated between a
radio access
network and a core network. The convergence gateway may be able to de-
encapsulate or look
inside tunnels, including secured tunnels, and may use this ability to
determine call status, in
some embodiments. In other embodiments a simple semaphore or metadata
signaling may be
used at the convergence gateway when a call is started and stopped either by
an app or by the
native dialer, allowing this information to be provided via the API to soft
switch 1303.
32
Date Recue/Date Received 2022-05-10
[0123] In some embodiments, based on the determination at the soft switch or
the
convergence gateway, the soft switch may route the call. In the case that the
mobile device is
in the middle of an app call, the call may be delivered as a VoIP call (1302).
In the case that
the mobile device is in the middle of a native call (1307), the call may be
delivered as a native
call (1309) via MSC 1306. This enables VoIP calls to be delivered to the VoIP
app, and native
calls to be delivered to the native app, and call holding and other call
management functions
to be performed when the mobile device is in the midst of another call.
[0124] In some embodiments, native calls may also be delivered directly from
switch 1311 to
MSC 1306. In some embodiments the MSC may access the API at soft switch
1303/at the
convergence gateway and may route calls back through soft switch 1303 (not
shown) to be
completed via VoIP.
[0125] FIG. 14 is a network architecture diagram showing a second delivery of
a call using a
soft switch, in accordance with some embodiments. This approach assumes a SIP
soft switch
that handles VoIP app calling, but where all calls before going to MSC are
routed via the soft
switch (using a numbering plan or routing tables, etc.). The soft switch may,
in some
embodiments, determine whether the call should be delivered via app or native
dialer.
Incoming calls for user device 1408 are received at the soft switch 1403,
which is also the
location of a convergence gateway, in some embodiments, or may be located at a
different
device from the convergence gateway. In some embodiments all incoming calls
are MSC calls
(e.g., native calls) (shown as 1404). The soft switch determines whether the
user is in an
active app call, using an API call to the convergence gateway or using other
means as
described herein. If the user is not in an active app call (1405), the call
may be delivered as a
normal call via MSC 1406, which requires no interworking or transcoding. The
normal call is
then delivered to the macro by the MSC 1407. Alternatively, in some
embodiments, if the
user is in the middle of a native app call, the call may be delivered as a
VoIP call (1402), over
a data bearer or other data tunnel; this path would not lead through the MSC.
The soft switch
1403 as shown here is able to receive native calls and transcode them as
appropriate to VoIP
calls and vice versa.
33
Date Recue/Date Received 2022-05-10
[0126] In some embodiments, with reference to at least FIGS. 13-14, the soft
switch may
optionally invoke SIP call forking, by, for example, calling the VoIP app
first followed by an
MSC call, or vice versa, or calling a number of devices in succession using
different SIP
destination addresses, including both VoIP and MSC call endpoints. In some
embodiments
the soft switch may support multiple apps, including desktop computer apps,
and may ring
them using call forking. In some embodiments, call waiting, call hold, call
merge, call swap,
and other functions may be enabled for VoIP calls by muting, merging,
transcoding, etc. as
necessary at the soft switch. In some embodiments, the call management
functions may be
performed at the soft switch for a combination of VoIP and native calls, or
may be assisted at
the soft switch therefor.
[0127] In some embodiments, VoIP calls may interact with native calls and vice
versa. This
may be via a call merge, and may be performed at the soft switch, or the
convergence
gateway, or at the mobile device. In some embodiments VoWiFi, VoLTE,
private/enterprise
3G/LTE deployments, or other types of calls could be handled as a peer to the
VoIP and
native calls described herein, and could be permitted to also interact and
have the benefit of
management functions.
[0128] In some embodiments, the API described herein could be used to permit
an operator or
VoIP app provider to provide in-network free calling without the cost or
burden of expensive
trunks or circuits, or hairpin routing, or international/long distance.
[0129] In some embodiments the API described herein may turn on and off any
combination
of features at the soft switch or convergence gateway. For example, a mobile
operator may
enforce, using the API, conversion of all calls to native dialer calls or VoIP
calls. As another
example, a UE can enforce the same type of conversion. As another example, a
base station in
the network may determine, based on relative load or usage of resources in the
radio access
network for packet-switched and circuit-switched connections, whether VoIP or
native calls
would be preferred, and may use this API to cause call termination using PS or
CS as most
appropriate (for example, terminating calls as CS calls when backhaul data
throughput is near
capacity).
34
Date Recue/Date Received 2022-05-10
[0130] In some embodiments, the functionality provided at the soft switch
and/or the
convergence gateway may be controlled on a per-user basis, or on a per-network
basis, or
based on a variety of other parameters or factors. Profiles and configuration
files may be
managed locally or remotely.
[0131] The soft switch may support RADIUS AAA, REDIRECT & ENUM Server Support,
NAT Traversal & Topology Hiding, Media Monitor (Disconnect Call on No Media),
Caller-
Carrier PTIME isolation, Auto Inband, Outband DTMF over IP, Digit Manipulation
&
Number Translation, Least Cost & Profit based Routing, LRN & MNP based
Routing, Source
& Destination based Routing, Prefix & Percentage based Routing, Preferred &
Gateway
based Routing, Route Capacity [Channels/CPS] Routing, Destination based
Rating, Pulse
Customization, Date & Time based Rates Upload, CSV and Excel File Support,
E,164 and
E,212 Format Support, Wholesale Tariff Management, Blocking & Unblocking of
Destinations, Hierarchy based Billing, Re-Rating, Individual Credit Limits for
every
Endpoint, Lower Balance Mail Alert, Billing Cycle with Setup & Rental Fee,
Free Calling for
a Certain Amount, Free Minutes (Overall or Certain Destinations Only), Special
Rates after
Free Minutes, Metered usage charges, Percentage or Flat Fee based Surcharges &
Taxes, IVR,
Web & SMS Interfaces, System connects Destination and Origination Numbers and
charges
the Subscriber, Caller ID or Name based on Caller, Origination Gateway or
Termination
Gateway, Caller ID Block, Anonymous Call Block, Call Hold, Music on Hold, Call
Waiting,
Absent Subscriber & DND, Call Return [Last Number Redial], Call Forward [Every
time,
Busy, No Answer & Number Not Available], Call Transfer [Attended &
Unattended], Find
Me - Follow Me, Simultaneous Ring, Call Pickup, Selective Outgoing Call
Barring, Selective
Incoming Call Block, Speed Dial, 3-Way-Calling (Device Feature), and other
functions
commonly supported by IP-based soft switches,
[0132] In some embodiments, the base stations described herein may be
compatible with a
Long Term Evolution (LTE) radio transmission interface or air interface. The
LTE-
compatible base stations may be eNodeBs. In addition to supporting the LTE
interface, the
base stations may also support other air interfaces, such as UMTS/HSPA,
CDMA/CDMA2000, GSM/EDGE, GPRS, EVDO, other 3G/2G, legacy TDD, or other air
interfaces used for mobile telephony. In some embodiments, the base stations
described
Date Recue/Date Received 2022-05-10
herein may support Wi-Fi air interfaces, which may include one of
802.11a/b/g/n/aciad/af/ah.
In some embodiments, the base stations described herein may support 802.16
(WiMAX), or
other air interfaces. In some embodiments, the base stations described herein
may provide
access to land mobile radio (LMR)-associated radio frequency bands. In some
embodiments,
the base stations described herein may also support more than one of the above
radio
frequency interfaces, and may also support transmit power adjustments for some
or all of the
radio frequency interfaces supported.
[0133] In some embodiments, the MSC described herein may be any mobile network
node
providing call switching, providing functions and having a different name as
appropriate for
2G, 3G, 4G, or future technologies. In some embodiments, the MSC may be a
multi-RAT-
capable MSC and may support more than one technology. In some embodiments, the
MSC
may be part of the soft switch and may natively handle VoIP call switching.
[0134] Although the present disclosure focuses on the use of SIP and RTP to
provide over-
the-top (OTT) calling functions, other protocols may also be used that operate
using a packet-
based protocol that is agnostic as to the network used for transport, e.g.,
VoWiFi, VoLTE, etc.
[0135] FIG. 15 is a diagram showing am all G platform 1500 enabling agility.
With an edge
centric architecture, the system is able to decouple core networks from RANS
by abstraction
core side to a virtualization letter to enable G unification. Smart
orchestration across all
network elements to provide best experience for end users in HetNet
environments. Self
configuration and self-optimization across ALL G.
[0136] FIG. 16 is a diagram showing a platform 1600 having an all IP network
on RAN side,
and a reduced number of interfaces for core.
[0137] FIG. 17 is a diagram showing LTE traffic optimization with Local
Breakout 1700.
Specific traffic can be offloaded locally (i.e.: voice, video). Significant
latency reduction for
offloaded traffic (LBO). With control and User Plane Separation (CUPS) LBO can
be done
closer to edge to reduce latency. Delay-sensitive flows can be prioritized.
Non sensitive
flows can be sent to centralized core. HetNet GW provides control,
optimization and an
embedded 4G core capabilities (EPC).
36
Date Recue/Date Received 2022-05-10
[0138] FIG. 18 is a diagram showing LTE/5G traffic optimization with Local
Breakout 1800,
in accordance with some embodiments. A mixed 4G/5G network is shown.
Integration of 4G
& 5G traffic with LBO, as well as single-G LTE traffic with LBO, is
contemplated. Latency
reduction for offloaded traffic (LBO), crucial for Low Latency 5G traffic, is
enabled using
LBO at the vRU and also at the HetNet GW, in some embodiments. A third party
EPC is
shown as enabling transport of traffic to the Internet. In some embodiments
the third party
EPC is also able to provide 4G core services. In some embodiments the 4G EPC
provides
non-standalone 5G RANs with access. The PW virtual radio unit (vRU) enables
local
breakout (LBO #1) to the Internet, in some embodiments through a core network
function
providing EPC-user plane (UP) and 5GC-user plane (UP) functionality. The vRU
can in some
embodiments provide a separate local breakout (LBO #2) through a core network
function
providing EPC-UP and 5GC-UP functionality, which may be connected through a
different
Internet backhaul or through a different network topology. Turning to the PW
HetNet GW,
the PW HetNet GW includes a virtual eNB function and an EPC control plane
function and a
5GC control plane function. The PW HetNet GW is also enabled, in some
embodiments, to
provide local breakout via one or more LBO points (for example, LBO #1 and LBO
#2). The
vRU and the HNG are able to redirect the traffic flexibly and as needed, for
example to meet
or provide a latency guarantee or to enable certain prioritized traffic to be
backhauled, in
some embodiments. Thus the PW solution allows for flexible location of User
Plane LBO
points anywhere in the network. Non-sensitive flows can be sent to centralized
core. HetNet
GW provides control, optimization and embedded 4G and 5G Core capabilities
(EPC &
5GC). In some embodiments and as shown in other figures, LBO functionality is
able to be
provided to RAN nodes of various RATs via the vRU and HNG as described
elsewhere
herein.
[0139] FIG. 19 is a diagram of a multiple core network 1900. The network
includes Any G ¨
Outdoor / Indoor Nodes. Neutral hosting for outdoor/indoor. Same HNG software
can
connect to multiple MMEs/SGW/PGW.
[0140] FIG. 20 is a network diagram in accordance with some embodiments. In
some
embodiments, as shown in FIG. 4, a mesh node 1 2001, a mesh node 2 2002, and a
mesh node
3 2003 are any G RAN nodes. Base stations 2001, 2002, and 2003 form a mesh
network
37
Date Recue/Date Received 2022-05-10
establishing mesh network links 2006, 2007, 2008, 2009, and 2010 with a base
station 2004.
The mesh network links are flexible and are used by the mesh nodes to route
traffic around
congestion within the mesh network as needed. The base station 2004 acts as
gateway node or
mesh gateway node, and provides backhaul connectivity to a core network to the
base stations
2001, 2002, and 2003 over backhaul link 2014 to a coordinating server(s) 2005
and towards
core network 2015. The Base stations 2001, 2002, 2003, 2004 may also provide
eNodeB,
NodeB, Wi-Fi Access Point, Femto Base Station etc. functionality, and may
support radio
access technologies such as 2G, 3G, 4G, 5G, Wi-Fi etc. The base stations 2001,
2002, 2003
may also be known as mesh network nodes 2001, 2002, 2003.
[0141] The coordinating servers 2005 are shown as two coordinating servers
2005a and
2005b. The coordinating servers 2005a and 2005b may be in load-sharing mode or
may be in
active-standby mode for high availability. The coordinating servers 2005 may
be located
between a radio access network (RAN) and the core network and may appear as
core network
to the base stations in a radio access network (RAN) and a single eNodeB to
the core network,
i.e., may provide virtualization of the base stations towards the core
network. As shown in
FIG. 20, various user equipments 2011a, 2011b, 2011c are connected to the base
station 2001.
The base station 2001 provides backhaul connectivity to the user equipments
2011a, 2011b,
and 2011c connected to it over mesh network links 2006, 2007, 2008, 2009, 2010
and 2014.
The user equipments may be mobile devices, mobile phones, personal digital
assistant (PDA),
tablet, laptop etc. The base station 2002 provides backhaul connection to user
equipments
2012a, 2012b, 2012c and the base station 2003 provides backhaul connection to
user
equipments 2013a, 2013b, and 2013c. The user equipments 2011a, 2011b, 2011c,
2012a,
2012b, 2012c, 2013a, 2013b, 2013c may support any radio access technology such
as 2G, 3G,
4G, 5G, Wi-Fi, WiMAX, LTE, LTE-Advanced etc. supported by the mesh network
base
stations, and may interwork these technologies to IP.
[0142] In some embodiments, depending on the user activity occurring at the
user equipments
2011a, 2011b, 2011c, 2012a, 2012b, 2012c, 2013a, 2013b, and 2013c, the uplink
2014 may
get congested under certain circumstances. As described above, to continue the
radio access
network running and providing services to the user equipments, the solution
requires
prioritizing or classifying the traffic based at the base stations 2001, 2002,
2003. The traffic
38
Date Recue/Date Received 2022-05-10
from the base stations 2001, 2002, and 2003 to the core network 2015 through
the
coordinating server 2005 flows through an IPSec tunnel terminated at the
coordinating server
2005. The mesh network nodes 2001, 2002, and 2003 adds IP Option header field
to the
outermost IP Header (i.e., not to the pre-encapsulated packets). The traffic
may from the base
station 2001 may follow any of the mesh network link path such as 2007, 2006-
110, 2006-
108-109 to reach to the mesh gateway node 2004, according to a mesh network
routing
protocol.
[0143] Although the above systems and methods for providing interference
mitigation are
described in reference to the Long Term Evolution (LTE) standard, one of skill
in the art
would understand that these systems and methods could be adapted for use with
other
wireless standards or versions thereof. The inventors have understood and
appreciated that the
present disclosure could be used in conjunction with various network
architectures and
technologies. Wherever a 4G technology is described, the inventors have
understood that
other RATs have similar equivalents, such as a gNodeB for 5G equivalent of
eNB. Wherever
an MME is described, the MME could be a 3G RNC or a 5G AMF/SMF. Additionally,
wherever an MME is described, any other node in the core network could be
managed in
much the same way or in an equivalent or analogous way, for example, multiple
connections
to 4G EPC PGWs or SGWs, or any other node for any other RAT, could be
periodically
evaluated for health and otherwise monitored, and the other aspects of the
present disclosure
could be made to apply, in a way that would be understood by one having skill
in the art.
[0144] Additionally, the inventors have understood and appreciated that it is
advantageous to
perform certain functions at a coordination server, such as the Parallel
Wireless HetNet
Gateway, which performs virtualization of the RAN towards the core and vice
versa, so that
the core functions may be statefully proxied through the coordination server
to enable the
RAN to have reduced complexity. Therefore, at least four scenarios are
described: (1) the
selection of an MME or core node at the base station; (2) the selection of an
MME or core
node at a coordinating server such as a virtual radio network controller
gateway (VRNCGW);
(3) the selection of an MME or core node at the base station that is connected
to a 5G-capable
core network (either a 5G core network in a 5G standalone configuration, or a
4G core
network in 5G non-standalone configuration); (4) the selection of an MME or
core node at a
39
Date Recue/Date Received 2022-05-10
coordinating server that is connected to a 5G-capable core network (either 5G
SA or NSA). In
some embodiments, the core network RAT is obscured or virtualized towards the
RAN such
that the coordination server and not the base station is performing the
functions described
herein, e.g., the health management functions, to ensure that the RAN is
always connected to
an appropriate core network node. Different protocols other than SlAP, or the
same protocol,
could be used, in some embodiments.
[0145] FIG. 21 is an enhanced eNodeB for performing the methods described
herein, in
accordance with some embodiments. Mesh network node 2100 may include processor
2102,
processor memory 2104 in communication with the processor, baseband processor
2106, and
baseband processor memory 2108 in communication with the baseband processor.
Mesh
network node 2100 may also include first radio transceiver 2112 and second
radio transceiver
2114, internal universal serial bus (USB) port 2116, and subscriber
information module card
(SIM card) 2118 coupled to USB port 2116. In some embodiments, the second
radio
transceiver 2114 itself may be coupled to USB port 2116, and communications
from the
baseband processor may be passed through USB port 2116. The second radio
transceiver may
be used for wirelessly backhauling eNodeB 2100.
[0146] Processor 2102 and baseband processor 2106 are in communication with
one another.
Processor 2102 may perform routing functions, and may determine if/when a
switch in
network configuration is needed. Baseband processor 2106 may generate and
receive radio
signals for both radio transceivers 2112 and 2114, based on instructions from
processor 2102.
In some embodiments, processors 2102 and 2106 may be on the same physical
logic board. In
other embodiments, they may be on separate logic boards.
[0147] Processor 2102 may identify the appropriate network configuration, and
may perform
routing of packets from one network interface to another accordingly.
Processor 2102 may
use memory 2104, in particular to store a routing table to be used for routing
packets.
Baseband processor 2106 may perform operations to generate the radio frequency
signals for
transmission or retransmission by both transceivers 2110 and 2112. Baseband
processor 2106
may also perform operations to decode signals received by transceivers 2112
and 2114.
Baseband processor 2106 may use memory 2108 to perform these tasks.
Date Recue/Date Received 2022-05-10
[0148] The first radio transceiver 2112 may be a radio transceiver capable of
providing LTE
eNodeB functionality, and may be capable of higher power and multi-channel
OFDMA. The
second radio transceiver 2114 may be a radio transceiver capable of providing
LTE UE
functionality. Both transceivers 2112 and 2114 may be capable of receiving and
transmitting
on one or more LTE bands. In some embodiments, either or both of transceivers
2112 and
2114 may be capable of providing both LTE eNodeB and LTE UE functionality.
Transceiver
2112 may be coupled to processor 2102 via a Peripheral Component Interconnect-
Express
(PCI-E) bus, and/or via a daughtercard. As transceiver 2114 is for providing
LTE UE
functionality, in effect emulating a user equipment, it may be connected via
the same or
different PCI-E bus, or by a USB bus, and may also be coupled to SIM card
2118. First
transceiver 2112 may be coupled to first radio frequency (RF) chain (filter,
amplifier,
antenna) 2122, and second transceiver 2114 may be coupled to second RF chain
(filter,
amplifier, antenna) 2124.
[0149] SIM card 2118 may provide information required for authenticating the
simulated UE
to the evolved packet core (EPC). When no access to an operator EPC is
available, a local
EPC may be used, or another local EPC on the network may be used. This
information may
be stored within the SIM card, and may include one or more of an international
mobile
equipment identity (IMEI), international mobile subscriber identity (IMSI), or
other parameter
needed to identify a UE. Special parameters may also be stored in the SIM card
or provided
by the processor during processing to identify to a target eNodeB that device
2100 is not an
ordinary UE but instead is a special UE for providing backhaul to device 2100.
[0150] Wired backhaul or wireless backhaul may be used. Wired backhaul may be
an
Ethernet-based backhaul (including Gigabit Ethernet), or a fiber-optic
backhaul connection, or
a cable-based backhaul connection, in some embodiments. Additionally, wireless
backhaul
may be provided in addition to wireless transceivers 2112 and 2114, which may
be Wi-Fi
802.11a/b/g/n/ac/ad/ah, Bluetooth, ZigBee, microwave (including line-of-sight
microwave),
or another wireless backhaul connection. Any of the wired and wireless
connections described
herein may be used flexibly for either access (providing a network connection
to UEs) or
backhaul (providing a mesh link or providing a link to a gateway or core
network), according
41
Date Recue/Date Received 2022-05-10
to identified network conditions and needs, and may be under the control of
processor 2102
for reconfiguration.
[0151] A GPS module 2130 may also be included, and may be in communication
with a GPS
antenna 2132 for providing GPS coordinates, as described herein. When mounted
in a vehicle,
the GPS antenna may be located on the exterior of the vehicle pointing upward,
for receiving
signals from overhead without being blocked by the bulk of the vehicle or the
skin of the
vehicle. Automatic neighbor relations (ANR) module 2132 may also be present
and may run
on processor 2102 or on another processor, or may be located within another
device,
according to the methods and procedures described herein.
[0152] Other elements and/or modules may also be included, such as a home
eNodeB, a local
gateway (LGW), a self-organizing network (SON) module, or another module.
Additional
radio amplifiers, radio transceivers and/or wired network connections may also
be included.
[0153] The protocols described herein have largely been adopted by the 3GPP as
a standard
for the upcoming 5G network technology as well, in particular for interfacing
with 4G/LTE
technology. For example, X2 is used in both 4G and 5G and is also complemented
by 5G-
specific standard protocols called Xn. Additionally, the 5G standard includes
two phases, non-
standalone (which will coexist with 4G devices and networks) and standalone,
and also
includes specifications for dual connectivity of UEs to both LTE and NR ("New
Radio") 5G
radio access networks. The inter-base station protocol between an LTE eNB and
a 5G gNB is
called Xx. The specifications of the Xn and Xx protocol are understood to be
known to those
of skill in the art and are hereby incorporated by reference dated as of the
priority date of this
application.
[0154] In some embodiments, several nodes in the 4G/LTE Evolved Packet Core
(EPC),
including mobility management entity (MME), MME/serving gateway (S-GW), and
MME/S-
GW are located in a core network. Where shown in the present disclosure it is
understood that
an MME/S-GW is representing any combination of nodes in a core network, of
whatever
generation technology, as appropriate. The present disclosure contemplates a
gateway node,
variously described as a gateway, HetNet Gateway, multi-RAT gateway, LTE
Access
Controller, radio access network controller, aggregating gateway, cloud
coordination server,
42
Date Recue/Date Received 2022-05-10
coordinating gateway, or coordination cloud, in a gateway role and position
between one or
more core networks (including multiple operator core networks and core
networks of
heterogeneous RATs) and the radio access network (RAN). This gateway node may
also
provide a gateway role for the X2 protocol or other protocols among a series
of base stations.
The gateway node may also be a security gateway, for example, a TWAG or ePDG.
The RAN
shown is for use at least with an evolved universal mobile telecommunications
system
terrestrial radio access network (E-UTRAN) for 4G/LTE, and for 5G, and with
any other
combination of RATs, and is shown with multiple included base stations, which
may be eNBs
or may include regular eNBs, femto cells, small cells, virtual cells,
virtualized cells (i.e., real
cells behind a virtualization gateway), or other cellular base stations,
including 3G base
stations and 5G base stations (gNBs), or base stations that provide multi-RAT
access in a
single device, depending on context.
[0155] In the present disclosure, the words "eNB," "eNodeB," and "gNodeB" are
used to refer
to a cellular base station. However, one of skill in the art would appreciate
that it would be
possible to provide the same functionality and services to other types of base
stations, as well
as any equivalents, such as Home eNodeBs. In some cases Wi-Fi may be provided
as a RAT,
either on its own or as a component of a cellular access network via a trusted
wireless access
gateway (TWAG), evolved packet data network gateway (ePDG) or other gateway,
which
may be the same as the coordinating gateway described hereinabove.
[0156] The word "X2" herein may be understood to include X2 or also Xn or Xx,
as
appropriate. The gateway described herein is understood to be able to be used
as a proxy,
gateway, B2BUA, interworking node, interoperability node, etc. as described
herein for and
between X2, Xn, and/or Xx, as appropriate, as well as for any other protocol
and/or any other
communications between an LTE eNB, a 5G gNB (either NR, standalone or non-
standalone).
The gateway described herein is understood to be suitable for providing a
stateful proxy that
models capabilities of dual connectivity-capable handsets for when such
handsets are
connected to any combination of eNBs and gNBs. The gateway described herein
may perform
stateful interworking for master cell group (MCG), secondary cell group (SCG),
other dual-
connectivity scenarios, or single-connectivity scenarios.
43
Date Recue/Date Received 2022-05-10
[0157] In some embodiments, the base stations described herein may be
compatible with a
Long Term Evolution (LTE) radio transmission protocol, or another air
interface. The LTE-
compatible base stations may be eNodeBs, or may be gNodeBs, or may be hybrid
base
stations supporting multiple technologies and may have integration across
multiple cellular
network generations such as steering, memory sharing, data structure sharing,
shared
connections to core network nodes, etc. In addition to supporting the LTE
protocol, the base
stations may also support other air interfaces, such as UMTS/HSPA,
CDMA/CDMA2000,
GSM/EDGE, GPRS, EVDO, other 3G/2G, legacy TDD, 5G, or other air interfaces
used for
mobile telephony. In some embodiments, the base stations described herein may
support Wi-
Fi air interfaces, which may include one of 802.11a/b/g/n/ac/ad/af/ah. In some
embodiments,
the base stations described herein may support 802.16 (WiMAX), or other air
interfaces. In
some embodiments, the base stations described herein may provide access to
land mobile
radio (LMR)-associated radio frequency bands. In some embodiments, the base
stations
described herein may also support more than one of the above radio frequency
protocols, and
may also support transmit power adjustments for some or all of the radio
frequency protocols
supported.
[0158] In any of the scenarios described herein, where processing may be
performed at the
cell, the processing may also be performed in coordination with a cloud
coordination server.
A mesh node may be an eNodeB. An eNodeB may be in communication with the cloud
coordination server via an X2 protocol connection, or another connection. The
eNodeB may
perform inter-cell coordination via the cloud communication server when other
cells are in
communication with the cloud coordination server. The eNodeB may communicate
with the
cloud coordination server to determine whether the UE has the ability to
support a handover
to Wi-Fi, e.g., in a heterogeneous network.
[0159] Although the methods above are described as separate embodiments, one
of skill in
the art would understand that it would be possible and desirable to combine
several of the
above methods into a single embodiment, or to combine disparate methods into a
single
embodiment. For example, all of the above methods could be combined. In the
scenarios
where multiple embodiments are described, the methods could be combined in
sequential
order, or in various orders as necessary.
44
Date Recue/Date Received 2022-05-10
[0160] Although the above systems and methods for providing interference
mitigation are
described in reference to the Long Term Evolution (LTE) standard, one of skill
in the art
would understand that these systems and methods could be adapted for use with
other
wireless standards or versions thereof. The inventors have understood and
appreciated that the
present disclosure could be used in conjunction with various network
architectures and
technologies. Wherever a 4G technology is described, the inventors have
understood that
other RATs have similar equivalents, such as a gNodeB for 5G equivalent of
eNB. Wherever
an MME is described, the MME could be a 3G RNC or a 5G AMF/SMF. Additionally,
wherever an MME is described, any other node in the core network could be
managed in
much the same way or in an equivalent or analogous way, for example, multiple
connections
to 4G EPC PGWs or SGWs, or any other node for any other RAT, could be
periodically
evaluated for health and otherwise monitored, and the other aspects of the
present disclosure
could be made to apply, in a way that would be understood by one having skill
in the art.
[0161] Additionally, the inventors have understood and appreciated that it is
advantageous to
perform certain functions at a coordination server, such as the Parallel
Wireless HetNet
Gateway, which performs virtualization of the RAN towards the core and vice
versa, so that
the core functions may be statefully proxied through the coordination server
to enable the
RAN to have reduced complexity. Therefore, at least four scenarios are
described: (1) the
selection of an MME or core node at the base station; (2) the selection of an
MME or core
node at a coordinating server such as a virtual radio network controller
gateway (VRNCGW);
(3) the selection of an MME or core node at the base station that is connected
to a 5G-capable
core network (either a 5G core network in a 5G standalone configuration, or a
4G core
network in 5G non-standalone configuration); (4) the selection of an MME or
core node at a
coordinating server that is connected to a 5G-capable core network (either 5G
SA or NSA). In
some embodiments, the core network RAT is obscured or virtualized towards the
RAN such
that the coordination server and not the base station is performing the
functions described
herein, e.g., the health management functions, to ensure that the RAN is
always connected to
an appropriate core network node. Different protocols other than SlAP, or the
same protocol,
could be used, in some embodiments.
Date Recue/Date Received 2022-05-10
[0162] In some embodiments, the software needed for implementing the methods
and
procedures described herein may be implemented in a high level procedural or
an object-
oriented language such as C, C++, C#, Python, Java, or Perl. The software may
also be
implemented in assembly language if desired. Packet processing implemented in
a network
device can include any processing determined by the context. For example,
packet processing
may involve high-level data link control (HDLC) framing, header compression,
and/or
encryption. In some embodiments, software that, when executed, causes a device
to perform
the methods described herein may be stored on a computer-readable medium such
as read-
only memory (ROM), programmable-read-only memory (PROM), electrically erasable
programmable-read-only memory (EEPROM), flash memory, or a magnetic disk that
is
readable by a general or special purpose-processing unit to perform the
processes described in
this document. The processors can include any microprocessor (single or
multiple core),
system on chip (SoC), microcontroller, digital signal processor (DSP),
graphics processing
unit (GPU), or any other integrated circuit capable of processing instructions
such as an x86
microprocessor.
[0163] In some embodiments, the radio transceivers described herein may be
base stations
compatible with a Long Term Evolution (LTE) radio transmission protocol or air
interface.
The LTE-compatible base stations may be eNodeBs. In addition to supporting the
LTE
protocol, the base stations may also support other air interfaces, such as
UMTS/HSPA,
CDMA/CDMA2000, GSM/EDGE, GPRS, EVDO, 2G, 3G, 5G, TDD, or other air interfaces
used for mobile telephony.
[0164] In some embodiments, the base stations described herein may support Wi-
Fi air
interfaces, which may include one or more of IEEE 802.11a/b/g/n/ac/af/p/h. In
some
embodiments, the base stations described herein may support IEEE 802.16
(WiMAX), to LTE
transmissions in unlicensed frequency bands (e.g., LTE-U, Licensed Access or
LA-LTE), to
LTE transmissions using dynamic spectrum access (DSA), to radio transceivers
for ZigBee,
Bluetooth, or other radio frequency protocols, or other air interfaces.
[0165] The foregoing discussion discloses and describes merely exemplary
embodiments of
the present invention. In some embodiments, software that, when executed,
causes a device to
46
Date Recue/Date Received 2022-05-10
perform the methods described herein may be stored on a computer-readable
medium such as
a computer memory storage device, a hard disk, a flash drive, an optical disc,
or the like. As
will be understood by those skilled in the art, the present invention may be
embodied in other
specific forms without departing from the spirit or essential characteristics
thereof. For
example, wireless network topology can also apply to wired networks, optical
networks, and
the like. Various components in the devices described herein may be added,
removed, split
across different devices, combined onto a single device, or substituted with
those having the
same or similar functionality.
[0166] Although the present disclosure has been described and illustrated in
the foregoing
example embodiments, it is understood that the present disclosure has been
made only by way
of example, and that numerous changes in the details of implementation of the
disclosure may
be made without departing from the spirit and scope of the disclosure, which
is limited only
by the claims which follow. Various components in the devices described herein
may be
added, removed, or substituted with those having the same or similar
functionality. Various
steps as described in the figures and specification may be added or removed
from the
processes described herein, and the steps described may be performed in an
alternative order,
consistent with the spirit of the invention. Features of one embodiment may be
used in
another embodiment. Other embodiments are within the following claims.
47
Date Recue/Date Received 2022-05-10
