Agenda item	Agenda item title	Tdoc 3GPP N2-99	Title	Source	S
W
G	Result	
1	Opening, approval of agenda	A61	Proposed meeting agenda	N2 Chairman	P		
2	Document allocation	A62	Proposed allocation of documents to agenda items	N2 Chairman	P		
3	Review of reports of previous meetings						
3.1	N2 & N2B	A63	Report of N2 meeting, Visby, 19 - 23 July 1999	MCC	P	Endorsed as correct	
		A64	Report of N2B meeting, Stockholm, 24 - 26 August 1999	MCC	P	Endorsed as correct	
4	Input liaison statements: allocation to subgroups	B47	LS to TSG N WG2 regarding changes to GSM 09.02 to clarify triplet re-use conditions	SMG10	P	To N2B (6.9)	
		B50	Proposed LS on MO SMS triggering in CAMEL phase 3	MoU-SERG	P	To N2A (6.1.4)	
		B51	Liaison statement on addition of 3rd MNC digit in routing area identification	3GPP N1	P	To N2B (8.2)	
		B54	Liaison Statement on multicall and enhancement of call barring services	3GPP N1	P	To N2B (6.5)	
		B55	Liaison Statement on SAT/MExE <-> CAMEL Interworking / Traceability	3GPP N1	P	To N2A (6.1.11)	
		B58	Answer to Liaison Statement from CN WG2 on CN Domain Identifiers used over the Iu & Iur interfaces	3GPP R3	P	To N2B (6.11.5)	
		B59	Liaison Statement to CN WG2 on the allocation of an SSN for RNSAP	3GPP R3	P	To N2B (6.11.2)	
		B64	LS answer to Overall Delay Budget within the Access Stratum Results and Requirements	3GPP S2	P	To N2B (6.11.6)	
		B65	Answer to the liaison on Interoperation between UMTS and GSM	3GPP S2	P	Noted	
		B66	Answer to the liaison on Enhanced User Identity Confidentiality	3GPP S2	P	To N2B (6.9)	
		B67	Answer to the liaison on Evolution to UMTS and R99 Security Features	3GPP S2	P	To N2B (6.9)	
		B68	Answer to the liaison on the time constraints on the execution of cryptographic algorithms	3GPP S2	P	To N2B (6.9)	
		B69	Liaison Statement on the handling of 03.60	3GPP S2	P	To N2B (6.3)	
		B70	Answer to Liaison Statement concerning Paging Co-ordination	3GPP S2	P	Noted	
		B71	CN Domain Identifiers used over the Iu & Iur Interfaces	3GPP S2	P	To N2B (6.11.5)	
		B72	Security interoperation between UMTS and GSM	3GPP S2	P	To N2B (6.9)	
		C18	3G TR 23.907: QoS Concept and Architecture	3GPP S2	P	We are asked to review and provide comments to S2 in time for their QoS ad hoc on 16 Sep 1999 To N2B (6.11.7)	
		C35	Response to the N2 Request to Maintain Codec Type and configuration	3GPP S4	P	To N2B (6.7)	
		C36	LS on Tandem Free Operation, Transcoder Free Operation, DTMF Signalling	3GPP S4	P	To N2B (6.7)	
		C37	LS about Synchronisation	3GPP T2	P	To N2B (6.11.8)	
		C38	LS on CBS Functionality and Responsibility	3GPP T2	P	To N2B (6.11.9)	
		C42	LS on CBS Functionality and Responsibility	3GPP S2	P	To N2B (6.11.9)	
		C43	LS on addition of APN parameter in network requested PDP context activation procedure	3GPP S2	P	To N2B (6.3)	
		D14	Liaison Statement - Cover letter for TR21.904, Terminal Capabilities Report, interim version	T2	P	To N2A, who noted it	
