Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description.

When a <NUM> UE moves into an area where local data services are available, the data connection of the UE may be re-configured by the <NUM> core network so that it supports access to these local data services, in addition to supporting access to remote data services. The local data services are services usually deployed in the vicinity of the UE, e.g. in a shopping mall, enterprise, etc, whereas remote data services are services usually deployed in the cloud and thus at far distance from the UE. A User Plane Function (UPF) accessing the local data network routes traffic either upstream towards the core network and then to the remote data service, or to the local data network. The forwarding decisions are normally taken by routing rules configured in the UPF. In doing so, the UPF provides a functionality referred to as an "Uplink Classifier (UL CL)" functionality.

One problem that arises when the data connection is re-configured to support access to a local data network, in addition to remote data networks, is that this re-configuration is completely transparent to the UE. In other words, the UE does not know when and if its data connection can provide access to local data services. If the UE is not aware of that, the UE may not attempt to discover such services unless (a) the user explicitly triggers the UE to start the service discovery (which leads to bad user experience) or (b) the UE is configured to periodically attempt the discovery (which leads to unnecessary use of battery and radio resources when the local data network is not available). This prevents the UE from optimizing its operation and from providing enhanced user experience.

<CIT> describes a mobile terminal that uses a plurality of communication routes for communication with a correspondent node. <CIT> describes Local IP Access (LIPA) that allows an IP-capable user equipment connected via a femto cell direct access to other IP-capable devices in the local IP network. <CIT> describes a User Equipment configurable to offload communication of packet data from a cellular radio-access network. <CIT> describes handling of local breakout traffic in a home base station.

Claim <NUM> defines a remote unit for wireless communication, claim <NUM> defines a method performed by a remote unit, and claim <NUM> defines a processor for wireless communication.

Methods for accessing a local data network via a mobile data connection are disclosed. Apparatuses and systems also perform the functions of the methods. In one embodiment, a method for accessing a local data network via a mobile data connection includes receiving, at a remote unit, a downlink data packet from a first data connection over a mobile communication network, the first data connection providing access to a remote data network. The method includes determining from the downlink data packet whether the first data connection provides access to a local data network in addition to the remote data network. The method also includes accessing one or more services in the local data network in response to determining that the first data connection provides access to the local data network.

Another method for accessing a local data network via a mobile data connection includes establishing a first data connection with a remote unit over a first network interface. Here, the first data connection providing the remote unit access to a remote data network. The method includes communicating with a session management function ("SMF") over a second network interface and determining whether to configure the first data connection to provide access to a local data network in addition to the remote data network based on information received from the SMF. In response to determining to configure the first data connection to provide access to a local data network, the method includes activating a third network interface that communicates with a local data network. The method includes transmitting a downlink data packet to the remote unit over the first data connection, the downlink data packet including an indicator that the first data connection provides access to a local data network, in response to activating the third network interface, and providing the remote unit with access one or more services via the local data network using the third network interface.

This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagrams.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagram.

In order to solve the above described problem of discovering locally available data services and to efficiently route data requests for a local data network, a UE receives downlink packets having an indicator that indicates when an established data connection becomes capable to provide access to a local data network and, in response, enables access to the local data network via the said data connection. Here, the UE determines if a data connection over a mobile communication network can provide connectivity to a local data network, in addition to connectivity to a remote data network, by examining the indicator. In one embodiment, the indicator is a flag in the downlink packet header. In certain embodiments, the UE also determines a charging rate applied for the traffic to the local data network that is accessible via its data connection over the mobile communication network. Here, a downlink data packet may also include a local charging rate parameter.

In order to efficiently route data requests for a local data network, the UE marks the traffic sent to its data connection over the mobile data network to indicate which traffic should be routed to the local data network and which traffic should be routed to the remote data network. In certain embodiments, the UE configures a virtual network interface that provides access to the local data network via the first data connection. All data packets sent to this virtual network interface are transmitted via the first data connection but are also marked with a local access request flag. This local access request flag is interpreted by the mobile network as a request from UE to route the data packet to the local data network.

Note that this local access request flag is particularly useful for routing multicast/broadcast data packets because the destination address in these packets cannot indicate if they should be routed to the local data network or upstream to a remote data network. In addition, the local access request flag is useful when the address space of the local data network overlaps with the address space of the remote data network. In this case, routing cannot be solely based on the destination address. Moreover, the local access request flag is useful for routing unicast DNS queries to a DNS server in the local data network when the UE is not aware of the address of the DNS server in the local data network. In this case, the Uplink Classifier receiving the DNS query with the local access request flag changes the destination address in the DNS query and forwards it to the local data network to reach the DNS server in the local data network.

<FIG> a wireless communication system <NUM> for accessing a local data network via a mobile data connection, according to embodiments of the disclosure. In one embodiment, the wireless communication system <NUM> includes remote units <NUM>, cellular base units <NUM>, and cellular communication links <NUM>. Even though a specific number of remote units <NUM>, cellular base units <NUM>, and cellular communication links <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, cellular base units <NUM>, and cellular communication links <NUM> may be included in the wireless communication system <NUM>.

In one implementation, the wireless communication system <NUM> is compliant with the <NUM> system specified in the 3GPP specifications. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication network, for example, LTE or WiMAX, among other networks.

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. The remote units <NUM> may communicate directly with one or more of the cellular base units <NUM> via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over the cellular communication links <NUM>.

In some embodiments, the remote units <NUM> communicate with a remote data network <NUM> via a data connection with the mobile core network <NUM>. For example, a remote unit <NUM> may establish a data connection (also known as "PDU session") with the remote data network <NUM> via the mobile core network <NUM> and via a cellular base unit <NUM>. A user plane function ("UPF") <NUM> in the mobile core network <NUM> then relays traffic between the remote unit <NUM> and the remote data network <NUM> over the data connection. As depicted, one or more UPFs <NUM> may be located outside the mobile core network <NUM>. In certain embodiments, the UPFs <NUM> may have access to local data networks. When in the data path of a data connection of a remote unit <NUM>, the UPF <NUM> may provide the remote unit <NUM> with access to local data services, such as print services, media/streaming services, HTTP services, file services, and the like.

