Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TS 22.519
Business Communication Requirements

V18.0.1 (PDF)2024/03  … p.
V17.0.0  2022/03  21 p.
V16.0.0  2020/06  21 p.
V15.0.0  2018/06  20 p.
V14.0.0  2017/03  21 p.
V13.0.0  2016/01  21 p.
V12.0.0  2014/10  21 p.
Rapporteur:
Ms. Covell, Betsy
Alcatel-Lucent Telecom Ltd

Content for  TS 22.519  Word version:  18.0.1

Here   Top

 

0  Introductionp. 5

The present document is structured in a similar manner to ETSI TS 181 005 [2] and the main clause numbering from this point in the document onwards therefore follows that document, with the scope of those clauses also following that of ETSI TS 181 005 [2].
As well as the interconnection of NGCN equipment to the NGN, the NGN can be used to host various business communication capabilities on behalf of an enterprise. These are:
  1. virtual leased line, where NGCN sites are interconnected through the NGN;
  2. business trunking application, where the NGN hosts transit capabilities between NGCNs, break-in capabilities from NGN to NGCN and break-out capabilities from NGCN to NGN; and
  3. hosted enterprise services, where an NGN hosts originating and/or terminating business communication capabilities for business communication users that are directly attached to an NGN.
These hosted capabilities may be hosted using the different capabilities described in different clauses in ETSI TS 181 005 [2] and therefore where appropriate the various clauses of the present document are broken up to further describe interconnection requirements, and these various hosted capabilities, as follows:
x.1
General;
x.2
NGN/NGCN interconnection requirements;
x.3
Specific requirements for hosted enterprise services;
x.4
Specific requirements for business trunking application; and
x.5
Specific requirements for virtual leased line.
This structure has been followed in 3GPP TS 22.519, even though TS 22.228 (the equivalent specification) is structured in a different manner.
Up

1  Scopep. 6

The present document specifies network requirements:
  • to support connection and interoperation of business communication capabilities (either hosted in NGCN or NGN) to the NGN; and
  • to support connection and interoperation of business communication capabilities to other business communication capabilities (either hosted in NGCN or NGN); and
  • to support connection and interoperation of business communication capabilities to other business communication capabilities located in or connected to the ISDN and PSTN; and
  • to support PABX functionality (hosted enterprise services) in an NGN.
The present document also specifies network requirements for communication between NGCN capabilities (including user equipment) to other NGCN capabilities of the same enterprise through the NGN (e.g. geographically separated).
The present document does not specify NGCN services, nor does it specify network based application services provided to a user of an NGCN.
Up

2  Referencesp. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
Recommendation ITU-T E.164: "The international public telecommunication numbering plan".
[2]
ETSI TS 181 005 (V1.1.1): "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Services and Capabilities Requirements".
[3]
TS 33.203: "3G security; Access security for IP-based services".
[4]
TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security".
[5]
ISO/IEC 11571: "Information technology - Telecommunications and information exchange between systems - Private Integrated Services Networks - Addressing".
[6]
TS 22.228: "Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1".
[7]
ETSI TR 102 478 (V1.1.1): "Corporate telecommunication Networks (CN); Enterprise communication involving Next Generation carrier Networks (NGN)".
[8]
TS 22.115: "Service aspects; Charging and billing".
[9]
TS 33.106: "3G security; Lawful interception requirements".
[10]
TR 21.905: " Vocabulary for 3GPP Specifications".
Up

3  Definitions and abbreviationsp. 7

3.1  Definitionsp. 7

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
business communication:
any communication that is either:
  • originated in an NGCN; or
  • terminated in an NGCN; or
  • originated in the NGN on behalf of an enterprise; or
  • terminated in the NGN on behalf of an enterprise;
