WO2025178613A1

WO2025178613A1 - Method and apparatus for allocating network addresses in a satellite communications system

Info

Publication number: WO2025178613A1
Application number: PCT/US2024/016551
Authority: WO
Inventors: Stephen O'NEAL
Original assignee: Viasat Inc
Current assignee: Viasat Inc
Priority date: 2024-02-20
Filing date: 2024-02-20
Publication date: 2025-08-28
Anticipated expiration: 2026-08-20

Abstract

Described techniques provide reduced delays with respect to a satellite communications system (SCS) assigning network addresses to personal electronic devices (PEDs) attempting to gain Internet access through a user terminal (UT) of the satellite communications system.

Description

METHOD AND APPARATUS FOR ALLOCATING NETWORK ADDRESSES IN A SATELLITE COMMUNICATIONS SYSTEM

TECHNICAL FIELD

[0001] Methods and apparatuses disclosed herein relate to the allocation and management of network addresses in a satellite communications system.

BACKGROUND

[0002] Operating a satellite communications system (SCS) as an access network for providing Internet Protocol (IP) based communications to personal equipment devices (PEDs), such as computers, smart phones, and like, requires that each PED obtain a network address — an IP address — that is managed within the SCS domain. For example, a dynamic host configuration protocol (DHCP) server in a core network (CN) of the SCS assigns and manages IP addresses within the SCS domain.

[0003] In an example scenario, a PED connects to a user terminal (UT) that is configured for operation in the SCS, such as being configured for operation as a gateway device supporting the connection of secondary devices to the SCS and, ultimately, the Internet. For example, a UT provide local access network (LAN) or wireless LAN (WLAN) connectivity to PEDs as secondary devices, within a residence, an office, or other locale.

[0004] To obtain an IP address, a given PED and the DHCP server of the SCS may employ a corresponding protocol by which the PED requests a specific or assigned IP address from the DHCP server. The DHCP server in this context offers an IP address lease and acknowledges a successful IP address lease by the PED, with the UT playing an intermediary role in the assignment and management of the IP address. The intermediation imparts delays. Further, at least some types of SCSs impart additional, potentially significant delays, stemming from the propagation delays associated with the satellite-based connectivity between the UT and the DHCP server.

SUMMARY

[0005] According to disclosed techniques, a dynamic host configuration protocol (DHCP) server in a satellite communications system (SCS) pre-allocates a pool of network addresses to a user terminal (UT), and the UT manages the subsequent allocation of addresses within the pool with respect to personal electronic devices (PEDs) connecting to the Internet through the UT. Among the multiple advantages flowing from these techniques, a connecting PED avoids satellite-link delays that would otherwise arise if the DHCP dynamically assigned a network address to the PED. At the same time, by providing each such connecting PED with its own network address within the domain of the DHCP, the SCS retains the ability to perform traffic shaping with respect to individual PEDs and/or the services consumed by them.

[0006] An example embodiment comprises a method of operation by a UT configured for connecting to a SCS. The method includes the UT obtaining pre-allocation of a pool of Internet Protocol (IP) addresses from a DHCP server in a core network (CN) of the SCS, based on communicating with the DHCP server over a satellite-based communications link supported by a first communications interface of the UT. Further, the method includes the UT performing local management of the pre-allocated pool. Local management includes the UT assigning individual ones of the IP addresses from the pre-allocated pool to individual PEDs, responsive to the individual PEDs attempting to access the Internet through the UT. Each such PED locally connects to the UT via a second communications interface of the UT.

[0007] A related example embodiment comprises a UT configured for connecting to a SCS. The UT includes a first communications interface configured to exchange signaling with the SCS over a satellite-based communications link, and a second communications interface configured to exchange signaling with individual PEDs local to the UT. Processing circuitry of the UT is operatively associated with the first and second communications interfaces and configured to obtain pre-allocation of a pool of IP addresses from a DHCP server in a CN of the satellite communications system, based on communicating with the DHCP server over the satellite-based communications link. Further, the processing circuitry is configured to perform local management of the pre-allocated pool. Local management includes assigning individual ones of the IP addresses from the pre-allocated pool to the individual PEDs, responsive to the individual PEDs attempting to access the Internet through the UT.

[0008] Another example embodiment comprises a method of operation by a DHCP server in a CN of a SCS. The method includes the DHCP server determining a pool of IP addresses to preallocate to a UT that is configured to connect to the SCS via a satellite-based communications link, for local management by the UT. Local management in this context includes assignment by the UT of individual IP addresses from the pre-allocated pool to individual PEDs attempting to access the Internet through the UT. Further, the method includes the DHCP server sending an indication of the pre-allocated pool to the UT.

[0009] A related further embodiment comprises a DHCP server configured for operation in a CN of a SCS. The DHCP server includes a communications interface and processing circuitry. The processing circuitry is configured to determine a pool of IP addresses to pre-allocate to a UT that is configured to connect to the SCS via a satellite-based communications link, for local management by the UT. Local management by the UT includes assignment by the UT of individual IP addresses from the pre-allocated pool to individual PEDs attempting to access the Internet through the UT. Further, the processing circuitry of the DHCP server is configured to send, via the communications interface, an indication of the pre-allocated pool to the UT. [0010] Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a block diagram of a satellite communications system (SCS) according to one embodiment.