The cellular base units <NUM> may be distributed over a geographic region. In certain embodiments, a cellular base unit <NUM> may also be referred to as an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, or by any other terminology used in the art. The cellular base units <NUM> are generally part of a radio access network ("RAN") that may include one or more controllers communicably coupled to one or more corresponding cellular base units <NUM>. These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The cellular base units <NUM> connect to the mobile core network <NUM> via the RAN.

The cellular base units <NUM> may serve a number of remote units <NUM> within a serving area, for example, a cell or a cell sector via a wireless communication link. The cellular base units <NUM> may communicate directly with one or more of the remote units <NUM> via communication signals. Generally, the cellular base units <NUM> transmit downlink ("DL") communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the cellular communication links <NUM>. The cellular communication links <NUM> may be any suitable carrier in licensed or unlicensed radio spectrum. The cellular communication links <NUM> facilitate communication between one or more of the remote units <NUM> and/or one or more of the cellular base units <NUM>.

In one embodiment, the mobile core network <NUM> is a <NUM> core ("5GC") or the evolved packet core ("EPC"), which may be coupled to other networks, like the Internet and private data networks, among other packet data networks. Each mobile core network <NUM> belongs to a single public land mobile network ("PLMN").

As depicted, the mobile core network <NUM> includes a UPF <NUM> and a session management function ("SMF") <NUM>. Although a specific number of UPFs <NUM> and SMFs <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of UPFs <NUM> and SMFs <NUM> may be included in the mobile core network <NUM>. The UPF <NUM> provides user plane (e.g., data) services to the remote units <NUM>. A data connection between the remote unit <NUM> and a data network is managed by a UPF <NUM>. The SMF <NUM> manages the data sessions of the remote units <NUM>, such as the PDU session discussed above. In certain embodiments, the SMF <NUM> may add or modify the data path of a data connection used by a remote unit <NUM>. For example, the SMF <NUM> may insert a new UPF <NUM> into the data path and/or configure a UPF <NUM> to provide access to the local data network <NUM>.

As discussed in greater detail below, a UPF <NUM> may indicate availability of local data services (e.g., in the local data network <NUM>) to a remote unit <NUM> already having a data connection to the remote data network <NUM>. Here, the UPF <NUM> may flag one or more downlink packets to indicate the availability of local data services. An interested remote unit <NUM> may discover one or more local data services and flag uplink packets to be routed via the local data network <NUM>. This flag in the uplink packet is interpreted by the mobile network (e.g., UPF <NUM>) as a request from the remote unit <NUM> to route the data packet to the local data network <NUM>.

<FIG> depict network architectures used for accessing a local data network via a mobile data connection, according to embodiments of the disclosure. <FIG> depicts a network architecture <NUM> at a first moment in time. The network architecture <NUM> includes a UE <NUM>, a RAN <NUM>, a core network <NUM>, a first UPF <NUM>, and a remote data network <NUM>. The UE <NUM> is a <NUM> UE and may be one embodiment of the remote unit <NUM> discussed above, the core network <NUM> is a <NUM> core network and may be one embodiment of the mobile core network <NUM> discussed above, and the first UPF <NUM> may be one embodiment of the UPF <NUM> discussed above. The remote data network may be substantially described above with reference to <FIG> and the RAN <NUM> may include a cellular base unit <NUM>. In certain embodiments, the RAN <NUM> is a 3GPP RAN (e.g., E-UTRAN or <NUM>-RAN). In other embodiments, the RAN <NUM> may be a non-3GPP RAN (e.g., a Wi-Fi network).

<FIG> shows the UE <NUM> having established a data connection <NUM> which supports access to the remote data network <NUM> and to services available in the remote data network <NUM>. In certain embodiments, the remote data network <NUM> is a private enterprise network while, in other embodiments, the remote data network <NUM> represents the entire Internet. In certain embodiments, the data connection <NUM> is a PDU session. The data path of the data connection <NUM> is composed of three concatenated interfaces: a radio interface (Uu) between the UE and RAN, a backhaul interface (N3) between RAN and the first UPF <NUM> in the <NUM> core network, and an N6 interface between the first UPF <NUM> and the remote data network <NUM>. Although only one UPF is shown, in other embodiment multiple UPFs may be in the data path. For example, in roaming cases where the data path extends to the home network one UPF is required in the visited network and another UFP in the home network.

<FIG> depicts a network architecture <NUM> used for accessing a local data network via a mobile data connection. The network architecture <NUM> may be an embodiment of the network architecture <NUM> at another moment in time (e.g., at a future time after the UE <NUM> moves to a different location). Here, the network architecture <NUM> includes the elements of the network architecture <NUM> and further includes a second UPF <NUM> in the data path of the data connection <NUM>. The second UPF <NUM> may be one embodiment of the UPF <NUM> discussed above. The first UPF <NUM> and the second UPF <NUM> communicate using an N9 interface.

When the UE <NUM> moves into an area (e.g. a mall, airport, enterprise, stadium, etc.) that supports local data services (e.g., print services, media services, HTTP services, Mobile Edge Computing ("MEC") services, etc.), the data path of the data connection <NUM> may be re-configured by the core network <NUM> (e.g., by a SMF in the core network <NUM>) to support access to the local data network <NUM>, as shown in <FIG>. For example, the SMF in the core network <NUM> may insert the second UPF <NUM> into the data path of the data connection <NUM>. Here, the second UPF <NUM> supports access to a local data network <NUM> via a second instance of the N6 interface. Note that the main role of second UPF <NUM> is to receive data traffic from the UE <NUM> and to determine how to route this traffic. The second UPF <NUM> will either forward the traffic to an upstream UPF (e.g., the first UPF <NUM>) for reaching the remote data network <NUM>, or forward the traffic to the local data network <NUM>.