and which is subject to special arrangements between the NGN operator and the enterprise
business communication capabilities:
any capability whether hosted in an NGCN or an NGN that enables and/or enriches Business Communication
Business Trunking (BT):
connection of an NGCN to an NGN
business trunking application:
NGN application that either provides transit capabilities between NGCNs, or, break-in capabilities from NGN to NGCN and/or break-out capabilities from NGCN to NGN
corporate network user identifier:
identifies a corporate network user on communications entering, leaving or transiting the NGN, either representing an originating corporate network user or as a globally routable target identity
Corporate telecommunication Network (CN):
sets of enterprise premises equipment, owned by or managed on behalf of an enterprise that are located at geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of users belonging to that enterprise
enterprise:
unit of economic organization or activity, especially a business organization
Hosted Enterprise Services (HES):
NGN application whereby the NGN hosts all originating and/or terminating business communication capabilities for enterprise users that are directly attached to NGN and have an IMS service subscription for this application in the NGN
Next Generation CN (NGCN):
self-contained corporate network designed to take advantage of emerging IP-based communications solutions and that can have its own applications and service provisioning
NGCN site:
separate part of an NGCN
NGCN identifier:
identifier by which an NGCN is known to an NGN with which it has a connectivity arrangement
public network traffic:
traffic sent to or received from an NGN for processing according to the normal NGN rules
private network traffic:
traffic sent to or received from an NGN for processing according to an agreed set of rules specific to an enterprise or a community of closely related enterprises
Private Numbering Plan (PNP):
numbering plan explicitly relating to a particular private numbering domain, defined by the PISN Administrator of that domain
PNP number:
number belonging to a PNP
Up

3.2  Abbreviationsp. 8

For the purposes of the present document, the following abbreviations apply:
BT
Business Trunking
CAC
Communication Admission Control
CN
Corporate telecommunication Network
HES
Hosted Enterprise Services
IMS
IP Multimedia core network Subsystem
IP
Internet Protocol
NGCN
Next Generation Corporate Network
NGN
Next Generation Network
PBX
Private Branch Exchange
PNP
Private Numbering Plan
PSAP
Public Safety Answering Point
SLA
Service-Level Agreement
TIP
Termination Identity Interface
UE
User Equipment
UNI
User to Network Interface

4  Capabilities for the support of IP multimedia servicesp. 8

4.1  Generalp. 8

4.1.1  Types of trafficp. 8

The traffic generated or received on behalf of an NGCN can be either:
  1. traffic sent to the NGN for processing according to normal rules of the NGN. This type of traffic is known as public network traffic;
  2. traffic sent to the NGN for processing according to an agreed set of rules specific to an enterprise. This type of traffic is known as private network traffic. Private network traffic is normally within a single enterprise, but private network traffic can also exist between two different enterprises if not precluded for regulatory reasons.
The NGN shall distinguish public network traffic from private network traffic. The NGN shall distinguish private network traffic belonging to one enterprise from that belonging to another enterprise.
Private network traffic may require different handling in the NGN compared to public network traffic, see for example clause 4.1.7 on regulatory requirements.
Except between closely-related enterprises where regulations permit, the NGN shall treat traffic between enterprises as public network traffic. In such cases, as part of the capabilities provided to the enterprise, the NGN can provide break-out and/or break-in capabilities on behalf of each enterprise.
For private network traffic the NGN shall be transparent to any extensions of the chosen signalling protocol, except where there is a specific need for NGN intervention required to deliver the service requested by the enterprise customer.
Up

4.1.2  Business communication capabilitiesp. 9

The NGN can provide the following capabilities to an enterprise:
  1. virtual leased line, where NGCN sites are interconnected through the NGN. No additional capabilities are provided by the NGN;
  2. business trunking application, where the NGN hosts transit capabilities between NGCNs, break-in capabilities from NGN to NGCN and break-out capabilities from NGCN to NGN. A business trunking application may also host additional capabilities beyond basic break-in, break-out and transit capabilities to the NGCN. Typically there is no corporate network terminal equipment connected directly to an NGN. The capabilities provided are defined in clause 4.4;
  3. hosted enterprise services, where an NGN hosts originating and/or terminating business communication capabilities for business communication users that are directly attached to an NGN and have an IMS service subscription for this application in this NGN. This is known commonly as IP-Centrex. The capabilities provided are defined in clause 4.3.
Up

4.1.3  Business modelsp. 9

