Accessing a local data network via a mobile data connection

Access to local data network via mobile data connection Technical field

[0001] The subject matter disclosed herein relates generally to wireless communications, and more particularly to accessing a local data network via a mobile data connection.

Background technique

[0002] The following abbreviations are defined herein, at least some of which are referenced in the following description.

3GPP Third Generation Partnership Project

5G fifth generation

DHCP Dynamic Host Configuration Protocol

[0006] DNS Domain Name System

DL downlink

eNB Evolved Node B.

EPC evolved packet core network

E-UTRAN Evolved Universal Terrestrial Radio Access

IMS IP Multimedia Subsystem

IP Internet Protocol

[0013] LAN Local Area Network

LTE Long Term Evolution

PDU packet data unit

PLMN public land mobile network

RAN Radio Access Network

SMF session management function

SSDP Simple Service Discovery Protocol

UE user entity/equipment (mobile terminal)

UL uplink

UPF User Plane Function

WiMAX Worldwide Interoperability for Microwave Access

WLAN wireless local area network

WPAD Web Proxy Automatic Discovery

When a 5G UE moves to an area where local data services are available, the UE's data connection can be reconfigured by the 5G core network so that in addition to supporting access to remote data services, it also supports access to these local data services. enter. Local data services are services that are typically deployed near the UE (eg, in malls, businesses, etc.), while remote data services are services that are typically deployed in the cloud and thus far from the UE. A User Plane Function (UPF) accessing the local data network either routes traffic upstream towards the core network and then to remote data services, or to the local data network. Forwarding decisions are usually taken by routing rules configured in UPF. In doing so, the UPF provides a function known as the "Uplink Classifier (UL CL)" function.

[0027] One problem that arises when a data connection is reconfigured to support access to a local data network in addition to a remote data network is that the reconfiguration 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 does not know this, the UE may not attempt to discover such a service unless (a) the user explicitly triggers the UE to start service discovery (which results in a poor user experience), or (b) the UE is configured to periodically attempt Discovery (this can lead to unnecessary use of battery and radio resources when the local data network is unavailable). This prevents the UE from optimizing its operation and providing an enhanced user experience.

SUMMARY OF THE INVENTION

[0028] A method for accessing a local data network via a mobile data connection is disclosed. The apparatus and system also perform the functions of the method. In one embodiment, a method for accessing a local data network via a mobile data connection includes receiving, at a remote unit over a mobile communication network, a downlink data packet from a first data connection providing a pair of Access to remote data networks. The method includes determining from the downlink data packets 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.

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

Description of drawings

[0030] A more detailed description of the embodiments briefly described above will be presented by reference to the specific embodiments illustrated in the accompanying drawings. With the understanding that these drawings depict only some embodiments and are therefore not to be considered limiting of scope, embodiments will be described and explained with additional character and detail through the use of the accompanying drawings, in which:

1 is a schematic block diagram illustrating one embodiment of a wireless communication system for accessing a local data network via a mobile data connection;

[0032] FIG. 2A illustrates one embodiment of a network architecture for accessing a local data network via a mobile data connection; [0033] FIG. 2B illustrates another embodiment of a network architecture for accessing a local data network via a mobile data connection Embodiments; [0034] Figure 3A illustrates one embodiment of a process for accessing a local data network via a mobile data connection; [0035] Figure 3B illustrates another embodiment of a process for accessing a local data network via a mobile data connection An embodiment; [0036] FIG. 4 is a diagram illustrating one embodiment of an uplink packet flow for accessing a local data network via a mobile data connection;

[0037] FIG. 5A is a schematic block diagram illustrating one embodiment of an apparatus for accessing a local data network via a mobile data connection.

5B is a diagram illustrating another embodiment of an apparatus for accessing a local data network via a mobile data connection

Intent frame.

6 is a schematic flow diagram illustrating one embodiment of a method for accessing a local data network via a mobile data connection; and

[0040] FIG. 7 is a schematic flow diagram illustrating another embodiment of a method for accessing a local data network via a mobile data connection.

Detailed ways

[0041] As will be appreciated by one of ordinary skill in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects.

[0042] For example, the disclosed embodiments may be implemented as hardware circuits including custom very large scale integration "VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, and the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.

[0043] In addition, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and/or program code (hereinafter code) . Storage devices may be tangible, non-transitory, and/or non-transitory. The storage device may not reflect the signal. In a certain embodiment, the storage device uses only the signals used to access the code.

[0044] Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device that stores code. The storage device may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical or semiconductor system, device or device or any suitable combination of the foregoing.

[0045] More specific examples (non-exhaustive list) of storage devices would include the following: electrical connections with one or more wires, portable computer disks, hard disks, random access memory "RAM"), read only memory "ROM" ), erasable programmable read only memory "EPROM" or flash memory), portable compact disc read only memory "CD-ROM"), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0046] Reference throughout this document to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, unless expressly stated otherwise, the appearances of the phrases "in one embodiment," "in an embodiment," and similar language throughout may, but are not necessarily all referring to the same embodiment, but rather mean "one or more but not all examples". The terms "including", "including", "having" and variations thereof mean "including but not limited to" unless expressly stated otherwise. Unless expressly stated otherwise, the enumerated list of items does not imply that any or all items are mutually exclusive. The terms "a," "an," and "the" also mean "one or more" unless expressly stated otherwise.

[0047] Apart from the above, the features, structures or characteristics of the described embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, related

One skilled in the art will recognize that the embodiments may be practiced without one or more of the specific details or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0048] Aspects of the embodiments are described below with reference to schematic flowchart illustrations and/or block diagrams of methods, apparatus, systems and program products according to the embodiments. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. The 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 executed by the processor of the computer or other programmable data processing apparatus create the steps for implementing the schematic flowcharts and and/or means of the functions/acts specified in the schematic block diagrams.

The code may also be stored in a storage device, which may instruct a computer, other programmable data processing apparatus, or other device to operate in a particular manner, such that the instructions stored in the storage device result in an article of manufacture comprising the following: Instructions for the functions/acts specified in the schematic flowchart and/or schematic block diagram.

