vintuwei / jss7

Automatically exported from code.google.com/p/jss7
0 stars 0 forks source link

CAP - Implement initialDPGPRS CAP V3 Operation #205

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
CAP - Implement initialDPGPRS CAP V3 Operation

Original issue reported on code.google.com by amit.bha...@gmail.com on 19 Dec 2012 at 12:37

GoogleCodeExporter commented 9 years ago

Original comment by reachlas...@gmail.com on 29 Dec 2012 at 5:21

GoogleCodeExporter commented 9 years ago
Hi 
Please review the attached patch file for issues from 205 to 216 (except issue 
215).

Original comment by reachlas...@gmail.com on 8 Jan 2013 at 7:43

Attachments:

GoogleCodeExporter commented 9 years ago
Hello!

Here is a my comments:

1.
org.mobicents.protocols.ss7.cap.api.service.gprs.primitive.AccessPointName: and
org.mobicents.protocols.ss7.map.api.service.mobility.subscriberManagement.APN

(from TS 3GPP TS 23.003):
The encoding of the APN shall follow the Name Syntax defined in RFC 2181 [18], 
RFC 1035 [19] and RFC 1123 [20].
The APN consists of one or more labels. Each label is coded as a one octet 
length field followed by that number of
octets coded as 8 bit ASCII characters. Following RFC 1035 [19] the labels 
shall consist only of the alphabetic
characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following RFC 1123 
[20], the label shall begin and end with
either an alphabetic character or a digit. The case of alphabetic characters is 
not significant. The APN is not terminated
by a length byte of zero.
NOTE: A length byte of zero is added by the SGSN/MME at the end of the APN 
before interrogating a DNS
server.
For the purpose of presentation, an APN is usually displayed as a string in 
which the labels are separated by dots (e.g.
"Label1.Label2.Label3").

May be can create a getter (String getAPN()) amd a constructor with a parameter 
(String apn) where apn string=="Label1.Label2.Label3".

2. We need unittests for:
CAMELFCIGPRSBillingChargingCharacteristics, SGSNCapabilities

3. FreeFormatData: do we need to implement this internal structure?

4. ChargingCharacteristics:
for "empty" values for parameters I meant "0" values, not "-1".
because "0" is not possible.
But your chaice is possible, you only should add comments in 
ChargingCharacteristics like:
"-1 means an absent value"

5. GPRSCause:
I am little confused here.
A specification says about mapping to GTP cause, GMM cause and SM cause values.
But I do not undwerstand which values to use.
Can anybody help me?