5	Work item management	A65	The structure of specifcations for the GLR & Super‑Charger	N2 Chairman	P	Endorsed. In debate in N2B, we accepted that there will be no CR to 23.012 for the GLR.	
		A98	Proposal regarding the standardisation of CAMEL Phase 3	Ericsson	P	To be re-opened in Friday plenary in the light of discussions in N2A on specific contributions.	
		B43	3GPP work program Project co-ordination aspects Project  Plan for packet and circuit architecture	3GPP	P	Postponed to Friday so MCC can be briefed	
		B44	3GPP work program: Inter group co-ordination aspects  Project Plan for location services in UMTS (3G PD 30.lcs version 0.0.2)	3GPP	P	Postponed to Friday so MCC can be briefed	
		B52	Implementation of the 3GPP and SMG Specification Handling decisions	MCC	P	Franco will check who should take the responsibility for the editing task mentioned in point 5 (updating of references to point to 3G TSs). I pointed to the possible separation of management & execution of updating work. Document was noted.	
		B53	3G and SMG Specification Handling	MCC	P	Noted	
		B80	Comments on the proposal in N2-99981 for the restructuring of TSG-N2	Vodafone	P	Noted; Steffen H will re-present 981.	
		981	Splitting of CN2 SWG-A and SWG-B	T-Mobil	P	I identified 3 possible approaches: separation into 2 WGs as proposed by Steffen; maintenance of status quo; or a compromise where we have the existing formal structure but improve efficiency by reducing the amount of time spent in plenary sessions (eg by letting the chairman & SWG chairmen do the allocation to SWGs, and by speeding up the formal business. Motorola, Nokia, FT, Ericsson, favour a compromise; T-Mobil favour the split(!); Siemens are ambivalent. Decided to go for the compromise.	
		B86	GSM Release 1999 Specifications (GSM 01.01 version 0.0.1 Release 1999)	MCC	P	Christian Homann & Sumio Miyagawa raaise the concern that 23.078 v3.1.0 (transposition of GSM 03.78 v7.1.0). I put the question: do we want to recommend to TSG-N that we present 23.078 as a new spec for approval, rather than a CR against the existing 23.078 v3.1.0. We could still fiddle this by having all the new text as a block, then the old text struck out as a block – still a CR(!). Christian also proposes an executive summary of the functional differences. Sumio also raises the question of whether we need to apply corrective “mirror” CRs to 23.078.	
		B87	Release 1999 Specifications (3G TS 21.101 version 0.0.1)	MCC	P	This is the 3G mirror of GSM 01.01 (B86); noted.	
		C30	Spec allocation table	MCC	P		
		C95	LS to TSG S WG1 regarding the scope of CAMEL Phase 3	T-Mobil, Ericsson	A	Question was raised: should we move notification of change of subscriber data into the “in for R99” list? Keijo also points out that item 10 has had no contributions to it! On an issue of principle, should we have a third list of items which are doubtful – neither definitely in nor definitely out? Rogier proposes that we define the list of items we can’t do for R99 by exclusion. I dug out the fact that there has been no input on the use of Continue with Argument for CAMEL support of OR. Dan Enberg flags up the danger of defining the items to go into R2000 by saying “anything not on the yes or maybe lists is in R2000”. He wants to give S1 the opportunity to shout at us if we miss out something which is in the stage 1. Keijo also identifies that we should show  the service drivers which demand the V-T-BCSM (MSP, MT AoC, mid-call DTMF) in the “maybe” list if we put the V-T-BCSM in the “maybe” list. We should also indicate that we will give it our best shot to do the “maybe” items for R99. Revised version will be in D25.	
		D16	Freezing GPRS Release 97 & Release 98	N2B	P	Proposal is to make this an input from N2 to N plenary	
6	Release 99						
6.1	CAMEL Phase 3						
6.1.1	Current stage 2 draft	B56	Draft 03.78 for CAMEL Phase 3	Alcatel/Siemens	A	Noted as basis for further development	
		A82	Correction related to explicit disarming in gsmSSF Monitoring state	Nokia	A	Accepted for input to the draft spec	
		A83	New Connect_To_Resource procedure to gsmSSF	Nokia	A	Result=fail is missing, agreed for Draft Spec with the proposed modification	
		A84	New Establish_Temporary_Connection procedure to gsmSSF	Nokia	A	Withdrawn	
		A97	Comments on 03.78 version x.5.0	Ericsson	A	Withdrawn	
		B12	Corrections related to O_Mid_Call detection, Description of the call model (PICs) and Implicit disarming rules	Nokia	A	Accepted for input to the draft spec	
		B13	Corrections to BCSM Modelling of Call Scenarios section	Nokia	A	ICS "shall" contain called party! Christian will do the change. Accepted for input to draft spec	
		B14	Adding of the Call Segment Association process to overall SDL architecture	Nokia	A	Rejected because CPH is out of R99	
		B15	Corrections to the CAMEL_OCH/MT/CF_ETC Procedures	Nokia	A	Accepted with editorial modification "process" shall be deleted	
		C16	Introduction of Roaming CSI in CAMEL phase 3	Siemens	A	R-CSI was not accepted, new structure of section 4.3 was accepted. Revised to C71	
		C17	CAMEL architecture in 03.02	Siemens	A	Accepted, proposed LS in C73	
		C21	Proposed addition of cause parameter to Initial DP	NTT	A	Route_Select_Failure, Busy (to differentiate Not reachable) SPS3 shall be informed. Revised to D75	
		C39	Description of conditional trigger checks at TDP’s	Ericsson	A	Mapping table for release causes, removal of "analyses" at analysed info. I/W with Call Forwarding Notification. Revised to C79	
		C69	Adding of the Call Segment Association process to overall SDL architecture	Nokia	A	withdrawn	
		C71	Introduction of Roaming CSI in CAMEL phase 3	Siemens	A	Revision of C16. Accepted for inclusion in draft stage 2.	
		C75	Proposed addition of cause parameter to Initial DP	NTT	A	Revision of C21. I pointed out that the way NTT propose to indicate that the call may be forwarded is different from the way we already do it in the Event Report BCSM; however in the Initial DP we already have the GSM Forwarding Pending indicator... this is for further study. Agreed to include the cause parameter in the stage 2 & 3 drafts.
[Christian warns that there will not be a draft of the R2000 CAMEL for a while yet – the only draft will be the one covering the items agreed for R99]	
		C79	Description of conditional trigger checks at TDP’s	Ericsson	A	Revision of C39. We agreed that we need a (short!) table to define the 3 conditions on which we can discriminate: busy/not reachable/no reply for triggering criteria. These can be determined from ISUP release cause coming in, forwarding reason in RCH or SRI ack, or internally determined. Christian will use the material to update the draft stage 3	
6.1.2	Current stage 3 draft	A96	Draft 29.078 version x.2.0	Ericsson	A	Will be the basis for release 99; ICA will be R2000	
		B91	CR 29.002-040 on Addition to description of O-CSI for CAMEL Phase 3 	NEC	A	Revised to C93; Route Select Failure is not supported	
		B92	CR 09.78-A074 on Addition to description of T-DP of CAMEL Phase 3	NEC	A	Withdrawn; superseded by C67 (Hiroshi)	
		C19	Clarification of Object Identifier for CAP TC-U-Abort reason	NTT	A	Accepted for stage 3	
		C67	Addition to description of T-DPs of CAMEL Phase3	NEC	A	Note is requested on usage of the EDPs and TDPs. Release 2000; noted	
		C93	CR 29.002-040r1 on Addition to description of O-CSI for CAMEL Phase 3 	NEC	A	Revision of B91; approved in N2A. Identified that someone in N2A needs to take on responsibility for collating the CAMEL CRs to 29.002, but nobody leapt up to do it! NEC will submit it for review in N2B.	
6.1.3	MSP	A73	Implementation of MSP Phase 2 Requirements on CAMEL Phase 3	Vodafone	A	Concern over possible clash of tag values 50 onwards.
Sumio objects on behalf of Siemens to continuing with the stage 2 work until the stage 1 is stable(!). Steffen proposes that we deal with this by not incorporationg the MSP stuff into the draft CAMEL phase 3 stage 2 yet.
Nokia propose to make the hold treatment indicator etc boolean rather than octet string; however Christian wants to have some future-proofing. I propose to defer this issue until we have the detailed proposal for the stage 3.
Keijo identifies that when we have the V-T-BCSM we will need an extra column in the IF descriptions to distinguish between MT handling in the GMSC & MT handling in the VMSC. This is not a direct impact of MSP, but we’ll have to deal with it when we introduce the V-T-BCSM. However we will need other revisions because of the comments on A74.	
		A74	CR 23.018-005 on Inclusion of handling of the Service Interaction Indicators Two parameter	Vodafone	A	Christian proposes that for the MO case (OCS_MSC4) and the MT case (ICH_MSC2) we store the SII2 indicator when we receive it in the connect message from the SCF. This means that it would have to go into 23.078.	
		C00	Addition of CCBS to the SS invocation notification 	Vodafone	A	Revised to C80	
		C01	CR 29.002-041 on Addition of CCBS to the SS invocation notification	Vodafone	A	Spotted one typo in the OP definition for SS invocation notification – ref to 7.2.1 not 17.2.1. Steffen asks whether we need a CR to 23.078 for this.	
		C80	Addition of CCBS to the SS invocation notification 	Vodafone	A	Revision of C00; accepted, further development awaits approval in S1.	
6.1.4	SMS interactions	A77	CR 23.078- 019 on CAMEL3 MO SMS modifications to 23.078	Nokia	A	Activity test handling is removed, appending of FCI shall be introduced, FCI handling shall be aligned with CAMEL phase 2. Revised in C64; CR is rejected.	
		A78	CR 29.078-011 on CAMEL3 MO SMS modifications to 29.078	Nokia	A	Append for FCI is needed, References need to be updated, Accepted for the draft specification. Jan will take care of it.	
		A79	CR 29.002-038 on CAMEL3 MO SMS modifications to 29.002	Nokia	A B	N2B view is generally favourable; however we believe that the text in the affected chapter should be (intelligently!) pruned to remove duplication. Nik points out that the SMS-CSI parameter in the service definition should refer to section 7.6, and the user error & provider error should stay at the end of the parameter list. Keijo already has a document number for a revised version.	
		A85	Short Message Submission Handling	Sonera	A	Noted, Sonera will reintroduce the doc after the SA1 decision.	
		A86	IE description in Connect SMS IF	Sonera	A	Accepted, Sumio will incorporate it in the draft Spec	
		B50	Proposed LS on MO SMS triggering in CAMEL phase 3	MoU-SERG	A	Stage 1 needs to be updated, LS is noted	
		C65	CR 23.078- 019r1 on CAMEL3 MO SMS modifications to 23.078	Nokia	A	revision of A77	
6.1.5	SoLSA interactions	A80	CR 23.078-020 on CAMEL3 introduction of SoLSA interworking	Nokia	A	IDP description of LSA ID shall be revised, IE for initial SMS event need to be qualified whether used for GSM or GPRS or both? Is SOLSA a 3G spec? The function will be part of R99.	
		A81	CR 29.078-012 on CAMEL3 introduction of SoLSA interworking	Nokia	A	Withdrawn	
6.1.6	GPRS interactions	A87	SDL descriptions of the CAMEL/GPRS procedures	Ericsson	A	Signal names shall be shown in the system diagram, editors shall decide. Two DP "change of position"; accepted for draft spec	
		A88	New operation SendGPRSChargingInformation	Ericsson	A	Accepted	
		A89	Modifications to the CAMEL/GPRS interworking	Ericsson	A	Conditions shall be described. Tariff Switch interval is optional. Accepted for the Draft spec.	
		A90	New operation ConnectGPRS	Ericsson	A	PDP ID will be "C". Accepted	
		A91	ASN.1 definitions for the CAMEL/GPRS interworking	Ericsson	A	Some optional indications are missing, cause values are GPRS specific, upper limit of maxelapsedtime? local value for unknownPDPID needs to checked, renaming of event report operations, Requirement for charging of number of packets? Accepted.	
		A92	Detailed procedure descriptions for the CAMEL/GPRS interworking	Ericsson	A	No specific activity test operation, Accepted	
		A93	Physical architecture for the CAMEL/GPRS interworking	Ericsson	A	IP will be replaced by SRP, Accepted	
		A94	09.78 definitions of SendGPRSChargingInformation	Ericsson	A	Is AoC supported for GPRS, shall the same handling be applied as for Circuit switched AOC? Accepted	
		A95	09.78 definitions of ConnectGPRS	Ericsson	A	PDPID needs to described further, proposal is accepted, however PDPID will be discussed at the next meeting.	
		C15	Renaming of a detection point in GPRS interworking	Siemens	A	Accepted	
6.1.7	Mobility management	A99	Marking of Mobility Management events (03.78)	Ericsson	A	Accepted for the draft specification, editorials shall be discussed with the editors	
		B00	Mobility Management in CAMEL Phase 3 (29.002)	Ericsson	A B	Network-initiated explicit detach? Rogier N will check. Rename operation to ReportMM-Event; ripple into other definitions. Data type for MM-Code should be OCTET STRING rather than INTEGER. Define the code points in the MM-Code rather than in the places where the data type is used. Other comments from Teemu. Revised version will be produced to take on these comments and include the SDL diagrams. SDL diagrams will be confined to the protocol level.	
		C05	Proposed improvement of Mobility Management implementation for CAMEL phase 3	Ericsson	A	Concept is agreed	
		C06	'Mobility Management' Contribution for 03.08 for CAMEL Phase 3	Ericsson	A	Accepted with editorial changes for the 03.08 draft spec	
		C07	'Mobility Management' Contribution for 03.16 for CAMEL Phase 3	Ericsson	A	Accepted for the 03.16 draft spec	
6.1.8	Location services	B01	ASN.1 definitions of Location Services (09.02)	Ericsson	A		
		B20	Active location retreival for CAMEL phase 3	France Telecom	A	Proposal accepted, LS in C91. candidate for R2000	
6.1.9	Call Party Handling	A98	Proposal regarding the standardisation of CAMEL Phase 3	Ericsson	P	Proposes radical reduction of scope of CAMEL phase 3, including removal of CPH, V-T-BCSM & Any Time modification of subscriber data, and putting them into a later phase. Jan also floats the idea of separating CAMEL into a GPRS control part and a “classical circuit switched” part (presumably with the GPRS control part being in R99 and the difficult CS part in R2000). Noel supports the principle of the split. I flagged up the fact that other services (e.g. MSP) rely on certain components of the CAMEL package, so if we delay those components we also delay the services which depend on them. We also have to remember that any proposal for a major reduction of scope will lead to extensive debate in higher level committees.
It seems we have two possible approaches for a split: stable vs unstable (regardless of what sort of basic service, ie packet vs circuit) or packet vs circuit (which then begs the question of whether we need to split each of those into stable vs unstable).
Keijo reckons that the SMS, GPRS and mobility management parts would be safe to include in R99; it’s the call-related enhancements which are doubtful. He admits that there are some “small features” in the call-related enhancements which could be included in R99, but wants to avoid an argument over which of those should be in and which should be out. Christian says he would have to oppose any rescoping of CAMEL phase 3 in N2. I warned that we should expect difficulty if we simply offer a choice between the whole lot late (when?) and our proposal for a reasonable package to be delivered at the end of R99.
First question; do we offer SA a choice between a cut down R99 and waiting until R2000 for the whole lot? We agree that we offer a phased release. Moving to the discussion on the contents of the phases, I put in the plug for the V-T-BCSM being in R99; this was accepted subject to Vodafone providing the necessary inputs, after Keijo indicated that there’s still a lot of work to be done on it (e.g. message contents, data stored in location registers (23.008), subs data handling (23.016), MAP syntax for new CSI, interactions with SS, CAP syntax,..). NTT Commware ask for us to decide on whether to put in any time interrogation/modification when we've seen their contributions (agenda item 6.1.11). Christian asks for CPH! This triggers concern that we’ll be putting almost everything back into R99.
I proposed that we should defer the decision on our recommendation for R99 until after the contributions on specific topics have been reviewed; this was accepted.	
		B03	Redefinitions of CAMEL Phase 3 CSCV states - Procedure parts	Ericsson	A	Postponed	
		B04	Redefinitions of CAMEL Phase 3 CSCV states - Mapping DPs/signalling	Ericsson	A	Postponed	
		B10	CAMEL Phase3 Call Party Handling discussion	Nokia	A	Lists many areas where we need to do more work on developing the specs for CPH. Implication is that we will not be able to resolve these in time for R99! Ericsson support. Frans Haerens raises the question of how we can verify the accuracy of our model, because we can’t feed our stage 2 SDLs into a simulation! Concluded that we won’t be able to put even a sensible subset of CPH into R99. Keijo also points out that we ought to decide whether we want to put full-blown CS-2 CPH onto R2000 or use a subset!	
		C22	Comments on CPH capability restriction	NTT	A	Postponed	
6.1.10	Congestion control	B21	Congestion control at the gsmSCF	France Telecom	A	For Release 2000	
6.1.11	SAT/MExE interactions	B55	Liaison Statement on SAT/MExE <-> CAMEL Interworking / Traceability	3GPP N1	A	Noted; for Release 2000	
6.1.12	Control/interrogation of subscriber data	B73	Working Assumptions of “Notify to CSE of Change of Subscriber Data”, “Any Time Interrogation” and “Any Time Modification”.	NTT Commware	A	Withdrawn; superseded by B93	
		B93	Working assumptions on any time interrogation/modification and notify subscriber data change	NTT Commware	A	Shall the HLR shall send PSI if supported CAMEL Phases is requested? CAMEL Phases are interrogated! Means for setting the CSI active or not active is needed. Second T-CSI needs to be added. USSD CSI in ATI? Activation/Dactivation and Register and Erase will be supported. N-CSI is not a CAMEL Feature. different messages for ATI subscriber data and Location. No Interrogation of CAMEL phases in VLR. CSI activation on TDP Level. The SCF requesting a notification will not be notified. Revised to C87	
		B94	Information elements of any time interrogation/modification and notify subscriber data change	NTT Commware	A	A complete CSI may be downloaded, U-CSI shall not be contained in IF. Noted	
		B95	CR on 03.78 draft ver dx.5.1 (related to any time interrogation/modification and notify subscriber data change)	NTT Commware	A	Alignment with the decisions on Doc B93. Revised to C89. SS ad hoc may be informed.	
		C87	Working assumptions on any time interrogation/modification and notify subscriber data change	NTT Commware	A	Revision of B93. Concluded that notification of change of subscription info for CSI shall be to a resolution of CSI (not finer). Rogier asks how we treat insertion and deletion of CSI. Notification of deletion is governed by the flag stored as part of the CSI before deletion; notification of insertion has to be controlled by a default notification flag. Rogier then raises the question of whether we have to notify all the SCFs listed in a CSI if one part of the CSI changes... We shall need to do some radical simplification if we are to have something we could put in R99! Keijo asks whether we can modify data to a resolution of TDP or to a resolution of a complete CSI; he recommends that the CSI is the atomic data item. However Steffen points out that we have a requirement that the CSI can’t be overwritten; we can only activate/deactivate the CSI. It seems we have no proper service requirement for this feature! Decided to accept the limitation of only activation/deactivation at the CSI level. Agreed that we should handle activation and deactivation of O-CSI by inserting/deleting subscriber data towards the VLR, to avoid having to change the subscriber data management procedures in the VLR. I proposed that we should have a clean revised version of this doc – D19 for distribution next week	
		C89	CR on 03.78 draft ver dx.5.1 (related to any time interrogation/modification and notify subscriber data change)	NTT Commware	A	Revision of B95; needs to be changed to reflect the decision that notification of change of data is per CSI, not per DP. Further, we need to wait until the result of the email discussion before we incorporate this into the draft stage 2. Keijo also identifies that we shouldn’t show the possibility to change U-CSI	
6.1.13	V-T-BCSM	B82	Draft SDLs to introduce the V-T-BCSM into TS 23.018	Vodafone	A	See mark-ups on paper copy. Also, do we need to put in a health warning about the values of the CW acceptance timer and the default CAMEL TNRy? We think it’s covered in the stage 1.
On ICH_MSC4, we should remove the notification of CF for the case of successful ORLCF.
On ICH_MSC7, the Release to the GMSC comes after the call on MT_GMSC_DISC4.
I also raised the question of whether we should invoke CAMEL handling for busy if the user UDUBs the call (e.g. see CCI_MSC5). Keijo thinks we should.
Another point: if TNRy or the NRCT expires, we should call CAMEL_MT_GMSC_DISC5 to have the possibility of invoking CAMEL based 
Accepted that we continue to work on the assumption that the V-T-BCSM is in R99.	
6.2	Combined mobility management	C28	Combined Update Location	NTT Commware	B	Proposes to adopt a modelling where the UMSC uses a distinct operation in a distinct AC for combined location update. Do we model this as separate logical UMSC, SGSN and MSC/VLR in the physical entity? What do we do on protocol fallback? Ulrich asks what AC the HLR sends back if it can’t accept the dialogue for combined location update: CS location update or PS location update? H-P Keutmann points out that this issue is also being handled in S2; we should wait for input from them. However because of the time lag we will probably not get the LS until it’s too late to deal with it here. The LS arrived on Thursday (see D20).	
		D20	Liaison statement on Combined MAP operations	S2	B	Several of the questions raised in this LS have been addressed in C28. However I (supported by Npkia and Ericsson) expressed concern that we can’t expect to complete the work without the equivalent work on the access signalling; we cannot guarantee that the work will be complete in R99. NTT DoCoMo reckon that the access signalling work has already been done – see the combined MM procedures for GPRS. However Yun-Chao points out that what we have in GPRS is a bodge which uses the Gs interface to let a GPRS RAU procedure trigger an LAU procedure in the VLR. We will reply to S2 (and N1) to say that we have worked on combined MM, but there is still more work to be done; we are not confident that the necessary work will be limited to the scope of N2, and we cannot guarantee that the work will be complete in December 1999.	
		D22	Proposed LS to S2 & N1 on combined mobility management	Vodafone	B	Revised to D32, which was approved.	
6.3	GPRS	B69	Liaison Statement on the handling of 03.60	3GPP S2	P	This means that S2/SMG12 keep their hands on 23.060 even though is has a lot of detailed stage 2 material in it. Noted.	
		B74	GTP-U DATA SAP	Lucent Technologies	B	Proposes a definition of the data SAP (response to Yun-Chao’s prompt from B75!).	
		B75	GTP-U SAPs	Lucent Technologies	B	Proposes to standardise only the data & control SAPs, leaving the management SAP for local definition. Principle was agreed; Yun-Chao prompts for inputs!	
		B76	GTP header	Lucent Technologies	B	Proposes restructuring of the GTP header to allow the transfer of optional/system-specific information. Ericsson ask for postponement; agreed to do so provided that there is an active email discussion in which Ericsson take part, so we can resolve the question no later than the November N2 meeting.	
		B85	CR 29.060-012 on An evolved and new GTP version for Release'99	Ericsson	B	To be revised for next meeting.	
		B89	CR 29.060-013 on Addition of APN parameter to PDU Notification Request	NTT DoCoMo	B	I proposed (& it was accepted) a repositioning of the new para in 7.9.23, & rewording to indicate that the APN is sent in the NI context activation procedure. I also proposed a clean-up to the additional text in 7.5.12. Revised CR in C74. Also needs to be checked whether the sections afffected are the same in v3.1.0	
		C43	LS on addition of APN parameter in network requested PDP context activation procedure	3GPP S2	B	Proposes stage 2 change which would lead to changes in both access signalling (N1) and GTP (us). On the proposal to change R97 and R98, we definitely oppose the R97, and Teemu indicates that N1 would also resist the change to R98; he proposes we also resist. Decided to escalate the issue of principle of accepting changes to R98 and have a discussion in TSG-N plenary. However we will also consider the principle of how we treat changes to R98 GPRS when we discuss C56. Sawada San will draft the response LS in C72. The CR to 29.060 is in B89.	
		C72	Proposed liaison statement to S2 on addition of APN parameter in Network-requested PDP context activation procedure	NTT DoCoMo	B	Will be revised to make the last paragraph read “until CN plenary decides whether to endorse the proposal to freeze R97 & R98”. Revised version in D28, which was approved.	
		C74	CR 29.060-013r1 on Addition of APN parameter to PDU Notification Request	NTT DoCoMo	B	Agreed in N2B	
6.4	IST for non-CAMEL subscribers						
6.5	Multicall	B41	CR 23.018-003r1 on Addition of the description for Multicall	NTT Commware	B	Agreed that this is a good start, but further development is needed. I raised the question of whether there is a stable stage 1 requirement (stage 1 is currently at v1.0.0). I will flag up to CN plenary that we can’t make much more progress until we have a proper service requirement.	
		B54	Liaison Statement on multicall and enhancement of call barring services	3GPP N1	B	IDCP to write a response (C82) saying that until we have a clear service requirement we won’t know whether enhanced barring is the best way to solve the problem. Send to N1 & S1.	
		C82	Proposed liaison statement to N1 and S1 on multicall and enhancement of call barring services	Vodafone	B	Approved by N2B	
6.6	Multimedia calls						
6.7	Out-of-band transcoder control	C35	Response to the N2 Request to Maintain Codec Type and configuration	3GPP S4	B		
		C36	LS on Tandem Free Operation, Transcoder Free Operation, DTMF Signalling	3GPP S4	B		
		C84	Out-of-band transcoder control: stage 2, v0.0.1	Ericsson	B		
		D00	Proposed LS to S4 on codec list management	Ericsson	B	Approved by N2B	
6.8	Pre-paging	B42	CR 23.018-002r3 on Addition of the description for Pre-Paging	NTC/Vodafone	B	Agreed subject to resolution of query from J-A Evenou: in the handling for busy subscriber outcome from paging we need to set the variable Fatal PAR error to False. Also neet to add references in text to initialising the PAR state variables on sheet 7, and to rename the procedure call in Prepage_MSC to Prepaging_Page_MS_MSC. Revised to C94	
		B57	CR 29.002-027r2 on Addition of the information elements and the ASN.1 definitions for Pre-paging	NTC	B	Agreed in N2B; for approval Friday	
		C94	CR 23.018-002r4 on Addition of the description for Pre-Paging	NTC/Vodafone	B	Approved in N2B	
6.9	Security issues	B47	LS to TSG N WG2 regarding changes to GSM 09.02 to clarify triplet re-use conditions	SMG10	B	We propose “instance” is replaced by “case”; also clarify that badly formatted request will allow re-use. IDCP to write response (C86)	
		B66	Answer to the liaison on Enhanced User Identity Confidentiality	3GPP S2	B	Copy to us for info. Noted	
		B67	Answer to the liaison on Evolution to UMTS and R99 Security Features	3GPP S2	B	Copy to us for info. Noted	
		B68	Answer to the liaison on the time constraints on the execution of cryptographic algorithms	3GPP S2	B	Copy to us for info. Noted	
		B72	Security interoperation between UMTS and GSM	3GPP S2	B	This is really a response to our LS on security issues related to the Super-Charger. They have drafted a CR to 33.102 to allow authentication sets to be used out of sequence (within limits). They also want to ensure that there’s a possibility for the new VLR to retrieve the IMSI (only) from the old VLR, as well as the new VLR asking for the IMSI & authentication sets. Ulrich suggests that we could add an extra option, to allow the old VLR to send some (but not all) of its authentication sets to the new VLR. This proposal was accepted; will go into the supercharger stage 2.	
		C03	CR 29.002 on Authentication Enhancements	Siemens	B	This is an advance copy for early information; Ulrich indicates that it will be subject to change because of the transfer of information from 29.002 to 23.012. Luis asks for postponement to tomorrow to allow time for consultation back home. Postponed.	
		C86	Proposed liaison statement to SMG10 on changes to GSM 09.02 to clarify triplet re-use conditions	Vodafone	B	Approved by N2B	
6.10	Signalling reduction techniques						
6.10.1	The GLR	B88	GLR stage 2 specificaton v.0.0.2	NTT DoCoMo	B	Ahti Muhonen points to the fact that references to the location services specs should use the UMTS numbers, not GSM 03.71. Ulrich raises the question of not being able to send a Purge MS error if the dialogue is at MAP v2 (does this really belong in a stage 2?); also, the conditions for sending the purge MS message to the HLR are more complex than stated here; if the purge message comes from a VLR which isn’t the one where the GLR thinks the sub is, the GLR returns an error to the VLR and doesn’t forward the message to the HLR. The whole MS purge section needs to be revised to reflect this! Further specific comments to the author.	
		B90	The HLR restoration procedure involving the GLR	Fujitsu	B	Combination of tools 1 & 2 (i.e. the VLR uses both HLR-ID list and HLR number to determine which subscribers are affected by an HLR reset) is opposed by Nokia et al because it would mean changes to the VLR. Otherwise the contribution is acceptable – the stage 2 will be updated with this material (intelligently imported!!).	
		C29	Draft GLR stage3 specification	NTT Commware	B	Noted that AC versions older than the current one will also need to be supported. I proposed to split it into two parts, one for MAP and another for GTP. Support from various quarters. I also asked for it to be more of a delta document and not import stuff from 29.002. Noted as the basis for further development.	
6.10.2	The Supercharger	A66	Super-Charger Technical Realisation; Stage 2	Nortel Networks	B	Various detailed comments. Noted as basis for further development.	
		A67	CR 23.018-004 on Introduction of the Super-Charger Concept in TS 23.018	Nortel Networks	B	Nik reported misalignment between text and SDL; this will lead to need for a revised version.	
		A68	CR 29.002-033r1 on Introduction of the Super-Charger Concept in TS 29.002	Nortel Networks	B	Several specific comments; we identified the need to extend the SendIdentification operation to allow the VLR to ask for IMSI alone, authentication sets alone, or both.	
		B05	CR 23-016-004r3 on Introduction of the Super-Charger Concept in TS 23.016	Nortel Networks	B	Updated to reflect the lack of structure of age information; approved, on hold in N2B.	
		B06	CR 23-008-003r1 on Introduction of the Super-Charger Concept in TS 23.008	Nortel Networks	B	Updated to reflect the lack of structure of age information; approved, on hold in N2B, subject to correction of “data is”.	
		C68	TMSI Re-allocation within a Super Charged Network	Ericsson	B	Replaced by C96	
		C70	SMS within a super charged networks	Ericsson	B	Replaced by C98	
		C96	TMSI Re-allocation within a Super Charged Network	Ericsson	B	Revision of C68. Proposes to release TMSI & P-TMSI after a period of lack of radio contact (similar principle to implicit detach); this requires the timer value to be broadcast on the BCCH. I pointed out that the use of BCCH capacity may be a sensitive issue in N1; we need to raise it with them. J-A Evenou asks whether this feature will be mandatory for all VLRs/SGSNs which support supercharger; Yun-Chao says it should be. The alternative to having the timer values broadcast is to have a standardised value, because the MS needs to know the shelf life of the TMSI. This also means that we can use only new (UMTS) mobiles on a super-charged network. Email discussion (with cutoff date of 10 October) to decide whether the approach is acceptable to N2; we also need to consult N1!!	
		C98	SMS within a super charged networks	Ericsson	B	Revision of C70. Proposes to allow the MS purged diagnostic to be sent as a diagnostic for AbsentSubscriberSM and recorded in the HLR. Nik points out that this will have an impact on 23.040, which is where the code points for the AbsentSubscriberSM diagnostic are defined.	
6.11	Other Release 99						
6.11.1	Location services	A72	CR 29.002-037 on Change of reference for geographical area description	Vodafone	P		
		B46	Combined Architecture for LCS Phase 2	T1P1.5	P		
		C91	Proposed LS to N1 on Active Location Retrieval in CAMEL Phase 3	France Télécom	A	Revised to reflect additional parameter in MAP messages, plus impact on MSC/VLR functionality. Revised version in D23.	
6.11.2	Subsystem numbers	B59	Liaison Statement to CN WG2 on the allocation of an SSN for RNSAP	3GPP R3	P	Noted; the CR in C23 is to meet the request.	
		C02	CR 23.003 A001r1 on SSN for RANAP	Siemens	B	Withdrawn; superseded by C23	
		C23	CR 23.003-008 on SSN allocation for RANAP,RNSAP	NEC	B	Needs base version on cover sheet changed to 3.1.3; otherwise approved.	
6.11.3	Lower layer protocols	B09	CR 29.002-A032r1 on Introduction of White Book SCCP in MAP	Nortel Networks	B	Nik Allen identifies that the term “White Book SCCP” needs further clarification: is it the 1993 version or the 1996 version? Agreed to replace “GMT” with “UTC”, and “GSM specifications” with “GSM and UMTS network operators”. Ulrich asks for clarification of the dropback mechanism, but Nik and I reckon it’s a matter of judgment for the network operator/implementer what dropback mechanism is used. Ulrich argues that if we have a dropback mechanism there’s no point in mandating the use of white book SCCP; Yun-Chao responds that the date means that GSM network operators have a driver to upgrade their nodes. Luis reckons that by having to provide a dropback mechanism we lose the advantage in specification & implementation, but I pointed out that we still get the runtime advantage of reduced messaging by using segmentation. Jean-Alain proposes to tie the use of white book SCCP to a new MAP application context, but Nik opposes; Ulrich supports the proposal for a link between SCCP white book and a raised AC version. Noel Crespi (supported by Ulrich) asks for a definition of the dropback mechanism if we don’t have the use of SCCP linked to AC version. Ericsson and Nokia and I opposed the linkage of white book SCCP to AC version. Yun-Chao puts the conclusion that the meeting agrees not to link the SCCP colour to the AC version, but Jean-Alain records his opposition to this conclusion. I suggest we could put in an example dropback mechanism. I will report to the October TSG-N that we’re studying the introduction of white book SCCP. J-A Evenou recommends that we send a liaison to SPAN1 to consult with them about the cutover date; he will draft it (D18). Ericsson, Alcatel & FT reckon they want a normative solution to dropback. Postponed to an email discussion with the aim of getting resolution by the October N2 meeting.	
		C04	SCCP level segmentation for MAP messages	Ericsson	B		
		D18	Proposed LS to SPAN1 on use of White Book SCCP to support MAP	Alcatel	B	Revised to D30	
6.11.4	CRs corresponding to corrections on earlier releases	A19	CR 29.002-028 on Clarification on registration of a default priority level higher than the maximum entitled one	Ericsson	B	Mirror of A17; agreed	
		A71	CR 23.078-019 on Inclusion of the SS Invocation Notification procedure	Vodafone	A	Corresponds to R97 and R98 CRs already agreed in N2. Formally agreed in N2A	
		B24	CR to 23.018 n. 005 v 3.0.0 on Removal of TDP-Criteria from RCH	Siemens	A	Mirror of B22; approved in N2A	
		B27	CR to 23.078 v 3.0.0 n. 021 on Removal of TDP-Criteria from RCH	Siemens	A	Mirror of B25; approved in N2A	
		B30	CR to 23.079 v 3.0.0 n. 003 on Removal of TDP-Criteria from RCH	Siemens	A	Mirror of B28; approved in N2A	
		B33	CR to 23.018 v 3.0.0 n. 007 on GMSC CAMEL Phases in PRN	Siemens	A	Mirror of B31; revised to D09 which was agreed.	
		B36	CR to 23.078 v 3.0.0 n. 022 on GMSC CAMEL Phases in PRN	Siemens	A	Mirror of B34; revised to D13, which was agreed	
		B39	CR to 23.079 v 3.0.0 n. 004 on GMSC CAMEL Phases in PRN	Siemens	A	Withdrawn	
		B62	CR 23.018-023 on Separation of success & failure cases for OR of late call forwarding	Vodafone	B	Mirror of B60; agreed	
		B63	CR 23.079-005 on Separation of success & failure cases for OR of late call forwarding	Vodafone	B	Mirror of B61; revised to C60	
		B83	CR 23.078- 023 on Call Reference Number	Siemens	A	Mirror of B19; revised to C49	
		B99	CR 23.003-007 on ASCII coding of <MNC> and <MCC> in APN OI	Alcatel	B	Mirror of B97; revised to C54	
		C14	CR 23.078-024 v 3.1.0 on Change procedure CAMEL_MT_GMSC_INIT in case of no absent subscriber	Siemens	A	Mirror of C12; rejected, candidate for inclusion in CAMEL phase 3 stage 2	
		C27	CR 29.002-042   on clarification on supported CAMEL phases in ISD ack	Siemens	B	Mirror of C24; agreed by N2B	
		C33	CR 29.002-043 on Addition of exception handling to the CancellationType	Nokia	B	Mirror of C31; revised to D06.	
		C44	CR 23.072-??? on Separation of success & failure cases for OR of late call forwarding	T-Mobil	B	Mirror of C46; For information; will be handled in the SS ad hoc. Noted	
		C49	CR 23.078- 023r1 on Call Reference Number	Siemens	A	Mirror of C47; revision of B83; approved in N2A	
		C63	CR 23.078-A??? on Corrections of process gsmSSF SDL	NTT	A	Mirror of C59; approved in N2A	
		C78	CR 29.002-044 on Editing error correction on VLR capabilities	Siemens	B	Mirror of C76; agreed in N2B	
		D03	CR 23.079-??? on Notification of CF to gsmSCF before activation of  CF Process (Release 99)	Alcatel	A	Mirror of C83; agreed in N2A	
		D05	CR 23.018-??? on Notification of CF to gsmSCF before activation of  CF Process (Release 99)	Alcatel	A	Mirror of C10; agreed in N2A	
		D06	CR 29.002-043r1 on Addition of exception handling to the CancellationType	Nokia	B	Mirror of D02; revision of C33. Agreed by N2B	
		D19	CR 23.078-??? on Value of Call Active parameter in ACR operation – clarifications in the SDL	Ericsson	A	Mirror of C55; agreed by N2A.	
6.11.5	Domain identifiers	B58	Answer to Liaison Statement from CN WG2 on CN Domain Identifiers used over the Iu & Iur interfaces	3GPP R3	B	R3 have done what we asked them; noted.	
		B71	CN Domain Identifiers used over the Iu & Iur Interfaces	3GPP S2	B	This is the one to which R3 refer in B58; noted	
6.11.6	Delay budget	B64	LS answer to Overall Delay Budget within the Access Stratum Results and Requirements	3GPP S2	B	Concluded that manufacturers would want not to release this information – it’s commercially sensitive. Yun-Chao will draft a response (C88)	
		C88	Proposed LS to S2 on delay budget	Ericsson	B	Approved by N2B	
6.11.7	QoS	C18	3G TR 23.907: QoS Concept and Architecture	3GPP S2	B	We are asked to review and provide comments to S2 in time for their QoS ad hoc on 16 Sep 1999 We should look at sections 4, 6.1.1, 6.3, 6.4.1, 6.4.2, 8, 10, Annex A as homework for discussion first thing tomorrow. Question: what is a “gateway node”? Question: how does residual bit error rate affect the network? Yun-Chao comments that the report seems to be directed mainly towards the radio access network, with very little about the core network. He will write to S2 (D10)	
		D10	Proposed LS to S2 on TR 23.907	Ericsson	B	Approved by N2B with editorial amendments.	
6.11.8	Synchronisation	C37	LS about Synchronisation	3GPP T2	B	Asks whether we’re doing anything on synchronisation. We aren’t – I will say so (C90)	
		C90	Proposed LS to T2 on synchronisation	Vodafone	B	Approved by N2B	
6.11.9	CBS	C38	LS on CBS Functionality and Responsibility	3GPP T2	B	Not our baby – noted.	
		C42	LS on CBS Functionality and Responsibility	3GPP S2	B	This was the trigger for the LS in C38. S2 propose the possibility of having a routeing node between the cell broadcast centre and the application node (i.e. RNC). Would involve us. Nick Alfano suggests that since cell broadcast is unidirectional we could use UDP as the protocol which runs on IP, but Yun-Chao points out that we may need to use TCP for other purposes. Yun-Chao voices the concern that if we have to do any specification work for R99 it’s too late! Yun-Chao fingered Nick Alfano to write the response (C92)	
		C92	Proposed LS to S2 on CBS Functionality and Responsibility	Motorola	B		
6.11.10	VHE/OSA	D12	Liaison statement on VHE/OSA	S2	A B	Noted in N2B; it’s really for N2A
In N2A, we reckoned that the proposed LS on the phasing of CAMEL phase 3 would answer the first part of the question; we could do with reminding S2 that we have had no response to our request for clarification of the role of the liaison/contact persons. Reply is in C97.	
6.11.11	Terminal capabilities	D14	Liaison Statement - Cover letter for TR21.904, Terminal Capabilities Report, interim version	T2	A	Noted	
7	GSM phase 2+ (R98)						
7.1	CAMEL Phase 2						
7.1.1	Stage 2	B19	CR to 03.78-A133 on Call Reference Number	Siemens	A	Mirror of B18; revised to C47.	
		B23	CR to 03.18 n. A051 v 7.1.0 on Removal of TDP-Criteria from RCH	Siemens	A	Mirror of B22; approved in N2A	
		B26	CR to 03.78 v 7.1.0 n. A134 on Removal of TDP-Criteria from RCH	Siemens	A	Mirror of B25; approved in N2A	
		B29	CR to 03.79 v 7.1.0 n. A015 on Removal of TDP-Criteria from RCH	Siemens	A	Mirror of B28; approved in N2A	
		B32	CR to 03.18 v 7.1.0 n. A053 on GMSC CAMEL Phases in PRN	Siemens	A	Mirror of B31; revised to D07	
		B35	CR to 03.78 v 7.1.0 n. A137 on GMSC CAMEL Phases in PRN	Siemens	A	Mirror of B34; revised to D11	
		B38	CR to 03.79 v 7.1.0 n. A017 on GMSC CAMEL Phases in PRN	Siemens	A	Withdrawn	
		C08	CR 03.18-A055 on Notification of CF to gsmSCF before activation of  CF Process (Release 98)	Alcatel	A	Mirror of C10; approved in N2A	
		C09	CR 03.79-A021 on Notification of CF to gsmSCF before activation of CF process (Release 98)	Alcatel	A	Mirror of C11; revised to C77	
		C13	CR 03.78-A140 v 7.1.0 on Change procedure CAMEL_MT_GMSC_INIT in case of no absent subscriber	Siemens	A	Mirror of C12	
		C47	CR to 03.78-A133r1 on Call Reference Number	Siemens	A	Mirror of C45; revision of B19; approved in N2A. Equivalent R99 CR is in C49	
		C61	CR 03.78-A??? on Corrections of process gsmSSF SDL	NTT	A	Mirror of C59; approved in N2A	
		C77	CR 03.79-A021r1 on Notification of CF to gsmSCF before activation of CF process (Release 98)	Alcatel	A	Mirror of C83; revision of C09; approved in N2A	
		D17	CR 03.78-A??? on Value of Call Active parameter in ACR operation – clarifications in the SDL	Ericsson	A	Mirror of C55; agreed by N2A.	
7.1.2	Stage 3	C26	CR 09.02-268 R98 on clarification on supported CAMEL phases in ISD ack	Siemens	B	Mirror of C24; agreed by N2B	
7.2	GPRS	B08	CR 09.60-A072 (R98) on Specification of the MSISDN Information Element in GSM 09.60	Nortel Networks	B	Mirror of B07. Approved; to Friday plenary	
		B77	CR 09.02-A257r1 (R98) on making the QoS IE variable length	Vodafone	B	Teemu is also opposed to the R98 changes because the QoS enhancement WI is Release 99. He also doesn’t like a MAP protocol upgrade for R98. Nick Alfano also thinks that R98 is too soon. Stefan Toth, Teemu & Nick Alfano all reckon we should wait for the result of the QoS ad hoc before we decide on the details of the protocol upgrade. CR withdrawn	
		B78	CR 09.60-A071r1 (R98) on making the QoS IE variable length	Vodafone	B	CR withdrawn (see B77)	
		B98	CR 03.03-A032 on ASCII coding of <MNC> and <MCC> in APN OI	Alcatel	B	Mirror of B97; revised to C52	
		C32	CR 09.02-A270 on Addition of exception handling to the CancellationType (R98)	Nokia	B	Mirror of C31; revised to D04.	
		D04	CR 09.02-A270 on Addition of exception handling to the CancellationType (R98)	Nokia	B	Mirror of D02; revision of C32. Agreed in N2B	
7.3	Location services						
7.4	MNP	A29	CR 03.66-A008 on Correction on Routeing Number in SRIack for Not Known to be ported numbers	Ericsson	B	Corrects misalignment of text and SDL by correcting the text. Jean-Alain Evenou says that if we have the routeing number mandatory we need an entry in the database for every ported number. Rejected in favour of A69	
		A69	CR 03.66-A009 on Clarification of NPLR functionality in not known to be ported case	Nokia	B	Corrects misalignment of text and SDL by correcting the SDL; Teemu says that there is less impact on implementation because routeing number ia already optional. Nik Allen aske whether it’s an operator option or a vendor option to omit the routeing number. Agreed, but later revised to D08	
		D08	CR 03.66-A009r1 on Clarification of NPLR functionality in not known to be ported case	Nokia	B	Improves the English in one section, and removes an unnecessary change in another section. Approved by N2B; to plenary	
		A70	CR 09.02-A264 on Clarification of returning the MSISDN in SRIack	Nokia	B	This is the companion CR to A69. Agreed.	
7.5	Optimal Routeing	B60	CR 03.18-A054 on Separation of success & failure cases for OR of late call forwarding	Vodafone	B	Agreed	
		B61	CR 03.79-A020 on Separation of success & failure cases for OR of late call forwarding	Vodafone	B	Revised to C58	
		C46	CR 03.72-A??? on Separation of success & failure cases for OR of late call forwarding	T-Mobil	B	For information; will be handled in the SS ad hoc. Noted	
7.6	Other Release 98						
7.6.1	eMLPP	A18	CR 09.02-A263 on Clarification on registration of a default priority level higher than the maximum entitled one (R98)	Ericsson	B	Mirror of A17. Agreed	
7.6.2	Harmonization	B45	Harmonization CR for GSM 09.02 (Redirecting Presentation)	T1P1.5	B	CR to put the redirecting presentation in the first octet of forwarding options. Ulrich points out that the latest version of 09.02 (v7.1.0) has dealt with most of the problem; there remains the editorial clarification. Agreed to reduce even the editorial clarification; I will send back a liaison statement (C64).	
		C64	Proposed liaison statement to T1P1.5 on Harmonization CR for GSM 09.02 (Redirecting Presentation)	Vodafone	B	Approved; to plenary	
7.6.3	Location management	B79	CR 09.02-A265 (R98) on clarification of LR-REJECT cause corresponding to Roaming Restriction Due To Unsupported Feature	Vodafone	B	Proposes to change the mapping from RoamingRestrictionDueToUnsupportedFeature into the LR-REJECT cause so that the MS will search for another network. Accepted the principle for Release 98, but not for Release 97. Cover sheet shouldn't include reference to GSM 09.60; otherwise was agreed. To plenary for approval on Friday.	
7.6.4	SoLSA	C76	CR 09.02-A271 on Editing error correction on VLR capabilities	Siemens	B	Agreed; to plenary	
8	Any other business						
8.1	CAMEL phase 2						
8.1.1	Stage 2	A75	CR 03.78-A130 on Alignment of CAMEL2 FCI & Handling of CIR	Nokia	A	Revised to C81	
		A76	CR 03.78-A131 on Alignment of CAMEL2 FCI	Nokia	A	This is an alternative to A75; withdrawn	
		B17	CR to 03.02-A??? v 6.1.0 on CAMEL Architecture	Siemens	P	Postponed to next meeting	
		B18	CR to 03.78-A132 on Call Reference Number	Siemens	A	Revised to C45	
		B22	CR to 03.18 n. A050 on v 6.4.0 on Removal of TDP-Criteria from RCH	Siemens	A	Approved in N2A	
		B25	CR to 03.78 v 6.4.0 n. A134 on Removal of TDP-Criteria from RCH	Siemens	A	Approved in N2A	
		B28	CR to 03.79 v 6.1.0 n. A014 on Removal of TDP-Criteria from RCH	Siemens	A	Approved in N2A	
		B31	CR to 03.18 v 6.4.0 n. A052 on GMSC CAMEL Phases in PRN	Siemens	A	Revised to C51	
		B34	CR to 03.78 v 6.4.0 n. A136 on GMSC CAMEL Phases in PRN	Siemens	A	Revised to C53	
		B37	CR to 03.79 v 6.1.0 n. A016 on GMSC CAMEL Phases in PRN	Siemens	A	Withdrawn	
		B40	CR 03.78-A127 on 'Handle CIR' CAMEL phase2	Alcatel	A	Superseded by C85; rejected.	
		B96	CR 03.78-A138 on Value of Call Active parameter in ACR operation – clarifications in the SDL	Ericsson	A	Revised to C55	
		C10	CR 03.18-A056 on Notification of CF to gsmSCF before activation of CF process (Release 97)	Alcatel	A	Approved in N2A	
		C11	CR 03.79-A022 on Notification of CF to gsmSCF before activation of CF process (Release97)	Alcatel	A	Revised to C83	
		C12	CR 03.78-A139 v 6.4.0 on Change procedure CAMEL_MT_GMSC_INIT in case of no absent subscriber	Siemens	A	Rejected	
		C20	CR 03.78-A141 on Corrections of process gsmSSF SDL	NTT	A	Revised to C59	
		C40	Discussion on the removal of O-CSI triggering criteria in RCH	Ericsson	A	Admitted that for R97 there’s no option to transfer the O-CSI to the GMSC in the RCH, because we don’t have segmentation.	
		C45	CR to 03.78-A132r1 on Call Reference Number	Siemens	A	Revision of B18; approved in N2A	
		C51	CR to 03.18 v 6.4.0 n. A052r1 on GMSC CAMEL Phases in PRN	Siemens	A	Revision of B31; approved in N2A	
		C53	CR to 03.78 v 6.4.0 n. A136r1 on GMSC CAMEL Phases in PRN	Siemens	A	Revision of B34; approved in N2A	
		C55	CR 03.78-A138r1 on Value of Call Active parameter in ACR operation – clarifications in the SDL	Ericsson	A	Revision of B96; some opposition, but eventually agreed to accept it with record in the report that there were some reservations. Approved in N2A	
		C57	CAMEL2 creation of O-BCSM: Clarification of behaviour in the case of Connect	Nokia	A	Christian opposes because he believes that the definition in the Connect information flow tells the story we need. I identified that we have some warts in the SDL, but this is for later! Steffen proposes that we postpone to tomorrow for study outside the meeting.	
		C59	CR 03.78-A141r1 on Corrections of process gsmSSF SDL	NTT	A	Revision of C20; approved in N2A	
		C73	Proposed Liaison to S2 (CAMEL architecture in GSM 03.02)	Siemens	A	To be sent to SMG12 as well as S2. Revised version in D21.	
		C81	CR 03.78-A130r1 on Alignment of CAMEL2 FCI & Handling of CIR	Nokia	A	Revision of A75; revised to C85	
		C83	CR 03.79-A022r1 on Notification of CF to gsmSCF before activation of CF process (Release97)	Alcatel	A	Revision of C11; approved in N2A	
		C85	CR 03.78-A130r2 on Alignment of CAMEL2 FCI & Handling of CIR	Nokia	A	Revision of C81; approved in N2A	
8.1.2	Stage 3	C25	CR 09.02-267 R97 on clarification on supported CAMEL phases in ISD ack	Siemens	B	Mirror of C24; agreed with change of category to F	
8.2	GPRS Phase 1	B07	CR 09.60-A??? (R97) on Specification of the MSISDN Information Element in GSM 09.60	Nortel Networks	B	Tidies up an error in an earlier CR which was presented in TSG-N plenary. Approved; to Friday plenary	
		B51	Liaison statement on addition of 3rd MNC digit in routing area identification	3GPP N1	B	IDCP to write an answer (C66) when Stefan Toth & H-P Keutmann have checked GSM 09.60 & GSM 09.02.	
		B97	CR 03.03-A031 on ASCII coding of <MNC> and <MCC> in APN OI	Alcatel	B	Clarifies that the <MCC> and <MNC> fields in the APN OI are always 3 digit fixed length. Revised to C50.	
		C31	CR 09.02-A269 on Addition of exception handling to the CancellationType (R97)	Nokia	B	Luis (Ericsson) proposes to map unknown values on to one of the known values, rather than discarding. Postponed to later this week to allow consultation back home. Revised to D02	
		C48	Freezing GPRS Release 97	Nokia	B	Proposes strict application of the principle that only essential corrections to GPRS R97 are allowed; exception is an improvement where all manufacturers support it. Clarified that “normal case” in C1 can be successful or unsuccessful case. Teemu (with help from Luis and me) will draft C56 to present the conclusions.	
		C56	Freezing GPRS Release 97	Nokia et al	B	Revision of C48 (presenting revised conclusions). In the light of N1 extending the scope to cover R98, Ericsson (supported by Nokia & Nortel) press for extension of the scope to R98. This was agreed; revised version in D16 will go to N2 plenary	
		C66	Proposed LS to N1 on addition of 3rd MNC digit in routing area identification	Vodafone	B	Response to B51; approved by N2B	
		D02	CR 09.02-A269r1 on Addition of exception handling to the CancellationType (R97)	Nokia	B	Revision of C31. Agreed by N2B	
8.3	Other R97, R96, GSM Phase 2, Release 2000						
8.3.1	eMLPP	A17	CR 09.02-A262 on Clarification on registration of a default priority level higher than the maximum entitled one (R97)	Ericsson	B	Agreed; to Friday plenary	
8.3.2	CAMEL control of Voice over IP	B11	CAMEL Control of VoIP Services Technical Report, Initial Draft	BT Cellnet	A	Presented by Michel Grech of Lucent. We are asked to review at home and wave under the noses of our S2 colleagues.	
8.3.3	CAMEL phase 1	B16	CR to 03.02-A??? v 5.3.0 on CAMEL Architecture	Siemens	P	Postponed to next meeting	
		C24	CR 09.02-A266 R96 on clarification on supported CAMEL phases in ISD ack	Siemens	B	Agreed with change of category to F	
8.3.4	Optimal Routeing R96	B48	CR 03.79-A018 on Handling of Release during forwarding interrogation of the HLR	Vodafone	B	Agreed by N2B	
8.3.5	Optimal Routeing R97	B49	CR 03.79-A019 on Handling of Release during forwarding interrogation of the HLR	Vodafone	B	Agreed by N2B	
9	Approval of output documents						
9.1	Liaison statements		Liaison statements agreed in N2A				
		C97	Proposed LS to S2 on OSA/VHE	T-Mobil	P		
		D21	Proposed Liaison to S2 (CAMEL architecture in GSM 03.02)	N2A	P	Revision of C73	
		D23	Proposed LS on Active Location Retrieval in CAMEL Phase 3	N2A	P	Revision of C91	
		D25	Proposed LS to S1 on scope of CAMEL phase 1	Ericsson	P	Revision of C95	
		D26	Liaison statements agreed in N2B	N2B Chairman	P		
		A54	Proposed liaison statement to SA on the use of GSM SIMs in 3G mobiles	N2B	P	Approved, will go to SA; IDCP to mail via Carole Rodriguez	
		A55	Proposed LS to SS ad hoc on changes to MAP SS signalling as a result of GLR introduction	N2B	P		
		A56	Proposed liaison statement to S2 on combined mobility management	N2B	P	Approved; will go to S2; IDCP to mail via Carole Rodriguez	
		A58	Proposed LS to N1 on the revised work item description for out-of-band transcoder control	N2B	P	Approved; will go to N1; IDCP to mail via Carole Rodriguez	
		C41	Proposed LS to S2 on further maintenance of architectural information in UMTS TS 29.002	N2B		Approved; will go to S2; IDCP to mail via Carole Rodriguez	
		C64	Proposed liaison statement to T1P1.5 on Harmonization CR for GSM 09.02 (Redirecting Presentation)	N2B	P		
		C66	Proposed LS to N1 on addition of 3rd MNC digit in routing area identification	N2B	P	Response to B51; approved by N2B	
		C82	Proposed liaison statement to N1 and S1 on multicall and enhancement of call barring services	N2B	P		
		C86	Proposed liaison statement to SMG10 on changes to GSM 09.02 to clarify triplet re-use conditions	N2B	P		
		C88	Proposed LS to S2 on delay budget	N2B	P		
		C90	Proposed LS to T2 on synchronisation	N2B	P		
		C92	Proposed LS to S2 on CBS Functionality and Responsibility	N2B	P		
		D00	Proposed LS to S4 on codec list management	N2B	P		
		D10	Proposed LS to S2 on TR 23.907	N2B	P		
		D28	Proposed liaison statement to S2 on addition of APN parameter in Network-requested PDP context activation procedure	N2B	P		
		D30	Proposed LS to SPAN1 on use of White Book SCCP to support MAP	N2B	P		
		D32	Proposed LS to S2 & N1 on combined mobility management	N2B	P	Approved by N2; will go to S2 (Franco will deal)	
9.2	CRs handled in subgroups		List of CRs agreed by N2A				
		A71	CR 23.078-019 on Inclusion of the SS Invocation Notification procedure	N2A	P	Corresponds to R97 and R98 CRs already agreed in N2. 	
		B22	CR to 03.18 n. A050 on v 6.4.0 on Removal of TDP-Criteria from RCH	N2A	P		
		B23	CR to 03.18 n. A051 v 7.1.0 on Removal of TDP-Criteria from RCH	N2A	P	Mirror of B22	
		B24	CR to 23.018 n. 005 v 3.0.0 on Removal of TDP-Criteria from RCH	N2A	P	Mirror of B22	
		B25	CR to 03.78 v 6.4.0 n. A134 on Removal of TDP-Criteria from RCH	N2A	P		
		B26	CR to 03.78 v 7.1.0 n. A134 on Removal of TDP-Criteria from RCH	N2A	P	Mirror of B25	
		B27	CR to 23.078 v 3.0.0 n. 021 on Removal of TDP-Criteria from RCH	N2A	P	Mirror of B25	
		B28	CR to 03.79 v 6.1.0 n. A014 on Removal of TDP-Criteria from RCH	N2A	P		
		B29	CR to 03.79 v 7.1.0 n. A015 on Removal of TDP-Criteria from RCH	N2A	P	Mirror of B28	
		B30	CR to 23.079 v 3.0.0 n. 003 on Removal of TDP-Criteria from RCH	N2A	P	Mirror of B28	
		C10	CR 03.18-A056 on Notification of CF to gsmSCF before activation of CF process (Release 97)	N2A	P		
		C45	CR to 03.78-A132r1 on Call Reference Number	N2A	P	Revision of B18	
		C47	CR to 03.78-A133r1 on Call Reference Number	N2A	P	Mirror of C45; revision of B19	
		C49	CR 23.078- 023r1 on Call Reference Number	N2A	P	Mirror of C45; revision of B83	
		C51	CR to 03.18 v 6.4.0 n. A052r1 on GMSC CAMEL Phases in PRN	N2A	P	Revision of B31	
		C53	CR to 03.78 v 6.4.0 n. A136r1 on GMSC CAMEL Phases in PRN	N2A	P	Revision of B34	
		C55	CR 03.78-A138r1 on Value of Call Active parameter in ACR operation – clarifications in the SDL	N2A	P	Revision of B96	
		C59	CR 03.78-A141r1 on Corrections of process gsmSSF SDL	NTT	A	Revision of C20	
		C61	CR 03.78-A??? on Corrections of process gsmSSF SDL	N2A	P	Mirror of C59	
		C63	CR 23.078-A??? on Corrections of process gsmSSF SDL	N2A	P	Mirror of C59	
		C77	CR 03.79-A021r1 on Notification of CF to gsmSCF before activation of CF process (Release 98)	N2A	P	Mirror of C83; revision of C09	
		C83	CR 03.79-A022r1 on Notification of CF to gsmSCF before activation of CF process (Release97)	N2A	P	Revision of C11	
		C85	CR 03.78-A130r2 on Alignment of CAMEL2 FCI & Handling of CIR	Nokia	A	Revision of C81	
		D03	CR 23.079-??? on Notification of CF to gsmSCF before activation of  CF Process (Release 99)	N2A	P	Mirror of C83; agreed in N2A	
		D05	CR 23.018-??? on Notification of CF to gsmSCF before activation of  CF Process (Release 99)	N2A	P	Mirror of C10; agreed in N2A	
		D07	CR to 03.18 v 7.1.0 n. A053r1 on GMSC CAMEL Phases in PRN	N2A	P	Mirror of C51; revision of B32	
		D09	CR to 23.018 v 3.0.0 n. 007r1 on GMSC CAMEL Phases in PRN	N2A	P	Mirror of C51; revision of B33	
		D11	CR to 03.78 v 7.1.0 n. A137r1 on GMSC CAMEL Phases in PRN	N2A	P	Mirror of C53; revision of B35	
		D13	CR to 23.078 v 3.0.0 n. 022 on GMSC CAMEL Phases in PRN	N2A	P	Mirror of B34; revision of B36	
		D15	CR 23.078-??? on Value of Call Active parameter in ACR operation – clarifications in the SDL	N2A	P	Mirror of C55	
		D17	CR 03.78-A??? on Value of Call Active parameter in ACR operation – clarifications in the SDL	N2A	P	Mirror of C55	
		D19	CR 23.078-??? on Value of Call Active parameter in ACR operation – clarifications in the SDL	Ericsson	A	Mirror of C55	
		D24	List of CRs agreed by N2B	N2B Chairman	P		
		A04	CR 29.060-011 on New Scope for GTP Release 99	N2B	P	Withdrawn for further discussion on the issue of backward compatibility. Will be tabled for discussion at Eton.	
		A17	CR 09.02-A262 on Clarification on registration of a default priority level higher than the maximum entitled one (R97)	N2B	P		
		A18	CR 09.02-A263 on Clarification on registration of a default priority level higher than the maximum entitled one (R98)	N2B	P	Mirror of A17	
		A19	CR 29.002-028 on Clarification on registration of a default priority level higher than the maximum entitled one	N2B	P	Mirror of A17	
		A43	CR 002r1 to 23.008 v3.0.0 on IST for non-CAMEL subscribers	N2B	P		
		A44	CR 003r1to 23.016 on IST for non-CAMEL subscribers	N2B	P		
		A45	CR 029r1 to 29.002 on IST for non-CAMEL subscribers	N2B	P		
		A70	CR 09.02-A264 on Clarification of returning the MSISDN in SRIack	N2B	P		
		B07	CR 09.60-A??? (R97) on Specification of the MSISDN Information Element in GSM 09.60	N2B	P		
		B08	CR 09.60-A073 (R98) on Specification of the MSISDN Information Element in GSM 09.60	N2B	P	Mirror of B07	
		B48	CR 03.79-A018 on Handling of Release during forwarding interrogation of the HLR	N2B	P		
		B49	CR 03.79-A019 on Handling of Release during forwarding interrogation of the HLR	N2B	P		
		B57	CR 29.002-027r2 on Addition of the information elements and the ASN.1 definitions for Pre-paging	N2B	P		
		B60	CR 03.18-A054 on Separation of success & failure cases for OR of late call forwarding	N2B	P		
		B62	CR 23.018-023 on Separation of success & failure cases for OR of late call forwarding	N2B	P	Mirror of B60	
		B79	CR 09.02-A265 (R98) on clarification of LR-REJECT cause corresponding to Roaming Restriction Due To Unsupported Feature	N2B	P		
		C23	CR 23.003-008 on SSN allocation for RANAP,RNSAP	N2B	P	Needs base version on cover sheet changed to 3.1.3; otherwise approved.	
		C24	CR 09.02-A266 R96 on clarification on supported CAMEL phases in ISD ack	N2B	P	Agreed by N2B with change of category to F	
		C25	CR 09.02-267 R97 on clarification on supported CAMEL phases in ISD ack	N2B	P	Mirror of C24; agreed by N2B with change of category to F	
		C26	CR 09.02-268 R98 on clarification on supported CAMEL phases in ISD ack	N2B	P	Mirror of C24; agreed by N2B with change of category to F	
		C27	CR 29.002-042   on clarification on supported CAMEL phases in ISD ack	N2B	P	Mirror of C24; agreed by N2B with change of category to F	
		C50	CR 03.03-A031r1 on ASCII coding of <MNC> and <MCC> in APN OI	N2B	P	Revision of B97	
		C52	CR 03.03-A032r1 on ASCII coding of <MNC> and <MCC> in APN OI	N2B	P	Revision of B98; Mirror of C50	
		C54	CR 23.003-007r1 on ASCII coding of <MNC> and <MCC> in APN OI	N2B	P	Revision of B99; Mirror of C50	
		C58	CR 03.79-A020r1 on Separation of success & failure cases for OR of late call forwarding	N2B	P	Revision of B61	
		C60	CR 23.079-005r1 on Separation of success & failure cases for OR of late call forwarding	N2B	P	Revision of B63; mirror of C58	
		C62	CR 29.060-014 on Specification of the MSISDN Information Element in GSM 09.60	N2B	P	Mirror of B07	
		C74	CR 29.060-013r1 on Addition of APN parameter to PDU Notification Request	N2B	P		
		C76	CR 09.02-A271 on Editing error correction on VLR capabilities	N2B	P		
		C78	CR 29.002-044 on Editing error correction on VLR capabilities	N2B	P	Mirror of C76; Agreed by N2B	
		C94	CR 23.018-002r4 on Addition of the description for Pre-Paging	N2B	P		
		D02	CR 09.02-A269r1 on Addition of exception handling to the CancellationType (R97)	N2B	P	Revision of C31. 	
		D04	CR 09.02-A270 on Addition of exception handling to the CancellationType (R98)	N2B	P	Mirror of D02; revision of C32. Agreed in N2B	
		D06	CR 29.002-043r1 on Addition of exception handling to the CancellationType	N2B	P	Mirror of D02; revision of C33. Agreed by N2B	
9.3	Technical reports, WIDs	A59	Enhanced WID for OoBTC	N2B	P	Approved; will go to N1 and to N plenary for approval.	
10	Review of dates and hosts for future meetings	B81	Current status of hosting offers for N2 meetings	Vodafone	P		
	Documents NYA	B02	Draft version of R99 09.02	Ericsson		Withdrawn	
		B84	Frank Erfurt	Siemens			
		C34					
		C97					
		C99					
		D01					
		D19					
		D27					
		D29