status report of smg3 to smg#24 - qt c · status report of smg3 to smg#24 ... cr 03.60-a018r5 on...

ETSI SMG#24 Tdoc SMG 1100/97 Madrid, 14 to 18 December 1997 Source: SMG3 (Technical managers for signalling and chairman SMG3) Date: December 1997

Status report of SMG3 to SMG#24

Abstract:

This document gives an overview of the status of the work within SMG3 for the period between October 1997 (SMG#23 meeting) and December 1997 (SMG#24).

Status report of SMG3 to SMG#24: December 1997

Contents of SMG3 status report to SMG#24

Abstract: ........................................................................................................................................................ 1

1 Recent activities.................................................................................................................................. 3 1.1 Plenary meetings................................................................................................................. 3 1.2 Working Party meetings, Ad-hoc group meetings, Joint meetings ..................................... 3 1.3 CRs, LSs and specifications from SMG3 to SMG#24......................................................... 3

2 Status of the technical specifications.................................................................................................. 6 2.1 General................................................................................................................................ 6 2.2 Radio interface and GPRS (SMG3-WPA)........................................................................... 6

2.2.1 Phase 2........................................................................................................... 6 2.2.3 Release 96 and Release 97............................................................................ 6

2.3 Supplementary services part (SMG3-WPB)........................................................................ 7 2.3.1 Phase 2........................................................................................................... 7 2.3.2 Release 96, Release 97 and next................................................................... 7

2.4 Network part (SMG3-WPC)................................................................................................. 8 2.4.1 Phase 2, Release 96 and Release 97 ............................................................ 8

2.5 System Architecture and UMTS (SMG3-SA) ...................................................................... 9

3 Future work ....................................................................................................................................... 10 3.1 General.............................................................................................................................. 10 3.2 Work Item status ............................................................................................................... 10 3.3 SMG3 meeting schedule after SMG3 #4/97-Brentford...................................................... 10

Annex A: Liaison statement to SMG on version management of SMG3 WPC specifications for Release’97 ............................................................................. 12

Annex B: Liaison statement to SMG on SMS Filtering ...................................................... 14

Annex C: Proposed CR to ITU-T Q.FIN on Roaming concept .......................................... 15

Annex D: Proposal for a contribution to ITU on the interface section of Q.FIN ................. 17


1 Recent activities

1.1 Plenary meetings

One plenary SMG3 session has been held in the period (between SMG#23 and SMG#24):

3 to 5 December 1997 SMG3 plenary #4/97; Brentford, hosted by Samsung Europe 1.2 Working Party meetings, Ad-hoc group meetings, Joint meetings

Several SMG3 working party and ad-hoc sessions have been held in the period (between SMG#23 and SMG#24):

22 to 24 October 1997 SMG3-WPA; 12 to 14 November 1997 SMG3-WPA; Sophia Antipolis, hosted by SMG-PN 6 to 10 October SMG3-WPB-CCBS ad-hoc; Wien, hosted by Siemens 27 Oct. to 1 November SMG3-WPB; Sophia Antipolis, hosted by SMG-PN 1 to 2 December 1997 SMG3-WPB; Brentford hosted by Samsung Europe 20 to 21 October 1997 SMG3-WPC GPRS R97ad-hoc; Grenoble, hosted by Hewlett-Packard 21 to 22 October 1997 SMG3-WPC CAMEL R97 ad-hoc; Grenoble, hosted by Hewlett-Packard 3 to 7 November 1997 SMG3-WPC; Sophia Antipolis, hosted by SMG-PN 1 to 2 December 1997 SMG3-WPC; Brentford hosted by Samsung Europe 6 to 9 October 1997 SMG3-SA; Milano, hosted by Italtel 17 to 21 November 1997 SMG3-SA; Stockholm, hosted by Ericsson 1.3 CRs, LSs and specifications from SMG3 to SMG#24

SMG3 agreed to present the following strategic change requests for Phase 2 (Release 95) to SMG#24 for approval (to be put in version 4.x.x):

CR 03.81-A004r3 on Handling of number parameters related to line identification services (P2)

1045/97

CR 04.08-A249r2 on Clarification on audio connection (Phase 2) 991/97

NOTE: The CRs for Phase 2 (Release 95) were all classified as strategic.

SMG3 agreed to present the following strategic change requests for Release 96 to SMG#24 for approval (to be put in version 5.x.x):

TEI:

CR 03.18 A007r2 on Sending ACM and similar messages only once for a call 911/97 CR 04.07-A010 on Alignment of the compact notation with the way it is used 987/97 CR 04.08-A245 on Inconsistency of user rate in IE bearer capability 986/97 CR 04.08-A255 on Alignment of the compact notation with the way it is used 987/97 Corresponding to Release 96 CRs: CR 03.81-A005r1 Handling of number parameters related to line identification services (R96) 1045/97 CR 04.08-A248r2 on Clarification on audio connection (Release 96) 986/97 Work item "MAP Release 96": CR 09.02-A106r4 on Corrections 917/97 CR 09.02-A107r2 on Addition of a context specific TAG for SendRoutingInfoRes 917/97 CR 09.02-A108 on Object identifier values for proprietary extensions 917/97 Work item CAMEL Phase 1:


CR 03.18 A012 on Interaction between OR of late call forwarding & CAMEL 915/97 CR 03.78 A011 on Removal of CallingPartyNumber from Connect 915/97 CR 03.78 A013 on Removal of the CalledPartyNumber for MO calls from IDP 915/97 CR 03.78 A014r1 on Use of the CallReference Number & GMSC address in SRI 915/97 CR 09.02-A112 on Correction due to GAD 915/97 CR 09.78-A019 on Removal of CallingPartyNumber from Connect 915/97 CR 09.78-A020 on Removal of the transparent mode monitoring 915/97 CR 09.78-A021 on Update the SCCP class requirements in GSM 09.78 915/97 CR 09.78-A022 Remove mapping of CalledPartyBCD number and order sequence in ASN.1 915/97

NOTE: The CRs with category F (correction to Release 96) were all classified as strategic.

SMG3 agreed to present the following non-strategic change requests for Release 96 to SMG#24 for approval (to be put in version 5.x.x):

Work items CAMEL Phase 1 and SOR Release 96:

CR 03.18-A009r3 on Concentration of description of core call handling functions in GSM 03.18

913/97

CR 03.78-A009r4 on Concentration of description of core call handling functions in GSM 03.18

913/97

CR 03.79-A004r3.on Concentration of description of core call handling functions in GSM 03.18

913/97

NOTE: The CRs which were not a correction to Release 96 were all classified as

non-strategic.

SMG3 agreed to present the following strategic change request for Release 97 to SMG#24 for approval (to be put in version 5.x.y):

Work Item CNAP:

CR 04.80-A007r2 on Changes due to CNAP (Release 97-CNAP) 1048/97 SMG3 agreed to present the following non-strategic change requests for Release 97 to SMG#24 for approval (to be put in version 5.x.y):

Work Item GPRS:

CR 03.02-A005r4 on Changes for GPRS regarding network architecture /97 CR 03.60-A011r1 on Idle mode and connected mode 937/97 CR 03.60-A012r1 on SMS delivery path 937/97 CR 03.60-A013r3 on Editorial changes on GSM 03.60 937/97 CR 03.60-A014r5 on Editorial changes and clarifications on GSM 03.60 937/97 CR 03.60-A015r4 on MS Purge for GPRS 937/97 CR 03.60-A016r3 on Maximum N-PDU size 937/97 CR 03.60-A017r4 on To align the anonymous PDP context activation with the non-

anonymous PDP context activation 937/97

CR 03.60-A018r5 on Routing Area Update procedure 937/97 CR 03.60-A019r3 on Clarification of the Routing Area Update procedure and cell identifier 937/97 CR 03.60-A021r2 on TLLI reallocation 937/97 CR 03.60-A022r3 on Additional PDP configuration options 937/97 CR 03.60-A023r3 on GSN number and address

937/97

CR 03.60-A024r4 on Access Point Name 937/97 CR 03.60-A025r3 on More robust Network-Requested PDP Context Activation Procedure 937/97 CR 03.60-A026r1 on Addition of a reset indication message from the SGSN to the VLR 937/97 CR 03.60-A028r5 on Handling of CS paging requests by the SGSN after a failure 937/97 CR 03.60-A030r5 on QoS definitions (only soft copy) 937/97 CR 03.60-A031r2 on Alert and monitoring procedures at the MSC/VLR for class A and B mobiles

937/97

CR 03.60-A032r1 on Further description of the Network-Requested Context Activation 937/97


procedure CR 03.60-A033 on Detach indication from the SGSN to the VLR 937/97 CR 03.60-A035r2 on No more combined (GPRS + non-GPRS) “Ready for SM” notification

to HLR 937/97

CR 04.07-A008r? on Inclusion of GPRS services 988/97 CR 04.64-A001r1 on Various corrections and alignments with other specifications 938/97 CR 04.64-A002r1 on NACK / SACK procedure 938/97 CR 04.64-A003 on T200 default values 938/97 CR 04.64-A004 on Introduction of new primitive 938/97 CR 04.64-A005 on Frame Reject Response 938/97 CR 04.64-A006r1 on Minimum value for N201 938/97 CR 04.64-A007r1 on Cipher parameter Input 938/97 CR 04.64-A008r1 on Introduction of Data Mode parameter in LLC 938/97 CR 04.64-A009 on Separate N201 parameter for I and U-UI frames 938/97 CR 04.64-A010r1 on Cell Update Procedure 938/97 CR 04.64-A011r1 on ABM SAPIs 938/97 CR 04.64-A012r1 on Update of service primitive names 938/97 CR 04.64-A012r1 on Update of service primitive names 938/97 CR 04.64-A013r1 on Maximum number of octets in an information field, N201 938/97 CR 04.64-A014 on Removal of the length indicator field 938/97 CR 04.65-A001r1 on Introduction of new primitive 990/97 CR 04.65-A003r1 on Introduction of header compression for SN-UNITDATA 990/97 CR 04.65-A004r1 on Introduction of data compression for SN-UNITDATA 990/97 CR 04.65-A005r1 on SNDCP XID negotiation 990/97 CR 04.65-A007 on Update of service primitives 990/97 CR 04.65-A008 on Separation of N201-I and N201-U 990/97 CR 04.65-A010r1 on 1st editorial changes 990/97 CR 04.65-A011r1 on 2nd editorial changes 990/97 CR 04.65-A012 on Various corrections to GSM 04.65 990/97 Work Item ASCI Phase 2: CR 03.68-A011 on E-interface issues 989/97 CR 03.69-A010 on E-interface issues 989/97 CR 09.02-A094r2 on Modifications due to ASCI Phase 2 989/97 Work Item SIWF: CR 03.18 A011r1 on Modification due to the introduction of SIWFS 912/97 CR 09.02-A103r6 due to the introduction of SIWFS 912/97 Work Item Network indication of alerting category:

CR 03.18 A004r1 on Introduction of alerting Categories 971/97 CR 04.08-A206r5 on Network's indication of alerting in the MS 971/97 CR 09.02-A084r3 Introduction of alerting indication 971/97 Work Item TEI: CR 04.08-A253 on Multiple allocation of IEIs within one protocol 986/97 CR 04.88-A004 on Call Barring after reconnection (Release 97-CAMEL) 1047/97

NOTE: The CRs to Release 97 were all classified as non-strategic (except for CNAP).

Furthermore, SMG3 agreed to present the following CR to SMG#24 for information:

Work item CAMEL Phase 2:

CR 03.78-A008r8 on CAMEL Phase 2 909/97 SMG3 agreed to present the following specifications to SMG#24 for information:

GSM 10.78 CAMEL Project scheduling and open issues version 1.5.0 916/97


and, SMG3 agreed to present the following specifications to SMG#24 for approval:

GSM 03.53 TFO stage 2 929/97 GSM 09.60 GPRS Tunnelling Protocol (GTP) across the Gn and GPRS Interface 910/97 SPS 03052-1 INAP Protocol specification for CAMEL Phase 1 914/97 SPS 03052-2 INAP PICS for SSF for CAMEL Phase 1 914/97 Moreover, SMG3 agreed to present the following liaison statements and other contribution to SMG#24 (attached to this SMG3 status report):

LS to SMG on Version management of SMG3-WPC specifications for Release 97 annex A LS to SMG on SMS Filtering annex B Proposed CR to ITU-T Q.FIN on Roaming concept annex C Proposal for a contribution to ITU on the interface section of Q.FIN annex D

2 Status of the technical specifications

2.1 General

The technical specifications under the responsibility of SMG3 are considered to be stable for the GSM Phase 1 standard.

The part of the Phase 2 (Release 95) technical specifications under the responsibility of SMG3 are also considered as stable, but in total two CRs are proposed for correction GSM 03.81 and GSM 04.08.

SAME STORY AS TO SMG#21 and to SMG#22 and to SMG#24: It should be noted that because of lack of rapporteurs and active contributors there is a risk that SMG3 needs to propose to delete or postpone several work items. The lack of rapporteurs was already mentioned to several SMG plenary meetings but without success. Especially in the supplementary service area work items can not be progressed. The number of delegates visiting the meetings is growing and growing; unfortunately without sufficient active participation.

SMG3: Chairman: Michel Mouly (Nortel) Vice-chairman Harald Dettner (Siemens) SMG-PN support: Peter van der Arend SMG3 plenary, SMG3-WPB Steffan Aprath SMG3-WPC Fredrik Pettersson SMG3-WPA, SMG3-SA

The following working parties are active within SMG3:

SMG3-WPA: radio-interface & GPRS chairman: OPEN: STILL NO CANDIDATES !!!!!!!!!! SMG3-WPB: supplementary services chairman: Steffen Haberman (T-Mobil) SMG3-WPC: network aspects chairman: Ian Park (Vodafone) SMG3-System Architecture chairman: Michel Mouly (Nortel)

2.2 Radio interface and GPRS (SMG3-WPA)

2.2.1 Phase 2

One correction is proposed for Phase 2 (with corresponding Release 96 CR) GSM 04.08 for Clarification on audio connection.

2.2.3 Release 96 and Release 97

For Phase 2 the following corrections are proposed for Release ’96:


CCBS: Several CRs were agreed by SMG3-WPA. Even the fact that SMG3-WPB and SMG3-WPC are postponing the forwarding for their CCBS specifications and CRs, it was the opinion of SMG3-WPA that their CRs to GSM 04.08 could be forwarded. However some concerns were expressed related to the statement made in SMG#23 on the avoidable reservation of radio channels. After a long discussion it was agreed by SMG3 that also CCBS should be forwarded to SMG as a packet and that the CCBS CRs will be put on hold till SMG#25.

The TeleDanmark view on the CCBS radio resources was forwarded again to SMG3. That document will be handled by SMG3-WPA and SMG3-WPB. TeleDanmark is inviting the next joint meeting of SMG3-WPA/SMG3-WPB on CCBS to come to Denmark (19 to 23 January 1998). TeleDanmark also promised to contribute to the meeting.

GPRS: Several CRs to include GPRS in the specifications are forwarded for approval.

GSM 04.07 and GSM 04.08: Some corrections to GSM 04.07 and GSM 04.08 are proposed.

Meetings: There are still no candidates to chair the SMG3-WPA meetings. The first meeting in 1998 is scheduled for 9 to 13 February (three days) (same date as SMG2-WPA). The agenda for GPRS and GSM 03.22 (for GPRS) have to be harmonised. A host has to be found.

2.3 Supplementary services part (SMG3-WPB)

2.3.1 Phase 2

No corrections are proposed for the Phase 2 standard. There are two outstanding CRs to GSM 09.12. These were agreed by SMG#22 but still need to be considered by SPS1. The outcome of the voting is under discussion within SMG3. The result will be forwarded to SPS1.It should be noted that this specification has not become a part of Release 96, i.e. there is no version 5.0.0 available.

2.3.2 Release 96, Release 97 and next

CCBS: The Stage 2 description of the handling in HLR A and B side is further stabilised. The description of the handling of CCBS activation and CCBS recall MSC/VLR A side is developed. Especially for the description of the handling of CCBS recall in on the A side is very strong related to the existing descriptions of basic call handling in GSM 03.18. It was recognised that for the introduction for CCBS a restructuring of GSM 03.18 is necessary. This was done by the editor of GSM 03.18.

Interworking with MO CAMEL was a major topic for discussion. For this purpose a concept of handling of called party numbers for CCBS activation and CCBS recall was developed. The concept is in some details still under review in WPB. For CAMEL phase 2 a new requirement was introduced by SMG1 very late. The implementation of this requirement is under study. A stable description of CAMEL phase 2 specific handling in GSM 03.18 is needed for further investigation.

Other specifications impacted by CCBS were identified and it was started to draft the appropriate CRs. Some of them are already agreed and put on hold, others are still under study. A list of open items for the development of CCBS was produced as a guideline for the further work.

Stage 3: The modelling in the stage 3 were changed in the way that a clear separation of CC establishment and handling of CCBS related information is separated in different operations. This concept was finalised. SMG3-WPA has aligned GSM accordingly. Some details on handling of HLC and LLC for a CCBS recall is still under study together with SMG3-WPA.

It was agreed in that for the Subscriber control procedures for CCBS a new SS version indicator is necessary. The introduction of the a new SS version indicator as well as the handling of SS version indicator is under study. Further co-operation with SMG3-WPC is required.

In order to allow future use of Facility IE , three different codings for the Facility IE in a MO SETUP message were introduced. This concept was adopted by SMG3-WPA.

SMG3-WPB has recognised complains from companies at SMG#23 on handling of radio resources during CCBS activation. No alternative proposals on this subject were received.


Considering the status of the CCBS specifications in SMG3-WPB and considering the fact that the MAP changes for CCBS will not be finalised at this stage, it is agreed within SMG3-WPB not to sent the specifications for approval for SMG#24. All the already agreed documents are put on hold, in order to allow a approval of the service within one package.

CNAP: Further progress was achieved on CNAP together with Nortel, the rapporteur of CNAP in T1P1. The specifications were reviewed again and comments were forwarded to T1P1. The updated versions of the specifications took the SMG3-WPB comments in consideration. In general the special procedures meeting the north American requirements were taken out of the main body of the specification and put into a normative annex valid for PCS 1900. The specifications were finally endorsed by SMG3-WPB for approval at SMG#24. A LS was sent out before the ongoing T1P1 meeting to indicate this. CR 04.80-A007r2 (Release 97-CNAP) was drafted by T1P1 and commented and corrected by SMG3-WPB. The CNAP service is finilised for the North American operators. In a later stage the European version can be developed. The present work item has to be enhanced or a new work item has to be proposed. For the moment there is no European interest expressed.

CAMEL:

For the introduction of CAMEL some new functionality for the interworking with existing supplementary services are required. The following services were identified so far:

CLIP/CLIR: The concept of additional calling line was introduced. CR 03.81-A004r3 (Phase 2-correction) and CR 03.81-A005r1(Release 96) which are corresponding CRs to GSM 02.81: agreed are proposed as strategic.

Call forwarding: It shall be allowed for certain subscriber to allow registration of non E.164 forwarded-to numbers. A CR to GSM 03.82 is under study. t was recognised that further actions from SMG1 are required to specify more detailed requirements and to align their specifications.

AoC: CAMEL is allowed to control CAI for the AoC service. It will be studied whether WPB specifications are impacted.

Call Barring: CR 04.88-A004 (Release 97-CAMEL Phase 2) is forwarded in order to allow barring notification to a served subscriber after CAMEL reconnection feature.

USSD: It is under study how the new concept of forwarding of USSD operations from the HLR to the gsmSCF is impacting WPB specifications.

In general some concerns were raised how supplementary service related topics are treated within SMG committees without involving SMG3-WPB.

Interaction between CAMEL Phase 2 and Call Forwarding/Call Barring was indicated as in issue for co-operation between SMG3-WPB and SMG3-WPC. It was already indicated that CAMEL Phase 2 will not be ready before SMG#25. The opinion was expressed that SMG3-SMG3-WPB should be get involved in an earlier state. Now the matter has to be solved in a very short time scale. Any possible SS interaction cases with CAMEL has to be indicated to SMG3-WPB.

2.4 Network part (SMG3-WPC)

2.4.1 Phase 2, Release 96 and Release 97

ASCI: CR 09.02 A094r2 (Release 97-ASCI Phase 2) is proposed linked to the stage 2 CRs 03.68-A011 and 03.69-A010 on E-interface issues (Release 97-ASCI Phase 2). The functionality for the support of eMLPP by MAP still has to be solved by SMG3-WPC.

Basic Call Handling (GSM 03.18): CR 03.18-A007r2 (Release 96 -correction) is proposed to show the correct handling of incoming address complete, answer and connect messages on the ISUP.

CAMEL Phase 1: A number of CRs to the CAMEL Phase 1 specifications are proposed to correct lingering errors and to reflect some new requirements which have been sent to us, e.g. from CAGE 2+. SMG3-WPC have also made one minor change to GSM 03.18 to improve the interaction between CAMEL


and OR for late call forwarding in a network configuration where there is not full support for CAMEL. However the CAMEL Phase 1 specifications can now be regarded as very stable.

CAMEL specifications from SPS3: SPS 03052-1 INAP Protocol specification for CAMEL Phase 1, SPS 03052-2 INAP PICS for SSF for CAMEL Phase 1 were reviewed and were agreed by SMG3. Both specifications are forwarded to SMG#24 for approval.

CAMEL Phase 2: SMG3-WPC has now stabilised the technical solutions to meet virtually all the service requirements; there has been a steady exchange of information between us and SMG1, by way of liaison statements and more informal discussions. All the specifications (GSM 03.78, GSM 09.78 and GSM 09.02) have been through at least one cycle of review and improvement; SMG3-WPC continue to use email for exchange of comments between meetings. The updates to GSM 03.18 (the basic call stage 2) have also been reviewed in the form of revised SDL diagrams. The formal CR to GSM 03.18 for CAMEL phase 2 awaits the approval of a CR which makes a major restructuring of GSM 03.18; that latter CR will be presented for approval at SMG3 today. SMG3-WPC expect to be able to deliver the CAMEL CRs for approval by SMG3 at the meeting of 24 to 26 February 1998, and onward routeing to SMG#25. SMG3-WPC propose the somewhat unusual step of sending the current draft of the CAMEL Phase 2 CR on GSM 03.78 to SMG#24 for information. GSM 03.78 for CAMEL phase 2 will be so different from GSM 03.78 for CAMEL phase 1 that SMG3-WPC thought it would be helpful to send the current draft for information, in the form of a “clean” draft of GSM 03.78 as it would be if the current version of the CR were approved.

CCBS: The main issues of work for SMG3-WPC are the changes to GSM 03.18 and GSM 09.02. The great majority of SMG3-WPC resource has been applied to CAMEL Phase 2 and GPRS, and the CCBS specification work in SMG3-WPB has only recently produced a stable stage 2 on which to build, so SMG3-WPC have not been able to make as much progress on CCBS as SMG3-WPC would have liked. However Ericsson have been working hard on the MAP CR, which is making useful progress. Nokia have offered to provide resource to progress both the MAP CR and the GSM 03.18 CR, and with this added effort SMG3-WPC should be able to deliver in time for SMG#25.

SMG3-WPC has completed a block of work which can be seen as a foundation stone on which to build CCBS and other services which interwork closely with call handling: a set of 3 CRs to remodel GSM 03.18, GSM 03.78 for CAMEL Phase 1 and GSM 03.79. These CRs can probably lay claim to being the largest editorial CR in GSM history: 224 pages with no technical impact!

GPRS: The GPRS subgroup in SMG3-WPC has laboured long and hard under the chairmanship of Miguel Cobo, and have produced the draft of GSM 09.60, which will be presented for approval, and the GPRS changes to GSM 03.07, GSM 03.08, GSM 03.16 and GSM 03.18 (yes, really!), which will also be presented for approval. Unfortunately the GPRS changes to MAP have not been completed, so the GPRS work in SMG3-WPC is not complete; with a final push in the first 6 weeks of 1998 (not to mention the run-up to Christmas!) SMG3-WPC should be able to offer the last piece of the GPRS SMG3-WPC jigsaw to the next meeting of SMG3, for approval by SMG#25.

MAP corrections: As requested by SMG#23, SMG3-WPC has agreed a CR to MAP to allow monitoring equipment to decode MAP messages without a knowledge of the application context being used. SMG3-WPC have also agreed two CRs for corrections to MAP 96.

Network Indication of Alerting: CR 03.18-A004r1 and CR 09.02-A084r3 (Release 97-NI alerting) are proposed for network indication of alerting. The evolution of GSM 03.78 and GSM 09.78 for CAMEL Phase 2 will also define support for control of alerting indications by the CAMEL server.

SIWF: This is a bright patch - well nigh single-handedly. CRs 03.18-A011r1 and 09.02-A103r6 (Release 97-SIWF) for the Shared Inter Working Function, which are forwarded for approval. The work item SIWF is finilised as far SMG3 is concerned. (GSM 03.02??)

2.5 System Architecture and UMTS (SMG3-SA)

GSM Release '97

GPRS: GPRS CR are forwarded.

Network selection multiple terminal: further work will be done on DECT-GSM and Satellite-GSM.


MNP: stage 1 was studied with several other contributions, no outcome.

TFO: It was the intention of SMG3-SA to forwarded the TFO specification for information, however the specification was not made available to SMG3 nevertheless the specification is forwarded to SMG#24 for information. ???????

UMTS: Work is going on.

ASCI: CRs are proposed to the stage 2 specifications of VBS and VGCS.

3 Future work

3.1 General

SAME STORY AS TO SMG#22 and to SMG#23: In general there seems to be a reasonable support for most of the work items, however most of the work is done by a limited number of participants, c.q. companies. It has to be mentioned again that for the "new" supplementary services there is no support at all.

3.2 Work Item status

Network indication of alerting: 3 CRs are forwarded; more changes may be required.

CAMEL Phase 2: Draft GSM 03.78 for information; WI not finalised for SMG#24; the goal is SMG#25.

GPRS: CRs are forwarded; WI not finalised for SMG#24; the goal is SMG#25.

CCBS: No CRs will be forwarded. WI not finalised for SMG#24; the goal is SMG#25.

SIWF: WI finilised

ASCI: CRs to GSM 09.02, GSM 03.68 and GSM 03.69 are forwarded.

TFO: stage 2 for information

CNAP: CR to GSM 04.80 is forwarded and CR to GSM 03.18 is planned for GSM#26.

3.3 SMG3 meeting schedule after SMG3 #4/97-Brentford

24 to 26 February 1998 SMG3 plenary #1/98; no host yet 2 to 4 June 1998 SMG3 plenary #2/98; no host yet ** Vodafone and BT } are investigating 22 to 24 September 1998 SMG3 plenary #3/98; no host yet ** T-Mobil } hosting possibility 24 to 26 November 1998 SMG3 plenary #4/98; no host yet 9 to 13 February 1998 SMG3-WPA; No host/NO CHAIRMAN (May be Sophia Antipolis) (3 days; to be harmonised with SMG2-WPA) 19 to 23 January 1998 SMG3-WPB #1/98-CCBS ad-hoc #1/98; may be hosted by TeleDanmark partly joint with SMG3-WPA and SMG3-WPC 9 to 13 February 1998 SMG3-WPB #2/98; no host yet 26 to 30 January 1998 SMG3-WPC; Vienna host Siemens: Parallel ad hoc meetings on CAMEL and GPRS16 to 20 February 1998 SMG3-WPC; Sophia Antipolis, host SMG-PN Regular SMG3-WPC meeting, targeted to finalise outputs for SMG#2530 March to 3 April 1998 SMG3-WPC; no host yet18 to 22 May 1998 SMG3-WPC; no host yet13 to 17 July 1998 SMG3-WPC; no host yet7 to 11 September 1998 SMG3-WPC; no host yet9 to 13 November 1998 SMG3-WPC; no host yet 19 to 23 January 1998 SMG3-SA; Malmø, host Telia 23 to 27 March 1998 SMG3-SA; Wien, host Siemens 20 to 24 April 1998 SMG3-SA; no host yet


(may be Teleside or Telecom Italia or Lucent Technologies)


Annex A: Liaison statement to SMG on version management of SMG3 WPC specifications for Release’97

SMG3 meeting #4/97 Tdoc SMG3 97P491 Brentford, 3 to 5 December 1997 Source: SMG3

To: SMG

Title: Liaison statement on version management of SMG3 WPC specifications for Release’97

In their November meeting SMG3-WPC performed a detailed analysis of the specification version management requirements for all the technical specifications for which they are responsible. The general conclusion from this analysis was that a single approach to specification version management would not be satisfactory.

It is SMG3-WPC’s opinion that the approach of using a single document stream for multiple releases (i.e. Release’96, ‘97, etc.), with new features identified with a Release number text tag, is appropriate for the following specifications:

GSM 03.07, GSM 03.08, GSM 03.15, GSM 03.16, GSM 09.10

However, SMG3-WPC has very strong reservations about using this approach for GSM 03.78, GSM 03.79, GSM 09.02 and GSM 09.78, for the following reasons:

- The readability of these documents will be seriously compromised if Release number text tags are introduced. In particular the SDLs in GSM 03.78 and GSM 03.79 will lose clarity. For GSM 09.02 and GSM 09.78, it is not seen as a practical solution to indicate in ASN.1 which parts belong to Release 97.

- It was felt that it may not be possible to create Phase 3 CAMEL (Release 98) specifications, which

clearly identify which aspects belong to which phase/release of CAMEL. Therefore, it is important to have separate document streams for each release of CAMEL so that it is clear in the future which CAMEL functionality belongs to which Phase of CAMEL.

- It was felt that vendor compliance documentation for these specifications would be made more

complicated than need be if a single document stream approach was taken for future releases. - Time which could have been spent improving the technical content of Release’97 of these

specifications will need to be spent reviewing the way the Release’97 aspects are identified. Therefore, SMG3-WPC requests that the following approach be taken for future releases of GSM 03.78, GSM 03.79, GSM 09.02 and GSM 09.78:

1) For each release where new features are added to the specification a new documentation stream should be created. This should be similar to the new document streams created for Phase 1, Phase 2 and Phase 2+ GSM specifications.

2) Each document stream should be maintained until stable. This may generate the requirement for

Change Requests to multiple streams of a particular specification but in the past this has been shown to work for specifications such as GSM 09.02.

3) Each GSM Release of these specifications should be identifiable via a version number, for example

