Disclaimer: This tr is an ad-hoc draft, and subject to modification. The Tr has yet to be presented to, or be accepted by, tsg-s1

Дата канвертавання25.04.2016
Памер274.37 Kb.
1   2   3   4   5   6   7

4.5 PS Domain Network Requirements

The PS domain shall support both transparent and non-transparent bearer services. Account shall be taken of the need for efficiency (e.g. over the air interface, potential use of header stripping/compression techniques) in the all IP network architecture.

The PS domain shall support simultaneous realtime multimedia services and non-realtime packet services.

Editor's note: the relationship to existing solutions (e.g. in GRPS) needs to be identified

In defining PS domain requirements, alignment with multimedia developments in the wired networks should be taken into consideration, including the provision of Voice over IP, making use of the same definitions and approaches wherever possible.

In many cases, the PS domain will need to interwork with circuit switched domain, PSTN and the ISDN. These interworking requirements (including end to end quality of service issues) should be identified.

Editor's note: reference to 22.060 for existing bearer service requirements, are they sufficient?

A single call control protocol for the PS domain is recommended.

4.6 High level service requirements

Introduction of new technologies should improve the user's service experience (i.e. should not impose a reduction in the service set available or a reduction in the quality of service). New technologies should be introduced in a manner allowing for a smooth transition from existing technologies (providing a clear and smooth evolution path).

The following high level service requirements need to be incorporated for successful deployment of services based on an all-IP network. These should be considered when identifying more specific requirements.

All-IP networks shall:-

  1. In general, provide backwards compatibility with the services offered by the Release 99 standard (including teleservices, supplementary services, and operator specific services)

  1. The “C” relationship in Figure 5 should provide sufficient capabilities to allow a Service Provider to develop and implement Release 99 services that would be transparent to the end user. However, Release 99 services implemented across the “C" relationship may utilise the additional capabilities of the Release 2000 multimedia environment to provide the end user with enhanced capabilities and improved user interfaces.

  2. Not all existing Release 99 services need to be supported in the PS domain (see Annex A). Some exceptions may exist, as identified in the provided feature list. A minimum set of PS domain service capabilities should be defined to enable roaming.

Editor's note: DeWayne Sennet (AWS) to provide rephrasing of above text

  1. To enable service compatibility and access independence, it shall be possible to implement mainstream IP based multimedia (supplementary) services to be compatible with the same services when used via other types of accesses, e.g. via fixed lines (see Annex A).

  1. Enable provision of services with the same (or greater) quality of service as circuit switched services.

  1. It shall be possible to offer services over an All-IP network with a quality of service that is no less than that already experienced by users of existing circuit switched networks.

  2. The enabling mechanisms (transport technology, etc.) should be transparent to the user.

  3. The All IP network shall have the ability to provide, on an end to end basis, when interworking with other All IP networks, other access networks (e.g. non-All IP), PLMNs or PSTNs, a Quality of Voice at least as good as that achieved by the Release 2000 circuit-switched (e.g. AMR codec based) wireless systems.

Editor's note: need to rework phrasing of above…

Editor's note: will need to separate these requirements in the feature list…

  1. Shall provide the same (or greater) degree of privacy, security, and authentication as Release 2000 circuit switched services

  2. Support roaming between All-IP networks and non-All-IP networks. The specific roaming scenarios required are identified in the feature list.

Editor's note: will need to elaborate roaming, handover and cell reselection…

Editor's note: will need to elaborate this in the feature list…

  1. Support the possibility to offer a set of Release 99 services to Release 99 terminals

Editor's note: text to be provided by Tomas Ahnberg (Telia)

5 Applicability of existing toolkits

This clause reviews the applicability of the existing toolkits in Release 99.
    1. CAMEL

Release 2000 shall incorporate CAMEL improvements following Release 99 (e.g. Phase 4).

Users shall be able to use their existing CAMEL services in a consistent manner in Release 2000 networks. This should occur in a transparent fashion and the user need not be aware of whether the service is either circuit switched or packet switched. The same look and feel of the service should be maintained.

Users should be able to indicate their service preferences (e.g. ring tone for specific callers) only once and the service should again be provided irrespective of network domain.

Operators shall be able to re-use their existing CAMEL services in the All IP network (cf. 21.978 [13]).

The development of new CAMEL services shall be supported independently of the network domain. Thus applications developed on CAMEL platforms shall be provisioned to users and be supported in both the packet switched and circuit switched domains in a seamless fashion.

Editor's note: CAMEL/multimedia interaction needs to be considered…

    1. MExE

Release 2000 shall incorporate improvements made in MExE Release 2000 (see 22.057 [9]), building on the (U)SIM certificate support, security and QoS management advances made in MExE Release 99. MExE supports both WAP and Java classmark devices.

MExE Release 99 provides the ability for operators, handset manufacturers and third parties to download applications, service logic and content into MExE terminals from servers. These entities will require that it shall be possible for applications, service logic and content downloaded in Release 99, shall also be downloadable and executable in a consistent manner in a Release 2000 environment. Further, it shall be possible to do so, without the need to redevelop the MExE services in order for them to be supported in the packet domain.

MExE terminals interact with the servers using capability negotiation, and it shall be possible to continue usage of the capability negotiation in the packet domain.

Editor's note: MExE/multimedia interaction needs to be considered…

1   2   3   4   5   6   7

База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка