Description
The L2TP Network Server (LNS) is a critical node defined in early 3GPP packet-switched architectures, particularly for GPRS and UMTS, to facilitate interworking with external IP networks using the Layer 2 Tunneling Protocol (L2TP). It operates as the termination point of L2TP tunnels established from an L2TP Access Concentrator (LAC), which in the 3GPP context is typically the Gateway GPRS Support Node (GGSN). The LNS resides in the service provider's or an enterprise's private IP network. Its primary function is to de-encapsulate incoming L2TP frames from the tunnel, extract the user's PPP (Point-to-Point Protocol) session data, and route the IP packets onto the destination IP network. Conversely, for downlink traffic, it encapsulates IP packets within PPP and L2TP frames for transmission back through the tunnel to the user's device (UE).
Architecturally, the LNS sits at the boundary between the 3GPP mobile network and an external Packet Data Network (PDN). The data path involves the UE establishing a PDP Context with the GGSN. The GGSN, acting as a LAC, then initiates an L2TP tunnel to a pre-configured LNS. The user's data traffic is carried over a PPP session, which is itself carried inside the L2TP tunnel. This creates a virtual point-to-point link between the UE and the LNS, making the UE appear as if it is directly connected to the LNS's network. The LNS is responsible for PPP negotiation (like IP address assignment via IPCP), authentication (often using CHAP or PAP), and accounting for the subscriber's session.
Key components of the LNS functionality include the L2TP tunnel endpoint management, PPP session termination, IP routing, and often integrated AAA (Authentication, Authorization, and Accounting) client capabilities to interact with a RADIUS server. Its role was pivotal for enabling secure access to corporate intranets (a forerunner to modern VPNs) and for ISPs to provide Internet access to mobile subscribers. By terminating the L2TP/PPP session, the LNS assigns the UE an IP address from the corporate/ISP pool and becomes the default gateway for the UE's traffic into the external network. This model provided a clear demarcation and a standardized method (L2TP) for connecting mobile networks to external IP service networks before the widespread adoption of GTP-based S8/SGi interfaces and IPsec.
Purpose & Motivation
The LNS was created to solve the problem of securely and transparently connecting mobile subscribers to external IP networks, particularly corporate private networks, in the early days of mobile data (GPRS/UMTS). Prior to standardized tunneling, providing direct corporate access was complex and insecure. The purpose of the L2TP/LNS architecture was to leverage the well-established PPP and L2TP protocols from the IETF to create a virtual dial-up connection over the IP-based mobile core network.
This approach addressed several limitations. It allowed corporations to use their existing remote access infrastructure (LNS servers) to accept connections from mobile users without major changes. It provided a layer of authentication and authorization separate from the mobile network's HLR/AuC. Furthermore, it created a private tunnel for user data, offering a degree of confidentiality within the mobile operator's backbone. The LNS model was central to the 'Wireless WAN' or 'Mobile VPN' service offerings, enabling business users to access email and internal applications remotely.
The motivation for its specification in 3GPP Rel-4 was to provide a standardized interworking solution between 3GPP networks and external IP networks, ensuring multi-vendor interoperability for end-to-end data services. As 3GPP architectures evolved towards a pure IP model with GTP on the SGi interface and later with IPsec, the reliance on L2TP and the LNS diminished for general Internet access. However, the concept laid the groundwork for secure access to packet data networks and influenced later architectures like eVPN and IMS-based services. It represented a crucial bridging technology between legacy dial-up remote access and modern mobile broadband.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (41 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-4, normative work from Rel-15.
In Release 15, the L2TP Network Server (LNS) function was updated to correct the signaling server address request and to correct the length of the redirection server address. Furthermore, the specification was amended to update the redirection server address to support dual stack UEs. These changes provided specific corrections and enhancements to the LNS's server address handling procedures.
In Release 16, the L2TP Network Server (LNS) function was enhanced with new capabilities for IP address management. Specifically, it introduced the procedure for IP address allocation via a DHCP or AAA Server. Furthermore, it added the functionality for a subscription trigger to request a UE's IP address from a DN-AAA server.
In Release 17, the L2TP Network Server (LNS) function was enhanced with new support for Control and User Plane Separation (CUPS) and for conveying L2TP information over the N6 interface. Furthermore, the release introduced procedures for reporting key session parameters—including the UE's local IP address, the Session S-NSSAI, and the FQDNs of network functions like the CHF and Serving NF—to both RADIUS and Diameter DN-AAA servers. These updates also included specific corrections to L2TP and defined an LNS Address parameter.
- Updates to support L2TP for CUPS TS 29.061CR0536
- Updates to support L2TP in RADIUS message flow TS 29.061CR0537
- Updates to support L2TP in Diameter message flow TS 29.061CR0538
- Reporting UE local IP to Diameter DN-AAA server TS 29.061CR0539
- Reporting UE local IP to RADIUS DN-AAA server TS 29.061CR0540
- L2TP Corrections TS 29.244CR0561
+ 26 more changes
In Release 18, the L2TP Network Server (LNS) function was enhanced with improved procedures for L2TP tunnel establishment and management. These enhancements specifically introduced new support for reporting detailed L2TP tunnel failure causes. Furthermore, the release expanded the roles an LNS can support within service architectures, such as enabling a VAL server to act as a Multicast/Broadcast Service Application Function (MBS AF).
In Release 19, the updates for the L2TP Network Server (LNS) function specifically enhanced its accounting reporting capability towards the DN-AAA server. This change introduced no new interfaces or logical entities but focused on refining an existing procedure. The modification was confined to improving the accounting report mechanism between these two network elements.
- Updates to accounting report to DN-AAA server TS 29.561CR0180
Explore further
Broader topics and technologies where LNS plays a role.
Defining Specifications
3GPP specifications that define or reference LNS, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 29.061 vj00 | Packet Domain Interworking for PLMN | Rel-19 |
| TS 29.244 vj40 | PFCP Specification for Control/User Plane Separation | Rel-19 |
| TS 29.561 vj30 | 5G Interworking with External Data Networks | Rel-19 |