for Release’97 version 6,x,y or 97,x,y could be used. 4) No additional text should be added to these specifications (hidden or otherwise) purely for the

identification of the release in which a certain aspect of the specification was introduced.


It is recognised that GSM 09.02 includes information which is imported into GSM 04.80, and therefore affects the behaviour of the MS. The information which is imported from GSM 09.02 to GSM 04.80 consists of the definition of the operations and associated data types for call-independent SS operations: register, erase, activate, deactivate and interrogate. MAP acts simply as a relay mechanism to carry these operations and their results between the MS and the HLR, so it seems to be appropriate to transfer the ‘master’ definition to GSM 04.80, and import it from there into GSM 09.02. SMG3 WPB and SMG3 WPC have agreed to study the detailed implications of this approach, which would remove GSM 09.02 from the list of specifications which affect the behaviour of the MS.

SMG3-WPC believe that GSM 03.18 is a special case. A copy of the latest version of this specification will show how any network feature introduced into GSM will interact with any feature from a current or previous release, from a call handling perspective. Hence SMG3 WPC would like to see a single stream approach be taken for future releases of this specification but with no tagging of the release in which new features are introduced.

SMG are asked to note that this liaison statement addresses only the version management of specifications which are the responsibility of SMG3-WPC; SMG3 did not reach a conclusion on version management of specifications which are the responsibility of other parts of SMG3.