Code can also be loaded on a computer, other programmable data processing apparatus, or other equipment to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other equipment to produce a computer-implemented process such that in Code executing on a computer or other programmable device provides processes for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0051] The schematic flowchart diagrams and/or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions of the code for implementing the specified logical function(s).

[0052] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods are contemplated that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated figures.

[0053] Descriptions of elements in each figure may refer to elements of previous figures. The same numerals refer to the same elements throughout the drawings, including alternate embodiments of the same elements.

To address the above-mentioned problems of discovering locally available data services and efficiently routing data requests to the local data network, the UE receives a downlink packet with an indicator indicating when an established data connection becomes available access to the local data network, and in response, the UE enables access to the local data network via the data connection. Here, the UE determines by checking the indicator whether the data connection on the mobile communication network can provide connection to the local data network in addition to the connection to the remote data network. In one embodiment, the indicator is a flag in the header of the downlink packet. In some embodiments, the UE also determines a charging rate to apply to traffic to a local data network accessible via its data connection on the mobile communication network. Here, the downlink data packets may also include local charging rate parameters.

In order to efficiently route data requests for the local data network, the UE marks the traffic sent to its data connection on 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 some embodiments, the UE configures a virtual network interface that provides access to the local data network via the first data connection. All packets sent to this virtual network interface are transmitted via the first data connection, but are also marked with a local access request flag. The local access request flag is interpreted by the mobile network as an

According to the packet routing request to the local data network.

[0056] Note that the local access request flag is particularly useful for routing multicast/broadcast data packets, since the destination addresses in these packets cannot indicate whether they should be routed to the local data network or upstream to a remote data network. Additionally, the local access request flag is useful when the address space of the local data network overlaps the address space of the remote data network. In this case, routing cannot be based solely on the destination address. Furthermore, the local access request flag is useful for routing unicast DNS queries to DNS servers in the local data network when the UE does not know the addresses of the DNS servers in the local data network. In this case, the uplink classifier that receives 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.

[0057] FIG. 1 is a wireless communication system 100 for accessing a local data network via a mobile data connection in accordance with an embodiment of the present disclosure. In one embodiment, the wireless communication system 100 includes a remote unit 105 , a cellular base station unit 110 and a cellular communication link 115 . Even though a particular number of remote units 105, cellular base station units 110, and cellular communication links 115 are depicted in FIG. 1, those skilled in the art will recognize that any number of remote units 105, cellular base station units 110, and cellular communication links 115 may be included in the wireless communication system 100 .

[0058] In one embodiment, the wireless communication system 100 conforms to the 5G system specified in the 3GPP specifications. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication network, such as LTE or WiMAX, among others. The present disclosure is not intended to be limited by the implementation of any particular wireless communication system architecture or protocol.

In one embodiment, the remote unit 105 may include a computing device such as a desktop computer, laptop computer, personal digital assistant "PDA"), tablet computer, smart phone, smart television (eg, a television connected to the Internet) ), smart appliances (eg, internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, networking equipment (eg, routers, switches, modems), etc. In some embodiments, the remote unit 105 includes a wearable device such as a smart watch, fitness band, optical head mounted display, and the like. Additionally, remote unit 105 may be referred to as a subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or other terminology used in the art. Remote units 105 may communicate directly with one or more cellular base station units 110 via uplink "UL") and downlink "DL") communication signals. Additionally, UL and DL communication signals may be carried over the cellular communication link 115 .

[0060] In some embodiments, the remote unit 105 utilizes the mobile core network 120 to communicate with the remote data network 125 via a data connection. For example, the remote unit 105 may establish a data connection (also referred to as a "PDU session") with the remote data network 125 via the mobile core network 120 and the cellular base station unit 110 . A user plane function "UPF") 130 in the mobile core network 120 then relays traffic between the remote unit 105 and the remote data network 125 over the data connection. As shown, one or more of the UPFs 130 may be located outside the mobile core network 120 . In some embodiments, UPF 130 may access a local data network. While in the data path of the remote unit 105 data connection, the UPF 130 may provide the remote unit 105 with access to local data services (eg, print services, media/streaming services, HTTP services, file services, etc.).

[0061] The cellular base station units 110 may be distributed over a geographic area. In some embodiments, cellular base station unit 110 may also be referred to as an access terminal, base, base station, NodeB, eNB, gNB, Home NodeB, relay node, device, or otherwise known in the art any other terms used. The cellular base station units 110 are typically part of a radio access network ("RAN"), which may include one or more controllers communicatively coupled to one or more respective cellular base station units 110. These and other elements of the radio access network are not shown, but are generally known to those of ordinary skill in the art. The cellular base station unit 110 is connected to the mobile core network 120 via the RAN.

[0062] A cellular base station unit 110 may serve a service area, eg, a plurality of remote units 105 within a cell or cell sector, via a wireless communication link. Cellular base unit 110 may communicate directly with one or more remote units 105 via communication signals. Typically, cellular base unit 110 transmits downlink "DL") communication signals to serve remote units 105 in the time, frequency and/or spatial domains. Additionally, DL communication signals may be carried over the cellular communication link 115 . The cellular communication link 115 may be any suitable carrier in the licensed or unlicensed radio spectrum. The cellular communication link 115 facilitates communication between one or more remote units 105 and/or one or more cellular base station units 110 .

In one embodiment, the mobile core network 120 is a 5G core network ("5GC") or an evolved packet core network ("EPC"), which may be coupled to other networks such as the Internet and private data networks and other packet data networks . Each mobile core network 120 belongs to a single public land mobile network "PLMN"). The present disclosure is not intended to be limited by the implementation of any particular wireless communication system architecture or protocol.

