5 Functions location inside/outside Access Stratum

23.1103GPPRelease 17Services and functionsTSUniversal Mobile Telecommunications System (UMTS) access stratum

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

Following table shows the functional split between Access Stratum and the rest of the system.

Table 1: Functions inside/outside the Access Stratum

LOCATION \ FUNCTION	Outside the Access Stratum	Inside the Access Stratum
Call set up/release	yes	no
(Connection) Bearer Set-Up Release	CN bearer [tbd]	Radio Access Bearer [tbd]
Supplementary Services	yes	no
Location management	yes (IWF/CN related)	yes (Radio related)
Attach/ Detach	yes	FFS, Contr expected
Resource Management	yes (for NAS resource)	yes (for AS resource incl. radio)
Handover	yes*	yes
Macrodiversity [ffs]	yes*	yes
Encryption	yes	yes**
Authentication	yes	no
compression (non source dependent)	yes	yes
source dependent coding	yes	no
radio channel coding (could be many)	no	yes (could be many)
UE location identification	may be supported	yes
Charging	yes	no
NOTE : Optionally execution. In some CNs, it may not be present but not full service will be supported (e.g. limited to RLL type of service). NOTE *: Contributions expected to clarify the role between encryption and subscriber data.

5.1 Call Control

This Functionality is placed in the NAS, since it manipulates the call state machine. An example is termination of Q.931 message and sending of ISUP.

Not part of AS. NAS specific signalling messages, e.g. Q.931, Q.2931 and ISUP.

5.2 (Connection) Bearer Control

It is distinguished between the bearers used in the NAS and the common bearer used in the AS (radio access bearer).

Basic principles for radio access bearers are:

1) Radio access bearers provide information transport between the non‑access stratum parts of the infrastructure side (i.e. the edge node) and the user equipment side. Radio access bearers shall support real time as well as non real time user traffic.

2) Radio access bearers must be flexible enough to support different traffic types, activity levels, throughput rates, transfer delays and bit error rates. Attributes allowing efficient use of radio resources are crucial.

3) Efficient mapping from the traffic attributes used by non-UMTS applications, given by dominating external network technologies, to the attributes of the radio access bearer layer of the access stratum is essential. Complexity in mapping procedures should be avoided.

4) Definitions of traffic attributes and traffic management for radio access bearers shall be consistent with the predominant networking technology on the market (e.g. N-ISDN and IP networks for UMTS phase 1). As networking technologies emerge, adapted radio access bearer attributes and types shall gradually be added.

5) Radio access bearer definitions must allow for straightforward and efficient traffic management and resource handling of the radio resources in the access stratum.

This procedure is part of the NAS. Example are 13.0 kbit/s (for GSM speech) and 2B+D (for ISDN BRI).

The protocols required in AS to provide a radio access bearer should be able to describe both packet switch and circuit switch types of connections.

5.3 Supplementary Services (CLIP, CF etc.)

Supplementary services are part of the NAS, since they manipulate the Call state machine.

Supplementary services are not part of AS since they manipulate the call state machine.

5.4 Location Management

"Location Updating Management" and "Paging" is an existing example of Location Management.

Location Management may be supported in the NAS.

Radio related Location Management may be part of the AS.

5.5 Attach/ Detach

If the Attach/ Detach procedures are supported in the NAS they use CN specific identifiers to mark the attached/detached subscriber. As an example in GSM, the attach/detach procedure is performed on the IMSI flag, and therefore it is a NAS functionality.

Attach/Detach may be performed in the AS using the URAN unique identifiers. This is FFS.

5.6 Resource management

This function allocates resources for a given information stream, as to allow to convey it with a given QoS. This information stream may support either signalling data (CC, MM, …) or user data.

Both circuit switched and packet access are supported, offering both connection oriented and connectionless services.

The AS resource management is transparent for the NAS and vice versa.

5.7 Handover

5.7.1 Handover – outside Access Stratum

Handover may be a NAS functionality, but it can not be expected that all CNs will support handover therefore the IWF may take care of any required handover functionality. The AN may leave certain parameters, e.g. the address to a new IWF/CN‑AN connection point, to which the IWF/CN may switch if it has the capabilities.

5.7.2 Handover – inside Access Stratum

Handover is performed in the AS, to hide all radio specific details from the NAS.

5.7.3 Handover scenarios supported by the Iu interface

The following clauses describe which functions will be supported by the Iu interface. Some functions have no impact on the Iu interface and therefore will be supported de-facto, nevertheless they are explicitly mentioned for completeness of the scenarios.

5.7.3.1 Classification A

Classification A describes the way the handover is prepared:

HO A1: the network has informed the target cell before the MS changes cell;

HO A2: the network has not informed the target cell before the MS changes cell;

HO A3: the mobile has informed the target cell before it leaves the source cell.

HO A1 is typical of the existing handover in GSM.

HO A2 reflects the call re-establishment in GSM, mobile directed handovers in general, or even GPRS to some extent (although the GPRS vocabulary is different).

HO A1, HO A2 and HO A3 shall be supported by the service primitives of the Iu interface.