After the second UPF <NUM> is inserted in the data path of the data connection <NUM>, the second UPF <NUM> marks every downlink packet sent to the UE <NUM> with a "local access available" flag, a new flag indicating the availability of local services. For example, the local data network <NUM> may enable a user of the UE <NUM> to print documents to a local print server and/or to consume audio/video content from a local media server. When the UE <NUM> starts receiving packets via the data connection <NUM> that contain the local access available flag, the UE <NUM> determines that the data connection <NUM> provides access to a local data network <NUM> in addition to access the remote data network <NUM>. In turn, the UE <NUM> may use the DHCP protocol to request IP configuration data (e.g. an IP address, network mask, domain name, DNS server address, etc.) for accessing the local data network. In addition, the UE <NUM> may discover the local services and enable access to the local data network <NUM> via the data connection <NUM>.

Because certain UEs may not care about locally available services and because potentially hundreds of services may be available in the local data network <NUM>, the local access available flag indicates that access to a local data network is available, but does not indicate which services are available to minimize packet overhead. This way, an interested UE can then discover the locally available services. As an example, the local access available flag (also referred to herein as a "local data available" flag) may be a one-bit flag in the header of the downlink packet.

The second UPF <NUM> adds the local access available flag to every X downlink packets. In certain embodiments, the value of X is <NUM> such that each downlink packet contains the local access available flag. In other embodiments, the value of X is greater than <NUM> such that not every packet includes the local access available flag. Here, the network operator may set the value for X (e.g., define how often to include the local access available flag).

In addition to the local access available flag, the second UPF <NUM> may mark one or more downlink packets sent to UE <NUM> with a "local charging rate" parameter indicating the charging rate applied to data traffic sent by the UE <NUM> and routed to the local data network <NUM> via the data connection <NUM>. For example, this parameter may be two bits encoded as: '<NUM>' for free, '<NUM>' for <NUM>% charging rate, '<NUM>' for <NUM>% charging rate and '<NUM>' for <NUM>% charging rate with respect to the charging rate applied to the traffic towards the remote data network <NUM> over the data connection <NUM>. Note that the charging rate may be specific to the UE <NUM>. In one embodiment, the second UPF <NUM> marks every downlink packet with the local charging rate parameter. In other embodiments, the second UPF <NUM> only marks some of the downlink packets with the local charging rate parameter to minimize packet overhead. Whenever the local charging rate changes, the second UPF <NUM> updates accordingly the charging rate parameter in the downlink packets.

In certain embodiments, the second UPF <NUM> indicates the availability of a local data network by including the local charging rate parameter in the downlink data packets. Here, the local access available flag may be omitted as the presence (or absence) of the local charging rate parameter indicates to the UE <NUM> also whether access to a local data network is available. Here, the second UPF <NUM> may add the local charging rate parameter to every X downlink packets whenever access the local data network <NUM> is available, where a network operator sets the value for X.

As one example, when the UE <NUM> is aware that it can access the local data network <NUM>, the UE <NUM> behaves as it normally does when configuring a new network interface. That is, the UE <NUM> broadcasts (via the data connection <NUM>) a dynamic host configuration protocol ("DHCP") request to discover a DHCP server in the local data network <NUM> and then requests from the DHCP server to provide IP configuration data, including an IP address, network mask, domain name, DNS server address, etc. After that the UE <NUM> is configured with two IP addresses on the same data connection <NUM>: One IP address assigned when the data connection <NUM> was established and another IP address assigned with DHCP after receiving the local access available flag. Here, the first IP address is used for communication with the remote data network <NUM> and the latter IP address is used for communication with the local data network <NUM>. Note that the above DHCP request broadcast by the UE <NUM> may include the local access request flag in order to be routed to the local data network <NUM>.

As a second example, when the UE <NUM> is aware that it can access the local data network <NUM>, the UE <NUM> may attempt to discover the locally offered services (e.g. printing service, media service, streaming services, etc.) and notify its applications and the user of the discovered services. As a third example, when the UE <NUM> is aware that it can access a local data network that supports data communication with reduced or no charging, the UE <NUM> may notify its applications which may then start content retrieval (e.g. start downloading a firmware update) which would be too costly over the remote data network <NUM>. As a fourth example, when the UE <NUM> is aware that it can access a local data network, the UE <NUM> may use the Web Proxy Auto-Discovery ("WPAD") protocol to discover and use an HTTP proxy available in the local data network, thereby improving subsequent web browsing experience as requests for content locally cached in the HTTP proxy are able to be served very quickly.

In some embodiments, the UE <NUM> initiates service discovery by using the Simple Service Discovery Protocol ("SSDP") or the multicast DNS ("mDNS") protocols to discover some services available in the local data network. For example, the UE <NUM> may initiate discovery of print servers and/or media servers in the local data network by sending a SSDP search request or an mDNS query. In certain embodiments, the UE <NUM> initiates the WPAD protocol to discover and use an HTTP proxy in the local data network. After discovering an HTTP proxy in the local data network, the UE <NUM> may configure its networking layer to steer all HTTP traffic of the UE <NUM> to go through the HTTP proxy server in the local data network.

Having discovered one or more local data services, the UE <NUM> may indicate to the network (e.g., the second UPF <NUM>) which uplink packets should be routed to the local data network. This is mainly required when the destination address of uplink packets cannot be used to determine if the packets should be routed to the local data network or to the remote data network, for example using Uplink Classifier, as discussed above. Here, the UE <NUM> marks uplink packets intended for the local data network <NUM> with a "local access request" flag, a new flag indicating packet routing to the UPF. The second UPF <NUM> routes packets marked with the local access request flag to the local data network <NUM>, unless network policy in the second UPF <NUM> prevents such routing.