6. ApplyChargingReportGPRS:
- active [2] BOOLEAN DEFAULT TRUE:
there are two approaches for encoding a parameter when value==TRUE:
a) sending boolean(true)
b) just sending nothing ("nothing" means "TRUE")
You selected the option a). I do not really know which of approaches is better 
:(
We can look at live traces to find which method is usually ised.
Another solution is boolean->Boolean replacing. And we can give to a CAP user 
an opportunity to select between true and null.
- pay attention to "RETURN RESULT TRUE" in ApplyChargingReportGPRS.
This means that we must implement "empty" (parameterless) 
ApplyChargingReportGPRSResponse
(not only ApplyChargingReportGPRSRequest) primitive.

7. EntityReleasedGPRSResponse:
we need to implement it

8. furnishChargingInformationGPRS:
bad implementation, look:
FurnishChargingInformationGPRSArg {PARAMETERS-BOUND : bound} ::=
FCIGPRSBillingChargingCharacteristics{bound}
FCIGPRSBillingChargingCharacteristics {PARAMETERS-BOUND : bound} ::= OCTET 
STRING (SIZE(1 .. 160))
(CONSTRAINED BY {-- shall be the result of the BER-encoded value of type -
CAMEL-FCIGPRSBillingChargingCharacteristics {bound}})
So the top level is OCTET STRING, getTag()->Tag.STRING_OCTET, 
getIsPrimitive()->true
And the OCTET STRING contains an encoded SEQUENCE

Original comment by serg.vet...@gmail.com on 9 Jan 2013 at 7:52

GoogleCodeExporter commented 9 years ago
Hi 

Thank you for your comments. Please review the attached patch as well. This 
patch includes implementations of issue 215 and 217.

A CAPFunctionalTest was also included just to check the gprs package.

Original comment by reachlas...@gmail.com on 20 Jan 2013 at 1:39

Attachments:

GoogleCodeExporter commented 9 years ago
Hi

I am doing some test cases based on the live trace. When I create a test case 
for EventReportGPRSRequest using the No.21 of the live trace, the encoded 
message byte stream didnt match with the live trace byte stream. When I check 
the error, i found that it is a problem with LocationInformationGPRS encoding. 
When I use below to encode CellGlobalIdOrServiceAreaIdOrLAIImpl of 
LocationInformationGPRS, our encoded stream matched with the live stream. 

if (this.cellGlobalIdOrServiceAreaIdOrLAI != null) {
                ((CellGlobalIdOrServiceAreaIdOrLAIImpl) this.cellGlobalIdOrServiceAreaIdOrLAI).encodeAll(asnOs, Tag.CLASS_CONTEXT_SPECIFIC, _ID_cellGlobalIdOrServiceAreaIdOrLAI);
}

Please advice me the whether this change is right or wrong.

And same thing happened for InitialDpGprsRequest live trace test case.

Thank you.

Original comment by reachlas...@gmail.com on 24 Jan 2013 at 2:37

GoogleCodeExporter commented 9 years ago
Hello!

I have revised cap-gprs2.patch. Here are my remarks:

1. SGSNCapabilities - we need extra constructor (+ CAPParameterFactory):
SGSNCapabilitiesImpl(boolean aoCSupportedBySGSN)

2. 
DetachSpecificInformation,DisconnectSpecificInformation,PdpContextchangeOfPositi
onSpecificInformation,
PDPContextEstablishmentAcknowledgementSpecificInformation,PDPContextEstablishmen
tSpecificInformation:
please replase code like
public int getTag() throws CAPException {
    return _ID_PdpContextchangeOfPositionSpecificInformation;
}
with 
public int getTag() throws CAPException {
    return Tag.SEQUENCE;
}
That is while _ID_PdpContextchangeOfPositionSpecificInformation code (and 
similar ones for other primitives) are only for encoding 
in GPRSEventSpecificInformation. Potencially it can be used in other place as a 
part of other primitives

3. ApplyChargingReportGPRSResponseImpl:
getMessageType():
applyChargingReportGPRS_Request -> applyChargingReportGPRS_Response (need to be 
created)

4. EntityReleasedGPRSResponseImpl: 
getMessageType():
entityReleasedGPRS_Request -> entityReleasedGPRS_Response (need to be created)

5. EventReportGPRSResponseImpl: 
getMessageType():
eventReportGPRSResponse_Request -> eventReportGPRSResponse_Response (need to be 
created)

6. About application context names support for different GPRS operations:
- initialDP is supported only by cap3-gprssf-scf ANC (21.3.50)
- ALL other GPRS operations are supported by both cap3-gprssf-scf ANC (21.3.50) 
and cap3-gsmscf-gprsssf (21.3.51)
Now several operations not supported by cap3-gsmscf-gprsssf. Please update it - 
it is important (both in CAPDialog* and CAPService*)

7. furnishChargingInformationGPRS: still bad encoding from my point of view
Your unit test encoded data for furnishChargingInformationGPRS is:
4, 20, -96, 18, -96, 16, -128, 8, 48, 6, -128, 1, 5, -127, 1, 2, -127, 1, 2, 
-126, 1, 1
I think it must be:
4, 20, 48, 18, -96, 16, -128, 8, 48, 6, -128, 1, 5, -127, 1, 2, -127, 1, 2, 
-126, 1, 1
4, 20, OCT_STR - FCIGPRSBillingChargingCharacteristics
  48, 18, SEQ CAMEL-FCIGPRSBillingChargingCharacteristics
    -96, 16, [0] SEQ fCIBCCCAMELsequence1 - choice 0
      -128, 8, 48, 6, -128, 1, 5, -127, 1, 2, [0] OCT_STR - FreeFormatData
      -127, 1, 2, [1] OCT_STR - PDPID
      -126, 1, 1  [2] ENUM - AppendFreeFormatData
So CAMEL-FCIGPRSBillingChargingCharacteristics must be SEQUENCE UNIVERSA, not 
CONTEXT-SPECIFIC

8. CAPServiceGprsImpl.furnishChargingInformationGPRSRequest:
error when tag checking: tag==octetstring+primitive

9. SendChargingInformationGPRSRequestImpl:
bad encoding - the root element is SEQUENCE, not STRING_OCTET

10. activityTestGPRS operation - is not implemented at all

Please commit your patch and then fix bugs

I will public CAPFunctional test scenarios soon for implementing

Original comment by serg.vet...@gmail.com on 27 Jan 2013 at 4:36

GoogleCodeExporter commented 9 years ago
Hello!

Here is scenarios for CAPFunctionalTest for GPRS.
Let's implement them.

    /**
     * GPSR messageflow 1
     * ACN=cap3-gprssf-scf
     * 
     * TC-BEGIN + InitialDPGPRSRequest + originationReference=1001
     *   TC-CONTINUE + requestReportGPRSEventRequest + destinationReference=1001 + originationReference=2001
     *   TC-CONTINUE + furnishChargingInformationGPRSRequest
     * TC-CONTINUE + eventReportGPRSRequest
     *   TC-CONTINUE + eventReportGPRSResponse
     *   TC-CONTINUE + resetTimerGPRSRequest
     *   TC-CONTINUE + applyChargingGPRSRequest + connectGPRSRequest
     * TC-CONTINUE + applyChargingReportGPRSRequest
     *   TC-END + applyChargingReportGPRSResponse
     */

    /**
     * GPSR messageflow 2
     * ACN=cap3-gsmscf-gprsssf
     * 
     * TC-BEGIN + activityTestGPRSSRequest + destinationReference=1001 + originationReference=2001
     *   TC-CONTINUE + activityTestGPRSSResponse + destinationReference=2001 + originationReference=1001
     * TC-CONTINUE + furnishChargingInformationGPRSRequest + continueGPRSRequest
     *   TC-CONTINUE + eventReportGPRSRequest
     * TC-END + eventReportGPRSResponse + cancelGPRSRequest
     */

    /**
     * GPSR messageflow 3
     * ACN=cap3-gprssf-scf
     * 
     * TC-BEGIN + eventReportGPRSRequest + destinationReference=2001 + originationReference=1001
     *   TC-END + eventReportGPRSResponse + connectGPRSRequest + sendChargingInformationGPRSRequest + destinationReference=1001 + originationReference=2001
     */

    /**
     * GPSR messageflow 4
     * ACN=cap3-gsmscf-gprsssf
     * 
     * TC-BEGIN + releaseGPRSRequest + destinationReference=1001 + originationReference=2001
     *   TC-END + destinationReference=2001 + originationReference=1001
     */

Original comment by serg.vet...@gmail.com on 28 Jan 2013 at 5:43

GoogleCodeExporter commented 9 years ago
Hi 

Thank you for the review and test cases. Please review the attached patch which 
includes test cases and bug fixes.

Original comment by reachlas...@gmail.com on 9 Feb 2013 at 1:33

Attachments:

GoogleCodeExporter commented 9 years ago
Hello!

About the last patch:

1. SendChargingInformationGPRSRequest
It looks like the encdoding is still wrong:
From your test:
48, 44, 
  -96, 42, 
    -96, 37, -96, 21, -128, 1, 1, -127, 1, 2, -126, 1, 3, -125, 1, 4, -124, 1, 5, -123, 1, 6, -122, 1, 7, -95, 12, -96, 6, -125, 1, 4, -124, 1, 5, -127, 2, 0, -34, 
    -127, 1, 1

I think it should be:
48, <length>, SEQUENCE - SendChargingInformationGPRSArg {PARAMETERS-BOUND: 
bound}::= SEQUENCE {
  128, <length>, [0] - primitive (OCTET STRING) - SCIGPRSBillingChargingCharacteristics {PARAMETERS-BOUND : bound} ::= OCTET STRING (SIZE (4 .. 255))
    48, <length> - CAMEL-SCIGPRSBillingChargingCharacteristics ::= SEQUENCE {
      160, <length>, <element> - aOCGPRS [0] AOCGPRS
      129, <length>, <element> - pDPID [1] PDPID OPTIONAL

2. CAPFunctionalTests: I have not checked details. You can check MAP and CAP 
functional tests now by creating a test trace pcap file and checking it then by 
WireShark.
To do this please follow these steps:
- select one test for testing, for example we starts with testGPRS1()
- insert at the beginning of the test code (for example before "long stamp = 
System.currentTimeMillis();") this code:
"this.saveTrafficInFile();"
- run the test for example in Eclipse
- then you can find a new file "MsgLog.pcap" in "cap" folder
- open it by WireShark and check if it "understands" all correctly
- remove or comment "this.saveTrafficInFile();" line

then you can move to a next gprs test.

Please commit your update. Pay attention that it will be conflicts in 
initialDPGprs merging because of this my update:
http://code.google.com/p/jss7/source/detail?r=b35cb0b7edbebd38ba4653b686cc576ff7
b185cd

Original comment by serg.vet...@gmail.com on 10 Feb 2013 at 9:28

GoogleCodeExporter commented 9 years ago
Hi

Please review the attached patch for SendChargingInformationGPRSArg encoding 
error.

Thank you.

Original comment by reachlas...@gmail.com on 13 Feb 2013 at 2:09

Attachments:

GoogleCodeExporter commented 9 years ago
This update looks good for me. Please commit it.

Original comment by serg.vet...@gmail.com on 13 Feb 2013 at 5:40

GoogleCodeExporter commented 9 years ago

Original comment by reachlas...@gmail.com on 5 Mar 2013 at 2:28

GoogleCodeExporter commented 9 years ago

Original comment by amit.bha...@gmail.com on 3 Nov 2013 at 12:10

GoogleCodeExporter commented 9 years ago

Original comment by amit.bha...@gmail.com on 3 Nov 2013 at 12:12