[0012] Figures 2 and 3 are block diagrams of example details for a user terminal (UT) of a SCS.

[0013] Figure 4 is a logic flow diagram of a method of operation by a UT of a SCS according to one embodiment.

[0014] Figure 5 is a logic flow diagram of a method of operation by a dynamic host configuration protocol (DHCP) server of a SCS according to one embodiment.

[0015] Figures 6 and 7 are block diagrams of example details for a DHCP server of a SCS.

[0016] Figure 8 is a block diagram of an example set of network addresses, and example preallocations of pools of network addresses from the set.

[0017] Figure 9 is a block diagram of example functional details for a UT according to one embodiment, shown in context with a PED and a core DHCP server.

DETAILED DESCRIPTION

[0018] Figure 1 illustrates a satellite communications system (SCS) 10 according to an example embodiment, with the SCS 10 providing one or more types of communication services to user terminals (UTs) 12. One UT 12 appears in the diagram for simplicity. In practice, the SCS 10 may serve a large population of UTs 12 distributed over a geographic region referred to as a satellite service area.

[0019] Among the communication service or services, the SCS 10 provides connectivity to the Internet 14, with the SCS 10 thus serving as a satellite-based access network for accessing one or more types of Internet Protocol (IP) based services. The UT 12 itself may use one or more IP based services. Additionally, or alternatively, the UT 12 acts as a local gateway or edge router for one or more personal electronic devices (PEDs) 16. Acting as a local gateway means providing Internet access to individual ones of the PEDs 16. As an example, the UT 12 is a modem that provides local connections 18 — e.g., Ethernet and/or Wi-Fi connections — for respective ones among one or more PEDs 16, with the PEDs 16 comprising essentially any type of device or system configured to connect to the Internet, such as set-top boxes, personal computing devices, smart phones, etc.

[0020] A satellite-based communications link supports connectivity of the UT 12 with respect to the SCS 10. The overall link includes a feeder link 20a between a satellite 22 of the SCS 10 and one or more respective satellite access nodes (SANs) 24 of the SCS 10, and further includes a user link 20b between the UT 12 and the satellite 22. The feeder link 20a is based on radiofrequency (RF) or optical forward uplink signals 26 going from the SAN(s) 24 to the satellite 22 and RF or optical return downlink signals 28 going from the satellite 22 to the SANs(s) 24. The user link 20b is based on RF forward downlink signals 30 going from the satellite 22 to the UT 12 and RF return uplink signals 32 going from the UT 12 to the satellite 22.

[0021] Each SAN 24 has a connection 34 to a core network (CN) 36 of the SCS 10. The CN 36 provides communicative coupling with the Internet 14, meaning that the CN 36 provides for IP-based routing of IP packets into and out of the SCS 10, with respect to various computer servers, devices, or systems reachable via the Internet 14. A communications processing system (CPS) 38 handles the incoming and outgoing IP traffic. The CPS 38 provides one or more forward communication signals 40 to the SAN(s) 24 over the connection(s) 34 and receives one or more return communication signals 42 from the SAN(s) 24.

[0022] The forward communication signal(s) 40 comprise forward IP packets destined for respective UTs 12 served by the SCS 10. Within the context of the example illustration, the one or more forward communication signals 40 may carry forward IP packets targeted to any one or more PEDs 16 having respective local connections 18 to the depicted UT 12. Similarly, the one or more return communication signals 42 are transmitted by the one or more SANs 24 over the connection 34, with the return communication signal(s) 42 carrying return IP packets originating from the UT 12 and/or from any one or more PEDs 16 having local connections 18 to the UT 12. [0023] Items of particular interest in the context of Figure 1 include a dynamic host configuration protocol (DHCP) server 50 in the CN 36, where the DHCP server 50 implements a pre-allocation function 52 that provides for the advantageous pre-allocation of IP addresses to the UT 12 for supporting PEDs 16 that attempt Internet access through the UT 12.

Correspondingly, the UT 12 implements a complementary pre-allocation function 54, for locally managing the pre-allocated IP addresses. Here, the word “function” denotes a set of operations arranged to produce a defined result, with an example implementation of a function being the execution of stored computer program instructions by a microprocessor or other digital processor, with the instructions arranged to cause the microprocessor to carry out or initiate the defining set of operations.

[0024] The pre-allocated IP addresses in this context are not sub-net addresses associated with any local domain with which the UT 12 may be associated. Instead, the pre-allocated addresses are at the domain- level of the SCS 10. For example, the SCS 10 may use a large block of private IP addresses for assignment to UTs 12 and/or PEDs 16 connecting to the Internet through the SCS 10. As such, any given pre-allocated pool contains a subset of addresses from the larger block.

[0025] To better appreciate the several advantages provided by the disclosed pre-allocation techniques, consider a first conventional approach wherein a PED connecting to the Internet via the SCS communicates a DHCP request to a core DHCP server in the SCS, with the SCS allocating a network address to the PED, from its overall pool of SCS-domain addresses. A distinct advantage of this approach is “visibility” for traffic flowing in the SCS for the PED, because that traffic is associated with the SCS-domain level network address assigned by the core DHCP server of the SCS. This visibility allows the SCS to perform traffic shaping with respect to the PED traffic and/or with respect to particular types of traffic exchanged with the PED. Overall performance, efficiency, and user experience depend critically upon the ability of the SCS to perform traffic shaping.