Annex B: Liaison statement to SMG on SMS Filtering

SMG3 meeting #4/97 Tdoc SMG3 97P465 Brentford, 3 to 5 December 1997 Source: SMG3

To: SMG

cc: SMG4

Subject: Liaison statement to SMG on SMS Filtering

In the last meeting of SMG3-WPC a Change Request to GSM 09.02 was reviewed which defined a mechanism by which the HLR could filter Mobile Terminated Short Messages based on information provided by the SMS-GMSC.

SMG3 is of the opinion that the proposed solution is probably the best solution that could be introduced using a MAP based SMS Filtering approach. However, SMG3 has identified a number of limitations which it believes SMG should be aware of, namely:

• The solution places a requirement on the SMS-GMSC to incorporate new parameters in the MAP message which it uses to obtain routing information from the HLR. It is questioned whether the SMS-GMSC/Service Centres which the filtering mechanism is likely to target will invest in this development.

• In the case where the Service Centre has multiple Short Messages to deliver to a subscriber, only information about the originator of the first message will be passed to the HLR for possible filtering.

SMG3 has investigated the possibility of using alternative technologies to meet the service requirements of SMS filtering. After this investigation it was concluded that other technologies such as CAMEL did not offer a feasible approach. Therefore, SMG3 believe that additional analysis of this issue would not be fruitful.