If the UE <NUM> receives IP configuration data from the local data network <NUM> (e.g., in response to a DHCP request), then the UE <NUM> becomes aware of the address space of the local data network <NUM>. For example, the UE <NUM> may learn that all IP addresses in the local data network <NUM> are "<NUM>. Accordingly, the transmitted packets for the local data network <NUM> will have a destination address "<NUM>. y" and can be used by the second UPF <NUM> for routing without the need of the local access request flag. However, the local access request flag may still be used in case of multicast and/or broadcast traffic or in situations of overlapping address spaces of the remote data network <NUM> and the local data network <NUM>.

In some embodiments, the UE <NUM> configures a new "virtual" network interface that provides access to the local data network <NUM> via the data connection <NUM>. In one embodiment, all data packets sent to this virtual network interface are transmitted via the data connection <NUM> but are also marked with the local access request flag. Referring to the above examples, the UE <NUM> is to mark all service discovery requests (e.g. SSDP, mDNS requests) and all DHCP requests with the local access request flag to ensure routing to the local data network <NUM>. In addition, the UE <NUM> may mark local service requests (e.g. print requests, streaming requests) with the local access request flag when these requests cannot be routed based on the destination address, e.g., when the address space of the remote and local data networks overlap.

In certain embodiments, the local access request flag (also referred to herein as a "local data request" flag) is a one-bit flag included in the packet header of each uplink packet. Here, a value of <NUM> may indicate that the uplink packet is to be routed to the local data network <NUM>, while a value of <NUM> may indicate that the uplink packet is to be routed to the first UPF <NUM> and the remote data network <NUM>. Note that each data packet exchanged over the Uu, N3 and N9 interfaces is prefixed by a specific header which contains metadata about the packet. In certain embodiments, the local access available flag, the local access request flag, and the local charging rate parameter may be included as additional metadata in this header.

<FIG> depicts a first procedure <NUM> for accessing a local data network via a mobile data connection, according to embodiments of the disclosure. The first procedure <NUM> involves the UE <NUM>, first UPF <NUM>, second UPF <NUM>, remote data network <NUM>, and the local data network <NUM>. Here, the local data network <NUM> includes a print server <NUM> that provides local printing services. The first procedure <NUM> begins sometime after a first data connection <NUM> is established between the UE <NUM> and the remote data network <NUM> (e.g., over a mobile communication network). The first data connection <NUM> may be one embodiment of the data connection <NUM> discussed above. Initially, the path of the data connection passes through the first UPF <NUM> but does not pass through the second UPF <NUM>.

At some point, the path of the first data connection <NUM> is modified (e.g., in response to the UE <NUM> moving to a new area) and a new UPF (e.g., the second UPF <NUM>) is added to the data path (see block <NUM>). Here, downlink traffic from the remote data network <NUM> first passes to the first UPF <NUM>, then passes to the second UPF <NUM>, and is finally passed to the UE <NUM> via the RAN (not shown in <FIG>). Because the UPFs are transparent to the UE <NUM>, the UE <NUM> is unaware of the path modification to the first data connection <NUM>.

Because the local data network <NUM> is accessible to the UE <NUM> via the second UPF <NUM>, the second UPF <NUM> begins to mark the DL data packets with a "local data available" flag and transmits the marked DL data packets to the UE <NUM> (see block <NUM>). For example, the second UPF <NUM> may set a flag bit in the packet headers of the downlink packets. The local data available flag indicates to the UE <NUM> that access to a local data network is available. However, the local data available flag does not indicate which services are available in the local data network. When the UE <NUM> is aware that it can access a local data network, the UE <NUM> may attempt to discover the local services and/or may attempt to request IP configuration data (e.g. via DHCP) for the local data network. For example, the UE <NUM> may be configured with a policy to utilize local services whenever available.

As depicted, the UE <NUM> discovers the available local services by sending out one or more mDNS query packets marked with a "local data request" flag (see block <NUM>). Here, the mDNS query packets allow the UE <NUM> to discover which services are available via the local data network <NUM>. The local data request flag indicates to the second UPF <NUM> that the mDNS query packets should be sent to the local data network <NUM>, rather than to the first UPF <NUM> and remote data network <NUM>.

Upon receiving the one or more mDNS query packets marked with a "local data request" flag, the second UPF <NUM> forwards the packets to the local data network <NUM> (see block <NUM>). When forwarding uplink packets to the local data network <NUM>, the second UPF <NUM> modifies the packet header (e.g., using network address and port translation ("NAPT")) to allow for routing in the local data network <NUM>. Because the original source IP address may not be routable in the local data network <NUM>, the second UPF <NUM> changes the source IP address to its own IP address and the source port number to its own source port. The second UPF <NUM> stores the IP address/port number mappings.

One or more devices in the local data network <NUM> may respond to the mDNS query (see block <NUM>). Here, at least the print server <NUM> sends a DNS response to the mDNS query. While the query uses multicast DNS, the response may be a unicast DNS response. The second UPF <NUM> receives the DNS response(s) from the local data network <NUM> and forwards the response(s) to the UE <NUM> (see block <NUM>). Here, the second UPF <NUM> again performs NAPT to modify the destination IP address and destination port number back to the original IP address/port number used by the UE <NUM>.