[0026] A distinct disadvantage of the PED obtaining its network address on demand, directly from the DHCP server is the latency involved. The DHCP request outgoing from the PED experiences at least one satellite uplink delay and at least one satellite downlink delay, with these delays being much larger than the typical processing delays associated with operation of the DHCP server and any inter-core communications associated with dynamic DHCP assignments. Further delays arise in mesh satellite arrangements, where there are one or more inter- satellite links on the overall end-to-end path between the DHCP server and the UT/PED.

[0027] One way to avoid such delays is for the DHCP to assign a single network address to the UT, from the pool of SCS-domain network addresses, with the UT then managing its own set of lower-level or local network addresses that it assigns to PEDs connecting to the Internet through the UT. In a more detailed example of this arrangement, the SCS has one or more public IP addresses used for routing traffic into and out of the SCS, with the SCS performing a first level of network address translation (NAT) between the one or more public IP addresses and a pool of private network addresses used for IP routing within the SCS domain — i.e., SCS domainlevel addresses. A UT is assigned one of these domain-level network addresses and it performs a second, lower-level NAT between its assigned address and the pool of local addresses that are private to the UT and used by the UT for differentiating between the PEDs that use the UT as a network gateway.

[0028] While this approach solves the delay problem associated with direct, on-the-fly allocation of domain-level network addresses to PEDs by the core DHCP, the delay solution comes at the expense of traffic-shaping ability. That is, traffic for individual PEDs connected through a given UT is associated with the single domain-level network address assigned to the UT, with the UT using its own private addresses to differentiate between the individual UTs. The disclosed techniques provide a simultaneous solution to the latency and visibility problems, without requiring expanded address pools at the domain level, and without disturbing normal DHCP operations or requiring any added intelligence at the PEDs. A further advantage is that the disclosed techniques avoid the need for NAT synchronization between UTs and the SCS, as would be needed if address assignment at the UT level relied on addresses private to the UT. [0029] Focusing first on the pre-allocation function 54, Figure 2 depicts the UT 12 according to example details and where the UT 12 is configured for connecting to the SCS 10. The UT 12 includes: a first communications interface 60 that is configured to exchange signaling with the SCS 10 over a satellite-based communications link; a second communications interface 62 that is configured to exchange signaling with individual PEDs 16 that are local to the UT 12; and processing circuitry 64 that is operatively associated with the first and second communications interfaces 60 and 62. Here, “operatively associated” refers to the processing circuitry 64 sending and receiving information — data, control signaling, etc. — via the communication interfaces 60 and 62.

[0030] The processing circuitry 64 is configured to obtain pre-allocation of a pool of IP addresses from the DHCP server 50 in the CN 36 of the SCS 10, based on communicating with the DHCP server 50 over the satellite-based communications link. Further, the processing circuitry 64 is configured to perform local management of the pre-allocated pool, including assigning individual ones of the IP addresses from the pre-allocated pool to the individual PEDs 16, responsive to the individual PEDs 16 attempting to access the Internet through the UT 12. [0031] The IP addresses in the pre-allocated pool are private IP addresses, for example. In turn, the CN 36 provides Network Address Translation (NAT) to map each private IP address to one among one or more public IP addresses used by the SCS 10 for providing Internet connectivity to PEDs 16. For performing local management of the pre-allocated pool according to at least one such embodiment, the processing circuitry 64 of the UT 12 is configured to return a previously assigned one of the private IP addresses to the pre-allocated pool responsive to disconnection from the UT 12 of the corresponding PED 16.

[0032] An expiry period governs the pre-allocation in one or more embodiments. In such embodiments, the processing circuitry 64 is configured to periodically contact the DHCP server 50 to reset the expiry period.

[0033] The processing circuitry 64 in at least one embodiment is configured to confirm continued validity of the pre-allocation after obtaining the pre-allocation. As an example, for confirming the continued validity of a pre-allocation, the processing circuitry 64 is configured to communicate with the DHCP server 50 on a periodic or triggered basis, with the DHCP server 50 returning an indication of whether the pre-allocation remains valid for continued use at the UT 12. Extending the example, the processing circuitry 64 in at least one embodiment is configured to terminate use of a pre-allocated pool responsive to the DHCP server 50 indicating that the pre-allocation is no longer valid.

[0034] In at least some embodiments of the UT 12, the first communications interface 60 comprises a satellite radio interface configured to transmit RF return uplink signals 32 and to receive RF forward downlink signals 30. The second communications interface 62 is configured to support local connectivity with individual PEDs 16 and comprises, for example, a Local Area Network (LAN) interface, such as an Ethernet-based interface. Additionally, or alternatively, the second communications interface includes wireless communication circuitry providing a Wireless LAN (WLAN) interface. For example, the UT 12 is configured to act as a Wi-Fi access point (AP) to which individual PEDs 16 connect for Internet access. Still other configurations include Bluetooth-based connectivity and/or connectivity based on some other personal area network (PAN) protocol.