[0064] As shown, the mobile core network 120 includes a UPF 130 and a session management function "SMF") 140. Although a specific number of UPFs 130 and SMFs 140 are depicted in FIG. 1 , those skilled in the art will recognize that any number of UPFs 130 and SMFs 140 may be included in the mobile core network 120. UPF 130 provides user plane (eg, data) services to remote unit 105 . The data connection between the remote unit 105 and the data network is managed by the UPF 130 . SMF 140 manages remote unit 105 data sessions, such as the PDU sessions discussed above. In some embodiments, SMF 140 may add or modify data paths for data connections used by remote units 105 . For example, SMF 140 may insert new UPF 130 into the data path and/or configure UPF 130 to provide access to local data network 135 .

[0065] As discussed in more detail below, UPF 130 may indicate the availability of local data services (eg, in local data network 135) to remote units 105 that already have data connections to remote data network 125. Here, UPF 130 may flag one or more downlink packets to indicate the availability of local data services. Interested remote units 105 may discover one or more local data services and flag uplink packets for routing via local data network 135 . This marking in the uplink packet is interpreted by the mobile network (eg, UPF 130 ) as a request from the remote unit 105 to route the data packet to the local data network 135 .

[0066] Figures 2A-2B depict a network architecture for accessing a local data network via a mobile data connection in accordance with an embodiment of the present disclosure. Figure 2A depicts the network architecture 200 at a first moment. Network architecture 200 includes UE 205, RAN 210, core network 215, first UPF 220 and remote data network 1250 UE 205 is a 5G UE and may be an embodiment of the remote unit 105 discussed above, core network 215 is a 5G core network, And may be an embodiment of the mobile core network 120 discussed above, and the first UPF 220 may be an embodiment of the UPF 130 discussed above. The remote data network may be substantially as described above with reference to FIG. 1 , and the RAN 210 may include a cellular base station unit 110 . In some embodiments, RAN 210 is a 3GPP RAN (eg, E-UTRAN or 5G-RAN). In other embodiments, RAN 201 may be a non-3GPP RAN (eg, a Wi-Fi network).

2A shows that UE 205 has established a data connection 221 that supports access to remote data network 125 and services available in remote data network 125. In some embodiments, remote data network 125 is a private enterprise network, while in other embodiments, remote data network 125 represents the entire Internet. In some embodiments, data connection 221 is a PDU session. The data path of the data connection 221 consists of three concatenated interfaces: the radio interface (Uu) between the UE and the RAN, the backhaul interface (N3) between the RAN and the first UPF 220 in the 5G core network and the first UPF 220 and the N6 interface between the remote data network 125. Although only one UPF is shown, in other embodiments, multiple UPFs may be in the data path. For example, in the case of roaming where the data path is extended to the home network, one UPF is required in the visited network and another UFP is required in the home network.

[0068] FIG. 2B depicts a network architecture 225 for accessing a local data network via a mobile data connection. The network architecture 225 may be an embodiment of the network architecture 200 at another point in time (eg, a future time after the UE 205 moves to a different location). Here, the network architecture 225 includes the elements of the network architecture 200 and further includes the second UPF 230 in the data path of the data connection 221 . The second UPF 230 may be one embodiment of the UPF 130 discussed above. The first UPF 220 and the second UPF 230 communicate using the N9 interface.

[0069] When the UE 205 moves to an area (eg, mall, airport, enterprise, stadium, etc.) that supports local data services (eg, print services, media services, HTTP services, Mobile Edge Computing "MEC") services, etc., The data path of the data connection 221 may be reconfigured by the core network 215 (eg, by the SMF in the core network 215) to support access to the local data network 135, as shown in Figure 2B. For example, the SMF in the core network 215 may insert the second UPF 230 into the data path of the data connection 221 . Here, the second UPF 230 supports access to the local data network 135 via the second instance of the N6 interface. Note that the primary role of the second UPF 230 is to receive data traffic from the UE 205 and determine how to route the traffic. The second UPF 230 either forwards the traffic to an upstream UPF (eg, the first UPF 220 ) to reach the remote data network 125 or forwards the traffic to the local data network 135 .

After inserting the second UPF 230 into the data path of the data connection 221, the second UPF 230 marks each downlink packet sent to the UE 205 with a "local access available" flag, which is indicative of local service New logo for usability. For example, the local data network 135 may enable a user of the UE 205 to print documents to a local print server and/or consume audio/video content from a local media server. When the UE 205 begins to receive packets via the data connection 221 containing the local access available flag, the UE 205 determines that the data connection 221 provides access to the local data network 135 in addition to access to the remote data network 125 . In turn, the UE 205 may use the DHCP protocol to request IP configuration data (eg, IP address, netmask, domain name, DNS server address, etc.) for accessing the local data network. Additionally, UE 205 may discover local services and enable access to local data network 135 via data connection 221 .

Because some UEs may not care about locally available services and because there may be hundreds of services available in the local data network 135, the local access available flag indicates that access to the local data network is available, but not which Services can be used to minimize packet overhead. In this way, interested UEs can then discover locally available services. As an example, the local access available flag (also referred to herein as the "local data available" flag) may be a one-bit flag in the header of the downlink packet.

[0072] The second UPF 230 adds the local access available flag to every X downlink packets. In some embodiments, the value of X is 1, such that each downlink packet contains a local access available flag. In other embodiments, the value of X is greater than 1, such that not every packet includes the local access available flag. Here, the network operator may set the value of X (eg, define the frequency including the local access available flag).

[0073] In addition to the local access available flag, the second UPF 230 may mark one or more downlink packets sent to the UE 205 with a "local charging rate" parameter that indicates The charging rate applied to data traffic sent by the UE 205 and routed to the local data network 135 via the data connection 221 . For example, the parameter may be two bits encoded as the following fraction relative to the billing rate applied to traffic to the remote data network 125 over the data connection 221: '00', for free; '01 ', for 25% billing rate; '10', for 50% billing rate; and, '11', for 75% billing rate. Note that the charging rate may be UE 205 specific. In one embodiment, the second UPF 230 marks each downlink packet with a local charging rate parameter. In other embodiments, the second UPF 230 marks only some downlink packets with the local charging rate parameter to minimize packet overhead. Whenever the local charging rate changes, the second UPF 230 updates the charging rate parameter in the downlink packet accordingly.