Upon receiving the DNS response(s), the UE <NUM> determines services available via the local data network <NUM>. Here, the UE <NUM> identifies at least the locally available print services provided by the local print server <NUM> from the DNS response (see block <NUM>). Additionally, the UE <NUM> makes the discovered services (including print services of the discovered print server <NUM>) available to its applications. When an application on the UE requests to print a document to the print server <NUM> (see block <NUM>), the UE <NUM> transmits a sequence of packets (e.g., corresponding to a print job) to the IP address of the print server <NUM>. These uplink packets are also marked with the local data request flag to ensure that the second UPF <NUM> routes the print job to the local data network <NUM>. Note that if the packets addressed to the print server <NUM> are not also marked with the local data request flag, then the second UPF <NUM> may route these packets to the first UPF <NUM> and remote data network <NUM>, especially when there is an overlap between the address space of the remote data network and the address space of the local access network.

<FIG> depicts a second procedure <NUM> for accessing a local data network via a mobile data connection, according to embodiments of the disclosure. The second procedure <NUM> involves the UE <NUM>, first UPF <NUM>, second UPF <NUM>, remote data network <NUM>, and the local data network <NUM>. Here, the local data network <NUM> includes a HTTP proxy <NUM> that provides local HTTP proxy services. The second procedure <NUM> begins sometime after the first data connection <NUM> is established between the UE <NUM> and the remote data network <NUM> (e.g., over a mobile communication network). Initially, the path of the first data connection <NUM> passes through the first UPF <NUM>, but does not pass through the second UPF <NUM>.

At some point, the path of the first data connection <NUM> is modified (e.g., in response to the UE <NUM> moving to a new area) and a new UPF (e.g., the second UPF <NUM>) is added to the data path (see block <NUM>). Because the local data network <NUM> is accessible to the UE <NUM> via the second UPF <NUM>, the second UPF <NUM> begins to mark the DL data packets with a "local data available" flag, indicating to the UE <NUM> that access to a local data network is available (see block <NUM>). Additionally, the second UPF <NUM> includes a "local charging rate" parameter (see block <NUM>). In certain embodiments, the second UPF <NUM> sends the local charging rate parameter in the first N number of DL packets. Here, N is a predetermined amount, for example ten, and may be configured by a network operator. In the embodiment of <FIG>, the local charging rate parameter indicates to the UE <NUM> that access to the local data network <NUM> is provided for free.

As depicted, the UE <NUM> discovers the available local services by sending out one or more unicast DNS query packets marked with a "local data request" flag (see block <NUM>). The local data request flag indicates to the second UPF <NUM> that the DNS query packets should be sent to the local data network <NUM>, rather than to the first UPF <NUM> and remote data network <NUM>. Where UE <NUM> attempts to discover an HTTP proxy in the local data network <NUM>, the UE <NUM> may send DNS query packets according to the WPAD protocol.

Upon receiving the one or more unicast DNS query packets marked with a "local data request" flag, the second UPF <NUM> forwards these packets to the local data network <NUM> (see block <NUM>). When forwarding uplink packets to the local data network <NUM>, the second UPF <NUM> modifies the packet header using NAPT. Here, the second UPF <NUM> may change the destination IP address to include the IP address of the DNS server (not shown in <FIG>) in the local data network <NUM>, instead of the IP address of the DNS server in the remote data network. Additionally, the second UPF <NUM> changes the source IP address and the source port number so that the response is routed back to the second UPF <NUM>.

The DNS server in the local data network <NUM> sends a DNS response to the second UPF <NUM> (see block <NUM>). The second UPF <NUM> forwards the response to the UE <NUM> (see block <NUM>). Here, the second UPF <NUM> again performs NAPT to modify the destination IP address and destination port number back to the original IP address/port number used by the UE <NUM> in its DNS request.

The UE <NUM> discovers the HTTP proxy <NUM> from the DNS response (see block <NUM>). The DNS response from the local DNS server includes the URL of a WPAD file, the WPAD file including an auto-configuration script. The UE <NUM> retrieves this WPAD file by initiating an HTTP GET operation and configures its HTTP stack to use the discovered HTTP proxy <NUM> in the local data network <NUM> based on the contents of the WPAD file (see block <NUM>).

The UE <NUM> sends subsequent HTTP requests to the discovered HTTP proxy <NUM> in the local data network <NUM>. All these requests are marked with the "local data request" flag in order to make sure they are routed to the local data network <NUM> (see block <NUM>). The performance of HTTP-based services may then be improved because requested content may be retrieved from the local cache of the HTTP proxy <NUM>.

<FIG> depicts a UE model for supporting data traffic to the remote data network and to the local data network via the same data connection. The UE <NUM> may be one embodiment of the remote unit <NUM> and/or UE <NUM> discussed above. The UE <NUM> includes one or more UE applications <NUM> installed thereon which generate uplink data <NUM>. The UE applications pass the uplink data <NUM> to the networking stack <NUM> which generates uplink packets <NUM>. Here, the uplink packets <NUM> include headers and payloads. The networking stack <NUM> determines a network interface for each uplink packet <NUM>. Those uplink packets <NUM> that should reach the local data network <NUM> (e.g., because they are for services in the local data network) are sent to the virtual network interface <NUM>. At the virtual network interface <NUM>, each uplink packet is marked with a "local access request" flag (also referred to as a local data request) forming marked uplink packets <NUM>. Those uplink packets <NUM> not destined for the local data network <NUM> are not marked. Both the marked and unmarked uplink packets <NUM> are then sent to the first data connection <NUM> for transmission over the mobile network (e.g., transmitted to the RAN). The first data connection <NUM> may be substantially similar to the data connection <NUM> and first data connection <NUM> discussed above. When the UE <NUM> uses the DHCP protocol as discussed above to receive IP data configuration for accessing the local data network, this IP data configuration is used to configure the virtual network interface <NUM>. For example, the virtual interface <NUM> may be assigned the IP address received from the DHCP server in the local data network.

<FIG> depicts one embodiment of an apparatus <NUM> that may be used for accessing a local data network via a mobile data connection, according to embodiments of the disclosure. The apparatus <NUM> includes one embodiment of the remote unit <NUM>. Furthermore, the remote unit <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a display <NUM>, a transceiver <NUM> for communicating over an access network (e.g., a 3GPP RAN or a WLAN). In some embodiments, the input device <NUM> and the display <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the remote unit <NUM> may not include any input device <NUM> and/or display <NUM>.