[0035] The processing circuitry 64 of the UT 12 comprises fixed circuitry or programmatically configured circuitry or a mix of both. In at least one embodiment, the processing circuitry 64 of the UT 12 comprises one or more microprocessors or other digital processors that are specially adapted to carry' out overall UT functionality, including the preallocation function 54, based on the execution of computer program instructions. Thus, the UT 12 in one or more embodiments includes storage 66 storing one or more computer program(s) 68 and, possibly, one or more types of data 70. For example, the data 70 includes provisioned information, such as credentials or other authentication information necessary for authorization of the UT 12 by the SCS 10. The data 70 may also include configuration data or other static or semi-static information, such as data indicating pre-allocated addresses and data for tracking individual assignments of such addresses, expiry timers, validity information, etc. [0036] The storage 66 comprises one or more types of computer-readable media, such as a mix of volatile and non-volatile memory. Examples of volatile memory include DRAM or SRAM, while examples of non-volatile memory include NVRAM, EEPROM, FLASH, or solid- state disk (SSD).

[0037] Figure 3 illustrates example details for the processing circuitry 64 and storage 66. In the illustrated example, the processing circuitry 64 is realized as microprocessor 80 that is specially adapted to carry out the operations described herein for the example UT 12, based on its execution of computer program instructions 82 stored in a memory 84.

[0038] Figure 4 illustrates a method 400 of operation by a UT 12, where the method 400 may be understood as representing the operations embodied in the pre-allocation function 54 illustrated in Figure 1. The example method 400 includes the UT 12 obtaining (Block 402) preallocation of a pool of IP addresses from a DHCP server 50 in a CN 36 of the SCS 10. For example, the UT 12 obtains the pre-allocation based on communicating with the DHCP server 50 over a satellite-based communications link supported by a first communications interface 60 of the UT 12.

[0039] The method 400 further includes the UT 12 performing local management of the preallocated pool. Local management by the UT includes assigning individual ones of the IP addresses from the pre-allocated pool to individual PEDs 16, responsive to the individual PEDs 16 attempting to access the Internet through the UT 12. For example, each such PED 16 locally connects to the UT 12 via a second communications interface 62 of the UT 12.

[0040] As noted earlier, the IP addresses in the pre-allocated pool may be private IP addresses used within the SCS 10. Correspondingly, the CN 36 provides NAT to map each private IP address to one among one or more public IP addresses used by the SCS 10 for providing Internet connectivity to PEDs 16. Performing local management of the pre-allocated pool according to the private-address context may include the UT 12 returning a previously assigned one of the private IP addresses to the pre-allocated pool responsive to disconnection from the UT 12 of the corresponding PED 16.

[0041] In one or more embodiments, an expiry period governs the pre-allocation and the method 400 includes the UT 12 periodically contacting the DHCP server 50 to reset the expiry period. This action can be understood as the UT 12 proactively communicating with the DHCP server 50, to renew an existing pre-allocation.

[0042] Along the same or similar lines, one or more embodiments of the method 400 include the UT 12 confirming continued validity of a pre-allocation after obtaining the pre-allocation. For example, the UT 12 communicates with the DHCP server 50 on a periodic or triggered basis, with the DHCP server 50 returning an indication of whether the pre-allocation remains valid for continued use at the UT 12. At least one such embodiment of the method 400 includes the UT 12 terminating use of the pre-allocated pool responsive to the DHCP server 50 indicating that the pre-allocation is no longer valid.

[0043] Figure 5 illustrates a method 500 of operation by a DHCP server 50, where the method 500 may be understood as representing the operations embodied in the pre-allocation function 52 illustrated in Figure 1. The DHCP server 50 is configured for operation in a CN 36 of a SCS 10 and the method 500 includes the DHCP server 50 determining (Block 502) a pool of IP addresses to pre-allocate to a UT 12, for local management by the UT 12. Here, the UT 12 is configured to connect to the SCS 10 via a satellite-based communications link, and local management by the UT 12 of the pre- allocated pool includes assignment by the UT 12 of individual IP addresses from the pre-allocated pool to individual PEDs 16 attempting to access the Internet through the UT 12. Further, the method 500 includes the DHCP server 50 sending (Block 504) an indication of the pre-allocated pool to the UT 12.

[0044] According to some embodiments or in at least some scenarios, the UT 12 is one among a plurality of UTs 12, with the understanding that each UT 12 may support pre-allocation of address pools and provide corresponding management of the pre-allocated addresses with respect to individual PEDs 16 that are local to each UT 12. Correspondingly, determining the pool of IP addresses to pre-allocate to the UT 12 may comprise the DHCP server 50 identifying an unallocated subset of IP addresses from a larger set of IP addresses available for preallocation to the plurality of UTs 12. For example, the larger set is a set of private IP addresses, and the CN 36 provides NAT to map each private IP address to one among one or more public IP addresses used by the SCS 10 for providing Internet connectivity to the individual PEDs 16 supported by the respective UTs 12.

[0045] One or more embodiments of the method 500 include the DHCP server 50 applying an expiry period that governs use by a UT 12 of a pre-allocated pool. In at least one such embodiment, the method 500 includes the DHCP server 50 returning the pre-allocated pool of IP addresses to a larger pool for subsequent pre-allocation to the same or another UT 12, responsive to expiration of the expiry period. Additionally, one or more such embodiments of the method 500 include the DHCP server 50 resetting the expiry period for a pre-allocated pool responsive to the associated UT 12 requesting a reset of the expiry period in advance of expiration.