SMG3 asks SMG whether the proposed solution for filtering Short Messages at the HLR will be acceptable, given its limitations. If it is, SMG3 will submit a CR to GSM 09.02 for approval at SMG#25. However, if SMG believes that the limitations of this solution are not acceptable, SMG3 recommend that this work item should be deleted.


Annex C: proposed CR to ITU-T Q.FIN on Roaming concept

SMG3 meeting #4/97 Tdoc SMG3 97P500 Brentford, 3 to 5 December 1997

ITU-Telecommunication Standardisation Sector

Meeting (Q.8, Q.23. & Q.24) rapporteurs TD 3/11 Hawaii-

Hawaii, USA 06-17 January 1998

Document addressed to : WP 3/11 Text available only in English

Question(s) : Q8/11

Source : An ITU member (tbd) on behalf of ETSI SMG

Title : Change request for Q.FIN

Status in SMG: For discussion in SMG#24: SMG3 approved.

A new clause in Q.FIN is proposed as follows:

6.4 Roaming Concept

6.4.1 Two Tier Roaming Concept

This clauseRoaming in this paper addresses roaming between networks (inter network roaming). This can be roaming between regional networks within a country or between national/regional networks in different countries.

ItWe must be distinguish whether the two networks involved in roaming (the home network and the visited network) belong to the same IMT 2000 system or two different systems (intra system roaming and inter system roaming).