The processor <NUM> is communicatively coupled to the memory <NUM>, the input device <NUM>, the display <NUM>, and the transceiver <NUM>.

In some embodiments, the processor <NUM> receives a downlink data packet from a first data connection (e.g., the data connection <NUM>, the first data connection <NUM>, and/or the first data connection <NUM>) over the mobile communication network. Here, the first data connection provides the remote unit <NUM> with access to a remote data network <NUM>. The processor <NUM> determines, from the downlink data packet, whether the first data connection provides access to a local data network <NUM> in addition to the remote data network <NUM>. In response to the first data connection providing access to the local data network <NUM>, the processor <NUM> accesses one or more services via the local data network <NUM>.

In some embodiments, the processor <NUM> examines a flag in a header of the downlink data packet (e.g., a "local access availability" flag) to determine whether the first data connection provides access to a local data network <NUM>. Here, the flag (e.g., local access availability flag) indicates whether the first data connection provides access to the local data network <NUM>. For example, when set (e.g., to a binary "<NUM>"), the flag indicates that a local data network <NUM> is available to access via the first data connection. If the flag is not set, the processor <NUM> determines that no local data network <NUM> is available to access via the first data connection.

In certain embodiments, the downlink data packet further includes a charging rate parameter. For example, the charging rate parameter may be inserted into the packet header. The charging rate parameter indicates a charging rate applied to data traffic sent by the remote unit <NUM> to the local data network <NUM> via the first data connection. The charging rate may be specific to the remote unit <NUM>. For example, devices of a certain model, manufacture, or associated with a certain subscription may be charged at a different rate than others. Upon parsing the charging rate parameter, the processor <NUM> may inform one or more applications installed at the remote unit <NUM> that a new network interface if available (e.g. the virtual network interface <NUM>) which supports data communication free of charge or with a reduced charging rate. In one embodiment, the processor <NUM> informs the application(s) only if the charging rate applied to data traffic sent by the remote unit <NUM> to the local data network <NUM> via the first data connection is different than a default charging rate for data traffic sent by the remote unit <NUM> via the first data connection.

In some embodiments, the processor <NUM> determines whether a charging rate parameter is present in the downlink data packet (e.g., in a packet header of the downlink data packet) to determine whether the first data connection provides access to the local data network <NUM>. Here, the presence of the charging rate parameter serves as an indication that the first data connection provides access to both the remote data network <NUM> and a local data network <NUM>. In such embodiments, the processor <NUM> determines that no local data network <NUM> is available to access via the first data connection whenever the downlink data packet does not include a charging rate parameter.

In certain embodiments, the processor <NUM> accesses the one or more services via the local data network <NUM> by configuring a virtual network interface <NUM> for accessing the local data network <NUM> via the first data connection. The virtual network interface <NUM> may be one embodiment of the virtual network interface <NUM> discussed above. Configuration of the virtual network interface <NUM> may be performed by using the DHCP protocol, after receiving the local data available flag, to request and receive IP configuration data including an IP address, network mask, domain name, address of DNS servers, etc. In such embodiments, the processor <NUM> may mark each uplink packet sent to the virtual network interface <NUM> with a flag (e.g., a "local access request" flag). Here, the flag requests routing of the uplink packet to the local data network <NUM>.

In some embodiments, the processor <NUM> accesses the one or more services via the local data network <NUM> by sending a service discovery request to the local data network <NUM>. For example, the processor <NUM> may send a DNS query packet, including an mDNS query packet. As another example, the processor <NUM> may send a Simple Service Discovery Protocol ("SSDP") packet. The processor <NUM> flags the service discovery request (e.g., marks the request with a local access request flag), to request that the service discovery request (e.g., the DNS query or SSDP packet) be routed to the local data network <NUM>.

In certain embodiments, accessing one or more services via the local data network <NUM> includes the processor <NUM> discovering a HTTP proxy <NUM> in the local data network <NUM>. In such embodiments, the processor <NUM> sends HTTP traffic to the discovered HTTP proxy <NUM> in the local data network <NUM>. In other embodiments, accessing one or more services via the local data network <NUM> includes the processor <NUM> requesting IP configuration data by using the DHCP protocol and using the received IP configuration data to configure a new network interface (e.g. the virtual network interface <NUM>) that supports data communication with the local data network.

In some embodiments, the processor <NUM> receives an uplink packet (e.g., from an application installed on the remote unit <NUM>) and determines whether the uplink packet is to be transmitted to the local data network <NUM>. For example, the uplink packet may belong to a local service provided by the local data network <NUM>. As another example, the uplink packet may not belong to a local service, but instead may simply need to be routed via the local data network <NUM> (e.g., to reduce cost).

If the processor <NUM> determines that the uplink packet should reach the local data network <NUM>, then the processor <NUM> marks the uplink packet with a flag, such as a local access request flag. Here, the flag requests routing of the uplink packet to the local data network <NUM>. After flagging the uplink packet, the processor <NUM> transmits it via the first data connection. Upon receiving the uplink packet and detecting the flag (e.g., the local access request flag), the UPF routes the flagged packet to the local data network <NUM>.

In some embodiments, the memory <NUM> stores data relating to accessing a local data network via a mobile data connection. In some embodiments, the memory <NUM> also stores program code and related data, such as an operating system or other controller algorithms operating on the remote unit <NUM> and one or more software applications.

In certain embodiments, the input device <NUM> may include a camera for capturing images or otherwise inputting visual data.

