[Fwd: Peretz's Action Item from last conf meeting]
Eric, see embedded.
Cheers, Peretz (back in the US - please mail some of the progress expected today
on the subject)
Introducing IEEE 802 family PHYs+MACs into UTRAN can/will lead to
> comprehensive re-engineering of the UTRAN products.
Agree and this is of course not desirable
> The commercial UTRAN
> products have been thoroughly optimized for the existing RABs (Radio Access
> Bearers). Note also that 3GPP is working on the evolution of UTRAN and has a
> technical report describing the current situation there, see TR 25.897
> 'Feasibility study on the evolution of UTRAN architecture'. These facts have
> to be taken into account. The comment regarding installed base is also valid
> here, which is an important point for both the vendors and for the
> operators.
>
I am amending the following one more time:
In UTRAN, Service Access Points (SAP) are used for communication among all
these sublayers. Triggers may already be supported in the PHY layer (e.g.
RSSI threshold crossing) and can be easily reported (communicated) through a
newly defined SAPs
or APIs. Other triggers or hints may also be supported across the UTRAN MAC, RLP
and RRC layers and can be provided through new or existing SAPs.
Alternatively a new 2.5 layer could be introduced above the Radio Resource
Control (RRC) and exchange information through new SAPs with all the sublayers
and the RRC itself, which is currently setting up, modifying and releasing layer
1 and 2 entities hence creating events that can be reported as triggers.
This concept is captured below.
This requirement document is not attempting to redefine the 3GPP architecture
but rather proposes new SAPs that in effect provide the layer 2.5 conceptual
functionality while enabling MIH across heterogeneous networks.