Additionally to the business domain relationships as specified in TS 22.228 the NGN shall support the following business domain relationships:
a)
NGCN to IMS relationship: NGCN is attached to an Access network that is connected to the NGN IMS with which the NGCN has a service agreement as shown in Figure 4.1, the relationship is with the home IMS.
Reproduction of 3GPP TS 22.519, Fig. 4.1:
Up
b)
NGCN to Access network relationship: NGCN is connected to an Access Network as shown in Figure 4.2. The relationships given in TS 22.228 would normally be sufficient to enable connectivity with the NGN, providing there is a relationship between the NGCN and the IMS. Relationship b may be required in some cases.
Reproduction of 3GPP TS 22.519, Fig. 4.2:
Up
The following business model relationship is shown as it plays a role in some scenarios. The present document assumes the business relationships described in item a) and b) and those as assumed from TS 22.228 in order to create communications in support of this relationship:
c)
NGCN to NGCN relationship: The relationship between two NGCNs is shown in Figure 4.3.
Reproduction of 3GPP TS 22.519, Fig. 4.3:
Up
Where the Figures and text identify "IMS" forming the business relationship; this can apply also to the usage of other subsystems in the NGN architecture.
Additionally to the interconnect models as specified in TS 22.228, the NGN shall support:
  • an interconnect model where bi-lateral Service Level Agreements are established between an NGCN and an NGN.
Business trunking applications are normally provided by the home IMS and relationship a) is used to establish these capabilities, which in turn uses relationships given in TS 22.228 for the access network related relationship. Hosted enterprise services are normally provided by the home IMS, the existing business relationships as specified in TS 22.228 being sufficient to establish such capabilities.
Virtual leased line services can be supported directly using relationship b, or it can be supported using relationship a) with the IMS which in turn uses relationships given in TS 22.228 for the access network related relationship.
Roaming of NGCN users is supported by either:
  • a combination of business model relationship a) with relationships in TS 22.228 relationship with the visited IMS. No relationship is required between the home NGCN and the visited NGN or access network.
Roaming of NGN users to NGCN is supported by:
  • a combination of business model relationship a) with relationships in TS 22.228 relationship with the home IMS. No relationship is required between the home IMS and the visited NGCN.
The service offering to an NGCN may be restricted by the capabilities of the access network, the business agreement between the access network operator and the NGN operator and the business agreement between the NGCN and NGN operators.
Up

4.1.4  Number, naming and addressingp. 11

3GPP TS 22.228 provides requirements for the support of numbering to end users of the NGN which apply equally for public network traffic generated by, or received by a business communication capability.
For private network traffic generated by, or received by, a business communication capability, the requirements of TS 22.228 apply along with the following additional requirements:
  1. the NGN shall support tel-URIs that encode a PNP number, the PNP used by the enterprise shall be uniquely identified in this tel URI.
For public and private network traffic generated by, or received by, a business communication capability, the requirements of TS 22.228 apply along with the following additional requirements:
  1. the NGN shall support usage of SIP URIs with a domain belonging to an enterprise, and any usage of SIP URIs with a domain hosted by the enterprise; and
  2. the NGN shall support usage of SIP URIs where more than one domain belong to the same enterprise, and any usage of SIP URIs where more than one domain is hosted by the same enterprise;
  3. the NGN shall support usage of SIP URIs where a domain belonging to an enterprise, is partly hosted in NGCN and partly hosted in NGN.
URIs prefixed with "IM" and "Pres" are supported as specified in TS 22.228.
Up

4.1.5  Identification of session originator and terminatorp. 11

As defined in TS 33.203 a trust domain is used for the management of identities within enterprise network interconnection.
For identification, the requirements described in TS 22.228 are supported to NGN users and users of business communications capabilities as follows:
  1. when the business communication capability is outside the trust domain, the NGN asserts an identity that the NGN associates (by means of subscription data) with the enterprise, in addition to delivering the identity of the enterprise user as provided by the NGCN and which is not asserted by the NGN;
  2. when the business communication capability is inside the trust domain, the NGN presents the identity of the enterprise user as the asserted identity. The NGN shall accept the asserted identity received from the NGCN; and
  3. in order to support interworking with the PSTN/ISDN, and for other purposes, an alias identity of the enterprise user can be needed. An alias set for an enterprise user consists of:
    1. a SIP URI not in the form of a public telecommunication number; and
    2. one of either:
      • a public telecommunications number that reaches the same enterprise user; or
      • a private network number that reaches the same enterprise user.
      For enterprise users, it is the responsibility of the enterprise to provide the alias set. The NGN shall be able to receive alias sets from the NGCN.
      NGNs shall be able to deliver alias sets (of any user) to the NGCN.
The above requirements apply to the identities of both session originator and session terminator.
Up

4.1.6  Charging and accounting requirementsp. 11

An enterprise can account for traffic in its business communication capabilities whether hosted in an NGCN or NGN.
For public network traffic, the requirements of TS 22.115 apply.
For public network traffic, the enterprise and the NGN operator shall be able to identify each other across any interconnection interface, including intra-NGN interfaces to hosted business communication capabilities. For private network traffic, any involved enterprise shall be able to identify each other across any interconnection interface between its business communication capabilities.
Any business communication capability hosted in an NGN shall be able to account for private network traffic to the enterprise in the same manner as exists for an NGN operator to account for their own traffic.
Additionally, for private network traffic, the enterprise and the NGN operator shall be able to identify each other across any interconnection interface.
Up

4.1.7  Regulatory requirementsp. 12

4.1.7.1  Lawful interceptp. 12

Lawful Intercept should be handled according to TS 33.106.

4.1.7.2  Emergency servicep. 12

Both public network traffic and private network traffic may carry emergency calls.
An emergency call identified as public network traffic shall be handled in accordance with the emergency call requirements of the NGN, i.e. in accordance with the requirements of TS 22.228.
In case of a public network traffic emergency call, an NGN shall forward geographical location information received from an NGCN and possibly use it for routing to an appropriate PSAP. This can be subject to both privacy and regulatory requirements.
Routeing of calls identified as emergency calls in private network traffic is outside the scope of NGN documents. The NGN shall not handle such calls as specified in TS 22.228. This also applies to a hosted NGCN capability.
Up

4.1.7.3  Identifying malicious communicationsp. 12

A call identified as public network traffic shall be handled in accordance with the malicious call identification requirements of the NGN, i.e. in accordance with the requirements of TS 22.228.
Identification of malicious calls in private network traffic is outside the scope of NGN documents. The NGN shall not handle such calls as specified in ETSI TS 181 005 [2]. This also applies to a hosted NGCN capability.
Up

4.1.7.4  Anonymous communications rejectionp. 12

A call identified as public network traffic shall be handled in accordance with the anonymous call rejection requirements of the NGN, i.e. in accordance with the requirements of TS 22.228.
Requirements for handling of anonymous calls in private network traffic are outside the scope of NGN documents. The NGN shall not handle such calls as specified in TS 22.228. This also applies to a hosted NGCN capability.
Up

4.1.8  Mobilityp. 13

4.1.8.1  Roamingp. 13

The business models as expressed in TS 22.228 and clause 4.1.3 of the present document allow several roaming scenarios. Important roaming scenarios in the context of business communication are highlighted in this clause. These scenarios apply whether the NGCN functionality is external to the NGN, or hosted in the NGN.
For all scenarios both terminal mobility and personal mobility should be supported as defined in TS 22.228.
An NGCN user should be able to register and receive service from their NGCN while roaming to:
  1. another NGCN site of the same NGCN and interconnected by the NGN; or
  2. the NGN to which the NGCN is directly connected; or
  3. the NGN to which the NGCN is indirectly connected via another NGN.
Over and above the roaming capabilities provided in TS 22.228, an NGN user should be able to register and receive service from their NGN while roaming to:
  1. an NGCN connected to the NGN; or
  2. an NGCN indirectly connected to the NGN;
subject to agreement with the NGCN.
Up

4.1.9  Routing requirementsp. 13

4.1.9.1  Routing to a NGCN userp. 13

The NGN shall support routing to NGCN users that do not have an IMS service subscription in the NGN, but can be reached through an NGCN site that has a business trunking arrangement with an NGN.
Up

4.1.9.2  number range based routingp. 13

The NGN shall support routing based on Recommendation ITU-T E.164 [1] number ranges.

4.1.10  Communication admission controlp. 13

The NGN shall support Communication Admission Control on a per NGCN site basis. The NGN operator defines the set of rules or policies under which this should occur, and the NGCN operator should be able to configure the capability within those rules and policies. It shall be possible to set the following thresholds on a per direction basis (i.e. incoming and outgoing communications):
  • maximum number of simultaneous session-oriented communications;
  • maximum number of simultaneous streams per communication;
  • maximum number of immediate messages.