[0074] In some embodiments, the second UPF 230 indicates the availability of the local data network by including a local charging rate parameter in the downlink data packets. Here, the local access available flag may be omitted since the presence (or absence) of the local charging rate parameter also indicates to the UE 205 whether access to the local data network is available. Here, the second UPF 230 may add the local charging rate parameter to every X downlink packets whenever access to the local data network 135 is available, where the value of X is set by the network operator.

[0075] As an example, when the UE 205 knows that it has access to the local data network 135, the UE 205 behaves the same as when it would normally configure a new network access. That is, UE 205 broadcasts a Dynamic Host Configuration Protocol "DHCP") request (via data connection 221) to discover a DHCP server in local data network 135, and then requests from the DHCP server to provide IP configuration data including IP address, netmask code, domain name, DNS server address, etc. Afterwards, the UE 205 is configured with two IP addresses on the same data connection 221: one IP address assigned when the data connection 221 is established and another IP address assigned using DHCP after receiving the local access available flag. Here, the first IP address is used for communication with the remote data network 125 and the latter IP address is used for communication with the local data network 135 . Note that the above DHCP request broadcast by UE 205 may include a local access request flag in order to be routed to local data network 135.

As a second example, when the UE 205 knows that it has access to the local data network 135, the UE 205 may attempt to discover locally provided services (eg, print services, media services, streaming services, etc.) and provide its applications and users Notify discovered services. As a third example, when the UE 205 knows that it has access to a local data network that supports reduced or no-billing data communications, the UE 205 can notify its application, which can then start content retrieval (eg, start downloading firmware) update), which would be much more expensive on the remote data network 125. As a fourth example, when the UE 205 knows that it has access to the local data network, the UE 205 may use the Web Proxy Autodiscovery ("WPAD") protocol to discover and use HTTP proxies available in the local data network to improve subsequent web browsing experience, as requests for locally cached content in the HTTP proxy can be served very quickly.

[0077] In some embodiments, the UE 205 initiates service discovery by using Simple Service Discovery Protocol ("SSDP") or Multicast DNS ("mDNS") protocols to discover some of the services available in the local data network. For example, the UE 205 may initiate discovery of print servers and/or media servers in the local data network by sending an SSDP search request or mDNS query. In some embodiments, the UE 205 initiates the WPAD protocol to discover and use HTTP proxies in the local data network. After discovering the HTTP proxy in the local data network, the UE 205 can configure its network layer to direct all HTTP traffic of the UE 205 through the HTTP proxy server in the local data network.

[0078] After having discovered one or more local data services, the UE 205 may indicate to the network (eg, the second UPF 230) which uplink packets should be routed to the local data network. This is primarily needed when the destination address of an uplink packet cannot be used as described above, eg using an uplink classifier to determine whether a packet should be routed to a local data network or a remote data network. Here, UE 205 marks uplink packets intended for local data network 135 with a "local access request" flag, which is a new flag indicating packets routed to the UPF. The second UPF 230 routes packets marked with the local access request flag to the local data network 135 unless network policy in the second UPF 230 prevents such routing.

[0079] If the UE 205 receives IP configuration data from the local data network 135 (eg, in response to a DHCP request), the UE 205 becomes aware of the address space of the local data network 135. For example, UE 205 may know that all IP addresses in local data network 135 are "192.168.x.y". Thus, packets sent for the local data network 135 will have the destination address "192.168.xy" and can be used by the second UPF 230 for routing without the need for a local access request flag. However, in the case of multicast and/or broadcast traffic or in the case of overlapping address spaces of remote data network 125 and local data network 135

In this case, the local access request flag can still be used.

[0080] In some embodiments, UE 205 configures a new "virtual" network connection that provides access to local data network 135 via data connection 221. In one embodiment, all data packets sent to this virtual network interface are sent via data connection 221, but are also marked with a local access request flag. Referring to the above example, the UE 205 will mark all service discovery requests (eg, SSDP, mDNS requests) and all DHCP requests with a local access request flag to ensure routing to the local data network 135 . In addition, the UE 205 may use the local access request flag to mark local service requests (e.g., print requests, streaming requests) when these requests cannot be routed based on the destination address, e.g. ).

[0081] In some 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 1 may indicate that the uplink packet is to be routed to the local data network 135, while a value of 0 may indicate that the uplink packet is to be routed to the first UPF 220 and the remote data network 125. Note that each packet exchanged over the Uu, N3 and N9 interfaces is prefixed with a specific header that contains metadata about the packet. In some embodiments, the local access available flag, the local access request flag and the local charging rate parameter may be included in the header as additional metadata.

[0082] FIG. 3A depicts a first process 300 for accessing a local data network via a mobile data connection in accordance with an embodiment of the present disclosure. The first process 300 involves the UE 205 , the first UPF 220 , the second UPF 230 , the remote data network 125 and the local data network 135 . Here, the local data network 135 includes a print server 301 that provides local print services. The first process 300 begins sometime after the first data connection 303 is established between the UE 205 and the remote data network 125 (eg, via a mobile communication network). The first data connection 303 may be one embodiment of the data connection 221 discussed above. Initially, the path of the data connection is through the first UPF 220 but not through the second UPF 230 .

[0083] At some point, the path of the first data connection 303 is modified (eg, in response to the UE 205 moving to a new area), and a new UPF (eg, the second UPF 230) is added to the data path (see block 305) ). Here, downlink traffic from the remote data network 125 is first delivered to the first UPF 220, then to the second UPF 230, and finally to the UE 205 via the RAN (not shown in Figure 3A). Since the UPF is transparent to the UE 205, the UE 205 is unaware of the path modification to the first data connection 303.

Since the local data network 135 is accessible to the UE 205 via the second UPF 230, the second UPF 230 starts marking the DL data packets with the "local data available" flag and sends the marked DL data packets to UE 205 (see block 310). For example, the second UPF 230 may set a flag bit in the packet header of the downlink packet. The local data available flag indicates to the UE 205 that access to the 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 205 knows that it has access to the local data network, the UE 205 may attempt to discover local services and/or may attempt to request IP configuration data (eg, via DHCP) for the local data network. For example, the UE 205 may be configured with a policy to utilize local services whenever available.