[0046] In at least one embodiment of the method 500, after pre-allocating a pool of IP addresses to a UT 12, the DHCP server 50 subsequently transmits one or more indications of continued validity of the pre-allocation, to inform the UT 12 of the continued validity. Further, at least one embodiment of the method 500 includes, after the DHCP server 50 pre-allocates a pool of IP addresses to a UT 12, the DHCP server 50 subsequently transmitting one or more indications of termination of the pre-allocation, to inform the UT 12 that the pre- allocation is no longer valid.

[0047] Figure 6 illustrates example details of a DHCP server 50 configured for operation in a CN 36 of a SCS 10. The example DHCP server 50 includes a communications interface 100 and processing circuitry 102. The processing circuitry 102 is configured to determine a pool of IP addresses to pre-allocate to a UT 12 that is configured to connect to the SCS 10 via a satellitebased communications link, for local management by the UT 12. Local management includes the UT 12 assigning individual IP addresses from the pre-allocated pool to individual PEDs 16 attempting to access the Internet through the UT 12. Further, the processing circuitry 102 is configured to send an indication of the pre-allocated pool to the UT 12. More broadly, the processing circuitry 102 can be understood as being configured to carry the operations described for the method 500.

[0048] Implementation of the processing circuitry 102 relies on fixed circuitry or programmatically configured circuitry or a mix of both. In at least one embodiment, some or all the functionality of the DHCP server 50 is based on realization of the processing circuitry 102 via the execution of computer program instructions by one or more computational units — e.g., digital processors. Thus, in one or more embodiments, the DHCP server 50 includes storage 104 comprising one or more types of computer readable media that stores one or more computer programs 106 and one or more types of supporting data 108. The supporting data 108 includes, for example, information about the IP addresses allocable within the SCS domain and mapping information that relates those addresses to public IP addresses used by the SCS 10 for routing IP packets into and out of the SCS 10. Figure 7 elaborates such details by depicting implementation of the processing circuitry 102 and the storage 104 as a microprocessor 110 that is configured to cause the DHCP server 50 to carry out the method 500 and any supporting or extending operations, based on the execution of computer program instructions 112 stored in a memory 114.

[0049] Figure 8 relates to the earlier references associated with one or more embodiments, wherein there is a larger set 120 of IP addresses allocable within the network domain of an SCS 10 — this set 120 may be regarded as an overall pool of IP addresses. The DHCP server 50 manages the set 120 by pre-allocating respective pools 122 — address subsets — from the larger set 120. Each pool 122 may be allocated to a different one among a plurality of UTs 12. Each UT 12 uses its respectively allocated pool 122 for assignment to PEDs 16 connecting through the UT 12.

[0050] In Figure 8, the DHCP server 50 pre-allocates the pools 122a through 122m to a respective plurality of UTs 12. Again, each pre-allocated pool 122 may be understood as a subset of the IP addresses contained in the larger set 120, with the DHCP server 50 carrying out overall management in cooperation with the involved UTs 12, to pre-allocate, maintain pre-allocations, terminate pre-allocations, and return at least the currently unused ones among a pre-allocated pool 122 of IP addresses to the larger set 120 upon termination of the pre-allocation.

[0051] Once a given PED 16 obtains one of the IP addresses pre-allocated to its supporting UT 12, the PED 16 can communicate with the CN 36 and use IP services available through the SCS 10. Among the various advantages associated with the pre-allocation techniques disclosed herein is faster acquisition by a PED 16 of a network address to use for communicating with or via the SCS 10. Additionally, one or more embodiments provide for maintaining DHCP associations with respect to a given UT 12, even when the UT 12 goes offline. Maintaining the associations — e.g., maintaining the pre-allocation to a UT 12 with respect to one or more instances of the UT 12 going offline may offer improved user experiences reduced signaling overhead in the SCS 10 with respect to performing and managing pre-allocations.

[0052] Figure 9 depicts an example functional arrangement of a UT 12, with emphasis on the edge router operations supporting address pre-allocation as disclosed herein. A PED 16 includes a DHCP client, e.g., implemented via the execution of computer program instructions on one or more microprocessors or other digital processing circuitry included in the PED 16. The PED 16 communicatively couples to the UT 12 via a local area network (LAN) interface of the UT 12, which may be a wired and/or wireless interface, such as an Ethernet and/or Wi-Fi interface. The UT 12 communicatively couples to a satellite 22 of the SCS 10 via a wide area network (WAN) interface, e.g., a satellite radio interface.

[0053] The UT 12 implements a number of functional entities providing a virtual routing function (VRF), with such entities realized, for example, via the execution of computer program instructions on one or more microprocessors or other digital processing circuitry included in the UT 12. The entities include an edge router DHCP server facing the LAN interface, an edge router DHCP proxy client facing the WAN interface, and an edge router DHCP configuration agent that coordinates operation of the edge router DHCP server and the edge router DHCP proxy client.

[0054] The UT 12 obtains pre-allocation of a pool of IP addresses from the core DHCP server, based on communicating with the core DHCP server over a satellite-based communications link supported by the WAN interface of the UT 12. The UT 12 correspondingly performs local management of the pre-allocated pool, including assigning individual ones of the IP addresses from the pre-allocated pool to individual PEDs 16, responsive to the individual PEDs 16 attempting to access the Internet through the UT 12, each such PED 16 locally connecting to the UT 12 via LAN interface of the UT 12.