IMT 2000 global roaming encompasses both inter system and intra system roaming. It should therefore be called a two tier roaming concept.

6.4.2 Intra System Roaming

The intra system roaming uses the architecture and protocols of each system.


6.4.3 Inter System International Roaming

The inter system international roaming is based on the following architecture:

A B

Network ofSystem A

Billing ITSystem A

A B

Network ofSystem B

Billing ITSystem B

Inter-workingfunction

Multimodeterminals

Networks

Billing ITsystems

Inter-workingfunction

Figure 1: Architecture for Inter System International Roaming

Note: An interworking function may be defined by, for example, protocol translators or implementation of two protocols in one entity.

6.4.4 Enabling Inter System International Roaming

The framework architecture and the principles as described above should be standardised in ITU SG11.

The regional standardisation organisations, who standardise IFS members should enter into discussions to seek international commonalties to enable Inter System International Roaming. This could include commonalties in subscriber identities, service definition, authentication, radio interface, network aspects and accounting protocols. The target of these activities should be simplification of multimode terminals and simplification of system interfaces.

The interested parties representing the variouspossible network operators of different IFS members should agree on requirements for Inter System International Roaming to guide the standardisation work.

****************


Annex D: Proposal for a contribution to ITU on the interface section of Q.FIN

SMG3 meeting #4/97 Tdoc SMG3 97P502 Brentford, 3 to 5 December 1997