[0085] As shown, the UE 205 discovers available local services by issuing one or more mDNS query packets marked with a "local data request" flag (see block 315). Here, the mDNS query packet allows the UE 205 to discover which services are available via the local data network 135. The local data request flag indicates to the second UPF 230 that the mDNS query packet should be sent to the local data network 135 instead of the first UPF 220 and the remote data network 125.

[0086] Upon receipt of one or more mDNS query packets marked with a "local data request" flag, the second UPF 230 forwards the packets to the local data network 135 (see block 320). When forwarding the uplink packet to the local data network 135, the second UPF 230 modifies the packet header (eg, using network address and port translation "NAPT") to allow local data

according to the routing in network 135 . Because the original source IP address may not be routable in the local data network 135, the second UPF 230 changes the source IP address to its own IP address and changes the source port number to its own source port. The second UPF 230 stores the IP address/port number mapping.

[0087] One or more devices in the local data network 135 may respond to mDNS queries (see block 325). Here, at least the print server 301 sends a DNS response to the mDNS query. When the query uses multicast DNS, the response can be a unicast DNS response. The second UPF 230 receives the DNS response from the local data network 135 and forwards the response to the UE 205 (see block 330). Here, the second UPF 230 performs NAPT again to modify the destination IP address and destination port number back to the original IP address/port number used by the UE 205.

[0088] After receiving the DNS response, the UE 205 determines the services available via the local data network 135. Here, the UE 205 identifies at least the locally available print services provided by the local print server 301 from the DNS response (see block 335). Additionally, the UE 205 makes the discovered services (including the discovered print service of the print server 301 ) available to its applications. When an application on the UE requests to print a document to print server 301 (see block 340 ), UE 205 sends a sequence of packets (eg, corresponding to a print job) to the IP address of print server 301 . These uplink packets are also marked with a local data request flag to ensure that the second UPF 230 routes the print job to the local data network 135 . Note that if packets addressed to the print server 301 are not also marked with a local data request flag, the second UPF 230 can route these packets to the first UPF 220 and the remote data network 125, especially when the address of the remote data network When there is overlap between the space and the address space of the local access network.

[0089] FIG. 3B depicts a second process 355 for accessing a local data network via a mobile data connection in accordance with an embodiment of the present disclosure. The second process 355 involves the UE 205 , the first UPF 220 , the second UPF 230 , the remote data network 125 and the local data network 135 . Here, the local data network 135 includes an HTTP proxy 307 that provides local HTTP proxy services. The second process 355 begins sometime after the first data connection 303 is established between the UE 205 and the remote data network 125 (eg, via a mobile communication network). Initially, the path of the first data connection 303 passes through the first UPF 220 , but not through the second UPF 230 .

[0090] At some point, the path of the first data connection 303 is modified (eg, in response to the UE 205 moving to a new area), and a new UPF (eg, the second UPF 230) is added to the data path (see block 305) ). Because the local data network 135 is accessible to the UE 205 via the second UPF 230, the second UPF 230 starts marking the DL data packets with the "local data available" flag, indicating to the UE 205 that access to the local data network is available (See box 360). Additionally, the second UPF 230 includes a "local billing rate" parameter (see block 360). In some embodiments, the second UPF 230 sends the local charging rate parameter in the first N DL packets. Here, N is a predetermined amount, eg 10, and can be configured by the network operator. In the embodiment of Figure 3B, the local charging rate parameter indicates to the UE 205 that access to the local data network 135 is provided free of charge.

[0091] As shown, the UE 205 discovers available local services by issuing one or more unicast DNS query packets marked with a "local data request" flag (see block 365). The local data request flag indicates to the second UPF 230 that the DNS query packet should be sent to the local data network 135 instead of the first UPF 220 and the remote data network 125. In the event that the UE 205 attempts to discover an HTTP proxy in the local data network 135, the UE 205 may send DNS query packets according to the WPAD protocol.

[0092] Upon receipt of one or more unicast DNS query packets marked with a "local data request" flag, the second UPF 230 forwards these packets to the local data network 135 (see block 320). When forwarding the uplink packet to the local data network 135, the second UPF 230 modifies the packet header using NAPT. Here, the second UPF 230 may change the destination IP address to include the IP address of the DNS server (not shown in FIG. 3B ) in the local data network 135, rather than the remote data network

IP address of the DNS server in the network. Additionally, the second UPF 230 changes the source IP address and source port number in order to route the response back to the second UPF 230.

[0093] The DNS server in the local data network 135 sends a DNS response to the second UPF 230 (see block 325). The second UPF 230 forwards the response to the UE 205 (see block 330). Here, the second UPF 230 performs NAPT again to modify the destination IP address and destination port number back to the original IP address/port number used by the UE 205 in its DNS request.

[0094] The UE 205 discovers the HTTP proxy 307 from the DNS response (see block 370). The DNS response from the local DNS server includes the URL of the WPAD file, which includes the auto-configuration script. The UE 205 retrieves the WPAD file by initiating an HTTP GET operation and configures its HTTP stack to use the discovered HTTP proxy 307 in the local data network 135 based on the contents of the WPAD file (see block 375).

[0095] The UE 205 sends subsequent HTTP requests to the discovered HTTP proxy 307 in the local data network 135. All of these requests are marked with a "local data request" flag to ensure that they are routed to the local data network 135 (see block 380). The performance of the HTTP-based service can then be improved because the requested content can be retrieved from the HTTP proxy 307's local cache.

