для Cisco Cisco Packet Data Gateway (PDG)

Скачать
Страница из 158
Contexts on the system can be categorized as follows:
• Source context: Also referred to as the "ingress" context, this context provides the subscriber's
point-of-entry in the system. It is also the context in which services are configured. For example, in a
3G UMTS network, the HNB access radio network containing the Home-NodeBs (HNBs) would
communicate with the system via IuH interfaces configured within the source context as part of the
HNB-GW service.
• Destination context: Also referred to as the "egress" context, this context is where a subscriber is
provided connectivity to core network (such as access to the MSC, SGSN, GGSN etc.) as configured
on HNB-GW service and related services. For example, the system's destination context would be
configured with the IuCS, IuPS, Gn, Gi or IP offload interfaces facilitating subscriber data traffic to/from
the core network (MSC, SGSN, GGSN) or other PDN (Mobile Data Service or Internet.
• AAA context: This context provides AAA functionality for subscriber bearer contexts and/or
administrative user sessions and contains the policies and logical interfaces for communication between
Security Gateway (SeGW) and a 3GPP AAA Server or 3GPP AAA proxy (OCS/CGF/AAA/HSS) over
AAA interface for authentication and authorization procedures for Femto user.
In the roaming case, the 3GPP AAA Proxy can act as a stateful proxy between SeGW and 3GPP AAA
Server.
The AAA server is responsible for transfer of subscription and authentication data for
authenticating/authorizing user access and UE authentication. The SeGW communicates with the AAA
on the PLMN using AAA interface.
To ensure scalability, authentication functionality for subscriber sessions should not be
configured in the local context.
Important
For administrative users, authentication functionality can either be configured in the local context or be
authenticated in the same context as subscribers.
• Local context: This is the default context on the system used to provide out-of-band management
functionality.
Logical Interfaces
This section describes the logical interface supported on HNB-GW.
Prior to allowing the flow of user data, the port must be associated with a virtual circuit or tunnel called a
logical interface. A logical interface within the system is defined as the logical assignment of a virtual router
instance that provides higher-layer protocol transport, such as Layer 3 IP addressing. Interfaces are configured
as part of the VPN context and are independent from the physical port that will be used to bridge the virtual
interfaces to the network.
Logical interfaces are assigned to IP addresses and are bound to a specific port during the configuration
process. Logical interfaces are also associated with services through bindings. Services are bound to an IP
address that is configured for a particular logical interface. When associated, the interface takes on the
characteristics of the functions enabled by the service. For example, if an interface is bound to an HNB-GW
service, it will function as an IuH interface between the SeGW (HNB-GW) service and the HNB. Services
are defined later in this section.
In support of both mobile and network originated subscriber UE contexts, the HNB-GW provides the following
network interface support:
   HNB-GW Administration Guide, StarOS Release 19
76
Understanding the Service Operation
Logical Interfaces