Subject : Proposal for a contribution to ITU on the interface section of Q.FIN

ITU-Telecommunication Standardisation Sector

Meeting (Q.8, Q.23. & Q.24) rapporteurs TD 3/11 Hawaii-

Hawaii, USA 06-17 January 1998

Document addressed to : WP 3/11 Text available only in English

Question(s) : Q8/11

Source : An ITU member (tbd) on behalf of ETSI SMG

Title : Text about the interfaces for Q.FIN

Status in SMG: For discussion

It is proposed to modify clause 8 of Q.Fin as follows :

8 Interfaces for study 8.1 list of interfaces

After considerable discussion a list of interfaces has been developed which are considered to be necessary to be identified and all shall be covered by ITU Recommendations standards but one are for standardisation in ITU.(See fig. 2.)

These are:

• The Network to Network interface (NNI)

• The User to Network interface (UNI) (Editorial note: This term needs definition. It may be replaced by ’Radio Interface’ - awaiting contributions.)

• The User Identity Module interface (UIM)

• For further study is Tthe Radio Access network to Core network (RAN to CN)

Two complementary pictures are produced, one showing in Fig 2 the physical viewpoint and the other in Fig 3 from a functional viewpoint. This is done as, for instance, it was seen as essential that the radio independent protocols such as call control, application and service control and location management are carried transparently from the user agent in the terminal to the core network. (other cases for further study)