[0096] FIG. 4 depicts a UE model for supporting data traffic to a remote data network and to a local data network via the same data connection. UE 400 may be one embodiment of remote unit 105 and/or UE 205 discussed above. The UE 400 includes one or more UE applications 405 installed thereon that generate uplink data 407. The UE applications pass the uplink data 407 to a network stack 410 that generates uplink packets 413. Here, the uplink packet 413 includes a header and a payload. The network stack 410 determines the network connection for each uplink packet 413. Those uplink packets 413 that should reach the local data network 135 (eg, because they are used for services in the local data network) are sent to the virtual network interface 415 . At the virtual network interface 415 , each uplink packet is marked with a "local access request" flag (also referred to as a local data request), forming a marked uplink packet 417 . Those uplink packets 413 that are not destined for the local data network 135 are not marked. Then, both marked and untagged uplink packets 413 are sent to the first data connection 420 for transmission over the mobile network (eg, to the RAN). First data connection 420 may be substantially similar to data connection 221 and first data connection 303 discussed above. When the UE 400 uses the DHCP protocol as described above to receive When accessing the IP data configuration of the local data network, the IP data configuration is used to configure the virtual network interface 415 . For example, virtual interface 415 may be assigned an IP address received from a DHCP server in the local data network.

[0097] FIG. 5A depicts one embodiment of an apparatus 500 that may be used to access a local data network via a mobile data connection in accordance with embodiments of the present disclosure. Apparatus 500 includes one embodiment of remote unit 105 . Additionally, the remote unit 105 may include a processor 505, a memory 510, an input device 515, a display 520, a transceiver 525 for communicating over an access network (eg, 3GPP RAN or WLAN). In some embodiments, input device 515 and display 520 are combined into a single device, such as a touch screen. In some embodiments, the remote unit 105 may not include any input device 515 and/or display 520 .

[0098] In one embodiment, the processor 505 may include any known controller capable of executing computer readable instructions and/or capable of performing logical operations. For example, processor 505 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processing unit ("GPU"), auxiliary processing unit, field programmable gate array ("FPGA"), or similar programmable control device. In some embodiments, processor 505 executes instructions stored in memory 510 to perform the methods and routines described herein. Processor 505 is communicatively coupled to memory 510 , input device 515 , display 520 and transceiver 525 .

[0099] In some embodiments, the processor 505 receives downlink data packets from a first data connection (eg, data connection 221, first data connection 303 and/or first data connection 420) over the mobile communication network. Here, the first data link

Access to remote data network 125 is then provided to remote unit 105 . The processor 505 determines from the downlink data packets whether the first data connection provides access to the local data network 135 in addition to the remote data network 125 . In response to the first data connection providing access to the local data network 135 , the processor 505 accesses one or more services via the local data network 135 .

In some embodiments, the processor 505 examines a flag (eg, a "local access availability" flag) in the header of the downlink data packet to determine whether the first data connection provides access to the local data network 135 . Here, a flag (eg, a local access availability flag) indicates whether the first data connection provides access to the local data network 135 . For example, when set (eg, to a binary "1"), the flag indicates that the local data network 135 can be accessed via the first data connection. If the flag is not set, the processor 505 determines that no local data network 135 can be accessed via the first data connection.

[0101] In some embodiments, the downlink data packet further includes a charging rate parameter. For example, the charging rate parameter can be inserted into the packet header. The billing rate parameter indicates the billing rate applied to data traffic sent by the remote unit 105 to the local data network 135 via the first data connection. The billing rate may be specific to the remote unit 105 . For example, a certain model, manufacturer, or device associated with a certain subscription may be charged at a different rate than other devices. In parsing the billing rate parameters, the processor 505 may notify one or more applications installed at the remote unit 105 of a new network interface (if available) (eg, virtual network interface 415) that supports free data communication or Data communications are supported at reduced billing rates. In one embodiment, the billing rate applied to data traffic sent by the remote unit 105 via the first data connection to the local data network 135 is different from the default billing rate for data traffic sent by the remote unit 105 via the first data connection only The processor 505 notifies the application until the rate is reached.

In some embodiments, the processor 505 determines whether a charging rate parameter is present in the downlink data packet (eg, in the packet header of the downlink data packet) to determine whether the first data connection provides local Access to data network 135 . 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 125 and the local data network 135 . In such an embodiment, the processor 505 determines that no local data network 135 can be accessed via the first data connection whenever the downlink data packet does not include a charging rate parameter.

[0103] In some embodiments, the processor 505 accesses one or more services via the local data network 135 via the virtual network interface 530 configured to access the local data network 135 via the first data connection. Virtual network interface 530 may be one embodiment of virtual network interface 415 discussed above. After receiving the local data available flag, configuration of the virtual network interface 530 may be performed by using the DHCP protocol to request and receive IP configuration data including IP addresses, netmasks, domain names, addresses of DNS servers, and the like. In such an embodiment, the processor 505 may mark each uplink packet sent to the virtual network interface 415 with a flag (eg, a "local access request" flag). Here, the flag requests that uplink packets be routed to the local data network 135 .

[0104] In some embodiments, the processor 505 accesses one or more services via the local data network 135 by sending a service discovery request to the local data network 135. For example, the processor 505 may send DNS query packets, including mDNS query packets. As another example, the processor 505 may send Simple Service Discovery Protocol ("SSDP") packets. The processor 505 marks the service discovery request (eg, marks the request with a local access request flag) to request routing of the service discovery request (eg, DNS query or SSDP packet) to the local data network 135 .

[0105] In some embodiments, accessing one or more services via the local data network 135 includes the processor 505 discovering the HTTP proxy 307 in the local data network 135. In such an embodiment, the processor 505 sends the HTTP traffic to the discovered HTTP proxy 307 in the local data network 135 . In other embodiments, access is via the local data network 135

One or more services include the processor 505 requesting IP configuration data by using the DHCP protocol, and using the received IP configuration data to configure a new network interface (eg, virtual network interface 530) that supports data communication with the local data network. ).

[0106] In some embodiments, the processor 505 receives uplink packets (eg, from an application installed on the remote unit 105) and determines whether to send the uplink packets to the local data network 135. For example, the uplink packets may belong to a local service provided by the local data network 135 . As another example, uplink packets may not belong to a local service, but may only need to be routed via the local data network 135 (eg, to reduce costs).

