For the purposes of the present document, the terms and definitions given in TS 22.519, ETSI ES 282 004 [3], TS 23.228, TS 23.003 and TS 23.218 apply.

For the purposes of the present document, the following abbreviations apply: AOR AS B2BUA CNG CNGCF CSCF DNS DSL HSS I-CSCF IP IP-CAN IWF LAN NASS NGCN NGN P-CSCF PNP S-CSCF SIP SLA UE URI

Business trunking refers to an architecture where corporate networks appear to the NGN as an NGCN. Although the interface between an NGCN and an NGN is IP-based, this does not preclude the existence of non-IP-based elements within the NGCN but not visible to the NGN. The NGCN appears to the NGN as a black box.

NGCN sites may be connected to any IP-connectivity Access Network (IP-CAN) valid for TISPAN NGN using a Customer Network Gateway (CNG), as defined in ETSI ES 282 001 [2] or connected to an NGN core network via an edge router of the enterprise. Connection to an IP-CAN includes the case where the NGCN site incorporates a CNG as defined in ETSI TS 185 003 [15], connected to a DSL-based access network (see Figure 4.1) as well as the case where the NGCN site comprises a corporate LAN with one or more edge routers playing the role of a CNG connected to access nodes in the operator's access network (see Figure 4.2). Towards an access network, the NGCN site acts as a UE. For further details see clause 7. Towards the IM CN subsystem, the entry point / exit point entity is dependent on the approach adopted and is described further in clause 6. An NGCN connects a multiplicity of endpoints to the network, each of which may be an IP device or a legacy phone. The NGN does not need to have any knowledge on the individual endpoints connected to the NGCN. With the subscription based approach, for each NGCN site, the Home Subscriber Server (HSS) stores a single public user identity and a single associated user profile enabling triggering of network-based services beyond those provided by the NGCN itself. A set of telephone numbers and/or SIP URIs are also associated with each NGCN site. The former could be expressed in the form of number ranges and the latter using wildcards in the user or host part.

Identifiers based on private numbers shall be handled in accordance with ETSI TR 102 634 [20].

The service level layer interconnection makes use of IMS. Two main interconnection arrangements are provided:

• Interconnection of the NGN and NGCN where the entry point to the IMS is the P-CSCF. This is known as the subscription-based approach. This is represented by scenario 5 in subclause 8.3 of TS 24.523. In this case each site of the NGCN has a service subscription to the IMS, with an appropriate entry in the HSS. An AS is used to provide business trunking applications, e.g. those defined in TS 22.519, subclause 4.4. If such capabilities are not required, then the AS is not included in any request processing. The service level capabilities of this scenario are described further in subclause 6.1.
• Interconnection of the NGN and NGCN where the entry point to the IMS is the IBCF. This is known as the peering-based approach. This is represented by scenario 6 in subclause 8.4 of TS 24.523. In this case there is no dynamic registration to the IMS of individual NGCN-users or NGCN-sites. However, the absence of such dynamic registrations in an HSS does not preclude the NGN to host enterprise specific data in an HSS. The service level capabilities of this scenario are described further in subclause 6.2.

The second of these arrangements is called the peering-based approach due to the similarity of the arrangement to the mechanism by which the IMS in two NGNs interconnect. The provision of the business trunking applications (e.g. those defined in TS 22.519, subclause 4.4) is realized by an intelligent routeing function, which may involve an AS depending on the actual enterprise specific data. In none of the arrangements do the private extensions behind the NGCN need their own service subscription within the NGN, since they are owned and managed by the NGCN. The private extensions register with the NGCN, and the NGCN provides the individual services to the private extensions. An architecturally similar case to the peering-based approach is represented by scenario 3 in subclause 7.1 of TS 24.523. In this case, SIP requests at one entry point are always routed to the same exit point, and no business trunking applications are provided. The service level capabilities of this scenario are described further in subclause 6.3 of the present document. This scenario carries private network traffic only.