In the following text, a set of specifications for a functional interface is a standalone set of ITU Recommendations documents providing specifications fulfilling all the requirements and objectives for the functional interface. A set of specifications for a functional interface can be developed by a regional organisation, and then adopted by ITU.


Note 1: a) Functional requirements / objectives will be common among family members. b) Functional elements and information flows may be different among family members.

Note 2: There may be intra-family member communication which perform similar functionality to the NNI but this is outside the scope of the ITU.

Figure 2. Physical Interfaces of an individual Family member

(Core networks of other IMT 2000 Family Members)

UIM MT RAN CN

UIM - MT

Radio Interface

(UNI)

RAN - CN NNI


Figure 3. Functional Interfaces of an individual Family member

(core networks of other IMT 2000 Family members)

8.2 The NNI interface.

This is the interface between different core networks.

For a given user in a roaming situation, and for a typical call, the CN shown in Figure 3 interacts with two CNs in the ‘other CN’ clouds, one related to the UIM and the other related to the other party in the call. We will call ‘Serving CN’ the CN in the box, ‘Home CN’ the CN in the cloud and related by subscription to the UIM, and ‘Transit CN’ the CN in the cloud which provides a communication path from the Serving CN toward the other party.

The NNI interface can then be functionally divided in several functional interfaces, two of them of relevance in the model, the one between the Serving CN and the Transit CN, and the one between the Serving CN and the Home CN.