[0107] If the processor 505 determines that the uplink packet should arrive at the local data network 135, the processor 505 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 135 . After marking the uplink packet, the processor 505 sends it via the first data connection. Upon receiving an uplink packet and detecting a flag (eg, a local access request flag), the UPF routes the flagged packet to the local data network 135 .

[0108] In one embodiment, the memory 510 is a computer-readable storage medium. In some embodiments, memory 510 includes volatile computer storage media. For example, memory 510 may include RAM, including dynamic RAM ("DRAM), synchronous dynamic RAM ("SDRAM), and/or static RAM ("SRAM). In some embodiments, memory 510 includes non-volatile computer storage media. For example, memory 510 may include a hard drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 510 includes both volatile and non-volatile computer storage media.

[0109] In some embodiments, memory 510 stores data related to accessing a local data network via a mobile data connection. In some embodiments, memory 510 also stores program code and related data, such as an operating system or other controller algorithms and one or more software applications running on remote unit 105 .

[0110] In one embodiment, the input device 515 may include any known computer input device, including a touchpad, buttons, keyboard, stylus, or microphone, and the like. In some embodiments, input device 515 may be integrated with display 520, eg, as a touch screen or similar touch-sensitive display. In some embodiments, input device 515 includes two or more different devices, such as a keyboard and a touchpad. In some embodiments, input device 515 may include a camera for capturing images or otherwise inputting visual data.

[0111] In one embodiment, the display 520 may comprise any known electronically controllable display or display device. Display 520 may be designed to output visual, audible and/or tactile signals. In some embodiments, display 520 includes an electronic display capable of outputting visual data to a user. For example, display 520 may include, but is not limited to, an LCD display, LED display, OLED display, projector, or similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, display 520 may include a wearable display, such as a smart watch, smart glasses, heads-up display, and the like. Additionally, display 520 may be a component of a smartphone, personal digital assistant, television, desktop computer, notebook (laptop) computer, personal computer, vehicle dashboard, or the like.

[0112] In some embodiments, the display 520 includes one or more speakers for producing sound. For example, display 520 may generate an audible alarm or notification (eg, a beep or chime). In some embodiments, display 520 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of display 520 may be integrated with input device 515 . For example, input device 515 and display 520 may form a touch screen or similar touch-sensitive display. In other embodiments, display 520 may be located near input device 515 .

[0113] The transceiver 525 communicates with a mobile communication network (eg, PLMN) through an access network such as a 3GPP RAN or WLAN. In some embodiments, the mobile communication network includes the cellular base station unit 110 and the mobile core discussed above with reference to FIG. 1

network 120. The transceiver 525 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 for providing UL communication signals to the cellular base station unit 110 and one or more receivers for receiving DL communication signals from the cellular base station unit 110 . Transceiver 525 supports virtual network interface 530 used in sending uplink packets to local data network 135 .

[0114] FIG. 5B depicts an apparatus 550 that may be used to access a local data network via a mobile data connection. Apparatus 550 includes one embodiment of UPF 130 in a data path of a first data connection (eg, data connection 221, first data connection 303, and/or first data connection 420). Additionally, UPF 130 may include processor 555 , memory 560 , and transceiver 575 supporting one or more network interfaces 580 . It will be appreciated that processor 555 and memory 560 may be substantially similar to processor 505 and memory 510, respectively. In some embodiments, UPF 130 also includes input device 565 and output device 570, which may be substantially similar to input device 515 and output device 520 described above. Processor 555 is communicatively coupled to memory 560 , input device 565 , output device 570 , and transceiver 575 .

[0115] In some embodiments, the processor 555 provides: a first network interface 5804 that supports communication with the UE over a first data connection (eg, data connection 221, first data connection 303, and/or first data connection 420) communication; the second network interface 580B, which supports communication with the SMF 140. Processor 555 determines whether the first data connection (eg, data connection 221 ) is configured to provide access to local data network 135 in addition to remote data network 125 . Here, the first data connection provides the remote unit 105 with access to the remote data network 125 . This determination is based on information received from the SMF 140 via the second network interface 5808. In response to determining to configure the first data connection to provide access to the local data network, the processor 555 activates a third network interface 580 in communication with the local data network 135.

[0116] In response to activating the third network interface 580C, the processor 555 sends the downlink data packets to the remote unit 105 over the first data connection. Here, the downlink data packet includes an indicator that the first data connection provides access to the local data network. The processor 555 also provides access to the one or more services to the remote unit 105 via the local data network 135 using the third network interface.

[0117] In some embodiments, the processor 555 indicates that the first data connection supports access to the local data network 135 by setting a local access availability flag in the header of the downlink data packet. In some embodiments, in response to activating the third network connection, the processor 555 inserts a local access availability flag into every X downlink data packets of the first data connection. Here, X may be a value chosen by the network operator.

[0118] In some embodiments, the processor 555 further sets charging rate parameters in the header. Here, the charging rate parameter indicates the charging rate applied to data packets sent by the remote unit 105 to the local data network 135 . In one embodiment, in response to activating the third network interface, the processor 555 sends the charging rate parameter only in a predetermined number of downlink packets. In another embodiment, processor 555 transmits the charging rate parameter in a predetermined number of downlink packets in response to determining that the charging rate applied to data packets sent by the remote unit to the local data network has changed.

[0119] In some embodiments, the processor 555 instructs the first data connection to provide access to the local data network 135 by placing a charging rate parameter in the 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 135 .

In certain embodiments, the processor 555 provides the remote unit 105 with access to one or more services via the local data network 135 by receiving the uplink packet over the first data connection, determining the uplink whether the link packet includes a local access request flag request, and the uplink packet is routed via the third network interface in response to the uplink packet including the local access request flag request. In other embodiments, the processor 555 provides the remote unit 105 with access to one or more services via the local data network 135 by receiving the uplink via the first data connection

routing the packet, 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.

[0121] The transceiver 575 includes communication hardware for communicating with elements of the mobile communication network (eg, the core network 215, the SMF 140, the additional UPF 130, and the RAN such as the RAN 210). The transceiver 575 supports a first network interface 5804 for facilitating communication between the remote unit 105 and the remote data network 125. Here, the first network interface D580A may communicate with the RAN using the N3 backhaul interface. The transceiver 575 also supports a second network interface 5808 for communicating with the SMF 140 . The transceiver 575 further supports a third network interface 580 for facilitating communication between the remote unit 105 and the local data network 135. [0122] The transceiver 575 also communicates with a packet data network, such as using the first network interface 580A to communicate with remote data network

125 or use the third network interface 580(: to communicate with the local data network 135. Here, the first network interface 580A can use the N6 interface to communicate with the remote data network 125, and the third network interface 580C can also use the N6 interface to communicate with the local data network 125. The network 135 communicates. When the UPF 130 supports the N6 interface to the packet data network, the UPF 130 is said to support the anchor function.

[0123] In some embodiments, the transceiver 575 is also configured to communicate with one or more additional UPFs 130, eg, using the first network interface 580A. Here, the first network interface D580A may use the N9 interface for communicating with the UPF 130. The transceiver 575 may also communicate with the SMF 140, eg, using the second network interface 580B. In some embodiments, the processor 555 may control the first data connection to provide the remote unit 105 with access to the local data network 135 by activating the third network connection 580C, as described herein.

[0124] FIG. 6 is a schematic flow diagram illustrating one embodiment of a method 600 for accessing a local data network via a mobile data connection according to an embodiment of the present disclosure. In some embodiments, method 600 is performed by a device such as remote unit 105 or UE 205 . In some embodiments, method 600 may be performed by a processor executing program code, eg, a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, or FPGA, or the like.

[0125] The method 600 may include receiving 605 a downlink data packet at the remote unit from the first data connection over the mobile communication network. Here, the first data connection provides access to a remote data network. The first data connection may be the data connection 221 , the first data connection 303 and/or the first data connection 420 discussed above.

[0126] The method 600 includes determining 610 from the downlink data packets whether the first data connection provides access to a local data network in addition to the remote data network. In some embodiments, determining 610 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 there is a count in the packet header of the downlink data packet Rate parameter. Here, the presence of the charging rate parameter indicates that the first data connection provides access to the local data network.

[0127] In some embodiments, determining 610 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 the header of the downlink data packet for Local access availability flag. In such an embodiment, the local access availability flag indicates whether the first data connection provides access to the local data network. In a further embodiment, the header may include a charging rate parameter in the header, the charging rate parameter indicating the charging rate applied to data traffic sent by the apparatus via the first data connection to the local data network. Here, the method 600 may additionally include a remote unit that informs an application installed thereon of the billing rate applied to data traffic sent by the device to the local data network.

[0128] The method 600 also includes, in response to determining that the first data connection provides access to the local data network, accessing 615 one or more services in the local data network. In one embodiment, accessing 615 one or more services in the local data network includes requesting and receiving IP configuration data (eg, by using the DHCP protocol), and utilizing the data configuration to provide access to the local data network virtual network connection. In some embodiments, for example, when the

Uplink packets sent via the virtual network interface are not marked with a local access request flag when the destination address is considered sufficient for routing the packet to the local data network. In other embodiments, for example, when the destination address in the uplink packet is insufficient for routing the packet to the local data network (eg, in a multicast/broadcast packet), the uplink sent via the virtual network interface Packets are marked with a local access request flag.

In one embodiment, accessing 615 one or more services in the local data network includes discovering a hypertext transfer protocol ("HTTP") proxy in the local data network and sending HTTP traffic to the local data network The discovered HTTP proxy in . In another embodiment, accessing 615 one or more services in the local data network includes sending a service discovery request to the local data network. In further embodiments, method 600 can include the remote unit sending a service discovery request, including sending a DNS query packet or SSDP packet marked with a local access request flag, wherein the local access request flag requests routing of the DNS query or SSDP packet to the local data network.

[0130] In some embodiments, the method 600 further includes determining whether the uplink packet should arrive at the local data network. In response to determining that the uplink packet should arrive at the local data network, method 600 includes marking the uplink packet with a local access request flag. The method 600 further includes sending an uplink packet via the first data connection, wherein the local access request flag requests routing of the uplink packet to the local data network. Method 600 ends.

[0131] FIG. 7 is a schematic flow diagram illustrating one embodiment of a method 700 for accessing a local data network via a mobile data connection according to an embodiment of the present disclosure. In some embodiments, method 700 is performed by a device such as UPF 130 or second UPF 230 . In some embodiments, method 700 may be performed by a processor executing program code, eg, a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, or FPGA, or the like.

[0132] The method 700 can include establishing 705 a first data connection with the remote unit over the first network interface. Here, the first data connection provides the remote unit's access to the remote data network. The method includes communicating 710 via a second network interface with a session management function "SMF") and determining 715 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 enter. In response to determining to configure the first data connection to provide access to the local data network, the method includes activating 720 a third network interface in communication with the local data network.

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

[0134] In some embodiments, method 700 further 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, the charging rate parameter is only inserted into a predetermined number of downlink packets in response to activating the third network interface. In another embodiment, the charging rate parameter is only inserted into a predetermined number of downlink packets in response to determining that the charging rate applied to data packets sent by the remote unit to the local data network has changed.

[0135] In some embodiments, sending 725 a downlink data packet that includes an indicator that the first data connection provides access to the local data network includes placing the charging rate parameter in a packet header of the downlink data packet middle. Here, the presence of the charging rate parameter indicates that the first data connection provides access to the local data network.

[0136] The method includes providing 730 access to one or more services to the remote unit via the local data network using a third network access. In some embodiments, the remote unit is provided 730 with access to one or more services in the local data network

The task includes: determining whether the 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 . Method 700 ends.

[0137] The embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Accordingly, the scope of the invention is indicated by the appended claims rather than the foregoing description. All changes that come within the meaning and equivalency range of the claims are included within their scope.

CN 110313197 B