Добавил:
linker.pp.ua Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
4g - LTE / Rel-08_description_20140924 / Rel-08_description_20140924.doc
Скачиваний:
86
Добавлен:
15.12.2018
Размер:
3.85 Mб
Скачать

23.5 Study on InterWorking Function between map based and Diameter based interfaces uid_380023

Resources: C4

References

Document

Title/Contents

WID(s)

CP-070760

SID on InterWorking Function (IWF) between MAP based and Diameter based interfaces

Impacted Specifications

-

-

New Dedicated Specifications/Reports

TR 29.805

InterWorking Function (IWF) between MAP based and Diameter based interfaces

Supporting Individual Members: Huawei, Vodafone, Orange, T-Mobile, Ericsson, RITT, TeliaSonera, Motorola, Alcatel-Lucent, China Mobile.

This work is linked to the SAES Feature UID_320005.

With network evolution to an all-IP-network, IP based signalling protocols are getting widely used in 3GPP systems. The number 3GPP defined Diameter-based interfaces increased for e.g. PCC, I-WLAN, MBMS, GBA architecture. Due to coexistence in the same system of new and legacy protocols (based on different transport layers e.g. IP and SS7), interworking between these protocols is required by operators.

This study evaluated complexity, performance and duality of an IWF based on concrete use cases. It recommended how to map procedures and parameters, and where to locate the IWF within the network in order to ensure less IWF complexity and best performance.

TR 29.805 evaluates the introduction of an IWF between MAP-based and Diameter-based interfaces. For each interworking deployment scenario, it analyzed how the IWF fulfils specific interworking requirements, and performs mapping of procedures and corresponding parameter handling.

Uses cases involving inter-operator interfaces got higher priority than intra-operator interfaces.

TR 29.805 conclusions:

  • IWF scenario 1 to 4 should be specified in Rel-8;

  • IWF scenario 5 is not supported in Rel-8.

Spin-off implementation Building Block UID_410007 (MAP2Diam) under the SAES Feature UID_320005.

24 Ran Studies

24.1 Study on Scope of future hspa Evolution for 1.28Mcps tdd uid_370041

Resources: R1

References

Document

Title/Contents

WID(s)

RP-070748

SID on Scope of future HSPA Evolution for 1.28 Mcps TDD

Impacted Specifications

-

-

New Dedicated Specifications/Reports

TR 25.824

Scope of High Speed Packet Access (HSPA) Evolution for 1.2 Mcps TDD

Supporting Individual Members: TD Tech, ZTE, CATT, Spreadtrum.

The importance of enhancing capabilities and performance of HSPA-based radio networks is widely recognized. For protecting operators' investments and offering a smooth migration path towards LTE, the following principles for HSPA evolution were considered:

  • HSPA spectrum efficiency, peak data rate, state transition efficiency and latency of both user plane and control plane should continue to evolve;

  • Evolved HSPA should be able to operate as a packet-only network based on utilization of Shared Channels only;

  • HSPA evolution should be backward compatible in the sense that legacy terminals (R99-DCH and HSPA mobiles) should be able to share the same carrier with terminals implementing the latest features of the HSPA evolution track without any performance degradation;

  • Evolved HSPA should be able to offer more efficient QoS support.

The study focussed on improving system performance for services delivered through PS-domain including voice and multimedia conversational services. Critical elements of such an evolution were included e.g. reduced latency, higher user data rates, improved system capacity and coverage, reduced operator cost while maintaining the highest possible level of backward compatibility. The study concentrated on the following items:

  • Define a set of requirements for HSPA evolution which covers the following aspects:

  1. Targets for improvements in latency, throughput and spectrum efficiency utilizing the existing 1.28MHz bandwidth

  2. Define constraints in terms of acceptable hardware/software changes to current elements (UE, Node, RNC, SGSN, GGSN)

  3. Define constraints in terms of acceptable network architecture changes

  • Determine performance benefits achievable by HSPA and in which scenario HSPA evolution applies most;

  • Identify potential solutions to improve HSPA performance towards agreed targets within the defined constraints;

  • Make recommendations for subsequent HSPA Evolution implementation work items.

Last Status Report in RP-080290.

NOTE: TR 25.824 and Status Report provide neither Conclusions and Recommendations nor a Work Plan.

Соседние файлы в папке Rel-08_description_20140924