Communications coming in excess to the allowed threshold may be accepted or rejected.
Up

4.1.11  Geographical locationp. 14

An NGN shall be able to provide to an NGCN the geographical location information of an NGCN user. This can be subject to privacy requirements.

4.2  NGN/NGCN interconnection requirementsp. 14

4.2.1  NGCN site identifierp. 14

NGN shall support identification of an NGCN site, for authentication and authorization purposes.

4.2.2  Corporate network user identifierp. 14

In addition to the Naming, Numbering and Addressing requirements expressed in TS 22.228and in clause 4.1.4 of the present document the NGN shall provide the capability to uniquely identify NGCN users. NGCN user identities are assigned by an NGCN operator.
Up

4.2.3  Authentication and security requirementsp. 14

Authentication and Security with regard to connection of an NGCN to the NGN shall comply with security requirements specified in TS 33.203 and TS 33.210.

4.3  Specific requirements for hosted enterprise servicesp. 14

4.3.1  Security requirements for hosted enterprise servicesp. 14

When HES are being provided, a UE which is directly attached to or roams into an IMS network (via UNI) shall comply to the IMS access security requirements as specified in TS 33.203.

4.3.2  Capabilities provided to a HES userp. 15

The capabilities provided by such hosting towards HES users are not specified further by the present document, except that such hosting can form an integral part of any business communication support.

4.3.3  Capabilities provided to the enterprisep. 15

4.3.3.1  Break-inp. 15

HES can provide break-in. Break-in is where public network traffic is accepted from the public network and delivered to the HES user.

4.3.3.2  Break-outp. 15

HES can provide break-out. Break-out is where private network traffic is routed in the NGCN, or other business communication capability, to a point where it can enter an NGN on terms advantageous to the NGCN operator. An HES providing break-out therefore converts private network traffic to become public network traffic. The purpose of this capability is to allow a call from within the NGCN, or other business communication capability, to reach a user outside the enterprise (e.g. in the NGN). The NGN operator defines the set of rules or policies under which this should occur, and the NGCN operator should be able to configure the capability within those rules and policies. As an example, these rules and policies may be selected for tariff reasons, and the point where the capability is applied may be dependent on both geographic location and the NGN operator involved.
When break-out is provided, the HES shall convert any identities provided as private network numbers to valid public telecommunication numbers.
Up

4.4  Specific requirements for business trunking applicationp. 15

4.4.1  Routeing capabilitiesp. 15

4.4.1.1  Overviewp. 15

The business trunking application can provide a number of special routeing capabilities. Examples of these are as follows:
  • Break-in.
  • Break-out.
  • Bulk rerouting.

4.4.1.2  Break-inp. 15

A business trunking application can provide break-in. Break-in is where public network traffic is routed in the NGN to a point where it can enter an NGCN, or other business communication capability, on terms advantageous to the NGCN operator. A business trunking application providing break-in therefore converts public network traffic to become private network traffic. The purpose of this capability is to allow a call from outside the NGCN to reach a user within the enterprise. The NGN operator defines the set of rules or policies under which this should occur, and the NGCN operator should be able to configure the capability within those rules and policies. As an example, these rules and policies may be selected for tariff reasons (for example such that the NGCN operator can reduce the tariff to the calling user), and the point where the capability is applied may be dependent on both geographic location and the NGN operator involved.
Up

4.4.1.3  Break-outp. 15

A business trunking application can provide break-out. Break-out is where private network traffic is routed in the NGCN, or other business communication capability, to a point where it can enter an NGN on terms advantageous to the NGCN operator. A business trunking application providing break-out therefore converts private network traffic to become public network traffic. The purpose of this capability is to allow a call from within the NGCN, or other business communication capability, to reach a user outside the enterprise (e.g. in the NGN). The NGN operator defines the set of rules or policies under which this should occur, and the NGCN operator should be able to configure the capability within those rules and policies. As an example, these rules and policies may be selected for tariff reasons, and the point where the capability is applied may be dependent on both geographic location and the NGN operator involved.
When break-out is provided, the business trunking application shall convert any identities provided as private network numbers to valid public telecommunication numbers.
Up

4.4.1.4  Bulk reroutingp. 16

A business trunking application can provide bulk rerouting. Bulk rerouting is where private network traffic (possibly after break-in) destined for a terminating NGCN site is routed to an alternative NGCN site or answer point. This allows the NGCN site to be removed from service, e.g. overnight when it is not attended, or under fault conditions. The NGN operator defines the set of rules or policies under which this should occur, and the NGCN operator should be able to configure the capability within those rules and policies. These can include:
  1. not reachable (e.g. all calls to a particular NGCN site are diverted to a configured destination in case IP connectivity is lost between the network and this NGCN site);
  2. congestion; and
  3. time and date (e.g. all calls to a particular NGCN site are rerouted to a configured destination during closed hours).
Up

4.4.2  Communication barringp. 16

Communication barring enables network rejection of incoming communications that fulfil certain globally provisioned or configured conditions for a particular NGCN site. The NGN operator defines the set of rules or policies under which this should occur, and the NGCN operator should be able to configure the capability within those rules and policies. The decision to reject a communication shall be independent of the actual communication target (i.e. which line behind the NGCN site is being targeted by the session).
Up

5  PSTN/ISDN emulation servicep. 16

Not in the scope of the present document.

6  Codecs servicesp. 16

Requirements on codec support in the network from ETSI TS 181 005 [2] clause 6 apply.

7  Network attachment requirementsp. 16

7.1  Generalp. 16

Network attachment requirements from TS 22.228 apply.

7.2  Specific requirements for virtual leased linep. 16

7.2.1  Security requirements for virtual leased linep. 16

When Virtual Leased Line is being provided, the NGN shall comply to the Communications and Data Security Requirements for Network Domain Security as specified in TS 33.210.

8  CPE configurationp. 17

CPE in the context of the present document is NGCN site equipment that connects to an NGN. Requirements on CPE configuration support in the network from TS 22.228, clause 5 apply. No specific requirements for CPE configuration support have been identified for business communication in this release.

9  Control of processing overloadp. 17

In addition to the control of processing overload requirements in TS 181 005 [2] clause 10, an NGN shall have mechanisms available to control overload at the interconnect between that NGN and an NGCN. Where NGCN sites from multiple enterprises are served by the same processing resource an NGN shall ensure that overload affects traffic from and to NGCN sites of multiple enterprises, and other traffic, fairly.
An NGN shall be able to provide to an NGCN site processing overload control information, the NGCN site shall use this to regulate the load presented to the NGN. How an NGCN site regulates the load presented to an NGN is outside the scope of the present document.
An NGCN site shall be able to provide to an NGN processing overload control information, an NGN shall use this to regulate the load presented to an NGCN site.
Up

10  IP addressingp. 17

Requirements on IP addressing support in the network from TS 22.228 apply. For business communication capabilities hosted in an NGN, the IP addressing support of that NGN applies.

11  NGN interconnectionp. 17

Requirements on NGN interconnection support in the network from TS 22.228 apply. No specific requirements for NGN interconnection support have been identified for business communication in this release.

12  Transport stratump. 17

12.1  NGN/NGCN interconnection requirementsp. 17

12.1.1  Redundancy supportp. 17

An NGN may support the connection of multiple NGCN sites belonging to the same enterprise, where an NGCN site B may serve as a redundant site for another NGCN site A. Redundancy is needed to ensure reachability of the NGCN users located in site A via the redundant site B.
When an NGN detects that an NGCN site cannot accept (totally or partially) communications or detects a failure at the interconnect with the NGCN site, then an NGN shall support failover mechanisms to the NGCN site serving as redundant NGCN site.
Up

12.2  Specific requirements for virtual leased linep. 17

NGN may provide the following capabilities:
  • A virtual leased line, where NGCN sites are interconnected transparently on IP level through the NGN. (IP level VPN) No additional capabilities are provided by the NGN.
  • A virtual leased line, where an NGCN UE (not directly connected to an NGCN site, but connected at the transport stratum to the NGN) and an NGCN site are interconnected transparently on IP level through the NGN. (IP level VPN) No additional capabilities are provided by the NGN.

$  Change historyp. 19


Up   Top