5.7.3.2 Classification B

Classification B describes the way the decision to initiate a handover is taken:

HO B1: decision is taken by the terminal;

HO B2: decision is taken by the network.

When the network takes the decision, it can be either in the RAN (HO B2a), or in the CN (probably based on information provided by the RAN and/or the MS) (HO B2b).

In order to keep the radio independence from the CN, it would be desirable that the decision be taken only in the RAN. This means that a communication mechanism is needed between URANs, that interface being logically different from the Iu interface.

HO B1 and HO B2 shall be supported by the service primitives of the Iu interface.

NOTE 1: FFS: For HO B2 cases, handover initiation/decisions shall be taken by the source URAN.

NOTE 2: FFS: There is a URAN to URAN signalling mechanism transparent to the CN. A standardised protocol will be implemented across that interface to allow handover decisions by the URAN in HO B2 cases.

5.7.3.3 Classification C

Classification C concerns the kind of handover performed:

1) intra-cell handover;

2) intra-URAN handover;

3) inter-URAN handover (without change of CN access point);

4) intra-CN handover with same URAN type;

5) intra-CN handover with different URAN type;

6) inter-CN handover with same URAN type and same CN type;

7) inter-CN handover with different URAN type and same CN type;

8) inter-CN handover with same URAN type and different CN type;

9) inter-CN handover with different URAN type and different CN type;

10) inter-CN handover without change of URAN.

The type of URAN type should be relatively transparent to the Iu interface.

Regarding handovers across multiple CN, it is proposed that this is supported (and this is already possible with GSM).

C1 to C7 scenarios shall be supported by the service primitives of the Iu interface.

NOTE: FFS: scenarios C8 to C10 shall be supported by the service primitives of the Iu interface.

5.7.3.4 Classification D

Regarding how a handover is performed, there is the possibility to either have the notion of anchor point, or not to have it. Example is circuit switched GSM, using anchor points, and GPRS, not using that notion.

Furthermore, the notion of anchor point may be handled differently for the signalling plane and the transmission plane.

The notion of anchor point shall be supported by the service primitives of the Iu interface.

NOTE 1: FFS: the notion of transmission plane anchor point is supported by the service primitives of the Iu interface.

NOTE 2: FFS: the notion of signalling plane anchor point is supported by the service primitives of the Iu interface.

NOTE 3: FFS: the anchor points for the signalling plane and transmission plane need not necessarily be the same or even exist simultaneously. The flexibility should be left in UMTS by the Iu service principles.

5.8 Macrodiversity

(if needed, dependent of the choice of multiple access technology)

Not all IWF/CNs will support macrodiversity.

Macrodiversity may be supported in the AS, dependent on the choice of multiple access technology.

5.9 Encryption

The NAS may support encryption to protect the transmitted data.

The AS needs to support encryption to prevent from eavesdropping at the radio interface.

5.10 Authentication of Subscriber

Subscriber data is stored in the NAS and therefore authentication should be considered a NAS functionality.

NAS data is not stored in the URAN, and subscriber authentication can therefore not be a URAN functionality.

5.11 (Non source dependent coding) Compression

NAS may support compression.

The AS should support compression to optimise usage of radio resources.

5.12 Source (e.g. voice or video) Coding

Source coding is different dependent on IWF/CN and is therefore a NAS functionality.

5.13 Radio Channel Coding

Radio Channel coding is needed due to the radio interface and could therefore be considered a radio functionality. Radio Channel coding is not a NAS functionality.

Radio Channel coding is supported by URAN.

5.14 UE Location Identification

The UE location identification may be supported by the UE and/or the access network side of the AS; i.e., URAN; e.g., as defined in the GSM LCS (Location Services) specifications or by some other means. The UE location identification is provided to identify the likely location of specific UEs. This is meant to be used for charging, location-based services, lawful interception, emergency calls, etc., as well as the positioning services.

When location identification is supported by URAN, the following apply:

URAN obtains ‘Area ID’ and/or geographic co-ordinates with uncertainty parameters for identification of the likely location of UE, to be sent to the NAS entity side of the CN (i.e., edge node) ‘Area ID’ represents either a radio access cell/sector or a geographic area. ‘Area ID’ is coded in the same format as Cell Global Identification (CGI), for compatibility to GSM.

Location information is categorised to two levels of accuracy. The Basic Level of information is what URAN obtains without extra signalling with the UE. The advanced level is obtained through extra signalling for positioning. Both levels can be used for both, Positioning services and other applications.

Location information is always at least obtained from URAN by the appropriate edge node(s) at the activation of a Call/PDP Context. Mechanism to make it possible to obtain the location information at the release of a Call/PDP Context should be specified. Location information sent to the edge node at other occasions is on the basis of asynchronous requests from the edge node to URAN. An edge node can request URAN to send the location information with the two types of requests, Type 1 (Direct request) where URAN sends location information only once at the request and Type 2 (Event request) where URAN sends location information at each specified event (e.g. Cell Update) requested by the edge node.

5.15 Charging

The functions related to charging are not part of the AS. These functions are mainly:

– charging information generation;

– charging processing.