In addition at least another functional interface may appear at the NNI interface, between UIM and Home Network. This functional interface has to be considered as an intra-family member communication.

8.2.1 Serving CN to Home CN

UIM MT RAN CN

UIM - MT MT - RAN RAN - CN

MT - CN

CN -CN


For this functional interface, different sets of specifications may be developed for different family members. In order to support roaming between them, a Serving CN and a Home CN from different family members need to implement a suitable specification in common.

8.2.2 Serving CN to Transit CN

This functional interface shall be covered by one set of specifications, or several sets of specifications. End-to-end calls between Core Networks can be provided only if the serving CN and the Transit CN implement a suitable (e.g., to the call) specification in common.

Text to be refined by contributions

8.3 The MT-CN interface

This is the interface between the terminal user and the network.

For this functional interface, the set of specifications may be different among family members.


8.4 The UIM interface

This is the so-called ‘smart card’(User Identity Module) interface in the handset.

This corresponds to one functional interface of relevance for the model, UIM-MT. Other functional interfaces may appear on the physical interface, such as UIM-Home CN mentioned above.

Different aspects of the UIM-MT functional interface have to be dealt with separately.

It appears important to allow that MT manufacturers to design a common hardware and software platform independently of UIM family. For this avail, the lower layers of the UIM-MT interface, including all the layers having a hardware impact (e.g., size, contacts, electrical specification, voltage, basic information exchange protocols), shall be covered by a unique IMT-2000 specification, based on ISO standardisation. This may apply also for instance to mechanisms related to the support of multiple UIM applications on the same physical device (e.g., Ic-card).

For higher layers (e.g., exchanges between the ME and the UIM application), the set of specifications may be different among family members.


8.5 The RAN to CN interface

This is not yet agreed for standardisation. It was noted that this interface could include fixed radio, CTM, DECT and wireline as well as the more familiar radio interface (CN-AN)

This section addresses only the lower layers (e.g., not the MT-CN functional interface).

For this functional interface, it is expected that there will be different sets of specifications. However, it seems preferable that for a given set of specifications for the MT-RAN interface there is a unique set of specifications for the corresponding RAN-CN interface.


8.6 The MT-RAN interface

The development of different sets of specifications is expected, because of the requirement to support different access techniques. In additionHowever, for the cellular radio access using the IMT-2000 cellular bandwidth, the set of specifications may be different among family members the aim is to have a single specification. Other sets of specifications for this interface can be entered in the family for other physical media (e.g., fixed radio, CTM, DECT, wireline, ...).


****************

status report of smg3 to smg#24 - qt c · status report of smg3 to smg#24 ... cr 03.60-a018r5 on...

Documents