The transceiver <NUM> communicates with a mobile communication network (e.g., a PLMN) over an access network, such as a 3GPP RAN or a WLAN. In some embodiments, the mobile communication network comprises the cellular base units <NUM> and a mobile core network <NUM> discussed above with reference to <FIG>. The transceiver <NUM> may include hardware circuitry and/or software code for communicating with the access network. For example, the first transceiver may include one or more transmitters used to provide UL communication signals to the cellular base unit <NUM> and one or more receivers used to receive DL communication signals from the cellular base unit <NUM>. The transceiver <NUM> supports the virtual network interface <NUM> used when sending uplink packets to the local data network <NUM>.

<FIG> depicts an apparatus <NUM> that may be used for accessing a local data network via a mobile data connection. The apparatus <NUM> includes one embodiment of the UPF <NUM> in the data path of a first data connection (such as the data connection <NUM>, first data connection <NUM>, and/or first data connection <NUM>). Furthermore, the UPF <NUM> may include a processor <NUM>, a memory <NUM>, and a transceiver <NUM> supporting one or more network interfaces <NUM>. As may be appreciated, the processor <NUM> and memory <NUM> may be substantially similar to the processor <NUM> and the memory <NUM>, respectively. In certain embodiments, the UPF <NUM> also includes an input device <NUM> and an output device <NUM>, which may be substantially similar to the input device <NUM> and output device <NUM>, described above. The processor <NUM> is communicatively coupled to the memory <NUM>, input device <NUM>, output device <NUM>, and transceiver <NUM>.

In some embodiments, the processor <NUM> provides a first network interface 580A that supports communication with the UE over the first data connection (e.g., the data connection <NUM>, first data connection <NUM>, and/or first data connection <NUM>) and a second network interface 580B that supports communication with the SMF <NUM>. The processor <NUM> determines whether to configure a first data connection (e.g., the data connection <NUM>) to provide access to a local data network <NUM> in addition to the remote data network <NUM>. Here, the first data connection provides a remote unit <NUM> access to a remote data network <NUM>. The determination is based on information received from the SMF <NUM> via the second network interface 580B. In response to determining to configure the first data connection to provide access to a local data network, the processor <NUM> activates a third network interface 580C that communicates with a local data network <NUM>.

In response to activating the third network interface 580C, the processor <NUM> transmits a downlink data packet to the remote unit <NUM> over the first data connection. Here, the downlink data packet includes an indicator that the first data connection provides access to a local data network. The processor <NUM> also provides the remote unit <NUM> with access to one or more services via the local data network <NUM> using the third network interface.

In some embodiments, the processor <NUM> indicates that the first data connection supports access to a local data network <NUM> by setting a local access availability flag in a header of the downlink data packet. In certain embodiments, the processor <NUM> inserts the local access availability flag into every X downlink data packets of the first data connection, in response to activating the third network interface. Here, X may be a value selected by a network operator.

In certain embodiments, the processor <NUM> further sets a charging rate parameter in the header. Here, the charging rate parameter indicates a charging rate applied to data packets sent by the remote unit <NUM> to the local data network <NUM>. In one embodiment, in response to activating the third network interface, the processor <NUM> sends the charging rate parameter is only in a predetermined number of downlink packets. In another embodiment, in response to determining that the charging rate applied to data packets sent by the remote unit to the local data network has changed, the processor <NUM> sends the charging rate parameter in a predetermined number of downlink packets.

In some embodiments, the processor <NUM> indicates that the first data connection provides access to a local data network <NUM> by placing a charging rate parameter in a packet header of the downlink data packet. Here, the presence of the charging rate parameter indicating that the first data connection provides access to the local data network <NUM>.

In certain embodiments, the processor <NUM> provides the remote unit <NUM> with access to one or more services via the local data network <NUM> by receiving an uplink packet over the first data connection, determining whether the uplink packet includes a local access request flag request, and routing the uplink packet via the third network interface in response to the uplink packet including the local access request flag request. In other embodiments, the processor <NUM> provides the remote unit <NUM> with access to one or more services via the local data network <NUM> by receiving an uplink packet over the first data connection and routing the uplink packet via the third network interface in response to the uplink packet including a destination IP address belonging to the address space of the local data network.

The transceiver <NUM> comprises communication hardware for communicating with elements of the mobile communication network, such as a core network <NUM>, SMF <NUM>, additional UPF <NUM>, and a RAN, such as the RAN <NUM>. The transceiver <NUM> supports the first network interface 580A used to facilitate communication between a remote unit <NUM> and the remote data network <NUM>. Here, the first network interface 580A may communicate with the RAN using a N3 backhaul interface. The transceiver <NUM> also supports the second network interface 580B used to communicate with an SMF <NUM>. The transceiver <NUM> further supports the third network interface 580C used to facilitate communications between the remote unit <NUM> and the local data network <NUM>.

The transceiver <NUM> also communicates with a packet data network, for example communicating with the remote data network <NUM> using the first network interface 580A or communicating with the local data network <NUM> using the third network interface 580C. Here, the first network interface 580A may use a N6 interface for communicating with the remote data network <NUM> and the third network interface 580C may also use a N6 interface for communicating with the local data network <NUM>. When the UPF <NUM> supports an N6 interface with a packet data network, the UPF <NUM> is said to support an anchor functionality.

In certain embodiments, the transceiver <NUM> is also configured to communicate with one or more additional UPFs <NUM>, for example using the first network interface 580A. Here, the first network interface 580A may use an N9 interface for communicating with a UPF <NUM>. The transceiver <NUM> may also communicate with a SMF <NUM>, for example using the second network interface 580B. In some embodiments, the processor <NUM> may control the first data connection to provide a remote unit <NUM> with access to a local data network <NUM> by activating the third network interface 580C, as described herein.

