Closed Bug 853809 Opened 11 years ago Closed 11 years ago

[Buri][SMS]SMS don't implement function that the replace type of Short Message

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 736708

People

(Reporter: sync-1, Unassigned)

References

Details

(Whiteboard: Poland, IOT, Buri)

Firefox os  v1.0.1
 Mozilla build ID: 20130310070203.
 
 GCF blocking issue.
 
 +++ This bug was initially created as a clone of Bug #420091 +++
 
 [6915][WuYing]
 DEFECT DESCRIPTION:
 SMS don't implement function that the replace type of Short Message  
 
 Make GCF case block
 Test of the replace mechanism for SM type 1-7(34.2.7)
 
 REPRODUCING PROCEDURES:
 For example
 1.receive the first new message that have replace type6
 2.receive the second new message that have replace type6
 3.the phone beavhior  is :the first SMS didn't replace by the second SMS, but receive 2 new SMS--KO
 
 
 EXPECTED BEHAVIOUR:
 Replace the message exxist with smae SC and replace type.
 
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 medium
 REPRODUCING RATE:
 5/5
 For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #420091 description ++++++++++
blocking-b2g: --- → tef?
David, how critical is this for certification?
tianmin
Hi, 

This issue does not seem critical for certification, but I think that we should confirm if this could really block GCF certificate. 

Does anyone know if this test case could be marked as "N/A" or waived in GCF? (sorry, I'm not an expert on GCF testing). 

Thnks!
David
Providing reference to specs: 
http://www.3gpp.org/ftp/tsg_t/TSG_T/TSGT_18/docs/PDF/TP-020299.pdf
[Section 16.1.7]

"On receipt of a short message, the UE shall check to see if the associated Protocol Identifier contains a Replace Short Message Type code. If such a code is present, then the UE will check the associated originating address (TP-OA) and
replace any existing stored message having the same Protocol Identifier code and originating address with the new short message.

Reference(s) 3GPP TS 23.040 clause 9.2.3.2, 9.2.3.9."
(In reply to David Palomino [:dpv] from comment #4)
> Hi, 
> 
> This issue does not seem critical for certification, but I think that we
> should confirm if this could really block GCF certificate. 
> 
> Does anyone know if this test case could be marked as "N/A" or waived in
> GCF? (sorry, I'm not an expert on GCF testing). 
> 
> Thnks!
> David

needinfo to understand if this can be marked n/a or waived for GCF. maybe a feature declaration form will help
Flags: needinfo?(chengan.xiong)
16.1.6a Test of short message type 0 (≥ REL-5 UE)
16.1.6a.1 Definition and applicability
This tests that the UE correctly acknowledges the receipt of the short message type 0 to the SC in Circuit Switched
mode. The UE shall discard the contents of the short message type 0.
This test shall apply to all ≥ REL-5 UEs supporting receipt of short messages in CS mode.
16.1.6a.2 Conformance requirement
When a mobile terminated message is type 0, the UE shall acknowledge receipt of the short message to the SC but shall
discard its contents. This means that
- the UE shall be able to receive the type 0 short message irrespective of whether there is memory available in the
(U)SIM or ME or not,
- the UE shall not indicate the receipt of the type 0 short message to the user,
- the short message shall neither be stored in the (U)SIM nor ME.
Flags: needinfo?(chengan.xiong)
Michael, from your experience, does it sound like something we cannot get a GCF waiver? THis is not critical for us
Flags: needinfo?(mvines)
Depends on: 736708
Bug 736708 is not a complicated one but will bring interface changes to message database.
Not sure I'm the best person to make this call TBH, would prefer the operator partners assess the downside.
Flags: needinfo?(mvines)
Not a blocker for us, I'd suggest we don't block on this one. Please renominate if you disagree.
blocking-b2g: tef? → -
Flags: needinfo?(ffos-product)
I agree.
Flags: needinfo?(ffos-product)
Leader in validation told us it's a GCF case.
Whiteboard: Poland, IOT, Buri
There is a serious possibility that device will not go thru
the GCF certification. Regarding the common DT rule this might be a big problem
for final technical approval from our side. Please consider this
modification.
 Shira-48964, 2-Medium
(In reply to 田旻 from comment #14)
> There is a serious possibility that device will not go thru
> the GCF certification. Regarding the common DT rule this might be a big
> problem
> for final technical approval from our side. Please consider this
> modification.
>  Shira-48964, 2-Medium
Please have a look at the 33'th item,"replace SMS", of Table A.25: Additional Information of 3GPP TS 51.010-2. This "replace SMS" is *optional* item in GCF certification.
Hi Mozilla, mark leo? per partner requirement.
blocking-b2g: - → leo?
Wilfred, can you validate if this is truly required given that it did not block 1.0.1 certification?
Flags: needinfo?(wmathanaraj)
For now, minusing.
blocking-b2g: leo? → -
(In reply to Alex Keybl [:akeybl] from comment #18)
> For now, minusing.

how about koi?
blocking-b2g: - → koi?
add to backlog bug 891754
blocking-b2g: koi? → ---
Status: NEW → RESOLVED
Closed: 11 years ago
No longer depends on: 736708
Resolution: --- → DUPLICATE
No longer blocks: comms_backlog
Flags: needinfo?(wmathanaraj)
You need to log in before you can comment on or make changes to this bug.