[0055] In an example case, obtaining the pre-allocation comprises the UT 12 sending a DHCP request to the core DHCP server and including in the DHCP request a value that prompts the core DHCP server to allocate the pool of IP addresses to the UT 12, rather than allocating a single IP address. For example, the value included in the DHCP request is a Vendor Class Identifier (VCI) associated with configuration information indicating to the core DHCP server that the UT 12 is a modem operative for connecting PEDs 16 to the Internet. As a particular example, the value included in the DHCP request is an aircraft identifier, e.g., a tail ID, such that the core DHCP server recognizes the UT 12 as a modem used for providing Internet connectivity to PEDs 16 of aircraft passengers.

[0056] Complementing such operations, the core DHCP server determines the pool of IP addresses to pre-allocate to the UT 12, for local management by the UT 12, including assignment by the UT 12 of individual IP addresses from the pre-allocated pool to individual PEDs attempting to access the Internet through the UT 12. The core DHCP server sends an indication of the pre-allocated pool to the UT 12. As mentioned elsewhere, the IP addresses at issue here are SCS domain-level addresses managed by the core DHCP server and used for routing within the SCS 10 and are not private or local addresses on a sub-net administered by the UT 12.

[0057] In one or more embodiments, the core DHCP server determines the pool of IP addresses to pre-allocate to the UT 12 in response to the core DHCP server first determining that the UT 12 is a modem operative for connecting PEDs 16 to the Internet. As an example, the core DHCP server determines that the UT 12 is a modem operative for connecting PEDs 16 to the Internet, from a value in a DHCP request sent to the core DHCP server by the UT 12. The included value is VCI, for example, and is associated with configuration information indicating to the core DHCP server that the UT 12 is a modem operative for connecting PEDs 16 to the Internet. As a particular example, the value included in the DHCP request is an aircraft identifier, such as a tail ID, whereby the core DHCP server recognizes the UT 12 as a modem used for providing Internet connectivity to PEDs 16 of aircraft passengers. Based on that determination, the core DHCP server determines the pool of IP addresses to pre-allocate, such as by selecting an available one from among two or more predefined blocks of network addresses. [0058] Figure 9 provides particular example details corresponding to the operational details presented immediately above, where the UT 12 may be referred to as an “edge router” to denote its operation as a gateway for potentially many PEDs 16 and, particularly, its ability to assign pre-allocated addresses to local PEDs 16.

[0059] In the example depiction, the UT 12 includes a number of logical modules, including an edge router DHCP proxy client, an edge router DHCP server, and an edge router DHCP configuration agent. These logical modules are, for example, instantiated in the UT 12 via the execution of stored computer program instructions by one or more microprocessors of the UT 12.

[0060] The edge router DHCP proxy client sends a DHCP request towards the core DHCP server 50 of the SCS 10, via a Wide Area Network (WAN) interface of the UT 12, e.g., a satellite radio modem. The core DHCP server 50 uses provisioned information and/or metadata included within an option string of the DHCP request to determine that the UT 12 is capable of or otherwise configured for operating as an edge DHCP server, in which the UT 12 manages address assignments for PEDs 16 connecting through the UT 12, from a pool or block of IP addresses pre-allocated to the UT 12 by the core DHCP server 50. In one or more embodiments, provisioning information includes information indicating the number of IP addresses that should be pre-allocated to the UT 12, such as by indicating the maximum number of PEDs 16 supported by the UT 12.

[0061] The core DHCP server 50 sends a response to the request, with the response indicating an IP address that the UT 12 should assign to itself, as well as indicating a subnet mask that is sized to indicate the sub network that the UT 12 is responsible for. The subnet mask is used to communicate the subnet size, which is to say that the response indicates the size of the IP address pool being pre-allocated to the UT 12. In at least one embodiment, the start (or end) of the pre-allocated pool — subnet — is referenced to the IP address assigned to the UT 12. The core DHCP server 50 marks or otherwise remembers the pre-allocation and while the preallocation is active does not allocate IP addresses that are within the subnet, relying instead on local management of such addresses by the UT 12. The core DHCP server 50 may support many such UTs 12 by allocating a respective subnet to each one.

[0062] The edge router DHCP configuration agent of the UT 12 interprets the size of the subnet from the subnet mask returned in the DHCP response and configures the edge router DHCP server of the UT 12 for local management of the IP addresses in the subnet. While the pre-allocation is valid, the edge router DHCP server of the UT 12 handles DHCP requests incoming from PEDs 16 that are connected to the UT 12 via its Local Area Network (LAN) interface, which comprises, for example, a WIFI radio interface and/or an Ethernet interface. [0063] Notably, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention(s) is/are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

CLAIMS What is claimed is:

1. A method of operation by a user terminal (UT) configured for connecting to a satellite communications system, the method comprising: obtaining pre-allocation of a pool of Internet Protocol (IP) addresses from a Dynamic Host Configuration Protocol (DHCP) server in a Core Network (CN) of the satellite communications system, based on communicating with the DHCP server over a satellite-based communications link supported by a first communications interface of the UT ; and performing local management of the pre-allocated pool, including assigning individual ones of the IP addresses from the pre-allocated pool to individual Personal Electronic Devices (PEDs), responsive to the individual PEDs attempting to access the Internet through the UT, each such PED locally connecting to the UT via a second communications interface of the UT.

2. The method according to claim 1 , wherein obtaining the pre-allocation comprises sending a DHCP request to the DHCP server and including in the DHCP request a value that prompts the DHCP server to allocate the pool of IP addresses to the UT, rather than allocating a single IP address.