<FIG> is a schematic flow chart diagram illustrating one embodiment of a method <NUM> for accessing a local data network via a mobile data connection, according to embodiments of the disclosure. In some embodiments, the method <NUM> is performed by an apparatus, such as the remote unit <NUM> or UE <NUM>. In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> may include receiving <NUM>, at a remote unit, a downlink data packet from a first data connection over the mobile communication network. Here, the first data connection providing access to a remote data network. The first data connection may be the data connection <NUM>, first data connection <NUM>, and/or the first data connection <NUM> discussed above.

The method <NUM> includes determining <NUM> from the downlink data packet whether the first data connection provides access to a local data network in addition to the remote data network. In some embodiments, determining <NUM> from the downlink data packet whether the first data connection provides access to the local data network in addition to the remote data network includes determining whether a charging rate parameter is present in a packet header of the downlink data packet. Here, the presence of the charging rate parameter indicates that the first data connection provides access to the local data network.

In certain embodiments, determining <NUM> from the downlink data packet whether the first data connection provides access to the local data network in addition to the remote data network includes examining a local access availability flag in a header of the downlink data packet. In such embodiments, the local access availability flag indicating whether the first data connection provides access to the local data network. In further embodiments, the header may include a charging rate parameter in the header, the charging rate parameter indicating a charging rate applied to data traffic sent by the apparatus to the local data network via the first data connection. Here, the method <NUM> may additionally include the remote unit informing an application installed thereon of the charging rate applied to data traffic sent by the apparatus to the local data network.

The method <NUM> also includes accessing <NUM> one or more services in the local data network in response to determining that the first data connection provides access to the local data network. In one embodiment, accessing <NUM> one or more services in the local data network includes requesting and receiving IP configuration data (e.g. by using the DHCP protocol) and configuring with this data a virtual network interface that provides access to the local data network. In some embodiments, uplink packets sent via the virtual network interface are not marked with the local access request flag e.g. when the destination address in the uplink packet is considered enough for routing the packet to the local data network. In other embodiments, uplink packets sent via the virtual network interface are marked with the local access request flag e.g. when the destination address in the uplink packet is not enough for routing the packet to the local data network (for example in multicast / broadcast packets).

In one embodiment, accessing <NUM> one or more services in the local data network includes discovering a hypertext transport protocol ("HTTP") proxy in the local data network and sending HTTP traffic to the discovered HTTP proxy in the local data network. In another embodiment, accessing <NUM> one or more services in the local data network comprises sending a service discovery request to the local data network. In a further embodiment, the method <NUM> may include the remote unit sending the service discovery request comprises sending a DNS query packet or a SSDP packet marked with a local access request flag, wherein the local access request flag requests routing the DNS query or the SSDP packet to the local data network.

In certain embodiments, the method <NUM> further includes determining whether an uplink packet should reach the local data network. In response to determining that the uplink packet should reach the local data network, the method <NUM> includes marking the uplink packet with a local access request flag. The method <NUM> further includes transmitting the uplink packet via the first data connection, wherein the local access request flag requests routing the uplink packet to the local data network. The method <NUM> ends.

<FIG> is a schematic flow chart diagram illustrating one embodiment of a method <NUM> for accessing a local data network via a mobile data connection, according to embodiments of the disclosure. In some embodiments, the method <NUM> is performed by an apparatus, such as the UPF <NUM> or second UPF <NUM>. In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> may include establishing <NUM> a first data connection with a remote unit over a first network interface. Here, the first data connection providing the remote unit access to a remote data network. The method includes communicating <NUM> with a session management function ("SMF") over a second network interface and determining <NUM> whether to configure the first data connection to provide access to a local data network in addition to the remote data network, based on information received from the SMF. In response to determining to configure the first data connection to provide access to a local data network, the method includes activating <NUM> a third network interface that communicates with a local data network.

The method includes transmitting <NUM> a downlink data packet to the remote unit over the first data connection, the downlink data packet including an indicator that the first data connection provides access to a local data network, in response to activating the third network interface. In some embodiments, transmitting <NUM> the downlink data packet including an indicator that the first data connection provides access to a local data network includes setting a local access availability flag in a header of the downlink data packet. In one embodiment, the method <NUM> further includes inserting the local access availability flag into every X downlink data packets of the first data connection, in response to activating the third network interface.

In certain embodiments, the method <NUM> also includes setting a charging rate parameter in the header, the charging rate parameter indicating a charging rate applied to data packets sent by the remote unit to the local data network. In one embodiment, in response to activating the third network interface, the charging rate parameter is only inserted in a predetermined number of downlink packets. In another embodiment, in response to determining that the charging rate applied to data packets sent by the remote unit to the local data network has changed, the charging rate parameter is only inserted in a predetermined number of downlink packets.

In some embodiments, transmitting <NUM> the downlink data packet including an indicator that the first data connection provides access to a local data network includes placing a charging rate parameter in a packet header of the downlink data packet. Here, the presence of the charging rate parameter indicating that the first data connection provides access to the local data network.

The method includes providing <NUM> the remote unit with access to one or more services via the local data network using the third network interface. In certain embodiments, providing <NUM> the remote unit with access to one or more services in the local data network includes determining whether an uplink packet received over the first data connection includes a local access request flag request and routing the uplink packet via the third network interface in response to the uplink packet including the local access request flag request. The method <NUM> ends.

Claim 1:
A remote unit (<NUM>) for wireless communication, the remote unit (<NUM>) comprising at least one memory (<NUM>), and at least one processor (<NUM>) coupled with the at least one memory (<NUM>) and configured to cause the remote unit (<NUM>) to:
receive a downlink data packet from a first data connection over the mobile communication network, the first data connection providing the remote unit (<NUM>) access to a remote data network;
determine from the downlink data packet whether the first data connection provides access to a local data network in addition to the remote data network, the determination made by examining a local access availability flag in a header of the downlink data packet, the local access availability flag indicating whether the first data connection provides access to the local data network; and
access one or more services in the local data network in response to determining that the first data connection provides access to the local data network.