3. The method according to claim 2, wherein the value included in the DHCP request is a Vendor Class Identifier (VCI) associated with configuration information indicating to the DHCP server that the UT is a modem operative for connecting PEDs to the Internet.

4. The method according to claim 2 or 3, wherein the value included in the DHCP request is an aircraft identifier, such that the DHCP server recognizes the UT as a modem used for providing Internet connectivity to PEDs of aircraft passengers.

5. The method according to any one of claims 1-4, wherein the IP addresses in the preallocated pool are private IP addresses, and wherein the CN provides Network Address Translation (NAT) to map each private IP address to one among one or more public IP addresses used by the satellite communications system for providing Internet connectivity to PEDs.

6. The method according to claim 5, wherein performing local management of the preallocated pool includes returning a previously assigned one of the private IP addresses to the preallocated pool responsive to disconnection from the UT of the corresponding PED.

7. The method according to any one of claims 1-6, wherein an expiry period governs the pre-allocation and wherein the method includes the UT periodically contacting the DHCP server to reset the expiry period.

8. The method according to any one of claims 1-7, wherein the method further comprises the UT confirming continued validity of the pre-allocation after obtaining the pre-allocation.

9. The method according to claim 8, wherein confirming the continued validity of the preallocation comprises communicating with the DHCP server on a periodic or triggered basis, with the DHCP server returning an indication of whether the pre-allocation remains valid for continued use at the UT.

10. The method according to claim 8 or 9, further comprising terminating use of the preallocated pool responsive to the DHCP server indicating that the pre-allocation is no longer valid.

11. The method according to any one of claims 1-10, wherein the first communications interface is a Wide Area Network (WAN) interface, and wherein the second communications interface is a Local Area Network (LAN) interface.

12. A method of operation by a Dynamic Host Configuration Protocol (DHCP) server in a Core Network (CN) of a satellite communications system, the method comprising: determining a pool of Internet Protocol (IP) addresses to pre-allocate to a User Terminal (UT) that is configured to connect to the satellite communications system via a satellite-based communications link, for local management by the UT, including assignment by the UT of individual IP addresses from the pre-allocated pool to individual Personal Electronic Devices (PEDs) attempting to access the Internet through the UT ; and sending an indication of the pre-allocated pool to the UT.

13. The method according to claim 12, wherein determining the pool of TP addresses to preallocate to the UT is performed responsive to the DHCP server first determining that the UT is a modem operative for connecting PEDs to the Internet.

14. The method according to claim 13, wherein the DHCP server determines that the UT is a modem operative for connecting PEDs to the Internet, from a value in a DHCP request sent to the DHCP server by the UT.

15. The method according to claim 14, wherein the value included in the DHCP request is a Vendor Class Identifier (VCI) associated with configuration information indicating to the DHCP server that the UT is a modem operative for connecting PEDs to the Internet.

16. The method according to claim 14 or 15, wherein the value included in the DHCP request is an aircraft identifier, such that the DHCP server recognizes the UT as a modem used for providing Internet connectivity to PEDs of aircraft passengers.

17. The method according to any one of claims 12-16, wherein determining the pool of IP addresses to pre-allocate to the UT comprises selecting an available one from among two or more predefined blocks of network addresses.

18. The method according to any one of claims 12-17, wherein the UT is one among a plurality of UTs, and wherein determining the pool of IP addresses to pre-allocate to the UT comprises identifying an unallocated subset of IP addresses from a larger set of IP addresses available for pre-allocation to the plurality of UTs.

19. The method according to claim 18, wherein the larger set is a set of private IP addresses, and wherein the CN provides Network Address Translation (NAT) to map each private IP address to one among one or more public IP addresses used by the satellite communications system for providing Internet connectivity to the individual PEDs.

20. The method according to any one of claims 12-19, further comprising applying an expiry period that governs use by the UT of the pre-allocated pool.

21 . The method according to claim 20, further comprising returning the pre-allocated pool of IP addresses to a larger pool for subsequent pre-allocation to the same or another UT, responsive to expiration of the expiry period.

22. The method according to claim 20 or 21 , further comprising resetting the expiry period responsive to the UT requesting a reset of the expiry period in advance of expiration of the expiry period.

23. The method according to any one of claims 12-22, further comprising subsequently transmitting one or more indications of continued validity of the pre-allocation, to inform the UT of the continued validity.

24. The method according to any one of claims 12-23, further comprising subsequently transmitting one or more indications of termination of the pre-allocation, to inform the UT that the pre-allocation is no longer valid.

25. A user terminal (UT) configured for connecting to a satellite communications system, the UT comprising: a first communications interface configured to exchange signaling with the satellite communications system over a satellite-based communications link; a second communications interface configured to exchange signaling with individual Personal Electronic Devices (PEDs) local to the UT; and processing circuitry operatively associated with the first and second communications interfaces and configured to: obtain pre-allocation of a pool of Internet Protocol (IP) addresses from a Dynamic Host Configuration Protocol (DHCP) server in a Core Network (CN) of the satellite communications system, based on communicating with the DHCP server over the satellite-based communications link; and perform local management of the pre-allocated pool, including assigning individual ones of the IP addresses from the pre-allocated pool to the individual PEDs, responsive to the individual PEDs attempting to access the Internet through the UT.

26. The UT according to claim 25, wherein, to obtain the pre-allocation, the processing circuitry is configured to send a DHCP request to the DHCP server and include in the DHCP request a value that prompts the DHCP server to allocate the pool of IP addresses to the UT, rather than allocating a single IP address.

27. The UT according to claim 26, wherein the value included in the DHCP request is a Vendor Class Identifier (VCI) associated with configuration information indicating to the DHCP server that the UT is a modem operative for connecting PEDs to the Internet.

28. The UT according to claim 26 or 27, wherein the value included in the DHCP request is an aircraft identifier, such that the DHCP server recognizes the UT as a modem used for providing Internet connectivity to PEDs of aircraft passengers.

29. The UT according to any one of claims 25-28, wherein the IP addresses in the preallocated pool are private IP addresses, and wherein the CN provides Network Address Translation (NAT) to map each private IP address to one among one or more public IP addresses used by the satellite communications system for providing Internet connectivity to PEDs.

30. The UT according to claim 29, wherein, for performing local management of the preallocated pool, the processing circuitry is configured to return a previously assigned one of the private IP addresses to the pre-allocated pool responsive to disconnection from the UT of the corresponding PED.

31. The UT according to any one of claims 25-30, wherein an expiry period governs the preallocation, and the processing circuitry is configured to periodically contact the DHCP server to reset the expiry period.

32. The UT according to any one of claims 25-31, wherein the processing circuitry is configured to confirm continued validity of the pre-allocation after obtaining the pre-allocation.

33. The UT according to claim 32, wherein, for confirming the continued validity of the preallocation, the processing circuitry is configured to communicate with the DHCP server on a periodic or triggered basis, with the DHCP server returning an indication of whether the preallocation remains valid for continued use at the UT.

34. The UT according to claim 32 or 33, wherein the processing circuitry is configured to terminate use of the pre-allocated pool responsive to the DHCP server indicating that the preallocation is no longer valid.

35. The UT according to any one of claims 25-34, wherein the first communications interface is a Wide Area Network (WAN) interface, and wherein the second communications interface is a Local Area Network (LAN) interface.

36. A Dynamic Host Configuration Protocol (DHCP) server configured for operation in a Core Network (CN) of a satellite communications system, the DHCP server comprising: a communications interface; and processing circuitry configured to: determine a pool of Internet Protocol (IP) addresses to pre-allocate to a User Terminal (UT) that is configured to connect to the satellite communications system via a satellite-based communications link, for local management by the UT, including assignment by the UT of individual IP addresses from the pre-allocated pool to individual Personal Electronic Devices (PEDs) attempting to access the Internet through the UT; and send, via the communications interface, an indication of the pre-allocated pool to the UT.

37. The DHCP server according to claim 36, wherein the processing circuitry is configured to determine the pool of IP addresses to pre-allocate to the UT in response to determining that the UT is a modem operative for connecting PEDs to the Internet.

38. The DHCP server according to claim 37, wherein the processing circuitry is configured to determine that the UT is a modem operative for connecting PEDs to the Internet, from a value in a DHCP request sent to the DHCP server by the UT.

39. The DHCP server according to claim 38, wherein the value included in the DHCP request is a Vendor Class Identifier (VCI) associated with configuration information indicating to the DHCP server that the UT is a modem operative for connecting PEDs to the Internet.

40. The DHCP server according to claim 38 or 39, wherein the value included in the DHCP request is an aircraft identifier, and wherein the processing circuitry is configured to recognize the UT as a modem used for providing Internet connectivity to PEDs of aircraft passengers.

41. The DHCP server according to any one of claims 36-40, wherein, for determining the pool of IP addresses to pre-allocate to the UT, the processing circuitry is configured to select an available one from among two or more predefined blocks of network addresses.

42. The DHCP server according to any one of claims 36-41, wherein the UT is one among a plurality of UTs, and wherein, to determine the pool of IP addresses to pre-allocate to the UT, the processing circuitry is configured to identify an unallocated subset of IP addresses from a larger set of IP addresses available for pre-allocation to the plurality of UTs.

43. The DHCP server according to claim 42, wherein the larger set is a set of private IP addresses, and wherein the CN provides Network Address Translation (NAT) to map each private IP address to one among one or more public IP addresses used by the satellite communications system for providing Internet connectivity to the individual PEDs.

44. The DHCP server according to any one of claims 36-43, wherein the processing circuitry is configured to apply an expiry period that governs use by the UT of the pre-allocated pool.

45. The DHCP server according to claim 44, wherein the processing circuitry is configured to return the pre-allocated pool of IP addresses to a larger pool for subsequent pre-allocation to the same or another UT, responsive to expiration of the expiry period.

46. The DHCP server according to claim 44 or 45, wherein the processing circuitry is configured to reset the expiry period responsive to the UT requesting a reset of the expiry period in advance of expiration of the expiry period.

47. The DHCP server according to any one of claims 36-46, wherein the processing circuitry is configured to subsequently transmit, via the communications interface, one or more indications of continued validity of the pre-allocation, to inform the UT of the continued validity.

48. The DHCP server according to any one of claims 36-47, wherein the processing circuitry is configured to subsequently transmit, via the communications interface, one or more indications of termination of the pre-allocation, to inform the UT that the pre-allocation is no longer valid.